Tim Beasley Consulente senior per la risposta agli incidenti

Bentornati al nostro approfondimento sui gruppi di Active Directory rischiosi che non “sembrano” tali. Come ho spiegato nella prima puntata, gli aggressori non hanno bisogno dei privilegi di amministratore di dominio per causare danni concreti, e non cercano sempre gruppi con privilegi così evidentemente elevati.

"Account Operators" è un gruppo di AD che molti sottovalutano proprio perché non contiene la parola "admins". Ed è proprio per questo che viene così spesso trascurato.

Un errore comune è ritenere che gli “Account Operator” non rappresentino un rischio serio, poiché i membri non dovrebbero modificare gruppi protetti come “Domain Admins”.

Questa ipotesi è , nel migliore dei casi, incompleta e, nel peggiore dei casi, pericolosa.
Inoltre, in determinate circostanze, è anche falsa.

Il problema principale non è che il gruppo “Account Operators” sia un gruppo amministrativo di “livello superiore” (anche se noi lo trattiamo come tale). Il vero problema è che esso conferisce un ampio controllo sulle identità all’interno del dominio — e in Active Directory, le identità equivalgono a privilegi.


Cosa possono fare effettivamente gli operatori di conto?

Per impostazione predefinita, i membri del gruppo "Account Operators" possono creare, modificare ed eliminare oggetti utente, gruppo e computer in gran parte del dominio. In molti ambienti, ciò include la possibilità di:

  • Reimposta le password
  • Attivare o disattivare gli account
  • Modifica dei nomi dei soggetti di servizio (SPN)
  • Gestisci l'appartenenza a gruppi non protetti
  • Crea nuovi account utente

Agli operatori di account è espressamente vietato modificare direttamente i gruppi protetti e gli account controllati da AdminSDHolder, inclusi Domain Admins, Enterprise Admins, Schema Admins e il gruppo Administrators predefinito sui controller di dominio.

Tuttavia, tali restrizioni non eliminano le vie di attacco che un autore di minacce esperto può sfruttare dopo aver compromesso un membro degli Account Operators.

Questo è il punto fondamentale che i responsabili della sicurezza devono comprendere appieno: “Account Operators” non è un innocuo ruolo amministrativo delegato.
Si tratta di un amplificatore di privilegi che si colloca direttamente al di sopra del piano identitario.


Perché il gruppo degli “Account Operators” diventa così pericoloso in così poco tempo?

Se un malintenzionato riesce a compromettere le credenziali di un operatore di account, non ha bisogno di aggiungersi al gruppo “Amministratori di dominio” per iniziare a ottenere risultati positivi.

Li ho visti creare utenti controllati dagli aggressori, reimpostare le password di account privilegiati non protetti, manipolare indirettamente l’appartenenza ai gruppi, aggiungere SPN per configurare attacchi di tipo “Kerberoasting” e abusare della creazione di oggetti computer per attacchi di delega, come la delega vincolata basata sulle risorse.

Questo è importante perché molti dei percorsi di attacco più realistici alle aziende non richiedono di prendere di mira innanzitutto i gruppi più evidenti, quelli che rappresentano il “fiore all’occhiello” dell’azienda. È sufficiente disporre delle identità giuste, dei gruppi delegati giusti e dei percorsi di autenticazione giusti per il tempo necessario a cambiare strategia.

In altre parole, gli “Account Operator” forniscono a un malintenzionato un accesso in scrittura distribuito all’interno dell’Identity Fabric. Spesso questo è più che sufficiente per passare da una situazione di “privilegi limitati” a una di “ti ho in pugno”.


Scenari realistici di abuso a seguito della compromissione da parte degli operatori di account

Una strategia ovvia è la creazione di account “backdoor”. Un aggressore può creare un nuovo utente e inserirlo in gruppi con privilegi o semi-privilegiati che è in grado di controllare, compresi gruppi con percorsi di escalation nascosti che spesso vengono monitorati in modo molto meno rigoroso rispetto agli amministratori di dominio. Inoltre, questo approccio gli consente di individuare le gerarchie all’interno dei gruppi con privilegi, permettendo un’ulteriore escalation e persistenza.

Un altro scenario comune è rappresentato dalle operazioni di reimpostazione delle password, sia mirate che in blocco. Gli operatori di account possono reimpostare le password della maggior parte degli utenti del dominio, inclusi gli account di servizio, le identità delle applicazioni e gli utenti amministrativi non protetti. Se questa funzionalità finisce nelle mani di un attore malintenzionato, ciò comporta un accesso operativo immediato e un potenziale disservizio aziendale.

Una terza possibilità è l'abuso degli SPN e il kerberoasting. Se un aggressore riesce a modificare gli attributi di un account e ad aggiungere SPN, può creare nuovi bersagli vulnerabili al kerberoasting o rendere vulnerabili gli account esistenti senza che l'“attacco” risulti evidente.

Un quarto metodo consiste nell’abusare di account non protetti ma comunque preziosi. Molte organizzazioni dispongono ancora di amministratori delegati, account di servizio legacy e gruppi annidati che non sono protetti da AdminSDHolder. Il ripristino delle password o la modifica degli attributi su tali oggetti può essere sufficiente per ottenere privilegi più elevati.

E poi c'è uso improprio di un account informatico. Poiché gli operatori di account possono spesso creare oggetti di sistema e controllarne la creazione, possono consentire attacchi che coinvolgono MachineAccountQuota e la delega con limitazioni basate sulle risorse. Ciò apre la strada all’usurpazione d’identità e all’escalation dei privilegi senza mai interagire direttamente con il gruppo “Domain Admins”.

Ci stiamo già divertendo?


La sfumatura di AdminSDHolder che i sostenitori non dovrebbero ignorare

È qui che la conversazione diventa ancora più imbarazzante.

In teoria, gli operatori di account non dovrebbero poter modificare gruppi protetti come “Domain Admins” o “Enterprise Admins”.

In pratica, tale protezione non viene applicata in modo continuo. È gestita dal processo Security Descriptor Propagator, comunemente denominato SDProp, che applica l'ACL AdminSDHolder agli oggetti protetti con cadenza periodica. Per impostazione predefinita, tale ciclo si ripete circa ogni 60 minuti.

L'intervallo predefinito di 60 minuti di SDProp è importante. Tra un'esecuzione e l'altra, gli “oggetti protetti” possono temporaneamente discostarsi dal descrittore di sicurezza previsto. Se le autorizzazioni hanno subito variazioni, se i diritti ereditati o delegati non sono stati ancora corretti completamente, oppure se un oggetto appena creato o modificato non è stato sottoposto a restamping, un aggressore potrebbe avere un'opportunità di breve durata per sfruttare tale lacuna prima che SDProp riapplichi l'ACL protetta.

Ciò significa che un aggressore potrebbe non aver bisogno di un’appartenenza persistente a un gruppo protetto. Potrebbe bastargli solo il tempo necessario, all’interno di quella finestra predefinita di 60 minuti, per aggiungere un soggetto controllato, avviare una sessione privilegiata, estrarre informazioni riservate, creare account backdoor o stabilire una persistenza altrove prima che SDProp rimuova le prove evidenti a livello di ACL o di appartenenza. Potrebbe persino avere il tempo di reimpostare un account amministratore appena creato.

60 minuti sono un tempo lungo per un autore di attacchi esperto.

Si tratta di un grave problema di individuazione per i responsabili della sicurezza, poiché comporta la possibilità che un account mantenga lo stato di privilegiato per un periodo molto breve, seguito da attività privilegiate da parte di un account che potrebbe non apparire più come privilegiato quando gli investigatori lo esamineranno in un secondo momento.

Il punto fondamentale da tenere presente è che la protezione di AdminSDHolder è “eventually consistent” (a coerenza differita), non in tempo reale, e che la pianificazione predefinita di SDProp, fissata a 60 minuti, rappresenta la falla che un aggressore cerca di sfruttare.


Cosa dovrebbero monitorare gli addetti alla sicurezza per individuare gli abusi da parte degli “Account Operator”?

Se si desidera individuare casi di abuso da parte degli operatori degli account, è opportuno iniziare dall’analisi delle attività relative al ciclo di vita delle identità. La creazione di nuovi account, l’attivazione degli account, le operazioni di reimpostazione della password e le modifiche agli account sono tutti segnali chiave quando vengono eseguiti da un membro di questo gruppo. Gli eventi rilevanti includono i codici 4720, 4722, 4723, 4724 e 4738.

Successivamente, monitorate attentamente le modifiche all’appartenenza ai gruppi, in particolare le aggiunte a gruppi delegati insoliti, gruppi annidati o gruppi che conferiscono privilegi e che vengono utilizzati raramente. In questo contesto sono rilevanti eventi quali 4728, 4732 e 4756; inoltre, in uno scenario con finestra temporale ridotta, è necessario correlare i modelli di aggiunta e rimozione rapida con gli eventi 4729, 4733 e 4757.

È inoltre opportuno monitorare le modifiche agli SPN e altre modifiche agli attributi delle directory. Evento 5136 è importante in caso di imprevisti servicePrincipalName modifiche, modifiche agli attributi relative alla delega, quali msDS-AllowedToActOnBehalfOfOtherIdentity, e altre modifiche sospette su oggetti appena creati o modificati di recente.

Infine, stabilisci un quadro di riferimento comportamentale.

  • Quanti utenti crea in genere un membro del team Account Operators in un giorno?
  • Quante operazioni di reimpostazione della password effettuano di solito?
  • Chi sono i destinatari tipici?

È proprio quando si verifica una deviazione da tale valore di riferimento che iniziano i rilevamenti ad alto livello di affidabilità.


Cosa fare al riguardo

La risposta migliore è semplice: svuotare il gruppo.

Se non sussiste alcun motivo operativo valido per utilizzare gli Account Operator (il che avviene quasi SEMPRE), rimuovi l'appartenenza e lascia il campo vuoto. Se hai comunque bisogno di un'amministrazione delegata, ricorri alla delega personalizzata sulle specifiche unità organizzative (OU) e sugli oggetti che richiedono effettivamente una gestione.

Se non è possibile eliminare immediatamente l'appartenenza al gruppo, consideratela come un dato molto più sensibile di quanto non facciano attualmente la maggior parte delle organizzazioni.

  • Applicare la suddivisione in livelli amministrativi
  • Impedire l'accesso interattivo ai controller di dominio e ai server critici
  • Negare l'accesso locale, ove possibile

Dovresti inoltre ridurre le possibilità di uso improprio degli oggetti informatici rafforzando MachineAccountQuota (preferibilmente a zero) ove opportuno e limitando chi può creare nuovi account utente.

Inoltre, monitorare in modo specifico le aree che potrebbero consentire un’escalation a breve termine o indiretta: modifiche ai gruppi con privilegi, modifiche alle deleghe, modifiche agli SPN e modifiche agli ACL su AdminSDHolder e sui gruppi protetti.


Rivalutare i rischi legati agli operatori di conto

Il gruppo "Account Operators" è pericoloso perché conferisce un ampio controllo sugli oggetti che definiscono l'accesso, l'affidabilità e l'autenticazione in Active Directory.

Se l’identità di un operatore di account viene compromessa, è possibile creare nuovi soggetti, reimpostare le password, manipolare i gruppi, configurare il “kerberoasting”, abusare della delega, garantire la persistenza e, nelle giuste condizioni, sfruttare il ritardo intrinseco nella protezione di AdminSDHolder.

Ecco perché i responsabili della sicurezza più esperti dovrebbero smettere di considerare gli “Account Operator” come un ruolo di supporto obsoleto e iniziare a trattarlo per quello che è realmente: un accesso con privilegi limitati ma con molteplici percorsi di escalation… ovvero il Livello 0.

L'identità è il perimetro… proteggila.

Alla prossima…Segui la discussione sugli Account Operator su LinkedIn.

E se desideri l'aiuto di esperti per individuare e colmare le lacune nella sicurezza di Active Directory, richiedi una Valutazione della sicurezza di Active Directory. Siamo qui per te.


Ulteriori letture