Controllo ACE Pericolose SID Orfani tra Domini Active Directory: l'abuso di ACL che la maggior parte degli strumenti non riesce nemmeno a risolvere

Un controllo ACE pericolose SID orfani tra domini Active Directory pone una domanda a cui una revisione ACL standard non arriva mai: quali concessioni nella tua directory sono detenute da trustee che nessuno riesce a identificare? Ogni voce di controllo accesso (ACE) in una DACL di AD identifica il proprio trustee tramite un security identifier (SID), e gli strumenti di revisione quasi sempre risolvono quel SID in un nome leggibile prima di mostrartelo. Ma cosa succede quando il SID non si risolve in nulla — e l'ACE in cui si trova concede il controllo completo?

È una domanda diversa da quella posta da una revisione normale. Una revisione normale chiede: «quali account attivi detengono GenericAll su Tier 0?». Questa chiede: «quali concessioni sono detenute da trustee che la mia directory non riesce a identificare?». Le due producono risultati completamente diversi, e la seconda viene sistematicamente ignorata: una voce il cui trustee non si risolve è facile da rendere, in un report, come una riga vuota, una stringa grezza, o niente del tutto.

Cosa verifica un controllo ACE pericolose SID orfani tra domini Active Directory

Un SID non è un nome. Il riferimento Microsoft Security Identifiers descrive la struttura con precisione: per un account di dominio, «il SID di un security principal viene creato concatenando il SID del dominio con un relative identifier (RID) per l'account». Tutto ciò che precede il segmento finale -RID è l'identificatore di dominio; l'ultimo segmento identifica il principal all'interno di quel dominio.

È questa struttura a rendere classificabile un riferimento interrotto. Prendi un SID trustee che non si risolve in alcun utente, gruppo, computer, unità organizzativa o principal noto, e confronta il suo prefisso di dominio con il SID del tuo dominio:

La distinzione è importante per via di una garanzia che Microsoft afferma esplicitamente nello stesso riferimento: «I SID rimangono sempre univoci. Le security authority non emettono mai due volte lo stesso SID e non riutilizzano mai i SID di account eliminati». Un SID locale orfano non può quindi essere riacquisito creando un nuovo account con lo stesso nome — il nuovo account riceve un nuovo RID. È un fatto genuinamente rassicurante, ed è il motivo per cui questo caso non è un'emergenza di massimo livello.

Il caso cross-domain non gode di questa garanzia, perché il principal potrebbe semplicemente esistere in un punto che non puoi vedere. Una concessione cross-domain legittima si materializza normalmente nella tua directory come oggetto Foreign-Security-Principal — «il Security Principal proveniente da una fonte esterna». Se non esiste un foreignSecurityPrincipal corrispondente, ti trovi di fronte o a una concessione intenzionale il cui oggetto complementare non è mai stato creato, oppure a un residuo di un trust che nel frattempo è stato rimosso o riconfigurato.

I diritti che rendono pericoloso un trustee non risolvibile

Non tutte le ACE con un trustee interrotto sono rilevanti. Quelle che contano portano diritti che permettono al detentore di impossessarsi dell'oggetto. Il riferimento Microsoft ADS_RIGHTS_ENUM fornisce i bit esatti:

C'è una trappola qui che rovina silenziosamente gli script di audit fatti in casa. I bit generici sopra sono i valori ADSI grezzi. L'enumerazione .NET ActiveDirectoryRights esposta da PowerShell usa invece i valori mappati del directory service: GenericAll è 983551 (0xF01FF), non 0x10000000. E 0xF01FF è un composito che include ReadProperty (16) e ListChildren (4).

Quindi uno script che scrive $ace.ActiveDirectoryRights -band 'GenericAll' e tratta un risultato diverso da zero come controllo completo segnalerà praticamente ogni ACE di lettura nella directory. Il test corretto è un test di uguaglianza contro la maschera completa, più controlli separati per i bit generici grezzi e per i diritti di scrittura standard:

$mask = [int]$ace.ActiveDirectoryRights
$isDangerous =
    (($mask -band 0x10000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_ALL   #>
    (($mask -band 0x40000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_WRITE #>
    (($mask -band 0x000F01FF) -eq 0x000F01FF) -or <# controllo completo (mappato) #>
    (($mask -band 0x00040000) -ne 0) -or          <# WRITE_DAC               #>
    (($mask -band 0x00080000) -ne 0)              <# WRITE_OWNER             #>

Microsoft stessa ne ha distribuita una

La prova più convincente che i riferimenti SID interrotti siano una condizione sistemica e non una curiosità viene dalla documentazione Microsoft stessa su ciò che adprep /domainprep fa alla tua directory.

Il riferimento Active Directory domain-wide schema updates elenca le operazioni eseguite quando viene preparato un domain controller Windows Server 2016. L'operazione 85 è descritta come una modifica del naming context di dominio «per permettere a domain\Key Admins e rootdomain\Enterprise Key Admins di modificare l'attributo msds-KeyCredentialLink». La colonna dei permessi registra poi cosa è realmente accaduto:

(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Key Admins)
(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins in root
 domain, but in nonroot domains resulted in a bogus domain-relative ACE with a
 nonresolvable -527 SID)

Rileggi quell'ultima clausola. Microsoft sta documentando che, in ogni dominio non radice di una foresta multi-dominio, questa operazione ha lasciato una ACE il cui trustee è un SID non risolvibile. Enterprise Key Admins è un gruppo a livello di foresta che risiede nella radice della foresta; l'operazione ha costruito il SID in modo relativo al dominio locale, producendo un riferimento -527 a un principal che quel dominio non possiede.

Altre due operazioni intervengono in seguito per ripulire — e non vengono distribuite insieme, il che determina se il tuo dominio ha ricevuto una sola correzione o entrambe. L'operazione 87 si trova nella stessa tabella di Windows Server 2016 (operazioni 82-88, al termine delle quali l'attributo revision su CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System viene impostato a 15); elimina «la ACE che concede il controllo completo (Full Control) al gruppo Enterprise Key Admins domain-relative errato» e ne aggiunge una corretta. L'operazione 89 è elencata in una tabella diversa — gli aggiornamenti domain-wide di Windows Server (Semi-Annual Channel), che portano lo stesso attributo revision a 16 — e va oltre, eliminando la voce ampia (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise Key Admins) e sostituendola con (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins) — controllo completo sull'intero naming context, ristretto ad accesso in scrittura su un solo attributo. Il valore di revision è il modo in cui puoi determinare quale delle due bonifiche il tuo dominio ha effettivamente ricevuto.

Queste stringhe SDDL si decodificano tramite il riferimento Microsoft ACE Strings: A è una ACE access-allowed, OA è specifica per oggetto, CI la contrassegna come ereditabile dai container, e RPWPCRLCLOCCDCRCWDWOSDDTSW concatena read property, write property, control access, list children, list object, create child, delete child, read control, write DAC, write owner, delete, delete tree e self-write. È il controllo completo sotto un altro nome — inclusi i due diritti che permettono al detentore di riscrivere la DACL e impossessarsi della proprietà.

🚨 Pericolo: se la tua foresta è stata preparata con i supporti originali di Windows Server 2016 e le successive operazioni di bonifica non sono mai state eseguite, una ACE -527 che concede diritti estesi sull'intero naming context di dominio potrebbe trovarsi ancora in un dominio figlio, puntando a nulla.

Perché i due casi hanno un peso diverso

Un SID locale orfano e un SID cross-domain appaiono identici in una DACL — un trustee non risolvibile — ma meritano priorità diverse.

SID locale orfano. Nessuno può esercitare questa concessione tramite un logon normale. Poiché AD non ricicla i RID, recuperare esattamente lo stesso SID richiederebbe iniettarlo nel sIDHistory di un account, il che presuppone già l'accesso privilegiato che un attaccante starebbe cercando di ottenere proprio tramite questa concessione. È un elemento di pulizia e un problema di audit trail, non un percorso attivo. Se lasciato, sopravviverà all'incidente che lo ha creato, allargando silenziosamente il raggio d'impatto di qualsiasi futura migrazione.

SID cross-domain. Questo caso è attivo se il dominio referenziato diventa mai raggiungibile. La guida Microsoft sul SID filtering descrive il meccanismo con chiarezza: «in alcune circostanze è possibile per attaccanti o amministratori infedeli che hanno compromesso un domain controller in un dominio trusted usare l'attributo SID history (sIDHistory) per associare SID a nuovi account utente, concedendosi diritti non autorizzati». La valutazione della postura degli account di Microsoft Defender for Identity ripropone la versione a livello di foresta: «Se hai un trust di foresta senza SID Filtering abilitato (chiamato anche Quarantine), è possibile iniettare un SID da un'altra foresta, che verrà aggiunto al token utente al momento dell'autenticazione e usato nelle valutazioni di accesso».

Mettendo insieme questi elementi, una ACE cross-domain obsoleta diventa una concessione pre-posizionata. Un attaccante che controlla — o in seguito ristabilisce — il dominio referenziato non ha alcun bisogno di modificare la tua DACL. Il permesso è già scritto. Gli basta un token che porti quel SID. È lo stesso ragionamento sui confini di trust trattato in attacchi alle trust di Active Directory e nel controllo del filtro SID delle trust e dell'autenticazione selettiva; la differenza è che qui la concessione sopravvive all'eliminazione del trust, perché eliminare un trust non ripulisce le ACL.

Altri due diritti nello stesso punto cieco

I riferimenti SID interrotti condividono un punto cieco con altri due pattern di permessi che le revisioni standard ignorano per un motivo diverso: non sono GenericAll, quindi gli audit basati su parole chiave non li vedono mai.

Self-membership sui gruppi. La validated write Self-Membership, GUID bf9679c0-0de6-11d0-a285-00aa003049e2, è documentata come «permesso di validated write che consente di aggiornare l'appartenenza di un gruppo in termini di aggiunta/rimozione del proprio account». Il suo nome visualizzato nell'editor ACL è Add/Remove self as member, e si applica solo alla classe Group. Concessa su un gruppo privilegiato, è un'escalation in un solo passaggio che non coinvolge mai una terza parte che scrive member — è il principal stesso ad aggiungersi. Il riferimento Microsoft Dsacls conferma l'ambito: il permesso WS è «significativo solo sugli oggetti gruppo e quando {ObjectType | Property} è 'member'». Questa è la famiglia di diritti che rende la nidificazione pericolosa dei gruppi peggiore di quanto sembri.

Enterprise Key Admins su msDS-KeyCredentialLink. Secondo Active Directory security groups, Enterprise Key Admins porta il RID noto 527, è un gruppo Global in CN=Users, non ha membri predefiniti ed è protetto da AdminSDHolder. L'attributo che governa, msDS-KeyCredentialLink (schemaIdGuid 5b47d60f-6090-40b2-9f37-2a4de88f3063), «contiene materiale chiave e informazioni sull'utilizzo» ed è stato «implementato per la prima volta su Windows Server 2016».

L'accesso in scrittura a quell'attributo è l'intero attacco Shadow Credentials. Nella ricerca originale di Elad Shamir Shadow Credentials: «se puoi scrivere sulla proprietà msDS-KeyCredentialLink di un utente, puoi ottenere un TGT per quell'utente» e «puoi recuperare l'hash NT di quell'utente». I prerequisiti sono un domain controller Windows Server 2016, un certificato Server Authentication su di esso, e il livello funzionale Windows Server 2016 — e la credenziale impiantata «persisterebbe anche se l'utente/computer cambiasse la propria password». Trattiamo la tecnica stessa in Shadow Credentials: abuso di msDS-KeyCredentialLink.

La domanda di audit è più circoscritta dell'attacco. Enterprise Key Admins viene distribuito vuoto. Ciò che stai verificando è se la ACE del gruppo sul naming context del tuo dominio sia la voce delimitata RPWP su 5b47d60f-… che l'operazione 89 installa, oppure la voce di controllo completo non delimitata lasciata dalla preparazione originale — e se il trustee si risolve effettivamente.

Rilevamento

Verificare questo aspetto richiede due passaggi: una scansione puntuale delle DACL esistenti, e un audit dei cambiamenti in modo che i nuovi riferimenti interrotti vengano intercettati non appena compaiono.

Scansionare le DACL esistenti alla ricerca di trustee pericolosi non risolvibili

Richiedi i SID grezzi anziché i nomi degli account. Chiedere a .NET oggetti NTAccount fin da subito genera un'eccezione esattamente sulle voci che stai cercando: SecurityIdentifier.Translate solleva IdentityNotMappedException quando «alcuni o tutti i riferimenti di identità non sono stati tradotti».

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$root      = (Get-ADRootDSE).defaultNamingContext

Get-ADObject -SearchBase $root -LDAPFilter '(objectClass=*)' -Properties nTSecurityDescriptor |
  ForEach-Object {
    $dn = $_.DistinguishedName
    $_.nTSecurityDescriptor.GetAccessRules(
        $true, $true, [System.Security.Principal.SecurityIdentifier]) |
      Where-Object { $_.AccessControlType -eq 'Allow' } |
      ForEach-Object {
        $mask = [int]$_.ActiveDirectoryRights
        $dangerous =
            (($mask -band 0x10000000) -ne 0) -or
            (($mask -band 0x40000000) -ne 0) -or
            (($mask -band 0x000F01FF) -eq 0x000F01FF) -or
            (($mask -band 0x00040000) -ne 0) -or
            (($mask -band 0x00080000) -ne 0)
        if (-not $dangerous) { return }

        $sid = $_.IdentityReference
        try {
            $null = $sid.Translate([System.Security.Principal.NTAccount])
            return
        } catch [System.Security.Principal.IdentityNotMappedException] { }

        $scope = if ($sid.Value.StartsWith("$domainSid-")) {
                     'Orphaned local SID'
                 } else {
                     'Cross-domain SID'
                 }

        [pscustomobject]@{
            ObjectDN = $dn
            Trustee  = $sid.Value
            Rights   = $_.ActiveDirectoryRights
            Scope    = $scope
        }
      }
  } | Sort-Object Scope, ObjectDN | Format-Table -AutoSize

Esegui prima questo script contro una singola OU. Una scansione completa del naming context legge ogni security descriptor del dominio e non è qualcosa da lanciare contro un DC di produzione durante l'orario lavorativo.

Verificare i due pattern specifici

Entrambe le query seguenti richiedono trustee di tipo SecurityIdentifier per lo stesso motivo della scansione precedente: la proprietà .Access esegue la traduzione in NTAccount e genera IdentityNotMappedException esattamente sulle ACE di cui parla questo articolo.

$root    = (Get-ADRootDSE).defaultNamingContext
$sidType = [System.Security.Principal.SecurityIdentifier]

<# Key Admins (-526) ed Enterprise Key Admins (-527) sul NC di dominio:
   delimitato, o controllo completo? Verifica sul RID, non sul nome — in un
   dominio non radice il trustee fasullo è esattamente quello che non si
   risolverà in "Key Admins", quindi un filtro sul nome manca silenziosamente
   il finding. #>
(Get-ADObject $root -Properties nTSecurityDescriptor).nTSecurityDescriptor.GetAccessRules(
    $true, $true, $sidType) |
  Where-Object { $_.IdentityReference.Value -match '-52[67]$' } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

<# Concessioni di self-membership sui gruppi: la validated write, oppure un DS_SELF non delimitato #>
$selfMembership = [guid]'bf9679c0-0de6-11d0-a285-00aa003049e2'
Get-ADGroup -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $g = $_
    $g.nTSecurityDescriptor.GetAccessRules($true, $true, $sidType) |
      Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
          $_.ObjectType -eq $selfMembership -or
          ($_.ObjectType -eq [guid]::Empty -and
           ([int]$_.ActiveDirectoryRights -band 0x8) -ne 0)
        )
      } |
      Select-Object @{n='Group';e={$g.DistinguishedName}},
                    IdentityReference, ActiveDirectoryRights
}

Un ObjectType pari a 5b47d60f-6090-40b2-9f37-2a4de88f3063 nella prima query è la forma delimitata e attesa. Un ObjectType vuoto con una maschera di controllo completo è la voce non delimitata che avrebbe dovuto essere sostituita — e un trustee -527 che non riesci ad associare a un gruppo Enterprise Key Admins realmente esistente è proprio il caso non risolvibile.

Intercettare le nuove occorrenze non appena compaiono

Il riferimento Microsoft sull'evento 5136 stabilisce i prerequisiti e le regole di lettura. L'evento appartiene alla sottocategoria Audit Directory Service Changes, e «per generare questo evento, l'oggetto modificato deve avere una voce appropriata nella SACL: l'auditing dell'azione 'Write' per attributi specifici» — abilitare la sola sottocategoria non basta, la SACL deve esistere sugli oggetti che ti interessano.

Aspettati coppie, non eventi singoli: «per un'operazione di modifica, in genere vedrai due eventi 5136 per una singola azione, con campi Operation Type diversi: 'Value Deleted' e poi 'Value Added'». La raccomandazione di Microsoft stessa è di generare un alert sull'evento Value Added e usare il Correlation ID per recuperare il valore precedente dal suo evento gemello.

Un dettaglio della stessa pagina funge anche da diagnostica per l'intero articolo: «Event Viewer tenta automaticamente di risolvere i SID e mostrare il nome dell'account. Se il SID non può essere risolto, vedrai i dati sorgente nell'evento». Un SID grezzo dove ti aspettavi un nome è il segnale rivelatore — in un evento, e in un report ACL.

Rimedio

1. Verifica che la bonifica di adprep sia stata eseguita. In ogni dominio non radice, ispeziona la DACL sul NC di dominio alla ricerca di ACE il cui trustee termina in -527. Se trovi una voce di controllo completo — specialmente una che non si risolve — ti trovi nello stato precedente alle operazioni 87/89. L'attributo revision su CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System ti dice quanto è avanzata la preparazione: 15 significa che le operazioni 82-88 sono state completate, 16 significa che anche l'operazione 89 lo è stata.

2. Classifica prima di eliminare. Per ogni trustee non risolvibile, confronta il prefisso di dominio con il SID del tuo dominio e con i SID di ogni dominio con cui hai un trust. Un SID cross-domain che corrisponde a un partner di trust attuale è probabilmente una concessione intenzionale a cui manca l'oggetto foreignSecurityPrincipal, ed eliminarlo romperà qualcosa. Uno che non corrisponde a nessun trust attuale è un riferimento obsoleto.

3. Rimuovi per SID, non per nome. È qui che gli strumenti ti remano contro. Il riferimento Microsoft Dsacls documenta /R come un parametro che accetta un trustee specificato «come User@Domain oppure come Domain\User» — una forma nominale che per definizione non esiste per un SID che non si risolve. Usa PowerShell e passa direttamente all'API un SecurityIdentifier:

$dn  = 'DC=child,DC=corp,DC=local'
$sid = [System.Security.Principal.SecurityIdentifier]'S-1-5-21-1004336348-1177238915-682003330-527'

$acl = Get-Acl -Path "AD:\$dn"
$acl.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) |
  Where-Object { $_.IdentityReference -eq $sid } |
  ForEach-Object { $null = $acl.RemoveAccessRuleSpecific($_) }

Set-Acl -Path "AD:\$dn" -AclObject $acl

Nota il $false per le regole ereditate: una ACE ereditata non può essere rimossa sul figlio, ma solo sull'oggetto che la definisce. Correggi il genitore e lascia che l'ereditarietà si propaghi.

4. Ripristina l'ambito previsto, non limitarti a eliminare. Dove la voce era Enterprise Key Admins sul NC di dominio, lo stato target è documentato: una ACE a livello di oggetto che concede RPWP delimitato a 5b47d60f-6090-40b2-9f37-2a4de88f3063, ereditabile dai container. Eliminare senza sostituire rimuove un permesso che il provisioning di Windows Hello for Business si aspetta di trovare.

5. Mantieni attivo il SID filtering — e non confonderlo con il quarantining. Una ACE cross-domain è sfruttabile solo se un SID esterno può raggiungere il tuo token di accesso, ed è il SID filtering a impedirlo. Attraverso un trust di foresta, il filtraggio è strutturale, non opzionale: MS-PAC specifica che un trust cross-forest «non permette ai SID locali alla propria foresta di attraversare un trust cross-forest», e che i SID ForestSpecific vengono «filtrati per i confini di trust QuarantinedWithinForest, CrossForest, External e QuarantinedExternal». Defender for Identity, citato sopra, tratta l'assenza di quel filtraggio come il finding. Il SID filter quarantining è una modalità separata e più restrittiva, e gli avvertimenti di Microsoft si applicano solo a essa: non applicare il quarantining «ai trust all'interno di una foresta che non utilizza il livello funzionale di foresta Windows Server 2003, perché farlo rimuove i SID richiesti per la replica di Active Directory», e «non dovrebbe essere applicato ai trust di foresta». Leggi questo come un'istruzione relativa al flag di quarantine — mai come un'autorizzazione a disattivare il SID filtering.

6. Applica una SACL agli oggetti che ti interessano. L'evento 5136 ne ha bisogno. Come minimo: l'oggetto NC di dominio, CN=AdminSDHolder,CN=System, CN=Keys, e ogni gruppo e OU di Tier 0. Sottoporre ad audit le scritture su nTSecurityDescriptor e msDS-KeyCredentialLink trasforma la prossima occorrenza in un alert invece che in un finding scoperto un anno dopo. L'articolo AdminSDHolder SDProp backdoor spiega perché quel container in particolare merita una sorveglianza permanente.

7. Integralo nella revisione ricorrente. I trustee orfani si accumulano da operazioni ordinarie — account di servizio dismessi, acquisizioni chiuse, trust ritirati. Tratta la scansione come parte dell'audit di sicurezza di Active Directory permanente, non come un progetto di remediation una tantum.

Come EtcSec rileva questo problema

EtcSec suddivide il problema dei riferimenti interrotti in due controlli, proprio perché i due casi comportano rischi diversi. ORPHANED_SID_DANGEROUS_ACE segnala le ACE di concessione che trasmettono GenericAll, controllo completo, WriteDACL, WriteOwner o GenericWrite a un trustee il cui prefisso di dominio corrisponde al dominio sottoposto ad audit ma che non si risolve in alcun principal attivo — il probabile caso dell'account eliminato, con rating High. CROSS_DOMAIN_SID_DANGEROUS_ACE segnala gli stessi diritti detenuti da un trustee proveniente da un dominio completamente diverso, con rating Critical, perché quel riferimento diventa sfruttabile nel momento in cui il dominio referenziato torna raggiungibile. Entrambi escludono deliberatamente i trustee amministrativi predefiniti e le ACE di tipo deny, in modo che l'output rappresenti l'esposizione e non la normale conformazione della directory.

Accanto a questi, ACL_SELF_MEMBERSHIP segnala la validated write Add/Remove-self-as-member sugli oggetti gruppo — limitata ai soli gruppi, ed esclude deliberatamente il controllo completo per non limitarsi a ripetere ciò che ACL_GENERICALL ha già trovato. ENTERPRISE_KEY_ADMINS_FULL_ACCESS segnala il trustee -527 che detiene controllo completo non delimitato oppure accesso in scrittura a msDS-KeyCredentialLink sugli oggetti di dominio, la condizione che le operazioni 87 e 89 esistono per correggere. ACL_WRITEDACL e ACL_WRITEOWNER coprono gli stessi due diritti quando il trustee si risolve effettivamente, e TRUST_SID_FILTERING_DISABLED copre il controllo lato trust che decide se un riferimento cross-domain possa mai raggiungere un token.

Insieme ai controlli più ampi di abuso di ACL e DCSync e all'audit dei permessi ACL, DPAPI, tombstone e schema, questi controlli colmano il divario tra «chi ha diritti pericolosi» e «quali diritti pericolosi sono detenuti da principal che nessuno riesce a identificare».