Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

Informações Básicas

Em designs legados do Exchange Hybrid, a implantação on-prem do Exchange podia autenticar-se como a mesma identidade de aplicação Entra usada pelo Exchange Online. Se um atacante comprometesse o servidor Exchange, extraísse a chave privada do certificado híbrido e realizasse um fluxo OAuth client-credentials, ele podia obter tokens first-party com contexto de privilégios do Exchange Online.

O risco prático não se limitava ao acesso a caixas de correio. Como o Exchange Online tinha amplas relações de confiança back-end, essa identidade podia interagir com serviços adicionais do Microsoft 365 e, em comportamentos antigos, podia ser usada para comprometer mais profundamente o tenant.

Caminhos de Ataque e Fluxo Técnico

Modificar a Configuração de Federação via Exchange

Historicamente, tokens do Exchange tinham permissões para gravar configurações de domínio/federação. Do ponto de vista do atacante, isso permitia manipular diretamente dados de confiança de domínios federados, incluindo listas de certificados de assinatura de token e flags de configuração que controlavam a aceitação de claims de MFA da infraestrutura de federação on-prem.

Isso significa que um servidor Exchange Hybrid comprometido podia ser usado para montar ou reforçar impersonation no estilo ADFS ao alterar a configuração de federação pelo lado da cloud, mesmo quando o atacante começava apenas a partir do compromisso on-prem do Exchange.

ACS Actor Tokens e Impersonação entre Serviços

O caminho de autenticação híbrido do Exchange usava Access Control Service (ACS) actor tokens com trustedfordelegation=true. Esses actor tokens eram então embutidos em um segundo service token não assinado que carregava a identidade do usuário alvo em uma seção controlada pelo atacante. Como o token externo era não assinado e o actor token delegava amplamente, o chamador podia trocar usuários alvo sem reautenticar.

Na prática, uma vez obtido o actor token, o atacante tinha um primitivo de impersonação de longa duração (tipicamente cerca de 24 horas) que era difícil de revogar no meio do seu tempo de vida. Isso permitia impersonação de usuários através das APIs do Exchange Online e SharePoint/OneDrive, incluindo exfiltração de dados de alto valor.

Historicamente, o mesmo padrão também funcionava contra graph.windows.net ao construir um token de impersonation com o valor netId da vítima. Isso fornecia ação administrativa direta em Entra como usuários arbitrários e permitia workflows de takeover completo do tenant (por exemplo, criar uma nova conta Global Administrator).

O Que Não Funciona Mais

O caminho de impersonation via graph.windows.net através de actor tokens do Exchange foi corrigido. A antiga cadeia “Exchange para administrador Entra arbitrário via Graph” deve ser considerada removida para essa rota específica de token.

Esta é a correção mais importante ao documentar o ataque: mantenha o risco de impersonation Exchange/SharePoint separado da escalada de impersonation via Graph que já foi corrigida.

O Que Ainda Pode Importar na Prática

Se uma organização ainda opera uma configuração híbrida antiga ou incompleta com confiança compartilhada e material de certificado exposto, o impacto de impersonation Exchange/SharePoint pode continuar severo. O ângulo de abuso da configuração de federação também pode permanecer relevante dependendo da configuração do tenant e do estado da migração.

A mitigação de longo prazo da Microsoft é separar as identidades on-prem e do Exchange Online para que o caminho de confiança do shared-service-principal deixe de existir. Ambientes que concluíram essa migração reduzem materialmente essa superfície de ataque.

Notas de Detecção

Quando essa técnica é abusada, eventos de auditoria podem mostrar discrepâncias de identidade onde o user principal name corresponde a um usuário impersonado enquanto o contexto de display/origem aponta para atividade do Exchange Online. Esse padrão de identidade mista é um sinal de hunting de alto valor, embora os defensores devam estabelecer uma baseline dos fluxos de trabalho legítimos de administradores do Exchange para reduzir falsos positivos.

Referências

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks