MFA Fatigue no Entra ID: detecção e prevenção

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 agora recomenda explicitamente mostrar esse contexto nas notificações do Authenticator.

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.

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
o riskEventType é userReportedSuspiciousActivity

Isso importa porque permite sair de conjectura para um sinal concreto confirmado pelo próprio usuário.

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.

1. Verificar que os fluxos push do Authenticator usam number matching

A Microsoft afirma que o number matching está habilitado para as notificações push atuais do Authenticator e o descreve como uma melhoria-chave de segurança em relação ao antigo modelo Approve/Deny.

Isso importa porque o atacante não consegue mais vencer com um simples toque distraído em um prompt genérico. O usuário precisa inserir um número mostrado no fluxo de sign-in.

Se o seu ambiente ainda depende de integrações MFA mais antigas ou adjacentes, é preciso validar o comportamento delas separadamente, em vez de assumir que todo workflow push tem o mesmo nível de proteção da experiência atual Entra + Authenticator.

A Microsoft recomenda explicitamente mostrar nome da aplicação e localização geográfica nas notificações do Authenticator para que o usuário possa tomar decisões informadas de aprovação.

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 passa a High User Risk
o evento fica visível em sign-in logs, audit logs e risk detections
organizações com licenciamento adequado podem usar risk-based Conditional Access para bloquear ou forçar remediação segura
organizações sem essa automação ainda recebem um sinal concreto que pode ser investigado e contido

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.

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 Acesso Condicional Azure: Riscos de Bypass MFA 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
confirmar que Report suspicious activity está habilitado 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, Acesso Condicional Azure: Riscos de Bypass MFA, 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.

MFA Fatigue: detecção e prevenção no Microsoft Entra ID