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

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

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

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

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

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

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

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

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

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

MFA защищает вход, но не гарантирует безопасность сессии

Внедрение MFA остаётся одним из наиболее эффективных базовых контролей.

Проблема начинается тогда, когда организация воспринимает его как конечную точку identity security.

Атакующему необязательно знать второй фактор, если он может: -похитить уже авторизованную browser session; - перехватить session cookie через adversary-in-the-middle phishing; - заставить пользователя подтвердить push-запрос; - зарегистрировать собственное MFA-устройство; - получить refresh token; - воспользоваться восстановлением доступа; - убедить help desk сбросить пароль или фактор аутентификации.

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

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

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

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

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

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