Device code phishing — o abuso do OAuth 2.0 device authorization grant para roubar tokens de acesso — evoluiu de uma técnica nichada de red team para uma ameaça industrial em menos de seis meses.
Projetado para dispositivos com restrições de entrada como smart TVs, impressoras e similares, o fluxo de login por autorização de dispositivo foi adotado por uma ampla gama de apps e casos de uso para os quais não foi originalmente destinado — mais comumente logins via CLI (interface de linha de comando).
Pesquisadores descreveram pela primeira vez esse vetor de ataque em 2020, mas levou até 2024 para que atores de nation-state como Storm-2372 começassem a utilizá-lo em ambiente real. Em 2025, o grupo ShinyHunters estava usando phishing via código de dispositivo contra tenants do Salesforce em escala, e em fevereiro de 2026, o kit EvilTokens chegou e a adoção criminal disparou. Em abril, a Microsoft reportava 10 a 15 campanhas inteiramente novas a cada 24 horas. A Barracuda registrou 7 milhões de ataques em quatro semanas. O FBI emitiu um avisos independente sobre o Kali365, o primeiro PSA de agência federal americana sobre um kit específico de phishing-as-a-service.
A Push Security adicionou phishing via código de dispositivo à sua Browser & Identity Attacks Matrix em 2023 e agora rastreia mais de 25 kits distintos de phishing via código de dispositivo em circulação — e o número continua crescendo. Entrando no segundo semestre de 2026, não há sinais de que o ritmo esteja diminuindo.
A Push recentemente realizou um webinar aprofundado sobre phishing via código de dispositivo, cobrindo a mecânica do ataque, uma demonstração ao vivo de um kit de phishing personalizado e o que vem a seguir. Aqui estão seis pontos-chave que equipes de segurança devem monitorar.
1. Ele vence todas as formas de MFA, incluindo passkeys
Phishing via código de dispositivo não ataca o fluxo de login. Ele ataca o que acontece após o login — a camada de autorização. Na maioria dos casos, a vítima já está conectada à sua conta Microsoft quando encontra a página de phishing. Ela copia um código curto, insere-o na página legítima de login de dispositivo da Microsoft, seleciona sua conta em um menu suspenso e clica em permitir. Esse é o ataque inteiro.
Passkeys, chaves de segurança de hardware, MFA phishing-resistant obrigatório — nada disso faz diferença, porque o fluxo de código de dispositivo é separado do mecanismo de autenticação. O ataque explora o fato de que provar sua identidade e conceder acesso a uma aplicação são duas coisas diferentes, e a maioria dos controles de segurança protege apenas a primeira.
2. O ecossistema PhaaS industrializou completamente essa técnica
Phishing via código de dispositivo não é mais uma técnica especializada. É um recurso padrão no catálogo de phishing-as-a-service. O Tycoon2FA, que a Push rastreava anteriormente como o kit de phishing AiTM mais comum em circulação, adicionou phishing via código de dispositivo ao seu framework em maio. O Kali365 oferece tanto phishing AiTM quanto via código de dispositivo em uma única plataforma.
Algumas empresas de segurança relatam que as semelhanças estruturais entre os kits são evidência de que o ecossistema está se bifurcando e fragmentando. Mas baseado no que vimos, kits construídos independentemente usando instruções similares de LLM podem parecer igualmente semelhantes.
Independentemente disso, as capacidades que esses kits oferecem continuam melhorando: por exemplo, o ARToken vem com persistência de PRT, acesso a caixas de correio, automação de BEC e exfiltração de SharePoint integrados como recursos de produto para operadores pagantes.
O padrão de comercialização espelha o que aconteceu com phishing AiTM: uma técnica passa de curiosidade de pesquisa para espionagem de nation-state para commodity criminal, cada estágio acelerando mais que o anterior. Mas phishing via código de dispositivo completou essa jornada inteira em questão de meses — uma compressão que reflete tanto a maturidade do mercado PhaaS existente quanto a velocidade com que o desenvolvimento assistido por IA permite que novas capacidades sejam construídas e distribuídas.
3. Atacantes estão criando novos kits via vibe-coding mais rápido do que defensores conseguem catalogá-los
A Push agora rastreia mais de 25 kits distintos de phishing via código de dispositivo em circulação — um número que seria inconcebível antes deste ano. Para contexto, um kit de phishing AiTM completamente novo aparecendo em circulação costumava ser um evento significativo que acontecia uma vez a cada poucos meses. Ter 25+ famílias de kits surgindo este ano sozinho reflete uma mudança fundamental na forma como ferramentas de phishing são construídas.
O desenvolvimento assistido por IA reduziu drasticamente a barreira de entrada. Muitos dos kits que a Push rastreia compartilham semelhanças estruturais como padrões de layout similares e arquitetura de código similar, porque foram gerados por LLMs respondendo a prompts similares. O VP de P&D da Push, Luke Jennings, criou seu próprio kit para demonstrar apenas quão fácil é.
4. Não é apenas um problema da Microsoft
99% do phishing via código de dispositivo que a Push detecta hoje tem como alvo a Microsoft, mas o webinar demonstra por que isso não vai durar. O OAuth 2.0 device authorization grant é um padrão multiplataforma, e qualquer aplicação que o implemente é um alvo potencial.
Atores de nation-state já usaram phishing via código de dispositivo contra o Salesforce em campanhas direcionadas. A campanha do ShinyHunters contra o Salesforce, que comprometeu mais de 1.000 organizações e produziu 1,5 bilhão de registros roubados, usou uma aplicação maliciosa "DataLoader" para abusar do fluxo de código de dispositivo em escala.
Phishing via código de dispositivo é menos universalmente aplicável que AiTM — nem todo app implementa o device authorization grant — mas tem as vantagens que já descrevemos: ignora todo MFA incluindo passkeys, não requer clonagem de página de login, e o usuário interage com URLs legítimas do provedor.
Aplicativos como GitHub, AWS e outros todos suportam fluxos de código de dispositivo, e para o GitHub é uma parte central de como desenvolvedores autenticam ferramentas CLI e túneis do VS Code. À medida que desenvolvedores de kits olham além da Microsoft, esses são os alvos que se abrem.
5. É parte de uma mudança mais ampla para ataques de autorização
Phishing via código de dispositivo não é uma técnica isolada. Atacantes estão se afastando da camada de autenticação porque é onde defensores concentraram seus controles, e mecanismos de autorização têm recebido atenção comparativamente menor.
A Push descobriu o ConsentFix no final de 2025, uma técnica de phishing de consentimento OAuth nativa do navegador inicialmente atribuída a atores russos que desde então apareceu em kits criminais. Como phishing via código de dispositivo, o ConsentFix ataca a camada de autorização e vence passkeys pela mesma razão estrutural: o ataque ocorre após a autenticação já ter sido bem-sucedida.
À medida que atacantes continuam desenvolvendo novas formas de abusar fluxos de consentimento, registro de dispositivos e mecanismos de troca de tokens, essa lacuna se ampliará a menos que defensores se adaptem.
6. A detecção tem que acontecer onde o ataque acontece
Páginas de phishing via código de dispositivo podem ser distribuídas por qualquer canal: e-mail, apps de mensagens, redes sociais, resultados de mecanismos de busca, sites comprometidos e mais. O usuário insere o código na URL de login legítima do provedor, o que significa que o ataque transita por infraestrutura que nenhum proxy de rede, serviço de reputação de URL ou gateway de e-mail vai bloquear.
O conselho de mitigação mais comum para ambientes Microsoft é restringir fluxos de autenticação de código de dispositivo via políticas de acesso condicional, e essa é uma boa etapa onde for viável. Mas nem sempre é direto — fluxos de código de dispositivo existem por razões legítimas, e organizações maiores frequentemente descobrem que não podem simplesmente desativá-los sem quebrar ferramentas de desenvolvedor, fluxos de trabalho CLI ou cenários de dispositivos restritos.
Mesmo onde organizações restringem para Microsoft, isso não faz nada para proteger contra phishing via código de dispositivo mirando GitHub, AWS ou outras plataformas onde controles de acesso condicional equivalentes podem não existir.
O único ponto de observação que vê tanto o phishing lure quanto a aprovação do código de dispositivo — através de qualquer provedor — é o navegador, que é onde a Push opera. O pipeline de threat hunting agentic da Push escreve e implanta regras de detecção continuamente, mirando a classe de técnica: ou seja, as assinaturas comportamentais de kits de phishing via código de dispositivo e o fluxo de aprovação de código de dispositivo em si, em vez de fingerprints específicas de kits ou domínios. Essa distinção importa quando novos kits estão aparecendo semanalmente e queimando infraestrutura mais rápido do que qualquer abordagem baseada em IOC pode rastrear.
Para a análise técnica completa, incluindo uma demonstração lado a lado do que a vítima vê e o que o atacante vê durante um ataque de phishing via código de dispositivo, a cadeia de escalação de privilégios de tokens roubados para acesso SSO completo e as opções defensivas disponíveis, assista ao webinar.
A Push Security é a ferramenta de segurança mais poderosa nativa de IA no navegador. Pense em EDR, mas para o navegador — telemetria de alta fidelidade e controle em tempo real em cada sessão, em cada dispositivo, sem necessidade de migração de navegador.
Equipes de segurança usam a Push para detectar e parar ataques avançados baseados em navegador como phishing AiTM, ClickFix e sequestro de sessão; obter visibilidade e controle sobre uso de ferramentas de IA em sua força de trabalho; fortalecer identidades expondo reutilização de credenciais, lacunas de SSO e TI sombra; e apoiar investigações de perda de dados e ameaças internas com telemetria na camada do navegador que outras ferramentas não conseguem ver.
