Alerta FBI Microsoft 365: golpe Kali365 explicado

Em 21 de maio de 2026, o FBI publicou o alerta I-052126-PSA confirmando o que muitos times de segurança no Brasil já suspeitavam: o alerta FBI Microsoft 365 descreve uma plataforma de phishing-as-a-service chamada Kali365, ativa desde abril, capaz de sequestrar tokens OAuth de Outlook, OneDrive e Teams sem precisar da sua senha e sem disparar o MFA. Se a sua empresa usa Microsoft 365, este post explica como o golpe funciona e o que ajustar no Entra ID ainda esta semana.

TL;DR

• O FBI emitiu em 21/05/2026 o alerta I-052126-PSA sobre a plataforma Kali365, vendida no Telegram desde abril de 2026.
• O ataque usa device code phishing para capturar tokens OAuth — burla a maioria das configurações de MFA.
• Outlook, OneDrive e Teams são os serviços alvo. O invasor opera como o usuário até o refresh token expirar.
• A mitigação principal é bloquear o device code flow via Conditional Access e revisar contas de break-glass.
• Empresas brasileiras com Entra ID sem políticas maduras estão especialmente expostas — o kit já vem com iscas em português geradas por IA.

O que diz o alerta FBI sobre Microsoft 365 e a plataforma Kali365

O alerta FBI Microsoft 365 publicado pelo Internet Crime Complaint Center (IC3) é categórico: a plataforma Kali365 começou a ser observada em campanhas reais em abril de 2026 e, em pouco mais de um mês, já bate centenas de organizações como vítimas. O kit é vendido como serviço (PhaaS — phishing-as-a-service) em canais de Telegram, com painéis em tempo real, geração automática de e-mails com IA e relatórios de tracking por alvo.

A escolha por Microsoft 365 não é acaso. O ecossistema concentra três produtos que, juntos, formam o sistema nervoso de boa parte das empresas: caixa de e-mail (Outlook), armazenamento e colaboração (OneDrive) e comunicação interna (Teams). Quem entra em um, entra nos três. E ao contrário do que muitos administradores assumiam, o alerta FBI Microsoft 365 deixa claro que não é só o varejo do crime cibernético que está usando: o kit é desenhado para baixar a barreira de entrada e permitir que operadores menos técnicos rodem campanhas inteiras com poucos cliques.

O comunicado oficial está em ic3.gov/PSA/2026/PSA260521{target="_blank"} e referencia o número I-052126-PSA. Se você atua com TI corporativa ou governança no Brasil, vale anexar essa referência no seu próximo relatório de risco.

Como o Kali365 funciona: device code phishing em 4 passos

Diferente do phishing clássico — que clona páginas de login e tenta roubar a senha —, o Kali365 explora um fluxo legítimo da Microsoft chamado device code authentication. É o mesmo fluxo usado quando você loga em uma smart TV ou em um console: o dispositivo mostra um código curto e pede que você o digite em uma página oficial da Microsoft.

Passo 1 — A isca chega por e-mail ou Teams

A vítima recebe uma notificação convincente: "um documento financeiro foi compartilhado com você", "convite para reunião de revisão Q2" ou "auditoria de conformidade pendente". O texto é gerado por IA, adaptado ao idioma e ao contexto do alvo, e geralmente vem de um domínio look-alike ou de uma conta legítima já comprometida.

Passo 2 — O usuário entra no portal oficial da Microsoft

Aqui mora a sofisticação: o link da isca aponta para microsoft.com/devicelogin — uma página real, com certificado válido, sem nenhuma anomalia visual. A vítima é instruída a digitar um código curto (oito dígitos) supostamente para "validar o documento" ou "entrar na reunião".

Passo 3 — O token OAuth é capturado

O código digitado pertence a uma sessão iniciada pelo atacante. Quando a vítima conclui o login (inclusive passando pelo MFA, porque sim, é a Microsoft de verdade), a Microsoft emite um par access token + refresh token vinculado ao "dispositivo" controlado pelo invasor. O Kali365 captura esse token via API.

Passo 4 — Acesso persistente sem nova senha

Com o refresh token em mãos, o invasor consegue gerar novos access tokens por dias ou semanas, sem novo desafio de MFA. É como se ele tivesse uma cópia das suas chaves, mas o sistema de fechadura nem percebe — o alerta FBI Microsoft 365 chama isso de "long-term access" e estima sobrevida do acesso enquanto o refresh token estiver válido (até 90 dias por padrão no Entra ID).

Por que o MFA tradicional não te protege desta vez

Muito administrador respira aliviado quando vê MFA habilitado para toda a tenant — e essa confiança é exatamente o que o Kali365 explora. O MFA tradicional valida que alguém legítimo está autenticando; não valida para qual dispositivo o token vai ser emitido.

Quando o usuário entra no microsoft.com/devicelogin e cumpre todos os fatores, ele aprova a sessão do invasor sem perceber. Não há "página fake" para detectar, não há erro de certificado, não há domínio estranho. Filtros de e-mail baseados em URL malicioso também ficam cegos, porque o link é, literalmente, da Microsoft.

A única defesa estrutural é uma combinação de:

• Conditional Access bloqueando ou restringindo o device code flow (a primeira recomendação do FBI no PSA).
• Chaves FIDO2 com binding ao dispositivo (passkeys phishing-resistant).
• Sign-in risk policies do Entra ID Premium P2 com bloqueio em risco alto.
• Token Protection (em preview no Entra ID), que vincula o token ao dispositivo de origem.

Para times que ainda dependem só de TOTP ou SMS, o alerta FBI Microsoft 365 é um aviso direto: o piso de segurança subiu — e quem ficar abaixo dele paga caro.

Phishing tradicional vs ataque com Kali365

Aspecto	Phishing tradicional	Kali365 (device code)
Página de login	Clonada, em domínio fake	Real (microsoft.com)
O que é roubado	Senha + segundo fator	Token OAuth (access + refresh)
MFA por SMS protege?	Frequentemente, sim	Não
MFA por app/TOTP protege?	Sim, na maioria	Não
Chave FIDO2 protege?	Sim	Sim, com token binding
Tempo de persistência	Curto (até troca de senha)	Longo (vida do refresh token, até 90 dias)
Detecção por antivírus	Média	Praticamente nula
Detecção por filtro de URL	Boa	Quase nula (URL é legítima)
Sinal no SIEM	Login em horário/lugar atípico	Sessão de dispositivo desconhecido

A leitura honesta dessa tabela é incômoda: a maior parte das defesas que as empresas brasileiras compraram nos últimos cinco anos foi pensada contra o phishing da coluna da esquerda. O Kali365 mora na coluna da direita.

O que o invasor consegue fazer dentro do Outlook, OneDrive e Teams

Quando o token cai em mãos hostis, o estrago vai muito além de "ler e-mails". O alerta FBI Microsoft 365 lista padrões observados em vítimas reais — e todos cabem dentro do que um usuário comum poderia fazer, o que dificulta a detecção.

• Outlook: criação de regras de inbox que encaminham e apagam silenciosamente — clássico para fraudes BEC (Business Email Compromise) e desvio de boletos. O invasor monitora trocas com fornecedores e injeta uma fatura com PIX alterado no momento certo.
• OneDrive: download em massa de bibliotecas inteiras (contratos, planilhas financeiras, dados de clientes), plantio de arquivos com macro maliciosa em pastas compartilhadas com a equipe e abuso da feature de compartilhamento "Anyone with the link" para extração discreta.
• Teams: postagem como o usuário comprometido em canais internos, criação de reuniões com convidados externos para reconhecimento e roubo de dados de chat (que muitas vezes contêm credenciais e segredos compartilhados de forma displicente).

Não é teoria. Casos públicos já mostram que, quando o ataque é industrializado por um kit como o Kali365, o tempo médio entre comprometimento e dano financeiro mensurável vem caindo. Em contextos análogos, como nos ataques à cadeia de suprimentos no NPM, vimos vetores semelhantes — abuso de fluxos legítimos de autenticação — provocarem prejuízos de milhões em poucas horas.

Como detectar comprometimento por Kali365 no seu tenant

Detecção precoce, neste cenário, depende de telemetria. Ferramentas de antivírus e antispam tradicionais não vão entregar. O que funciona:

Audit log do Entra ID

No portal entra.microsoft.com → Monitoring & Health → Audit logs, filtre por Sign-in logs e procure por:

• Eventos Device Code Authentication recentes em massa.
• Logins de dispositivos com Device ID desconhecido e Compliant: No.
• Localizações geográficas inconsistentes com o perfil do colaborador.
• Aplicativos com permissão offline_access emitida fora do padrão.

Regras de inbox suspeitas

PowerShell para varrer regras criadas recentemente:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.Identity | Where-Object {
    $_.WhenChanged -gt (Get-Date).AddDays(-30) -and
    ($_.ForwardTo -or $_.DeleteMessage -or $_.MoveToFolder -like "*RSS*")
  }
}

Regras que encaminham para domínio externo e apagam o original são bandeira vermelha clássica.

Microsoft 365 Defender e Purview

Se sua licença permite, use o Microsoft 365 Defender para caçar sessões com RiskLevelAggregated: high ou unfamiliarFeatures. O Purview Audit (Premium) mantém eventos por até um ano e permite reconstruir a timeline do incidente. Times sem essas licenças precisam, no mínimo, exportar logs do Entra para um SIEM externo — vimos times brasileiros adotando essa rotina após o caso da extensão maliciosa do VS Code no GitHub.

O que fazer agora: Conditional Access e bloqueio do device code flow

O alerta FBI Microsoft 365 traz uma recomendação operacional bem específica: criar uma política de Conditional Access que bloqueie o device code flow para a maior parte dos usuários, abrindo exceção apenas para casos legítimos (autenticação em dispositivos sem teclado, como totens e algumas câmeras de reunião).

Plano de ação para esta semana, em ordem de prioridade:

1. Auditar uso atual do device code flow. No Entra ID, filtre Sign-in logs por Authentication Protocol: Device Code. Liste quem usa, quando e por quê. Sem essa baseline, qualquer bloqueio quebra produção.
2. Criar política de Conditional Access "Block Device Code Flow". Aplique a "All users", exclua um grupo CA-Exception-DeviceCode com poucos integrantes auditáveis e exclua também as contas break-glass.
3. Habilitar grants de "Require phishing-resistant MFA" para acessos administrativos. Passkeys e FIDO2 são o padrão a buscar.
4. Encurtar o tempo de vida do refresh token via Conditional Access "Sign-in frequency", forçando reautenticação a cada 7 dias para usuários sensíveis.
5. Ativar Token Protection (preview) para sessões críticas, vinculando o token ao dispositivo.
6. Configurar alertas no Defender for Cloud Apps para criação de regras de inbox com encaminhamento externo.
7. Treinar usuários com foco específico no padrão "digite este código aqui" — é o novo "clique aqui e digite a senha".

Documente cada política. Em incidente, sua capacidade de provar o que estava habilitado importa tanto quanto a defesa em si — vale para auditoria, para seguro cibernético e para LGPD.

Plano de resposta se uma conta foi comprometida

Suponha o pior: você confirmou um sign-in suspeito por device code há 12 horas e o usuário não reconhece. Ordem das ações:

1. Revogue todas as sessões do usuário. No Entra ID, abra o perfil → "Revoke sessions". Isso invalida tokens emitidos, incluindo refresh tokens.
2. Force redefinição de senha e reaplicação do MFA. Se houver suspeita de MFA fatigue, registre novo método FIDO2.
3. Inspecione e remova regras de inbox criadas ou alteradas nas últimas 30 dias.
4. Audite consentimentos de aplicativos em "Enterprise applications" → "User settings" e revogue qualquer app não reconhecido.
5. Baixe a timeline completa do Entra Audit Log para o período. Preserve para forense.
6. Notifique partes potencialmente afetadas — clientes, fornecedores e, se houver dados pessoais expostos, prepare comunicação à ANPD dentro do prazo da LGPD.
7. Reporte ao IC3 em ic3.gov com cabeçalhos completos da isca, IDs de sessão suspeita e qualquer artefato. O FBI agrega esses dados para correlacionar campanhas globais.

Times maduros já têm runbook desses. Quem não tem, este é o momento — montar o documento depois do incidente é caro e estressante.

Conclusão: o alerta FBI Microsoft 365 fecha uma era

O alerta FBI Microsoft 365 sobre o Kali365 marca um ponto importante: a era do "MFA habilitado igual a empresa segura" acabou. Quem opera Microsoft 365 no Brasil em 2026 precisa olhar para Conditional Access, FIDO2 e telemetria de Entra ID como infraestrutura básica, não como projeto futuro. Não é alarmismo — é o piso novo.

Se você quer revisar a postura de segurança no M365 da sua empresa ou desenhar políticas de Conditional Access adequadas ao porte da operação, fale comigo. Trabalhamos com governança Entra ID, modernização de autenticação e resposta a incidentes para times brasileiros que vivem dentro do ecossistema Microsoft.