Abuso de redirecionamento OAuth entrega malware contra alvos governamentais

Campanhas de phishing exploram comportamento legítimo de redirecionamento em provedores de identidade para levar usuários a arquivos ZIP com cadeia de execução em PowerShell, MSI e DLL sideloading.

Componente	Fluxos OAuth de redirecionamento associados a provedores de identidade populares, incluindo Entra ID e Google Workspace, combinados com aplicações maliciosas registradas em locatários controlados pelo operador.
Vetor	E-mails de phishing levam a links OAuth criados com escopo intencionalmente inválido, parâmetros manipulados e redirecionamento para domínio controlado pelo atacante.
Impacto	O usuário é conduzido ao download de arquivo ZIP que inicia execução via atalho LNK, PowerShell, instalador MSI, documento isca, DLL sideloading e carga final em memória com conexão de saída para C2 externo.
Prioridade	Restringir consentimento de usuários para aplicações OAuth, revisar permissões concedidas, remover aplicações não utilizadas ou excessivamente privilegiadas e caçar redirecionamentos anômalos ligados a temas de phishing.
Artefatos	ZIP com LNK, MSI, documento isca, binário legítimo steam_monitor.exe, DLL maliciosa crashhandler.dll e arquivo criptografado crashlog.dat.
Mitigação	Governança de consentimento, revisão periódica de aplicações, inspeção de logs de identidade, bloqueio de downloads suspeitos e detecção de execução PowerShell acionada por atalhos extraídos de arquivos compactados.

Resumo técnico

A campanha observada usa phishing com links OAuth para contornar controles convencionais de proteção em e-mail e navegador sem depender, pelo que foi descrito, de roubo direto de tokens, exploração de vulnerabilidade em software ou captura tradicional de credenciais. O ponto central é o abuso de uma funcionalidade legítima: provedores de identidade permitem redirecionar usuários para uma página específica em determinados fluxos, inclusive cenários de erro ou respostas esperadas do protocolo. Ao manipular esse comportamento com aplicações registradas em ambiente controlado pelo operador, o link inicial pode parecer associado a um provedor confiável, mas a navegação termina em infraestrutura externa preparada para entregar malware.

Os alvos citados são organizações governamentais e do setor público. A operação combina engenharia social, identidade e execução em endpoint: mensagens com temas de assinatura eletrônica, gravações do Teams, seguridade social, finanças e política induzem o clique; o fluxo OAuth redireciona a vítima; o destino entrega um arquivo ZIP; e a abertura do conteúdo inicia uma cadeia no Windows com atalho LNK, PowerShell, instalador MSI, documento isca, DLL sideloading e carga final executada em memória. O risco operacional está menos em uma falha do OAuth e mais na confiança concedida a fluxos de autenticação e consentimento quando eles são apresentados fora de um contexto legítimo de negócio.

Fluxo técnico

O operador começa criando uma aplicação maliciosa em um locatário sob seu controle. Essa aplicação é configurada com uma URL de redirecionamento apontando para um domínio fraudulento que hospeda o malware. Em seguida, os destinatários recebem um link de phishing OAuth que solicita autenticação contra essa aplicação e usa um escopo intencionalmente inválido. Essa condição força o fluxo para o caminho de redirecionamento desejado, permitindo que o usuário seja encaminhado para uma página controlada pelo atacante sem que a campanha precise roubar o token da sessão como objetivo principal.

A cadeia de entrega usa arquivo ZIP como contêiner inicial. Dentro dele há um atalho do Windows que aciona PowerShell quando aberto; o comando operacional foi omitido, mas sua função descrita é executar reconhecimento do host por meio de comandos de descoberta. O mesmo atalho extrai um instalador MSI, que grava um documento isca para manter a aparência de legitimidade diante da vítima. Em paralelo, a execução carrega uma DLL maliciosa chamada crashhandler.dll por meio de sideloading com o binário legítimo steam_monitor.exe. Essa DLL descriptografa crashlog.dat e executa a carga final em memória, reduzindo artefatos óbvios em disco e permitindo comunicação de saída com um servidor C2 externo.

O uso do parâmetro state também é relevante para análise defensiva. Em fluxos OAuth legítimos, esse parâmetro costuma correlacionar requisição e resposta e deve ser tratado como valor imprevisível. Na campanha, ele foi reaproveitado para carregar o endereço de e-mail do alvo com técnicas de codificação, de modo que a página de phishing pudesse preencher automaticamente o identificador da vítima. Esse detalhe aumenta credibilidade para o usuário e cria um ponto de caça em logs e URLs capturadas: valores state com dados pessoais codificados ou padrões compatíveis com endereços de e-mail não devem aparecer em jornadas OAuth normais sem justificativa de aplicação.

Superfície afetada

A exposição recai sobre ambientes que permitem consentimento amplo de usuários para aplicações, mantêm pouca revisão sobre aplicações OAuth registradas ou aceitas e tratam links de provedores de identidade como inerentemente confiáveis. Mesmo quando o domínio inicial pertence a um provedor reconhecido, a aplicação associada, o escopo solicitado, o locatário de origem e a URL final de redirecionamento precisam ser avaliados. Controles que se concentram apenas em reputação do domínio visível no e-mail podem perder a transição para a infraestrutura fraudulenta.

No endpoint, a superfície inclui estáções Windows em que usuários conseguem baixar e abrir arquivos compactados vindos de mensagens externas. O encadeamento LNK, PowerShell, MSI e DLL sideloading cria oportunidades de bloqueio em diferentes camadas: filtragem de anexos e links, inspeção de arquivos compactados, regras de execução para atalhos vindos de zonas não confiáveis, restrição de PowerShell iniciado por processos de usuário e detecção de carregamento de DLL não esperado por binários legítimos. O contexto não confirma exploração de vulnerabilidade, vazamento de dados ou movimentação lateral; o impacto sustentado é infecção do dispositivo, reconhecimento local, execução em memória e comunicação com C2.

• Organizações governamentais e do setor público abordadas por temas de assinatura eletrônica, reuniões, seguridade social, finanças e política.
• Locatários e políticas em que usuários conseguem conceder consentimento a aplicações OAuth sem revisão administrativa adequada.
• Endpoints Windows expostos a ZIPs com atalhos LNK e execução subsequente de PowerShell, MSI e DLL sideloading.
• Fluxos de e-mail em que links OAuth ou PDFs com links internos recebem confiança excessiva por aparentarem envolver provedores de identidade conhecidos.

Hunting e telemetria

A investigação deve começar na camada de identidade. Procure aplicações OAuth recém-criadas ou raramente vistas, consentimentos recentes concedidos por usuários, escopos inválidos ou incomuns e URLs de redirecionamento que apontem para domínios sem relação com aplicações internas. Eventos em que o parâmetro state contenha valores codificados compatíveis com e-mails de usuários merecem revisão, principalmente quando aparecem em campanhas de mensagens similares ou em acessos originados de destinatários do setor público. A remoção de aplicações maliciosas já identificadas reduz um conjunto específico de artefatos, mas a técnica continua dependente de governança de aplicações e monitoramento de consentimento.

No endpoint, a sequência de processos é um bom eixo de detecção. O encadeamento esperado para caça envolve extração de ZIP, abertura de LNK, criação de processo PowerShell, execução de reconhecimento local, acionamento de instalador MSI, gravação de documento isca e carregamento de crashhandler.dll por steam_monitor.exe. A comunicação de saída da carga final deve ser correlacionada com execução em memória e com eventos de rede iniciados logo após o sideloading. Como nenhum domínio C2 específico foi fornecido no contexto, a defesa deve priorizar padrões comportamentais, reputação de destinos recém-observados, conexões incomuns para estáções de usuário e relação temporal entre clique, download e execução.

• Consentimento OAuth para aplicações desconhecidas, recém-observadas ou com permissões acima do necessário.
• URLs OAuth com escopo inválido, redirecionamento externo e state carregando endereço de e-mail codificado.
• E-mails em massa ou PDFs contendo links OAuth associados a temas de assinatura, gravações do Teams, seguridade social, finanças ou política.
• Execução de PowerShell a partir de LNK extraído de ZIP, sem necessidade operacional clara.
• steam_monitor.exe carregando crashhandler.dll fora de diretório ou fluxo esperado.
• Acesso a crashlog.dat seguido de execução em memória e conexão de saída para infraestrutura externa.

Mitigação

A resposta deve separar duas frentes: identidade e endpoint. Na identidade, limite consentimento de usuários a aplicações OAuth, exija aprovação administrativa quando o risco justificar, revise permissões já concedidas e remova aplicações não usadas ou excessivamente privilegiadas. Registros de aplicações e URLs de redirecionamento devem ser inventariados, com atenção especial a aplicações externas que não tenham dono interno, justificativa de negócio ou histórico conhecido. Políticas de acesso e alertas precisam considerar que o domínio aparente do link não basta para classificar o fluxo como seguro.

Na camada de e-mail e endpoint, bloqueie ou submeta a análise reforçada arquivos ZIP contendo LNK, especialmente quando a mensagem trouxer iscas de assinatura eletrônica, reunião, documento financeiro ou tema político. Regras de controle de aplicação podem impedir atalhos extraídos de arquivos da internet de iniciarem PowerShell e podem restringir instaladores MSI em diretórios temporários ou de usuário. Também é necessário revisar detecções de DLL sideloading para binários legítimos usados fora do caminho esperado e correlacionar conexões externas após execução em memória. Para máquinas com sinais da cadeia, a contenção deve incluir isolamento, coleta de artefatos, revisão de processos, análise de persistência, inspeção de conexões recentes e validação de que nenhuma aplicação OAuth indevida permaneceu autorizada para a conta do usuário.

• Desabilitar consentimento amplo de usuários quando não houver processo de revisão e aprovação de aplicações OAuth.
• Revisar periodicamente aplicações, permissões, escopos e URLs de redirecionamento associadas a provedores de identidade.
• Remover aplicações não utilizadas, desconhecidas ou com privilégios excessivos.
• Bloquear ou analisar ZIPs com LNK e execução subsequente de PowerShell em estáções de usuário.
• Criar alertas para state com e-mail codificado em fluxos OAuth e para escopos inválidos ligados a redirecionamento externo.
• Conter endpoints com sinais de crashhandler.dll, steam_monitor.exe em uso anômalo ou acesso a crashlog.dat antes de comunicação externa.