|
https://forum.antichat.xyz/attachmen...d10dc1a50a.png
Каждый пентестер рано или поздно упирается в 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 выглядит так:
Что делает SIM-swap релевантным для пентестера В red team engagement SIM-swap редко выполняется буквально (это уголовка вне санкционированного скоупа), но его включение в threat model критически важно. При оценке корпоративной MFA-стратегии проверяйте:
MFA fatigue атака: push-бомбинг и усталость пользователя MFA fatigue атака (push-усталость атака) - техника, при которой атакующий, зная пароль жертвы, инициирует десятки или сотни push-уведомлений на устройство пользователя. Расчёт на то, что тот одобрит одно из них от усталости, раздражения или просто по ошибке. В MITRE ATT&CK это техника Multi-Factor Authentication Request Generation (T1621, Credential Access). Атакующий не перехватывает второй фактор - он генерирует легитимные запросы на аутентификацию, эксплуатируя человеческий фактор. Механика push-бомбинга на практике Предпосылка: атакующий уже имеет валидную пару логин/пароль (из утечки, credential stuffing, фишинга). Дальше:
Самый показательный публичный кейс - 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 между жертвой и легитимным сервисом. Принцип:
В 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 (концепция)Код:
Document.cookie = "session_id="Помимо Evilginx2, по данным Bugcrowd, существуют инструменты прокси-фишинга, где жертва фактически авторизуется в браузере на машине атакующего. Отдельно набирает обороты device code phishing в Azure - эксплуатация легитимного потока аутентификации устройств Microsoft, при котором жертва вводит код на настоящей странице Azure, но авторизует при этом приложение атакующего. Красивый вектор, и пока мало кто на него мониторит. Маппинг техник обхода MFA на MITRE ATT&CK Для структурирования результатов red team engagement в отчёте - таблица маппинга: Техника атакиMITRE ATT&CK IDТактикаОбходит MFA-типSS7-перехват SMST1111Credential AccessSMS OTPSIM-свопингT1451 (Mobile) + T1598Credential Access, ReconnaissanceSMS OTPMFA fatigue / push-бомбингT1621Credential AccessPush-уведомленияAiTM фишинг-проксиT1557 + T1539Credential Access, CollectionSMS, TOTP, PushКража session cookieT1539 + T1550.004Credential Access, Lateral MovementВсе типы MFAМодификация MFA на сервереT1556.006Credential Access, Persistence, Defense EvasionВсе типы MFAИспользование украденной сессииT1078Initial Access, Persistence, Privilege EscalationВсе типы MFA Обратите внимание: AiTM-прокси обходит все типы MFA кроме FIDO2/WebAuthn. Криптографические ключи FIDO2 привязаны к origin (домену). Фишинговый домен атакующего не совпадёт с легитимным, и аутентификатор откажется подписывать запрос. Единственный тип MFA, который архитектурно устойчив к AiTM. Детектирование обхода MFA: практический чеклист Как пентестер, вы должны не только уметь проводить атаки на MFA, но и указывать blue team конкретные точки детектирования. Вот что стоит мониторить. Сигналы компрометации в логах MFA fatigue (T1621):
Самый надёжный детект для AiTM-атаки - сопоставление IP-адреса аутентификации с IP последующей активности. В Azure AD / Entra ID через KQL: Код: Код:
SigninLogsПо данным Bugcrowd, AiTM-атаки через Evilginx выполняются с недоверенного устройства, что детектится как impossible travel при наличии хороших правил. Привязка Conditional Access Policies к compliant devices существенно сужает attack surface. Защита: что реально работает против bypass 2FA методов На основании анализа всех техник - ранжирование MFA-методов по устойчивости: MFA-методAiTM-проксиSIM-swapPush fatigueSS7-перехватSMS OTPОбходитсяОбходитсяНепри енимоОбходитсяTOTP (Google Auth)ОбходитсяУстойчивНепри енимоУстойчивPush-уведомленияОбходитсяУстой чивОбходитсяУстойчивFIDO2 / WebAuthnУстойчивУстойчивУстой чивУстойчив Почему FIDO2 устойчив к фишинг-прокси? Криптографический ключ привязан к конкретному домену (origin binding). Когда жертва оказывается на фишинговом домене, аутентификатор не подписывает challenge - origin не совпадает с зарегистрированным. Защита работает на криптографическом уровне, бдительность пользователя тут вообще не при чём. Помимо перехода на FIDO2, организации могут ощутимо снизить риски через:
Вопрос к читателям В Entra ID (Azure AD) через Conditional Access Policy можно настроить Authentication Strength, требующую phishing-resistant MFA (FIDO2/Windows Hello) для конкретных ролей. У кого в инфраструктуре уже разделены CA-политики для обычных пользователей и privileged accounts типа Global Admin? Какой Код:
authenticationStrengthКод:
deviceFilterКод:
device.isCompliant -eq True |
| Время: 22:04 |