Campanhas de phishing que imitam portais de login podem capturar senhas, códigos de uso único e sessões autenticadas, afetando principalmente contas de e-mail, acesso remoto, arquivos e administradores. A prioridade defensiva é identificar quais serviços ainda aceitam MFA suscetível a phishing, bloquear sessões suspeitas e migrar os usuários de maior risco para autenticação resistente a phishing, como FIDO2 ou WebAuthn.
O problema não é apenas o roubo da senha. Em um ataque de intermediário, a vítima acessa uma página controlada pelo criminoso que reproduz o fluxo real de autenticação. A página encaminha as informações para o serviço legítimo, recolhe o segundo fator quando ele é digitado ou aprovado e tenta capturar o material que mantém a sessão aberta. Para a equipe defensiva, isso muda a pergunta de “o usuário usou MFA?” para “qual tipo de autenticador foi usado e que sessão surgiu depois dele?”.
Por que o MFA falha
O MFA reduz o risco de credenciais vazadas, mas não torna todos os métodos equivalentes. Códigos enviados por SMS, códigos de aplicativos e aprovações por notificação podem ser retransmitidos, induzidos ou obtidos por engenharia social. A própria orientação da CISA sobre MFA resistente a phishing descreve páginas falsas que solicitam usuário, senha e o código de seis dígitos do autenticador.
Em campanhas de intermediário, o atacante procura fazer a autenticação parecer normal para a vítima e para o provedor. O domínio pode usar HTTPS, a marca pode ser copiada e a solicitação de aprovação pode surgir no momento esperado. Depois do login, o invasor tenta reutilizar a sessão em outro ambiente. Por isso, uma troca imediata de senha pode não encerrar o incidente se as sessões, tokens ou métodos de recuperação continuarem válidos.
O risco é maior para contas com acesso a correio, armazenamento, faturamento, código-fonte, VPN, consoles de nuvem e ferramentas de identidade. Uma conta comum também pode servir para fraude, coleta de contatos, movimentação lateral e novos ataques contra parceiros. O impacto operacional depende menos da quantidade de mensagens enviadas do que da capacidade do invasor de obter uma identidade confiável.
O que verificar primeiro
Comece pelo provedor de identidade e preserve os registros antes de fazer alterações amplas. Correlacione autenticações bem-sucedidas, falhas, alterações de fatores, criação de aplicativos autorizados, consentimentos OAuth, redefinições de senha e mudanças em regras de encaminhamento. Um login de um endereço IP novo, seguido de alteração de método de autenticação ou acesso a grande volume de arquivos, merece prioridade mesmo que a MFA tenha sido aprovada.
Não trate geolocalização isolada como prova. Redes corporativas, celulares e serviços de nuvem podem alterar a origem aparente. Procure combinações: dispositivo não reconhecido, navegador incomum, mudança rápida de país ou provedor, sessão simultânea incompatível, criação de token persistente e leitura de mensagens antes de uma fraude. Em ambientes Microsoft 365, Google Workspace ou equivalentes, retenha também eventos de acesso a aplicativos, consentimento delegado e regras de caixa postal.
| Prioridade | Verificação | Decisão |
|---|---|---|
| P1 | Login anômalo seguido de alteração de fator, consentimento ou regra de encaminhamento | Revogar sessões e tokens, bloquear a conta e abrir investigação |
| P1 | Conta privilegiada autenticada por origem ou dispositivo desconhecido | Suspender privilégios, preservar evidências e revisar ações administrativas |
| P2 | Uso recorrente de SMS, OTP ou aprovação sem contexto | Priorizar migração para FIDO2/WebAuthn e reforçar controles temporários |
| P2 | Serviço sem suporte ao autenticador resistente | Isolar o acesso, exigir SSO quando possível e registrar exceção com prazo |
Contenção sem perder evidências
Quando houver indício consistente de comprometimento, revogue sessões ativas e tokens de atualização, desabilite temporariamente a conta e remova métodos de autenticação adicionados durante a janela suspeita. Faça a redefinição da senha em canal confiável, mas não a considere suficiente. Revise aplicativos empresariais autorizados, chaves de acesso, dispositivos registrados, regras de encaminhamento, delegações e grupos alterados.
Para administradores, aplique a contenção por uma conta separada e verificada. Evite investigar usando a própria identidade possivelmente comprometida. Preserve horários em UTC, identificadores de usuário, endereços IP, agentes de usuário, IDs de sessão, eventos de autenticação e ações realizadas após o login. Se a conta acessou dados pessoais, financeiros ou de clientes, acione o processo interno de incidente e avalie as obrigações de comunicação.
O bloqueio do domínio usado no phishing ajuda, mas é uma medida de curta duração. O criminoso pode trocar domínio, redirecionamento ou infraestrutura. Também não apague imediatamente a mensagem original da caixa postal: guarde cabeçalhos, URLs, anexos e indicadores para pesquisa retroativa. Procure a mesma campanha em caixas de executivos, financeiro, suporte e administradores.
A migração que reduz o risco
A autenticação resistente a phishing vincula a resposta criptográfica à origem legítima do serviço. Isso dificulta que uma página intermediária reutilize a autenticação em outro domínio. A CISA classifica FIDO/WebAuthn como a forma amplamente disponível de MFA resistente a phishing e recomenda priorizar a migração, começando por sistemas de e-mail, compartilhamento de arquivos, acesso remoto e identidade.
O NIST SP 800-63B estabelece requisitos para níveis de garantia de autenticação e determina que aplicações avaliadas no nível AAL2 ofereçam uma opção resistente a phishing. A decisão operacional não deve ser “comprar chaves para todos” sem planejamento. Mapeie os serviços compatíveis, defina recuperação segura, entregue pelo menos dois autenticadores por pessoa quando a política permitir e teste contas de emergência sob controle rigoroso.
Comece por administradores, equipe de suporte, financeiro, executivos e usuários com acesso a dados sensíveis. Depois expanda para os demais grupos. Durante a transição, use número correspondente em notificações, limites de risco, reautenticação para ações críticas e alertas de registro de novos fatores. Essas medidas não substituem FIDO2, mas reduzem a probabilidade de aprovação acidental enquanto a migração não termina.
Como medir o avanço
Acompanhe a cobertura por aplicação e por grupo de risco, não apenas a porcentagem geral de usuários com MFA. Um indicador útil é a proporção de autenticações privilegiadas feitas com autenticador resistente a phishing. Registre também contas sem MFA, serviços legados, exceções, métodos de recuperação e tempo médio para revogar sessões após um alerta.
Faça exercícios com mensagens simuladas sem coletar segredos reais. O objetivo é testar reporte, triagem, revogação de sessão, comunicação com o usuário e investigação de alterações posteriores ao login. O resultado deve produzir uma lista de serviços que ainda dependem de OTP, SMS ou aprovação simples, além de responsáveis e prazos para eliminar cada exceção.
A decisão defensiva é clara: MFA continua necessário, mas o método importa. Se a identidade controla e-mail, administração, dados ou dinheiro, trate OTP, SMS e notificações como controles de transição. Bloqueie sessões suspeitas agora, investigue o que ocorreu depois da autenticação e estabeleça uma migração verificável para autenticadores vinculados ao domínio legítimo.