MFA Fatigue: o ataque que faz o seu 2FA trabalhar contra você

Em abril de 2025, a Marks & Spencer — uma das maiores varejistas do Reino Unido — ficou com o e-commerce fora do ar por cinco dias consecutivos. A causa não foi um zero-day sofisticado nem uma vulnerabilidade desconhecida. O grupo Scattered Spider ligou para a central de atendimento da empresa, se passou por um funcionário, conseguiu uma redefinição de senha, e de lá em diante foi uma questão de tempo. Prejuízo estimado pelo Cyber Monitoring Centre: entre £270 milhões e £440 milhões. Tudo começou com um telefonema e uma notificação de MFA aprovada por engano.

O que é MFA fatigue (e por que o nome é preciso)

Multi-factor authentication fatigue — ou push bombing — é uma técnica de ataque que explora a psicologia humana em vez de vulnerabilidades técnicas. O conceito é simples: o atacante já tem a senha da vítima (comprada em marketplace de credenciais vazadas, obtida via phishing, ou quebrada offline). O que falta é o segundo fator.

Em sistemas com MFA baseado em notificação push — como o Microsoft Authenticator, Duo ou Okta Verify — o aplicativo dispara um alerta no celular perguntando "Você está tentando fazer login?". Em vez de tentar burlar tecnicamente esse mecanismo, o atacante dispara dezenas ou centenas de solicitações de autenticação em sequência, às vezes no meio da madrugada, às vezes durante o pico do expediente. O objetivo é fazer a vítima clicar em "aprovar" só para parar o barulho.

Push bombing não exige código malicioso, não depende de patch ausente, e não aciona antivírus. A "vulnerabilidade" é a atenção humana.

Como o ataque funciona, passo a passo

O fluxo padrão documentado em múltiplos incidents é este:

1. Obtenção de credenciais: o atacante compra um par login/senha em fórum underground, obtém via credential stuffing contra um serviço menos protegido, ou pesca via phishing clássico.
2. Validação: tenta autenticar no sistema-alvo para confirmar que a senha ainda é válida. O sistema pede o segundo fator — o ataque começa aqui.
3. Disparo em rajada: ferramentas automatizadas disparam requisições de autenticação consecutivas. Cada uma gera uma notificação push no celular da vítima.
4. Engenharia social paralela: em ataques mais sofisticados, o atacante liga para a vítima se passando por suporte de TI — "estamos atualizando o sistema, precisa aprovar a notificação que vai chegar agora".
5. Acesso: a vítima aprova. O segundo fator foi vencido sem explorar nenhuma falha técnica.

Dois casos reais que confirmam o padrão

Cisco (maio de 2022)

Um funcionário da Cisco tinha as credenciais corporativas sincronizadas no Google Chrome, e a conta pessoal do Google foi comprometida. O Cisco Talos — time de inteligência de ameaças da própria empresa — documentou que o grupo Yanluowang disparou uma série de notificações push até o funcionário aprovar uma, ao mesmo tempo em que recebia chamadas de voz de atacantes se passando por suporte técnico. Com acesso ao VPN corporativo, o grupo se moveu lateralmente até controladores de domínio. Segundo o Bleeping Computer, 2,75 GB de dados foram exfiltrados e publicados em agosto de 2022.

Marks & Spencer (fevereiro–abril de 2025)

Conforme reportado pelo Bleeping Computer e analisado pela Specops Software, o Scattered Spider obteve acesso inicial impersonando um funcionário junto ao service desk terceirizado da M&S para forçar um reset de senha. Com credenciais válidas, exfiltraram o arquivo NTDS.dit — o banco de dados do Active Directory contendo hashes de senha de toda a organização. Após quebrar os hashes offline, implantaram o DragonForce ransomware nos servidores VMware ESXi em 24 de abril. As operações de e-commerce ficaram suspensas por cinco dias, com perdas de £3,8 milhões por dia só em vendas online. O impacto no mercado de ações superou £500 milhões.

Mesma receita: credencial comprometida, engenharia social no service desk, acesso escalado. A diferença entre os dois casos foi apenas a escala do dano.

Por que o 2FA convencional não é suficiente

O problema está na escolha do método de segundo fator, não no conceito de autenticação em dois fatores em si. Notificações push são convenientes — e exatamente por isso são o alvo mais fácil. O usuário vê "Aprovar / Negar", está no meio de outra coisa, e clica. Sem verificar IP de origem, localização, horário incomum, ou quantas tentativas precederam aquela notificação.

OTP via SMS tem um problema diferente: SIM swap. Um atacante que convence a operadora a transferir o número para um SIM próprio passa a receber todos os tokens temporários. Não é hipótese de laboratório — é o vetor documentado em casos contra executivos e figuras públicas com acesso a contas de alto valor.

O que os dois métodos têm em comum: dependem de um canal que pode ser abusado sem explorar nenhuma vulnerabilidade técnica.

Hardening: o que realmente reduz a superfície

Medidas concretas, em ordem de impacto:

• Troque push por TOTP ou chave FIDO2/passkey: apps como Aegis (Android) ou Raivo (iOS) geram códigos baseados em tempo que não podem ser aprovados remotamente por spam. Passkeys — baseadas em FIDO2 — são phishing-resistant por design: o par de chaves criptográficas é vinculado ao domínio exato, e um site falso não consegue completar a autenticação mesmo com as credenciais corretas.
• Ative number matching: Microsoft Authenticator, Duo e Okta já suportam exibir um número na tela de login que precisa ser digitado no app para aprovar. Isso quebra o push bombing porque o atacante não vê o número exibido na tela da vítima.
• Configure limites de tentativas de MFA: políticas de lock-out após N tentativas frustradas cortam o ataque na fase de rajada. Monitorar eventos de autenticação suspeitos — como 50 notificações push geradas em 10 minutos — é viável com auditoria de logs no PowerShell via Get-WinEvent, sem precisar de SIEM corporativo.
• Desconfie de SMS como segundo fator em contas críticas: para e-mail principal, gerenciador de senhas e banco, SMS é o método mais fraco disponível. Substitua por TOTP no mínimo, FIDO2 quando possível.
• Treine a regra dos três segundos: se você não iniciou o login, recuse e reporte. O funcionário da Cisco sabia que as notificações eram suspeitas — e ainda assim aprovou depois de ligações reforçando a narrativa de suporte técnico. A defesa aqui é hábito, não tecnologia.

Para quem administra redes, vale combinar controle de MFA com filtragem DNS criptografada como camada anterior ao problema: bloquear domínios de phishing na resolução impede que credenciais cheguem ao atacante antes mesmo do MFA entrar em cena.

O padrão que se repete

Cisco em 2022, M&S em 2025, MGM Resorts, Twilio — o vetor é o mesmo, só mudam os alvos. Push bombing não exige capacidade técnica sofisticada: exige credenciais válidas (mercado farto após cada vazamento), paciência, e um método de MFA baseado em aprovação manual.

Isso não torna o MFA inútil — sem nenhum segundo fator, os incidents teriam sido ainda mais rápidos. Significa que o tipo de MFA importa tanto quanto tê-lo ativado. A exposição massiva de credenciais em vazamentos como o da Canvas — 275 milhões de registros estudantis — alimenta exatamente esse pipeline: credencial vaza, entra no marketplace underground, vira tentativa de push bombing contra quem reutilizou a senha em outro serviço.

Se você gerencia infraestrutura: revisar qual método de MFA está configurado hoje vale mais do que instalar mais uma camada de detecção. Se você cuida só das suas próprias contas: TOTP com app dedicado, agora. SMS serve para a maioria das coisas — exceto para as contas que mais importam quando comprometidas.