MFA sob ataque: como bloquear a fadiga de aprovação antes que ela vire incidente grave

Nos últimos meses, uma discussão no Reddit voltou a expor uma dor real das equipes de segurança: usuários bombardeados por notificações de login até clicarem em “aprovar” só para parar o incômodo. Não é teoria. É rotina em empresas que dependem de push MFA sem controles adicionais. O problema não é “MFA ruim”; é MFA mal configurado para um adversário que já entendeu o comportamento humano. Neste guia editorial, vamos separar hype de prática e mostrar um plano viável para reduzir risco em semanas, não em trimestres.

O gatilho: o que a comunidade técnica está relatando no Reddit

O debate ganhou força em um tópico de r/it sobre MFA fatigue attacks (também chamado de MFA bombing). O relato era direto: múltiplos incidentes no mês, usuários recebendo push a cada poucos segundos e, em alguns casos, aprovação indevida por exaustão. O time já tinha feito “o básico” — treinamento, limitação parcial, checagens geográficas — mas continuava perdendo para a engenharia social de atrito.

Esse tipo de depoimento importa porque mostra um padrão operacional, não um evento isolado. Quando várias organizações descrevem o mesmo mecanismo de falha, normalmente o problema está no desenho do controle e na experiência do usuário, não apenas na conscientização. Em outras palavras: insistir no mesmo fluxo e aumentar o volume de campanha educativa tende a gerar retorno decrescente.

Também apareceu no debate uma confusão comum entre três coisas distintas: MFA tradicional, MFA com mitigação de fadiga (como number matching) e MFA resistente a phishing (FIDO2/WebAuthn). Tratar essas camadas como equivalentes atrapalha decisões de investimento. Elas não oferecem o mesmo nível de proteção.

Por que “aprovar/recusar” virou alvo fácil

No modelo de push legado, o atacante obtém senha (vazamento, reutilização, spray ou phishing), tenta autenticar e dispara uma sequência de prompts. A cada notificação, a organização aposta que o usuário vai negar com atenção. O atacante aposta no contrário: pressa, distração, ansiedade, horário ruim, cansaço.

É um jogo assimétrico. Para defender, o usuário precisa acertar sempre. Para atacar, basta um clique errado. Essa assimetria cresce quando a notificação não traz contexto suficiente (origem, app, local, código de confirmação), quando o funcionário recebe muitos alertas legítimos por dia, ou quando há cultura de “resolve rápido e volta ao trabalho”.

A CISA alertou que, se a organização ainda depende de push convencional, deve ao menos adotar controles intermediários, como number matching, enquanto migra para métodos resistentes a phishing. A mensagem é clara: não basta “ter MFA”; importa qual MFA, como está configurado e como é operado no dia a dia.

O que as fontes técnicas confirmam (e o mercado às vezes simplifica demais)

Três referências ajudam a colocar os pés no chão:

• CISA/FBI (AA22-074A): descreve atores explorando configurações padrão e lacunas de re-enrolamento, reforçando que má configuração de MFA pode abrir porta para comprometimento.
• Microsoft Entra: consolidou number matching como melhoria de segurança para reduzir aprovações acidentais em notificações push.
• OWASP MFA Cheat Sheet: lembra que MFA continua sendo defesa crítica, mas precisa de fatores independentes, fluxo de recuperação seguro e escolha adequada ao risco.

O ponto editorial aqui é importante: muita comunicação de vendor vende “MFA” como selo binário de maturidade. Na prática, maturidade está no detalhe operacional: política de inscrição, proteção de canal, resistência a phishing, trilha de auditoria e governança de exceções.

Não caia no falso dilema: “treinamento ou tecnologia”

Quando acontece fadiga de MFA, a reação comum é culpar usuário. Isso simplifica demais. Treinamento é necessário, mas sozinho não vence um fluxo que incentiva erro humano sob pressão. O desenho do sistema precisa assumir falha humana previsível.

A combinação mais eficiente costuma ser:

• Controles técnicos imediatos: number matching, contexto na notificação, limites de tentativas, bloqueios adaptativos.
• Política clara de resposta: se recebeu push sem iniciar login, reportar e disparar contenção.
• Treino orientado a cenário: simulações curtas com casos reais, não só e-learning anual.

Esse trio reduz risco rápido e evita a armadilha de gastar meses em “programa cultural” enquanto o vetor continua ativo.

Estratégia em 3 camadas: conter agora, endurecer em 90 dias, transformar em 12 meses

Camada 1 — Contenção imediata (0 a 30 dias): priorize usuários administrativos, finanças, RH, diretoria e acesso remoto. Ative number matching para todos os push suportados. Remova fallback fraco (SMS/voz) onde possível. Exija redefinição de senha e revisão de sessão após alertas de fadiga.

Camada 2 — Endurecimento (30 a 90 dias): revise políticas de re-enrolamento e recuperação de conta; implemente prova de identidade robusta para reset. Aplique conditional access com sinal de risco, dispositivo gerenciado e contexto de login. Integre detecção de anomalia com SOAR para resposta mais rápida.

Camada 3 — Transformação (3 a 12 meses): migre gradualmente para autenticadores resistentes a phishing (FIDO2/WebAuthn, chaves de segurança, passkeys corporativas sob governança). Redesenhe processos de onboarding/offboarding e reposição de fator para evitar atalhos inseguros.

Empresas que tentam pular da camada 1 direto para a 3 geralmente travam em adoção. Já as que encadeiam as fases conseguem resultado visível cedo e mantêm apoio executivo.

Mini-caso prático: onde o projeto costuma quebrar

Considere uma empresa de médio porte com 800 colaboradores e duas ferramentas críticas em nuvem. O time ativa number matching e comemora queda dos incidentes por 4 semanas. No mês seguinte, volta a ter aprovações indevidas em usuários de suporte terceirizado.

A causa raiz não estava na tecnologia principal, mas na exceção: um grupo de contas compartilhadas com fluxo de recuperação frágil e bypass operacional para plantão noturno. Resultado: o invasor não atacou o caminho principal; atacou o “atalho oficial”.

Lição: qualquer programa de MFA deve mapear exceções, contas de serviço, suporte terceirizado e rotinas de emergência. É aí que a segurança real costuma perder para a operação.

Checklist prático para reduzir MFA fatigue sem paralisar a operação

• Inventarie todos os métodos MFA ativos e classifique por resistência a phishing.
• Ative number matching em 100% dos fluxos push compatíveis.
• Desative gradualmente SMS e chamada de voz como fallback padrão.
• Aplique políticas diferentes para contas privilegiadas e contas comuns.
• Implemente bloqueio progressivo após sequência anômala de prompts.
• Exija dispositivo em conformidade para aprovar login sensível.
• Revise processo de re-enrolamento (prova forte + trilha de auditoria).
• Crie playbook de “push inesperado” com SLA de resposta do SOC.
• Treine usuários com exercícios curtos e recorrentes baseados em casos reais.
• Monitore métricas semanais: taxa de negação, aprovações suspeitas, tempo de contenção.
• Planeje rollout de FIDO2/passkeys por grupos de maior risco primeiro.
• Formalize exceções com prazo de expiração e dono responsável.

Métricas que realmente mostram evolução (e evitam autoengano)

Sem métricas, a organização confunde “mudança implementada” com “risco reduzido”. Três indicadores ajudam a manter honestidade operacional:

• Taxa de prompts não solicitados por 1.000 usuários: mostra pressão de ataque e qualidade do filtro inicial.
• Tempo médio de contenção após aprovação suspeita: mede prontidão de resposta, não só prevenção.
• Percentual de autenticações em método resistente a phishing: sinal de maturidade estrutural.

Uma meta pragmática para 90 dias: reduzir drasticamente prompts indevidos, manter contenção em janela curta e elevar de forma contínua a adoção de autenticadores fortes nos perfis críticos.

Erros caros que continuam acontecendo mesmo em empresas maduras

Erro 1: tratar exceção como detalhe administrativo. Em quase todo incidente de identidade, existe uma exceção antiga: conta de fornecedor sem revisão, usuário de diretoria fora da política, bypass para plantão, integração legada sem MFA forte. A exceção vira caminho principal do atacante. Se não houver inventário e prazo de expiração para exceções, o programa degrada silenciosamente.

Erro 2: confundir baixa taxa de incidente com baixo risco. Algumas empresas passam meses sem caso confirmado e relaxam telemetria. O problema é que ataques de fadiga podem parecer “ruído de autenticação” até que uma aprovação indevida aconteça. Sem monitoramento de tentativas anômalas e correlação com risco de sessão, a organização enxerga tarde demais.

Erro 3: reset de MFA fraco. Muita estratégia boa cai por um processo de recuperação permissivo. Se a redefinição de fator pode ser concluída com validação frágil, o invasor não precisa vencer o controle principal; ele dribla o processo de suporte. Reset precisa de prova forte, dupla checagem para perfis críticos e trilha auditável.

Erro 4: projeto sem patrocínio executivo real. Adoção de autenticação forte mexe em experiência, help desk, operação e orçamento. Sem direção clara da liderança, cada área cria exceção “temporária” e o risco volta. Segurança de identidade é tema de continuidade de negócio, não apenas tarefa de TI.

Plano 30-60-90 para sair do improviso

Primeiros 30 dias: mapear métodos ativos, ativar number matching onde houver push, remover fallback fraco em contas privilegiadas e instituir protocolo de resposta para push não solicitado. Entrega esperada: redução imediata de aprovações acidentais.

Até 60 dias: corrigir re-enrolamento, padronizar processo de reset, integrar logs de identidade ao SOC e aplicar controles condicionais por risco/dispositivo. Entrega esperada: menor janela de exploração após credencial comprometida.

Até 90 dias: iniciar migração assistida para FIDO2/passkeys em grupos críticos (administração, finanças, acesso remoto, equipes com dados sensíveis), com métricas semanais e governança de exceções. Entrega esperada: aumento mensurável de autenticações resistentes a phishing.

Esse cronograma é realista para organizações de médio porte porque combina ganho rápido com transformação progressiva. A alternativa — adiar tudo até “projeto perfeito” — costuma custar mais caro em incidentes, horas de resposta e desgaste com auditoria.

FAQ — dúvidas comuns de quem está no front

1) Number matching resolve definitivamente MFA fatigue?
Não. Reduz bastante aprovações acidentais, mas não substitui MFA resistente a phishing. É mitigação intermediária, não estado final.

2) SMS MFA ainda pode ser usado?
Pode existir como contingência temporária em alguns cenários, mas deve sair do papel de fallback padrão em ambientes com risco elevado.

3) Biometria é automaticamente melhor?
Depende da arquitetura. Biometria local associada a chave criptográfica forte pode ser ótima. Biometria sem proteção adequada de canal e identidade não é bala de prata.

4) Vale forçar hardware token para todo mundo de uma vez?
Raramente. O rollout big-bang costuma gerar resistência e exceções perigosas. Melhor começar por grupos de maior impacto e risco.

5) Treinamento perdeu valor?
Não. Ele muda de função: deixa de ser única barreira e passa a reforçar um sistema que já foi desenhado para errar menos.

6) Como vender isso para liderança?
Mostre risco operacional em linguagem de negócio: indisponibilidade, fraude, impacto reputacional, custo de resposta e auditoria.

Conclusão editorial: maturidade de identidade é decisão de gestão, não só de TI

O alerta vindo do Reddit ecoa o que CISA, OWASP e grandes plataformas já vêm apontando: ataques de fadiga exploram um ponto cego entre segurança e usabilidade. Se a empresa continuar tratando MFA como checkbox de conformidade, vai seguir vulnerável a um vetor barato e escalável.

A saída real é combinar resposta tática imediata com uma rota estratégica para autenticação resistente a phishing. Em termos práticos: pare de medir sucesso por “quantos têm MFA” e comece a medir por “qual método, em qual contexto, com qual governança e qual tempo de resposta”. A diferença entre incidente recorrente e controle maduro está exatamente aí.

Referências

• Reddit (gatilho editorial): r/it — “MFA fatigue attacks are getting out of control – time to rethink our auth strategy?”
• CISA/FBI Cybersecurity Advisory AA22-074A — exploração de configurações padrão de MFA.
• CISA Alert (31/10/2022) — guidance sobre phishing-resistant MFA e number matching.
• Microsoft Entra — “How number matching works in MFA push notifications for Authenticator”.
• OWASP Cheat Sheet — Multifactor Authentication.
• NIST SP 800-63B/63-4 — diretrizes de autenticação e níveis de garantia.