Abuso do device authorization grant escala com kits PhaaS, alvos Microsoft e Salesforce, e autorização pós-login que bypassa passkeys e MFA resistente a phishing.
| Componente | Fluxo OAuth 2.0 device authorization grant; tokens de acesso e aprovação de aplicativo após autenticação já concluída |
| Vetor | Isca entrega código curto; vítima autentica na página legítima do provedor e concede autorização, permitindo roubo de token sem clonar o login |
| Impacto | Contorno de MFA, passkeys e chaves de hardware; persistência via PRT; acesso a caixa de correio, BEC e SharePoint em kits comerciais; campanhas em escala industrial |
| Prioridade | Restringir device code via Conditional Access onde viável; monitorar aprovações anômalas de device code; caçar comportamento da técnica em navegador e identidade, não só IoCs |
| Artefatos | Kits citados: EvilTokens, Kali365, Tycoon2FA com device code, ARToken; ConsentFix como técnica paralela de consentimento OAuth |
| Mitigação | Políticas de Conditional Access para device code no Microsoft; revisão de usos legítimos de CLI e dispositivos restritos; telemetria de aprovação e iscas em múltiplos canais |
O phishing por código de dispositivo abusa do device authorization grant do OAuth 2.0 para obter tokens de acesso sem atacar o formulário de autenticação em si. O fluxo foi concebido para equipamentos com entrada limitada, como smart TVs e impressoras, e acabou sendo adotado em cenários para os quais não foi originalmente pensado, sobretudo logins de ferramentas de linha de comando. Em poucos meses, a técnica saiu do repertório de red team e passou a operar em escala industrial, com telemetria de provedores e de empresas de segurança apontando dezenas de campanhas novas por dia e milhões de tentativas em janelas curtas.
A linha do tempo no contexto é clara. Pesquisadores descreveram o vetor em 2020. Em 2024, atores de estado-nação como Storm-2372 passaram a usá-lo em ambiente real. Em 2025, ShinyHunters aplicou phishing por código de dispositivo contra tenants Salesforce em escala. Em fevereiro de 2026, o kit EvilTokens acelerou a adoção criminosa. Em abril, a Microsoft reportava de dez a quinze campanhas novas a cada vinte e quatro horas, enquanto a Barracuda contabilizou sete milhões de ataques em quatro semanas. O FBI emitiu aviso específico sobre o kit Kali365, descrito como o primeiro alerta federal estadunidense sobre um phishing-as-a-service concreto desse tipo.
A mudança estrutural é o alvo: não a autenticação, e sim a camada de autorização. Em muitos casos a vítima já está autenticada na conta Microsoft quando encontra a isca. Ela copia um código curto, digita-o na página legítima de login por dispositivo do provedor, escolhe a conta e concede a permissão. Controles como passkeys, chaves de segurança de hardware e MFA forçado resistente a phishing não interrompem esse caminho, porque o fluxo de device code é independente do mecanismo que prova identidade no login inicial. Provar identidade e conceder acesso a um aplicativo são etapas distintas; a maior parte dos controles concentra-se na primeira.
O atacante não precisa clonar a página de login do provedor. A isca pode chegar por e-mail, mensagens, redes sociais, resultados de busca ou sites comprometidos. O usuário interage com URLs legítimas do provedor ao inserir o código e aprovar o aplicativo. Proxies de rede, reputação de URL e gateways de e-mail perdem eficácia relativa, porque o trânsito crítico ocorre em infraestrutura confiável do provedor de identidade.
Após a concessão, o operador obtém tokens que habilitam acesso às aplicações autorizadas. Kits comerciais empacotam capacidades pós-comprometimento. O ARToken, por exemplo, é descrito com persistência via PRT, acesso a caixa de correio, automação de BEC e exfiltração em SharePoint como recursos de produto para operadores pagantes. O Tycoon2FA, antes associado sobretudo a phishing AiTM, incorporou device code phishing em maio. O Kali365 oferece AiTM e device code na mesma plataforma.
A comercialização replica o ciclo visto no AiTM — pesquisa, uso por estado-nação, commodity criminosa — porém comprimido em meses, refletindo maturidade do mercado PhaaS e desenvolvimento assistido por modelos de linguagem. Mais de vinte e cinco famílias distintas de kits de device code foram rastreadas em ambiente real. Semelhanças estruturais entre kits podem indicar bifurcação do ecossistema ou geração independente com instruções semelhantes a LLMs; em ambos os casos, a barreira de entrada caiu.
Noventa e nove por cento das detecções citadas ainda miram Microsoft, mas o grant de autorização por dispositivo é padrão multiplataforma. Qualquer aplicativo que o implemente é alvo potencial. Campanhas de estado-nação e o caso Salesforce atribuído a ShinyHunters — com aplicativo malicioso apresentado como DataLoader, mais de mil organizações comprometidas e cerca de 1,5 bilhão de registros obtidos — mostram abuso do fluxo fora do perímetro Microsoft. GitHub e AWS sustentam device code; no GitHub o fluxo é central para autenticação de CLIs e túneis do VS Code. À medida que desenvolvedores de kits olham além da Microsoft, essas superfícies ganham prioridade.
A técnica não é isolada. Defensores concentraram controles na autenticação; mecanismos de autorização receberam menos atenção. O ConsentFix, identificado no final de 2025 como phishing de consentimento OAuth nativo do navegador e depois visto em toolkits criminosos, também age após autenticação bem-sucedida e derrota passkeys pelo mesmo motivo estrutural. Abusos de consentimento, registro de dispositivo e troca de tokens tendem a ampliar essa lacuna se a defesa não se adaptar.
Ficam expostos ambientes Microsoft com device code habilitado, tenants Salesforce sujeitos a abuso de aplicativo via device code, e plataformas que implementam o grant para CLIs e dispositivos restritos. Organizações grandes frequentemente não conseguem desligar o fluxo sem quebrar ferramentas de desenvolvimento, fluxos de CLI ou cenários de dispositivo limitado. Bloquear apenas no Microsoft não protege GitHub, AWS ou outros provedores sem controles equivalentes de Conditional Access.
A superfície humana inclui usuários já autenticados que apenas autorizam um aplicativo. A superfície de controle inclui políticas de acesso condicional, inventário de usos legítimos de device code e telemetria de aprovação de tokens. A superfície de ameaça inclui PhaaS com AiTM e device code combinados, kits com automação de BEC e persistência de sessão.
Indicadores puramente baseados em domínio ou fingerprint de kit envelhecem rápido: novos kits surgem com frequência semanal e a infraestrutura é descartada mais depressa do que abordagens só de IoC conseguem acompanhar.
- Contas Microsoft com device code ainda permitido e usuários já autenticados no momento da isca
- Tenants Salesforce e aplicativos OAuth abusáveis via device authorization grant
- CLIs e integrações em GitHub, AWS e demais apps com device code habilitado
- Operadores PhaaS com
EvilTokens,Kali365,Tycoon2FAeARTokenou variantes equivalentes - Canais de entrega: e-mail, mensagens, redes sociais, SEO e sites comprometidos
A prioridade de hunting é a classe de comportamento, não o hash de um kit específico. Em identidade Microsoft, correlacione aprovações de device code com origem da isca, horário atípico, aplicativo desconhecido e ausência de necessidade legítima de CLI ou dispositivo restrito. Em endpoint e identidade, procure sequências em que o usuário não passa por desafio de MFA no momento da concessão, porque a autenticação já tinha ocorrido.
No navegador, observe páginas de isca que instruem a copiar códigos curtos e redirecionam o usuário para o fluxo legítimo de device login do provedor. Em correio e colaboração, busque automação de BEC e acessos anômalos a caixa postal e SharePoint após emissão de tokens. Em Salesforce e demais SaaS, revise consentimentos e aplicativos como o padrão DataLoader malicioso descrito no caso de escala.
Para ConsentFix e técnicas irmãs, monitore fluxos de consentimento OAuth no navegador após sessão autenticada. Em CI/CD e desenvolvimento, inventarie usos reais de device code em GitHub CLI, túneis VS Code e ferramentas AWS. Telemetria de rede isolada tende a falhar quando a aprovação ocorre em URL legítima do provedor.
- Picos de aprovações de device code sem mudança correspondente em inventário de ferramentas legítimas
- Aplicativos OAuth novos ou pouco usados recebendo consentimento via device code
- Sessões com PRT ou tokens que habilitam caixa postal, SharePoint ou SSO sem login interativo recente
- Iscas multi-canal pedindo código curto e apontando para página legítima do provedor
- Sinais de kits PhaaS com AiTM e device code na mesma cadeia operacional
A mitigação mais citada para Microsoft é restringir autenticação por device code com políticas de Conditional Access, quando operacionalmente viável. Antes de bloquear, mapeie dependências: CLIs, dispositivos restritos e fluxos de desenvolvedores. Onde o desligamento total não for possível, limite por grupo, localização, risco de sessão e aplicativos aprovados, e exija justificativa para exceções.
Trate a resposta em camadas. Contenção: revogar tokens e sessões suspeitas, invalidar PRT quando aplicável, auditar caixas postais e SharePoint por automação de BEC ou exfiltração. Correção de processo: educar que aprovação de código em página legítima ainda pode ser abuso de autorização. Ampliação: avaliar superfícies GitHub e AWS com device code, mesmo após endurecimento Microsoft.
Não dependa só de IoCs. Kits novos e infraestrutura descartável superam listas estáticas. Prefira detecção comportamental da isca mais da aprovação de device code, revisão contínua de consentimentos OAuth e controles na camada em que isca e aprovação podem ser correlacionadas. Ignore chamadas comerciais de produtos específicos; a prioridade operacional é fechar a lacuna entre autenticação bem protegida e autorização ainda frágil.
- Restringir device code no Microsoft via Conditional Access com inventário prévio de usos legítimos
- Revogar tokens, auditar BEC e SharePoint após aprovação suspeita
- Estender revisão a GitHub, AWS e Salesforce com device authorization grant
- Caçar comportamento da técnica e de consentimento pós-login, não apenas domínios de kits
- Tratar ConsentFix e abusos de token exchange como mesma família de risco na autorização
0 Comentários