){kind=link}
No último mês de março, a Microsoft divulgou uma série de campanhas de phishing que exploram o comportamento legítimo do protocolo OAuth, o padrão amplamente utilizado para autenticação em serviços como o botão “Entrar com o Google”, para redirecionar vítimas a páginas e arquivos maliciosos.
O diferencial do ataque é que ele não depende do roubo de credenciais: a cadeia de infecção avança mesmo quando a autenticação falha completamente. As campanhas têm como alvo prioritário organizações governamentais e do setor público.
smart_display
Nossos vídeos em destaque
O que é OAuth e por que ele é explorado
OAuth é um protocolo de autorização — um conjunto de regras padronizadas que permite que um sistema confirme a identidade de um usuário e autorize o acesso a recursos em seu nome. É o mecanismo por trás de botões como “Entrar com o Google” ou “Entrar com a Microsoft”.
O protocolo inclui um mecanismo nativo de redirecionamento que entra em ação quando ocorre um erro durante a autenticação. Em condições normais, esse redirecionamento leva o usuário de volta a uma página segura previamente definida pelo desenvolvedor do aplicativo, o chamado URI de redirecionamento, que é a base para a criação de endereços na internet, incluindo URLs.
Como o erro de autenticação é provocado de propósito
Os atacantes perceberam que é possível registrar um aplicativo falso dentro de plataformas como o Microsoft Entra ID ou o Google Workspace e configurar esse destino para apontar a um servidor sob seu controle.
Para acionar o redirecionamento, os atacantes combinam dois recursos previstos na própria especificação do OAuth. O primeiro é o parâmetro prompt=none, que faz com que o provedor de identidade tente autenticar o usuário silenciosamente, sem exibir nenhuma tela de login.
O segundo é um escopo intencionalmente inválido, o escopo é o campo que define quais permissões o aplicativo está solicitando, como acesso a e-mails ou contatos. Ao fornecer um valor inexistente, o atacante garante que a autenticação não será concluída.
Quando a autenticação falha, o provedor de identidade redireciona o navegador da vítima para o URI registrado junto com um código de erro. Como esse URI foi configurado pelo atacante, a vítima é enviada automaticamente ao domínio malicioso, sem ter feito login e sem ter suas credenciais comprometidas diretamente.
Esse comportamento está previsto nas especificações RFC 6749 e RFC 9700, o que significa que a técnica pode ser replicada em qualquer serviço compatível com OAuth, não sendo uma falha exclusiva da Microsoft ou do Google.
Como a isca chega até a vítima
A distribuição é feita por e-mail com iscas de temas corporativos comuns: solicitações de assinatura eletrônica, comunicados previdenciários, alertas financeiros, redefinições de senha e relatórios de RH.
Em alguns casos, a URL maliciosa está embutida dentro de um anexo PDF enviado sem conteúdo no corpo da mensagem, uma variação que dificulta a análise por sistemas de segurança que inspecionam predominantemente o texto das mensagens. Anexos falsos de convites de calendário no formato .ics também foram usados para simular reuniões reais e reforçar a aparência de legitimidade.
Uma das técnicas de personalização identificadas envolve o parâmetro state, que no uso correto do OAuth serve como valor aleatório de segurança. Nas campanhas observadas, os atacantes reaproveitaram esse campo para transportar o endereço de e-mail da vítima codificado em diferentes formatos.
O efeito prático é que, ao chegar à página de phishing, o endereço já aparece preenchido automaticamente no formulário, passando uma falsa sensação de que o sistema reconhece quem está acessando e aumentando a chance de que a vítima insira sua senha.
O que acontece depois do redirecionamento
Após o redirecionamento, os destinos variam conforme a campanha. Parte das vítimas é encaminhada para plataformas de phishing intermediárias, como o EvilProxy, que funcionam como um intermediário malicioso capaz de interceptar em tempo real tanto as credenciais digitadas quanto os cookies de sessão, pequenos arquivos que o navegador guarda para manter o usuário logado.
Com esses cookies, o atacante pode acessar a conta da vítima mesmo que ela utilize autenticação de dois fatores.
Outra parcela das campanhas leva as vítimas ao download automático de um arquivo ZIP contendo um atalho .LNK. Quando aberto, esse atalho executa silenciosamente um script PowerShell, uma linguagem de automação nativa do Windows, que inicia uma cadeia de comprometimento do dispositivo.
A cadeia de infecção dentro do computador da vítima
O script começa coletando informações sobre o ambiente da vítima, como configurações de rede e processos em execução, para que o atacante identifique se está lidando com um ambiente corporativo antes de prosseguir. Em seguida, extrai três arquivos: steam_monitor.exe, crashhandler.dll e crashlog.dat.
O ataque então aplica uma técnica chamada DLL sideloading: o executável legítimo steam_monitor.exe, que simula ser um componente da plataforma Steam, é usado para carregar a DLL maliciosa crashhandler.dll em lugar do arquivo original.
Como o processo inicial parece legítimo, ferramentas de segurança não levantam suspeitas imediatamente. A DLL descriptografa o crashlog.dat — que não é um log de erros real, mas a carga final do ataque — e a executa diretamente na memória do computador da vítima, sem gravar arquivos adicionais no disco.
Essa técnica, chamada de fileless malware, dificulta enormemente a detecção por antivírus tradicionais. Por fim, o malware estabelece conexão com um servidor externo de comando e controle, a partir do qual o atacante pode enviar instruções, exfiltrar dados ou instalar componentes adicionais.
O Microsoft Entra ID desativou os aplicativos OAuth identificados durante a investigação, mas a Microsoft alerta que a atividade relacionada persiste e exige monitoramento contínuo.