Атака усталости от MFA-запросов, или MFA-бомбинг, — это попытка заставить пользователя одобрить настоящий запрос многофакторной аутентификации, который он не начинал. Злоумышленник многократно вызывает push-уведомления, дополняет их звонком или сообщением либо ждет, пока жертва нажмет «разрешить» по ошибке, от раздражения или из-за сходства с обычным входом.

Важное предварительное условие: атакующий уже способен дойти до этапа запроса MFA. Он может знать или сбросить пароль, владеть действующим первым фактором либо управлять живым процессом входа. Поэтому серия запросов — не просто уведомительный спам, а возможное свидетельство попытки завершить вход. CISA рекомендует сопоставление чисел как меру против бомбардировки push-запросами, поскольку она добавляет контекст вместо одной кнопки одобрения.［1］

Ключевые выводы

Одобряйте запрос MFA только для входа, который вы начали сами и сведения о котором соответствуют вашим действиям.

Отклонить один запрос полезно, но повторные запросы означают, что аккаунт нужно защитить, а о событии — сообщить.

Сопоставление чисел уменьшает случайное одобрение, но не делает любой запрос или звонок честным.

После ошибочного одобрения считайте вход возможным: отзовите сеансы, сбросьте скомпрометированные факторы и изучите действия.

Как работает атака усталости от MFA-запросов?

Сначала злоумышленник получает сведения для первого шага. Повторно используемый пароль из другой утечки можно применить при подстановке учетных данных. Фишинговая страница способна перехватить пароль в реальном времени. Манипуляция поддержкой или процедурой восстановления тоже может приблизить атакующего к MFA.

Далее он многократно отправляет попытки входа, и push-система доставляет настоящий запрос на зарегистрированное устройство. После отказа запросы повторяются ночью, во время совещания или подряд. Иногда атакующий звонит от имени ИТ-службы, называет уведомления обновлением безопасности и просит одобрить одно из них, чтобы «закончить синхронизацию» или прекратить шум.

Если жертва одобрит запрос, провайдер может завершить вход атакующего. Дальнейшее зависит от аккаунта и мер защиты: атакующий способен создать сеанс, зарегистрировать новый фактор, читать почту и файлы, менять восстановление, выдавать разрешения приложениям или атаковать связанные сервисы. Термин «усталость от MFA» относится именно к давлению через запросы; не каждый обход MFA, украденный токен сеанса, подмена SIM-карты или выманенный одноразовый код является такой атакой.

Чем отличаются push, TOTP, сопоставление чисел и ключ доступа?

Методы аутентификации ставят перед пользователем разные решения. Обычный push-запрос лишь спрашивает, разрешить ли вход. Одноразовый пароль на основе времени (TOTP) требует ввести короткий меняющийся код в ту форму входа, которую пользователь видит перед собой. При сопоставлении чисел процесс входа показывает число, и его нужно ввести или выбрать в приложении-аутентификаторе, а ключ доступа (passkey) подтверждает вход криптографически, привязан к запрашивающему сайту и требует локальной проверки пользователя или его присутствия. Эти методы по-разному сопротивляются давлению и фишингу.

Метод	Действие пользователя	Защита от усталости	Ограничение
Push с выбором «разрешить/отклонить»	Нажать разрешить или отклонить	Удобно, но контекста мало	Повторение и социальная инженерия используют привычку
TOTP	Ввести меняющийся код в текущий вход	Нет неожиданной кнопки для случайного согласия	Фишинговый прокси-сайт может запросить и передать код
Сопоставление чисел	Сопоставить число на странице и в приложении-аутентификаторе	Связывает уведомление с видимым входом	Звонящий может манипулировать человеком, который открыл чужой процесс
Ключ доступа/FIDO2	Использовать привязанный к сайту ключ с локальным подтверждением	Противостоит повторному использованию секрета и многим фишинговым прокси-сайтам	Регистрация, восстановление, устройства и запасные способы требуют управления

При сопоставлении чисел Microsoft показывает число в процессе входа, а пользователь вводит его в Authenticator для завершения.［2］ Дополнительное сравнение уменьшает слепое согласие, но не отменяет вопрос «я начал этот вход?». Мошенник по телефону может провести жертву через процесс, который открыл сам, поэтому совпавшее число подтверждает связь с попыткой, а не честность звонящего.

Ключи доступа и FIDO2 создают криптографическую связь с настоящим сайтом. Это не многоразовый пароль и не код, который можно просто скопировать на фишинговый прокси-сайт. Microsoft относит ключи доступа и FIDO2 к устойчивым к фишингу методам MFA, одновременно отмечая сложности развертывания и совместимости.［3］ Такая устойчивость не означает полную неуязвимость: каналы восстановления, устаревшие методы, вредоносное ПО и уже разрешенные сеансы остаются важными.

Что делать, если пришел неожиданный запрос MFA?

Не одобряйте и не вводите число, продиктованное другим человеком. Если приложение позволяет отклонить и сообщить о мошенничестве, используйте эту функцию. Закройте страницу входа, которую не открывали, и вручную перейдите в официальный раздел безопасности.

Один запрос иногда связан с задержанным собственным сеансом, вторым устройством или повтором сервиса. Сопоставьте время, приложение, устройство, географию и число с тем, что делаете сейчас. Если точного соответствия нет, запрос подозрителен. Серия уведомлений, запрос в необычное время или одновременный звонок «поддержки» повышают срочность реакции.

Ситуация	Возможный уровень риска	Немедленное действие
Один запрос во время вашего входа	Может быть нормальным	Сверить сервис, число, устройство и местоположение
Один запрос без вашего входа	Кто-то дошел до MFA	Отклонить, сообщить, проверить активность и пароль
Много запросов или сопровождающий звонок	Активная атака давлением	Прекратить разговор и независимо обратиться в поддержку или службу безопасности
Запрос одобрен по ошибке	Возможен успешный вход	Немедленно начать восстановление и расследование

Для личного аккаунта смените с доверенного устройства пароль, если он повторялся или мог быть раскрыт, и проверьте недавние входы и способы восстановления. Для рабочего аккаунта свяжитесь со службой безопасности или поддержкой по известному внутреннему каналу. Передайте время запросов, приложение, показанную географию и сведения о звонке; не используйте номер из подозрительного сообщения.

Что делать после ошибочного одобрения?

Пока не доказано обратное, считайте, что одобрение завершило чужую аутентификацию. На официальной странице отзовите незнакомые сеансы или выйдите с других устройств. Смените потенциально известный пароль. Проверьте методы MFA, ключи доступа и аппаратные ключи, телефоны, резервную почту, доверенные устройства и подключения; удалите все, что не можете подтвердить.

Затем изучите ресурсы аккаунта: правила и пересылку почты, отправленные письма, общий доступ к облачным файлам, делегированные доступы, платежные настройки, токены разработчика и недавние изменения. Атакующий может пользоваться уже созданным сеансом, не вызывая нового запроса MFA. Порядок восстановления в материале Кто-то вошел в мой аккаунт помогает упорядочить эти проверки.

Уровень	Приоритет	Что сохранить
Все запросы отклонены	Защитить первый фактор и сообщить	Время, приложение, географию, звонки и сообщения
Одобрено, действий пока не видно	Отозвать сеансы и сбросить факторы	Записи входов и аудита до истечения хранения
Найдены изменения	Восстановить MFA и способы восстановления, ограничить сервисы	Параметры до и после изменений, новые факторы, правила, разрешения, данные устройства и IP-адреса
Затронуты рабочие, финансовые или регулируемые данные	Передать ответственной команде и выполнять процедуру реагирования	Журналы провайдера, транзакции, объем доступа к данным и переписка

Не верьте, что следующий push «отменит» первое согласие. Не удаляйте доказательства до работы службы безопасности. Для финансового аккаунта позвоните в организацию по надежному номеру. Если злоумышленник убедил поддержку заменить фактор, явно сообщите об этом, чтобы расследовали путь восстановления, а не только пароль.

Как организациям уменьшить риск, который создает атака push-усталости?

Замените лишенные контекста запросы с кнопками «разрешить/отклонить» на сопоставление чисел и применяйте устойчивые к фишингу методы там, где это возможно. Отключите слабые неиспользуемые запасные способы. Аккуратно применяйте ограничение частоты, контроль на основе риска, сигналы о невозможных перемещениях и незнакомых устройствах, а также оповещения о серии отказов или большом числе запросов. Система, бесконечно повторяющая уведомления, сама усиливает давление.

Дайте пользователю понятную кнопку сообщения о мошенничестве и отдельный надежный путь к поддержке. Сотрудник поддержки не должен просить одобрить необъяснимый запрос или назвать одноразовый код. Защитите регистрацию и сброс факторов: когда основной вход укрепляется, атакующий часто переключается на восстановление.

Связывайте события всей цепочки: проверку пароля, запросы MFA, отказы и одобрения, добавление фактора, создание сеанса, разрешения OAuth и чувствительные действия. Корреляция событий важнее простого подсчёта запросов: серия отказов, за которой следуют одно согласие и новое устройство, значит больше, чем единичный повтор.

Наконец, поддерживайте проверенный путь восстановления. При переходе на ключи доступа или аппаратные ключи спланируйте выдачу, потерю, замену, доступность, поездки, автономное и экстренное использование. Нельзя незаметно оставлять слабый общий запасной способ, который вернет фишинговый путь. Пароли, устройства и восстановление описаны в руководстве по онлайн-безопасности.

Часто задаваемые вопросы (FAQ)

Неожиданный MFA-запрос доказывает кражу пароля?

Это не абсолютное доказательство, но может означать, что кто-то достиг шага MFA. Защитите аккаунт и проверьте события, а не списывайте уведомление на ошибку.

Отклонить запрос или просто игнорировать?

Отклоните и сообщите, если приложение это позволяет, затем независимо проверьте аккаунт. Если игнорировать повторные запросы и не защитить аккаунт, проблема с первым фактором останется нерешённой.

Сопоставление чисел остановит любую атаку усталости?

Нет. Оно снижает вероятность слепого и случайного согласия, связывая запрос с показанным числом. Но социальная инженерия всё ещё может повлиять на пользователя, а другие пути восстановления аккаунта могут остаться уязвимыми.

TOTP защищен от фишинга?

Нет. TOTP избавляет от неожиданной кнопки одобрения, но фишинговый сайт, работающий в реальном времени, может запросить код и переслать его до истечения срока.

Ключ доступа — это тот же push MFA?

Нет. Ключ доступа — это привязанные к сайту криптографические учетные данные с локальной проверкой на устройстве; push-запрос предлагает разрешить отдельную попытку входа. Механизмы и устойчивость к фишингу у них различаются.

Что, если уведомление пришло во время моего входа?

Сверьте сервис, устройство, местоположение, время и число. Отклоните запрос, если контекст не совпадает с начатым вами входом.

Смена пароля завершит одобренный сеанс?

Не всегда. Помимо смены раскрытого пароля отзовите незнакомые сеансы и проверьте изменения факторов и настроек восстановления.

Зачем сообщать об отклоненном запросе?

Организация сможет сопоставить ваше сообщение с попытками входа, защитить других атакуемых пользователей, заблокировать инфраструктуру атакующих и обнаружить кампанию до того, как кто-то одобрит запрос.

Материал дает общую информацию. Возможности аутентификации и отзыва различаются у провайдеров; используйте актуальные инструкции затронутого аккаунта и процесс своей организации.

Источники

CISA — Implement Number Matching in MFA Applications — https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf
Microsoft Learn — How number matching works in MFA push notifications for Authenticator — https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
Microsoft Learn — Phishing-resistant MFA — https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa

Sources checked 28 августа 2026 г.

Что такое атака усталости от MFA-запросов?