Современная кибератака всё чаще выглядит как обычный вход

Мы привыкли представлять кибератаку как попытку что-то сломать: подобрать пароль, обойти межсетевой экран, запустить вредоносный код или использовать уязвимость.

Но всё чаще злоумышленнику не требуется взламывать систему в привычном смысле. Достаточно получить легитимный пароль, активную сессию, OAuth-токен или убедить службу поддержки восстановить доступ.

После этого атака выглядит почти так же, как обычная работа сотрудника.

Пользователь успешно прошёл аутентификацию. MFA подтверждена. Запросы идут через штатный интерфейс. У учётной записи есть необходимые права. Формально большинство защитных механизмов видит не взлом, а разрешённую активность.

Именно поэтому identity security сегодня должна отвечать не только на вопрос «правильно ли введён пароль», но и на более сложный вопрос:

можем ли мы продолжать доверять субъекту, который действует от имени этой идентичности?

Verizon DBIR 2026 зафиксировал важное изменение: эксплуатация уязвимостей впервые за 19 лет существования отчёта обошла украденные учётные данные и стала ведущей точкой входа, фигурируя в 31% исследованных компрометаций. (Verizon)

Это не означает, что identity-риски отошли на второй план.

Первоначальное проникновение и дальнейшее развитие атаки — разные этапы. Даже получив доступ через уязвимость, атакующий стремится похитить учётные данные, токены, cookies, ключи, сервисные идентичности или привилегированные роли. Ему выгоднее перестать выглядеть как внешний злоумышленник и начать выглядеть как внутренний доверенный субъект.

Данные Microsoft показывают и другую сторону проблемы: 97% зафиксированных компанией identity-атак были связаны с password spraying. Большая часть атакующих по-прежнему использует не самые сложные, а самые дешёвые и масштабируемые способы эксплуатации слабой идентификации. (Microsoft)

Поэтому противопоставлять vulnerability management и identity security неправильно. Зрелая защита должна учитывать оба сценария:

Внедрение MFA остаётся одним из наиболее эффективных базовых контролей. Проблема начинается тогда, когда организация воспринимает его как конечную точку identity security.

Атакующему необязательно знать второй фактор, если он может:

MITRE ATT&CK отдельно описывает кражу web session cookie: получив cookie действующей сессии, злоумышленник может обращаться к сервису как уже аутентифицированный пользователь, в ряде сценариев обходя MFA. (attack.mitre.org)

С точки зрения приложения всё выглядит корректно. Оно получает допустимый токен, связанный с существующим пользователем. Поэтому проверка «успешно ли пройдена MFA» ещё ничего не говорит о том, кто фактически управляет сессией через пять минут после входа.

MFA подтверждает событие аутентификации. Оно не доказывает легитимность всех последующих действий.

Один из наиболее показательных identity attack paths сегодня проходит не через сложную техническую уязвимость, а через help desk.

Злоумышленник собирает информацию о сотруднике, звонит в службу поддержки, сообщает о потерянном телефоне или невозможности войти и просит сбросить пароль либо зарегистрировать новый фактор MFA.

В обсуждении тактик Scattered Spider представители FBI и Mandiant отмечали успешные компрометации, в которых атакующие убеждали сотрудников help desk предоставить доступ или восстановить учётную запись. В отдельных случаях традиционные контрольные вопросы не обеспечивали надёжной проверки личности. (FBI)

Это важный управленческий вывод: процедура восстановления доступа является таким же security control, как MFA, PAM или Conditional Access.

Если процесс enrolment защищён сильнее, чем процесс recovery, атакующий просто выберет более слабый маршрут.

Поэтому обучение пользователей само по себе не решает проблему. Необходимо пересматривать:

Ещё один недооценённый сценарий — злоупотребление OAuth.

Пользователь может не передавать злоумышленнику пароль. Вместо этого его убеждают предоставить вредоносному приложению разрешение на чтение почты, файлов, контактов или других корпоративных данных.

Microsoft определяет consent phishing как атаку, при которой пользователя обманом заставляют предоставить вредоносному cloud-приложению права на доступ к легитимным сервисам и данным. (Microsoft Learn)

С точки зрения инфраструктуры пользователь сам подтвердил разрешение. Пароль не украден. MFA не обязательно обходить. Вредоносное приложение действует через документированный API.

Это снова показывает ограниченность традиционного взгляда на атаку. Вопрос заключается не только в том, кто вошёл в систему, но и в том:

Identity security должна охватывать не только сотрудников. В контур цифрового доверия входят приложения, сервисные аккаунты, workload identities, API-ключи, агенты автоматизации и AI-системы.

Многие защитные системы лучше обнаруживают технически запрещённое действие, чем подозрительную последовательность разрешённых действий.

Попытка входа из заблокированной страны заметна.

Но что делать, если:

Каждое отдельное событие может выглядеть допустимым. Риск проявляется только в контексте.

Например:

По отдельности это могут быть легитимные действия. Вместе — вероятный identity attack path.

Поэтому SOC должен анализировать не только authentication events, но и полную цепочку действий после входа.

Типовой сценарий может выглядеть так:

1. Разведка

Атакующий собирает сведения о сотруднике, его руководителе, используемых сервисах, подрядчиках и процедурах поддержки.

↓

2. Получение артефакта доверия

Пароль, session cookie, OAuth consent, API-ключ, refresh token, доступ к телефону или возможность сбросить MFA.

↓

3. Вход или восстановление доступа

Использование штатной формы входа, SSO, help desk, self-service recovery либо легитимного API.

↓

4. Закрепление

Регистрация нового MFA-метода, создание OAuth-приложения, добавление recovery-адреса, выпуск токена или создание скрытого правила пересылки.

↓

5. Повышение привилегий

Запрос административной роли, компрометация service account, использование избыточных прав, переход к PAM или облачной консоли.

↓

6. Доступ к данным и системам

Почта, документы, CRM, репозитории, облачная инфраструктура, системы разработки и резервные копии.

↓

7. Эксплуатация доверия

Кража данных, мошеннические платежи, изменение конфигураций, отключение защиты, дальнейшее социальное воздействие или подготовка ransomware-атаки.

На каждом этапе действия могут быть технически разрешёнными. Поэтому контролировать нужно не только права, но и обоснованность их использования.

Во многих компаниях IAM всё ещё воспринимается как административная функция:

Этого недостаточно.

Зрелая identity security должна объединять как минимум:

Особенно важен последний пункт. Недостаточно заблокировать пароль, если у атакующего остаются действующие tokens или sessions.

Современные механизмы Continuous Access Evaluation позволяют сервисам реагировать на критические события — например, блокировку пользователя, изменение риска или административный отзыв сессии — не дожидаясь стандартного истечения access token. Однако такой контроль зависит от поддержки со стороны конкретных приложений и ресурсов. (Microsoft Learn)

Это хороший пример правильной архитектурной логики: доверие не должно выдаваться один раз на входе и безусловно сохраняться до окончания сессии.

Процент пользователей с MFA важен, но не показывает:

Особый приоритет — администраторы, help desk, разработчики, финансовые сотрудники, руководители и пользователи облачных консолей.

Сброс пароля и MFA должен считаться высокорисковой операцией. Для него необходимы независимая проверка личности, ограничение полномочий оператора и отдельный мониторинг.

Эти направления не должны развиваться как отдельные проекты. SOC необходимо видеть изменения прав, регистрацию новых факторов, OAuth consent, выдачу привилегий и признаки компрометации устройства.

Успешная аутентификация — начало контроля, а не его завершение. Нужны поведенческий контекст, риск сессии, device posture, история пользователя и чувствительность выполняемой операции.

Организация должна уметь одновременно:

Я не считаю MFA конечной точкой identity security.

MFA — необходимый контроль, но он защищает преимущественно момент подтверждения доступа. Современная атака развивается до входа, во время восстановления учётной записи и после успешной аутентификации.

Поэтому защищать нужно весь жизненный цикл доверия:

кто получил идентичность, как она была подтверждена, с какого устройства действует, какие права использует, соответствует ли поведение контексту и можем ли мы немедленно прекратить доверие.

Главная ошибка — продолжать искать только признаки взлома там, где злоумышленник уже действует легитимными средствами.

Вопрос «успешно ли пользователь вошёл в систему?» больше не является достаточным.

Гораздо важнее другое:

почему мы всё ещё доверяем этой сессии?

Когда атакующий использует допустимый токен, штатный API и законные права, отличие между сотрудником и злоумышленником определяется не фактом входа, а контекстом действий.

Поэтому identity должна перестать быть службой выдачи доступов и стать системой управления цифровым доверием.

А зрелость такой системы определяется не тем, насколько хорошо она разрешает вход, а тем, насколько быстро способна распознать и прекратить ошибочно выданное доверие.

Подписывайтесь на мой ТГ канал: @ib_decisions