Escalation di privilegi Exchange WriteDacl dominio Active Directory: come un'installazione di dieci anni fa distribuisce ancora Domain Admin

Cos'è l'escalation di privilegi Exchange WriteDacl dominio Active Directory

Le configurazioni errate di escalation di privilegi Exchange WriteDacl dominio Active Directory sono tra i default più gravi ancora presenti negli ambienti che hanno installato Exchange Server on-premise in un qualsiasi momento nell'ultimo decennio. Quando Exchange Server 2013, 2016 o 2019 viene configurato con il modello di permessi condivisi predefinito di Microsoft, al gruppo di sicurezza Exchange Windows Permissions viene concesso il diritto WriteDacl — il diritto di modificare la discretionary access control list (DACL) — direttamente sull'oggetto dominio alla radice di Active Directory. Quella singola access control entry (ACE), a pochi passaggi da una catena breve, basta a consegnare a un aggressore un accesso equivalente a Domain Admin sull'intera foresta, non solo sull'organizzazione Exchange.

Il gruppo Exchange Trusted Subsystem — l'identità di servizio che ogni server Exchange usa per agire in AD per conto degli utenti finali tramite il modello RBAC (Role Based Access Control) di Exchange — è a sua volta annidato per default dentro Exchange Windows Permissions (Microsoft Learn, «Split permissions in Exchange Server»). Chiunque possa aggiungere un account a Exchange Trusted Subsystem, o comprometta direttamente un server Exchange, eredita il diritto WriteDacl sull'oggetto dominio.

Perché non è «solo» il CVE-2019-1166

Non si tratta di un singolo CVE risolvibile con una patch: la stessa documentazione Microsoft sui permessi condivisi lo presenta come un default architetturale del modello di permessi condivisi, non come una vulnerabilità con una versione correttiva. Questa distinzione conta, perché il testo di alcuni cataloghi su questo finding viene talvolta erroneamente incrociato con il CVE-2019-1166 — un CVE reale, ma che copre un bypass NTLM Message Integrity Check (MIC) non correlato («Drop the MIC 2», scoperto dal Preempt Research Team e corretto da Microsoft nel Patch Tuesday di ottobre 2019, secondo l'advisory di Praetorian). Quella patch, e la sua gemella di giugno 2019 CVE-2019-1040, hanno rafforzato le difese contro NTLM relay in generale; nessuna delle due ha toccato l'ACE WriteDacl che Exchange lascia sull'oggetto dominio. Le organizzazioni che hanno installato entrambe senza mai adottare i permessi condivisi restano esposte ancora oggi, e un domain controller completamente patchato non dice nulla sul fatto che questa ACE sia ancora presente — vedi la nostra analisi più ampia di abuso ACL e percorsi DCSync verso Domain Admin per capire come queste concessioni di accesso si sommano ad altre configurazioni errate di Active Directory.

Come funziona: da Exchange Windows Permissions a DCSync

La catena di privilegi predefinita

La catena da un'identità Exchange con privilegi eccessivi (o semplicemente compromessa) alla compromissione completa del dominio è breve:

1. Exchange Windows Permissions detiene un'ACE WriteDacl sull'oggetto dominio.
2. Exchange Trusted Subsystem è membro di Exchange Windows Permissions per default.
3. I membri del gruppo di ruolo RBAC Organization Management possono modificare l'appartenenza di altri gruppi di sicurezza Exchange, incluso Exchange Trusted Subsystem (ADSecurity.org, «Mitigating Exchange Permission Paths to Domain Admins in Active Directory»; Trimarc Security).
4. Chiunque si trovi in quella catena — o comprometta direttamente l'account macchina di un server Exchange — può usare il diritto WriteDacl per scrivere una nuova ACE sull'oggetto dominio che concede DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, i due diritti estesi da cui dipende DCSync.
5. Da lì, una richiesta di replica estrae tutti gli hash delle password del dominio, incluso quello di krbtgt. È lo stesso abuso dei diritti di replica che trattiamo nella nostra guida di audit sui permessi ACL, DPAPI, tombstone e schema — Exchange è semplicemente la fonte più comune di questa concessione, non l'unica.

# Enumerazione in sola lettura: Exchange Windows Permissions (o un gruppo annidato)
# detiene ancora WriteDacl sull'oggetto dominio?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

L'amplificazione PrivExchange del 2019

Nel gennaio 2019, il ricercatore Dirk-jan Mollema ha dimostrato che questo default non richiedeva nemmeno un punto d'appoggio preesistente in un gruppo Exchange. La funzionalità PushSubscription di Exchange poteva essere sfruttata per forzare l'account macchina di un server Exchange ad autenticarsi, via HTTP, verso un endpoint controllato dall'aggressore. Poiché NTLM su HTTP non imposta per default il flag di firma obbligatoria, quell'autenticazione poteva essere inoltrata a LDAP e combinata con il diritto WriteDacl del server per concedere all'aggressore privilegi DCSync — attivabile da qualsiasi utente con una mailbox (dirkjanm.io, «Abusing Exchange: one API call away from Domain Admin»). Gli aggiornamenti cumulativi Exchange di febbraio 2019 di Microsoft hanno affrontato il problema da due direzioni: KB4490060 ha modificato il contratto di autenticazione delle Push Notification di Exchange Web Services in modo che le sottoscrizioni non trasmettessero più credenziali forzabili verso un'autenticazione in uscita, e KB4490059 ha documentato come ridurre i permessi Active Directory predefiniti di Exchange in futuro — ma né questa patch, né le successive patch del bypass NTLM MIC, rimuovono un'ACE già scritta su un oggetto dominio anni prima.

Una variante comune nel mondo reale aggrava ulteriormente il problema: le organizzazioni che hanno migrato le mailbox su Exchange Online spesso mantengono un server Exchange on-premise unicamente per la gestione degli attributi AD, perché le linee guida ibride di Microsoft hanno storicamente sconsigliato di rimuovere completamente l'ultimo server on-premise. Quel server mantenuto, e i gruppi AD dietro di esso, continuano a portare la stessa concessione WriteDacl a tempo indeterminato — è esattamente così che un'installazione di dieci anni fa finisce per distribuire Domain Admin in un ambiente dove ormai nessuno considera Exchange «nel perimetro», molto dopo che le mailbox stesse si sono spostate nel cloud.

Rilevamento

L'audit di Directory Service Access e Directory Service Changes non è abilitato per default sui domain controller, e anche quando lo è, l'Event ID 4662 si genera solo per gli oggetti che portano una SACL corrispondente. Entrambe le lacune devono essere colmate prima che uno qualsiasi dei seguenti indicatori compaia davvero nei log (Altered Security, «A primer on DCSync attack and detection»). La nostra guida al monitoraggio di Active Directory sugli Event ID che contano approfondisce i prerequisiti di audit policy per tutti questi indicatori.

Rilevamento basato sui log

Enumerazione proattiva

Poiché l'ACE stessa può avere anni e restare silenziosa — non genera un nuovo evento solo per il fatto di esistere — il monitoraggio dei log va abbinato a un'enumerazione proattiva periodica: dsacls o Get-Acl "AD:\<domain DN>" sull'oggetto dominio, oppure una raccolta BloodHound verificata specificamente per un edge WriteDacl che atterra sul nodo dominio. Trattatelo come trattereste il privileged access drift: un audit puntuale dimostra solo che l'ACE non c'era il giorno del controllo, non che resti assente in seguito.

Remediation

Controlli compensativi immediati

1. Enumerare. Esegui dsacls o Get-Acl sull'oggetto dominio e verifica se Exchange Windows Permissions / Exchange Trusted Subsystem detiene WriteDACL; confronta con una raccolta BloodHound per lo stesso edge.
2. Ridurre il raggio d'impatto immediato se una migrazione completa ai permessi condivisi non è ancora praticabile: rimuovi Exchange Trusted Subsystem da Exchange Windows Permissions e richiedi un processo controllato e loggato per qualsiasi aggiunta futura a Organization Management, Exchange Windows Permissions o Exchange Trusted Subsystem (Trimarc Security).

La soluzione permanente

3. Adottare il modello di permessi condivisi di Microsoft. Lo split RBAC è il default raccomandato da Microsoft; lo split di Active Directory offre una separazione completa tra l'amministrazione Exchange e quella AD. Entrambi richiedono di rieseguire il Setup con /PrepareAD /ActiveDirectorySplitPermissions:true, più /PrepareAllDomains (o un /PrepareDomain per dominio) nelle foreste multi-dominio (Microsoft Learn, «Split permissions in Exchange Server»). Questo è ciò che rimuove davvero le ACE di Exchange Windows Permissions dall'oggetto dominio — non una patch di sicurezza Windows o Exchange.
4. Dismettere correttamente. Se Exchange è già stato migrato fuori sede o ritirato, verifica che l'ACE dell'oggetto dominio sia stata rimossa come parte di quel processo. Il deprovisioning di Exchange non rimuove automaticamente e retroattivamente una precedente concessione WriteDacl, ed è esattamente così che un'installazione di dieci anni fa continua a distribuire Domain Admin molto dopo lo spegnimento dell'ultimo server Exchange.
5. Verificare. Riesegui l'enumerazione del passaggio 1 dopo la remediation e conferma che i diritti DS-Replication-Get-Changes(-All) sull'oggetto dominio siano limitati ai domain controller e agli account di replica esplicitamente autorizzati. Integra questo controllo in un workflow di audit ricorrente invece di una pulizia una tantum, poiché riattivare i permessi condivisi o riaggiungere Exchange Trusted Subsystem a Exchange Windows Permissions ripristina silenziosamente l'ACE, senza alcun segnale di allarme evidente.

Come EtcSec rileva questo

L'audit Active Directory di EtcSec segnala direttamente questo schema tramite il controllo Exchange Privilege Escalation Risk (EXCHANGE_PRIV_ESC_PATH), che ispeziona l'ACL dell'oggetto dominio alla ricerca della concessione WriteDacl di Exchange Windows Permissions e ricostruisce l'annidamento dei gruppi fino alla sua origine. È correlato con i controlli più ampi ACL WriteDACL (ACL_WRITEDACL) e DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES), oltre al rollup generale DCSync Capable (DCSYNC_CAPABLE), cosicché un percorso di attacco completo da Exchange a DCSync compare come un unico finding prioritizzato invece di quattro voci ACL scollegate, che provenga da un server Exchange attivo o da un residuo di dieci anni che nessuno ha pensato di dismettere.