O problema não é a ausência de autenticação multifator, mas o uso de fatores que o criminoso consegue induzir a vítima a entregar. Organizações que protegem contas com códigos temporários, mensagens de aprovação ou SMS continuam expostas a páginas falsas, fadiga de notificações e roubo de sessão. A ação prioritária é identificar contas administrativas, de suporte e de acesso financeiro que ainda dependem desses fatores e iniciar a migração para chaves de acesso baseadas em criptografia de chave pública.
O ataque não termina na senha
Uma campanha de phishing contra identidade pode começar com uma mensagem banal, seguir para uma página que imita o provedor de login e terminar com a coleta de senha, código temporário ou aprovação no celular. O invasor não precisa quebrar a criptografia do serviço. Ele precisa conduzir a pessoa pelo fluxo legítimo enquanto observa ou retransmite os dados para o serviço real.
Esse modelo altera a decisão defensiva. Bloquear domínios maliciosos, treinar usuários e exigir uma segunda etapa continuam sendo controles úteis, mas não devem ser tratados como barreira absoluta. Quando o segundo fator é digitado em uma página controlada pelo invasor ou aprovado sob pressão, a autenticação pode ser convertida em autorização para o adversário.
A CISA descreve phishing, bombardeio de notificações, abuso de mensagens móveis e troca fraudulenta de SIM como caminhos usados para obter credenciais de autenticação. A agência recomenda autenticação resistente a phishing e classifica FIDO/WebAuthn como a alternativa mais forte para a migração.
O que muda com WebAuthn
O ganho central não está no nome comercial do recurso, mas no vínculo técnico entre a credencial e o serviço legítimo. O navegador e o autenticador participam da verificação da origem; uma chave registrada para um domínio não deve responder como se estivesse diante de outro domínio. Isso reduz o valor de uma página clonada, mesmo quando a aparência é convincente.
A especificação do W3C define credenciais de chave pública vinculadas à parte confiável e informa que elas só podem ser acessadas por origens pertencentes a essa parte. O servidor recebe uma prova criptográfica e verifica o desafio, a conta e o identificador do serviço. A senha não precisa ser enviada, e o usuário não precisa copiar um código que possa ser retransmitido.
Passkeys são uma forma de disponibilizar esse modelo em dispositivos pessoais e corporativos. Dependendo da implementação, a credencial pode ficar em um dispositivo, ser sincronizada de modo protegido ou ser mantida em uma chave física. O ponto relevante para o SOC é confirmar se o serviço realmente usa FIDO2/WebAuthn no fluxo de autenticação, e não apenas um rótulo de “login sem senha” sobre um mecanismo convencional.
O vínculo de origem não elimina todo risco de identidade. Recuperação de conta, inscrição inicial, administração do provedor, dispositivos comprometidos e sessões já abertas continuam exigindo controles próprios. A migração também precisa considerar como revogar uma credencial, substituir um dispositivo perdido e investigar uma sessão criada antes da troca do fator.
Decida por risco e privilégio
Não comece distribuindo a mesma política para todos. Faça um inventário das identidades que conseguem alterar regras, acessar dados sensíveis, aprovar pagamentos, administrar o diretório ou redefinir fatores de terceiros. Inclua contas de suporte e operadores que podem assumir a identidade de outro usuário.
| Prioridade | Alvo | Decisão operacional |
|---|---|---|
| P1 | Administradores, suporte e recuperação de contas | Exigir chave de acesso resistente a phishing e bloquear métodos fracos quando houver alternativa funcional. |
| P1 | Contas com acesso financeiro ou dados regulados | Revisar sessões ativas, métodos de recuperação e aprovações fora do padrão antes da migração. |
| P2 | Usuários sem privilégio elevado | Oferecer inscrição guiada, manter fator alternativo controlado e medir a adoção sem ampliar exceções. |
| P2 | Aplicações legadas | Colocar o acesso atrás do provedor de identidade ou registrar prazo e proprietário para substituição. |
O inventário deve registrar proprietário da conta, aplicação, método usado, possibilidade de recuperação, último uso e privilégio efetivo. Uma conta que aparece como “MFA ativo” pode continuar usando SMS ou aprovação simples. Esse campo não basta para decidir o risco.
Feche os caminhos de retorno
A migração falha quando a organização instala o fator forte, mas preserva uma rota de recuperação mais fraca. Se o usuário pode perder a chave e voltar ao SMS sem revisão, o invasor tende a atacar o processo de recuperação. Se o suporte pode redefinir qualquer fator após uma conversa curta, o help desk vira o novo ponto de entrada.
Defina critérios para recuperação: comprovação independente da identidade, aprovação por mais de uma função em contas privilegiadas, registro completo da solicitação e expiração de credenciais temporárias. Separe a administração do provedor de identidade das equipes que operam aplicações. Revise quem pode registrar uma nova chave, remover a anterior ou alterar métodos alternativos.
Também é necessário controlar sessões. A troca do método de autenticação não deve ser confundida com encerramento automático de acessos já estabelecidos. Para contas suspeitas, o procedimento deve incluir revogação de sessões, rotação de tokens quando aplicável, revisão de regras de encaminhamento, análise de alterações recentes e validação de dispositivos usados no login.
O portal já mostrou que phishing de código de dispositivo pode sequestrar contas; a lição operacional é tratar qualquer código exibido para o usuário como dado potencialmente retransmissível. A proteção precisa estar no protocolo e na origem, não apenas na atenção de quem recebe a mensagem.
Monitore sinais de abuso
O SOC deve acompanhar eventos de inscrição, remoção e substituição de credenciais, alterações no método de recuperação, elevação de privilégio e criação de sessões em dispositivos novos. O alerta precisa mostrar identidade, aplicação, origem, dispositivo, método usado, resultado e responsável pela mudança.
Uma inscrição inesperada pode ser mais importante que uma falha de senha. Uma conta que troca o fator e logo depois altera regras de caixa postal, cria uma sessão administrativa ou acessa dados fora do padrão merece investigação correlacionada. A detecção deve juntar eventos de identidade, endpoint, rede e aplicação, respeitando atrasos de entrega e diferenças de horário.
O teste defensivo deve simular uma página falsa sem coletar credenciais reais. Verifique se o fluxo resistente rejeita a origem incorreta, se o usuário identifica a solicitação no dispositivo e se o SOC recebe os eventos necessários. Faça o exercício com uma conta de suporte e uma conta administrativa, porque os procedimentos de recuperação são parte do perímetro de identidade.
Para preservar a investigação, a equipe deve manter registros fora do controle cotidiano do provedor de identidade. O artigo sobre logs de nuvem íntegros e investigação detalha como separar coleta, retenção e validação. Sem essa trilha, a organização pode perceber a troca do fator, mas não conseguir provar quem autorizou a mudança nem quais acessos ocorreram depois.
Plano de migração
Na primeira fase, selecione um grupo pequeno de alto privilégio, elimine exceções sem proprietário e documente o processo de recuperação. Na segunda, integre aplicações críticas ao provedor de identidade e exija o fator resistente nos caminhos administrativos. Na terceira, expanda para os demais usuários, mantendo métricas de inscrição, falhas, recuperações e abandono.
Não trate a adoção como simples indicador de quantidade. A equipe precisa saber quantas contas privilegiadas continuam com método fraco, quantas recuperações ocorreram fora do procedimento e quantas aplicações ainda permitem acesso direto. Cada exceção deve ter motivo, responsável, prazo de revisão e controle compensatório.
A decisão recomendada é iniciar a migração pelas identidades que podem transformar um incidente de phishing em comprometimento amplo. Códigos temporários e aprovações móveis ainda podem reduzir risco em ambientes que não conseguem mudar de imediato, mas não devem permanecer como destino final para contas críticas. O objetivo é fazer com que a autenticação dependa de uma credencial vinculada ao serviço correto, enquanto recuperação, sessões e registros recebem o mesmo nível de rigor.