Se a sua organização usa Microsoft 365 e confia no MFA como principal barreira de segurança, este artigo é para você.
Por Matheus Jacyntho, Diretor de Investigações Cibernéticas da Protiviti Brasil.
Nos últimos meses, investigamos uma série de incidentes em clientes com ambiente Microsoft 365. O detalhe que nos chamou atenção logo de cara: em todos os casos, os logs mostravam que o MFA havia sido validado com sucesso, exatamente o tipo de coisa que normalmente tiraria qualquer caso da lista de suspeitos. Mas realmente houve o comprometimento!
Ao aprofundar a análise, encontramos um padrão comum entre esses incidentes, que detalhamos no artigo abaixo.
Em fevereiro de 2026, uma plataforma de phishing-as-a-service chamada EvilTokens comprometeu mais de 340 organizações em cinco países em menos de seis semanas. Nenhuma das vítimas entregou uma senha. Todas passaram pelo MFA normalmente. E ainda assim, os atacantes tiveram acesso completo a e-mails, arquivos, calendários e contatos por semanas ou meses.
Como isso é possível?
O golpe em linguagem simples
O ataque funciona assim: a vítima recebe uma mensagem (pode ser um e-mail, uma mensagem no Teams ou até num grupo de WhatsApp) com um link que abre o que parece ser uma tela de login legítima da Microsoft, muitas vezes imitando aplicativos conhecidos como Teams, Outlook ou SharePoint. Ao tentar entrar, a vítima é direcionada para o fluxo real de autenticação da Microsoft, completa o MFA normalmente e vê a tela de sucesso. Tudo parece certo.
De acordo com um estudo da Cloud Security Alliance (CSA), os temas usados nessa campanha de phishing foram variados e bem elaborados: convites para licitações, notificações de documentos no DocuSign, alertas de caixa postal, formulários do Microsoft Forms e lembretes de arquivos compartilhados — muitos deles com a identidade visual da própria organização da vítima, obtida de fontes públicas. Além disso, as páginas falsas foram construídas para dificultar a análise técnica: clique com botão direito bloqueado, ferramentas de desenvolvedor desativadas e loops de JavaScript inseridos para confundir sistemas automatizados de detecção. Tudo pensado para que nem o usuário nem as ferramentas de segurança percebessem o que estava acontecendo.
O problema é que o código digitado pertence ao atacante, não à vítima. Ao concluir esse fluxo, o usuário autoriza um aplicativo malicioso a acessar sua conta. O sistema interpreta isso como uma concessão legítima e entrega ao atacante um token de acesso de longa duração, com acesso ao e-mail, ao OneDrive, aos contatos e ao calendário, sem que nenhum alerta seja disparado.
Esse token sobrevive a trocas de senha e permanece válido por semanas ou meses, dependendo da configuração do tenant. O atacante nunca precisou da senha. O MFA já tinha sido feito pelo próprio usuário.
Por que o MFA não resolve aqui
O MFA foi projetado para proteger o momento do login, quando alguém tenta usar uma credencial roubada. No ataque de device code phishing, esse momento ocorre de forma legítima: é o próprio usuário que faz a autenticação, no domínio real da Microsoft, completando o segundo fator sem qualquer problema.
O que o usuário não percebe é que, ao digitar o código e clicar em “Aceitar”, não está confirmando um login seu — está autorizando que um aplicativo externo acesse sua conta em nome dele. Essa ação fica registrada como concessão de permissão, não como tentativa de invasão. Os sistemas de detecção tradicionais simplesmente não veem isso como uma ameaça.
Os riscos vão além da conta individual
Quando um atacante obtém esse tipo de acesso, ele entra silenciosamente no ambiente. A partir da caixa de e-mail comprometida, ele pode se passar pelo colaborador para enganar colegas com novos ataques internos. Pode mapear arquivos confidenciais no OneDrive e SharePoint. Pode mover-se lateralmente em busca de contas com mais privilégios.
E há um risco menos óbvio que cresce com o uso de agentes de IA e integrações SaaS: quando um único usuário autoriza múltiplos aplicativos ao longo do tempo, cada concessão parece inofensiva isoladamente. Mas a combinação dessas permissões cria uma superfície de acesso que nenhum gestor de aplicativo individualmente autorizou. A CSA chama isso de “combinações tóxicas”, e elas são invisíveis para os logs de cada aplicação separada.
O que fazer para se proteger
Primeiro, bloqueie ou restrinja o fluxo de device code nas políticas de Conditional Access do Microsoft Entra ID. Se a sua organização não usa dispositivos que dependem desse fluxo, não há motivo para deixá-lo ativo.
Segundo, configure políticas de consentimento de aplicativos para que usuários comuns não possam autorizar aplicativos de terceiros livremente. Permita
consentimento apenas para aplicativos de publishers verificados e com permissões de baixo risco, ou exija aprovação de um administrador para tudo mais.
Terceiro, faça um inventário dos tokens OAuth ativos no seu tenant. Qualquer aplicativo com refresh token ativo há mais de 30 dias sem re-consentimento merece revisão. Tokens não utilizados devem ser revogados proativamente.
Quarto, inclua esse cenário nos treinamentos de conscientização. Usuários precisam entender que digitar um código em microsoft.com/devicelogin pode ser tão perigoso quanto clicar em um link suspeito, mesmo que a página seja real.
Por fim, considere implementar políticas de Conditional Access que disparem não apenas em eventos de login, mas também em eventos de consentimento OAuth. E certifique-se de que o plano de resposta a incidentes preveja revogação granular de tokens, sem precisar suspender a conta inteira do usuário.
O phishing evoluiu. A pergunta não é mais apenas “o usuário entregou a senha?”. É também “o usuário autorizou um aplicativo que não deveria?”
Enquanto a maioria das organizações ainda trata autenticação como o perímetro principal, os atacantes já operam uma camada abaixo, na camada de consentimento, onde os controles tradicionais simplesmente não chegam.
