Duas plataformas de phishing como serviço surgiram na primeira semana de julho de 2026, e nenhuma delas constrói uma página de login falsa. A DEBULL, documentada por pesquisadores da ZeroBEC, e a ARToken, um painel afiliado à plataforma EvilTokens exposto pela Cisco Talos, dependem ambas de um mecanismo de autenticação legítimo da Microsoft para tomar o controle de contas do Microsoft 365. Não existe página de captura de credenciais para uma equipe de segurança detectar, nenhum domínio parecido para sinalizar, e nenhuma senha que a vítima digite no lugar errado. A vítima faz login pela experiência real da Microsoft. O acesso simplesmente vai parar nas mãos de outra pessoa.
Como Funciona o Phishing por Código de Dispositivo
Os dois kits abusam do Device Authorization Grant do OAuth 2.0, um fluxo que a Microsoft criou para dispositivos sem navegador ou teclado, como smart TVs ou equipamentos de sala de reunião. A versão legítima pede que o usuário visite microsoft.com/devicelogin, digite um código curto e aprove o login em um dispositivo no qual já confia. Os atacantes reaproveitam esse mesmo fluxo como isca: uma mensagem com a aparência de um documento compartilhado, um convite de calendário ou uma solicitação de colaboração leva o alvo até essa mesma página real da Microsoft, com um código que o backend do atacante gerou momentos antes. A vítima digita o código e aprova o que parece ser um aviso de login rotineiro. Um intermediário do lado do atacante consulta os servidores da Microsoft em segundo plano e recebe o token de acesso resultante no instante em que a vítima clica em aprovar. A autenticação multifator não impede isso, porque é a própria vítima quem a completa, no site real da Microsoft, para uma sessão na qual o atacante viaja em silêncio junto.
Industrializando a Etapa Pós-Comprometimento
O que torna a DEBULL e a ARToken notáveis não é a técnica de código de dispositivo em si, que pesquisadores de segurança vêm rastreando desde as campanhas Storm-2372 reveladas no início de 2026. É o quanto cada plataforma automatiza o que acontece depois que o token cai em suas mãos. A DEBULL é construída sobre ferramentas derivadas do GraphSpy para pós-exploração de Microsoft 365 e Entra ID, dando aos operadores uma forma de apontar e clicar para fazer reconhecimento e manter acesso depois de entrar em um tenant. A ARToken vai além: a Talos encontrou um painel de operador baseado em React que expõe mais de 80 endpoints de API cobrindo persistência de Primary Refresh Token, acesso a caixas de entrada, exfiltração do SharePoint e um módulo dedicado de comprometimento de e-mail corporativo (BEC). Esse módulo dá a um afiliado acesso de leitura completo à caixa de entrada do Outlook da vítima, a capacidade de enviar e-mail como a vítima, a capacidade de criar regras de caixa de entrada que encaminham ou excluem mensagens silenciosamente, e monitoramento por palavras-chave em todas as caixas comprometidas ao mesmo tempo, de modo que um operador gerenciando dezenas de contas recebe um alerta no momento em que uma conversa sobre fatura ou transferência bancária aparece em qualquer uma delas. A Talos também observou iscas que abusam de um relacionamento real com um fornecedor em vez de inventar um, se passando por um contato de contas a pagar de um contratante real para alcançar um destinatário de contas a pagar em um cliente real desse contratante.
Onde o DMARC Não Tem Nada a Acrescentar
Essa é a mesma lacuna estrutural que já descrevemos antes com kits de phishing por tomada de conta, e vale a pena repeti-la com precisão porque essas duas plataformas a deixam tão evidente. DMARC, SPF e DKIM verificam se uma mensagem passou por infraestrutura que o proprietário do domínio autorizou a enviar em seu nome. Quando a ARToken envia um e-mail de BEC a partir de uma caixa de entrada comprometida, ela o faz através dos próprios servidores do Exchange Online da Microsoft, usando a sessão válida real da vítima, sob o domínio real da vítima. Todo sinal que o DMARC verifica é genuíno, porque a infraestrutura realmente pertence à organização do remetente. O fluxo de código de dispositivo não falsificou nada do que o DMARC inspeciona; ele obteve uma autorização real e vigente para agir como a conta, e o DMARC nunca foi projetado para perguntar se essa autorização foi concedida sob um pretexto falso. Um domínio com aplicação estrita do DMARC vai ver esse e-mail passar com um resultado limpo, com relatórios agregados e tudo, porque, da perspectiva do DMARC, nada na mensagem é inautêntico.
O Que as Equipes de Segurança Precisam Fazer
Restrinja o próprio fluxo de código de dispositivo. Políticas de Acesso Condicional podem bloquear completamente o fluxo de autenticação por código de dispositivo para usuários que não precisam dele, que é a maioria de uma organização. A Microsoft publicou orientações para limitar ou desativar esse fluxo, o que fecha o ponto de entrada do qual esses kits dependem, em vez de reagir ao que acontece depois.
Monitore os eventos de login por código de dispositivo. Os registros de login do Entra ID registram autenticações por código de dispositivo separadamente dos logins interativos normais. Um pico nesse tipo de autenticação, especialmente em usuários que nunca o usaram antes, é um sinal de detecção forte e específico que antecede qualquer abuso de e-mail posterior.
Trate a criação de regras de caixa de entrada como um alerta de alta prioridade. Tanto a pós-exploração no estilo DEBULL quanto no estilo ARToken dependem de regras silenciosas de encaminhamento e exclusão para esconder seus rastros. Alertar sobre novas regras de caixa de entrada que encaminham para fora ou excluem mensagens automaticamente detecta a etapa de BEC mesmo depois que o roubo inicial do token teve sucesso.
Treine os usuários sobre o que um aviso legítimo de código de dispositivo nunca deveria acompanhar. Um convite de calendário ou notificação de documento compartilhado que em seguida leva a uma página de digitação de código de login da Microsoft não é um padrão normal para a maioria das ferramentas de colaboração. Essa incoerência é o único momento em que um humano ainda consegue perceber o que os protocolos de autenticação não conseguem.
A Conclusão
A aplicação do DMARC continua sendo a base correta, e ainda impede o caso muito mais comum de um estranho falsificando um cabeçalho From sem nenhum ponto de apoio em seus sistemas. A DEBULL e a ARToken são um lembrete de que a indústria já superou esse caso básico. Quando plataformas de phishing como serviço empacotam todo o caminho, de um convite de calendário falso a um token de sessão funcional e um pagamento de BEC automatizado, em um único painel, o e-mail resultante vai se autenticar perfeitamente, porque ele não está mentindo sobre sua origem. O comprometimento aconteceu um passo antes, no aviso de login, e é ali que as defesas agora precisam se concentrar.
A Excello Mail oferece visibilidade contínua sobre seus relatórios agregados de DMARC e suas fontes de envio, para que você veja exatamente o que está se autenticando como seu domínio e aja rápido quando algo parecer errado. Cadastre-se gratuitamente na Excello Mail para manter essa visibilidade enquanto sua equipe fecha brechas como a tomada de conta por código de dispositivo.