mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
@@ -1,40 +1,42 @@
|
||||
# Az - Lateral Movement (Cloud - On-Prem)
|
||||
# Az - Movimento Lateral (Cloud - On-Prem)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
Esta seção cobre as pivoting techniques para mover de um tenant Entra ID comprometido para o on-premises Active Directory (AD) ou de um AD comprometido para o tenant Entra ID.
|
||||
Esta seção cobre as técnicas de pivoting para mover de um tenant Entra ID comprometido para o Active Directory (AD) on-premises ou de um AD comprometido para o tenant Entra ID.
|
||||
|
||||
## Pivoting Techniques
|
||||
## Técnicas de Pivoting
|
||||
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se um atacante puder controlar ou criar uma conta de computador AD e acessar o compartilhamento de deployment do Azure Arc GPO, ele pode decryptar o Service Principal secret armazenado e usá-lo para autenticar no Azure como o service principal associado, comprometendo totalmente o ambiente Azure vinculado.
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se um atacante conseguir controlar ou criar uma conta de computador do AD e acessar o share de deployment do Azure Arc GPO, ele pode descriptografar o segredo do Service Principal armazenado e usá-lo para autenticar no Azure como o service principal associado, comprometendo totalmente o ambiente Azure vinculado.
|
||||
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): How to pivot from Entra ID to AD when Cloud Kerberos Trust is configured. Um Global Admin em Entra ID (Azure AD) pode abusar do Cloud Kerberos Trust e da sync API para se passar por contas AD de alto privilégio, obter seus tickets Kerberos ou hashes NTLM, e comprometer totalmente o Active Directory on-prem — mesmo que essas contas nunca tenham sido cloud-synced — efetivamente ligando a escalada de privilégio da cloud para o AD.
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Como pivotar do Entra ID para o AD quando o Cloud Kerberos Trust está configurado. Um Global Admin no Entra ID (Azure AD) pode abusar do Cloud Kerberos Trust e da sync API para se passar por contas AD de alto privilégio, obter seus tickets Kerberos ou hashes NTLM e comprometer totalmente o Active Directory on-prem — mesmo que essas contas nunca tenham sido sincronizadas para a nuvem — efetivamente criando uma ponte para escalada de privilégios do cloud para o AD.
|
||||
|
||||
- [**Cloud Sync**](az-cloud-sync.md): Como abusar do Cloud Sync para mover da cloud para o AD on-premises e vice-versa.
|
||||
- [**Cloud Sync**](az-cloud-sync.md): Como abusar do Cloud Sync para mover da nuvem para o AD on-premises e vice-versa.
|
||||
|
||||
- [**Connect Sync**](az-connect-sync.md): Como abusar do Connect Sync para mover da cloud para o AD on-premises e vice-versa.
|
||||
- [**Connect Sync**](az-connect-sync.md): Como abusar do Connect Sync para mover da nuvem para o AD on-premises e vice-versa.
|
||||
|
||||
- [**Domain Services**](az-domain-services.md): O que é o Azure Domain Services Service e como pivotar de Entra ID para o AD que ele gera.
|
||||
- [**Domain Services**](az-domain-services.md): O que é o serviço Azure Domain Services e como pivotar do Entra ID para o AD que ele gera.
|
||||
|
||||
- [**Federation**](az-federation.md): Como abusar do Federation para mover da cloud para o AD on-premises e vice-versa.
|
||||
- [**Federation**](az-federation.md): Como abusar da Federation para mover da nuvem para o AD on-premises e vice-versa.
|
||||
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Ataques diversos que podem ser usados para pivotar da cloud para o AD on-premises e vice-versa.
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Ataques diversos que podem ser usados para pivotar da nuvem para o AD on-premises e vice-versa.
|
||||
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Onde encontrar credenciais para a cloud quando um PC é comprometido.
|
||||
- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Internals do actor-token do Exchange Hybrid, caminhos de abuso corrigidos vs ainda relevantes, e como avaliar o risco residual após migrações com split de service-principal.
|
||||
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): Gerar um cert baseado no PRT para logar de uma máquina para outra.
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Onde encontrar credenciais para a nuvem quando um PC é comprometido.
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Roubar Azure cookies do navegador e usá-los para fazer login.
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): Gerar um certificado baseado no PRT para fazer login de uma máquina em outra.
|
||||
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): O que é o PRT, como roubá-lo e usá-lo para acessar recursos Azure se passando pelo usuário.
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Roubar cookies do Azure do navegador e usá-los para fazer login.
|
||||
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Como abusar do Pass-through Authentication para mover da cloud para o AD on-premises e vice-versa.
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): O que é o PRT, como roubá-lo e usá-lo para acessar recursos do Azure se passando pelo usuário.
|
||||
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Como abusar do Seamless SSO para mover do on-prem para a cloud.
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Como abusar do Pass-through Authentication para mover da nuvem para o AD on-premises e vice-versa.
|
||||
|
||||
- **Another way to pivot from cloud to On-Prem is** [**abusing Intune**](../az-services/intune.md)
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Como abusar do Seamless SSO para mover de on-prem para a nuvem.
|
||||
|
||||
- **Outra forma de pivotar da nuvem para On-Prem é** [**abusing Intune**](../az-services/intune.md)
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
# Az - Exchange Hybrid Impersonation (ACS Actor Tokens)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
Em designs legados de 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 poderia obter tokens first-party com contexto de privilégio 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 aproveitada para um comprometimento mais profundo do tenant.
|
||||
|
||||
## Caminhos de Ataque e Fluxo Técnico
|
||||
|
||||
### Modify Federation Configuration via Exchange
|
||||
|
||||
Historicamente, os tokens do Exchange tinham permissões para gravar configurações de domínio/federação. Do ponto de vista do atacante, isso permitia a manipulação direta dos 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 uma impersonação ao estilo ADFS mudando a configuração de federação a partir do lado cloud, mesmo quando o atacante começava apenas com o comprometimento do Exchange on-prem.
|
||||
|
||||
### ACS Actor Tokens and Service-to-Service Impersonation
|
||||
|
||||
Exchange's hybrid auth path used Access Control Service (ACS) actor tokens with `trustedfordelegation=true`. Those actor tokens were then embedded into a second, unsigned service token that carried the target user identity in an attacker-controlled section. Because the outer token was unsigned and the actor token delegated broadly, the caller could swap target users without re-authenticating.
|
||||
|
||||
Na prática, uma vez obtido o actor token, o atacante dispunha de um primitivo de impersonação de longa duração (tipicamente cerca de 24 horas) que era difícil de revogar no meio do seu período de validade. 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 impersonação com o valor `netId` da vítima. Isso fornecia ação administrativa Entra direta como usuários arbitrários e possibilitava fluxos de takeover completo do tenant (por exemplo, criando uma nova conta Global Administrator).
|
||||
|
||||
## O que Não Funciona Mais
|
||||
|
||||
O caminho de impersonação via `graph.windows.net` por meio dos actor tokens do Exchange Hybrid foi corrigido. A antiga cadeia "Exchange to arbitrary Entra admin over 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 impersonação Exchange/SharePoint separado da escalada de impersonação no Graph que já foi corrigida.
|
||||
|
||||
## O que Ainda Pode Importar na Prática
|
||||
|
||||
Se uma organização ainda executa uma configuração hybrid antiga ou incompleta com trust compartilhado e material de certificado exposto, o impacto da impersonação 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 de 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 de service principal compartilhado deixe de existir. Ambientes que completaram 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/fonte aponta para atividade do Exchange Online. Esse padrão de identidade mista é um sinal de caça de alto valor, embora defensores devam criar baseline dos fluxos de trabalho legítimos de administrador do Exchange para reduzir falsos positivos.
|
||||
|
||||
## Referências
|
||||
|
||||
- https://www.youtube.com/watch?v=rzfAutv6sB8
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user