A armadilha de OAuth: quando uma redirecção legítima se converte em phishing, malware e roubo de credenciais

A Microsoft publicou esta semana um alerta que deveria colocar em guarda administradores e usuários do setor público: atacantes estão aproveitando mecanismos legítimos de redireccionamento em fluxos OAuth para levar vítimas até infraestruturas controladas por criminosos, aumentando assim muitas das proteções habituais de correio e navegador. Não se trata tanto de violar um serviço como de explorar o comportamento previsto pelo padrão de autorização para que um URL aparentemente inócua termine numa armadilha.

OAuth é a peça técnica que permite a aplicativos pedir permissão para agir em nome de um usuário sem exigir sua senha, e é a base dos inícios de sessão "Iniciar sessão com o Google" ou "Iniciar sessão com a Microsoft". A especificação contempla que, em determinados cenários (por exemplo erros ou fluxos concretos), o fornecedor de identidade redireccione o utilizador a um URL específico. Os atacantes projetaram aplicações maliciosas e links que abusam dessa redireccionamento para dirigir o usuário a páginas alojadas pelos próprios criminosos. Se você quer rever o funcionamento do protocolo, a explicação básica está em oauth.net e a documentação concreta dos fornecedores como o Google e a Microsoft detalham como as URIs são gerenciadas em suas plataformas ( Google OAuth, Microsoft Entra/Identity).

O modo de operação descrito pela Microsoft combina engenharia social e abuso do fluxo OAuth: os atacantes criam uma aplicação em um inquilino que controlam e colocam-no como URI de redireccionar um domínio malicioso. Em seguida, enviam links de phishing em e-mails - cuidadosamente elaborados como pedidos de assinatura eletrônica, gravações de Teams ou temas financeiros e administrativos - que pedem ao usuário autenticar-se com a aplicação maliciosa, muitas vezes usando um "scope" intencionalmente inválido para forçar a rota de erro/reendereço desejado. O resultado não é sempre o roubo direto de tokens; em várias campanhas a finalidade foi forçar downloads que infetam a própria equipe do usuário.

Nos casos analisados, o arquivo que termina chegando ao dispositivo é normalmente um ZIP que contém acesso direto do Windows (LNK). Ao abrir esse acesso direto é executado imediatamente um comando do PowerShell que inspeciona o computador e extrai um instalador MSI. Esse instalador deixa à vista um documento señuelo enquanto, por trás de cena, uma biblioteca maliciosa (uma DLL com nome como "crashhandler.dll") aproveitando um binário legítimo para carregar, decifrar um arquivo adicional e lança a carga final em memória. Desde então o malware estabelece comunicação com um servidor de comando e controle para continuar a intrusão, que pode terminar em atividade de tipo pré-ransom ou ações manuais por parte de operadores humanos.

Além das campanhas que entregam malware, a mesma técnica de redireccionamento foi usada para páginas que implementam kits de phishing tipo adversary-in-the-middle (AitM). Esses marcos permitem capturar credenciais, cookies de sessão ou até mesmo trocar códigos OAuth em tempo real; frameworks conhecidos na comunidade de segurança demonstraram a eficácia dessas abordagens quando o usuário confia no fluxo e o provedor de identidade nunca bloqueia o redireccionamento.

Outro detalhe relevante detectado pela Microsoft é o uso criativo do parâmetro "state": originalmente pensado para correlacionar pedidos e respostas e proteger contra CSRF, nessas cadeias os atacantes codificam o endereço de e-mail do objetivo para que apareça automaticamente na página de phishing, aumentando sua credibilidade. É um lembrete de que uma peça desenhada para segurança pode ser reutilizada de forma perversa se o seu conteúdo não for verificado.

A Microsoft já eliminou várias aplicações maliciosas identificadas, mas a conclusão para equipamentos de segurança e responsáveis TI é clara: há que combinar controles técnicos com boas práticas administrativas. Limitar o consentimento que os usuários podem dar a aplicativos de terceiros, auditar regularmente as permissões concedidas e revogar aplicativos desnecessários ou overprivileged São passos críticos. A Microsoft oferece ferramentas de gestão de aplicativos e políticas de consentimento em sua plataforma; revisar essas opções pode reduzir a superfície de ataque ( Gestão de Aplicações no Azure AD / Entra).

Para complementar essas medidas, convém reforçar proteções em endpoints e correio: impedir a abertura automática de anexos perigosos, bloquear domínios e arquivos conhecidos maliciosos em porta de ligação e correio, e manter soluções de detecção capazes de identificar técnicas como a execução de PowerShell a partir de LNK ou o sideloading de DLLs. Também é importante ensinar usuários e equipamentos a suspeitar de ligações mesmo quando parecem se originar de um fornecedor legítimo; a Agência de Segurança dos EUA. EUA e outras entidades publicam recomendações práticas contra phishing que podem ser incorporadas nos programas de sensibilização ( CISA — Phishing guidance).

Além disso, as organizações com identidade centralizada devem valorizar políticas mais rigorosas: impedir o consentimento de usuários não administradores para certas aplicações, exigir revisões administrativas para autorizações especialmente sensíveis e ativar controlos condicionais que obriguem a verificação adicional ou bloqueiem o acesso a ambientes não confiáveis. Ferramentas nativas dos fornecedores permitem criar listas permitidas ou recusadas de aplicativos e monitorar tentativas de consentimento incomuns.

Este episódio lembra que a segurança na era da identidade como perímetro é multidimensional: não basta proteger a infraestrutura perimetral se o próprio modelo de autorização pode ser manipulado socialmente. A prevenção exige coordenar políticas de identidade, controles no correio e endpoints, e formação contínua das pessoas Para que não sejam o elo mais fraco.

Se você quer rever o relatório técnico da Microsoft com todos os indicadores e exemplos apresentados pela equipe de Defender, está disponível em seu blog de segurança: Microsoft Security Blog — OAuth redirection abuse. Para aprofundar a forma como se gerem redesireções e URIs nos diferentes fornecedores, a documentação oficial do Google e da Microsoft sobre OAuth/Identity é um bom ponto de partida ( Google, Microsoft Entra), e para entender o desenho do próprio protocolo, a referência em oauth.net É útil.

Em suma: não é apenas uma questão técnica, mas sim de governação e cultura. Manter um inventário de aplicativos, limitar o que os usuários podem autorizar e revisar ativamente as permissões são medidas que, combinadas com controles técnicos, dificultam que ataques como este cheguem a bom porto.