Как работает MFA prompt bombing#
Атакующий получает действующий пароль через утечки, фишинг, credential stuffing или инфостилеры. Далее он инициирует серию попыток входа в систему с push-based MFA (VPN, Microsoft 365, Okta, Duo и т.д.). Пользователь начинает получать поток запросов подтверждения на телефон. Повторение убирает контекст: отдельное уведомление перестаёт восприниматься как событие и становится шумом. На этом фоне возрастает вероятность случайного подтверждения.
Часто атака автоматизируется: скрипты или ботнеты генерируют повторные login-attempt запросы с разными IP и устройствами, чтобы обойти простые rate-limit механизмы. Иногда добавляется телефонный звонок от якобы IT-поддержки, который усиливает давление и закрепляет сценарий “это нормальная процедура”.
Почему push MFA уязвим#
Слабость не в криптографии второго фактора. Слабость в модели принятия решения. Пользователь не видит достаточного контекста: география входа, устройство, риск-сигналы, инициатор действия. Решение сводится к нажатию “Approve” или “Deny” без понимания ситуации.
Возникает MFA fatigue — привыкание к повторяющимся запросам. Чем чаще появляется push-уведомление, тем ниже когнитивный порог реакции. Это превращает второй фактор в элемент социальной инженерии, где атакующий управляет не системой, а вниманием человека.
Как атакуют на практике#
Типовой сценарий состоит из нескольких этапов:
- Сбор пароля через инфостилеры или утечки баз
- Проверка валидности на VPN, SSO или почтовых сервисах
- Запуск серии push MFA запросов
- Маскировка активности через разные IP и user-agent
- Усиление давления через voice phishing или имитацию helpdesk
- Получение случайного или ошибочного подтверждения
- Закрепление доступа через добавление нового MFA устройства
После этого атакующий часто расширяет доступ: подключается к VPN, внутренним системам, облачным панелям и каталогам.
Сигналы атаки#
Ранние признаки можно отследить в логах и поведении:
- серия MFA push запросов за короткое время
- повторяющиеся неуспешные login попытки с разных IP
- резкая смена географии входов
- попытки входа вне рабочего времени
- всплеск уведомлений без соответствующих действий пользователя
Эти сигналы часто игнорируются, потому что каждый отдельный event выглядит легитимно.
Кейc Cisco 2022#
В расследовании инцидента злоумышленник получил доступ к личному Google аккаунту сотрудника Cisco, где были сохранены браузерные пароли, включая доступ к корпоративному VPN. После этого началась серия массовых MFA push-запросов.
Когда стандартные попытки не дали результата, была применена схема voice phishing с имитацией службы поддержки. Пользователя убедили, что запросы связаны с восстановлением доступа. В результате доступ к VPN был подтверждён.
Далее атакующий зарегистрировал дополнительные MFA устройства, повысил привилегии и получил доступ к Citrix и domain controllers. Было выведено около 2.8 GB данных.
Что проверить#
Проверьте, где используется только push-based MFA без дополнительных механизмов защиты.
Замените одиночное подтверждение на number matching, FIDO2 или WebAuthn.
Включите conditional access:
- привязка к устройству
- проверка геолокации и аномалий
- блокировка новых устройств по умолчанию
Ограничьте частоту MFA push запросов и добавьте экспоненциальные задержки при повторных попытках.
Ведите мониторинг:
- повторяющиеся push события
- успешные подтверждения после серии отказов
- аномальные входы перед MFA сессией
Проведите аудит паролей на совпадения с утечками и отключите reuse на уровне политики.
Вывод#
Push MFA остаётся рабочим механизмом, но его устойчивость падает при наличии валидного пароля и человеческого фактора. Основной риск возникает на стыке автоматизированного давления и отсутствия контекстной проверки входа.