Superficie di Attacco degli Oggetti Computer in Active Directory: Il Rischio di Identità Macchina che Nessuno Controlla

La superficie di attacco degli oggetti computer in Active Directory è il termine collettivo per i rischi di delega, diritti di replica e appartenenza a gruppi che gli account macchina portano abitualmente — account che Active Directory crea automaticamente per ogni macchina unita al dominio, e che raramente audita come audita gli account utente. A differenza degli account utente, gli account macchina raramente ricevono attenzione individuale: nessuno rivede le loro impostazioni di delega, le loro appartenenze ai gruppi, o il loro livello di patch come farebbe con un utente privilegiato. È esattamente questo punto cieco su cui fanno leva diverse tecniche di attacco ben consolidate.

Questo articolo tratta specificamente la superficie di attacco degli oggetti computer — a differenza di Attacchi Delega Kerberos: Non Vincolata a RBCD, che spiega i meccanismi di delega in sé, e di Abuso ACL e DCSync: Percorsi verso Domain Admin, che copre l'escalation basata su ACL in generale. Qui il focus è più ristretto: quali oggetti computer nel tuo dominio portano diritti pericolosi, e perché è così facile non accorgersene.

Cos'è la superficie di attacco degli oggetti computer in Active Directory?

Ogni macchina Windows unita al dominio ottiene un account computer in Active Directory — un principal di sicurezza a pieno titolo, con il proprio SID, le proprie credenziali Kerberos (ruotate automaticamente, in genere ogni 30 giorni), e la capacità di avere appartenenze a gruppi e diritti di delega esattamente come un account utente. È proprio questo il punto: i servizi eseguiti come SYSTEM su una macchina unita al dominio si autenticano verso il resto del dominio come quell'account computer.

Il rischio deriva direttamente da questo design. A un account computer possono essere concessi — deliberatamente o per deriva — le stesse categorie di diritti pericolosi di un account utente: una delega che gli permette di impersonare altri utenti, diritti di replica che abilitano DCSync, o l'appartenenza a un gruppo privilegiato. La differenza sta nella visibilità: i team di sicurezza controllano regolarmente quali utenti sono Domain Admins, ma raramente si chiedono quali computer possano comportarsi come tali.

Perché gli oggetti computer sfuggono ai controlli

I flussi di provisioning creano oggetti computer automaticamente, spesso tramite imaging, enrollment Autopilot, o deployment SCCM/Intune — senza alcuna revisione umana dei diritti dell'oggetto risultante al momento della creazione. Percorsi di attacco come quelli trattati in Percorsi di Attacco AD: Catene di Configurazioni Errate concatenano esattamente questo tipo di diritto non revisionato con altre configurazioni errate per raggiungere Domain Admin; gli oggetti computer sono un anello sproporzionatamente frequente in questa catena, proprio perché raramente sono oggetto di un ciclo di revisione dedicato come lo sono gli account utente privilegiati.

Delega non vincolata su un oggetto computer

Quando un account computer è configurato per la delega non vincolata (il flag UserAccountControl TRUSTED_FOR_DELEGATION), qualsiasi utente che si autentica a un servizio su quella macchina ha il proprio Ticket Granting Ticket (TGT) completo — non solo un ticket di servizio — memorizzato nella cache della memoria di quella macchina. Secondo l'analisi ampiamente citata del ricercatore di sicurezza Sean Metcalf su questo rischio, ciò significa che un singolo host compromesso con delega non vincolata può accumulare i TGT di tutti gli utenti che vi si autenticano, inclusi i domain controller stessi quando vengono indotti a connettersi.

Perché è ancora presente

La delega non vincolata era il modello di delega originale di Windows 2000 ed è stata superata dalla delega vincolata e da RBCD per i casi d'uso legittimi; le stesse linee guida Microsoft ne sconsigliano l'uso. Il suo rischio principale oggi è di natura storica: server configurati così anni fa — spesso per server di stampa, deployment web precoci, o strumenti amministrativi ad hoc — e mai più rivisti una volta dimenticata la giustificazione originale.

Abuso della delega vincolata basata sulle risorse (RBCD)

La delega vincolata basata sulle risorse (RBCD) funziona diversamente dai modelli di delega più vecchi: invece di essere configurata sull'account che ha bisogno di delegare, viene configurata sulla risorsa di destinazione stessa, tramite l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity. Chiunque sia elencato in tale attributo può impersonare utenti arbitrari verso quella specifica risorsa.

L'implicazione di sicurezza è stata dettagliata nella ricerca di Elad Shamir del 2019, «Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory». La conclusione chiave: qualsiasi principal con accesso in scrittura all'attributo msDS-AllowedToActOnBehalfOfOtherIdentity di un oggetto computer può configurare RBCD per esso — senza bisogno dei privilegi di livello domain admin richiesti dai modelli di delega più vecchi. Questo include un principal con solo i diritti GenericAll, GenericWrite, o WriteDacl/WriteProperty sull'oggetto computer di destinazione. La ricerca di Shamir ha anche dimostrato che S4U2Self funziona su qualsiasi account con un SPN, indipendentemente dalla sua impostazione TrustedToAuthForDelegation, e che la risposta di Microsoft all'epoca fu che questo "non era un problema che sarebbe stato risolto tramite un aggiornamento di sicurezza" — il potenziale di abuso di RBCD è una conseguenza del suo design, non un bug correggibile.

Perché RBCD è un problema di ACL, non un problema di delega

Questo rende l'abuso di RBCD fondamentalmente un problema di ACL sugli oggetti computer, non un problema di configurazione della delega. Un account computer con una concessione ACL apparentemente a basso rischio, ereditata da un progetto passato o dal comportamento predefinito di un installer, può diventare una primitiva di impersonazione completa. Rivedere solo il valore di msDS-AllowedToActOnBehalfOfOtherIdentity in sé non intercetta l'esposizione — il vero punto di controllo è chi è autorizzato a scriverci.

Diritti DCSync detenuti da un account macchina

DCSync abusa dei diritti estesi DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, normalmente riservati ai domain controller, per estrarre gli hash delle password di qualsiasi account tramite il protocollo di replica della directory. Gli account computer dei domain controller detengono questi diritti in modo legittimo. Il rischio trattato qui è diverso: un account computer non-DC a cui sono stati concessi diritti che abilitano DCSync, deliberatamente o per errore (ad esempio tramite un template ACL troppo permissivo applicato alla radice del dominio, o diritti di replica concessi a un account di servizio di backup/monitoraggio che si trova a essere legato a una macchina).

La documentazione BloodHound di SpecterOps descrive l'edge DCSync come la combinazione di questi due diritti su qualsiasi principal — utente, gruppo, o computer — e nota che può emergere anche indirettamente tramite configurazioni errate della delega vincolata, senza che l'oggetto detenga mai esplicitamente i diritti di replica.

Computer in gruppi privilegiati

Un account computer aggiunto a un gruppo privilegiato (Domain Admins, Enterprise Admins, o un gruppo Tier 0 personalizzato) concede diritti equivalenti a Domain Admin a qualsiasi cosa venga eseguita come SYSTEM su quella macchina — il che, in pratica, significa chiunque riesca a ottenere esecuzione di codice su di essa. Questo è un profilo di esposizione diverso da quello di un account utente privilegiato: una workstation o un application server è generalmente più facile da compromettere di un endpoint amministrativo irrobustito, e il suo contesto SYSTEM è accessibile a molti più percorsi di codice (attività pianificate, servizi, account admin locali) rispetto a una singola sessione utente interattiva.

Questo è lo stesso problema strutturale trattato in Gruppi AD nidificati: Percorsi nascosti verso DA — un'appartenenza a un gruppo che appare irrilevante se isolata diventa pericolosa non appena si ricostruisce chi controlla effettivamente la macchina che la detiene.

Sistemi operativi obsoleti ancora presenti nel dominio

Gli oggetti computer che eseguono versioni di Windows oltre il loro ciclo di supporto — Windows XP, Windows Server 2003, o precedenti — non ricevono più aggiornamenti di sicurezza da Microsoft, incluse quelle per vulnerabilità attivamente sfruttate. Un domain controller o un server membro con un OS obsoleto è un punto debole permanente e non correggibile, e poiché questi sistemi vengono spesso mantenuti online per un'applicazione legacy specifica, tendono a essere esclusi dai processi ordinari di gestione delle patch e delle vulnerabilità invece di essere segnalati come l'esposizione ad altissima priorità che rappresentano realmente.

Questi sistemi si sovrappongono spesso allo schema descritto in Account Obsoleti e Sovraprivilegiati in AD: entrambi sono esposizioni che persistono proprio perché nessuno si assume la decisione di rimuoverle.

Rilevamento

Rimedio

1. Contrassegnare gli account sensibili come non delegabili

Attiva il flag "L'account è sensibile e non può essere delegato" sugli account ad alto valore, così che non possano essere catturati nemmeno da un host compromesso con delega non vincolata.

2. Rimuovere la delega non vincolata ovunque possibile

Migra i casi d'uso legittimi verso la delega vincolata o RBCD, che limitano l'impersonazione a servizi di destinazione specifici.

3. Auditare ogni configurazione RBCD — e le ACL che ne permettono l'impostazione

Rivedi msDS-AllowedToActOnBehalfOfOtherIdentity su tutti gli oggetti computer, e — soprattutto — rivedi chi detiene i diritti GenericAll/GenericWrite/WriteDacl che permetterebbero loro di configurarla in primo luogo.

4. Rimuovere i diritti che abilitano DCSync dai principal non-DC

Audita le concessioni DS-Replication-Get-Changes / DS-Replication-Get-Changes-All alla radice del dominio e su ogni OU delegata.

5. Rimuovere gli account computer dai gruppi privilegiati

A meno che non esista una ragione specifica, documentata e rivista per quell'appartenenza, tratta ogni occorrenza come un rilievo da correggere, non come una configurazione da tollerare indefinitamente.

6. Dismettere o isolare i sistemi con OS obsoleto

Quando la dismissione non è immediatamente possibile, isola il sistema sulla rete e rimuovi qualsiasi diritto privilegiato o appartenenza a gruppo che detiene.

# Elenca gli oggetti computer configurati per la delega non vincolata
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem

# Elenca gli oggetti computer con una configurazione RBCD impostata
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }

Come EtcSec rileva questo

La categoria Computers di EtcSec copre direttamente questa superficie di attacco: COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS, e COMPUTER_IN_ADMIN_GROUP segnalano i rischi di delega, diritti di replica e appartenenza a gruppi descritti sopra, mentre COMPUTER_OS_OBSOLETE_XP e COMPUTER_OS_OBSOLETE_2003 segnalano i sistemi operativi fuori supporto ancora presenti nel dominio.

Riferimenti principali

• Elad Shamir: Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
• ADSecurity.org (Sean Metcalf): Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
• SpecterOps BloodHound Documentation: DCSync edge
• SpecterOps BloodHound Documentation: CoerceToTGT edge
• hackndo: Resource-Based Constrained Delegation — Risks
• Microsoft Learn: Making the second hop in PowerShell Remoting (contesto sulla delega)