Microsoft derruba EvilTokens: phishing por device code

A Microsoft interrompeu a operação do EvilTokens, uma plataforma de phishing como serviço que abusava do fluxo de autenticação por device code para sequestrar sessões e acessar caixas de entrada. A campanha teria comprometido cerca de 12 mil contas, destacando como mecanismos legítimos de login podem ser explorados para contornar MFA e roubar tokens de acesso. O caso reforça a necessidade de monitorar consentimentos OAuth, fluxos de device code e sinais anômalos de autenticação em ambientes Microsoft 365.

O episódio é relevante porque mostra uma mudança importante no cenário de ameaças: muitos ataques modernos não dependem apenas de malware, exploração de vulnerabilidades técnicas ou quebra de senhas. Em vez disso, criminosos exploram fluxos legítimos de autenticação, autorização e consentimento, especialmente em plataformas de identidade em nuvem. O phishing por device code é um exemplo claro dessa tendência, pois utiliza um recurso real, documentado e útil para determinados cenários, mas o transforma em um meio de obtenção indevida de tokens e acesso a aplicações corporativas.

Para organizações que utilizam Microsoft 365, Entra ID, aplicações SaaS e autenticação multifator, o caso EvilTokens deve ser entendido como um alerta de governança de identidade, segurança da informação e proteção de dados. A existência de MFA não elimina o risco quando o usuário é induzido a autorizar uma sessão controlada pelo atacante. Por isso, a defesa precisa combinar controles técnicos, monitoramento comportamental, políticas de acesso condicional, revisão de consentimentos OAuth, educação de usuários, resposta a incidentes e governança contínua.

Índice

• O que é phishing por device code
• Como o caso EvilTokens explorou fluxos legítimos
• Por que o phishing por device code é crítico para empresas
• Principais riscos para Microsoft 365 e identidade em nuvem
• Boas práticas para prevenir phishing por device code
• Monitoramento, detecção e resposta a incidentes
• Governança, compliance e proteção de dados
• Evidências de maturidade e conformidade
• Exemplos práticos e cenários de ataque
• Plano de ação para organizações
• Perguntas frequentes sobre o tema

O que é phishing por device code

O phishing por device code é uma técnica de engenharia social que abusa de um fluxo legítimo de autenticação conhecido como device authorization flow. Esse fluxo foi criado para permitir login em dispositivos com capacidade limitada de entrada, como televisores, consoles, dispositivos IoT, equipamentos de reunião, terminais compartilhados ou interfaces sem navegador completo. Em um cenário legítimo, o dispositivo exibe um código e solicita que o usuário acesse uma página oficial de autenticação em outro aparelho, normalmente um computador ou celular, para inserir esse código e concluir o login.

O problema surge quando um atacante inicia esse fluxo em seu próprio ambiente e convence a vítima a inserir o código em uma página legítima do provedor de identidade. Como a página pode ser real, com domínio legítimo da Microsoft ou de outro provedor confiável, a vítima pode acreditar que está realizando uma autenticação segura. Ao concluir o processo, o usuário não está autenticando seu próprio dispositivo, mas autorizando a sessão iniciada pelo criminoso. O resultado pode ser a emissão de tokens de acesso e refresh tokens para aplicações como e-mail, calendário, arquivos, chats e APIs corporativas.

Esse tipo de ataque é especialmente perigoso porque não depende necessariamente da coleta direta da senha. Em muitos casos, a vítima realiza a autenticação completa, inclusive com MFA, em uma página oficial. A fraude está no contexto da autorização. O usuário acredita estar validando uma ação legítima, mas, na prática, concede ao atacante uma sessão autenticada. Isso torna o phishing por device code mais difícil de reconhecer por usuários e mais desafiador para controles tradicionais de segurança baseados apenas em bloqueio de páginas falsas.

Diferença entre phishing tradicional e phishing por device code

No phishing tradicional, o atacante geralmente cria uma página falsa para capturar credenciais. Em campanhas mais avançadas, pode usar proxies adversary-in-the-middle para capturar cookies de sessão e tokens. Já no phishing por device code, a interação pode acontecer com uma página legítima do provedor de identidade, o que reduz a eficácia de alguns filtros baseados em reputação de URL. A fraude ocorre porque o código informado pela vítima está vinculado a uma sessão controlada pelo atacante.

Por que esse fluxo existe

O fluxo por device code não é, por si só, uma falha. Ele atende a necessidades reais de usabilidade e interoperabilidade. A própria documentação da Microsoft descreve o fluxo de autorização de dispositivo em cenários nos quais o usuário precisa autenticar um dispositivo com entrada limitada. A questão de segurança está na exposição indevida desse fluxo, na falta de restrições contextuais e na ausência de monitoramento adequado. Mais informações técnicas podem ser consultadas na documentação oficial da Microsoft identity platform device authorization grant flow.

Em termos de governança, a pergunta central não é apenas se o fluxo deve existir, mas quando ele é necessário, para quais usuários, em quais aplicações, com quais condições e com qual nível de monitoramento. Organizações maduras tratam fluxos de autenticação como componentes críticos de segurança, não como configurações meramente operacionais.

Como o caso EvilTokens explorou fluxos legítimos

O caso EvilTokens ganhou destaque por combinar phishing como serviço, abuso de autenticação e exploração de confiança em plataformas amplamente utilizadas. Segundo informações públicas divulgadas pela Microsoft em seus canais de inteligência de ameaças e segurança, a operação foi interrompida após afetar milhares de contas. Embora detalhes técnicos possam variar conforme a campanha, a lógica do ataque se apoia em uma sequência relativamente simples: iniciar um fluxo legítimo de device code, persuadir a vítima a inserir o código e, depois, usar tokens obtidos para acessar recursos corporativos.

O modelo de phishing como serviço reduz a barreira de entrada para criminosos. Em vez de desenvolver toda a infraestrutura, o agente malicioso pode contratar ou utilizar uma plataforma que oferece kits, painéis, automação, modelos de mensagem, coleta de tokens e integração com canais de comunicação. Isso amplia a escala das campanhas e dificulta a defesa, pois múltiplos operadores podem usar táticas semelhantes contra diferentes organizações.

Etapas prováveis de uma campanha desse tipo

• Preparação da infraestrutura: o atacante configura contas, aplicações, scripts ou ferramentas para iniciar solicitações de device code.
• Geração do código: um código de dispositivo é criado pelo provedor de identidade para uma sessão controlada pelo criminoso.
• Engenharia social: a vítima recebe uma mensagem por e-mail, chat, SMS ou plataforma colaborativa solicitando que acesse uma página legítima e insira o código.
• Autenticação pela vítima: o usuário realiza login e pode aprovar MFA, acreditando estar concluindo uma solicitação corporativa válida.
• Emissão de tokens: a sessão do atacante recebe tokens que permitem acesso a aplicações e dados.
• Movimentação e exploração: o criminoso acessa e-mails, arquivos, contatos, histórico de conversas e eventualmente tenta escalar privilégios.
• Persistência e fraude: podem ocorrer criação de regras de caixa postal, exfiltração de dados, envio de novos phishings e tentativas de fraude financeira.

Essa sequência evidencia por que o phishing por device code precisa ser tratado como risco de identidade e não apenas como risco de e-mail. O ataque começa com engenharia social, mas o impacto depende da forma como a organização controla tokens, consentimentos, aplicações, políticas de acesso e logs.

O papel dos tokens de acesso

Tokens são artefatos de autenticação e autorização. Eles permitem que aplicações acessem recursos em nome do usuário, dentro de determinados escopos e por determinado período. Em arquiteturas modernas, tokens são fundamentais para integrações entre aplicações SaaS, APIs e serviços em nuvem. Quando obtidos indevidamente, no entanto, podem permitir acesso sem que o atacante precise conhecer a senha da vítima.

A gestão de tokens exige controles específicos. Revogar sessões, invalidar refresh tokens, revisar consentimentos OAuth, analisar aplicações autorizadas e investigar atividades posteriores ao comprometimento são ações essenciais. Em ambientes Microsoft, a segurança de identidade deve ser acompanhada por recursos como logs de entrada, logs de auditoria, alertas de risco, políticas de acesso condicional, proteção de identidade e soluções de detecção e resposta.

Por que o phishing por device code é crítico para empresas

O phishing por device code é crítico porque afeta diretamente o perímetro moderno das organizações: a identidade digital. Em ambientes baseados em nuvem, o acesso a e-mails, documentos, sistemas financeiros, repositórios de código, ferramentas de atendimento, plataformas de CRM e ambientes de colaboração depende de identidades e tokens. Quando uma conta corporativa é comprometida, o atacante pode ter acesso a uma quantidade significativa de informações sensíveis, mesmo sem invadir a rede interna tradicional.

Além disso, contas de e-mail corporativas continuam sendo um dos ativos mais valiosos para criminosos. Elas armazenam histórico de negociações, documentos, contratos, dados pessoais, informações financeiras, mensagens internas, contatos de clientes e fornecedores. Uma caixa de entrada comprometida pode servir como ponto de partida para fraudes de pagamento, golpes contra fornecedores, alteração de dados bancários, vazamento de dados e novas campanhas de phishing com alto grau de credibilidade.

Impacto para a alta liderança

Para conselhos, diretorias e comitês executivos, o caso EvilTokens reforça que a segurança da informação não pode ser tratada como tema exclusivamente técnico. A exploração de fluxos legítimos de autenticação envolve decisões de risco, governança de acesso, investimentos em detecção, processos de resposta a incidentes, cultura organizacional e conformidade regulatória. Um ataque bem-sucedido pode gerar perdas financeiras, interrupção de operações, sanções contratuais, incidentes de privacidade e danos reputacionais.

A alta liderança deve exigir indicadores de maturidade em segurança de identidade, como percentual de usuários protegidos por MFA resistente a phishing, cobertura de acesso condicional, tempo médio de revogação de sessões comprometidas, volume de consentimentos OAuth revisados, número de aplicações não verificadas bloqueadas e efetividade de treinamentos contra engenharia social.

Relação com proteção de dados e LGPD

Quando uma conta é comprometida, pode haver acesso indevido a dados pessoais. Dependendo do contexto, isso pode configurar incidente de segurança envolvendo dados pessoais e exigir avaliação conforme a Lei Geral de Proteção de Dados. A LGPD estabelece princípios como segurança, prevenção, responsabilização e prestação de contas. Organizações devem demonstrar que adotam medidas técnicas e administrativas aptas a proteger dados pessoais contra acessos não autorizados e situações acidentais ou ilícitas.

O phishing por device code pode atingir dados de colaboradores, clientes, pacientes, alunos, fornecedores e parceiros. Portanto, a resposta não deve ficar restrita ao time de TI. Privacidade, jurídico, compliance, comunicação, auditoria, gestão de riscos e áreas de negócio precisam participar quando houver potencial exposição de dados pessoais ou informações estratégicas.

Principais riscos para Microsoft 365 e identidade em nuvem

Ambientes Microsoft 365 concentram serviços essenciais. Exchange Online, SharePoint, OneDrive, Teams, Entra ID e aplicações integradas podem ser acessados por diferentes dispositivos, locais e aplicações. Essa flexibilidade é positiva para produtividade, mas exige governança de segurança robusta. O phishing por device code explora exatamente a confiança depositada em fluxos de identidade e na familiaridade dos usuários com solicitações de login.

Comprometimento de caixas de entrada

O acesso a e-mails permite ao atacante entender processos internos, identificar executivos, mapear fornecedores, localizar faturas, acompanhar negociações e interceptar comunicações. Uma técnica comum após o comprometimento é a criação de regras de encaminhamento ou ocultação de mensagens, para manter persistência e reduzir a chance de detecção. Regras que movem mensagens para pastas incomuns, excluem alertas, encaminham e-mails externamente ou marcam mensagens como lidas devem ser monitoradas.

Abuso de OAuth e consentimentos indevidos

Aplicações OAuth podem solicitar permissões para ler e-mails, acessar arquivos, enviar mensagens ou consultar diretórios. Em ambientes mal governados, usuários podem consentir aplicações de terceiros sem avaliação. Isso abre caminho para persistência mesmo após troca de senha. A revisão de consentimentos e a restrição de permissões são controles essenciais contra ataques que abusam de identidade.

Movimentação lateral em SaaS

Uma conta comprometida pode ser usada para acessar outros sistemas por single sign-on. O atacante pode buscar documentos sensíveis, repositórios de código, sistemas financeiros, plataformas de atendimento e ferramentas administrativas. O risco aumenta quando há permissões excessivas, ausência de segregação de funções e falta de revisão periódica de acessos.

Fraude financeira e BEC

Business Email Compromise continua sendo um risco significativo. Com acesso real a uma caixa postal, o criminoso pode responder conversas existentes, alterar instruções de pagamento, solicitar urgência em transferências ou criar mensagens convincentes para áreas financeiras. O phishing por device code pode ser apenas a etapa inicial de uma fraude mais ampla.

Boas práticas para prevenir phishing por device code

A prevenção contra phishing por device code exige uma combinação de controles. Não basta treinar usuários, assim como não basta habilitar MFA de forma genérica. O objetivo deve ser reduzir a superfície de ataque, restringir fluxos desnecessários, fortalecer a autenticação, monitorar anomalias e criar processos de resposta rápida.

Restringir ou controlar o fluxo de device code

Organizações devem avaliar se o fluxo por device code é realmente necessário para seus usuários. Em muitos ambientes corporativos, seu uso pode ser limitado a grupos específicos, aplicações aprovadas ou cenários gerenciados. Quando possível, políticas devem bloquear ou restringir esse tipo de autenticação para contas sensíveis, administradores, executivos e usuários de alto risco.

Essa decisão deve ser baseada em análise de impacto. Há empresas que dependem de dispositivos compartilhados, salas de reunião e equipamentos com entrada limitada. Nesses casos, a solução não é simplesmente desabilitar tudo, mas aplicar controles contextuais, inventário de dispositivos, gestão de exceções, documentação de justificativas e monitoramento dedicado.

Adotar MFA resistente a phishing

Nem todo MFA oferece o mesmo nível de proteção. Métodos baseados em aprovação simples por push, SMS ou códigos temporários podem ser vulneráveis a fadiga de MFA, engenharia social e ataques de proxy. Métodos resistentes a phishing, como chaves FIDO2, passkeys com validação de origem, certificados de dispositivo e autenticação vinculada ao canal, reduzem o risco de aprovação indevida.

A adoção deve priorizar administradores, equipes financeiras, jurídico, RH, tecnologia, executivos e usuários com acesso a dados sensíveis. A evolução pode ser gradual, mas deve estar vinculada a metas claras, orçamento, comunicação interna e suporte operacional.

Fortalecer políticas de acesso condicional

Políticas de acesso condicional permitem decisões baseadas em risco, localização, dispositivo, aplicação, grupo, tipo de cliente e nível de autenticação. Para reduzir o risco de phishing por device code, a organização pode exigir dispositivos conformes, bloquear países não utilizados, impor autenticação forte para aplicações críticas, restringir clientes legados e responder automaticamente a sinais de risco.

É importante evitar políticas excessivamente permissivas por conveniência. Exceções devem ter dono, justificativa, prazo de validade e revisão periódica. Uma exceção permanente pode se tornar o elo fraco do ambiente.

Governar consentimentos OAuth

O consentimento de aplicações deve ser tratado como processo de segurança. Usuários não deveriam conceder permissões amplas a aplicações desconhecidas sem avaliação. Boas práticas incluem bloquear consentimento de usuário para aplicações não verificadas, exigir aprovação administrativa para escopos sensíveis, manter inventário de aplicações autorizadas e revisar permissões periodicamente.

Capacitar usuários com exemplos reais

Treinamentos genéricos sobre phishing são insuficientes. Os usuários precisam reconhecer situações específicas, como pedidos para inserir códigos de dispositivo, solicitações inesperadas de login, mensagens com urgência injustificada e instruções fora do processo padrão. Simulações controladas podem ajudar, desde que conduzidas com ética, foco educativo e respeito aos colaboradores.

Monitoramento, detecção e resposta a incidentes

Mesmo com bons controles preventivos, organizações devem assumir que tentativas de phishing por device code ocorrerão. A capacidade de detectar rapidamente e responder de forma coordenada reduz impacto. Isso exige logs adequados, casos de uso no SIEM, integração com EDR/XDR, playbooks de resposta e responsabilidades definidas.

Sinais de alerta em logs de autenticação

• Autenticações usando fluxo de device code fora do padrão esperado.
• Logins bem-sucedidos a partir de localizações incomuns ou endereços IP de reputação duvidosa.
• Uso de aplicações desconhecidas com permissões sensíveis.
• Sequências de login com MFA aprovado após mensagem suspeita reportada.
• Acesso a e-mail seguido de criação de regras de encaminhamento.
• Downloads incomuns em massa de arquivos no OneDrive ou SharePoint.
• Envio de grande volume de mensagens externas após login anômalo.

Resposta imediata a conta suspeita

Quando houver suspeita de comprometimento, a organização deve agir rapidamente. Medidas comuns incluem revogar sessões, redefinir credenciais quando aplicável, exigir novo MFA, remover consentimentos indevidos, bloquear aplicações suspeitas, revisar regras de caixa postal, analisar mensagens enviadas, preservar evidências e avaliar exposição de dados. Em contas privilegiadas, a resposta deve ser ainda mais rigorosa, incluindo revisão de alterações administrativas e rotação de segredos.

Playbook recomendado

Integração com NIST e CIS Controls

O tema dialoga diretamente com o NIST Cybersecurity Framework, especialmente nas funções Identificar, Proteger, Detectar, Responder e Recuperar. Também se relaciona com os CIS Controls, incluindo gestão de contas, controle de acesso, proteção de e-mail e navegador, monitoramento de logs, resposta a incidentes e conscientização em segurança.

A organização deve traduzir esses referenciais em controles práticos. Por exemplo, inventariar aplicações OAuth, proteger contas administrativas, habilitar logs, revisar permissões, treinar usuários e testar resposta a incidentes são medidas alinhadas a boas práticas reconhecidas internacionalmente.

Governança, compliance e proteção de dados

A governança de segurança deve estabelecer papéis, responsabilidades, políticas, critérios de risco e mecanismos de prestação de contas. O phishing por device code não é apenas uma técnica de ataque; é um teste da maturidade organizacional em identidade, privacidade, compliance e gestão de riscos. Empresas que não sabem quais aplicações têm acesso aos dados, quem pode consentir permissões e como revogar sessões rapidamente estão expostas a incidentes recorrentes.

Políticas corporativas necessárias

• Política de identidade e acesso: define requisitos de autenticação, MFA, acesso condicional, contas privilegiadas e revisão de acessos.
• Política de uso de aplicações SaaS: estabelece critérios para aprovação, integração, consentimento OAuth e monitoramento.
• Política de segurança de e-mail: orienta proteção contra phishing, regras de encaminhamento, autenticação de domínio e resposta a abuso.
• Política de resposta a incidentes: determina classificação, escalonamento, comunicação, preservação de evidências e lições aprendidas.
• Política de proteção de dados: conecta incidentes técnicos à avaliação de impacto em dados pessoais e obrigações legais.

Relação com ISO 27001 e ISO 27002

A ISO/IEC 27001 exige abordagem sistemática para gestão de segurança da informação com base em riscos. O caso EvilTokens se relaciona com controles de gestão de identidade, controle de acesso, conscientização, gestão de incidentes, segurança em nuvem, relacionamento com fornecedores e monitoramento. A ISO/IEC 27002 oferece orientações para implementação de controles que podem apoiar a proteção contra phishing avançado e abuso de autenticação.

Em uma auditoria, a empresa deve demonstrar que conhece seus riscos, implementa controles proporcionais, monitora sua efetividade e melhora continuamente. Não é suficiente afirmar que usa MFA; é preciso evidenciar que o MFA é adequado ao risco, que exceções são controladas e que eventos suspeitos são tratados.

Privacidade desde a concepção

Aplicações integradas ao Microsoft 365 podem acessar dados pessoais em larga escala. Por isso, processos de privacy by design devem avaliar permissões solicitadas, finalidade, base legal, minimização de dados, retenção, compartilhamento com terceiros e capacidade de revogação. Uma aplicação que solicita leitura completa de e-mails para uma finalidade limitada deve ser questionada. O princípio da necessidade, previsto na LGPD, recomenda limitar o tratamento ao mínimo necessário.

Evidências de maturidade e conformidade

Para demonstrar maturidade, a organização precisa manter evidências verificáveis. Evidência não é apenas uma política publicada; é a prova de que a política funciona na prática. No contexto de phishing por device code, auditores, reguladores, clientes e parceiros podem solicitar demonstrações de controle sobre identidade, autenticação, consentimentos, logs e resposta a incidentes.

Evidências técnicas

• Relatórios de políticas de acesso condicional ativas e testadas.
• Lista de métodos de MFA permitidos e percentual de adoção por grupo de risco.
• Inventário de aplicações OAuth, permissões concedidas e responsáveis de negócio.
• Logs de autenticação retidos pelo período definido em política.
• Alertas de device code, consentimento anômalo e login de risco configurados no SIEM.
• Histórico de revogação de sessões e bloqueio de aplicações suspeitas.
• Relatórios de revisão de regras de encaminhamento em caixas postais.

Evidências de governança

• Atas de comitês de segurança ou risco discutindo ameaças de identidade.
• Matriz de responsabilidades entre segurança, TI, privacidade, jurídico e negócio.
• Processo formal para aprovação de aplicações SaaS e consentimentos OAuth.
• Registros de treinamento e campanhas de conscientização com foco em engenharia social.
• Resultados de testes de resposta a incidentes e exercícios de mesa.
• Planos de ação acompanhados com prazos, responsáveis e status.

Indicadores úteis

Exemplos práticos e cenários de ataque

Exemplos práticos ajudam a compreender como o phishing por device code aparece no cotidiano. Abaixo estão cenários realistas, sem instruções operacionais ofensivas, úteis para treinamento, gestão de riscos e desenho de controles defensivos.

Cenário 1: mensagem falsa de suporte interno

Um colaborador recebe uma mensagem em nome do suporte de TI informando que sua conta precisa ser validada para continuar acessando o e-mail corporativo. A mensagem orienta o usuário a acessar uma página legítima de login e inserir um código. Como o domínio é verdadeiro e o usuário já está acostumado a autenticações frequentes, ele conclui o processo. Minutos depois, o atacante acessa a caixa postal, pesquisa termos como “invoice”, “pagamento”, “contrato” e “banco”, e começa a preparar uma fraude.

Controles aplicáveis incluem treinamento específico, bloqueio ou restrição do fluxo de device code, alertas para autenticações incomuns, revisão de regras de caixa postal e validação de solicitações de suporte por canais oficiais.

Cenário 2: executivo em viagem

Um executivo em viagem recebe uma mensagem urgente aparentemente enviada por um parceiro estratégico. O texto afirma que é necessário autenticar o acesso a um documento compartilhado. O executivo usa o celular, aprova o login e não percebe que autorizou uma sessão indevida. Como executivos costumam ter acesso a informações estratégicas, o impacto pode envolver planos de fusão, dados financeiros, negociações e comunicações confidenciais.

Nesse caso, a organização deveria aplicar autenticação resistente a phishing para executivos, acesso condicional baseado em risco, proteção contra links suspeitos, classificação de dados e monitoramento de download anômalo.

Cenário 3: aplicação OAuth com permissões excessivas

Um usuário autoriza uma aplicação aparentemente relacionada a produtividade. A aplicação solicita permissões amplas para ler e enviar e-mails. Mesmo após a troca de senha, a aplicação continua autorizada até que o consentimento seja revogado. Esse cenário mostra por que a gestão de consentimentos OAuth é tão importante quanto a gestão de senhas.

Boas práticas incluem bloquear consentimentos de usuário para permissões sensíveis, exigir aprovação administrativa, manter inventário de aplicações, revisar escopos e remover integrações sem finalidade clara.

Cenário 4: fornecedor comprometido

Um fornecedor tem uma conta comprometida e envia mensagens legítimas a clientes solicitando autenticação para visualizar documentos. Como a relação comercial existe, a taxa de confiança é maior. Esse cenário reforça a importância da gestão de terceiros, validação de comunicações críticas e processos independentes para alterações financeiras ou compartilhamento de dados sensíveis.

A segurança da informação deve considerar a cadeia de suprimentos digital. Um controle interno forte pode ser enfraquecido por um parceiro com baixa maturidade. Contratos, due diligence, requisitos de segurança e comunicação de incidentes são partes essenciais da resposta.

Plano de ação para organizações

Um plano de ação eficaz contra phishing por device code deve ser realista, priorizado por risco e acompanhado pela liderança. A seguir está uma abordagem em etapas para organizações de diferentes níveis de maturidade.

Primeiros 30 dias

• Mapear se o fluxo de device code está sendo utilizado e por quais usuários ou aplicações.
• Revisar logs recentes de autenticação em busca de eventos incomuns.
• Identificar aplicações OAuth com permissões sensíveis e sem dono definido.
• Bloquear consentimentos de usuário para aplicações não verificadas, quando viável.
• Priorizar contas administrativas e executivas para controles adicionais.
• Criar comunicação interna alertando sobre solicitações inesperadas de códigos de dispositivo.
• Definir um playbook mínimo para revogação de sessões e remoção de consentimentos indevidos.

De 30 a 90 dias

• Implementar ou revisar políticas de acesso condicional para aplicações críticas.
• Ampliar MFA resistente a phishing para grupos de maior risco.
• Integrar logs de identidade ao SIEM e criar casos de uso específicos.
• Formalizar workflow de aprovação para aplicações SaaS e OAuth.
• Realizar exercício de mesa simulando comprometimento de conta por phishing por device code.
• Revisar retenção de logs, papéis de resposta e critérios de notificação de incidentes.

De 90 a 180 dias

• Estabelecer indicadores recorrentes para comitê de risco ou segurança.
• Executar revisão completa de permissões e aplicações integradas ao ambiente Microsoft 365.
• Automatizar respostas para eventos de alto risco, como revogação de sessão e bloqueio temporário.
• Conduzir campanha de conscientização baseada em cenários reais.
• Avaliar aderência a ISO 27001, NIST CSF e CIS Controls.
• Integrar requisitos de segurança de identidade em contratos com terceiros relevantes.

Recomendações para continuidade de negócios

Embora o phishing por device code seja um tema de identidade, ele pode afetar a continuidade de negócios. Uma fraude financeira, vazamento de dados ou comprometimento de contas críticas pode interromper processos essenciais. O plano de continuidade deve considerar indisponibilidade ou bloqueio emergencial de contas, necessidade de comunicação alternativa, procedimentos manuais de aprovação financeira e recuperação de caixas postais comprometidas.

Testes periódicos são importantes. A organização deve saber como operar se precisar suspender temporariamente acessos, bloquear integrações ou revogar sessões em massa. Sem testes, decisões emergenciais podem ser lentas, contraditórias ou excessivamente dependentes de pessoas específicas.

Recomendações para DevSecOps e nuvem

Times de desenvolvimento e nuvem também são impactados. Contas comprometidas podem acessar repositórios de código, pipelines, segredos, ambientes de teste e consoles de administração. DevSecOps deve incluir controles de identidade, mínimo privilégio, segregação de ambientes, proteção de segredos, revisão de tokens de API, monitoramento de alterações em pipelines e uso de identidades gerenciadas sempre que possível.

Em ambientes multicloud, a identidade federada pode ampliar o impacto de um ataque. Uma conta comprometida no provedor de identidade corporativo pode abrir portas para AWS, Azure, Google Cloud, GitHub, Jira, ServiceNow e outras plataformas. Por isso, a proteção contra phishing por device code deve ser parte da estratégia ampla de segurança em nuvem.

O caso EvilTokens demonstra que a evolução dos ataques acompanha a evolução dos ambientes corporativos. À medida que empresas adotam autenticação moderna, SaaS e colaboração em nuvem, criminosos procuram explorar fluxos legítimos, permissões excessivas e lacunas de governança. A resposta não deve ser pânico nem confiança excessiva em um único controle, mas maturidade progressiva, baseada em risco e evidências.

Organizações que tratam identidade como perímetro estratégico estão mais preparadas para enfrentar esse tipo de ameaça. Isso inclui restringir fluxos desnecessários, adotar MFA resistente a phishing, monitorar tokens e consentimentos, revisar aplicações OAuth, treinar usuários com exemplos concretos, integrar logs ao processo de detecção e manter playbooks de resposta testados. Também significa envolver jurídico, privacidade, compliance, auditoria, fornecedores e liderança de negócio.

O phishing por device code não elimina a importância de controles tradicionais, mas evidencia que eles precisam ser atualizados. Segurança da informação, cibersegurança e proteção de dados dependem cada vez mais de governança de identidade, visibilidade em nuvem e capacidade de resposta. O caso EvilTokens deve ser usado como oportunidade para revisar processos, fortalecer controles e elevar a maturidade em segurança de forma sustentável.

Perguntas frequentes sobre o tema