«Многофакторная аутентификация не ломается — ей просто надоедают. Атака MFA bombing использует не уязвимость в коде, а когнитивную перегрузку человека, превращая защитный механизм в оружие против самого пользователя.»
Что такое MFA bombing
В классическом сценарии взлома злоумышленник борется с шифрованием или ищет уязвимость в софте. MFA bombing (также известная как MFA fatigue attack) работает иначе. Её цель — не обойти криптографию, а создать ситуацию, в которой легитимный пользователь сам подтвердит несанкционированный вход. Атака строится на простом принципе: если завалить человека десятками push-уведомлений с запросом на подтверждение входа, в момент усталости, спешки или непонимания он может нажать «Разрешить», чтобы просто остановить этот поток.
Это атака на поведенческий уровень, и она эффективна именно потому, что современные системы защиты часто проектируются без учёта человеческого фактора как самого ненадёжного звена.
Как проходит атака на практике
Сценарий разворачивается в несколько этапов:
- Подготовка. Злоумышленник получает логин и пароль жертвы (через фишинг, утечку базы данных или покупку на теневом форуме).
- Инициация входа. Используя эти данные, атакующий начинает попытки входа в защищённый сервис, где настроена push-аутентификация через мобильное приложение (например, Microsoft Authenticator, VK ID или корпоративное решение).
- Создание «шума». Каждая попытка входа генерирует push-уведомление на телефон пользователя. С помощью скрипта или специализированного инструмента (вроде Modlishka или самописных средств) атакующий может автоматизировать этот процесс, отправляя запросы каждые 10-30 секунд.
- Когнитивная атака. Пользователь получает лавину одинаковых уведомлений. Первые несколько он, скорее всего, отклонит. После пятого или десятого начнётся раздражение и мысли о сбое в системе.
- Успешный компромисс. В момент, когда внимание пользователя ослаблено (например, во время совещания, вождения или в конце рабочего дня), он может случайно или намеренно («чтобы это прекратилось») подтвердить один из запросов. Этого достаточно для доступа злоумышленника.
Почему корпоративная среда особенно уязвима
В российских компаниях, где внедрение MFA часто диктуется требованиями регуляторов (152-ФЗ, стандарты ФСТЭК), эта атака представляет особую опасность. Причины кроются в организационных и технических особенностях:
- Привычка к системным уведомлениям. Сотрудники постоянно получают уведомления от корпоративных чатов, тикет-систем, CI/CD-пайплайнов. Push от MFA растворяется в этом шуме и не воспринимается как критическая угроза.
- Ограниченный контекст в уведомлениях. Многие корпоративные MFA-решения, особенно кастомизированные под внутренние нужды, отправляют скупые сообщения: «Запрос на вход». В них нет информации об IP-адресе, местоположении или типе устройства, что лишает пользователя возможности оценить легитимность.
- Культура быстрого реагирования. В некоторых командах поощряется оперативное реагирование на системные алерты. Это может невольно перенестись и на MFA-запросы: «пришло — нужно быстро обработать».
- Единая точка входа (SSO). Если MFA защищает доступ к единому порталу (например, через Active Directory Federation Services), то, подтвердив один запрос, злоумышленник получает доступ не к одному сервису, а ко всем связанным приложениям — от почты и документооборота до систем управления инфраструктурой.
Слабое место типовой реализации MFA
Часто системы проектируются с упором на удобство, а не на устойчивость к социальной инженерии. Ключевые уязвимости:
| Уязвимость | Последствие |
|---|---|
| Отсутствие задержек (rate limiting) на запросы MFA | Атакующий может отправлять запросы бесконечно, создавая максимальный дискомфорт. |
| Push-уведомление с одной кнопкой «Подтвердить» | Для ошибочного действия нужен всего один тап. Нет дополнительного шага (ввод цифры, проверка по отпечатку). |
| Невозможность временно «заглушить» запросы | Пользователь не может через приложение или веб-интерфейс на час остановить уведомления, если заподозрил атаку. |
Методы защиты: от технических до организационных
Борьба с MFA bombing требует комплексного подхода, выходящего за рамки простого включения второго фактора.
Технические контрмеры
- Внедрение интеллектуального rate limiting. Система должна отслеживать аномальную активность. Например, после 5 отклонённых push-запросов за 2 минуты следующие попытки входа с этого IP или для этого аккаунта блокируются на 15-30 минут с отправкой алерта администратору безопасности.
- Контекст в уведомлениях. Каждое push-сообщение должно содержать детали: «Вход с IP 95.165.xx.xx (Москва, Beeline) в 14:30 через браузер Chrome». Это превращает уведомление из раздражающего сигнала в информационный инструмент.
- Переход от push к TOTP или WebAuthn.
- TOTP (коды в приложениях типа Google Authenticator) полностью исключают сценарий bombing, так как код генерируется локально, а не запрашивается удалённо.
- WebAuthn/Passkeys (аутентификация через физический ключ или биометрию на устройстве) не только устойчивы к bombing, но и обеспечивают защиту от фишинга.
- Геолокация и поведенческий анализ. Если система видит попытку входа из необычного города, в то время как пользователь только что заходил из офиса, можно потребовать дополнительное подтверждение (например, через резервный email), а не просто слать push.
Политики и обучение пользователей
Технические меры бесполезны без понимания угрозы людьми.
- Чёткие инструкции в политике безопасности. В документ должен быть включён пункт: «Получение серии запросов на подтверждение входа за короткий период является признаком атаки. Немедленно отклоняйте все запросы и сообщайте в службу информационной безопасности. Никогда не подтверждайте запрос, чтобы остановить уведомления.»
- Регулярные тренировки (отправка тестовых «атак»). Периодически безопасники могут имитировать MFA bombing на добровольцах или в рамках учений, чтобы сформировать у сотрудников мышечную память на правильную реакцию — не подтверждать, а сообщать.
- Пересмотр сценариев аварийного доступа. Что делать сотруднику, если он стал жертвой атаки и его аккаунт заблокирован? Должен быть альтернативный, безопасный канал для экстренного обращения в ИБ-службу.
Соответствие требованиям 152-ФЗ и ФСТЭК: формальность vs. реальность
Требования регуляторов часто фокусируются на факте наличия МФА для доступа к персональным данным. Однако они редко детально регламентируют реализацию этой меры. Система может формально соответствовать приказу ФСТЭК № 21, имея MFA, но при этом быть уязвимой к bombing из-за:
- Отсутствия ограничений на частоту запросов.
- Отправки уведомлений без минимального контекста (что нарушает принцип обеспечения осведомлённости пользователя).
- Не проведённого обучения пользователей по распознаванию нестандартных атак.
При аудите или аттестации ИБ-специалисту стоит поднимать вопрос не только «Есть ли MFA?», но и «Как она реализована и насколько устойчива к социальной инженерии?». Это может стать основанием для доработок, даже если формальные проверочные листы пройдены.
Почему об этой атаке говорят так мало
MFA bombing остаётся в тени по нескольким причинам:
- Не техническая, а человеческая уязвимость. Её сложно обнаружить автоматическими средствами SIEM/SOAR до момента успешного взлома. Логи будут показывать лишь множественные попытки входа, которые ничем не отличаются от действий забывчивого пользователя.
- Стигма вокруг «человеческого фактора». Гораздо проще доложить руководству о найденной уязвимости в криптобиблиотеке, чем о том, что корпоративная защита пала из-за того, что сотрудник в спешке нажал «OK».
- Отсутствие громких публичных инцидентов. Успешные атаки часто остаются нераскрытыми или списываются на «утерянные/скомпрометированные учётные данные» без детального разбора механизма.
Игнорирование этой угрозы создаёт ложное чувство безопасности. MFA — критически важный элемент защиты, но её внедрение должно быть вдумчивым. Без учёта поведенческих рисков многофакторная аутентификация превращается из надёжного щита в инструмент, который можно развернуть против своей же линии обороны.