Em 2026-05-21 o FBI emitiu o aviso de serviço público I-052126-PSA, alertando sobre um kit de Phishing-as-a-Service chamado Kali365 que sequestra contas do Microsoft 365. Ele não rouba senhas. Ele não intercepta códigos MFA. A vítima faz login na própria página da Microsoft, conclui a autenticação multifator, e o atacante mesmo assim sai com acesso persistente. O Kali365 faz isso abusando da concessão de autorização de dispositivo do OAuth 2.0 para capturar os tokens de acesso e de atualização que a Microsoft emite após um login totalmente legítimo.
Não é uma técnica nova. Em fevereiro de 2025 a Microsoft documentou uma campanha de device code phishing do Storm-2372, um ator que ela avalia como alinhado a interesses estatais russos, ativo contra alvos de governo, defesa, telecomunicações e energia. O que mudou foi o empacotamento. O Kali365 transforma essa tática em um kit por assinatura com iscas geradas por IA, de modo que um ator de baixa habilidade consegue executá-la. O login funciona, o prompt de MFA funciona, e a suposição por baixo de ambos falha: que um evento de autenticação bem-sucedido diz quem está com a sessão um minuto depois.
Essa suposição é o verdadeiro alvo. "Usuário autenticado com sucesso" deixou de ser uma fronteira de confiança. A sessão ativa, carregada por um token ao portador vinculado a nada, é.
O que o Kali365 realmente automatiza
O FBI descreve o Kali365 como uma plataforma de PhaaS distribuída pelo Telegram, vista pela primeira vez em abril de 2026. Ele reúne iscas de phishing geradas por IA, modelos de campanha automatizados, painéis em tempo real para rastrear pessoas específicas, e captura de tokens OAuth. Nas palavras do FBI, ele "reduz a barreira de entrada, dando a atacantes menos técnicos acesso a iscas de phishing geradas por IA, modelos de campanha automatizados, painéis de rastreamento de indivíduos/entidades em tempo real, e capacidades de captura de tokens OAuth."
Leia isso como uma divisão de trabalho. As partes difíceis do device code phishing costumavam ser escrever uma isca convincente e operar de forma confiável a infraestrutura de captura e resgate de tokens dentro de uma janela de 15 minutos. A IA escreve a isca. O kit roda o encanamento do OAuth. O operador só escolhe alvos. É isso que torna este um exemplo mais limpo de IA escalando fraude do que a maioria: ele não inventa um ataque novo, remove a habilidade que antes controlava o acesso a um existente.
O fluxo de código de dispositivo, passo a passo
A concessão de autorização de dispositivo existe por um bom motivo. Ela permite fazer login em dispositivos onde digitar é incômodo, como TVs inteligentes, decodificadores e ferramentas de linha de comando. Você vê um código curto, o insere no seu celular, o dispositivo fica autenticado. O design é legítimo e é usado o tempo todo no Microsoft 365.
Aqui está o mesmo fluxo transformado em ataque:
- O atacante envia um
POSTparahttps://login.microsoftonline.com/common/oauth2/v2.0/devicecodeusando umclient_idpróprio e público, muitas vezes Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) ou Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46). São clientes da Microsoft com consentimento prévio, então não é preciso registrar um app nem consentimento de administrador. - A Microsoft devolve um
device_code, umuser_codeque uma pessoa consegue digitar, a URL de verificaçãohttps://microsoft.com/devicelogine umexpires_inde 900 segundos. O atacante agora tem uma janela de 15 minutos. - O atacante engana a vítima para abrir
microsoft.com/devicelogine inserir ouser_code. O Microsoft Entra não suportaverification_uri_complete, a variante pré-preenchida do link, então a vítima precisa digitar o código à mão. Essa etapa manual é exatamente o que uma isca de alta conversão escrita por IA é feita para impulsionar. - A vítima se autentica na página genuína da Microsoft, conclui a MFA e dá o consentimento. Cada elemento é real: o domínio é a Microsoft, o certificado é válido, o prompt de MFA é o de sempre.
- O atacante consulta
https://login.microsoftonline.com/common/oauth2/v2.0/tokencomgrant_type=urn:ietf:params:oauth:grant-type:device_codee odevice_code, respeitando ointerval(5 segundos) e absorvendo as respostasauthorization_pending, até o endpoint devolver umaccess_tokene umrefresh_token.
Não há domínio falsificado para sinalizar nem payload no endpoint para detectar. A parte fraudulenta é um fluxo legítimo da Microsoft concluído pela pessoa errada, e o token que ele produz é indistinguível de um token emitido para uma sessão real.
Por que a MFA é satisfeita e o Acesso Condicional deixa passar
Esta é a parte que pega as equipes de surpresa. A vítima realmente concluiu o login interativo, MFA incluída, contra o endpoint real da Microsoft. Então o login é registrado como satisfeito por MFA, refletido no detalhe de autenticação do log de entrada do Entra e, nos tokens v1.0, no claim amr carregando mfa. O Acesso Condicional avalia esse login como um login interativo em conformidade e aprovado por MFA, e emite os tokens de acordo.
O atacante não está burlando a MFA no sentido de derrotar o desafio. O desafio rodou e passou. O que o modelo de token ao portador nunca faz é vincular o token emitido ao dispositivo que passou no desafio. A MFA respondeu "a pessoa certa está se autenticando agora?". Ela não respondeu "é o dispositivo certo que está com este token trinta segundos depois?", e nada no fluxo padrão faz isso.
O raio de dano: tokens de atualização FOCI e escalada para PRT
Um token de acesso capturado é ruim por uma hora. O token de atualização é o verdadeiro prêmio, e o modelo de tokens da Microsoft o torna pior do que o comprometimento de um único app.
Os tokens de atualização emitidos para os clientes próprios da Microsoft costumam ser tokens FOCI, Family of Client IDs. Um token de atualização de família obtido por meio de um cliente pode ser resgatado por tokens de acesso como outros clientes da família, de modo que um token capturado via Microsoft Office pode ser trocado por acesso ao Exchange Online, Teams, SharePoint e OneDrive, e Microsoft Graph. Um único token de atualização roubado é movimento lateral pelos dados do tenant, não um ponto de apoio em um app.
A aritmética da validade agrava tudo. Desde janeiro de 2021 as validades dos tokens de atualização não são mais ajustáveis por políticas de validade de token; a janela de inatividade padrão do token de atualização é de 90 dias e a idade máxima é, na prática, até a revogação. Onde o cliente e o recurso suportam Avaliação Contínua de Acesso, os tokens de acesso podem se estender para 24 a 28 horas, embora sejam revogáveis quase em tempo real diante de eventos críticos. Para forçar a reautenticação você agora se apoia na frequência de entrada do Acesso Condicional, não na política de token.
O teto de escalada é ainda mais alto. Na atualização de fevereiro de 2025 do seu relatório sobre o Storm-2372, a Microsoft observou o ator migrar para o cliente Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) para obter um token de atualização, registrar um dispositivo controlado pelo atacante no Entra ID e então cunhar um Primary Refresh Token. Um PRT é material de identidade durável e vinculado ao dispositivo que destrava um single sign-on amplo. O código de dispositivo é o ponto de entrada; o PRT é o tenant.
"Autenticado com sucesso" deixou de ser uma fronteira de confiança
Durante anos o modelo dominante foi simples: verifique o usuário no login e depois confie no token até ele expirar. Os backends registram o evento de autenticação, os provedores de identidade alertam sobre padrões de login estranhos, e uma vez que a sessão existe a maioria dos aplicativos para de perguntar quem está do outro lado.
O device code phishing é uma refutação limpa desse modelo. O evento de login é genuíno, o token é genuíno, e a única coisa errada é que o token agora está com alguém diferente da pessoa que se autenticou. Um token emitido para um usuário no seu notebook em um país pode ser resgatado e reproduzido a partir da infraestrutura do atacante em outro, e o Entra vê uma sessão válida e satisfeita por MFA porque, no momento da autenticação, ela era.
Ajuda ver os três caminhos comuns de roubo de tokens lado a lado. Todos terminam com um token válido pós-autenticação, mas tocam partes diferentes da superfície de ataque, o que muda tanto como eles driblam os controles quanto onde você ainda pode pegá-los.
| Ataque | Token capturado | O que toca a vítima | Onde ocorre o uso malicioso | Principal lacuna de telemetria |
|---|---|---|---|---|
| Device code phishing (Kali365) | OAuth de acesso e de atualização (muitas vezes FOCI) | Uma mensagem de phishing mais a página real microsoft.com/devicelogin | Resgate e reúso do token a partir da infraestrutura do atacante | O login é o login MFA genuíno da vítima; o resgate é atribuído a ele |
| Phishing adversary-in-the-middle | Token de sessão ou cookie capturado em trânsito | Uma página de login falsa com proxy reverso | Sessão reproduzida a partir da infraestrutura do atacante | Existe um domínio parecido, mas a sessão parece válida adiante |
| Malware infostealer | Cookies de sessão copiados do disco | Malware rodando no endpoint | Sessão retomada a partir do cookie roubado | Comprometimento do endpoint, mas a sessão retomada passa nas verificações do servidor |
O fio comum é a última coluna. Em todos os casos o aplicativo tem um token válido e trata quem o possui como o usuário autenticado. O dispositivo que se autenticou e o dispositivo que agora usa o token são diferentes, e o modelo padrão não tem verificação nativa para essa diferença.
Detectar e bloquear
Há duas tarefas aqui: fechar o fluxo, e encontrar onde ele já foi usado.
Bloquear o fluxo no Acesso Condicional do Entra
Isso corresponde diretamente à recomendação principal do FBI. No Acesso Condicional, use a condição de fluxos de autenticação e defina o fluxo de código de dispositivo como Bloquear, e bloqueie a transferência de autenticação na mesma política. A própria orientação da Microsoft é bloquear o fluxo de código de dispositivo sempre que possível.
- Aplique a política a todos os usuários e todos os recursos, e depois exclua as contas break-glass e de acesso de emergência para que uma má configuração não tranque você do lado de fora.
- Se um processo legítimo registra dispositivos pelo fluxo de código de dispositivo, exclua o Serviço de Registro de Dispositivos (
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), já que as políticas de fluxos de autenticação são aplicadas ali quando a política mira todos os recursos. - Audite o uso atual do código de dispositivo antes de aplicar, para que as exceções legítimas sejam conhecidas em vez de adivinhadas.
Caçar o uso anterior nos logs de entrada
As entradas por código de dispositivo são visíveis nos logs de entrada do Entra ID. O filtro de detecção mais usado é o protocolo de autenticação:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize logins=count() by UserPrincipalName, AppDisplayName, IPAddress, tostring(LocationDetails.countryOrRegion)
Observe também OriginalTransferMethod == "deviceCodeFlow" para captar sessões rastreadas por protocolo em renovações posteriores, e sinalize eventos de registro de dispositivo realizados pelo cliente Microsoft Authentication Broker onde você não os espera, que é o sinal da escalada para PRT.
A limitação honesta está na tabela acima. O evento de autenticação que produziu o token é o login real e satisfeito por MFA da vítima, então a detecção por logs é forte sobre o fluxo em si, mas fraca sobre o resgate e o reúso que vêm depois, que o Entra atribui a esse login legítimo.
Onde a brecha do código de dispositivo realmente se fecha: a camada de sessão
Um token roubado precisa ser usado em algum lugar, e esse lugar quase nunca é o dispositivo que se autenticou. Essa divergência é o sinal que o modelo de token ao portador descarta e o que a cside foi construída para preservar.
O fingerprinting avançado de dispositivos da cside coleta mais de 100 sinais de navegador, dispositivo e rede para construir um identificador persistente de cada visitante. Na autenticação, esses sinais estabelecem uma linha de base para a sessão. Quando um token é depois apresentado a partir de um ambiente diferente, um fingerprint de TLS e de navegador diferente, um ASN ou uma saída por proxy residencial diferentes, marcas de automação ou headless que não estavam no login, o fingerprint não corresponde à linha de base, e essa divergência pode acionar a invalidação do token ou um desafio adicional antes que o atacante chegue aos dados. Aprofundamos isso em como dados de localização avançados detectam o reúso inseguro de tokens e na mudança mais ampla em por que a sessão do navegador agora é um plano de controle de segurança.
A cside também monitora o ambiente do lado do cliente em busca dos scripts maliciosos e das cargas de sequestro de sessão que operam inteiramente abaixo da camada de autenticação. Essa é a visibilidade na camada do navegador que os logs de backend não conseguem fornecer, e é a parte da superfície de ataque onde o roubo de tokens é de fato decidido. Para ver onde isso se encaixa em um stack mais amplo de tomada de conta, nosso guia para comparar soluções de prevenção de ATO mapeia onde a MFA para e onde os sinais de nível de sessão começam.
Agende uma demo para ver como a cside detecta sessões comprometidas antes que o dano aconteça.
Os controles do Microsoft 365, o comportamento do Entra e as orientações do FBI estão corretos em 2026-05-31. Os fluxos dos fornecedores, os IDs de cliente e os avisos mudam; confirme as opções atuais de fluxo de código de dispositivo e de Acesso Condicional da Microsoft antes de depender de uma configuração específica.
