O Novo Phishing Click

O Novo Phishing Click: Como o Consentimento OAuth Ignora a Autenticação Multifator (MFA)

Em fevereiro de 2026, uma plataforma de phishing como serviço (PhaaS) chamada EvilTokens entrou em operação. Em cinco semanas, ela comprometeu mais de 340 organizações do Microsoft 365 em cinco países.

Os alvos da plataforma receberam uma mensagem solicitando que inserissem um código curto em microsoft.com/devicelogin e concluíssem o processo de autenticação multifator (MFA) padrão, acreditando, em seguida, que haviam verificado um login de rotina. Na verdade, haviam fornecido ao operador um token de atualização válido, com escopo para sua caixa de correio, unidade, calendário e contatos, e com a duração de uma política de locatário, e não de uma sessão.

O operador nunca precisou de uma senha, nunca acionou uma solicitação de autenticação multifator (MFA) e nunca gerou um evento de login que parecesse uma intrusão. O ataque foi bem-sucedido porque a tela de consentimento do OAuth se tornou um clique instintivo, e os controles criados para impedir o phishing de credenciais não consideram a camada de consentimento.

Pesquisadores de segurança chamam a condição resultante de phishing de consentimento ou abuso de concessão OAuth. O clique de phishing que importava na década passada fornecia uma senha. O clique de phishing que importa agora fornece um token de atualização e está estruturalmente abaixo dos controles de identidade que a maioria das organizações ainda considera como perímetro.

Por que a MFA não consegue ver uma concessão OAuth?

Um ataque de phishing de credenciais fornece um nome de usuário e senha que precisam ser reproduzidos em algum lugar, e a maioria dos sistemas de gerenciamento de identidade agora exige uma segunda autenticação nesse momento. Até mesmo kits de ataque do tipo “adversário no meio” (AiTM) geram um cookie de sessão vinculado a um evento de login, que o SIEM correlaciona com dados geográficos, de dispositivos e padrões de deslocamento.

Figura 1: O phishing de credenciais deixa um rastro de login que o SIEM pode correlacionar.

Uma concessão OAuth não gera credenciais repetidas. O usuário se autentica no provedor de identidade legítimo, conclui o desafio MFA no domínio legítimo e clica em Aceitar. O token que o atacante obtém é o sistema funcionando conforme projetado. Ele é assinado pelo provedor de identidade, tem escopo limitado ao que o usuário concordou e pode ser atualizado. O MFA não pode bloqueá-lo porque a autenticação já foi realizada.

Figura 2: Uma concessão OAuth não deixa nenhum registro de resposta, apenas um token atualizável.

O outro problema é que os tokens de atualização estendem o período de validade. Os tokens emitidos pela EvilTokens sobreviveram a redefinições de senha e permaneceram válidos por semanas ou meses, dependendo da configuração do locatário. A rotação da senha não invalidava a concessão. Somente a revogação explícita ou uma política de acesso condicional que exigisse novo consentimento a encerrava.

Esse vetor de ataque existe desde que o OAuth se tornou padrão. O que mudou foi o ambiente em que ele opera. Os usuários foram condicionados a clicar em telas de consentimento com a mesma frequência com que clicavam em banners de cookies. Todo agente de IA instala o Surface One. Toda integração de produtividade o utiliza. Toda extensão de navegador que interage com uma conta SaaS o utiliza. O volume de consentimentos legítimos que um profissional do conhecimento vê em um mês excede qualquer coisa que existia quando os modelos de ameaça originais do OAuth foram criados.

Os próprios escopos usam uma linguagem que não se correlaciona claramente com o risco. Um escopo chamado “Ler seus e-mails” soa limitado, mas na prática abrange todas as mensagens, anexos e conversas compartilhadas às quais o usuário pode acessar. Um escopo chamado “Acessar arquivos quando você não estiver presente” significa um token de longa duração emitido sem que o usuário precise estar em frente a uma tela para revogá-lo. A lacuna entre a linguagem do consentimento e o alcance operacional é exatamente onde os atacantes atuam.

Combinações tóxicas formam-se abaixo do proprietário do aplicativo

Um único consentimento OAuth concede a um invasor uma entrada limitada dentro de uma aplicação. O risco aumenta quando essas entradas se interligam.

Um usuário da área financeira concede acesso ao seu calendário e caixa de entrada de e-mail a um assistente de IA para resumo de reuniões. Posteriormente, o mesmo usuário concede acesso à unidade de rede compartilhada da empresa a um assistente de produtividade. Uma terceira concessão conecta uma ferramenta de enriquecimento de CRM ao banco de dados de clientes. Cada uma foi aprovada individualmente. Nenhum responsável pela aplicação autorizou a combinação. A superfície de risco agora consiste em três escopos que se cruzam por meio de uma única identidade humana, onde a vulnerabilidade do assistente de IA para resumo de reuniões pode atingir rascunhos de contratos e registros de clientes através da mesma pessoa.

Isso é chamado de combinação tóxica . Consiste em uma quebra de permissões entre aplicativos, intermediada por uma concessão OAuth, uma integração ou um agente de IA, que nenhum proprietário de aplicativo jamais autorizou como sua própria superfície de risco. Não pode ser visualizada pelo log de auditoria de nenhum aplicativo individual, porque a ponte existe fora de todos eles.

Figura 3: Uma combinação tóxica entre dois aplicativos SaaS não autorizados pelo proprietário.

A instalação do MCP, o clique de consentimento do OAuth e a concessão da extensão do navegador: cada um deles é uma ponte emitida na velocidade de um único clique. Os servidores do Protocolo de Contexto de Modelo (MCP) estão emergindo como a próxima superfície de ataque no estilo OAuth, permitindo que agentes adquiram alcance limitado por meio do mesmo mecanismo de confiança única que as telas de consentimento já utilizam.

O incidente Salesloft-Drift de 2025 mostrou como isso se manifesta em grande escala. Um conector downstream comprometido se espalhou por mais de 700 tenants do Salesforce por meio de tokens OAuth que os clientes haviam aprovado legitimamente. Cada cliente autorizou a integração. Nenhum autorizou a propagação em cascata.

O que verificar

Para colmatar esta lacuna, é necessário tratar o consentimento OAuth da mesma forma que o programa de segurança já trata a autenticação. Um pequeno conjunto de perguntas revela onde reside a verdadeira lacuna.

Área a ser revisada	Como isso se parece na prática
Inventário de aplicativos OAuth	Todos os aplicativos de terceiros que possuem tokens de atualização no locatário são atualizados continuamente, em vez de apenas no momento da auditoria.
Concede idade e novo consentimento	Tokens emitidos há mais de 30 dias sem novo consentimento apareceram em uma fila.
Identidades entre aplicações	Identidades que detêm subsídios em três ou mais aplicativos SaaS foram sinalizadas para revisão.
Pontes de agentes e integração	Agentes de IA e integrações que interligam dois sistemas sem a aprovação do proprietário da aplicação.
Acesso condicional mediante consentimento.	Políticas que são reativadas em eventos de consentimento, e não apenas em eventos de login.
Revogação em nível de token	Um playbook que revoga um único token OAuth em vez de suspender o usuário.

A disciplina procedimental tem seus limites. As pontes existem em um grafo que nenhuma aplicação individual controla, e são criadas na velocidade de uma instalação do MCP ou de um clique de consentimento do OAuth. Visualizar esse grafo continuamente exige uma plataforma construída para observar a camada de tempo de execução onde as pontes são efetivamente formadas.

Onde as plataformas de segurança com IA se encaixam

Uma nova classe de plataformas lida com grande parte disso automaticamente. Elas mapeiam cada concessão OAuth, agente de IA e integração de terceiros no grafo de identidade no momento em que é emitido, em vez de esperar pela próxima auditoria, e então exibem as pontes, tokens não utilizados e desvios de política como uma fila operacional contínua.

Um exemplo notável é o Reco. Ele integra segurança de agentes de IA, governança de identidade e detecção de ameaças em um único plano de controle. Seu Gráfico de Conhecimento de Identidade conecta identidades humanas e não humanas aos aplicativos, concessões OAuth e integrações que elas podem acessar em todo o ambiente SaaS.

Figura 4: Visão do Reco sobre as concessões OAuth e as contas conectadas de um agente de IA.

A plataforma descobre continuamente agentes de IA e concessões OAuth à medida que surgem, mapeia cada escopo de volta à identidade que o aprovou, monitora o comportamento em busca de desvios de política e revoga o acesso no nível do token, em vez de na conta do usuário. Isso proporciona às equipes de segurança visibilidade da camada de tempo de execução, onde essas relações de confiança são de fato formadas.

É provável que o phishing de consentimento não permaneça à margem por muito mais tempo. A autenticação resistente a phishing recebeu anos de investimento e escrutínio, enquanto a camada de consentimento ainda opera em grande parte com base na confiança. Reduzir essa lacuna significa tratar as concessões OAuth e as conexões com agentes de IA com a mesma visibilidade, monitoramento e disciplina de revogação já aplicadas à própria autenticação.