Iniezione SID-History: SID-History Injection (T1134.005)

In un esercizio red team la simulazione di SID-History Injection richiede un ambiente di laboratorio con almeno un dominio Active Directory e credenziali di Domain Admin già ottenute in fasi precedenti della kill chain. È fondamentale operare esclusivamente in lab isolati: la modifica dell'attributo sIDHistory è una tecnica ad alto impatto che può alterare permanentemente la sicurezza di un dominio produttivo.

Il tool di riferimento è Mimikatz (open source), disponibile nel repository ufficiale di gentilkiwi su GitHub. Il modulo dedicato è misc::addsid, che consente di aggiungere un SID arbitrario all'attributo sIDHistory di un account bersaglio. La sequenza tipica prevede prima l'elevazione a SYSTEM sul Domain Controller con privilege::debug e token::elevate, quindi l'invocazione del modulo con l'account vittima e il SID da iniettare (tipicamente quello di Enterprise Admins, terminante in -519).

Una catena completa in laboratorio si sviluppa così:

• Ricognizione dei SID privilegiati del dominio con PowerView (open source, parte del progetto PowerSploit) tramite cmdlet come Get-DomainGroup e Get-DomainSID.
• Compromissione di un account con diritti di replica per estrarre hash via DCSync (lsadump::dcsync di Mimikatz).
• Iniezione del SID di Enterprise Admins nell'attributo sIDHistory di un utente controllato.
• Verifica: nuova sessione di logon dell'utente compromesso e ispezione del token con whoami /groups, che mostrerà l'appartenenza effettiva ai gruppi privilegiati.

Alternativa a Mimikatz è Empire (open source, versione mantenuta da BC-Security), framework post-exploitation che integra moduli per la manipolazione di SID-History quando eseguito con contesto privilegiato su un Domain Controller. Empire automatizza parti della catena tramite agenti PowerShell e semplifica la persistenza.

Per scenari multi-forest, la tecnica si combina con la forgiatura di Golden Ticket contenenti SID esterni nel campo ExtraSids del PAC Kerberos, tecnica che estende il compromesso oltre il singolo dominio se non è attivo il SID Filtering sui trust. Strumenti come Rubeus (open source) permettono di forgiare ticket TGT con SID arbitrari nel campo ExtraSids per validare la superficie d'attacco su trust inter-foresta.

Documentare ogni modifica e ripristinare sIDHistory al termine del test è essenziale: l'attributo non viene ripulito automaticamente e costituisce una backdoor persistente se lasciato in essere.

La detection di SID-History Injection si fonda sulla correlazione tra modifiche all'attributo sIDHistory in Active Directory e comportamenti anomali dei token nelle sessioni successive. La detection DET0136 definisce una behavior-chain in quattro fasi che il SOC deve implementare come regola composita.

Il log source primario è WinEventLog:Security sui Domain Controller, in particolare l'evento EventCode 5136 ("A directory service object was modified"), che registra le modifiche agli attributi AD. Il filtro va impostato sull'attributo sIDHistory: qualsiasi scrittura fuori da finestre di migrazione approvate deve generare un alert ad alta priorità. In parallelo, il provider ETW Microsoft-Windows-Directory-Services-SAM fornisce visibilità sulle chiamate API sensibili come DsAddSidHistory, spesso invocata da tool offensivi.

Una regola robusta correla tre segnali:

• Modifica di sIDHistory (EventCode 5136) su un account non incluso nella whitelist di servizi di migrazione approvati.
• Nuova sessione di logon (EventCode 4624 con LogonType 3 o 10) dell'account modificato entro una finestra di 15-30 minuti.
• Accesso a risorse privilegiate (share amministrative, cmdlet di gestione AD, connessioni WinRM verso DC) da parte dello stesso account.

Parametri di tuning critici definiti da DET0136:

• PrivilegedSIDList: lista di SID che non devono mai comparire in sIDHistory di utenti standard, inclusi quelli terminanti in -512 (Domain Admins), -519 (Enterprise Admins), -518 (Schema Admins), -544 (Administrators locali).
• AnomalousSIDCountThreshold: alert quando un token contiene più di 2 voci sIDHistory, valore anomalo per account non migrati.
• UserContextFilter: esclusione dei service account ADMT (Active Directory Migration Tool) e delle finestre di migrazione pianificate.
• TimeWindow: correlazione entro 15-30 minuti tra modifica attributo e attività di logon sospetta.

Sul fronte hardening (approccio D3FEND), il controllo preventivo più efficace è l'applicazione del SID Filtering sui trust inter-foresta e sui trust esterni. Sui forest trust la disabilitazione di SID-History si ottiene con il comando netdom trust /EnableSIDHistory:no eseguito sul Domain Controller; sui trust esterni si applica il SID Filter Quarantining con netdom trust /domain: /quarantine:yes.

I falsi positivi legittimi provengono quasi esclusivamente da migrazioni AD reali via ADMT o strumenti equivalenti come Quest Migration Manager (a pagamento). Documentare le finestre di migrazione e i service account autorizzati riduce il rumore. Query PowerShell periodiche per enumerare account con sIDHistory popolato (Get-ADUser -Filter {SIDHistory -like ''} -Properties SIDHistory*) forniscono baseline utili per la threat hunting proattiva.

L'analisi forense di un incidente che coinvolge SID-History Injection ruota attorno a tre fonti primarie di artefatti: gli event log dei Domain Controller, il database NTDS.dit di Active Directory e i token di accesso delle sessioni interattive successive all'iniezione.

Sui Domain Controller l'evento cardine è EventCode 5136 nel Security log, che registra la modifica dell'attributo sIDHistory. Il campo Directory Service Object identifica il DN dell'account bersaglio, mentre Attribute Value contiene il SID iniettato. La correlazione con EventCode 4662 ("An operation was performed on an object") permette di ricostruire l'identità del principal che ha effettuato la modifica e la workstation di origine. Eventi 4624 e 4672 successivi mostrano nuovi logon con privilegi elevati non giustificati dall'appartenenza esplicita ai gruppi.

Un passo cruciale è l'estrazione offline dell'attributo sIDHistory dal database NTDS.dit. Su una copia forense del file, ottenuta ad esempio con VSS o ntdsutil ifm, si utilizzano tool open source come impacket-secretsdump (open source, progetto Impacket di Fortra) per dumpare il contenuto includendo gli attributi di history, oppure DSInternals (open source, PowerShell module di Michael Grafnetter) con cmdlet come Get-ADDBAccount che espone esplicitamente il campo SIDHistory di ogni account. Il confronto tra lo stato attuale e backup precedenti del NTDS.dit consente di datare l'iniezione.

La timeline forense tipica include:

• T0: compromissione iniziale e privilege escalation a Domain Admin (spesso via Kerberoasting o furto di credenziali di admin).
• T0+minuti: esecuzione di Mimikatz o Empire sul Domain Controller, evidenza in Sysmon EventCode 1 (process creation) se attivo, con command line contenente misc::addsid o riferimenti ai moduli Empire corrispondenti.
• T0+minuti: modifica dell'attributo, tracciata da EventCode 5136.
• T0+ore/giorni: uso ricorrente dell'account backdoored per accessi laterali, con EventCode 4624 LogonType 3 verso risorse sensibili.

Artefatti aggiuntivi utili: il file NTDS.dit stesso conserva il valore corrente di sIDHistory finché non viene esplicitamente ripulito; i backup periodici di AD (via Windows Server Backup o soluzioni enterprise) forniscono snapshot per stabilire il momento esatto dell'iniezione. Sui client, i token cached nella LSASS memory al momento del logon contengono le voci sIDHistory risolte, ispezionabili post-mortem con Volatility (open source) e il plugin windows.getsids su un memory dump.

La remediation forense richiede la rimozione manuale delle voci sIDHistory sospette (script PowerShell dedicati o ADSI Edit) e l'analisi di tutti gli accessi effettuati dagli account compromessi nella finestra tra iniezione e rilevazione, per identificare pivot laterali e persistenze secondarie eventualmente instaurate.

I dati MITRE ATT&CK forniti per T1134.005 non associano gruppi APT specifici a questa sotto-tecnica, ma la disponibilità di tool offensivi documentati e la sua centralità negli scenari di compromissione totale di foresta ne fanno una tecnica di riferimento negli arsenali di operatori sofisticati, in particolare in contesti di cyber-espionage e ransomware enterprise.

Il profilo di rischio della tecnica si delinea attraverso i due tool documentati nel dataset. Mimikatz (S0002), sviluppato da Benjamin Delpy, integra il modulo MISC::AddSid che consente l'inserimento di qualsiasi SID o account nell'attributo sIDHistory di un utente. La stessa suite utilizza SID-History Injection come componente ausiliaria di attacchi più ampi: nella forgiatura di Golden Ticket i SID arbitrari vengono inseriti nel campo ExtraSids del PAC Kerberos, permettendo di estendere la validità del ticket oltre il dominio originale; nelle operazioni DCSync consente di simulare la replica da un Domain Controller di un altro dominio della stessa foresta. Questa versatilità rende Mimikatz uno strumento chiave per compromessi multi-dominio.

Empire (S0363), framework post-exploitation originariamente rilasciato dal team Adaptive Threat Division e oggi mantenuto in versione community da BC-Security, integra la capacità di aggiungere SID-History a un utente quando l'agente è in esecuzione su un Domain Controller con contesto privilegiato. La disponibilità in un framework modulare abbassa la barriera d'ingresso per operatori meno sofisticati e amplia la platea di attori capaci di sfruttare la tecnica.

Il pattern operativo tipico osservato in incident response su ambienti enterprise segue una sequenza consolidata: compromissione iniziale, escalation locale, movimento laterale fino a un account con diritti di replica AD, esecuzione di DCSync per estrarre l'hash del KRBTGT, forgiatura di Golden Ticket con ExtraSids popolato, oppure iniezione diretta di sIDHistory su account backdoor per persistenza a lungo termine.

Il trend rilevante è l'integrazione della tecnica in playbook di ransomware operator che puntano alla compromissione della foresta prima della fase di encryption, per massimizzare l'impatto e disabilitare backup e strumenti di sicurezza gestiti centralmente. La persistenza silenziosa garantita da sIDHistory — che non appare nei report standard di enumerazione dei gruppi — la rende particolarmente attraente per operatori che pianificano ritorni sull'obiettivo, come nei casi di doppia estorsione con ri-attacco a distanza di mesi.

Sul fronte difensivo, la mitigazione M1015 (Active Directory Configuration) enfatizza il ruolo del SID Filtering come contromisura strutturale sui trust inter-foresta, elemento che rende gli attacchi multi-forest significativamente più complessi quando correttamente implementato.

MITRE ATT&CK: T1134.005 (SID-History Injection), tattiche TA0004 e TA0005. Software: S0002 (Mimikatz), S0363 (Empire). Mitigazione: M1015 (Active Directory Configuration). Detection: DET0136 con analytic AN0383. MITRE D3FEND per mapping difensivo. Il contenuto integra conoscenza professionale di cybersecurity per comandi operativi, tool open source (Mimikatz, Empire, PowerSploit, Rubeus, Impacket, DSInternals, Volatility) e procedure forensi, nel rispetto delle regole di verificabilità e sintassi reale.