ACL degli oggetti computer Active Directory: revisione DACL

Che cos’è l’abuso delle ACL degli oggetti computer in Active Directory?

Le revisioni dell’abuso delle ACL degli oggetti computer in Active Directory verificano chi può modificare l’oggetto di directory di un’identità macchina. GenericAll, WriteDACL e WriteOwner possono aprire percorsi verso la delega vincolata basata sulle risorse (RBCD), credenziali a chiave non autorizzate o una reimpostazione della password della macchina. Individuare una concessione pericolosa dimostra un’esposizione; provare il suo sfruttamento richiede evidenze di modifiche e autenticazione.

L’introduzione alla superficie di attacco degli oggetti computer spiega già il percorso ACL verso RBCD, insieme a delega, diritti di replica e appartenenza a gruppi privilegiati. Questa guida porta tali basi in una revisione operativa: ispezionare la DACL e il proprietario, distinguere tre percorsi di abuso, raccogliere evidenze delle modifiche alla directory e correggere sia il percorso di autorizzazioni sia qualsiasi configurazione non autorizzata.

La revisione riguarda i diritti su un oggetto computer. Un account macchina che detiene privilegi altrove rappresenta una relazione diversa. Registra DN e GUID dell’oggetto controllato, il principale che riceve la concessione, il suo ambito e la finalità amministrativa prevista prima di decidere cosa rimuovere.

Come funziona: esaminare la DACL e il proprietario

Una lista di controllo degli accessi discrezionale (DACL) contiene voci di controllo degli accessi (ACE). Ogni voce identifica un principale e dei diritti; le voci specifiche dell’oggetto possono limitare la proprietà, il diritto esteso o la classe di oggetto che eredita. Leggere solo il nome di un’autorizzazione visualizzato non permette di coglierne l’ambito. L’enumerazione dei diritti di accesso AD di Microsoft definisce questi campi e i diritti WriteDACL e WriteOwner.

GenericAll non è semplicemente un bit grezzo da cercare. La mappatura dei diritti di accesso MS-ADTS converte i diritti generici in diritti specifici quando viene memorizzato un descrittore di sicurezza. Un audit che cerca soltanto 0x10000000 può non rilevare il controllo completo risultante dalla mappatura. Interpreta i diritti risultanti insieme al tipo di ACE, all’ambito delle proprietà e all’ereditarietà.

La proprietà richiede un controllo dedicato. Microsoft documenta il blocco dei diritti impliciti del proprietario sugli oggetti computer, con condizioni relative al sistema operativo e a BlockOwnerImplicitRights. Non presumere che diventare proprietario fornisca sempre un percorso di scrittura senza restrizioni sulla DACL. Verifica i diritti effettivi sulla configurazione reale del DC. Allo stesso modo, rimuovere un’ACE evidente di controllo completo non dimostra che la situazione sia risolta se rimangono un proprietario inatteso o un’altra concessione applicabile.

Perché gli oggetti computer richiedono una revisione dedicata delle ACL

Un inventario della delega indica quali macchine accettano attualmente identità delegate. Una revisione delle ACL chiede chi potrebbe cambiare questa risposta domani. Un attributo RBCD vuoto, quindi, non chiude un rilievo relativo a un principale che può scriverlo. La stessa distinzione vale per le credenziali a chiave: censisci i valori memorizzati e la possibilità di aggiungerne.

Parti dal contesto aziendale invece di vietare qualsiasi amministrazione. Un servizio di distribuzione può aver bisogno di diritti specifici di provisioning; questo non dimostra la necessità di un controllo completo permanente su ogni oggetto server. Chiedi al responsabile di identificare l’operazione, gli oggetti interessati, il principale approvato e la data di scadenza o revisione. Confronta tale requisito con l’ACE effettiva.

Le autorizzazioni dirette e quelle ereditate richiedono correzioni diverse. Se una concessione indesiderata ha origine in un’OU padre, modificare un computer lascia esposti gli altri destinatari. Individua l’origine dell’ereditarietà e ispeziona l’ambito per classe di oggetto prima di modificarla. Coinvolgi i responsabili amministrativi dell’OU e dei suoi carichi di lavoro affinché la delega sostitutiva consenta l’attività legittima.

La catena di attacco: tre percorsi dal controllo dell’oggetto

1. Configurazione RBCD

Un attaccante con accesso effettivo in scrittura a msDS-AllowedToActOnBehalfOfOtherIdentity può tentare di inserire un’identità di servizio che controlla nella configurazione di delega della risorsa. WriteDACL può essere una fase precedente che concede l’autorizzazione di scrittura necessaria. Il riferimento dello schema Microsoft descrive questo attributo come il controllo di accesso per agire per conto di altre identità presso i servizi eseguiti con l’account.

La panoramica Microsoft della delega vincolata spiega l’autorizzazione lato risorsa e lo scambio di ticket di servizio S4U2Proxy. La conseguenza è l’accesso tramite servizi idonei sulla risorsa di destinazione, subordinato all’ambiente e all’autorizzazione del servizio. Non garantisce automaticamente privilegi di amministratore locale o Domain Admin. Esamina i servizi di destinazione e i privilegi dell’identità impersonata per valutare l’impatto.

2. Credenziali ombra

Una chiave pubblica non autorizzata in msDS-KeyCredentialLink può creare un percorso separato di autenticazione basata su chiavi quando l’ambiente supporta il flusso di attendibilità delle chiavi pertinente e l’attaccante possiede la relativa chiave privata. MS-PKCA Key Trust richiede che le implementazioni basate su AD confermino la stessa chiave pubblica nell’attributo dell’account.

Distingui l’accesso ampio in scrittura agli attributi dalle scritture convalidate. Queste ultime impongono controlli aggiuntivi oltre allo schema dell’attributo. La specifica delle scritture convalidate per i computer richiede SELF, il diritto di scrittura convalidata pertinente e vincoli specifici sul blob per aggiungere un valore, inclusa l’assenza di un valore esistente. Queste condizioni non significano che qualsiasi terza parte con una scrittura convalidata possa installare una chiave.

L’autenticazione con chiave pubblica dei dispositivi aggiunti al dominio spiega anche il provisioning legittimo delle chiavi dei computer. Un attributo valorizzato è un dato per il triage, non un verdetto di compromissione. La guida alle credenziali ombra approfondisce questa distinzione e spiega perché una bonifica limitata alla password può lasciare attivo un percorso a chiave non autorizzato.

3. Reimpostazione della password della macchina

Il controllo completo può includere il diritto esteso Reset Password. La voce di schema Reset Password di Microsoft elenca esplicitamente Computer tra le classi applicabili. Una reimpostazione non autorizzata può dare a un attaccante il controllo della credenziale basata sulla password dell’account, con un impatto che dipende dai privilegi dell’account e dai percorsi di autenticazione disponibili.

Può anche interrompere la relazione di attendibilità della macchina. La guida Microsoft alla risoluzione dei problemi del canale sicuro descrive le discrepanze delle password tra dispositivo e AD. Tratta una reimpostazione inspiegata come un incidente di identità e un problema di disponibilità. Coordina il ripristino con il responsabile del sistema; una modifica unilaterale della password lato directory non è un esperimento diagnostico sicuro.

Enumerazione: un comando di lettura, poi revisione dei diritti effettivi

Su un sistema Windows amministrativo con dsacls disponibile, apri un prompt dei comandi con privilegi elevati o una sessione PowerShell e sostituisci il DN verificato del computer in questo singolo comando di lettura:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

Il riferimento dsacls di Microsoft documenta la visualizzazione delle ACL e l’opzione /A per le informazioni sul proprietario e sull’audit. Usa un account autorizzato a leggere DACL, proprietario e informazioni di audit; l’accesso ordinario READ_CONTROL esclude la SACL. Questo esempio non è stato eseguito in un ambiente AD.

Risolvi ogni principale inatteso in un’identità attuale. Registra le concessioni ereditate rispetto a quelle esplicite, i gruppi applicabili, l’ambito delle proprietà e il proprietario. Conferma le autorizzazioni effettive con gli strumenti di sicurezza della directory invece di trattare ogni voce di autorizzazione come un attacco indipendente e immediatamente utilizzabile. Indaga sulle identità non risolte e spiega le eccezioni amministrative approvate nel verbale di revisione.

Dai priorità ai server sensibili e alle OU che delegano il controllo su di essi, poi estendi la revisione a tutti gli oggetti computer. Salva lo stato precedente per poter valutare una modifica successiva sullo stesso oggetto e con lo stesso ambito di autorizzazioni.

Rilevamento: Event ID 5136 e KQL

Il riferimento Microsoft dell’Event ID 5136 conferma l’audit delle modifiche agli oggetti di directory. Abilita l’audit degli esiti positivi di Audit Directory Service Changes sui DC e le voci SACL appropriate di audit delle scritture sugli oggetti o attributi monitorati. Microsoft segnala che le impostazioni dello schema possono sopprimere l’audit per alcuni oggetti e proprietà: valida quindi la copertura reale. Conserva i campi di correlazione relativi ad attore, oggetto, attributo e operazione. L’eliminazione e l’aggiunta di valori possono far parte di una sola modifica; non contarle come incidenti separati.

Il KQL seguente è una query iniziale non eseguita per un’area di lavoro che riceve gli eventi Security dei DC in WindowsEvent. Presuppone proprietà denominate all’interno di EventData. Lo schema della tabella WindowsEvent di Microsoft definisce questo campo come dinamico e indica che gli errori di analisi popolano invece RawEventData. Ispeziona record rappresentativi prima di affidarti a questa mappatura.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Controlla separatamente i record 5136 con EventData vuoto o strutturato diversamente; altrimenti le lacune di analisi diventano invisibili. Adatta la query se il connettore usa SecurityEvent o un’altra tabella. Valida la copertura SACL e la visibilità delle modifiche al descrittore di sicurezza con una modifica amministrativa controllata prima di dichiarare la copertura. La query trova modifiche candidate, non prove di abuso.

Per il percorso di reimpostazione, integra la revisione delle modifiche alla directory con l’Event ID 4742, sotto Audit Computer Account Management. Il campo Password Last Set può riflettere una reimpostazione manuale o la normale rotazione della password della macchina. Microsoft documenta anche modifiche alla DACL che producono campi vuoti degli attributi modificati. Un elenco di campi vuoto, quindi, non dimostra che non sia cambiato nulla di rilevante.

Esegui il triage confrontando le modifiche con quelle approvate per distribuzione, registrazione e delega. Conserva la configurazione precedente quando disponibile, identifica l’account che ha avviato l’operazione e controlla l’attività successiva della macchina interessata. Aumenta la priorità quando un attore non approvato modifica un server sensibile, un proprietario cambia in modo inatteso o una modifica delle autorizzazioni precede un’aggiunta di delega o chiave. L’assenza di dati di audit richiede un’indagine sulla raccolta; non dimostra l’assenza di sfruttamento.

Correzione (Remediation): rimuovere il percorso di autorizzazioni e recuperare l’identità

Passo 1: conservare le evidenze e limitare la delega

Acquisisci DACL, proprietario, origine dell’ereditarietà e valori degli attributi pertinenti prima di modificarli. Rimuovi le concessioni non autorizzate di controllo completo, scrittura della DACL e acquisizione della proprietà. Sostituisci l’accesso di provisioning necessario con diritti limitati all’operazione e alla classe di oggetto documentate. Correggi una concessione ereditata alla sua origine e verifica gli altri computer interessati.

Se è confermato che un principale specifico non deve mantenere alcuna ACE su questo oggetto, dsacls /R fornisce un’operazione di rimozione documentata:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R rimuove tutte le ACE per quel principale; non è una bonifica selettiva del controllo completo. Per un principale che conserva diritti legittimi, modifica invece la specifica ACE problematica. Conferma poi il proprietario e i diritti effettivi risultanti. Questo esempio basato sulla documentazione non è stato eseguito.

Passo 2: rimuovere deleghe e chiavi non autorizzate

Riconcilia i delegati RBCD con l’elenco approvato dal responsabile della risorsa. Set-ADComputer espone PrincipalsAllowedToDelegateToAccount; usa l’insieme previsto e verificato, preservando le dipendenze applicative legittime. Rimuovere un delegato non autorizzato senza correggere l’autorizzazione di chi scrive lascia la configurazione esposta alla ricreazione.

Per una chiave confermata come non autorizzata, lo stesso cmdlet consente di rimuovere un valore esatto di attributo LDAP:

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue deve contenere l’esatto valore conservato e revisionato. Si tratta di un esempio di sintassi basato sulla documentazione, non di un ripristino eseguito. Conserva le chiavi di dispositivo approvate, documenta come è stato validato ciascun valore rimanente e verifica l’autenticazione legittima dopo la bonifica.

Passo 3: ripristinare l’attendibilità e verificare la chiusura

Se le credenziali della macchina sono state compromesse, coordina il recupero delle credenziali con il responsabile del dispositivo e indaga sugli accessi successivi. Su un membro del dominio, il cmdlet Microsoft per il canale sicuro fornisce questo comando di verifica:

Test-ComputerSecureChannel -Verbose

Eseguilo localmente in PowerShell aperto con Esegui come amministratore sul membro del dominio interessato. Questo comando di verifica basato sulla documentazione non è stato eseguito. Microsoft avverte che produce errori falsi positivi sui controller di dominio; in quel caso segui le procedure specifiche per i DC. Un canale sicuro funzionante verifica quella relazione, non la rimozione di ogni valore di directory controllato da un attaccante.

Chiudi il rilievo solo dopo aver verificato autorizzazioni e proprietario risultanti, riconciliato delega e chiavi, controllato il funzionamento previsto del servizio e confermato che il monitoraggio riceve le modifiche attese. Assegna un responsabile e una data di revisione a ogni eccezione mantenuta.

Come EtcSec rileva questo problema

L’implementazione di etc-collector fornisce due viste del catalogo per questa revisione delle autorizzazioni degli oggetti computer:

• COMPUTER_ACL_GENERICALL ispeziona le ACE di concessione sugli oggetti computer cercando GenericAll grezzo o il controllo completo AD risultante dalla mappatura, escludendo i principali amministrativi predefiniti. Associa i DN dei computer quando l’inventario è disponibile e usa un’euristica di localizzazione meno precisa quando è assente.
• COMPUTER_ACL_ABUSE segnala i computer che presentano il flag DangerousACL. Il motore di audit deriva questo flag dalle concessioni consentite GenericAll, WriteDACL o WriteOwner sugli oggetti computer, escludendo l’account stesso e i principali privilegiati previsti.

Considerale un unico controllo editoriale con sovrapposizione: una vista specifica del controllo completo e una vista aggregata dei diritti pericolosi. I loro filtri sui principali differiscono, quindi non promettere insiemi di rilievi identici e non sommare i conteggi per ottenere un totale di esposizioni indipendenti. Entrambe segnalano un’esposizione della configurazione; nessuna dimostra che RBCD, una chiave malevola o una reimpostazione della password siano stati sfruttati con successo. Usa gli oggetti interessati per iniziare la revisione delle DACL e correlare con le evidenze delle modifiche.