Resumo: roubo de tokens de MFA e o modelo de confiança do device code phishing
- A lacuna: Todas as apresentações de sensibilização continuam a posicionar a MFA como a linha de chegada, mas o kit Kali365 permite a um operador pouco qualificado recolher tokens de acesso e de atualização depois de a vítima completar a MFA na página real da Microsoft, com o Conditional Access a tratar o início de sessão como conforme.
- O que a cside vê: Um único token de atualização FOCI capturado dá acesso lateral ao Outlook, Teams, SharePoint, OneDrive e Microsoft Graph dentro de uma janela de inatividade predefinida de 90 dias; a cside expõe anomalias de sessão em direto em navegadores reais de utilizadores, tornando o replay de tokens contra recursos do tenant visível em vez de legítimo.
- A decisão: Antes da próxima revisão do Conditional Access do Entra, decida se o fluxo de código de dispositivo e a transferência de autenticação estão bloqueados sempre que possível, e se as exclusões de break-glass e do Device Registration Service estão documentadas.
Sem tempo? Veja a deteção de account takeover da cside. Cobre tudo o que se segue numa única implementação.
Em 2026-05-21 o FBI emitiu o comunicado de serviço público I-052126-PSA, alertando para um kit de Phishing-as-a-Service chamado Kali365 que sequestra contas do Microsoft 365. Não rouba uma palavra-passe nem intercepta um código de MFA. A vítima inicia sessão na própria página da Microsoft, completa a autenticação multifator, e o atacante mesmo assim sai com acesso persistente. O Kali365 consegue isto 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 início de sessão totalmente legítimo.
Esta 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 avalia como alinhado com interesses estatais russos, ativo contra alvos de governo, defesa, telecomunicações e energia. O que mudou foi a embalagem. O Kali365 transforma essa técnica num kit por subscrição com iscas geradas por IA, permitindo que um ator com poucas competências o execute. O início de sessão funciona, o pedido de MFA funciona, e a suposição por baixo de ambos falha: a de que um evento de autenticação bem-sucedido diz quem detém a sessão um minuto depois.
Essa suposição é o verdadeiro alvo. "Utilizador autenticado com sucesso" deixou de ser uma fronteira de confiança. A sessão ativa, transportada por um token portador vinculado a nada, é.
O que o Kali365 realmente automatiza
O FBI descreve o Kali365 como uma plataforma de PhaaS distribuída via Telegram, vista pela primeira vez em abril de 2026. Reúne iscas de phishing geradas por IA, modelos de campanha automatizados, painéis em tempo real para rastrear indivíduos visados, e captura de tokens OAuth. Nas palavras do FBI, "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 visados em tempo real, e capacidades de captura de tokens OAuth."
Leia isto como uma divisão de trabalho. As partes difíceis do device code phishing costumavam ser escrever uma isca convincente e operar de forma fiável a infraestrutura de captura e resgate de tokens dentro de uma janela de 15 minutos. A IA escreve a isca. O kit trata da canalização OAuth. O operador limita-se a escolher alvos. É isto que torna este caso um exemplo mais claro de IA a escalar a fraude do que a maioria: não inventa um ataque novo, remove a competência que antes controlava o acesso a um já existente.
O fluxo de código de dispositivo, passo a passo
A concessão de autorização de dispositivo existe por uma boa razão. Permite iniciar sessão em dispositivos onde é incómodo escrever, como smart TVs, set-top boxes de streaming e ferramentas de linha de comandos. Vê-se um código curto, insere-se no telemóvel, e o dispositivo fica com sessão iniciada. O design é legítimo e é usado constantemente em todo o Microsoft 365.
Eis o mesmo fluxo transformado em ataque:
- O atacante envia um
POSTparahttps://login.microsoftonline.com/common/oauth2/v2.0/devicecodeusando umclient_idpúblico próprio da Microsoft, frequentemente Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) ou Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46). São clientes Microsoft pré-consentidos, pelo que não é necessário registar uma app personalizada nem consentimento de administrador. - A Microsoft devolve um
device_code, umuser_codeque uma pessoa consegue digitar, o URL de verificaçãohttps://microsoft.com/devicelogin, e umexpires_inde 900 segundos. O atacante tem agora 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, pelo que a vítima tem de digitar o código manualmente. É exatamente esse passo manual que uma isca de alta convicção escrita por IA é construída para provocar. - A vítima autentica-se na página genuína da Microsoft, completa a MFA e dá o consentimento. Todos os elementos são reais: o domínio é da Microsoft, o certificado é válido, o pedido de MFA é o mesmo 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 detetar. A parte fraudulenta é um fluxo legítimo da Microsoft concluído pela pessoa errada, e o token que produz é indistinguível de um token emitido para uma sessão real.
Por que a MFA fica satisfeita e o Conditional Access deixa passar
Esta é a parte que apanha as equipas de surpresa. A vítima concluiu genuinamente o início de sessão interativo, incluindo a MFA, contra o endpoint real da Microsoft. Assim, o início de sessão é registado como satisfeito por MFA, refletido no detalhe de autenticação do registo de início de sessão do Entra e, em tokens v1.0, na claim amr a transportar mfa. O Conditional Access avalia esse início de sessão como um login interativo em conformidade e aprovado por MFA, e emite os tokens em conformidade.
O atacante não está a contornar a MFA no sentido de derrotar o desafio. O desafio correu e foi aprovado. O que o modelo de token portador nunca faz é vincular o token emitido ao dispositivo que satisfez o desafio. A MFA respondeu "é a pessoa certa que está a autenticar-se agora". Não respondeu "é o dispositivo certo que detém este token trinta segundos depois", e nada no fluxo padrão o faz.
O raio de dano: tokens de atualização FOCI e escalada para PRT
Um token de acesso capturado é mau durante uma hora. O token de atualização é o verdadeiro prémio, e o modelo de tokens da Microsoft torna-o pior do que o comprometimento de uma única app.
Os tokens de atualização emitidos aos clientes próprios da Microsoft são tipicamente tokens FOCI, Family of Client IDs. Um token de atualização de família obtido através de um cliente pode ser resgatado por tokens de acesso a outros clientes da família, pelo 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 representa movimento lateral pelos dados do tenant, não um ponto de apoio numa única app.
A matemática da duração agrava a situação. Desde janeiro de 2021 as durações dos tokens de atualização deixaram de ser ajustáveis através de políticas de duração de token; a janela de inatividade predefinida do token de atualização é de 90 dias e a idade máxima é, na prática, até ser revogado. Onde o cliente e o recurso suportam Continuous Access Evaluation, os tokens de acesso podem estender-se a 24 a 28 horas, embora sejam revogáveis quase em tempo real perante eventos críticos. Para forçar a reautenticação, apoia-se agora na frequência de início de sessão do Conditional Access, 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 a passar para o cliente Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) para obter um token de atualização, registar um dispositivo controlado pelo atacante no Entra ID e depois cunhar um Primary Refresh Token. Um PRT é material de identidade duradouro e vinculado ao dispositivo que desbloqueia 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: verificar o utilizador no início de sessão e depois confiar no token até expirar. Os backends registam o evento de autenticação, os fornecedores de identidade alertam para padrões de início de sessão estranhos, e assim que a sessão existe a maioria das aplicações deixa de perguntar quem está do outro lado.
O device code phishing é uma refutação clara desse modelo. O evento de início de sessão é genuíno, o token é genuíno, e a única coisa errada é que o token está agora na posse de alguém diferente da pessoa que se autenticou. Um token emitido para um utilizador no seu portátil num país pode ser resgatado e reproduzido a partir da infraestrutura do atacante noutro, e o Entra vê uma sessão válida e satisfeita por MFA porque, no momento da autenticação, era.
Ajuda ver os três caminhos comuns de roubo de tokens lado a lado. Todos terminam num token válido pós-autenticação, mas tocam em partes diferentes da superfície de ataque, o que muda tanto a forma como evitam os controlos como onde ainda é possível apanhá-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 (frequentemente FOCI) | Uma mensagem de phishing mais a página real microsoft.com/devicelogin | Resgate e reutilização do token a partir da infraestrutura do atacante | O início de sessão é o login MFA genuíno da vítima; o resgate é-lhe atribuído |
| 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 semelhante, mas a sessão parece válida a jusante |
| Malware infostealer | Cookies de sessão copiados do disco | Malware a correr no endpoint | Sessão retomada a partir do cookie roubado | Comprometimento do endpoint, mas a sessão retomada passa nas verificações do lado do servidor |
O fio condutor é a última coluna. Em todos os casos a aplicação detém um token válido e trata o portador como o utilizador 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 nenhuma verificação nativa para essa diferença.
Detetar e bloquear
Há duas tarefas aqui: fechar o fluxo, e descobrir onde já foi usado.
Bloquear o fluxo no Conditional Access do Entra
Isto corresponde diretamente à recomendação principal do FBI. No Conditional Access, 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 utilizadores 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 o bloqueie a si de fora.
- Se um processo legítimo regista dispositivos através do fluxo de código de dispositivo, exclua o Device Registration Service (
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), já que as políticas de fluxos de autenticação são aplicadas aí quando a política visa todos os recursos. - Audite o uso atual do código de dispositivo antes de aplicar a política, para que as exceções genuínas sejam conhecidas em vez de adivinhadas.
Procurar utilizações anteriores nos registos de início de sessão
Os inícios de sessão por código de dispositivo são visíveis nos registos de início de sessão do Entra ID. O filtro de deteção mais utilizado é 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 apanhar sessões rastreadas pelo protocolo em renovações posteriores, e sinalize eventos de registo de dispositivo realizados pelo cliente Microsoft Authentication Broker onde não os espera, o que é o indício de escalada para PRT.
A limitação honesta está na tabela acima. O evento de autenticação que produziu o token é o início de sessão real e satisfeito por MFA da vítima, pelo que a deteção baseada em registos é forte quanto ao próprio fluxo, mas fraca quanto ao resgate e reutilização que se seguem, que o Entra atribui a esse início de sessão legítimo.
Onde a brecha do código de dispositivo realmente se fecha: a camada de sessão
Um token roubado tem de ser usado nalgum lugar, e esse lugar quase nunca é o dispositivo que se autenticou. Essa incompatibilidade é o sinal que o modelo de token portador descarta e o que a cside foi construída para preservar.
O fingerprinting avançado de dispositivos da cside recolhe mais de 250 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, uma fingerprint TLS e de navegador diferente, um ASN ou uma saída por proxy residencial diferentes, marcadores de automação ou headless que não existiam no início de sessão, a fingerprint não corresponde à linha de base, e essa incompatibilidade pode desencadear a invalidação do token ou um desafio adicional antes de o atacante chegar aos dados. Aprofundamos isto em como dados de localização avançados detetam a reutilização insegura de tokens e na mudança mais ampla em por que a sessão do navegador é agora um plano de controlo de segurança, incluindo o que a DBSC do Chrome cobre e o que o fingerprinting de dispositivos complementa.
A cside também monitoriza 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. É a visibilidade ao nível do navegador que os registos de backend não conseguem fornecer, e é a parte da superfície de ataque onde o roubo de tokens é efetivamente decidido. Para perceber onde isto se encaixa numa pilha mais ampla de prevenção de tomada de conta, o nosso guia de comparação de soluções de prevenção de ATO mapeia onde a MFA termina e onde começam os sinais ao nível da sessão.
Marque uma demonstração para ver como a cside deteta sessões comprometidas antes de o dano acontecer.
Os controlos do Microsoft 365, o comportamento do Entra e as orientações do FBI são precisos a partir de 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 Conditional Access da Microsoft antes de depender de uma configuração específica.
