46
Слушай, бро, тема горячая – MFA считают серебряной пулей, а на деле её обходят пачками через кражу токенов и злоупотребление OAuth. По данным Microsoft за 2025 год, 80% инцидентов с обходом MFA связаны именно с кражей и повторным использованием сессионных токенов, а не с паролями. Разбираемся, как это работает технически и что с этим делать.
Почему MFA не панацея
MFA защищает момент входа – проверку логина и пароля плюс второй фактор. Но после успешной аутентификации сервер выдаёт сессионный токен (cookie или bearer-токен), и именно этот артефакт браузер прикладывает к каждому последующему запросу. Если атакующий украдёт этот токен, он получает доступ к аккаунту без повторного прохождения MFA – второй фактор просто не срабатывает, потому что вход уже “случился”.
Credential-атаки бьют по входным данным (логин/пароль) – их MFA останавливает. Session hijacking бьёт по выходу процесса — по токену, который уже прошёл проверку.
Техника 1: AiTM-фишинг (Evilginx2, Modlishka, Muraena)
Классика жанра – adversary-in-the-middle proxy встаёт между жертвой и легитимным сайтом. Жертва вводит логин, пароль, проходит MFA – а прокси в реальном времени перехватывает сессионный cookie после успешной аутентификации. Атакующий забирает этот cookie и открывает сессию с любой другой машины, не оставляя следов взлома пароля.
Схема атаки:
Инфостилеры (RedLine, Lumma и подобные) работают похожим образом – читают cookie прямо из хранилища браузера жертвы и сразу продают в стилер-логах.
Техника 2: OAuth token hijacking и consent phishing
OAuth-токены (access и refresh) после выдачи работают независимо от пароля и MFA, пока их явно не отозвали. Свежий пример 2026 года – атака ConsentFix против Microsoft Entra ID: злоумышленник злоупотребляет легитимным OAuth authorization code flow, заставляя жертву выдать код авторизации, который потом обменивается на токены без единого MFA-запроса.
Более простой вектор для пентеста – злоупотребление device code flow (RFC 8628), придуманным для устройств с ограниченным вводом (Smart TV, CLI-утилиты):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# Пример атаки на OAuth Device Code Flow 1. Атакующий сам инициирует device flow у легитимного провайдера: POST /oauth2/v2.0/devicecode → получает user_code и verification_uri 2. Через вишинг/фишинг убеждает жертву перейти по verification_uri и ввести полученный user_code — "подтвердите вход в корпоративный портал" 3. Жертва аутентифицируется, проходит MFA полностью легитимно 4. Атакующий на своей стороне поллит: POST /oauth2/v2.0/token grant_type=device_code&device_code=... → получает access_token и refresh_token с запрошенными scope |
Жертва честно прошла MFA – но токены получил атакующий. Refresh-токен может жить месяцами, обеспечивая персистентный доступ к почте, файлам и API без повторной проверки личности.
Техника 3: Перехват authorization code через MITM
Для пентеста SSO-флоу связка mitmproxy + подмена redirect_uri – рабочий кейс:
|
1 2 3 4 5 6 7 8 9 10 11 |
# Перехват и повторное использование authorization code mitmproxy -p 8080 # В конфиге OAuth-клиента проверяем: # - валидируется ли redirect_uri строго (или принимает wildcard/поддомены) # - одноразовый ли authorization code # - привязан ли токен к IP/устройству (token binding) # Если authorization code не инвалидируется сразу после обмена: curl -X POST https://target.com/oauth/token \ -d "grant_type=authorization_code&code=STOLEN_CODE&client_id=..." |
Если redirect_uri принимает любые поддомены, а код авторизации не одноразовый – можно перехватить код на этапе редиректа и обменять его на токен раньше легитимного клиента.
Сравнение векторов
| Вектор | Что крадут | Момент кражи | Обходит MFA? |
|---|---|---|---|
| AiTM-прокси (Evilginx2) | Сессионный cookie | После прохождения MFA жертвой | Да, полностью |
| Инфостилер-малварь | Cookie из браузера | Постфактум, локально на хосте | Да |
| OAuth device code abuse | Access/refresh token | Жертва сама авторизует | Да |
| Consent phishing (ConsentFix) | OAuth access token | Через authorization code | Да, MFA не триггерится |
| Push-усталость (MFA bombing) | Само подтверждение | На этапе входа | Частично, через соц. инженерию |
Защита: что реально работает
Короткие сессии – это база: чем меньше живёт токен, тем меньше окно для атакующего. Для Microsoft-инфраструктуры включай Token Protection в Conditional Access под “Session controls” – это привязывает токен к конкретному устройству и делает бессмысленной его кражу с другой машины.
Главный вывод для защитников: MFA – это проверка личности в момент входа, а не защита самого токена после. Пока индустрия массово не перейдёт на sender-constrained токены (DPoP/mTLS) и короткие TTL, session hijacking и OAuth-абьюз будут топовым способом обхода MFA в 2026 году.