Attacco DCShadow: Domain Controller Canaglia

La tecnica di attacco DCShadow domain controller canaglia (registrazione di un domain controller canaglia) — resa pubblica da Benjamin Delpy e Vincent Le Toux (creatori di Mimikatz) al BlueHat IL nel gennaio 2018 — permette a un attaccante con privilegi sufficienti di registrare temporaneamente una macchina compromessa come domain controller e di inviare modifiche agli oggetti di Active Directory al resto del dominio attraverso il normale protocollo di replica, invece che tramite una API di scrittura standard. MITRE ATT&CK la classifica come T1207 — Rogue Domain Controller.

Questo articolo copre il meccanismo, il motivo per cui elude il logging che normalmente rileva le modifiche privilegiate in AD, e passaggi concreti di rilevamento e remediation. Per la tecnica di abuso della replica più comune — leggere segreti invece di scrivere modifiche — vedi Abuso di ACL e DCSync: I Percorsi Silenziosi verso Domain Admin e Monitoraggio Sicurezza AD: Event ID che Contano per la base di audit sulla replica più ampia che questa tecnica è progettata per eludere.

L'Attacco DCShadow Domain Controller Canaglia Spiegato

Ogni domain controller di Active Directory è rappresentato nella directory stessa: un oggetto server e un oggetto nTDSDSA figlio sotto il naming context Configuration (CN=Sites), la stessa classe di oggetti creata ogni volta che un vero DC viene promosso. DCShadow abusa del fatto che qualsiasi principal in possesso dei permessi di replica appropriati può creare quella stessa coppia di oggetti su una macchina che non è realmente un domain controller — per poi usare il protocollo RPC legittimo Directory Replication Service (DRS) per far sì che il resto del dominio recuperi "modifiche" da quella macchina come se fosse un peer fidato.

⚠️

⚠️ Attenzione: poiché la modifica arriva tramite replica anziché tramite scritture LDAP o il log Security locale di un DC, DCShadow non genera gli eventi su cui i team di sicurezza normalmente fanno affidamento per rilevare una manomissione privilegiata di AD — nessun 4738 (account utente modificato), nessun 5136 (oggetto del servizio directory modificato) collegato alla modifica stessa.

DCShadow è distinto da DCSync. DCSync (DS-Replication-Get-Changes) abusa dei diritti di replica per leggere segreti — più spesso per estrarre hash delle password dal punto di vista di un DC legittimo. DCShadow abusa di un insieme diverso, ma adiacente, di diritti di replica per scrivere — fabbrica una fonte di replica canaglia e inietta modifiche nella directory. Le due tecniche vengono spesso confuse perché condividono la stessa famiglia di protocollo sottostante (MS-DRSR) e la stessa domanda di audit su "chi ha diritti vicini a DCSync", ma sono primitive di attacco distinte con superfici di rilevamento distinte.

Come Funziona

Passo 1 — Acquisire i Diritti

Secondo una ricerca indipendente sui permessi minimi pubblicata da Lab of a Penetration Tester nell'aprile 2018, DCShadow non richiede rigorosamente l'appartenenza a Domain Admin o Enterprise Admin — quello è il percorso più comune, ma la tecnica può funzionare anche con un insieme più ristretto di permessi concessi direttamente sull'oggetto dominio: i diritti estesi DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, secondo il riferimento ADSchema di Microsoft), DS-Replication-Manage-Topology, e DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, secondo il riferimento ADSchema di Microsoft) — più abbastanza WriteProperty sull'oggetto computer della macchina attaccante stessa (vedi Superficie di attacco degli oggetti computer in Active Directory per la classe di rischio più ampia) per impostarne gli Service Principal Names. Per questo il catalogo di EtcSec traccia chi possiede i diritti Server Trust Account come un finding distinto e critico: è la precondizione che rende possibile registrare un DC canaglia in primo luogo, indipendentemente dal fatto che quell'account sia anche Domain Admin.

Passo 2 — Registrare il DC Canaglia

Tramite il modulo lsadump::dcshadow, Mimikatz (eseguito con privilegi SYSTEM sulla macchina attaccante) imposta due Service Principal Names sull'account computer compromesso, quindi crea gli oggetti server e nTDSDSA nella partizione Configuration. Secondo la strategia di rilevamento DET0276 di MITRE, gli SPN usati sono lo SPN Global Catalog (GC/<hostname>/<domain>) e lo SPN dell'interfaccia Directory Replication Service (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) — le stesse classi di SPN che porta un DC legittimo, ed è esattamente ciò che permette alla macchina di farsi passare per un DC ai fini della replica.

Passo 3 — Inviare la Modifica

Con il DC canaglia registrato e gli SPN impostati, un secondo comando lsadump::dcshadow /push innesca un evento di replica in uscita: la modifica fabbricata di oggetto o attributo (una riscrittura di ACL, un'appartenenza a un gruppo, un msDS-KeyCredentialLink, un attributo di schema — DCShadow può colpire praticamente qualsiasi dato AD scrivibile) viene replicata dalla macchina dell'attaccante a un DC reale tramite IDL_DRSReplicaAdd/GetNCChanges, esattamente come se provenisse da un DC peer.

Passo 4 — Deregistrarsi e Sparire

L'attaccante rimuove gli oggetti server e nTDSDSA canaglia, ripristina gli SPN originali, e la macchina torna ad apparire come un normale computer aggiunto al dominio. La modifica malevola, tuttavia, si è già replicata su ogni DC reale del dominio e persiste nella directory.

Rilevamento

I passaggi di registrazione e deregistrazione sono la finestra rilevabile — la modifica inviata in sé, una volta replicata, appare come qualsiasi altro attributo della directory.

Indicatore	Event ID	Fonte	Descrizione
Naming context di origine della replica stabilito	4928	DC — sottocategoria "Audit Detailed Directory Service Replication"	Secondo il riferimento eventi di Microsoft, si attiva quando un DC inizia a trattare una fonte come partner di replica. Su un DC legittimo questo corrisponde a promozioni note; un Source DRA inatteso è il segnale da monitorare.
Naming context di origine della replica rimosso	4929	DC — stessa sottocategoria	Secondo il riferimento eventi di Microsoft, si attiva alla deregistrazione — il passaggio di pulizia di DCShadow. Una coppia 4928/4929 ravvicinata, proveniente da un host che non è un DC noto, è un segnale forte.
Account computer modificato	4742	DC — "Audit Computer Account Management"	Secondo il riferimento eventi di Microsoft, si attiva quando vengono impostati gli SPN della macchina attaccante. Confronta il Subject (l'account che effettua la modifica) con l'elenco noto dei detentori di Domain Admin / Server Trust Account.
Creazione di oggetto nTDSDSA / server nel NC Configuration	—	Directory Service Changes (5137), richiede una SACL su `CN=Sites,CN=Configuration`	Active Directory non audita la partizione Configuration per impostazione predefinita. È necessaria una SACL sul container Sites prima che questo segnale esista — questo corrisponde direttamente alla correlazione di "oggetti nTDSDSA/server inattesi" secondo la guida DET0276 di MITRE.
Uso inatteso di SPN DRS	—	Correlazione autenticazione Kerberos / SIEM	Secondo MITRE DET0276, autenticazione Kerberos che usa le classi di SPN `GC/` o `E3514235-4B06-11D1-AB04-00C04FC2DCD2` da un host esterno all'elenco dei DC noti.

💡

💡 Suggerimento: nessuno dei segnali della partizione Configuration sopra elencati viene catturato per impostazione predefinita. Se la tua unica visibilità sulla replica è la politica di audit predefinita del NC di dominio, non vedrai una registrazione di DC canaglia DCShadow. Questo è esattamente il varco che la tecnica è progettata per sfruttare — l'analisi esterna (analisi di SentinelOne) raccomanda di trattare la coppia 4928/4929 e le SACL del NC Configuration come base, non come aggiunta opzionale.

Remediation

1. Verificare Chi Possiede i Diritti Server Trust Account e Replica-Scrittura

La precondizione di un attacco DCShadow è un principal con DS-Install-Replica, DS-Replication-Manage-Topology, e DS-Replication-Synchronize sull'oggetto dominio — o permessi più ampi che consentono di impostare gli SPN di un account computer. Enumera questo allo stesso modo in cui verificheresti gli account capaci di DCSync, ma per i diritti estesi lato scrittura:

# Enumerare i principal non standard con diritti estesi di replica sull'oggetto dominio
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Confronta ogni risultato con la tua appartenenza attesa a Domain Admin / Enterprise Admin — tutto il resto è un permesso non documentato da investigare.

2. Abilitare l'Audit della Partizione Configuration

Le modifiche al NC Configuration non vengono auditate per impostazione predefinita. Applica una SACL a CN=Sites,CN=Configuration,DC=<domain> (e idealmente alla radice del NC Configuration) affinché la creazione/eliminazione di oggetti nTDSDSA e server generi eventi Directory Service Changes (5136/5137), e abilita la sottocategoria "Audit Detailed Directory Service Replication" a livello di dominio affinché 4928/4929 vengano catturati.

3. Ridurre al Minimo e Segmentare gli Accessi Privilegiati

💡

💡 Quick Win: tratta "chi può registrarsi come DC" come una questione di Tier 0, non solo "chi è Domain Admin".

Segui un modello di amministrazione a livelli — vedi Messa in Sicurezza di Active Directory: Priorità — affinché gli account capaci di detenere diritti di replica-scrittura siano lo stesso piccolo insieme monitorato che già tratti come Tier 0, senza appartenenza permanente oltre a ciò che serve attivamente. È la stessa disciplina che previene la deriva degli accessi privilegiati più in generale.

4. Allertare sulla Coppia 4928/4929 Correlata ai DC Noti

Costruisci una regola di rilevamento che segnali qualsiasi 4928 (e il suo 4929 associato) il cui Source DRA non corrisponda al tuo inventario mantenuto di domain controller legittimi. Poiché una finestra di registrazione DCShadow è tipicamente breve, l'inoltro dei log quasi in tempo reale conta qui più che nella maggior parte dei rilevamenti AD — una revisione batch giornaliera in genere verrà eseguita dopo che il DC canaglia si è già deregistrato.

Come EtcSec Rileva Questo

Il catalogo delle vulnerabilità AD di EtcSec segnala questa esposizione tramite due controlli: DCSHADOW_EVIDENCE, che cerca prove dirette che una registrazione di DC canaglia DCShadow sia avvenuta, e SERVER_TRUST_ACCOUNT_RIGHT, che segnala gli account e i gruppi in possesso dei diritti per impostare un server trust account — la precondizione che rende la tecnica praticabile, indipendentemente dal fatto che quell'account sia anche Domain Admin. Gli ambienti che hanno già revisionato i loro account capaci di DCSync dovrebbero trattare questo come l'audit complementare: i diritti di replica in lettura e scrittura vengono di solito concessi dagli stessi errori di delega, ma raramente revisionati insieme.

ℹ️

ℹ️ Nota: EtcSec verifica automaticamente le prove di DCShadow e i diritti Server Trust Account a ogni audit AD. Esegui un audit gratuito per verificare se il tuo ambiente presenta questa esposizione.

Attacco DCShadow Controller di Dominio Canaglia: Come Elude l'Audit delle Modifiche AD