O antivírus não disparou. O firewall não bloqueou. O MFA foi concluído com sucesso. E ainda assim, a conta estava comprometida — e o atacante tinha acesso total ao e-mail, aos arquivos e ao calendário do executivo há três semanas. Esse é o cenário que equipes de segurança de todo o mundo estão enfrentando em 2026: ataques que não usam malware, não exploram vulnerabilidades de software e não precisam roubar senhas — porque usam credenciais e tokens legítimos do próprio Microsoft 365 para entrar, persistir e agir como se fossem o próprio usuário. Em maio de 2026, o FBI emitiu alerta formal sobre a plataforma Kali365 — um serviço de Phishing-as-a-Service distribuído no Telegram que captura tokens OAuth do M365 e burla o MFA sem precisar das credenciais do usuário. Mais de 340 organizações em cinco países já foram comprometidas por campanhas que usam essa técnica só nos últimos meses. A pergunta que qualquer gestor de TI precisa responder agora não é “temos antivírus?” — é “conseguiríamos detectar se um atacante estivesse dentro da nossa conta do M365 agora?”

O que são ataques com contas legítimas — e por que são mais perigosos que malware

Ataques com contas legítimas são ameaças que utilizam credenciais reais, tokens de autenticação válidos ou permissões de aplicativos autorizados para executar ações maliciosas — sem acionar os mecanismos tradicionais de segurança.

A diferença fundamental em relação a um ataque de malware é que nada “errado” é instalado: o atacante simplesmente entra como se fosse o usuário legítimo. Pode envolver:

  • Contas comprometidas via credential theft — senha roubada por phishing ou vazamento e usada diretamente
  • Token hijacking — roubo de tokens de sessão ou OAuth que concedem acesso persistente sem precisar de senha ou MFA
  • OAuth abuse — indução do usuário a autorizar um aplicativo malicioso que recebe permissões sobre a conta M365
  • Session hijacking via AiTM — interceptação da sessão autenticada em ataques Adversary-in-the-Middle que capturam os cookies após o MFA ser concluído

Por que esses ataques passam completamente despercebidos

Ferramentas de segurança tradicionais foram projetadas para detectar o que é estranho no ambiente: um arquivo malicioso, um processo desconhecido, um IP bloqueado por reputação. Um atacante usando um token OAuth válido do Microsoft 365 não instala nada, não conecta de um IP malicioso catalogado e não executa nenhum processo suspeito — ele usa as APIs legítimas do Microsoft 365 exatamente da forma que elas foram projetadas para ser usadas. O resultado é invisibilidade quase total para antivírus, firewall, filtragem de e-mail e qualquer ferramenta que não faça análise comportamental de identidade.

O que mudou em 2025–2026: por que esses ataques explodiram

De técnica de espionagem estatal a commodity criminal

O abuso de OAuth device code para comprometer contas Microsoft 365 não é uma técnica nova — mas até meados de 2025, era usada predominantemente por grupos de espionagem estatal patrocinados por Rússia e China, como APT29 e UNK_AcademicFlare, em ataques altamente direcionados. A mudança que 2025-2026 trouxe foi a democratização da técnica: plataformas como EvilTokens e Kali365 transformaram o device code phishing em um serviço por assinatura acessível a qualquer criminoso.

O Kali365, alertado pelo FBI em maio de 2026, permite que atacantes menos técnicos acessem tokens OAuth do Microsoft 365 e burlem o MFA sem as credenciais do usuário. A plataforma oferece iscas de phishing geradas por IA, templates automatizados de campanha e dashboards de rastreamento de vítimas em tempo real. Distribuída via Telegram, a plataforma reduziu a barreira técnica para zero — qualquer pessoa com cartão de crédito pode lançar uma campanha sofisticada de comprometimento de contas M365.

A Proofpoint observou campanhas generalizadas usando esses fluxos de ataque desde setembro de 2025, o que foi altamente incomum. Antes eram ataques pontuais e direcionados; agora são campanhas em massa atingindo simultaneamente setores de construção, saúde, manufatura, serviços financeiros, jurídico e governo.

IA acelerando a escala e a personalização dos ataques

A IA entrou como multiplicador de eficiência do lado ofensivo. Plataformas como Kali365 usam modelos de linguagem para gerar iscas de phishing altamente personalizadas — e-mails que mencionam o nome da empresa-alvo, referenciam o setor e usam o tom correto para o país e idioma da vítima. O que antes exigia um operador humano pesquisando cada alvo manualmente agora é automatizado: a plataforma pesquisa, gera o e-mail e dispara em escala sem intervenção manual. O resultado é que campanhas que em 2023 atingiam dezenas de alvos hoje atingem milhares, com o mesmo nível de personalização.

Movimento lateral em segundos após o comprometimento inicial

Tokens OAuth roubados concedem acesso total de leitura, escrita e envio a e-mails, calendários, arquivos e até funções administrativas. Uma vez que o atacante tem o token, o movimento lateral acontece em tempo real: pode acessar todos os e-mails do usuário, encaminhar conversas sensíveis, enviar e-mails fingindo ser o executivo comprometido para outros funcionários, acessar SharePoint, OneDrive e Teams — e fazer tudo isso dentro do ambiente M365 legítimo, usando as APIs oficiais da Microsoft, sem levantar qualquer alerta nos sistemas de monitoramento tradicionais.

Como funciona o ataque: o lifecycle do comprometimento de identidade no M365

Etapa 1 — Comprometimento de credenciais ou captura de token

O ponto de entrada mais comum em 2026 é o device code phishing — e sua insidiosidade está no fato de usar a própria infraestrutura legítima da Microsoft. O ataque funciona assim:

  1. O atacante registra um aplicativo OAuth malicioso no Microsoft 365 e gera um device code único
  2. Uma isca de phishing chega à vítima — e-mail de bônus salarial, convite de reunião, alerta de segurança, notificação do DocuSign — com instruções para “completar a autenticação segura” inserindo um código
  3. A vítima é redirecionada para microsoft.com/devicelogin — o portal legítimo da Microsoft — e insere o código fornecido pelo atacante
  4. A vítima completa normalmente o processo de autenticação, incluindo o MFA
  5. A Microsoft emite tokens válidos de acesso e refresh para o aplicativo controlado pelo atacante, que os captura em tempo real

O resultado: o atacante tem tokens válidos que concedem acesso total à conta M365 — sem nunca ter visto a senha, sem ter tocado no MFA e sem ter instalado nada no dispositivo da vítima. Os tokens de refresh têm vida longa e permanecem válidos até serem explicitamente revogados. Uma empresa que não monitora ativamente o uso de tokens pode ter um comprometimento ativo por semanas ou meses sem saber.

Etapa 2 — Persistência silenciosa

Uma vez dentro da conta M365 com tokens válidos, atacantes sofisticados não agem imediatamente — primeiro estabelecem persistência para garantir acesso contínuo mesmo que a senha seja trocada:

  • Criação de regras de encaminhamento de e-mail — toda a correspondência do executivo comprometido é silenciosamente copiada para um endereço externo controlado pelo atacante
  • Registro de aplicativos OAuth adicionais — novos apps com permissões amplas são registrados na conta, criando múltiplos pontos de acesso que persistem mesmo após troca de senha
  • Modificação de métodos de autenticação — em casos com acesso privilegiado, adicionar dispositivos ou métodos de autenticação que o atacante controla
  • Criação de contas de administrador secundárias — em ambientes com privilégios elevados, criar contas backdoor que sobrevivem à contenção do acesso inicial

Etapa 3 — Escala e impacto

Com persistência estabelecida e acesso total à conta, o atacante executa o objetivo da campanha — que varia conforme o perfil do grupo:

  • Grupos financeiramente motivados: Business Email Compromise (BEC) — e-mails enviados fingindo ser o executivo comprometido para autorizar transferências, alterar dados bancários de fornecedores ou solicitar cartões-presente; roubo de dados para extorsão; acesso a informações de clientes para fraudes
  • Grupos de espionagem estatal (Rússia, China): exfiltração silenciosa de comunicações estratégicas, contratos, propriedade intelectual e dados de relacionamentos com parceiros governamentais; acesso persistente para inteligência de longo prazo
  • Ataques de supply chain via M365: usar a conta comprometida para enviar phishing para contatos da vítima — com altíssima taxa de clique porque vem de um endereço real e confiável da organização

Casos reais e campanhas ativas em 2026

Kali365: o FBI alerta em maio de 2026

Em maio de 2026, o FBI emitiu alerta formal sobre o Kali365 — uma plataforma de phishing-as-a-service que permite a hackers acessar tokens OAuth do Microsoft 365 e burlar o MFA sem as credenciais do usuário. A assinatura da plataforma serve como ponto de entrada para atacantes menos sofisticados, oferecendo iscas geradas por IA, dashboards de rastreamento de vítimas, templates automatizados e outras capacidades. Primeiro observado em abril de 2026 e distribuído via Telegram, o Kali365 representa a fase mais madura da democratização do device code phishing como serviço.

EvilTokens e a campanha Railway: 340+ organizações em março de 2026

Em fevereiro de 2026, pesquisadores da Huntress detectaram uma campanha que comprometeu mais de 340 organizações em cinco países. A campanha usou a plataforma Railway — originalmente um serviço de hospedagem para desenvolvimento de software — como infraestrutura de captura de credenciais. A atividade atingiu setores de construção, ONGs, imóveis, manufatura, serviços financeiros, saúde, jurídico e governo. O que tornou essa campanha incomum não foram apenas as técnicas de device code phishing envolvidas, mas a variedade: iscas de licitação de construção, geração de código de página de destino, impersonação de DocuSign, notificações de correio de voz e abuso de páginas do Microsoft Forms atingindo o mesmo grupo de vítimas através da mesma infraestrutura Railway.

Grupos alinhados à Rússia rastreados como Storm-2372, APT29, UTA0304, UTA0307 e UNK_AcademicFlare foram atribuídos a esses ataques. A presença de grupos de espionagem estatal nas mesmas campanhas que grupos financeiramente motivados sinaliza que a técnica atingiu maturidade operacional suficiente para substituir vetores de ataque mais tradicionais.

UNK_AcademicFlare: espionagem com construção de relacionamento

Um grupo suspeito de alinhamento russo rastreado como UNK_AcademicFlare conduz ataques de device code phishing desde pelo menos setembro de 2025. O ator usa endereços de e-mail comprometidos de organizações governamentais e militares para construir relacionamento com as vítimas antes de compartilhar links que falsificam o OneDrive, levando as vítimas a um fluxo de device code phishing. A atividade visa principalmente setores governamentais, acadêmicos, think tanks e de transporte nos EUA e Europa. O que diferencia esse grupo é a paciência: semanas ou meses de comunicação aparentemente inocente antes de lançar o ataque — tornando a detecção por análise de e-mail individual praticamente impossível sem contexto comportamental.

Por que sua empresa provavelmente está vulnerável

As três falhas de segurança mais comuns em ambientes M365

A maioria das empresas que operam com Microsoft 365 tem pelo menos uma dessas lacunas — e cada uma é suficiente para tornar o ambiente vulnerável a ataques baseados em identidade:

  • MFA básico sem proteção a phishing — MFA por SMS ou app autenticador (TOTP) não protege contra device code phishing e ataques AiTM. O usuário completa o MFA normalmente e ainda assim a conta é comprometida. Apenas MFA resistente a phishing — FIDO2, passkeys ou Windows Hello — oferece proteção real contra essas técnicas. A maioria das empresas brasileiras não chegou a esse nível
  • Falta de monitoramento comportamental de identidade — sem UEBA (User and Entity Behavior Analytics) ou Microsoft Entra Identity Protection ativo com políticas de resposta automática, tokens sendo usados de localizações anômalas, em horários incomuns ou com padrões de acesso atípicos simplesmente não geram alertas
  • Excesso de permissões e ausência de governança de aplicativos OAuth — a maioria dos ambientes M365 tem dezenas de aplicativos OAuth com permissões amplas que usuários autorizaram ao longo dos anos. Sem inventário e revisão periódica, aplicativos comprometidos ou maliciosos persistem indefinidamente no ambiente. O Entra Permissions Management e as políticas de App Consent do Entra ID podem controlar isso — mas raramente estão configurados

Os ambientes mais expostos

Alguns perfis de ambiente têm exposição maior pelo próprio modelo de uso:

  • Empresas com Microsoft 365 sem SOC ou MDR ativo — dependem exclusivamente das proteções padrão do M365, que bloqueiam malware e spam mas não detectam abuso de tokens legítimos
  • Ambientes híbridos e multicloud — Active Directory on-premises sincronizado com Entra ID cria complexidade de permissões que amplifica o impacto de uma conta comprometida; acesso a sistemas on-premises via conta cloud comprometida é um vetor de movimento lateral frequentemente subestimado
  • Alto uso de SaaS integrado ao M365 — cada integração SaaS que usa OAuth do M365 é um ponto potencial de comprometimento; o abuso de tokens de integrações como Salesforce, HubSpot e plataformas de colaboração foi documentado em múltiplas campanhas recentes

Para entender o impacto financeiro que um comprometimento de identidade como esses pode gerar, confira nosso artigo sobre vazamentos de dados em 2026 — custo médio de R$ 7,19 milhões por incidente.

Como detectar ataques baseados em identidade no M365

Sinais técnicos que indicam comprometimento em andamento

Ataques de identidade deixam rastros — mas apenas em logs que precisam ser ativamente monitorados e correlacionados. Os principais sinais de comprometimento incluem:

  • Autenticações de localizações geográficas incomuns — especialmente quando combinadas com o login legítimo do usuário na mesma sessão ou em janelas curtas de tempo (“impossible travel”: login em São Paulo às 9h e autenticação de token em Kiev às 10h)
  • Tokens OAuth de aplicativos não reconhecidos ou recém-registrados — presença de aplicativos com permissões amplas (leitura de e-mail, envio de e-mail, acesso a arquivos) que não estavam no ambiente há 30 dias
  • Criação de regras de encaminhamento de e-mail — especialmente regras que encaminham para domínios externos, criadas em horários fora do padrão do usuário ou via interface diferente da habitual
  • Volume anômalo de acesso a e-mails via API — scripts ou aplicativos acessando centenas ou milhares de mensagens em sequência, típico de exfiltração automatizada de histórico de e-mail
  • Alterações em métodos de autenticação — adição de dispositivos MFA ou endereços de recuperação que o usuário não reconhece
  • Acesso a dados fora do padrão histórico do usuário — um analista financeiro acessando repositórios de código; um executivo de vendas acessando documentos de RH

Por que ferramentas tradicionais são inadequadas para detectar isso

O treinamento tradicional de conscientização sobre phishing enfatiza verificar a legitimidade das URLs. Essa abordagem não endereça efetivamente o device code phishing, onde os usuários são instruídos a inserir um código no portal legítimo da Microsoft. O antivírus não detecta porque nenhum arquivo malicioso é executado. O firewall não bloqueia porque as conexões vão para domínios Microsoft legítimos. O filtro de e-mail não sinaliza porque as iscas vêm de endereços comprometidos de organizações reais.

A detecção eficaz exige UEBA (User and Entity Behavior Analytics) — análise contínua do padrão comportamental de cada usuário e alerta automático quando o comportamento desvia do baseline histórico. No ecossistema Microsoft, o Microsoft Entra Identity Protection oferece essa capacidade nativamente, com políticas que podem bloquear automaticamente sessões com risco elevado. Para ambientes que precisam de correlação entre múltiplas fontes, o Microsoft Sentinel adiciona visibilidade cross-platform essencial.

Como se proteger: framework prático para 2026

1. Zero Trust como arquitetura central — não como produto

A proteção eficaz contra ataques de identidade começa com a adoção real do modelo Zero Trust: nenhum usuário, dispositivo ou token é confiável por padrão, e todo acesso é verificado continuamente com base em múltiplos fatores de contexto. Isso significa que um token OAuth válido de uma localização geográfica incomum, em um horário atípico, acessando dados que o usuário nunca acessou antes, deve gerar um alerta ou ser bloqueado — independentemente de o token ser tecnicamente válido. Para entender como o portfólio Microsoft Security implementa Zero Trust de ponta a ponta, confira nosso artigo sobre o que é Microsoft Security.

2. MFA resistente a phishing (FIDO2 e passkeys)

A conclusão mais importante que as campanhas de 2025-2026 entregam é que o MFA tradicional não é suficiente. SMS, TOTP (app autenticador) e notificações push foram todos contornados por device code phishing, AiTM e SIM swapping. A proteção real começa com MFA resistente a phishing:

  • FIDO2 / chaves de segurança física (YubiKey, Titan Security Key) — autenticação vinculada ao domínio da origem, impossível de ser usada em um portal phishing mesmo que o usuário seja enganado
  • Passkeys via Windows Hello ou autenticador de plataforma — biometria vinculada ao dispositivo, sem código transferível
  • Certificate-based authentication — autenticação via certificado digital emitido pela organização, não transferível

Para PMEs que não conseguem migrar todos os usuários imediatamente para FIDO2, a prioridade deve ser: MFA resistente para todos os administradores e para usuários com acesso a dados sensíveis ou funções financeiras — onde o risco de BEC é mais alto.

3. Conditional Access com bloqueio do fluxo de Device Code

A Proofpoint recomenda que organizações criem políticas de Acesso Condicional para bloquear o fluxo de device code completamente ou implementar listas de permissão para usuários e intervalos de IP aprovados. No Microsoft Entra ID, é possível criar uma política de Conditional Access que bloqueia o fluxo de autenticação de device code para todos os usuários ou restringe quais aplicativos podem usar esse fluxo — eliminando o vetor principal das campanhas ativas. Para ambientes onde dispositivos sem navegador (Smart TVs, consoles, IoT corporativo) usam legitimamente o device code flow, a política pode ser aplicada seletivamente por grupo de usuário.

4. Monitoramento contínuo de identidade (MDR / SOC)

Mesmo com as proteções técnicas acima, a detecção comportamental 24/7 é o que fecha a janela de exposição quando um ataque bem-executado consegue passar pelas camadas preventivas. Um serviço de MDR ativo monitora os logs do Microsoft Entra e do Defender em tempo real, detecta anomalias de comportamento de identidade e responde — revogando tokens, bloqueando sessões e iniciando investigação — dentro da janela de contenção. Para entender a diferença entre MDR gerenciado e SOC interno nesse contexto, confira nossa análise completa sobre Sophos MDR vs. SOC Interno.

5. Hardening do ambiente M365: governança de OAuth e permissões

Além das proteções de autenticação, o hardening do ambiente M365 reduz o raio de dano de qualquer comprometimento de identidade:

  • Inventário e revisão de aplicativos OAuth — identificar todos os apps com permissões de acesso a dados da organização e revogar os não reconhecidos, desnecessários ou de alto risco. No portal de administração do Entra, em Enterprise Applications
  • Políticas de App Consent — configurar que usuários não possam autorizar aplicativos de terceiros sem aprovação administrativa. Qualquer novo app OAuth deve ser aprovado antes de receber permissões
  • Auditoria de regras de e-mail — verificar regularmente se há regras de encaminhamento ativas nas caixas de e-mail dos usuários, especialmente de executivos e usuários com acesso a informações financeiras
  • Revisão de permissões de administradores — aplicar privilégio mínimo: eliminar contas com Global Admin permanente em favor de Privileged Identity Management (PIM) com elevação just-in-time
  • Monitoramento de Sign-in Logs no Entra — configurar alertas para autenticações de alto risco, impossible travel e uso de tokens de aplicativos não monitorados

O papel da IA: o mesmo recurso que ataca também defende

IA no ataque: escala e evasão

Plataformas como Kali365 usam IA generativa para criar iscas de phishing indistinguíveis de comunicações legítimas — personalizadas por empresa, cargo, idioma e contexto cultural. A IA também é usada para adaptar as campanhas em tempo real: se uma isca tem baixa taxa de clique, o modelo gera variações automaticamente. Técnicas anti-análise e anti-bot detectadas nas campanhas de 2026 sugerem que IA também está sendo usada para identificar e evadir sandboxes de análise de segurança.

IA na defesa: detecção comportamental que escala

O Microsoft Entra Identity Protection usa modelos de machine learning treinados em sinais de bilhões de autenticações diárias para avaliar o risco de cada sign-in em tempo real. Um token sendo usado de uma localização incomum, com um User Agent atípico, acessando dados fora do padrão histórico — o modelo calcula um score de risco e pode bloquear automaticamente a sessão ou exigir reautenticação forte antes de permitir o acesso. O Security Copilot, por sua vez, usa IA generativa para acelerar a investigação de incidentes de identidade: em vez de analistas passando horas correlacionando logs manualmente, o Copilot produz um resumo do incidente com contexto completo em minutos.

O futuro: ataques sem malware (malwareless attacks) como novo padrão

A tendência que os dados de 2025-2026 confirmam é a transição acelerada do cibercrime para ataques que operam completamente dentro de ambientes legítimos, sem malware, sem exploração de vulnerabilidades de software e sem tráfego de rede facilmente categorizável como malicioso. A Proofpoint e o CrowdStrike documentaram consistentemente que a maioria das intrusões bem-sucedidas em 2025 envolveu acesso inicial via credenciais comprometidas ou abuso de ferramentas legítimas — não exploração de CVEs.

Essa tendência tem uma implicação direta para investimentos em segurança: o endpoint protection clássico e o firewall de perímetro estão deixando de ser a linha de defesa mais relevante. O que define a resiliência de um ambiente em 2026 é a qualidade do monitoramento de identidade, a maturidade das políticas de acesso condicional e a velocidade de detecção e resposta a comportamentos anômalos. Isso alinha com o que abordamos no artigo sobre as principais vulnerabilidades de cibersegurança em 2026: o perímetro morreu, e a identidade é o novo campo de batalha.

Checklist: sua empresa está exposta a ataques de identidade no M365?

Responda com honestidade. Cada “não” ou “não sei” é uma janela de exposição ativa:

  • ☐ MFA resistente a phishing (FIDO2 / passkeys) para administradores? MFA por SMS ou app autenticador não protege contra device code phishing
  • ☐ Conditional Access com bloqueio do fluxo de Device Code configurado? Sem essa política, o vetor mais ativo de 2026 está aberto
  • ☐ Inventário de aplicativos OAuth revisado nos últimos 90 dias? Apps com permissões amplas e não reconhecidos são backdoors persistentes
  • ☐ Microsoft Entra Identity Protection ativo com políticas de resposta automática? Alertas sem ação automática dependem de analista disponível para agir a tempo
  • ☐ Monitoramento de regras de encaminhamento de e-mail para domínios externos? Sinal mais comum de conta comprometida em uso ativo
  • ☐ Sign-in Logs do Entra exportados para SIEM ou MDR com alertas configurados? Logs locais sem monitoramento ativo não detectam nada
  • ☐ Impossible travel detectado e com resposta automática? Autenticações de localizações geograficamente impossíveis no mesmo intervalo de tempo
  • ☐ Usuários com Global Admin têm PIM (Privileged Identity Management) ativo? Acesso permanente de administrador é o prêmio máximo para qualquer atacante que compromete uma conta

Se você respondeu “não” a três ou mais itens acima, seu ambiente M365 tem lacunas de segurança de identidade que as campanhas ativas de 2026 — Kali365, EvilTokens, grupos alinhados à Rússia — exploram ativamente.

Como a InfoB pode ajudar: Assessment de Segurança do Microsoft 365

A InfoB, como parceira certificada Microsoft com mais de 15 anos de atuação no mercado brasileiro, oferece um Assessment de Segurança do Microsoft 365 estruturado para identificar e quantificar as lacunas de identidade e acesso no seu ambiente atual:

  • Análise de identidade — revisão das políticas de MFA, Conditional Access, e Identity Protection; identificação de usuários sem proteção adequada e contas com privilégios excessivos
  • Revisão de permissões OAuth — inventário completo de aplicativos com acesso ao ambiente M365, identificação de apps de risco e recomendação de revogações
  • Auditoria de Sign-in Logs — análise de autenticações recentes para identificar padrões anômalos que possam indicar comprometimento ativo ou tentativas de ataque em andamento
  • Revisão de configurações de e-mail — verificação de regras de encaminhamento, delegates e permissões atípicas em caixas de e-mail prioritárias
  • Plano de correção priorizado — roadmap de hardening com ações ordenadas por impacto e custo de implementação, alinhado ao perfil e orçamento da empresa

O assessment é conduzido remotamente, em até 48 horas, e entrega um relatório executivo com os riscos identificados e as ações imediatas recomendadas.

Descubra em 48h se sua empresa está vulnerável a ataques invisíveis no M365

Perguntas frequentes sobre ataques com contas legítimas do Microsoft 365

Como hackers invadem contas do Microsoft 365 sem roubar senha?

A técnica mais comum em 2026 é o device code phishing com abuso de OAuth: o atacante engana o usuário para inserir um código no portal legítimo da Microsoft (microsoft.com/devicelogin), o que autoriza um aplicativo malicioso a acessar a conta M365. Isso gera tokens de acesso válidos — sem que o atacante precise da senha ou precise burlar o MFA diretamente. O token concede acesso persistente a e-mail, arquivos, calendário e funções administrativas enquanto não for explicitamente revogado.

O MFA protege contra ataques de device code phishing?

O MFA tradicional — SMS, app autenticador TOTP, notificações push — não protege contra device code phishing. Nessa técnica, o usuário completa o MFA normalmente, mas no processo autoriza um aplicativo malicioso. A proteção eficaz exige MFA resistente a phishing: FIDO2 (chaves de segurança física), passkeys via Windows Hello, ou certificate-based authentication — métodos vinculados ao dispositivo e ao domínio de origem, que não podem ser transferidos ou usados em fluxos de autenticação controlados pelo atacante.

O que é Kali365?

Kali365 é uma plataforma de Phishing-as-a-Service (PhaaS) alertada pelo FBI em maio de 2026, distribuída via Telegram. Permite que atacantes sem conhecimento técnico avançado capturem tokens OAuth do Microsoft 365 e obtenham acesso persistente a ambientes M365 sem as credenciais do usuário. Oferece iscas de phishing geradas por IA, templates automatizados de campanha, dashboards de rastreamento de vítimas em tempo real e captura de tokens OAuth — democratizando ataques sofisticados de comprometimento de contas M365.

O que é um ataque baseado em identidade?

Um ataque baseado em identidade usa credenciais legítimas, tokens de autenticação ou permissões de aplicativos para acessar sistemas e dados — sem instalar malware, sem explorar vulnerabilidades de software e sem acionar alertas de segurança tradicionais. Em vez de “invadir”, o atacante “entra” como um usuário autorizado. Em 2026, esses ataques representam a categoria de mais rápido crescimento no cenário de ameaças corporativas, com grupos financeiramente motivados e de espionagem estatal convergindo para o mesmo vetor: as contas Microsoft 365 de usuários reais.