Um post no Reddit, publicado por um profissional de TI que simulou envios de push no Duo para usuários da própria empresa, trouxe uma constatação desconfortável: mesmo sem ter iniciado login, muita gente aprova a notificação por impulso. A discussão foi direta e honesta — não sobre tecnologia “ruim”, mas sobre processo mal desenhado. Neste artigo, vamos usar esse gatilho para ir além do susto: por que o MFA falha na prática, onde estão os pontos cegos e como montar uma defesa que funcione no mundo real.
O alerta do Reddit: quando o usuário aprova o que não pediu
O gatilho desta pauta veio de um tópico no r/cybersecurity com o título “Even with MFA the users are the weakness.” O autor descreve que enviou pushes aleatórios para um grupo de usuários e se surpreendeu com a quantidade de aprovações indevidas. O mais importante da conversa não é “culpar o usuário”. É entender que, quando a autenticação vira um reflexo mecânico, ela deixa de ser prova de identidade e vira apenas clique.
Esse tipo de cenário está cada vez mais comum porque muitos ambientes ainda operam com “aprovação simples”: chegou a notificação, o usuário toca em aprovar, sem contexto suficiente sobre aplicativo, local, horário ou motivo daquele desafio. Em ambientes sob pressão (reunião, prazo, celular vibrando o dia todo), o comportamento tende a piorar.
Em outras palavras: o problema não é só humano, é de desenho de controle. Se o fluxo permite aprovação sem fricção inteligente, o atacante só precisa insistir até encontrar alguém cansado, distraído ou inseguro.
MFA fatigue: um ataque simples, barato e teimosamente eficaz
O chamado MFA fatigue (ou push bombing) explora saturação psicológica. O atacante já tem senha válida (obtida por phishing, vazamento, credencial reutilizada ou engenharia social) e dispara pedidos repetidos de autenticação até que a vítima aprove um deles. Em variantes mais agressivas, o criminoso ainda liga para a vítima fingindo ser do suporte: “estamos validando sua conta, confirme a solicitação”.
A Microsoft descreveu esse padrão de ataque e destacou um dado incômodo em estudos próprios: uma pequena parcela de usuários ainda aprova solicitações simples já na primeira tentativa. Pode parecer pouco, mas em empresas grandes isso é suficiente para gerar incidentes recorrentes.
A grande lição: enquanto a autenticação depender de um “sim” sem contexto forte, haverá margem para abuso operacional. O atacante não precisa ser brilhante; precisa ser persistente.
Quando “ter MFA” não significa estar protegido
No discurso corporativo, “temos MFA habilitado” costuma aparecer como selo de maturidade. Na operação, isso pode esconder fragilidades sérias. A própria CISA, em alerta conjunto com o FBI, mostrou como atores estatais exploraram configurações padrão e cenários de re-enrollment para contornar proteção em ambientes reais.
Há três armadilhas clássicas:
- Configuração permissiva por padrão: políticas de fallback, reativação de conta inativa e exceções antigas esquecidas.
- Dependência excessiva de push/SMS: métodos convenientes, mas mais expostos a engenharia social.
- Governança fraca de ciclo de vida: contas órfãs, reset de MFA sem validação robusta e baixo monitoramento de sinais de risco.
Em resumo, MFA é indispensável, mas não é “ligar e esquecer”. É um controle vivo, que precisa de política, observabilidade e revisão contínua.
O que as fontes técnicas recomendam (e por quê)
Se cruzarmos Reddit, CISA, NIST e fabricantes de identidade, surge um consenso prático:
- Trocar aprovação cega por desafio contextual. Number matching e contexto de login reduzem aprovações acidentais.
- Priorizar MFA resistente a phishing. NIST 800-63B enfatiza opções resistentes a phishing em níveis maiores de garantia.
- Controlar re-enrollment e contas inativas. O caso descrito pela CISA mostra como esse ponto é explorável.
- Tratar repetição de push como sinal de incidente. Não é “usuário distraído”; é potencial comprometimento de senha.
- Amarrar autenticação ao risco. Políticas condicionais e step-up quando comportamento desvia do normal.
Note que nenhuma dessas medidas depende de “ferramenta mágica”. É disciplina de arquitetura e operação.
Trade-offs reais: segurança, atrito e produtividade
Um erro comum é tratar UX e segurança como lados opostos. Na prática, autenticação ruim gera os dois problemas ao mesmo tempo: aumenta risco e piora experiência. Quando o usuário recebe notificações demais, ele passa a aprovar no automático. Isso não é produtividade; é erosão de controle.
O caminho maduro é desenhar fricção inteligente:
- Baixo risco: fluxo rápido e previsível.
- Risco intermediário: confirmação adicional com contexto claro.
- Risco alto: bloqueio, revisão e autenticação forte (idealmente passkey/chave FIDO2).
Esse modelo protege melhor e reduz fadiga operacional, porque a fricção aparece quando realmente importa.
Arquitetura mínima para reduzir MFA fatigue em 30 dias
Se você precisa sair do diagnóstico e ir para execução, este plano enxuto funciona bem em ambientes de pequeno e médio porte:
- Semana 1 — Inventário e limpeza: mapear métodos de MFA por grupo, remover exceções antigas, revisar contas inativas e política de re-enrollment.
- Semana 2 — Endurecimento: habilitar number matching/contexto, reduzir dependência de SMS quando possível e aplicar políticas de risco para logins anômalos.
- Semana 3 — Detecção e resposta: criar alerta para múltiplos pushes em janela curta, playbook de contenção e reset seguro de credenciais.
- Semana 4 — Treino cirúrgico: campanha curta focada em “não aprove o que você não iniciou”, com exemplo de ataque por telefone e canal oficial para reportes.
Esse ciclo de 30 dias não encerra o tema, mas muda o patamar de risco rapidamente.
Checklist prático para equipes de segurança e TI
- Desative aprovação simples onde houver alternativa mais segura.
- Ative number matching e contexto de localização/aplicativo no prompt.
- Bloqueie ou limite re-enrollment sem validação adicional forte.
- Revise contas inativas e contas privilegiadas toda semana.
- Aplique políticas de acesso condicional por risco e por dispositivo.
- Defina limiar de tentativas e lockout para abuso de autenticação.
- Configure alerta para rajadas de push no SIEM/IdP.
- Padronize runbook: contenção, comunicação ao usuário, forense básica e lições aprendidas.
- Treine help desk para não “resetar no susto” após ligação suspeita.
- Meça mensalmente: taxa de prompts negados, aprovações indevidas e tempo de resposta.
Indicadores que mostram se você está melhorando
Sem métrica, MFA vira ritual. Com métrica, vira controle de risco. Comece com cinco indicadores simples:
- Taxa de aprovação sem contexto: deve cair após number matching.
- Volume de prompts por usuário/dia: picos anormais precisam de investigação.
- Incidentes de reset de MFA por engenharia social: indicador direto de maturidade do suporte.
- Percentual de contas privilegiadas em método resistente a phishing: prioridade absoluta.
- MTTR de eventos de autenticação suspeita: tempo entre alerta e contenção efetiva.
Se os números não mudam, o programa está só “cumprindo tabela”.
Mini-caso: como um incidente costuma acontecer na vida real
Veja um cenário comum em empresas com operação híbrida. Um colaborador reutiliza senha em um serviço externo que sofreu vazamento meses atrás. A credencial para e-mail corporativo continua válida. O atacante testa login em horário de pico, dispara cinco prompts de MFA em sequência e, no sexto, recebe aprovação. A partir daí, cria regra de encaminhamento no e-mail, coleta conversa financeira e tenta fraude de pagamento com linguagem idêntica à do executivo.
Perceba a cadeia completa: o problema começou fora do ambiente corporativo, atravessou o login por um método de baixa resistência e terminou em abuso de processo interno. Esse é o ponto editorial que muita empresa ignora: ataque de identidade quase sempre vira ataque de negócio.
Agora compare com um ambiente mais maduro: o mesmo login suspeito aciona risco elevado por geolocalização incomum; o sistema exige confirmação com number matching e bloqueia após tentativas consecutivas; o usuário recebe alerta claro para reportar tentativa não iniciada; o SOC abre investigação automática; e o help desk só executa reset com dupla validação de identidade. Resultado: o atacante gasta esforço, não ganha sessão.
Não existe milagre aqui. Existe engenharia de processo. Quanto mais previsível for a sua resposta operacional, menor a chance de o adversário transformar insistência em acesso.
Governança: o papel do help desk, do SOC e da liderança
MFA fatigue não é um tema “só de segurança”. É transversal. Se a governança não estiver clara, cada área responde de um jeito e o atacante explora a desorganização.
- Help desk: precisa de roteiro rígido para reset de senha e MFA, sem atalhos por pressão hierárquica ou urgência aparente.
- SOC: deve tratar rajada de prompts como evento correlacionável com tentativa de comprometimento de conta.
- Gestores de negócio: precisam aceitar que, em certos casos, bloqueio temporário é melhor do que “liberar para não parar operação”.
- Liderança executiva: deve patrocinar a migração para métodos resistentes a phishing nas contas mais sensíveis.
Um acordo interno útil é documentar RACI simples: quem detecta, quem decide bloqueio, quem comunica usuário, quem fecha incidente e quem revisa causa-raiz. Sem isso, a organização repete erro em ciclos curtos.
Também vale formalizar uma política de exceções com prazo de validade. Exceção permanente vira vulnerabilidade institucionalizada. Se o diretor quer “quebra de regra”, precisa ter dono, data final e compensação de controle.
FAQ
1) MFA por SMS ainda vale a pena?
Melhor do que senha isolada, sem dúvida. Mas, para contas críticas, o ideal é migrar para métodos mais resistentes a phishing e engenharia social.
2) Number matching resolve tudo?
Não. Ele reduz muito aprovações acidentais em push, mas precisa vir com monitoramento, política de risco, governança de contas e resposta a incidente.
3) Pequenas empresas conseguem implementar isso?
Sim. Comece com o básico bem feito: revisão de contas, prompts com contexto, política de bloqueio e treinamento objetivo para usuários e suporte.
4) Treinamento anual de conscientização é suficiente?
Normalmente não. O que funciona melhor é microtreinamento frequente, com exemplos reais do seu ambiente e reforço no momento do risco.
5) Como convencer diretoria a investir?
Mostre o trade-off financeiro: um incidente de conta comprometida custa muito mais do que endurecer autenticação e processo de suporte.
Conclusão editorial: pare de discutir “se” e decida “como”
O debate no Reddit deixa um recado simples: o elo fraco não é “o usuário” em abstrato, é o conjunto de decisões que empurra pessoas para aprovar sem pensar. A empresa madura não terceiriza isso para campanha de e-mail. Ela redesenha o fluxo, mede comportamento e reduz superfície de erro operacional.
Se você lidera segurança, a decisão prática é esta: abandonar aprovação cega, priorizar autenticação resistente a phishing nas contas sensíveis e tratar rajada de push como incidente em potencial. O resto é detalhe de implementação. O risco, esse, já está batendo na porta faz tempo.
Referências
- Reddit (r/cybersecurity): “Even with MFA the users are the weakness.” https://www.reddit.com/r/cybersecurity/comments/1et2mvh/even_with_mfa_the_users_are_the_weakness/
- Microsoft Tech Community: “Defend your users from MFA fatigue attacks.” https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defend-your-users-from-mfa-fatigue-attacks/2365677
- CISA/FBI Advisory AA22-074A: exploração de protocolos MFA padrão e recomendações de mitigação. https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-074a
- NIST SP 800-63B (Digital Identity Guidelines – Authentication and Authenticator Management). https://pages.nist.gov/800-63-4/sp800-63b.html
- Verizon 2025 DBIR (página oficial do relatório). https://www.verizon.com/business/resources/reports/dbir/