https://forum.antichat.xyz/attachmen...68ea72bd9c.png

Ваш пользователь вводит логин, пароль, подтверждает 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:

1. Жертва получает письмо со ссылкой. Часто это не прямой URL, а файл на легитимной платформе - SharePoint, Dropbox - с вторичной ссылкой на прокси атакующего. Email-gateway пропускает, потому что первичный домен доверенный.
   
2. Браузер жертвы поднимает TLS-соединение с прокси атакующего. Прокси устанавливает собственное TLS-соединение с login.microsoftonline.com. Два отдельных зашифрованных канала - HTTPS не спасает, потому что прокси является конечной точкой обоих.
   
3. Каждый HTTP-запрос от жертвы проксируется на легитимный IdP. Жертва видит настоящую страницу входа Microsoft - не копию, а реальный контент, пропущенный через прокси. Вводит email, пароль, проходит MFA-challenge (push, TOTP, SMS - без разницы). Все данные транзитом идут через сервер атакующего.
   
4. После успешной аутентификации IdP выдаёт session cookie. Cookie летит обратно через прокси. Атакующий перехватывает его до того, как он доберётся до браузера жертвы. Жертва попадает в свой почтовый ящик, ничего не подозревая.
   
5. Атакующий импортирует cookie в свой браузер - через
   
   Код:

   ---

   document.cookie

   ---

   или Cookie-Editor - и получает полностью аутентифицированную сессию. MFA уже пройден. Conditional Access видит валидный токен.

Принципиальное отличие от классического Man-in-the-Middle: MitM работает на сетевом уровне (ARP-spoofing, rogue AP), нейтрализуется TLS и MFA. AiTM работает на уровне приложения, специально заточен под обход MFA, и TLS его не останавливает. По данным Obsidian Security (исследование WorkOS), 84% аккаунтов, взломанных через AiTM, имели включённый MFA — однако в реальности эта защита была обойдена.
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.

Секция
определяет маппинг: для каждого легитимного поддомена Microsoft (login.microsoftonline.com, login.live.com, www.office.com) создаётся фишинговый поддомен. Секция
- ради неё всё и затевается: здесь указываются имена cookie для перехвата. Для M365 это обычно
и
на домене login.microsoftonline.com. Секция
определяет, из каких POST-параметров вытаскивать логин и пароль - поля
и
в форме авторизации.

Когда жертва заходит на фишинговый URL, Evilginx подставляет свои поддомены вместо оригинальных, на лету переписывая все ссылки в HTML/JS-ответах. Жертва взаимодействует с настоящим Microsoft, но через прокси. После прохождения MFA - session cookie перехватывается и падает в базу Evilginx.
Практическая настройка кампании
Для развёртывания нужно: VPS с белым IP, домен с NS-записями на этот IP и бинарник Evilginx. После запуска конфигурация идёт из встроенной консоли.

Базовый flow: командой
задаём фишинговый домен,
- внешний IP сервера. Затем
привязывает phishlet к домену,
активирует его и автоматически запрашивает TLS-сертификат. Для генерации фишинговой ссылки -
, после чего
выдаёт URL для отправки жертве.

Типичная ошибка при настройке - кривая DNS-конфигурация: если NS-записи домена не указывают на IP сервера Evilginx, Let's Encrypt не пройдёт challenge, и phishlet останется без сертификата. Вторая проблема - попытка проксировать сервисы с WebSocket (некоторые части Teams, например): Evilginx3 обрабатывает WebSocket лучше второй версии, но стабильность - не 100%.

Ещё один момент, на котором я терял время: многие целевые сервисы проверяют заголовки
и
. Evilginx обрабатывает это через перезапись в phishlet, но при кривом
аутентификация ломается - жертва видит ошибку, сессия не устанавливается. Приходится руками допиливать фильтрацию под конкретную версию login-страницы Microsoft, которая, к слову, меняется регулярно.
Modlishka и Muraena - альтернативные фишинг-прокси
Evilginx - не единственный инструмент в этом зоопарке. Для полноценного понимания картины нужно знать альтернативы: у каждой свои сильные стороны и специфические болячки.
Modlishka фреймворк: автоматический реверс-прокси
Modlishka написана на Go и отличается от Evilginx принципиально другим подходом: не нужно писать phishlet под каждый сервис. Вместо этого Modlishka работает как «универсальный» reverse proxy - указываете целевой домен, фреймворк автоматически проксирует весь контент, переписывая URL на лету.

Плюс очевиден: скорость развёртывания. Запуск сводится к
с целевым доменом и
с фишинговым, плюс настройка TLS-сертификата.

Минус тоже очевиден: «универсальность» становится проблемой. Modlishka хуже справляется с сервисами, которые активно используют Content Security Policy (CSP), HSTS preload lists и строгую проверку origin. Если целевой сервис отдаёт CSP с жёстким
, контент рендерится криво. При работе с 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 по универсальности, но с более тонкой настройкой через
-паттерны. На практике Muraena хорошо работает с простыми SSO-порталами, но на сложных SPA с динамической загрузкой - те же проблемы с CSP и CORS, что и у Modlishka.
Сравнение прокси-фреймворков для обхода многофакторной аутентификации

ПараметрEvilginx3ModlishkaMuraenaЯзыкG oGoGoКонфигурация целейPhishlet (YAML) под каждый сервисАвтоматически по доменуJSON с replace-паттернамиTLSВстроенный (Let's Encrypt)Внешний или встроенныйВнешнийТочечный перехват cookieДа, через auth_tokensОбщий перехватНастраиваемыйРабо та с CSP/HSTSЧерез sub_filtersОграниченаОграничен� �WebSocketЧастичная поддержкаНетНетПост-эксплуатацияРучнаяРучнаяNe crobrowser (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). Типичная цепочка:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше


Получить доступ просто — достаточно проявить активность на форуме

Аномальная регистрация MFA-устройства. В течение 30 минут после аутентификации на аккаунте регистрируется новое MFA-устройство - с IP, отличного от того, с которого прошла аутентификация. Высоко релевантный индикатор AiTM. В Sentinel для этого используется запрос к таблице
с фильтрацией по
и корреляцией с
по временному окну.

Создание inbox rules. Любое правило, которое перемещает письма в RSS Feeds, скрытые папки или удаляет их по ключевым словам - красный флаг. В Exchange Online это отображается в Unified Audit Log как операция
.

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 через политику, требующую
или
.

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 - какие
в phishlet пришлось допиливать вручную, чтобы обойти текущие CSP-заголовки Microsoft? У меня login.microsoftonline.com стабильно ломает JS-бандлы при стандартном phishlet из репозитория, и приходится патчить фильтрацию
в ответах. Поделитесь фрагментом вашей секции
- или альтернативным подходом, если решили это иначе.