Iniezione SIDHistory: SID noto verso Domain Admin

Cos'è l'iniezione SIDHistory? L'escalation di privilegi tramite SID noto, spiegata

L'iniezione SIDHistory con un SID noto è una tecnica di persistenza ed escalation di privilegi in Active Directory in cui un attaccante scrive un SID privilegiato noto — come il suffisso RID 512 (Domain Admins) o RID 519 (Enterprise Admins) del SID di dominio — nell'attributo sIDHistory di un account non privilegiato. MITRE ATT&CK classifica questo come la sotto-tecnica T1134.005 — Access Token Manipulation: SID-History Injection.

Poiché ogni SID memorizzato in sIDHistory viene copiato nel PAC Kerberos (Privilege Attribute Certificate) dell'account e, di conseguenza, nel suo token di accesso al momento del login, l'account con pochi privilegi eredita di fatto i diritti di Domain Admin senza mai essere aggiunto al gruppo Domain Admins. Gli audit sull'appartenenza ai gruppi, le revisioni dei gruppi annidati e i controlli net group /domain risultano tutti puliti — l'escalation è invisibile a qualsiasi controllo che ispezioni solo l'appartenenza ai gruppi.

Come funziona: sIDHistory e i SID noti

sIDHistory è un attributo legittimo di Active Directory progettato per le migrazioni tra domini e tra foreste: quando un account viene spostato in un nuovo dominio, il suo vecchio SID viene conservato in sIDHistory in modo che mantenga l'accesso alle risorse per cui era già autorizzato, senza che un amministratore debba riscrivere manualmente ogni ACL. La funzione DsAddSidHistory di Microsoft e l'impostazione di trust EnableSIDHistory esistono proprio per supportare questo scenario di migrazione.

Il problema è che Windows non distingue tra un SID aggiunto durante una migrazione legittima e uno aggiunto da un attaccante. Al login, il domain controller costruisce il PAC dell'utente a partire da tutti i SID associati all'account — gruppo primario, tutte le appartenenze ai gruppi e l'intero contenuto di sIDHistory — e quel PAC diventa il token di accesso di cui si fida ogni servizio a valle. Questa è una superficie di persistenza fondamentalmente diversa dall'annidamento pericoloso dei gruppi, dove il privilegio è almeno visibile nell'elenco dei membri di un gruppo — qui, nessuna appartenenza a gruppo cambia mai.

Gli account di dominio normali, e persino la maggior parte degli strumenti amministrativi, non possono semplicemente eseguire Set-ADUser -Replace @{sidHistory=...} via LDAP; sIDHistory è un attributo costruito/protetto. In pratica, gli attaccanti vi accedono tramite:

• I moduli sid::patch e sid::add di Mimikatz, eseguiti direttamente su un domain controller con privilege::debug — il che richiede un accesso equivalente a Domain Admin/SYSTEM sul DC stesso, e sid::patch non funziona più su Windows Server 2016 e versioni successive.
• Add-ADDBSidHistory di DSInternals modificava il database ntds.dit offline e richiedeva l'arresto del servizio NTDS — usato direttamente contro il database di un DC anziché tramite la normale API di replica. Al momento della stesura, questo cmdlet è stato rimosso dall'attuale modulo PowerShell DSInternals (la sua documentazione è conservata solo come riferimento); l'equivalente mantenuto oggi è Add-ADReplSidHistory, che esegue l'iniezione online tramite il protocollo di replica MS-DRSR e richiede comunque diritti di replica equivalenti a quelli di un DC.
• L'API legittima DsAddSidHistory, pensata per la migrazione tra foreste, che alcuni strumenti usano in modi non previsti quando l'attaccante controlla già privilegi equivalenti a quelli di un DC.

In ogni caso, l'attaccante ha già bisogno di un accesso di livello replica o domain controller per scrivere in sIDHistory — questa è una tecnica di persistenza e furtività post-compromissione, non un vettore di accesso iniziale. Ciò che giustifica un rilevamento dedicato è ciò che accade dopo: il privilegio iniettato non è visibile nell'appartenenza ai gruppi, sopravvive ai reset della password e non è influenzato dalla rimozione dell'account da alcun gruppo (poiché non ne è mai stato membro).

La catena d'attacco

Fase 1 — Ottenere accesso di livello DC o equivalente a replica

L'attaccante ha prima bisogno di privilegi equivalenti a Domain Admin, o di accesso diretto a un domain controller — ad esempio tramite una precedente compromissione DCSync, accesso diretto a console/RDP del DC, o una copia esfiltrata di ntds.dit. Questo passaggio è lo stesso prerequisito di un attacco DCSync o di un Golden Ticket falsificato.

Fase 2 — Identificare l'account bersaglio e il SID noto

L'attaccante sceglie un account a bassa visibilità e basso privilegio (un account di servizio, un vecchio account di un fornitore, o un account appena creato) e il SID di dominio con il RID noto che vuole iniettare:

Fase 3 — Iniettare il SID in sIDHistory

Su un DC compromesso, con Mimikatz:

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Storicamente, offline contro una copia di ntds.dit, con DSInternals:

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Fase 4 — Autenticarsi come l'account con pochi privilegi

Al login successivo, il DC costruisce un PAC per lowpriv-svc che include il SID Domain Admins iniettato. Ogni servizio che si fida dei dati di autorizzazione Kerberos ora concede all'account un accesso equivalente a Domain Admin — mentre la sua reale appartenenza ai gruppi continua a non mostrare nulla di anomalo.

🚨 Pericolo: poiché il SID iniettato risiede sull'oggetto account stesso anziché in un ticket falsificato, persiste a ogni login futuro finché qualcuno non ispeziona specificamente e cancella sIDHistory — a differenza di un Golden Ticket, che scade o viene invalidato da una rotazione di KRBTGT.

Rilevamento

Le modifiche a sIDHistory sono rare in un ambiente sano al di fuori di una finestra di migrazione attiva, il che le rende una superficie di rilevamento ad alto segnale — ma solo se è abilitata la giusta policy di audit e vengono controllati i RID giusti.

Gli Event ID 4765/4766 richiedono che la sottocategoria di audit avanzato "Controlla gestione account utente" sia abilitata — non è attiva per impostazione predefinita in molti ambienti, quindi verificare la policy di audit prima di presumere la copertura.

Enumerare gli account esistenti alla ricerca di un sIDHistory valorizzato e filtrare specificamente per i RID privilegiati noti, non solo per un valore storico qualsiasi:

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

Microsoft Defender for Identity offre una valutazione della postura di sicurezza per gli account che presentano un valore sIDHistory e include una logica di rilevamento comportamentale calibrata per segnalare modifiche inattese dell'attributo SID-History al di fuori di un'attività di migrazione — un controllo compensativo utile dove la policy di audit avanzato presenta lacune.

Correzione

1. Abilitare la policy di audit avanzato per la gestione degli account. Attivare "Controlla gestione account utente" affinché gli Event ID 4765/4766 vengano effettivamente generati, e inoltrarli al proprio SIEM con avvisi su qualsiasi occorrenza al di fuori di una finestra di modifica di migrazione nota.
2. Limitare e monitorare l'accesso di livello DC ed equivalente a replica. Poiché iniettare sIDHistory richiede accesso Domain Admin/SYSTEM su un DC o una copia di ntds.dit, il controllo a maggior impatto è lo stesso che blocca DCSync e i Golden Ticket: ridurre al minimo e sottoporre ad audit gli account che detengono DS-Replication-Get-Changes-All e limitare il login interattivo/RDP sui domain controller.
3. Sottoporre sIDHistory ad audit su tutto il dominio con cadenza ricorrente, non solo dopo una migrazione nota. Qualsiasi valore valorizzato che contenga un RID privilegiato noto non collegato a un progetto di migrazione documentato e limitato nel tempo va trattato come un incidente critico.
4. Ripulire sIDHistory al termine delle migrazioni. Una volta corrette le ACL verso i nuovi SID, cancellare i valori sIDHistory ereditati — una superficie di attacco più piccola senza valori residui è più facile da monitorare rispetto a una in cui "un po' di SID history è previsto".
5. Distribuire uno strumento di rilevamento e risposta alle minacce sull'identità (ITDR), come Microsoft Defender for Identity, per aggiungere copertura comportamentale sulle modifiche a sIDHistory che integri le regole statiche basate sui log di audit.

# Rimuovere tutti i valori sIDHistory da un account una volta completate migrazione/correzione
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

Come EtcSec rileva questo problema

L'audit Active Directory di EtcSec distingue specificamente i problemi di igiene SID-History dagli indicatori attivi di escalation dei privilegi:

• SIDHISTORY_WELLKNOWN_SIDS (Critico) — segnala qualsiasi account il cui attributo sIDHistory contiene un RID privilegiato noto (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) corrispondente al SID del dominio stesso — lo schema specifico descritto in questo articolo, non una semplice presenza generica di SID History.
• SID_HISTORY (Alto) — segnala qualsiasi account con un sIDHistory valorizzato, in modo che il legittimo lavoro di pulizia post-migrazione possa essere tracciato e completato.
• SIDHISTORY_RECENT_CHANGES (Info) — evidenzia gli oggetti il cui sIDHistory è cambiato di recente, per la correlazione con finestre di migrazione documentate.
• DCSYNC_CAPABLE — segnala il privilegio di punto di ingresso (account non-DC che detengono diritti di replica) che è il prerequisito tipico per raggiungere un DC ed eseguire l'iniezione in primo luogo.

Priorità di revisione

L'iniezione SIDHistory con SID noti va trattata come un riscontro di livello dominio-completo, non come una semplice lacuna di igiene di routine. Iniziare enumerando ogni account con un sIDHistory non vuoto, quindi separare gli artefatti di migrazione documentati dai valori inspiegati — in particolare qualsiasi corrispondenza con un RID privilegiato noto sul SID del dominio corrente. Confermare quali domain controller erano raggiungibili da quali amministratori e account di servizio durante la finestra sospetta, poiché la tecnica richiede accesso di livello DC o equivalente a replica per essere eseguita. Poiché il privilegio iniettato aggira completamente la revisione dell'appartenenza ai gruppi, qualsiasi piano di correzione che verifichi solo l'appartenenza ai gruppi lo mancherà — l'attributo stesso deve essere la fonte di verità.

Controlli adiacenti da rivedere

L'iniezione SIDHistory raramente è isolata: l'accesso di livello DC che richiede è lo stesso accesso che consente l'estrazione di credenziali tramite DCSync, la falsificazione di Golden Ticket e il furto diretto di ntds.dit. Quando si indaga su una sospetta iniezione, verificare chi deteneva diritti di replica e accesso al login sui DC durante la finestra di esposizione, se KRBTGT è stato ruotato di recente, e se altri account privilegiati mostrano segni di manomissione. Una correzione che cancella il sIDHistory di un solo account senza chiudere il percorso di accesso al DC sottostante lascia l'attaccante libero di iniettarlo di nuovo — o in un account diverso.

Letture correlate

Approfondisci questo argomento insieme a Golden Ticket: le chiavi del tuo regno, Abuso di ACL e DCSync: i percorsi silenziosi verso Domain Admin, Attacchi ai trust di Active Directory: dal dominio figlio alla radice della foresta, Account privilegiati di Active Directory: Protected Users, delega e lacune negli account di servizio, Annidamento pericoloso dei gruppi in Active Directory e Monitoraggio di Active Directory: gli Event ID di sicurezza che contano.

• Golden Ticket: le chiavi del tuo regno
• Abuso di ACL e DCSync: i percorsi silenziosi verso Domain Admin
• Attacchi ai trust di Active Directory: dal dominio figlio alla radice della foresta
• Account privilegiati di Active Directory: Protected Users, delega e lacune negli account di servizio
• Annidamento pericoloso dei gruppi in Active Directory
• Monitoraggio di Active Directory: gli Event ID di sicurezza che contano

Checklist di validazione

Prima di chiudere la revisione, rieseguire l'enumerazione di sIDHistory per RID noto in produzione e confermare che non rimanga alcun riscontro inspiegato. Verificare che la policy di audit avanzato sia abilitata su ogni domain controller affinché gli Event ID 4765/4766 vengano effettivamente generati, non solo teoricamente disponibili. Confermare che i diritti di replica e l'accesso al login sui DC siano stati limitati agli account che ne hanno realmente bisogno, e registrare le evidenze — l'output dell'enumerazione e lo stato della policy di audit — come base di riferimento per il prossimo audit ricorrente.