Каждый пентестер рано или поздно упирается в MFA. Клиент включил двухфакторку, отчёт выглядит чисто, все довольны. Но вот что я вижу на проектах раз за разом: MFA защищает ровно один момент - ввод второго фактора. Всё, что до и после - attack surface, который большинство организаций даже не мониторит. Разберу конкретные техники обхода многофакторной аутентификации - от перехвата OTP кода через SS7 до adversary-in-the-middle фишинг-прокси - с маппингом на MITRE ATT&CK и рекомендациями по детектированию для blue team.
Почему MFA защищает только момент аутентификации
Заблуждение, на которое я натыкаюсь у клиентов с завидной регулярностью: «мы внедрили MFA, значит учётные записи защищены». В реальности MFA прикрывает authentication moment - тот короткий промежуток, когда пользователь подтверждает себя вторым фактором. После успешной аутентификации система выдаёт session token, cookie или OAuth refresh token, и дальше именно эти артефакты определяют доступ. Никакого второго фактора для них уже не требуется.Кто владеет session token - тот и в аккаунте. Без повторного прохождения MFA. Токен не содержит биометрических данных, не привязан к устройству пользователя (в большинстве реализаций) и не требует непрерывной верификации. Это архитектурная реальность, которую эксплуатируют все техники обхода двухфакторной аутентификации, описанные ниже.
По данным Obsidian Security, атаки на идентификацию выросли на 32% в первой половине 2025 года, причём более 97% из них начинались с массовых попыток подбора паролей к MFA-защищённым аккаунтам. Атакующие не пытаются взломать криптографию MFA - они ищут зазоры вокруг неё: где живут токены, где пользователь принимает решения, где legacy-системы не поддерживают второй фактор.
Перехват OTP кода: SMS, SS7 и фишинг в реальном времени
Одноразовые коды - самый распространённый второй фактор и одновременно самый дырявый. Атаки на MFA через перехват OTP кода, делятся на две категории: перехват канала доставки и перехват кода через фишинг.SS7 атака и перехват SMS-кодов
Протокол SS7 (Signaling System 7) - основа сигнализации в сотовых сетях, спроектированная в 1970-х без какой-либо модели угроз (тогда доступ к телеком-инфраструктуре имели только операторы, и все друг другу доверяли). SS7 атака на перехват SMS работает на уровне телекоммуникационной инфраструктуры: атакующий, имея доступ к SS7-сети (через скомпрометированного оператора, арендованный шлюз или уязвимый узел), перенаправляет SMS-сообщения жертвы на свой номер. Жертва ничего не замечает - телефон работает нормально, но входящие SMS с OTP-кодами маршрутизируются через узел атакующего.В MITRE ATT&CK SS7-перехват ближе всего к технике Multi-Factor Authentication Interception (T1111, Credential Access), хотя T1111 описывает перехват на уровне endpoint - прямого маппинга для SS7-атак в Enterprise-матрице нет. На практике доступ к SS7-шлюзу - ресурс не массовый, но вполне достижимый для мотивированных группировок. Для большинства пентестеров SS7 остаётся скорее теоретическим вектором, но понимать его нужно для правильной оценки рисков SMS-based MFA в threat model.
Вывод тут простой: любая MFA, завязанная на SMS, уязвима на уровне протокола доставки. Это не баг реализации на стороне приложения - это архитектурный дефект канала.
TOTP-код - всего лишь 6-значное число, валидное в 30-секундном окне. Большинство реализаций допускают drift в одно-два окна (то есть принимают код, актуальный 60-90 секунд).
Это создаёт практическое окно для атаки через фишинг MFA токенов: если атакующий в реальном времени получает TOTP-код от жертвы через фишинговую страницу и в течение тех же 30-90 секунд ретранслирует его на легитимный сервис - аутентификация проходит. Именно этот принцип лежит в основе adversary-in-the-middle атак, о которых ниже.
Аутентификатор-приложение безопаснее SMS, но от фишинга в реальном времени не спасает. Это стоит доносить до клиентов при составлении отчётов: TOTP снижает риск перехвата канала, но не устраняет риск социальной инженерии 2FA.
SIM-свопинг атака: как угоняют номер через оператора
SIM-свопинг атака - техника, при которой атакующий убеждает мобильного оператора перенести номер жертвы на новую SIM-карту. После переноса все входящие звонки и SMS (включая OTP-коды) поступают на устройство злоумышленника.Анатомия SIM-swap
Attack flow выглядит так:- Разведка. Атакующий собирает персональные данные жертвы: ФИО, дата рождения, последние четыре цифры паспорта, ответы на контрольные вопросы. Источники - утечки баз данных, соцсети, OSINT.
- Звонок оператору. Атакующий звонит в поддержку мобильного оператора, представляется владельцем номера и просит замену SIM-карты («потерял телефон», «повредил SIM»). Дальше классическая социальная инженерия: давление, срочность, детальное знание персональных данных.
- Перенос номера. Оператор активирует новую SIM. Телефон жертвы теряет связь с сетью. Все SMS, включая MFA-коды, начинают приходить атакующему.
- Использование. Атакующий вводит украденные ранее учётные данные (логин + пароль) и подтверждает вход через перехваченный SMS-код. Session token получен, MFA пройдена.
Что делает SIM-swap релевантным для пентестера
В red team engagement SIM-swap редко выполняется буквально (это уголовка вне санкционированного скоупа), но его включение в threat model критически важно. При оценке корпоративной MFA-стратегии проверяйте:- Какой процент сотрудников использует SMS как второй фактор (особенно привилегированные аккаунты).
- Есть ли механизм обнаружения SIM-swap (мониторинг потери сигнала, alert на смену IMSI).
- Привязана ли MFA к конкретному устройству, а не к номеру телефона.
MFA fatigue атака: push-бомбинг и усталость пользователя
MFA fatigue атака (push-усталость атака) - техника, при которой атакующий, зная пароль жертвы, инициирует десятки или сотни push-уведомлений на устройство пользователя. Расчёт на то, что тот одобрит одно из них от усталости, раздражения или просто по ошибке.В MITRE ATT&CK это техника Multi-Factor Authentication Request Generation (T1621, Credential Access). Атакующий не перехватывает второй фактор - он генерирует легитимные запросы на аутентификацию, эксплуатируя человеческий фактор.
Механика push-бомбинга на практике
Предпосылка: атакующий уже имеет валидную пару логин/пароль (из утечки, credential stuffing, фишинга). Дальше:- Атакующий инициирует вход в целевой сервис - система отправляет push-уведомление на устройство жертвы.
- Жертва отклоняет. Атакующий повторяет.
- Цикл крутится десятки раз, часто в нерабочее время (ночью, рано утром) - когда когнитивный контроль пользователя на минимуме.
- Параллельно атакующий может позвонить жертве, представившись IT-поддержкой, и попросить «подтвердить системное обновление». Именно так работала группа Lapsus$ в кампаниях 2022 года против Microsoft, Nvidia и Samsung.
- Жертва одобряет push. Атакующий получает валидный session token.
Кейс Uber 2022: анатомия успешной MFA fatigue атаки
Самый показательный публичный кейс - 15 сентября 2022 года. По данным Obsidian Security, атакующий скомпрометировал учётные данные подрядчика Uber и начал бомбить push-уведомлениями. Подрядчик отклонял их больше часа, после чего решил, что это системный сбой, и одобрил одно. За несколько минут атакующий получил доступ к внутренним системам Uber, Slack-каналам и репозиториям исходного кода.MFA сработала ровно так, как была спроектирована. Сломался человек.
Аналогичный вектор использовался при атаке на Cisco Systems в августе 2022 года - атакующие сочетали vishing (голосовой фишинг) с MFA-бомбингом, представляясь сотрудниками helpdesk. По данным LMG Security, злоумышленники получили доступ к внутренней сети и провели эскалацию привилегий по множеству систем.
Adversary-in-the-Middle: фишинг-прокси как главная угроза MFA
Если MFA fatigue эксплуатирует человека, то adversary-in-the-middle MFA (AiTM) бьёт по архитектуре аутентификации. Это самый технически элегантный bypass 2FA метод, и регулярно использую его в red team операциях.Attack flow через Evilginx2
Evilginx2 работает как reverse proxy между жертвой и легитимным сервисом. Принцип:- Атакующий разворачивает Evilginx2 на своём сервере и настраивает phishlet - конфигурацию, имитирующую целевой сервис (Microsoft 365, Google Workspace и др.).
- Жертва получает фишинговую ссылку (Phishing, T1566, Initial Access) и переходит на домен атакующего.
- Evilginx2 проксирует все запросы на реальный сервис. Жертва видит настоящую страницу входа, вводит логин, пароль, проходит MFA (push, TOTP - без разницы).
- После успешной аутентификации реальный сервис выдаёт session cookie. Evilginx2 перехватывает его (Steal Web Session Cookie, T1539, Credential Access).
- Атакующий импортирует cookie в свой браузер и получает полный доступ к аккаунту без какого-либо MFA-челленджа (Web Session Cookie, T1550.004, Defense Evasion / Lateral Movement).
В MITRE ATT&CK AiTM-атака задействует сразу несколько техник: Adversary-in-the-Middle (T1557, Credential Access / Collection) для позиционирования, Phishing (T1566) для доставки ссылки, Steal Web Session Cookie (T1539) для перехвата токена и Valid Accounts (T1078, Defense Evasion / Persistence / Privilege Escalation / Initial Access) для использования украденной сессии.
Масштаб проблемы: цифры и инструментарий
По данным Microsoft Digital Defense Report (на которые ссылается Obsidian Security), AiTM-атаки выросли на 146% за последний год - около 40 000 инцидентов ежедневно. На рынке Phishing-as-a-Service крутится как минимум 11 крупных фишинг-китов для AiTM-атак: Tycoon 2FA, EvilProxy, Mamba, Evilginx2 и другие. Аренда доступа - несколько сотен долларов в месяц. Порог входа стал неприлично низким.Базовая структура phishlet в Evilginx2 выглядит так:
YAML:
# Структура phishlet (концепция)
name: 'example-target'
proxy_hosts:
- phish_sub: 'login'
orig_sub: 'login'
domain: 'target-service.com'
session: true
auth_tokens:
- domain: '.target-service.com'
keys: ['session_id', 'auth_token']Document.cookie = "session_id=<stolen_value>". С этого момента браузер атакующего неотличим от легитимной сессии пользователя.Помимо Evilginx2, по данным Bugcrowd, существуют инструменты прокси-фишинга, где жертва фактически авторизуется в браузере на машине атакующего. Отдельно набирает обороты device code phishing в Azure - эксплуатация легитимного потока аутентификации устройств Microsoft, при котором жертва вводит код на настоящей странице Azure, но авторизует при этом приложение атакующего. Красивый вектор, и пока мало кто на него мониторит.
Маппинг техник обхода MFA на MITRE ATT&CK
Для структурирования результатов red team engagement в отчёте - таблица маппинга:| Техника атаки | MITRE ATT&CK ID | Тактика | Обходит MFA-тип |
|---|---|---|---|
| SS7-перехват SMS | T1111 | Credential Access | SMS OTP |
| SIM-свопинг | T1451 (Mobile) + T1598 | Credential Access, Reconnaissance | SMS OTP |
| MFA fatigue / push-бомбинг | T1621 | Credential Access | Push-уведомления |
| AiTM фишинг-прокси | T1557 + T1539 | Credential Access, Collection | SMS, TOTP, Push |
| Кража session cookie | T1539 + T1550.004 | Credential Access, Lateral Movement | Все типы MFA |
| Модификация MFA на сервере | T1556.006 | Credential Access, Persistence, Defense Evasion | Все типы MFA |
| Использование украденной сессии | T1078 | Initial Access, Persistence, Privilege Escalation | Все типы MFA |
Обратите внимание: AiTM-прокси обходит все типы MFA кроме FIDO2/WebAuthn. Криптографические ключи FIDO2 привязаны к origin (домену). Фишинговый домен атакующего не совпадёт с легитимным, и аутентификатор откажется подписывать запрос. Единственный тип MFA, который архитектурно устойчив к AiTM.
Детектирование обхода MFA: практический чеклист
Как пентестер, вы должны не только уметь проводить атаки на MFA, но и указывать blue team конкретные точки детектирования. Вот что стоит мониторить.Сигналы компрометации в логах
MFA fatigue (T1621):- Множественные отклонённые push-запросы за короткий период (больше 5 за 10 минут для одного аккаунта)
- Успешная аутентификация сразу после серии отклонений
- Push-запросы из нехарактерных геолокаций или IP-диапазонов
- Аутентификации в нерабочее время
- Impossible travel: session cookie используется из IP/геолокации, отличной от той, где была аутентификация
- Смена user-agent между аутентификацией и использованием сессии
- Массовый доступ к ресурсам (перечисление почтовых ящиков, скачивание файлов из SharePoint) в первые минуты после входа - нетипичное поведение для пользователя
- Создание mail forwarding rules на внешние адреса сразу после аутентификации
- Потеря мобильного сигнала у сотрудника с последующей успешной SMS-аутентификацией (корреляция требует интеграции с телеком-провайдером или MDM)
- Аутентификация с SMS-кодом из региона, не совпадающего с регистрацией SIM-карты
Detection rule для AiTM: пример логики
Самый надёжный детект для AiTM-атаки - сопоставление IP-адреса аутентификации с IP последующей активности. В Azure AD / Entra ID через KQL:
Код:
SigninLogs
| where ResultType == 0
| extend AuthIP = IPAddress
| join kind=inner (
AuditLogs | where TimeGenerated > ago(1h)
) on CorrelationId
| where AuthIP != CallerIpAddress
| project TimeGenerated, UserPrincipalName, AuthIP, CallerIpAddressПо данным Bugcrowd, AiTM-атаки через Evilginx выполняются с недоверенного устройства, что детектится как impossible travel при наличии хороших правил. Привязка Conditional Access Policies к compliant devices существенно сужает attack surface.
Защита: что реально работает против bypass 2FA методов
На основании анализа всех техник - ранжирование MFA-методов по устойчивости:| MFA-метод | AiTM-прокси | SIM-swap | Push fatigue | SS7-перехват |
|---|---|---|---|---|
| SMS OTP | Обходится | Обходится | Неприменимо | Обходится |
| TOTP (Google Auth) | Обходится | Устойчив | Неприменимо | Устойчив |
| Push-уведомления | Обходится | Устойчив | Обходится | Устойчив |
| FIDO2 / WebAuthn | Устойчив | Устойчив | Устойчив | Устойчив |
Почему FIDO2 устойчив к фишинг-прокси? Криптографический ключ привязан к конкретному домену (origin binding). Когда жертва оказывается на фишинговом домене, аутентификатор не подписывает challenge - origin не совпадает с зарегистрированным. Защита работает на криптографическом уровне, бдительность пользователя тут вообще не при чём.
Помимо перехода на FIDO2, организации могут ощутимо снизить риски через:
- Number matching в push-уведомлениях - вместо простого «Approve/Deny» пользователь вводит число с экрана входа. AiTM не убивает, но MFA fatigue как вектор хоронит.
- Conditional Access Policies с привязкой к compliant device - токен принимается только с устройства из MDM. Машина атакующего не compliant, и AiTM ломается.
- Лимитирование push-запросов - не более N запросов в M минут, блокировка аккаунта при превышении.
- Мониторинг impossible travel - корреляция IP/геолокации аутентификации с последующей активностью.
- Отказ от SMS как фактора - особенно для привилегированных аккаунтов и административного доступа.
Вопрос к читателям
В Entra ID (Azure AD) через Conditional Access Policy можно настроить Authentication Strength, требующую phishing-resistant MFA (FIDO2/Windows Hello) для конкретных ролей. У кого в инфраструктуре уже разделены CA-политики для обычных пользователей и privileged accounts типа Global Admin? КакойauthenticationStrength задаёте для admin-ролей и используете ли deviceFilter с device.isCompliant -eq True совместно с phishing-resistant requirement? Интересно увидеть конфиг, который реально блокирует AiTM в проде.
Последнее редактирование модератором:
