A fraude de redireccionamento OAuth que rouba credenciais

Os investigadores de segurança da Microsoft alertaram recentemente sobre uma técnica que está aproveitando uma função legítima do ecossistema de identidade para colar páginas maliciosas sem recorrer ao engano clássico de suplantação direta. Em vez de falsificar os remetentes ou mascarar domínios, os atacantes estão a explorar o mecanismo de redireccionamento do OAuth para “forçar” o navegador ou o cliente de e-mail a levar o usuário a um recurso controlado pelo atacante. O resultado é uma fraude de phishing muito mais difícil de detectar por filtros automáticos e pela simples inspeção visual.

O vetor que descrevem os analistas combina mensagens que aparentam urgência —petições de assinatura eletrônica, avisos do seguro social, convites a reuniões ou reinícios de senha — com ligações que aparentam ser pedidos de autorização legítimas. Às vezes esses URLs maliciosas ficam escondidos dentro de arquivos PDF para evitar os controles de e-mail. Quando a vítima clica, a cadeia de eventos aproveita como os provedores de identidade lidam com erros de autorização para redireccionar o usuário para uma URI que os atacantes registraram em aplicativos OAuth sob seu controle. Você pode ler o relatório técnico na nota publicada pela Microsoft: Microsoft Security Blog.

Para entender por que este truque funciona é preciso lembrar que OAuth é um padrão projetado para delegar licenças entre serviços. Um provedor de identidade — como a Microsoft Entra ID — permite que aplicativos registrados solicitem acesso em nome de usuários seguindo regras muito concretas ( RFC 6749). Quando algo está errado durante a negociação — por exemplo, parâmetros que exigem uma autenticação “silenciosa” (prompt=none) ou um scope inválido — a especificação contempla que o serviço de identidade gera um erro e, em muitos casos, responda com um redireccionamento para a URI registrada pela aplicação. Os atacantes aprenderam a provocar esse comportamento deliberadamente para transformar uma resposta de erro em uma rota para a sua própria infraestrutura.

Na prática, os abusadores criam aplicações OAuth em um tenant que controlam e registram um redireccionamento que aponta para o seu servidor. Depois constroem links de autorização que parecem legítimos e os distribuem em campanhas direcionadas, sobretudo contra organismos públicos e entidades governamentais. Quando o provedor de identidade detecta o “error” intencional, envia o usuário exatamente para o endereço que o atacante configurou. Em alguns casos essa página é um site de phishing que reproduz a interface de início de sessão; em outros, o redireccionamento aponta para um recurso que entrega automaticamente um ZIP com atalhos (.LNK) e técnicas de HTML smuggling para sortear detecções e executar código na equipe da vítima.

Os pesquisadores também descrevem variantes em que os criminosos usam frameworks de ataque homem-en-médio especializados para interceptar credenciais ou tokens de sessão e assim contornar barreiras como a autenticação multifator. Ferramentas deste tipo – por exemplo, projetos conhecidos em código aberto que facilitam ataques de proxy em sessões web – permitem que um atacante capture cookies ou tokens válidos e reutilize antes que a vítima note algo estranho; uma referência técnica de projetos similares está disponível no repositório de Evilginx2: Evilginx2 (GitHub).

Um detalhe particularmente eficaz nestas campanhas é o abuso do parâmetro “state” de OAuth. Normalmente é usado para manter o contexto entre o pedido e a resposta de autorização; os atacantes o usam para inserir o endereço de e-mail da vítima na página de phishing, aumentando a sensação de autenticidade e reduz as suspeitas ao ver o seu próprio e-mail já preenchido. Em outras variantes, a abertura do atalho .LNK executa PowerShell que realiza reconhecimento local e desencadeia uma cadeia de carga lateral do DLL: um binário legítimo carga um DLL malicioso que decifra e executa o payload final em memória, um padrão conhecido e documentado pela comunidade de detecção de ameaças (ver técnicas relacionadas no MITRE: PowerShell, DLL Side-Loading).

A chave desta campanha não é uma vulnerabilidade em OAuth, mas o aproveitamento de um comportamento previsto pelo próprio padrão: os fornecedores de identidade estão respondendo exatamente como devem diante de certos erros, e os atacantes estão manipulando esses erros a seu favor. Por isso, as defesas puramente baseadas em listas de URLs ou em heurísticas de correio podem falhar se uma petição de autorização legítima —aparentemente — serve como coberta.

O que as organizações podem fazer para reduzir este risco? As recomendações da Microsoft apontam em várias direções complementares: limitar quem pode registrar aplicativos no tenant, exigir consentimento administrativo para permissões sensíveis, aplicar políticas sólidas de identidade e Conditional Access, e coordenar detecção entre correio, serviços de identidade e endpoints para identificar padrões cross-domain. A documentação oficial sobre permissões e consentimento e políticas do Conditional Access ajuda a entender como aplicar esses controles em ambientes Azure: Permissões e consentimento no Azure AD e Guia do Conditional Access. Também é boa prática restringir o registro de aplicativos através de políticas e auditar regularmente as aplicações com permissões delegados.

Ao nível do utilizador final, é conveniente extremar a precaução com ligações inesperadas, mesmo que provem de serviços legítimos ou quando a mensagem parecer dirigida: os anexos que contêm URLs, como PDFs, são uma técnica de evasão habitual. A combinação de educação, filtros de correio avançados, análises comportamentais em endpoints e uma configuração de identidade rigorosa é a melhor defesa. Para quem quiser aprofundar a forma como as autorizações OAuth funcionam e como evitar maus usos, o processo de registro de aplicativos na plataforma de identidade da Microsoft oferece uma base técnica útil: Registrar aplicativos em Microsoft identity platform.

Em suma, enfrentamos ataques que não quebram a criptografia nem exploram falhas tradicionais, mas que trazem vantagem de comportamentos padrão e de cadeias de confiança humanas. O remédio parte por reconhecer que a superfície de ataque agora inclui a própria infraestrutura de autorização e por aplicar controles de governança de identidade com o mesmo cuidado com o qual se protege a rede e o endpoint. Como sempre, a segurança é uma coordenação entre tecnologia, processos e consciênciação.