Ваш пользователь вводит логин, пароль, подтверждает push в Authenticator - и считает себя в домике. А в это время атакующий на другом конце планеты уже импортировал его session cookie в свой браузер и спокойно читает почту в Exchange Online. Никакого брутфорса, никакого перебора OTP-кодов. MFA пройден - самой жертвой, через прокси, который стоит между ней и легитимным IdP.
AiTM фишинг (Adversary-in-the-Middle) - не теоретическая модель и не CVE из бюллетеня. Это рабочая индустрия с подпиской от 100 до 1000 долларов в месяц за готовый фишинг-кит. По данным Sekoia (январь–апрель 2025), в активной коммерческой эксплуатации крутилось 11 различных AiTM-китов, а только в октябре 2025 года Microsoft Defender for Office 365 заблокировал более 13 миллионов вредоносных писем, связанных с одной лишь кампанией Tycoon 2FA. Канадский центр кибербезопасности задокументировал свыше 100 AiTM-кампаний против Microsoft Entra ID с 2023 по начало 2025 года, и к августу 2024-го практически 100% наблюдаемых кампаний мигрировали от классического credential harvesting к proxy-based перехвату.
Ниже разберу, как именно работает AiTM атака на уровне HTTP-сессии, покажу внутреннюю механику трёх прокси-фреймворков - Evilginx, Modlishka и Muraena - и объясню, почему TOTP, push и SMS тут бессильны. Для тех, кто на синей стороне - конкретные индикаторы детекта.
Как работает AiTM атака на уровне HTTP-сессии
Прежде чем лезть в инструменты, нужно понять, что происходит на уровне протокола. AiTM - не клон страницы и не скриншот логин-формы. Это полноценный reverse proxy, который терминирует TLS-соединение с обеих сторон.По MITRE ATT&CK это комбинация трёх тактик: Adversary-in-the-Middle (T1557, credential-access/collection), Steal Web Session Cookie (T1539, credential-access) и Modify Authentication Process: Multi-Factor Authentication (T1556.006, credential-access/defense-evasion/persistence). Доставка - через Spearphishing Link (T1566.002, initial-access).
Вот что происходит при типичной атаке на Microsoft 365:
- Жертва получает письмо со ссылкой. Часто это не прямой URL, а файл на легитимной платформе - SharePoint, Dropbox - с вторичной ссылкой на прокси атакующего. Email-gateway пропускает, потому что первичный домен доверенный.
- Браузер жертвы поднимает TLS-соединение с прокси атакующего. Прокси устанавливает собственное TLS-соединение с login.microsoftonline.com. Два отдельных зашифрованных канала - HTTPS не спасает, потому что прокси является конечной точкой обоих.
- Каждый HTTP-запрос от жертвы проксируется на легитимный IdP. Жертва видит настоящую страницу входа Microsoft - не копию, а реальный контент, пропущенный через прокси. Вводит email, пароль, проходит MFA-challenge (push, TOTP, SMS - без разницы). Все данные транзитом идут через сервер атакующего.
- После успешной аутентификации IdP выдаёт session cookie. Cookie летит обратно через прокси. Атакующий перехватывает его до того, как он доберётся до браузера жертвы. Жертва попадает в свой почтовый ящик, ничего не подозревая.
- Атакующий импортирует cookie в свой браузер - через
document.cookieили Cookie-Editor - и получает полностью аутентифицированную сессию. MFA уже пройден. Conditional Access видит валидный токен.
Evilginx фишинг - анатомия ведущего прокси-фреймворка
Evilginx (актуальная версия - Evilginx3) - standalone-приложение на Go, работающее как HTTP/HTTPS reverse proxy с собственным DNS-сервером. Первая версия была nginx-модулем, текущая реализация полностью самодостаточна: встроенный web-сервер, автоматические TLS-сертификаты через Let's Encrypt и модульная конфигурация через phishlets.Структура phishlet и логика перехвата
Phishlet - YAML-файл, который описывает: какой сервис атакуем, какие поддомены проксировать, какие HTTP-параметры содержат credentials и (самое вкусное) какие cookies являются session tokens.Секция
proxy_hosts определяет маппинг: для каждого легитимного поддомена Microsoft (login.microsoftonline.com, login.live.com, www.office.com) создаётся фишинговый поддомен. Секция auth_tokens - ради неё всё и затевается: здесь указываются имена cookie для перехвата. Для M365 это обычно ESTSAUTH и ESTSAUTHPERSISTENT на домене login.microsoftonline.com. Секция credentials определяет, из каких POST-параметров вытаскивать логин и пароль - поля login и passwd в форме авторизации.Когда жертва заходит на фишинговый URL, Evilginx подставляет свои поддомены вместо оригинальных, на лету переписывая все ссылки в HTML/JS-ответах. Жертва взаимодействует с настоящим Microsoft, но через прокси. После прохождения MFA - session cookie перехватывается и падает в базу Evilginx.
Практическая настройка кампании
Для развёртывания нужно: VPS с белым IP, домен с NS-записями на этот IP и бинарник Evilginx. После запуска конфигурация идёт из встроенной консоли.Базовый flow: командой
config domain задаём фишинговый домен, config ipv4 - внешний IP сервера. Затем phishlets hostname <phishlet_name> <domain> привязывает phishlet к домену, phishlets enable <phishlet_name> активирует его и автоматически запрашивает TLS-сертификат. Для генерации фишинговой ссылки - lures create <phishlet_name>, после чего lures get-url <lure_id> выдаёт URL для отправки жертве.Типичная ошибка при настройке - кривая DNS-конфигурация: если NS-записи домена не указывают на IP сервера Evilginx, Let's Encrypt не пройдёт challenge, и phishlet останется без сертификата. Вторая проблема - попытка проксировать сервисы с WebSocket (некоторые части Teams, например): Evilginx3 обрабатывает WebSocket лучше второй версии, но стабильность - не 100%.
Ещё один момент, на котором я терял время: многие целевые сервисы проверяют заголовки
Origin и Referer. Evilginx обрабатывает это через перезапись в phishlet, но при кривом sub_filters аутентификация ломается - жертва видит ошибку, сессия не устанавливается. Приходится руками допиливать фильтрацию под конкретную версию login-страницы Microsoft, которая, к слову, меняется регулярно.Modlishka и Muraena - альтернативные фишинг-прокси
Evilginx - не единственный инструмент в этом зоопарке. Для полноценного понимания картины нужно знать альтернативы: у каждой свои сильные стороны и специфические болячки.Modlishka фреймворк: автоматический реверс-прокси
Modlishka написана на Go и отличается от Evilginx принципиально другим подходом: не нужно писать phishlet под каждый сервис. Вместо этого Modlishka работает как «универсальный» reverse proxy - указываете целевой домен, фреймворк автоматически проксирует весь контент, переписывая URL на лету.Плюс очевиден: скорость развёртывания. Запуск сводится к
-target с целевым доменом и -phishingDomain с фишинговым, плюс настройка TLS-сертификата.Минус тоже очевиден: «универсальность» становится проблемой. Modlishka хуже справляется с сервисами, которые активно используют Content Security Policy (CSP), HSTS preload lists и строгую проверку origin. Если целевой сервис отдаёт CSP с жёстким
script-src, контент рендерится криво. При работе с Microsoft 365 я сталкивался с ситуацией, когда JS-бандлы Microsoft ломались из-за некорректной подмены доменных ссылок внутри минифицированного JS - вместо страницы входа белый экран. Неприятно.Modlishka умеет собирать credentials через анализ POST-запросов и перехватывать cookie, но конфигурация менее гранулярна, чем у Evilginx - нельзя точечно указать, какие именно cookie являются session tokens.
Muraena фишинг прокси: модульный подход
Muraena (разработка итальянской ИБ-лаборатории) - ещё один Go-фреймворк, но с акцентом на модульность. Разделён на два компонента: сам proxy-сервер (Muraena) и кроулер Necrobrowser, который автоматизирует действия с перехваченными сессиями.Necrobrowser - главное отличие: после перехвата cookie он запускает headless-браузер, автоматически импортирует сессию и выполняет постэксплуатационные действия - сбор писем, создание inbox rules, скачивание файлов с OneDrive. По сути это автоматизация постэксплуатации, которую в Evilginx нужно делать руками или скриптовать отдельно. Удобная штука, если нужно продемонстрировать заказчику полный импакт.
Muraena использует JSON-конфигурацию с описанием целевого домена, замен в контенте и правил перехвата. Подход ближе к Modlishka по универсальности, но с более тонкой настройкой через
replace-паттерны. На практике Muraena хорошо работает с простыми SSO-порталами, но на сложных SPA с динамической загрузкой - те же проблемы с CSP и CORS, что и у Modlishka.Сравнение прокси-фреймворков для обхода многофакторной аутентификации
| Параметр | Evilginx3 | Modlishka | Muraena |
|---|---|---|---|
| Язык | Go | Go | Go |
| Конфигурация целей | Phishlet (YAML) под каждый сервис | Автоматически по домену | JSON с replace-паттернами |
| TLS | Встроенный (Let's Encrypt) | Внешний или встроенный | Внешний |
| Точечный перехват cookie | Да, через auth_tokens | Общий перехват | Настраиваемый |
| Работа с CSP/HSTS | Через sub_filters | Ограничена | Ограничена |
| WebSocket | Частичная поддержка | Нет | Нет |
| Пост-эксплуатация | Ручная | Ручная | Necrobrowser (headless) |
| Anti-bot / fingerprinting | Через JS-inject в lure | Нет нативно | Нет нативно |
| Сообщество и поддержка | Активное, регулярные обновления | Ограниченное | Минимальное |
| Порог входа | Средний (нужно понимать phishlets) | Низкий | Средний |
На практике выбор зависит от цели. Кампания против Microsoft 365 или Okta с кастомной аутентификацией - Evilginx даёт максимальный контроль. Быстрая проверка концепции на стандартном веб-приложении - Modlishka. Нужна автоматизация постэксплуатации - Muraena с Necrobrowser.
В большинстве проектов я беру Evilginx. Да, порог входа выше, да, phishlet иногда приходится патчить после очередного обновления Microsoft - но предсказуемость результата того стоит.
Перехват сессионных токенов: что происходит после MFA
Кража session cookie - только начало. Понимание того, что атакующий делает дальше, критично и для Red Team (довести операцию до импакта), и для Blue Team (детектировать на ранних стадиях).По данным Канадского центра кибербезопасности, 91% постэксплуатационной активности после AiTM-компрометации - это Business Email Compromise (BEC). Типичная цепочка:
Аномальная регистрация MFA-устройства. В течение 30 минут после аутентификации на аккаунте регистрируется новое MFA-устройство - с IP, отличного от того, с которого прошла аутентификация. Высоко релевантный индикатор AiTM. В Sentinel для этого используется запрос к таблице
AuditLogs с фильтрацией по OperationName == "User registered security info" и корреляцией с SigninLogs по временному окну.Создание inbox rules. Любое правило, которое перемещает письма в RSS Feeds, скрытые папки или удаляет их по ключевым словам - красный флаг. В Exchange Online это отображается в Unified Audit Log как операция
New-InboxRule.Token reuse с нетипичного User-Agent или IP. Одна сессия используется параллельно с двух разных IP или с разными browser fingerprints. Требует аналитики на стороне SIEM, но даёт высокую точность.
Индикаторы фишинговой инфраструктуры
Домены AiTM-кампаний обычно живут 24–72 часа. По данным Sekoia, Tycoon 2FA регистрирует десятки новых доменов ежедневно и еженедельно обновляет anti-bot страницы. Характерные признаки: свежая регистрация домена, Let's Encrypt сертификат, wildcard DNS, структура поддоменов, повторяющая целевой сервис (login.target-phishing-domain.com). Если видите такое в логах - копайте дальше.Защита от обхода многофакторной аутентификации через AiTM
Конкретные меры - от наиболее эффективных к дополнительным.FIDO2 / passkeys - единственная аутентификация, устойчивая к AiTM. Аппаратный ключ (YubiKey, Titan) или platform passkey криптографически привязан к origin - конкретному домену. Когда жертва на фишинговом домене, ключ просто не сработает: origin не совпадает, подпись не формируется. Тут нечего проксировать. По данным Канадского центра кибербезопасности, в тенантах с phishing-resistant MFA и Conditional Access на зарегистрированные устройства процент успешных компрометаций через AiTM снизился с ~20% в Q3 2023 до 6–7% в Q2 2025.
Conditional Access: требование managed device. Даже если cookie украден, попытка использовать его с unmanaged device атакующего провалит проверку Conditional Access. Второй по эффективности контроль после FIDO2. Настраивается в Entra ID через политику, требующую
compliant device или Hybrid Azure AD joined device.Continuous Access Evaluation (CAE) и короткие TTL. CAE позволяет Microsoft 365 в реальном времени переспорить сессию - например, при смене IP. На практике покрытие CAE неравномерно: Exchange Online поддерживает хорошо, некоторые SaaS-приложения - нет. Минимизация TTL session token сужает окно возможностей для атакующего, но не закрывает его полностью.
Блокировка legacy authentication и device code flow. Оба метода обходят modern Conditional Access и часто используются после AiTM-компрометации для persistence. Microsoft явно рекомендует отключать device code flow там, где он не нужен. Если у вас он включён «на всякий случай» - выключайте. Случай уже наступил.
Мониторинг. Подключение Entra ID audit logs к SIEM с алертами на: новую регистрацию MFA-устройства, создание inbox rules, OAuth consent grants от неверифицированных издателей, impossible travel.
Вопрос к читателям
Если вы разворачивали Evilginx3 в рамках Red Team-операции против Microsoft 365 - какиеsub_filters в phishlet пришлось допиливать вручную, чтобы обойти текущие CSP-заголовки Microsoft? У меня login.microsoftonline.com стабильно ломает JS-бандлы при стандартном phishlet из репозитория, и приходится патчить фильтрацию Content-Security-Policy в ответах. Поделитесь фрагментом вашей секции sub_filters - или альтернативным подходом, если решили это иначе.
Последнее редактирование модератором:
