Entre os dias 14 e 16 de abril de 2026, uma única campanha de phishing rastreada pela Microsoft Threat Intelligence coletou tokens de sessão de mais de 35 mil usuários em 13 mil organizações espalhadas por 26 países. Todas essas vítimas tinham MFA habilitado, e em nenhum dos casos foi preciso roubar senha nenhuma: bastou o usuário completar o login normalmente, autenticação multifator incluída, para que a sessão fosse sequestrada minutos depois por um proxy que ficou no meio do caminho o tempo todo, entre o navegador da vítima e o Microsoft 365.
Esse caso virou o padrão, não a exceção. Nos últimos dois anos, um tipo específico de kit de phishing amadureceu rápido: Tycoon2FA, Mamba2FA, EvilTokens, Kali365. Cada um tem nome comercial e público-alvo levemente diferentes, mas por trás todos vendem a mesma coisa, um serviço por assinatura com painel de controle, suporte técnico e atualização periódica de templates, como se fosse um SaaS qualquer. A Microsoft chegou a desarticular a infraestrutura do Tycoon2FA em conjunto com a Europol no início de 2026. O vácuo durou pouco: concorrentes preencheram o espaço em semanas, porque a brecha que exploram não está num kit específico, está na arquitetura do MFA, que protege o momento do login e para de prestar atenção exatamente quando a sessão começa.
Nada disso é exclusividade de empresas americanas ou de multinacionais. São produtos comerciais vendidos por assinatura, e assinatura não escolhe geografia: qualquer organização brasileira operando Microsoft 365 com MFA no padrão de fábrica, código por aplicativo, push ou SMS, está no mesmo raio de exposição descrito nos relatórios que embasam este texto. O que segue é como o ataque funciona por dentro, o que ele compromete quando dá certo e quais controles do próprio ecossistema Microsoft reduzem essa exposição de forma mensurável. Um adendo necessário: os números acima não tornam o MFA tradicional inútil, ele segue barrando a maior parte dos ataques de força bruta e de credenciais vazadas. O recorte deste artigo é mais específico do que isso, é sobre o intervalo em que ele para de proteger.
O Que Mudou nos Ataques de Phishing Contra o Microsoft 365?
Do roubo de senha ao roubo de sessão
Phishing clássico rouba um par de credenciais. Funcionou bem durante anos porque a maioria das contas não tinha segunda camada de proteção. Quando o MFA se tornou padrão corporativo, esse modelo de ataque perdeu eficácia: uma senha sozinha deixou de abrir a porta. O problema é que a resposta do mercado criminoso não foi tentar quebrar o MFA, foi ignorá-lo. Em vez de atacar o segredo que comprova a identidade, os kits atuais atacam o artefato que a Microsoft emite depois que a identidade já foi comprovada: o token de sessão. Esse token vale tanto quanto a senha e o segundo fator juntos, só que ninguém pede para o usuário digitá-lo de novo a cada clique.
Phishing-as-a-Service comoditizou o ataque
O que antes exigia conhecimento técnico de proxy reverso e infraestrutura própria hoje se compra pronto. O Tycoon2FA, atribuído pela Microsoft ao grupo Storm-1747, chegou a movimentar dezenas de milhões de mensagens de phishing por mês contra mais de 500 mil organizações, com acesso ao painel a partir de cerca de US$ 120. O Kali365, alvo de alerta público do FBI em 21 de maio de 2026, é distribuído por assinatura via Telegram a partir de US$ 250 por 30 dias e não depende de capturar senha nenhuma: ele abusa de um fluxo legítimo de autorização OAuth para obter o token diretamente. O EvilTokens, lançado no início de 2026, automatizou essa mesma técnica em escala e foi associado pela Huntress a mais de 340 organizações comprometidas em cinco países num único levantamento.
O efeito prático dessa comoditização é a queda da barreira técnica. Um atacante não precisa mais entender como funciona um proxy adversary-in-the-middle, ele precisa apenas de um cartão de crédito e de uma lista de e-mails corporativos.
Por que o Microsoft 365 é alvo prioritário
Uma conta do Microsoft 365 comprometida não é só uma caixa de e-mail. É a porta de entrada para Exchange Online, Teams, SharePoint e OneDrive, quatro sistemas que juntos concentram comunicação, identidade e documentos de uma empresa inteira. Os templates de phishing analisados pela Microsoft no caso Tycoon2FA imitavam justamente esse conjunto: Microsoft 365, Azure, OneDrive, SharePoint e DocuSign, marcas que o usuário corporativo vê todos os dias e não questiona. Quanto mais central o Microsoft 365 é na operação de uma empresa, maior o valor de uma sessão sequestrada dentro dele.
Como um Kit de Phishing Consegue Burlar o MFA?
O que é um ataque AiTM (Adversary-in-the-Middle)
Em vez de exibir uma página falsa estática, o kit sobe um servidor que funciona como proxy reverso entre o navegador da vítima e o login real da Microsoft. Cada campo que o usuário preenche, incluindo o desafio de MFA, é repassado em tempo real para os servidores legítimos da Microsoft. Do ponto de vista da Microsoft, a autenticação é genuína, porque tecnicamente é: as credenciais e o segundo fator são validados contra a API real. A diferença é que o atacante está sentado no meio dessa conversa, capturando tudo o que passa por ela, incluindo o cookie de sessão que a Microsoft devolve ao final do processo.
Como o token de sessão é capturado e reutilizado
O usuário entra com o login e a senha. O MFA é solicitado e completado normalmente, seja por aplicativo autenticador, SMS ou notificação push. Nesse exato momento, o proxy já capturou o token de sessão gerado pela Microsoft como prova de que a autenticação foi bem-sucedida. O atacante extrai esse token do tráfego interceptado e o injeta no próprio navegador, em outra máquina, muitas vezes em outro fuso horário inteiro. Não precisa da senha, não precisa completar MFA nenhum, porque está simplesmente reaproveitando uma sessão que já passou pela validação de outra pessoa.
Onde o MFA tradicional para
O MFA baseado em código, aplicativo autenticador ou push foi desenhado para responder a uma pergunta específica no instante do login: quem está tentando entrar é mesmo quem diz ser? Ele não foi desenhado para continuar amarrado a essa prova depois que a sessão já começou, e é exatamente essa lacuna que o AiTM explora. Um código de seis dígitos ou uma aprovação de push são segredos que passam de um lugar para outro, e qualquer coisa que passe de um lugar para outro pode ser interceptada no meio do caminho, desde que o intermediário consiga repassá-la rápido o suficiente antes que expire. É por isso que SMS, OTP e push notification, mesmo sendo eficazes contra a maioria dos ataques de senha em massa, simplesmente não enxergam um AiTM em andamento.
A variante que nem precisa de página falsa: phishing por código de dispositivo
Existe uma segunda técnica que dispensa até o proxy. Ela abusa do OAuth 2.0 Device Authorization Grant, o fluxo legítimo criado para autenticar dispositivos sem teclado, como TVs e impressoras de rede. O atacante gera um código de dispositivo válido e o envia à vítima disfarçado de convite para acessar um documento, uma gravação de reunião ou uma assinatura pendente. A vítima é instruída a digitar esse código na página oficial de ativação da Microsoft, o endereço real, sem nenhum proxy envolvido. Se ela já tiver uma sessão ativa no navegador, o que é o estado padrão da maioria dos profissionais durante o expediente, o token é emitido para o dispositivo do atacante sem disparar um novo desafio de MFA, porque a sessão existente já satisfez esse requisito.
Foi exatamente esse mecanismo que o FBI descreveu no alerta público sobre o Kali365 em maio de 2026, e é o mesmo caminho automatizado em escala pelo EvilTokens desde o início do ano. A recomendação de bloquear o device code flow por Conditional Access, detalhada mais adiante, existe especificamente por causa dessa variante.
Se sua empresa já leu o alerta anterior sobre o Kali365, este artigo cobre o quadro mais amplo: o mesmo mecanismo aparece em pelo menos onze kits distintos identificados por pesquisadores de ameaças, e a defesa não muda de kit para kit porque o alvo estrutural é sempre o mesmo token de sessão. Veja o histórico completo do alerta do FBI sobre o Kali365.
Quais os Riscos Reais para Empresas que Usam Microsoft 365?
Exchange Online comprometido: leitura de e-mails e fraude financeira
Com a sessão sequestrada, o primeiro movimento observado nas campanhas analisadas em 2026 costuma ser mais discreto do que exfiltrar dados em massa: estabelecer persistência dentro da própria caixa de entrada. Regras de encaminhamento silencioso para endereços externos, ou regras que ocultam automaticamente mensagens com palavras como “segurança”, “suspeito” ou “redefinição de senha”, são criadas em minutos, antes que qualquer alerta de segurança chegue à vítima. A partir daí, o terreno está preparado para Business Email Compromise: o atacante estuda threads reais de cobrança ou pagamento e responde se passando pelo próprio usuário, algo muito mais convincente do que um e-mail falso vindo de fora.
Acesso indevido a SharePoint e OneDrive
Uma sessão sequestrada herda exatamente as mesmas permissões que o usuário legítimo tinha. Se essa pessoa tinha acesso a contratos, propostas comerciais ou documentação técnica no SharePoint e no OneDrive, o atacante também tem. Uma das campanhas documentadas em janeiro de 2026 foi além do roubo passivo de dados: usou o SharePoint da própria organização comprometida para hospedar e distribuir novos links de phishing, elevando artificialmente a credibilidade da campanha seguinte porque ela partia de dentro de um domínio confiável.
Microsoft Teams como vetor de phishing interno
Mensagens enviadas de dentro do Teams por uma conta legítima raramente passam pelo mesmo filtro mental de desconfiança que um e-mail externo recebe. Uma conta sequestrada pode ser usada para espalhar o próximo link malicioso lateralmente, para colegas de equipe, parceiros em canais compartilhados ou até para outra vítima na cadeia de fornecedores, ampliando o alcance da campanha original sem depender de mais phishing por e-mail.
Escalada para ransomware
O relatório de ameaças 2026 da CrowdStrike registrou que 82% das detecções não envolveram instalação de malware algum, só login. Uma identidade comprometida por AiTM passa direto pelos controles de perímetro que boa parte das empresas ainda trata como primeira linha de defesa, porque do ponto de vista da rede não houve invasão nenhuma, houve um usuário entrando com as próprias credenciais. Esse ponto de apoio inicial costuma virar base para reconhecimento interno, movimento lateral e, em parte dos casos observados, para preparar a implantação de ransomware.
Se sua empresa ainda não avaliou até onde a superfície de identidade no Microsoft 365 está exposta a esse tipo de ataque, esse diagnóstico costuma valer mais a pena antes de um incidente forçar a conversa. A InfoB é parceira certificada Microsoft e pode conduzir essa avaliação junto com o time de TI. Fale com um especialista da InfoB.
Como Saber se Sua Empresa Já Foi Vítima?
Indicadores de comprometimento a observar
- Login registrado a partir de um país onde a empresa não opera, especialmente em sequência imediata a um login legítimo
- Duas ou mais sessões ativas simultâneas para o mesmo usuário, em dispositivos ou geografias que não fazem sentido juntas
- Regras de caixa postal criadas sem participação do usuário, principalmente as que encaminham para fora do domínio ou ocultam mensagens
- Consentimentos concedidos a aplicativos OAuth desconhecidos, um vetor que cresce em paralelo ao AiTM tradicional
- Novo método de autenticação registrado no perfil do usuário sem que ele tenha solicitado
Onde procurar: logs e ferramentas de monitoramento
Nenhum desses indicadores aparece sozinho numa única tela. Eles ficam espalhados entre o log de sign-in do Microsoft Entra ID, os alertas de replay de cookie do Microsoft Defender XDR via conectores do Defender for Cloud Apps, as detecções de risco do Entra ID Protection, as regras de caça a ameaças do Microsoft Sentinel e o log de auditoria do Exchange Online, onde fica registrada a criação de regras de caixa postal. Empresas sem um SIEM configurado tendem a descobrir esse tipo de comprometimento pelo efeito colateral, um cliente reclamando de um e-mail de cobrança estranho, e não pelo sinal técnico em si, que normalmente aparece dias antes.
Como se Proteger Contra Phishing que Burla o MFA?
Migrar para MFA resistente a phishing
A força de autenticação “Resistente a phishing” do Conditional Access no Entra ID aceita só métodos em que a prova de identidade fica vinculada ao hardware do usuário: chaves de segurança FIDO2, Windows Hello for Business, certificados de autenticação e passkeys. Um proxy AiTM não tem como repassar nenhum desses métodos, porque a verificação criptográfica acontece dentro do próprio dispositivo e nunca vira um código digitável que trafegue por uma tela intermediária. Na prática, o atacante fica sem nada para interceptar.
Conditional Access ajusta a exigência ao risco de cada acesso
Nem toda empresa consegue migrar todos os usuários para FIDO2 de uma vez, e não precisa. O Conditional Access permite escalonar a exigência: força de autenticação resistente a phishing para administradores e sistemas financeiros, políticas baseadas em risco de sign-in para o restante do quadro, compliance de dispositivo como pré-requisito de acesso e bloqueio de localizações fora do padrão operacional da empresa. A recomendação da própria Microsoft é implantar em modo report-only por sete a dez dias antes de ativar, justamente para medir o impacto sem travar ninguém no primeiro dia.
Token Protection: vincular o token ao dispositivo
O Token Protection ataca diretamente o passo do qual o AiTM depende, a portabilidade do token. Quando habilitado via Conditional Access, o token emitido carrega informações do dispositivo que o solicitou, e se esse mesmo token for copiado para outra máquina, como faz o atacante ao injetá-lo no próprio navegador, a validação falha porque o dispositivo apresentado não bate com o original. Tem limite, e convém conhecê-lo antes de prometer isso para a diretoria: o dispositivo precisa estar registrado ou ingressado no Entra, o cliente precisa ser compatível (hoje, basicamente Edge ou Chrome com a extensão do Entra) e a cobertura por aplicativo segue em expansão. Como está longe de cobrir 100% do ambiente de uma vez, o mais sensato é priorizar contas administrativas e de alto risco primeiro e tratar o resto do tenant como uma segunda onda.
Continuous Access Evaluation: revogação quase em tempo real
Sem Continuous Access Evaluation, um token de acesso comprometido continua válido até expirar, o que costuma levar de 60 a 90 minutos, tempo suficiente para o atacante já ter feito o que precisava fazer. Com CAE habilitado, Exchange Online, SharePoint Online e Teams passam a receber sinais críticos do Entra ID quase em tempo real: desativação de conta, troca de senha, mudança de localização de rede ou detecção de risco elevado. A latência típica de propagação fica em torno de até 15 minutos para eventos críticos, e a aplicação de política por localização de IP é instantânea. Como contrapartida, sessões que negociam CAE recebem tokens de vida mais longa, até 28 horas, porque a revogação deixa de depender apenas do tempo de expiração. A limitação relevante: contas de convidado (guest) não são suportadas pelo CAE hoje, e a cobertura inicial se concentra nesses três serviços do Microsoft 365, não no ecossistema inteiro de aplicativos de terceiros conectados ao tenant.
Bloquear o fluxo de código de dispositivo por padrão
Essa é a recomendação mais direta do próprio FBI no alerta sobre o Kali365: crie uma política de Conditional Access que bloqueie o device code flow para todos os usuários, com exceções limitadas e documentadas apenas para os processos de negócio que realmente dependem dele, como dispositivos de sala de conferência sem teclado. Antes de bloquear, convém auditar o uso atual desse fluxo, para não derrubar sem aviso alguma dependência legítima.
Treinamento de usuários: um papel real, mas limitado
Ensinar o time a desconfiar de qualquer solicitação de MFA que ele mesmo não tenha iniciado, principalmente sob pressão de urgência, reduz o sucesso das campanhas de massa mais rasas. Isso é real e vale manter. Mas contra um ataque direcionado, com página de login idêntica à real e domínio quase indistinguível do original, quem decide o resultado é o controle técnico configurado por trás, não a atenção do usuário no segundo em que ele clica. Treinamento continua tendo lugar no plano de segurança, só não é ele que vai segurar um AiTM bem feito.
Qual o Papel do Microsoft Defender e do Sentinel na Mitigação?
Microsoft Defender for Office 365
Safe Links reescreve URLs para verificação no momento do clique, não apenas no momento do envio, o que importa porque muitos domínios de phishing só ficam ativos por horas. Safe Attachments detona anexos suspeitos em sandbox antes de entregá-los. A proteção contra impersonation sinaliza remetentes que imitam executivos ou parceiros conhecidos. Nenhum desses três controles impede um AiTM em si, mas reduzem a chance de o e-mail inicial chegar até a caixa de entrada.
Microsoft Defender XDR
Para clientes que usam o Microsoft Edge com Entra ID, o Defender XDR correlaciona sinais do Defender for Cloud Apps para detectar tentativas de reprodução de cookie de sessão em aplicações do Microsoft 365. Ele também combina cliques suspeitos de URL detectados pelo Defender for Office 365 com sinais de sign-in de risco do Entra ID Protection para levantar alertas específicos de AiTM. Um ponto para calibrar expectativa: essa camada normalmente entra em ação depois que a sessão já foi comprometida, funcionando como resposta a um incidente em curso, mais do que como barreira que impede o clique inicial.
Microsoft Sentinel
Onde o Defender XDR correlaciona sinais dentro do ecossistema Microsoft, o Sentinel dá visão centralizada somando outras fontes, permite hunting ativo em busca de padrões que ainda não geraram alerta automático e executa playbooks de resposta, como revogar sessões e forçar reautenticação, sem depender de intervenção manual a cada incidente.
Passkeys e Identidade Sem Senha: Para Onde a Microsoft Está Indo?
Por que passkeys resistem nativamente a phishing
Uma passkey elimina o elemento que todo AiTM precisa capturar: um segredo compartilhado que trafega entre usuário e servidor. A chave privada nunca sai do dispositivo, e o desafio criptográfico só é resolvido quando o domínio de destino bate exatamente com o domínio para o qual a passkey foi registrada. Um proxy que finge ser login.microsoft-secure-portal.com, por mais convincente que pareça visualmente, simplesmente não recebe uma resposta válida, porque o protocolo verifica a origem antes mesmo de o usuário perceber que algo está errado.
Estratégia passwordless da Microsoft
Entra ID, FIDO2 e Windows Hello for Business formam o eixo da estratégia passwordless da Microsoft, com passkeys sendo tratadas hoje como o método de autenticação de maior força dentro do Conditional Access. A direção do produto é clara: reduzir progressivamente a dependência de senha e de códigos temporários como fator de autenticação primário.
O que passkeys não resolvem sozinhas
Migrar para passkeys se soma a Conditional Access, Token Protection e CAE, não os aposenta. Contas de serviço e aplicações que autenticam via API seguem fora do alcance de uma passkey, simplesmente porque não existe um humano ali para completar a biometria. E há um ponto que costuma passar despercebido no projeto: se o fluxo de recuperação de conta aceita um método mais fraco como alternativa quando o usuário perde o dispositivo, esse fallback vira a porta dos fundos que anula todo o ganho de segurança da passkey. Na prática, o caminho mais sensato é mapear as identidades privilegiadas primeiro, migrar essas contas, e só então expandir para o restante da base em ondas.
Checklist: Sua Empresa Está Preparada Contra Phishing que Burla o MFA?
Use esta lista como ponto de partida para uma conversa com o time de TI, não como um selo de aprovação automática. Cada item marcado reduz uma parte específica da superfície de ataque descrita neste artigo, não o risco inteiro de uma vez.
- MFA habilitado para 100% dos usuários, sem exceção informal para diretoria ou contas de serviço
- Conditional Access implementado, com pelo menos administradores exigindo força de autenticação resistente a phishing
- Autenticação legada bloqueada no tenant
- Device code flow bloqueado por padrão, com exceções documentadas e auditadas
- Token Protection habilitado para contas privilegiadas e apps compatíveis
- Continuous Access Evaluation ativo para Exchange Online, SharePoint Online e Teams
- Defender for Office 365 com Safe Links e Safe Attachments ativos
- Simulações de phishing recorrentes, tratadas como reforço, não como controle principal
- Revisão periódica de consentimentos OAuth concedidos por usuários a aplicativos de terceiros
- Plano de migração para passkeys ou FIDO2 mapeado, começando pelas contas de maior privilégio
Conclusão
Os 35 mil usuários comprometidos na campanha de abril de 2026 tinham MFA funcionando exatamente como deveria, provando identidade no momento do login. O ataque que os pegou foi desenhado para agir no minuto seguinte a esse, exatamente quando a maioria das empresas para de prestar atenção. É essa a linha que separa quem ainda trata SMS e push notification como suficientes de quem já enxerga a sessão pós-login como parte da superfície que precisa ser protegida.
Nenhum desses controles resolve isso sozinho. Token Protection sem Conditional Access por trás dele deixa buracos abertos, passkeys implantadas sem revisar o fluxo de recuperação de conta mantêm uma porta mais fraca destrancada em algum canto do processo, e CAE sem cobertura nos aplicativos certos protege só uma fatia do ambiente. O que muda o resultado de uma tentativa de AiTM, de conta comprometida para tentativa registrada e barrada a tempo, é essa combinação funcionando junto: identidade resistente a phishing, contexto de acesso avaliado continuamente e monitoramento ativo via Defender e Sentinel.
A InfoB é parceira certificada Microsoft e já ajudou empresas a sair de um MFA configurado no padrão para uma arquitetura de Conditional Access, Token Protection e CAE ajustada à realidade de cada operação. Se esse é o próximo passo para a sua empresa, converse com o time da InfoB e comece pelo diagnóstico da sua exposição atual.
Perguntas Frequentes
O MFA pode ser burlado?
Sim, mas não do jeito que a maioria imagina. Nenhum kit atual quebra o segundo fator em si, ele deixa o usuário completar o MFA normalmente e rouba o token gerado logo depois. Chaves FIDO2 e passkeys fecham essa porta porque não geram nenhum segredo copiável no meio do caminho.
O Microsoft 365 está vulnerável a esse tipo de ataque?
Está, se o MFA configurado for só o tradicional, código, push ou SMS, e isso vale para empresas de qualquer porte. O fator decisivo é a configuração de Conditional Access e Entra ID por trás do tenant, independentemente do tamanho da empresa.
Passkeys substituem o MFA?
Elas são a próxima geração do MFA, não um item extra na lista. Uma passkey já embute posse de dispositivo e biometria num único fator, e a Microsoft trata isso hoje como o nível mais alto de força dentro do Conditional Access. O ponto de atenção fica fora da passkey em si: é o fluxo de recuperação de conta, que precisa ser revisado junto.
Como proteger contas do Microsoft 365 contra MFA bypass?
A defesa aqui funciona em pilha, não como controle único: MFA resistente a phishing nas contas críticas, Conditional Access com Token Protection nos apps compatíveis, Continuous Access Evaluation ligado, device code flow bloqueado por padrão e monitoramento ativo via Entra ID, Defender XDR e Sentinel. Tirar qualquer uma dessas camadas da equação abre uma brecha específica para o tipo de ataque descrito neste artigo.
O Microsoft Defender detecta ataques AiTM?
Detecta parte do ataque, principalmente por correlação entre Defender for Cloud Apps e Defender for Office 365 dentro do Defender XDR. O ponto cego é o timing: a maioria dos alertas dispara depois que a sessão já foi sequestrada, então essa camada funciona bem como resposta a um incidente em curso, não como o que impede o primeiro acesso indevido. Ela entrega mais valor combinada com os controles de identidade deste artigo do que sozinha.