OAuth & Consent Phishing: O sequestro invisível das contas Microsoft
Imagine um executivo recebendo uma notificação para integrar uma nova ferramenta de produtividade à sua conta Microsoft 365. A página de login é da Microsoft. A tela de permissões é da Microsoft, o usuário clica em “Aceitar, e em segundos, sem que nenhuma senha seja roubada e nenhuma barreira de autenticação multifator (MFA) seja acionada, ele acaba de entregar a um invasor acesso persistente e irrestrito à sua caixa de e-mail, arquivos e contatos. Este cenário descreve uma das ameaças mais sofisticadas que visam o ecossistema corporativo hoje: o phishing de consentimento. Em um ambiente onde a Microsoft relata que seus clientes enfrentam mais de 600 milhões de ataques diariamente, os adversários evoluíram. A nova fronteira dos ataques não visa mais apenas roubar credenciais, mas sim manipular a confiança do usuário e abusar dos próprios mecanismos que sustentam a nuvem moderna. Este artigo vai dissecar a anatomia do phishing de consentimento, uma técnica que transforma o protocolo de autorização OAuth 2.0 em uma arma, vamos explicar por que defesas tradicionais como o MFA são ineficazes contra esse vetor e apresentar a estratégia de defesa em profundidade, orquestrada pelo Cyber Fusion Center (CFC) da Asper, essencial para neutralizar essa ameaça silenciosa. Ouça o resumo do artigo: O paradoxo do OAuth 2.0: Quando a confiança se torna a arma do invasor Para entender a gravidade do phishing de consentimento, é crucial primeiro compreender o papel legítimo do OAuth 2.0. Este protocolo é a espinha dorsal da conectividade na nuvem, permitindo que aplicações de terceiros acessem dados em outras plataformas em nome do usuário, sem que ele precise compartilhar sua senha. É um mecanismo de delegação de confiança, concedendo permissões limitadas (escopos) para que uma aplicação execute tarefas específicas. O phishing de consentimento, também conhecido como concessão de consentimento ilícito, explora precisamente esse fluxo de confiança. O ataque começa quando um adversário cria e registra uma aplicação maliciosa em um provedor de identidade, como o Microsoft Entra ID. Em seguida, ele engana um usuário para que conceda as permissões que essa aplicação solicita. O ponto crucial é que a solicitação de consentimento é apresentada em uma página legítima da própria Microsoft, para o usuário, tudo parece autêntico: o domínio é login.microsoftonline.com e a interface é familiar. A diferença fundamental deste ataque reside na camada do processo que ele explora: não a autenticação, mas a autorização. A autenticação verifica quem você é, a autorização determina o que você pode fazer, o phishing de consentimento ignora a primeira e foca na segunda. O usuário já está logado, sua identidade já foi validada, muitas vezes com MFA. O ataque acontece no passo seguinte, quando o usuário autoriza a aplicação maliciosa a agir em seu nome. É por isso que o MFA se torna inútil; ele foi projetado para proteger o login, não para impedir que um usuário autenticado tome uma decisão de autorização ruim. A tabela a seguir compara o phishing tradicional com o phishing de consentimento: Essa distinção revela uma evolução tática alarmante: os adversários não precisam mais criar uma infraestrutura de phishing elaborada. Em vez disso, exploram a própria infraestrutura legítima e confiável da Microsoft contra os usuários da organização. A confiança que os colaboradores depositam na marca e na interface da Microsoft passa a ser o verdadeiro alvo da exploração. Isso também expõe um problema de delegação excessiva de escopos: aplicações maliciosas solicitam mais permissões do que o necessário (por exemplo, acesso amplo a e-mail, arquivos ou offline_access), ganhando alcance e persistência além do estritamente justificado. Aqui entra a diferença entre application consent grant e admin consent grant No application consent grant, usuários individuais podem autorizar apps a acessar dados em seu nome, conforme as permissões solicitadas. Muitas organizações mantêm esse comportamento por padrão para facilitar a adoção de SaaS, o que abre espaço para consent phishing, induzindo o usuário a autorizar um aplicativo malicioso e resultando em exfiltração de dados ou persistência não autorizada. Já o admin consent grant exige que um administrador conceda explicitamente permissões (especialmente quando há acesso de alto impacto ou envolvendo múltiplos usuários), adicionando uma camada essencial de governança e validação sobre o que é autorizado no ambiente. Diante disso, treinamentos focados apenas em “verificar a URL” tornam-se menos eficazes. O desafio não é identificar o que é falso, mas avaliar criticamente o que é perigosamente real — inclusive o ato de conceder escopos a um aplicativo “aparentemente legítimo”. Medidas recomendadas: O sequestro invisível: Como funciona um ataque de phishing silencioso Um ataque de phishing de consentimento é executado com precisão cirúrgica, seguindo uma cadeia de eventos projetada para ser o mais discreta possível. Etapa 1: Registro e isca Tudo começa quando o atacante registra uma nova aplicação OAuth em um tenant do Microsoft Entra ID que ele controla. O nome da aplicação é escolhido para parecer legítimo, como “Privacy Policy Extension” ou “Atualização de Segurança”. Com a aplicação pronta, o próximo passo é levar a vítima até a tela de consentimento. E-mails de phishing continuam sendo um vetor popular, mas os atacantes estão diversificando para canais como Microsoft Teams ou Slack, que são inerentemente mais confiáveis. A isca geralmente envolve engenharia social com senso de urgência, como um documento importante que precisa de revisão ou um alerta de segurança falso. Etapa 2: Consentimento e roubo do token Ao clicar no link malicioso, a vítima é redirecionada para a tela de consentimento oficial da Microsoft. Esta é a etapa mais enganosa, a página é legítima, segura com HTTPS e hospedada no domínio da Microsoft,nela, são listadas as permissões que a aplicação maliciosa está solicitando, que costumam ser de alto privilégio, como Mail.ReadWrite.All (ler e escrever e-mails), Files.ReadWrite.All (acessar e modificar arquivos) e offline_access (manter o acesso indefinidamente). Quando o usuário clica em “Aceitar”, ele autoriza a aplicação. Nesse momento, o Microsoft Entra ID gera um código de autorização e o envia para a aplicação do atacante, a aplicação então troca esse código por um access token e, mais importante, por um refresh token. Orefresh token é de
