Phishing de consentimento: o novo vetor que rouba tokens OAuth e expande o acesso

Em fevereiro de 2026 emergiu um serviço que resume a evolução do phishing: EvilTokens. Em menos de cinco semanas, esta plataforma de phishing-as-a-service comprometeu mais de 340 organizações que usam a Microsoft 365 em cinco países, não roubando senhas, mas solicitando um consentimento OAuth aparentemente inocuo em microsoft.com/devicelogin. O usuário completava seu MFA legítimo, clicava em OK e retornava à sua tarefa com a sensação de ter verificado um início de sessão rotineira; o atacante, em vez disso, levava-se um refresh token válido e renovável com acesso a correio, calendário, unidade e contatos, que perdurava enquanto a política do tenant o permitisse.

A mecânica do ataque revela uma ruptura conceitual: a camada de consentimento OAuth mantém-se fora do perímetro que muitas organizações protegem com rigor. Enquanto o roubo de credenciais provoca sinais reconhecíveis (reintes, correlações de sessão, pedidos de locais anómalas) um grant OAuth legítimo é indistinguível da operação normal do fornecedor de identidade; está assinado, leva scopes que o usuário aceitou e não gera o tipo de evento que as SIEMs tradicionais consideram suspeito. O resultado é o que a comunidade chama consent phishing u OAuth grant abuse, um vetor que explora a confiança do usuário e o desenho do protocolo. Para entender a sua base técnica, convém repassar o padrão: OAuth 2.0 (RFC 6749).

Duas propriedades tornam especialmente potente este abuso: a primeira, que a autenticação e o MFA ocorrem no domínio legítimo, pelo que os controles anti-phishing centrados em credenciais falham; a segunda, que os refresh tokens estendem a janela de exposição e muitas vezes sobrevivem a mudanças de senha. A consequência prática: um atacante não precisa reproduzir uma sessão humana ou sortear MFA, porque obteve um artefato de acesso com a mesma validade que o resto do ecossistema confia em usar automaticamente.

O ecossistema atual amplifica o problema. Os trabalhadores recebem uma avalanche mensal de pedidos de consentimento: agentes de IA que se integram com calendários, extensões de navegador que exigem acesso a contas SaaS, conectores que unem aplicações de terceiros. A linguagem dos scopes – “Leer o seu e-mail”, “Acceder a arquivos quando você não está presente” – esconde um alcance operacional amplo: cada scope costuma traduzir-se em acesso a todas as mensagens, anexos, arquivos compartilhados e recursos aos quais o usuário pode chegar. Essa lacuna entre etiqueta e capacidade é o espaço onde atacantes como os operadores de EvilTokens se movem.

O risco verdadeiro não é apenas o acesso isolado a uma conta, mas as combinações tóxicas que emergem quando as permissões aparentemente benignos se interconectam através de uma identidade humana. Um usuário concede a um assistente de reuniões acesso ao calendário e ao correio, depois autoriza outro agente ao drive compartilhado e um terceiro serviço ao CRM; nenhuma dessas aprobações foi desenhada para interoperar, mas juntas criam uma ponte que permite a um atacante pivotar entre informações confidenciais, contratos e dados de clientes. Estas “combinações tóxicas” não aparecem nos logs de uma única aplicação porque a conexão ocorre fora do domínio de qualquer dono de aplicação.

Uma nova frente emergente são os Model Context Protocol (MCP) e servidores equivalentes que facilitam agentes de IA adquirir alcance através do mesmo mecanismo de confiança única que os consent screens exploram. Já vimos eventos em escala por mecanismos semelhantes: em 2025 uma cadeia de concessões legítimas permitiu que um conector comprometido se propagar entre centenas de tenants da Salesforce, mostrando que a cascata de OAuth pode converter uma concessão isolada em uma infecção massiva.

Fechar esta lacuna exige alterar a forma como o consentimento é governado: os grants OAuth e as ligações de agentes da IA com a mesma disciplina que se aplica à autenticação. Isso significa políticas que limitem a delegação automática, revogação ágil de tokens a nível de aplicação, monitorização contínua do grafo de identidades e concessões, e medidas técnicas que reduzam a longevidade dos refresh Tokens. A Microsoft e outros fornecedores publicam diretrizes sobre fluxos como o Device Code e como os tokens devem ser geridos corretamente; consultar ajuda a entender as opções de configuração: Azure AD — OAuth 2.0 Device Code.

Além de ajustar configurações, as organizações devem incorporar detecção e visibilidade em tempo real sobre o runtime do consentimento. Ferramentas que mapeam um grafo de identidades e concessões no momento da sua criação facilitam ver pontes inesperadas, tokens sem uso ou desvios de política antes de se tornarem um incidente. A integração entre governança de identidade, detecção de ameaças e controle de agentes de IA torna-se prioritária para reduzir a janela de exposição e automatizar a remediação: desde revogar um grant comprometido até disparar reconsentimento forçado ou aplicar políticas condicionadas por risco.

No operacional, os equipamentos de segurança devem exigir aprovação administrativa para aplicações com scopes elevadas, aplicar princípios de menor privilégio nas aprobações por defeito, limitar a duração de refresh tokens quando o fornecedor o permita e habilitar a supervisão de atividades invulgares das aplicações (por exemplo, exportações maciças ou acessos fora de horário). A formação continua a ser necessária, mas já não bastará instruir os usuários a não clicar: é preciso que o ambiente tecnológico faça difícil autorizar permissões amplas por erro.

Por último, o fenômeno obriga a repensar a responsabilidade: a superfície de risco é um grafo que nenhuma aplicação individual controla por completo. É por isso que a mitigação efetiva combina controlos de plataforma (configurações de tenant, políticas de acesso condicional), ferramentas que observam o grafo de consentimento em tempo real e processos organizacionais que reduzam a velocidade a que se podem criar pontes (provisão de agentes, processos de aprovação, verificação de fornecedores). O tempo de reação deve ser encurtado desde semanas e auditorias periódicas a minutos e filas operacionais contíguas à emissão do grant.

O modelo de ameaças evoluiu: já não só defendemos credenciais, defendemos o ato de conceder licenças. Tratar o consentimento como recurso crítico e aplicar visibilidade, limitação e revogação com a mesma prioridade que ao controle de acessos e MFA é a linha de defesa que impede que serviços como EvilTokens deixem de ser a exceção e se tornem rotineiras.