O que é MFA Fatigue?
MFA fatigue, também chamada de MFA bombing ou push bombing, é a geração repetida de solicitações de multifactor authentication até que um usuário acabe aprovando uma. A MITRE acompanha essa técnica como T1621, Multi-Factor Authentication Request Generation.
O mecanismo é mais estreito do que muitas equipes descrevem. No caso mais comum, o atacante já possui a senha da vítima e fica bloqueado apenas pelo segundo fator. Em vez de parar aí, ele dispara notificações push repetidas para Microsoft Authenticator, Duo, Okta Verify ou um serviço MFA semelhante e tenta desgastar o usuário.
O escopo deste artigo é Microsoft Entra ID e MFA push com Microsoft Authenticator, com ênfase em detecção operacional e hardening do tenant. MFA fatigue não é a mesma coisa que password spraying, phishing adversary-in-the-middle ou SIM swapping, embora essas técnicas frequentemente apareçam antes ou em paralelo.
O risco central é simples: um controle MFA baseado em aprovação por push ainda depende de que o usuário tome a decisão correta sob pressão. Se o atacante consegue gerar prompts repetidos, ou combiná-los com um pretexto de engenharia social, um controle que parecia forte na política pode falhar na prática.
Como a MFA Fatigue funciona
A definição da MITRE é precisa: adversários podem tentar contornar MFA gerando solicitações MFA enviadas aos usuários. Se eles já têm credenciais válidas, podem ficar bloqueados apenas porque não controlam o segundo fator. Para contornar isso, abusam de notificações push e esperam que o usuário conceda acesso.
Isso importa porque o ataque não quebra criptografia. Ele abusa do desenho do fluxo de autenticação e do comportamento humano de aprovação.
Uma sequência típica focada em Entra se parece com isto:
- o atacante obtém um nome de usuário e senha válidos por phishing, password spraying, credential stuffing ou engenharia social contra o help desk
- o atacante inicia um sign-in interativo que exige aprovação no Microsoft Authenticator
- o usuário recebe notificações push repetidas
- o atacante continua tentando, frequentemente em momentos escolhidos para gerar confusão ou cansaço
- se o usuário finalmente aprova um prompt, o atacante obtém uma sessão autenticada válida
A MITRE também observa um segundo caminho que às vezes passa despercebido: se o atacante ainda não possui as credenciais, a geração automática de push também pode ser abusada em alguns cenários de self-service password reset quando esse fluxo está configurado para enviar notificações push.
MFA fatigue não é a mesma coisa que outros ataques de identidade
As diferenças importam, porque as mitigações não são idênticas.
- Password spraying tenta uma ou poucas senhas sobre muitos usuários para obter a primeira credencial válida. Veja Password Spraying: detecção e prevenção em Active Directory e Entra ID.
- MFA fatigue começa depois que o atacante já possui, ou está muito perto de possuir, um primeiro fator válido e quer transformar um login bloqueado em um login aprovado.
- Phishing adversary-in-the-middle faz proxy do fluxo de sign-in para capturar tokens ou contexto de sessão em tempo real. Não depende do cansaço do usuário da mesma forma.
- SIM swapping tem como alvo fatores baseados em telefone tomando controle do número móvel da vítima.
A MFA fatigue ataca especificamente a etapa humana de aprovação dentro da MFA baseada em push.
Por que a MFA Fatigue ainda funciona
A MFA fatigue continua eficaz quando três problemas se sobrepõem: o atacante tem um primeiro fator válido, o tenant ainda depende de aprovações push para contas importantes e o usuário não tem contexto ou fricção suficientes para rejeitar a solicitação com segurança.
A orientação da Microsoft sobre phishing-resistant MFA é explícita: métodos MFA tradicionais como SMS, OTP por email e notificações push estão se tornando menos eficazes contra atacantes modernos. O documento cita user fatigue e MFA bombing como exemplos concretos de como atacantes contornam padrões MFA legados.
Na prática, a MFA fatigue funciona porque:
Aprovações push são fáceis de disparar repetidamente
O atacante não precisa quebrar um token ou derrotar uma chave de hardware. Basta um fluxo de login que continue gerando prompts.
Muitos usuários ainda recebem prompts com pouco contexto
Se a notificação não mostra claramente o nome da aplicação e o contexto geográfico do sign-in, o usuário tem menos informação para distinguir um login legítimo de um ataque. A Microsoft documenta a adição desse contexto às notificações do Authenticator como uma forma de melhorar a segurança do sign-in, mas o entrega desativado: o padrão Microsoft managed para o nome da aplicação e para a localização geográfica é Disabled.
Usuários podem ser socialmente manipulados enquanto os prompts chegam
Uma solicitação push tem mais chance de ser aprovada se chegar enquanto o atacante pressiona a vítima por telefone ou mensagem, durante um reset de senha legítimo ou quando o usuário já espera alguma atividade real de login.
Contas de alto valor ainda costumam estar protegidas apenas por MFA padrão
Se administradores ainda dependem apenas de aprovações push padrão em vez de MFA resistente a phishing, a lista de alvos do atacante se torna muito mais valiosa.
Pré-requisitos para um ataque de MFA Fatigue bem-sucedido
Um ataque de MFA fatigue bem-sucedido normalmente exige as seguintes condições.
1. O atacante tem um primeiro fator válido ou consegue acionar um fluxo de reset
A suposição base da MITRE é que o atacante já possui credenciais válidas. No universo Entra, isso normalmente significa uma senha roubada, uma senha recuperada em outra intrusão ou uma senha obtida após Password Spraying: detecção e prevenção em Active Directory e Entra ID.
2. O alvo usa MFA push
O ataque depende de que o usuário receba uma solicitação de aprovação. Se a conta-alvo estiver restrita a métodos resistentes a phishing, por exemplo por meio de authentication strengths mais fortes para sign-ins privilegiados, a MFA fatigue se torna muito menos útil.
3. O tenant não reduziu o suficiente aprovações de baixo contexto
Se o prompt mostra apenas uma solicitação genérica, ou se o reporte de atividade suspeita não está habilitado, o usuário recebe menos contexto e o defensor menos sinais de alta confiança quando há abuso.
4. A conta tem valor suficiente para justificar tentativas repetidas
Administradores, operadores cloud, equipe de help desk e administradores de aplicações são alvos especialmente atraentes, porque uma única aprovação pode abrir muito acesso posterior.
5. Os workflows de resposta são lentos demais
Se negativas repetidas de prompts não forem investigadas rapidamente, ou se reports de prompts suspeitos não gerarem containment, o atacante pode continuar tentando até que um usuário aprove ou uma segunda etapa de engenharia social funcione.
A cadeia de ataque
Uma cadeia prática de intrusão por MFA fatigue normalmente se parece com isto.
Etapa 1 - Obter a senha
O atacante primeiro obtém a senha por phishing, password spraying, reutilização de credenciais ou engenharia social.
Etapa 2 - Disparar o desafio MFA
O atacante tenta um login em Microsoft 365, Azure ou uma carga conectada ao Entra que exija aprovação no Authenticator.
Etapa 3 - Repetir a geração dos prompts
Em vez de aceitar a falha inicial, o atacante continua gerando solicitações de aprovação. Esse é exatamente o comportamento que a MITRE captura em T1621.
Etapa 4 - Adicionar pressão social
Atacantes podem combinar os prompts com ligações ou mensagens que pressionam o usuário a aprovar uma solicitação, muitas vezes fingindo ser suporte interno ou explorando um momento de confusão em torno de um login ou reset de senha real.
Etapa 5 - Usar imediatamente a sessão aprovada
Quando o usuário aprova um prompt, o atacante obtém o que queria: uma sessão válida no tenant alvo. A partir daí, os próximos passos dependem do privilégio e da cobertura de políticas. Ações comuns incluem revisar o diretório, descobrir funções privilegiadas, procurar application registrations, acessar caixas de correio ou alterar configurações de autenticação.
O prompt aprovado, portanto, não é o estado final do incidente. É o ponto de pivô entre login bloqueado e acesso autenticado.
Detecção
Não existe um único evento do Entra que diga “isso foi definitivamente MFA fatigue”. O modelo correto é detecção baseada em sequência mais contexto.
Procurar negativas MFA repetidas contra o mesmo usuário
O sinal mais óbvio é um conjunto de tentativas repetidas em que o mesmo usuário recebe múltiplas solicitações MFA e as nega ou ignora. Nos sign-in logs do Entra, isso normalmente aparece como sign-ins interrompidos repetidos com detalhes de falha MFA antes de um possível sucesso posterior.
Tratar reports de prompts suspeitos como evidência de alta confiança
A funcionalidade Report suspicious activity da Microsoft é o sinal nativo mais forte nesse fluxo. Segundo o Microsoft Learn:
- usuários que reportam como suspeito um prompt MFA desconhecido são marcados como High User Risk
- o evento aparece em sign-in logs, audit logs e risk detections
- nos sign-in logs, o Result detail da autenticação aparece como MFA denied
- no relatório de risk detections, o detection type é User Reported Suspicious Activity, o risk level é High e a source é End user reported
- o
riskEventTypeéuserReportedSuspiciousActivity, e a conta reportada retornariskLevel = highna APIriskyUsersdo Graph
Isso importa porque permite sair de conjectura para um sinal concreto confirmado pelo próprio usuário.
Uma exceção documentada deve entrar nas suas consultas: a Microsoft afirma que um usuário não é reportado como High Risk se realizar passwordless authentication. Quando parte da população já usa passkeys ou passwordless phone sign-in, a ausência de um usuário High Risk não é prova de que nada foi reportado — verifique também o audit log e o sign-in log.
Correlacionar a sequência MFA com o contexto do sign-in
As investigações devem correlacionar a sequência de prompts com:
- IPs e geografias que o usuário normalmente não utiliza
- aplicações incomuns iniciando o sign-in
- tentativas repetidas da mesma fonte contra uma conta de alto valor
- um padrão de várias negativas seguido de um único sucesso
- atividade imediatamente posterior à aprovação bem-sucedida
Dar atenção especial às identidades privilegiadas
Um único episódio de push bombing contra um usuário comum já é sério. O mesmo padrão contra um Global Administrator, um Conditional Access Administrator ou um Privileged Role Administrator exige containment imediato.
Essa é uma das razões para revisar Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM e Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático em conjunto com esse padrão de ataque.
Evitar conclusões baseadas em um único evento
Usuários às vezes negam prompts legítimos. Mudanças de rede móvel, sign-ins a partir de um novo dispositivo ou simples confusão também podem gerar ruído. O melhor detector, portanto, não é uma única negativa, mas um padrão repetido, especialmente quando combinado com user-reported suspicious activity, contexto de sign-in incomum ou ações privilegiadas posteriores.
Remediação
Parar MFA fatigue não é adicionar ainda mais prompts MFA genéricos. É tornar aprovações maliciosas mais difíceis de disparar, mais fáceis de reconhecer e menos valiosas quando acontecem.
A MITRE enquadra o mesmo objetivo em três mitigações para T1621: substituir aprovações simples por push ou de um único toque por mecanismos mais fortes e implementar limites para o número máximo de solicitações MFA que um usuário pode receber em um período de tempo (M1032), bloquear sign-ins originados de localizações suspeitas ou de localizações que não correspondem à localização do dispositivo MFA (M1036), e treinar os usuários para aceitar apenas prompts que eles mesmos iniciaram e reportar o restante (M1017). Os controles do Entra abaixo são a forma como isso se traduz em um tenant.
1. Verificar que os fluxos push do Authenticator usam number matching
A Microsoft afirma que o number matching está habilitado para todas as notificações push do Authenticator e o descreve como um upgrade de segurança essencial em relação às notificações tradicionais de segundo fator. Os usuários não podem fazer opt-out, e o comportamento cobre MFA, SSPR e o registro combinado SSPR/MFA.
Isso importa porque, num prompt push genérico, o atacante não consegue mais vencer com um único toque distraído. O usuário precisa inserir um número mostrado no fluxo de sign-in.
Duas nuances documentadas impedem que isso seja, sozinho, uma resposta completa:
- Sign-ins no mesmo dispositivo continuam sendo um prompt Yes/No. Quando o usuário faz sign-in no mesmo dispositivo que executa o Authenticator, para apps móveis da Microsoft como Teams ou Outlook, a Microsoft permite responder Yes/No em vez de digitar o número. A justificativa da Microsoft é que não há risco adicional, porque o prompt só aparece no dispositivo que iniciou o sign-in — exatamente o caso que um atacante remoto não consegue alcançar. Sign-ins vindos de Edge, Chrome ou Safari continuam exigindo o número.
- Caminhos de integração MFA adjacentes não se comportam todos da mesma forma. O adapter do AD FS só aplica number matching em builds corrigidas do Windows Server 2016, 2019 e 2022; servidores não corrigidos mantêm a experiência Approve/Deny. A extensão NPS não suporta number matching de forma alguma — a partir da versão 1.2.2216.1 ela solicita um código TOTP no lugar, e somente para usuários com um método TOTP registrado. O Azure MFA Server, descontinuado, não aplica number matching, e o recurso não é suportado em Apple Watch ou wearables Android.
Valide esses caminhos separadamente, em vez de assumir que todo workflow push tem o mesmo nível de proteção da experiência atual Entra + Authenticator.
2. Habilitar contexto de sign-in nas notificações do Authenticator
A Microsoft documenta isso como uma forma de melhorar a segurança do sign-in: adicionar o nome da aplicação e a localização geográfica do sign-in às notificações push e passwordless do Authenticator, combinando esse contexto adicional com o number matching. A mitigação de user-training da MITRE aponta na mesma direção — os usuários devem revisar a origem da tentativa de login que gerou o prompt, o que só é possível se o prompt exibir essa informação.
A armadilha é que esse contexto vem desativado até você ativá-lo. As duas configurações ficam na política de Authentication methods, em Microsoft Authenticator > Configure (displayAppInformationRequiredState e displayLocationInformationRequiredState no Microsoft Graph), e a própria tabela da Microsoft de padrões Microsoft managed lista Location in Microsoft Authenticator notifications e Application name in Microsoft Authenticator notifications como Disabled. Deixar qualquer uma das duas em Microsoft managed significa, portanto, deixá-la desativada. Defina o status explicitamente como Enabled.
Duas limitações documentadas valem a pena conhecer antes de planejar o rollout: só usuários já habilitados para o Authenticator nessa política veem o contexto extra, e o additional context não é suportado para a extensão NPS nem para o AD FS.
Um tenant que deixa as aprovações push genéricas demais facilita ataques de fatigue. Quando o prompt mostra uma aplicação ou localização que o usuário não reconhece, a rejeição se torna muito mais provável.
Esse controle é especialmente útil quando o atacante já tem uma senha real e tenta convertê-la em uma sessão aprovada.
3. Habilitar Report suspicious activity e conectá-lo à resposta
Essa configuração é um dos controles Entra de maior valor contra MFA fatigue.
A Microsoft documenta que, quando um usuário reporta um prompt MFA suspeito:
- o usuário é marcado como High User Risk
- o evento fica visível em sign-in logs, audit logs e risk detections
- tenants com licença Microsoft Entra ID P2 podem usar risk-based Conditional Access em user risk = high para bloquear o sign-in ou forçar um password reset
- tenants com P1 ainda recebem o evento de risk detection, e fazem a remediação manualmente ou via automação com Microsoft Graph ou PowerShell
Operacionalmente, isso significa que o usuário pode fazer mais do que tocar em Deny. Ele pode gerar um sinal de incidente visível ao defensor a partir do próprio prompt.
Dois detalhes de configuração decidem se algo disso realmente acontece. Primeiro, a configuração é habilitada em Authentication methods > Settings, no Microsoft Entra admin center, e a Microsoft afirma claramente que o recurso permanece desativado se você escolher Microsoft managed — o padrão Microsoft managed para Report suspicious activity é Disabled. Selecione Enabled e depois defina o escopo para todos os usuários ou um grupo específico. Segundo, o Report suspicious activity substituiu os recursos legados Block/unblock users, Fraud alert e Notifications, que a Microsoft removeu em 1º de março de 2025; qualquer runbook que ainda instrua um analista a verificar o Fraud alert precisa ser reescrito.
4. Migrar usuários privilegiados para MFA resistente a phishing
A orientação atual da Microsoft é clara: funções administrativas privilegiadas são alvos frequentes, e as organizações deveriam exigir phishing-resistant MFA para esses papéis.
Para o tema deste artigo, esse ponto é central. Uma aprovação push padrão ainda pode ser abusada por fatigue ou engenharia social. Uma authentication strength resistente a phishing torna esse caminho materialmente mais difícil.
Se você estiver endurecendo acesso privilegiado, combine isso com Seguranca de Identidade Azure: Quando o MFA Nao Basta e Azure Identity Protection: Politicas de Risco.
5. Reduzir a quantidade de senhas que atacantes podem reutilizar desde o início
A MFA fatigue geralmente começa depois de uma compromissão de senha. Se você reduz o roubo de senhas e o sucesso do password spraying, também reduz o número de oportunidades de push bombing.
É isso que torna Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real e Fortalecimento do Tenant Azure: Security Defaults diretamente relevantes. Fluxos de aprovação MFA mais fortes são importantes, mas devem se apoiar em um tenant que já esteja reduzindo o acesso inicial baseado em senha.
6. Revisar identidades externas e guest separadamente
O risco da MFA push não se limita a contas de funcionários. Identidades externas, contas B2B guest e acessos de parceiros também podem se tornar caminhos de aprovação ruidosos ou pouco revisados se estiverem isentos de controles mais fortes ou forem monitorados com menos rigor. É por isso que Contas de Convidado Azure: Riscos do Tenant faz parte da mesma revisão.
7. Implementar políticas mais fortes com cuidado
A orientação da Microsoft para administradores inclui um aviso operacional real: antes de exigir MFA resistente a phishing amplamente para administradores, confirme que esses usuários já estão registrados nos métodos necessários. Caso contrário, você corre o risco de se bloquear para fora do tenant.
A mesma lógica vale para mudanças de Conditional Access em geral:
- usar report-only quando disponível
- proteger intencionalmente contas de acesso de emergência
- revisar separadamente service accounts e workload identities
- validar que workflows de help desk e recuperação de identidade continuam funcionando
Bom hardening de identidade não é apenas sobre controles mais fortes. Também é sobre evitar indisponibilidade autoinduzida.
Validação após o hardening
Não encerre esse tema apenas porque uma configuração do Entra foi ativada. É preciso validar o workflow completo de aprovação.
- confirmar que o tenant realmente apresenta number matching nos cenários de Authenticator push que você usa de fato
- confirmar que o prompt mostra nome da aplicação e localização geográfica onde isso é esperado, e que ambas as configurações mostram Enabled em vez de Microsoft managed
- confirmar que Report suspicious activity mostra Enabled, não Microsoft managed, para a população de usuários pretendida
- confirmar que reports de prompts suspeitos geram os sinais esperados em sign-in logs, audit logs e risk detections
- confirmar que o workflow de resposta revoga sessões, investiga sign-ins e redefine credenciais quando um usuário reporta um prompt malicioso
- confirmar que administradores privilegiados estão cobertos por requisitos de autenticação mais fortes do que usuários comuns
O teste real não é se MFA está habilitada no tenant. O teste real é se uma senha roubada, combinada com tentativas push repetidas, ainda tem um caminho realista para aprovação.
Como a EtcSec detecta exposição relacionada
MFA fatigue é uma técnica de ataque, não uma única misconfiguração do Entra. Os findings de catálogo mais próximos são os gaps de controle que tornam push bombing mais provável de ter sucesso ou mais difícil de conter.
As exposições relacionadas mais relevantes são:
- ausência de risk-based sign-in response, o que enfraquece o containment depois que um usuário reporta um prompt suspeito
- proteção fraca ou incompleta de identidades privilegiadas, especialmente quando usuários administrativos não são movidos para padrões de autenticação mais fortes
- desenhos de Conditional Access que ainda dependem demais de prompts MFA padrão em vez de exigir métodos mais fortes
Por isso este tema fica ao lado de Azure Identity Protection: Politicas de Risco, Seguranca de Identidade Azure: Quando o MFA Nao Basta e Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático, e não como uma simples configuração isolada do tenant.
Controles relacionados
Se você estiver revisando MFA fatigue, também deve revisar os controles que moldam o mesmo caminho de ataque: Seguranca de Identidade Azure: Quando o MFA Nao Basta, Azure Identity Protection: Politicas de Risco, Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real, Fortalecimento do Tenant Azure: Security Defaults, Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático e Contas de Convidado Azure: Riscos do Tenant.
Fontes primárias
- MITRE ATT&CK – Multi-Factor Authentication Request Generation (T1621)
- Microsoft Learn – Configure Microsoft Entra multifactor authentication
- Microsoft Learn – How number matching works in MFA push notifications for Authenticator
- Microsoft Learn – Use additional context in Authenticator notifications
- Microsoft Learn – Protecting authentication methods in Microsoft Entra ID (Microsoft managed settings)
- Microsoft Learn – Phishing-resistant MFA
- Microsoft Learn – Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles
Explore as paginas de identidade que sustentam este tema