Clicou em 'Aceitar' e Esqueceu: Como uma Equipe Red Team Invadiu a Infraestrutura Usando OAuth 2.0
Um relatório detalhado de um ataque de phishing sofisticado que contornou as defesas tradicionais, explorando o fluxo de autorização OAuth 2.0 do Microsoft 365. A equipe Red Team conseguiu acesso a caixas de correio sem usar arquivos maliciosos, enganando usuários a conceder permissões.
MundiX News·01 de junho de 2026·7 min de leitura·👁 16 views
No cenário em constante evolução da cibersegurança, as equipes de segurança estão constantemente testando os limites das defesas de uma organização. Este artigo detalha um estudo de caso de uma equipe Red Team que conduziu um teste de penetração interno, focando em uma campanha de phishing sofisticada que explorou o processo de autorização OAuth 2.0 no Microsoft 365. O objetivo era identificar novos vetores de ataque e avaliar a resiliência da infraestrutura da empresa.
A equipe Red Team, ciente de que os dispositivos finais estavam equipados com soluções EDR (Endpoint Detection and Response) com análise comportamental, decidiu evitar métodos tradicionais de phishing, como anexos maliciosos ou exploits. Em vez disso, eles se concentraram em atacar o próprio processo de autorização OAuth 2.0 no Office 365. A estratégia escolhida foi o fluxo de código de autorização OAuth 2.0. Em vez de enviar um link para uma página de login falsa, a equipe induziu os usuários a clicar no botão 'Aceitar' dentro de uma janela legítima da Microsoft. Isso permitiu que a equipe, usando a API, lesse o conteúdo das caixas de correio sem a necessidade de um único arquivo malicioso.
A chave para o sucesso da equipe foi a arquitetura do Microsoft 365, que é construída em cima do Azure Active Directory. Qualquer aplicativo externo pode obter acesso aos dados do usuário se receber seu consentimento explícito e um token. A equipe criou um novo aplicativo no portal do Azure AD, especificando um URI de redirecionamento e gerando um client_secret e client_id. Eles então construíram um link especial que levava ao site legítimo login.microsoftonline.com. Este link continha parâmetros como o client_id, o tipo de resposta (código), o redirect_uri e, crucialmente, um conjunto de permissões solicitadas (scope), incluindo Mail.Read (para ler e-mails) e offline_access (para acesso de longo prazo). A equipe usou um serviço de encurtamento de URL para disfarçar o link e o incorporou em um e-mail de phishing convincente. O e-mail se passava por um anúncio do departamento de TI sobre uma nova solução de autenticação única (SSO), induzindo os usuários a clicar no link para ativar o recurso. Quando um funcionário clicava em 'Aceitar' na janela de permissões da Microsoft, o navegador redirecionava um código para o servidor da equipe Red Team, permitindo que eles trocassem esse código por tokens de acesso e atualização, concedendo acesso à caixa de correio do usuário.
O processo de ataque envolveu as seguintes etapas:
O usuário recebe o e-mail de phishing.
O usuário clica no link, que o leva ao site de login da Microsoft.
O usuário faz login e concede permissões ao aplicativo malicioso.
O navegador redireciona o código de autorização para o servidor da equipe Red Team.
A equipe troca o código por tokens de acesso e atualização.
A equipe usa o token de acesso para acessar a caixa de correio do usuário.
A equipe usou um servidor web simples para trocar o código por tokens. O servidor recebeu o código, o client_secret, o redirect_uri e o grant_type, e trocou-os por tokens de acesso e atualização. Esses tokens foram salvos em um banco de dados, permitindo que a equipe se autenticasse e lesse os e-mails dos usuários. Em apenas duas horas, 132 dos 300 funcionários (44%) clicaram no link e 98 deles (32,6%) clicaram em 'Aceitar', concedendo acesso à sua caixa de correio. Este estudo de caso destaca a importância de entender as ameaças modernas e a necessidade de medidas de segurança robustas.
Medidas de Resposta:
Habilitar a política 'User consent to apps': Permitir o consentimento do usuário apenas para editores verificados ou negar o consentimento do usuário (a segunda opção é preferível).
Configurar a coleta de logs do Azure AD em um SIEM: Com correlação de Consentimento + MailItemsAccessed em massa.
Habilitar a política: Acesso à Graph API apenas de dispositivos híbridos ou através de VPN.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
No cenário em constante evolução da cibersegurança, as equipes de segurança estão constantemente testando os limites das defesas de uma organização. Este artigo detalha um estudo de caso de uma equipe Red Team que conduziu um teste de penetração interno, focando em uma campanha de phishing sofisticada que explorou o processo de autorização OAuth 2.0 no Microsoft 365. O objetivo era identificar novos vetores de ataque e avaliar a resiliência da infraestrutura da empresa.
A equipe Red Team, ciente de que os dispositivos finais estavam equipados com soluções EDR (Endpoint Detection and Response) com análise comportamental, decidiu evitar métodos tradicionais de phishing, como anexos maliciosos ou exploits. Em vez disso, eles se concentraram em atacar o próprio processo de autorização OAuth 2.0 no Office 365. A estratégia escolhida foi o fluxo de código de autorização OAuth 2.0. Em vez de enviar um link para uma página de login falsa, a equipe induziu os usuários a clicar no botão 'Aceitar' dentro de uma janela legítima da Microsoft. Isso permitiu que a equipe, usando a API, lesse o conteúdo das caixas de correio sem a necessidade de um único arquivo malicioso.
A chave para o sucesso da equipe foi a arquitetura do Microsoft 365, que é construída em cima do Azure Active Directory. Qualquer aplicativo externo pode obter acesso aos dados do usuário se receber seu consentimento explícito e um token. A equipe criou um novo aplicativo no portal do Azure AD, especificando um URI de redirecionamento e gerando um client_secret e client_id. Eles então construíram um link especial que levava ao site legítimo login.microsoftonline.com. Este link continha parâmetros como o client_id, o tipo de resposta (código), o redirect_uri e, crucialmente, um conjunto de permissões solicitadas (scope), incluindo Mail.Read (para ler e-mails) e offline_access (para acesso de longo prazo). A equipe usou um serviço de encurtamento de URL para disfarçar o link e o incorporou em um e-mail de phishing convincente. O e-mail se passava por um anúncio do departamento de TI sobre uma nova solução de autenticação única (SSO), induzindo os usuários a clicar no link para ativar o recurso. Quando um funcionário clicava em 'Aceitar' na janela de permissões da Microsoft, o navegador redirecionava um código para o servidor da equipe Red Team, permitindo que eles trocassem esse código por tokens de acesso e atualização, concedendo acesso à caixa de correio do usuário.
O processo de ataque envolveu as seguintes etapas:
O usuário recebe o e-mail de phishing.
O usuário clica no link, que o leva ao site de login da Microsoft.
O usuário faz login e concede permissões ao aplicativo malicioso.
O navegador redireciona o código de autorização para o servidor da equipe Red Team.
A equipe troca o código por tokens de acesso e atualização.
A equipe usa o token de acesso para acessar a caixa de correio do usuário.
A equipe usou um servidor web simples para trocar o código por tokens. O servidor recebeu o código, o client_secret, o redirect_uri e o grant_type, e trocou-os por tokens de acesso e atualização. Esses tokens foram salvos em um banco de dados, permitindo que a equipe se autenticasse e lesse os e-mails dos usuários. Em apenas duas horas, 132 dos 300 funcionários (44%) clicaram no link e 98 deles (32,6%) clicaram em 'Aceitar', concedendo acesso à sua caixa de correio. Este estudo de caso destaca a importância de entender as ameaças modernas e a necessidade de medidas de segurança robustas.
Medidas de Resposta:
Habilitar a política 'User consent to apps': Permitir o consentimento do usuário apenas para editores verificados ou negar o consentimento do usuário (a segunda opção é preferível).
Configurar a coleta de logs do Azure AD em um SIEM: Com correlação de Consentimento + MailItemsAccessed em massa.
Habilitar a política: Acesso à Graph API apenas de dispositivos híbridos ou através de VPN.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
