O phishing de consentimento está se consolidando como uma das ameaças mais perigosas do cenário moderno de segurança digital, principalmente por contornar expectativas tradicionais de proteção baseadas em senha e autenticação multifator (MFA). Diferente do phishing clássico, que depende do roubo direto de credenciais, esse novo modelo explora algo muito mais sutil: o consentimento legítimo do usuário para acesso a dados e serviços.
Nesse contexto surge a plataforma EvilTokens, associada a campanhas de abuso de OAuth e exploração de tokens de atualização, demonstrando como atacantes não precisam mais “quebrar” autenticações, mas sim convencê-las a autorizar o acesso. O resultado é um cenário em que a invasão acontece sem alertas tradicionais de segurança.
O objetivo deste artigo é explicar em profundidade como funciona o phishing de consentimento, por que ele consegue ignorar a MFA e como os chamados ataques com tokens persistentes criam um novo paradigma de risco. Também vamos abordar o conceito de “combinações tóxicas de permissões”, além do impacto crescente de agentes de IA e protocolos como o MCP (Model Context Protocol) na ampliação da superfície de ataque.
No centro dessa mudança está uma realidade desconfortável: os atacantes não querem mais apenas senhas, eles querem acesso contínuo e autorizado.
O que é o phishing de consentimento e como ele funciona
O phishing de consentimento é um tipo de ataque que explora fluxos legítimos de autorização, especialmente aqueles baseados em OAuth 2.0 e login de dispositivos. Em vez de roubar credenciais diretamente, o atacante induz o usuário a conceder permissões a um aplicativo malicioso.
Um dos vetores mais comuns envolve o fluxo de autenticação de dispositivos, como o endpoint /device login. Nele, o usuário é direcionado a uma página legítima de login de uma plataforma confiável (como Microsoft, Google ou serviços SaaS corporativos). O detalhe crítico é que, nesse processo, o usuário não está entregando apenas sua identidade, mas também autorizando escopos de acesso.
Quando o usuário aceita permissões de um aplicativo controlado por um ator malicioso, ferramentas como a suposta EvilTokens podem capturar e reutilizar tokens de atualização (refresh tokens). Esses tokens permitem acesso contínuo aos recursos sem necessidade de nova autenticação.
Na prática, isso significa que o atacante pode manter acesso persistente ao ambiente da vítima mesmo após mudanças de senha ou redefinições de segurança.
Por que a autenticação multifator não impede o ataque?
A grande confusão em torno do phishing de consentimento está no fato de que ele não quebra a autenticação multifator (MFA). Na realidade, ele a contorna completamente.
Isso acontece porque o fluxo de ataque ocorre dentro de um ambiente legítimo. O usuário faz login normalmente, insere seu segundo fator de autenticação e, em seguida, aprova um pedido de permissão que parece inofensivo. A MFA cumpre exatamente o seu papel, validar a identidade no momento do login.
O problema é o que acontece depois: o sistema emite um token de acesso e um token de atualização, e é esse segundo elemento que garante persistência ao atacante.
Além disso, muitas soluções de monitoramento e SIEM tradicionais não detectam essa atividade como suspeita, já que o acesso vem de um aplicativo “autorizado”. Em outras palavras, o ataque não parece um ataque, ele parece uma integração legítima.
O perigo da persistência dos tokens de atualização
O ponto mais crítico desse tipo de ataque está nos tokens de atualização (refresh tokens). Diferente de uma senha, esses tokens não expiram imediatamente e podem permanecer válidos por longos períodos.
Isso cria um cenário preocupante: mesmo que a senha seja alterada ou a MFA seja reforçada, o token pode continuar funcionando até que seja explicitamente revogado.
Em muitos ambientes corporativos, a revogação de tokens não é tratada com a mesma urgência da troca de credenciais. Isso abre uma janela de persistência silenciosa, onde o atacante mantém acesso contínuo a e-mails, arquivos e APIs.
O phishing de consentimento transforma, portanto, a confiança inicial do usuário em um vetor de ataque de longo prazo.
A normalização do clique e as combinações tóxicas
Nos últimos anos, usuários e administradores foram condicionados a aceitar solicitações de permissões como parte natural da experiência digital. Extensões de navegador, integrações SaaS e agora agentes de IA dependem desse modelo de consentimento contínuo.
Esse comportamento criou um ambiente onde o “clique para permitir” se tornou banal, reduzindo drasticamente a percepção de risco.
O que são combinações tóxicas de permissões?
As chamadas combinações tóxicas de permissões surgem quando múltiplos aplicativos, cada um com escopos aparentemente limitados, são combinados dentro de um mesmo usuário ou tenant.
Isoladamente, cada permissão pode parecer inofensiva. Um app acessa e-mails, outro acessa arquivos, outro gerencia calendário. No entanto, quando essas permissões são combinadas, criam uma visão completa do ambiente corporativo.
O problema central é que auditorias tradicionais analisam permissões de forma isolada, e não como um conjunto de capacidades interconectadas.
No contexto do phishing de consentimento, isso significa que um único consentimento malicioso pode se tornar a chave para múltiplos vetores de exfiltração de dados.
O papel dos agentes de IA e do protocolo MCP
A expansão de agentes de IA corporativos adiciona uma nova camada de complexidade a esse cenário. Com o avanço de integrações baseadas no Model Context Protocol (MCP), sistemas de IA podem acessar ferramentas, APIs e dados corporativos de forma dinâmica.
Isso é poderoso do ponto de vista produtivo, mas também amplia drasticamente a superfície de ataque.
Um agente de IA comprometido, ou um conector MCP mal configurado, pode herdar permissões extensas de um usuário humano. Se esse acesso estiver ligado a tokens de longa duração, o risco se multiplica.
O resultado é um ecossistema onde humanos, aplicações e agentes automatizados compartilham o mesmo espaço de confiança, tornando o abuso de OAuth ainda mais difícil de detectar.
Como se proteger do abuso de concessões OAuth
Mitigar o phishing de consentimento exige uma mudança de mentalidade: sair do foco exclusivo em autenticação e migrar para governança de consentimento.
Algumas práticas essenciais incluem:
- Implementar inventário contínuo de aplicações OAuth, com visibilidade completa de todos os apps autorizados no ambiente.
- Restringir consentimentos de usuários finais, permitindo apenas aprovação administrativa centralizada para aplicativos sensíveis.
- Aplicar políticas de acesso condicional para consentimento, exigindo validação adicional para novos apps ou escopos elevados.
- Reduzir a vida útil de tokens de atualização, forçando reautenticação periódica.
- Manter playbooks de resposta rápida para revogação de tokens e aplicações OAuth comprometidas.
- Monitorar padrões anômalos de uso de APIs, especialmente acessos fora do comportamento habitual do usuário.
Essas medidas não eliminam o risco, mas reduzem significativamente a janela de exploração de ataques baseados em consentimento.
Conclusão e o futuro da segurança de identidade
O cenário atual mostra claramente que a segurança de identidade não pode mais ser definida apenas pelo momento do login. O verdadeiro campo de batalha está na camada de consentimento contínuo, onde usuários autorizam silenciosamente o acesso a sistemas críticos.
O phishing de consentimento representa essa mudança de paradigma: ataques que não quebram autenticação, mas exploram a própria lógica de autorização moderna baseada em tokens.
Para organizações, isso significa uma necessidade urgente de revisar como permissões são concedidas, monitoradas e revogadas. A confiança não pode mais ser estática, ela precisa ser continuamente verificada.
Como próximo passo, vale revisar quais aplicativos de terceiros têm acesso ao seu ambiente corporativo, entender seus escopos reais e questionar se todas essas permissões ainda são necessárias.
