Захват аккаунтов все чаще становится для атакующих не запасным, а основным сценарием входа в корпоративную инфраструктуру. По данным, которые приводит BleepingComputer, на компрометацию учетных данных пришлось 22% всех инцидентов в 2025 году, и для российских IT-команд это плохая новость: старый набор защиты в духе «пароль посложнее плюс MFA» уже не закрывает проблему целиком.
Логика у атакующих предельно прагматичная. Ломать инфраструктуру шумно, долго и дорого, а вот войти под легитимной учеткой намного проще. Особенно если компания живет в гибридном режиме, допускает BYOD, раздает доступ подрядчикам и держит десятки SaaS-сервисов, облаков, VPN и внутренних приложений. В такой схеме служба безопасности часто уже не видит главное: кто именно зашел, с какого устройства, в каком состоянии это устройство и насколько вообще этому сеансу можно доверять.
На этом фоне привычный фишинг тоже изменился. Речь уже не только о краже пароля. Злоумышленники бьют по самой процедуре аутентификации: используют MFA fatigue, или prompt bombing, когда пользователю снова и снова прилетают push-запросы на подтверждение входа, пока он не нажмет «разрешить» просто чтобы это прекратилось. Самый известный пример такого сценария произошел в 2022 году с Uber: сотрудника засыпали MFA-запросами, один из них был подтвержден, после чего атакующие получили начальную точку входа, нарастили привилегии и пошли глубже в облачную инфраструктуру компании.
Вторая проблема еще неприятнее: даже корректно настроенная MFA не всегда мешает захвату аккаунтов, если злоумышленник ворует уже не пароль, а сессионный токен после успешного входа. Для этого используют adversary-in-the-middle-инструменты, reverse proxy-схемы и угон активной сессии. По сути, защита на входе срабатывает, а потом атакующий просто забирает результат этой успешной проверки. Для SOC и IAM-команд это один из самых неудобных сценариев: в логах виден как будто нормальный пользователь, а не классический взлом.
Отдельно рынок получил сигнал, что и сам фишинг стал гораздо убедительнее. В материале приводится пример кампании, обнаруженной исследователями Outpost24, материнской компании Specops: злоумышленники использовали легитимный домен Cisco в многоступенчатой схеме редиректов, чтобы повысить доверие и обойти часть защитных механизмов. Это важный сдвиг. Если раньше ИБ-обучение часто сводилось к плакату «не кликайте по кривым ссылкам», то теперь этого явно мало. Поддельные страницы собираются на легитимных хостингах, маскируются под настоящие порталы входа и все чаще дополняются контентом, который выглядит слишком аккуратно, чтобы сразу считать его разводкой.
Есть и еще одна причина, почему захват аккаунтов пошел вверх: конечные устройства стали слабым местом почти по умолчанию. Сотрудники заходят в корпоративные системы с домашних ноутбуков, личных смартфонов и машин вне классического периметра. У IT-отдела в такой модели не всегда есть нормальная телеметрия: установлены ли обновления, не отключены ли защитные средства, нет ли на устройстве инфостилера. А именно инфостилеры в последние годы стали одним из самых удобных инструментов для злоумышленников: они собирают логины, пароли, сохраненные в браузере данные и те самые cookies активных сессий, которые позволяют обойти часть традиционных проверок без лишнего шума.
Отсюда и главный вывод для бизнеса: сам факт успешной аутентификации больше не равен доверию. Если компания по-прежнему принимает решение об доступе только по схеме «логин, пароль, второй фактор пройден», она играет по правилам, которые атакующие уже изучили. В статье Specops продвигает собственный подход через Device Trust, но сама постановка задачи вполне отражает реальный тренд рынка: проверять нужно не только личность, но и устройство, и состояние сессии на протяжении всей работы, а не один раз в момент входа. Это уже ближе к нормальной Zero Trust-модели, чем к старому IAM-подходу, где после логина пользователь как будто автоматически становится благонадежным.
Практически это означает несколько довольно приземленных вещей. Во-первых, организациям придется жестче связывать доступ к чувствительным ресурсам с доверенными устройствами, а не только с пользователями. Во-вторых, нужна непрерывная проверка состояния конечной точки: версия ОС, браузера, наличие защитного ПО, отключенные контроли, признаки заражения. В-третьих, политика доступа должна быть гибкой. Жесткая блокировка всего подряд дает красивую отчетность, но быстро ломает рабочие процессы. Намного полезнее сценарии, где система может ограничить рискованный доступ, предложить remediation и не превращать каждую проблему в аварийный сброс пароля или тикет в сервис-деск.
Для разработчиков, продактов и IT-руководителей здесь есть неприятный, но полезный вывод: захват аккаунтов перестал быть задачей только для команды ИБ. Это уже архитектурный вопрос. Если корпоративный стек строится вокруг SaaS, удаленного доступа, подрядчиков и личных устройств сотрудников, то контроль доверия к устройству и сессии должен быть встроен в общую модель доступа так же естественно, как SSO и MFA. Иначе бизнес продолжит вкладываться в аутентификацию на входе, в то время как атака давно переехала на уровень после входа.
Следующий этап этой гонки выглядит довольно очевидно: чем больше компаний переводят доступ в облака и размывают периметр, тем ценнее для атакующего становится не эксплойт, а чужая легитимная сессия. Вопрос уже не в том, нужен ли второй фактор, а в том, готовы ли организации перестать считать его финальной точкой проверки и начать относиться к каждому активному сеансу как к объекту постоянного недоверия.