Spiegazione degli attacchi di sfruttamento gMSA e degli attacchi Golden gMSA

Cos'è un attacco gMSA?

Un attacco a un gruppo Managed Service Account è un'intrusione in cui gli aggressori compromettono o calcolano le credenziali gMSA per ottenere accesso non autorizzato ai servizi e aumentare i privilegi in un ambiente Active Directory.

I gMSA sono utilizzati per i servizi Windows, i pool di applicazioni IIS, i servizi SQL Server, le attività pianificate, i servizi di backup e altre identità di servizio automatizzate in cui un servizio necessita di una credenziale di dominio gestita automaticamente. L'abuso dei gMSA offre una vasta superficie di attacco perché ogni sistema o servizio autorizzato a recuperare o eseguire con un gMSA diventa un potenziale punto di ingresso per gli aggressori. Leggendo le password gMSA e sfruttando questi account, gli aggressori possono impersonare le identità di servizio, muoversi lateralmente all'interno del dominio e mantenere una presenza persistente difficile da rilevare e risolvere.

Gli aggressori utilizzano principalmente i seguenti metodi per lo sfruttamento di gMSA:

• Leggi msDS-ManagedPassword: Gli aggressori compromettono un host o un account con accesso SYSTEM/autorizzato e leggono l'attributo msDS-ManagedPassword per un gMSA da Active Directory. Questo attributo contiene le password correnti e precedenti per il gMSA, quindi leggendo i valori dell'attributo, gli aggressori leggono effettivamente le password gMSA.
• Golden gMSA (KDS root key abuse): Gli avversari ottengono gli attributi della chiave root KDS (Key Distribution Service) (memorizzati in CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=domain,DC=com) e li utilizzano per calcolare le password gMSA offline, senza contattare un controller di dominio. Forgiando credenziali valide, gli attaccanti possono autenticarsi come quegli account di servizio in qualsiasi momento.

Attacchi Golden gMSA

Ecco le caratteristiche principali di un attacco Golden gMSA:

• La compromissione iniziale richiede diritti di alto livello (ad esempio, Domain Admin o account SYSTEM su un domain controller) per leggere o esportare il materiale della chiave root KDS.
• Una volta ottenuti gli attributi della chiave root KDS, gli aggressori possono:
  • Calcola le password gMSA correnti e future senza contattare un domain controller, in modo da non generare log di autenticazione sui DC.
  • Crea credenziali per qualsiasi gMSA nel dominio.
  • Mantieni l'accesso persistente anche dopo che la compromissione iniziale è stata rilevata (la chiave root è valida per impostazione predefinita fino a 10 anni).
• Concettualmente, un attacco Golden gMSA è analogo a un attacco Golden Ticket, poiché entrambi comportano la creazione di credenziali contraffatte o derivate.

Utilizzi dello strumento

Gli strumenti e gli script seguenti facilitano lo sfruttamento di Golden gMSA:

• Le utility di credential-dumping sono utilizzate per estrarre credenziali o materiale di credenziali da un host in modo che un attaccante possa elevare i privilegi o muoversi lateralmente. Gli obiettivi includono la memoria dove risiedono i token di autenticazione/hash NTLM, le credenziali memorizzate nella cache e le copie di backup degli archivi delle credenziali.
• Le utility di enumerazione AD mappano gli oggetti, i permessi e le relazioni di Active Directory in modo che un attaccante possa trovare dove risiedono chiavi/oggetti sensibili (per gMSA: chiavi root KDS, oggetti msDS-ManagedPassword e associazioni di servizi). Esaminano l'appartenenza ai gruppi, le ACL e gli attributi.
• Le utility proof-of-concept e gli script personalizzati implementano una logica matematica/criptografica che deriva le password gMSA dalla chiave root KDS e dai metadati dell'oggetto.

Come funziona un attacco gMSA?

Un attacco di sfruttamento gMSA segue un percorso a tappe: l'attaccante inizia scoprendo dove vengono utilizzati i gMSA e alla fine riesce a muoversi lateralmente e ad aumentare i privilegi in modo persistente e furtivo. Ecco le fasi dell'attacco:

Scopri l'utilizzo di gMSA

Gli aggressori iniziano mappando dove sono distribuiti i gMSA nell'ambiente. Scansionano Active Directory e gli endpoint per identificare servizi, pool di applicazioni, attività pianificate e processi di database o backup che vengono eseguiti con identità gMSA. Con questa mappatura, sondano quegli host alla ricerca di vulnerabilità sfruttabili (come RCE del server web, difetti di servizio non patchati e configurazioni di servizio deboli) che possono essere abusate per ottenere l'esecuzione di codice o per elevare i privilegi a NT AUTHORITY\SYSTEM.

Accedi alle password gMSA

Su un host compromesso con privilegi SYSTEM o tramite un account con sufficienti permessi di Active Directory, l'attaccante utilizza strumenti o API (ad esempio, PowerShell con DSInternals o letture della directory) per recuperare l'attributo msDS-ManagedPassword. L'attaccante quindi decodifica il blob delle credenziali in testo semplice (o in un hash NTLM), spesso usando la funzione PowerShell ConvertFrom-ADManagedPasswordBlob. Con queste credenziali in testo semplice o derivate, l'attaccante può accedere come account di servizio, eseguire il servizio, accedere a qualsiasi risorsa raggiungibile e spostarsi su altri sistemi con poco sforzo.

Attacco Golden gMSA

In uno scenario Golden gMSA, un avversario estrae gli attributi della chiave root KDS (come msKds-RootKeyData, msKds-KDFParam e i parametri KDF correlati) che Active Directory utilizza per derivare le password gMSA. Usando strumenti come GoldenGMSA o script personalizzati, può calcolare offline le password gMSA attuali e future. In questo modo, può autenticarsi a qualsiasi servizio che si basi su quei gMSA.

Movimento laterale o escalation dei privilegi

Una volta che le credenziali gMSA (sia lette direttamente sia calcolate dalla chiave KDS) sono sotto il controllo dell’attaccante, queste possono essere utilizzate per:

• Autenticarsi su database, interfacce di gestione, condivisioni di file o altri servizi che accettano il gMSA.
• Passa ad altri host che si fidano dell'identità del servizio.
• Combina con tecniche Silver Ticket o Golden Ticket, o abuso di token per aumentare i privilegi.
• Esfiltrare dati sensibili.
• Distribuisci persistenza o crea nuovi account di servizio privilegiati.

I servizi che funzionano sotto gMSA operano solitamente con privilegi elevati e connettività estesa, offrendo agli aggressori una vasta superficie di attacco da sfruttare.

Diagramma del flusso di attacco

Ecco un diagramma di flusso che spiega la catena degli eventi in un attacco gMSA e un esempio di storia dal punto di vista di un'organizzazione per aiutarti a comprendere l'attacco.

Un attaccante compromette il server web rivolto ai clienti di un’organizzazione tramite un plugin vulnerabile, installa una web shell, eleva i privilegi a SYSTEM su quell’host ed estrae le credenziali di servizio. Utilizzando la chiave root KDS e i parametri KDF scaricati, calcola le password gMSA offline e si autentica ai servizi backend (database e condivisioni di file) senza connettersi al domain controller. In 48 ore, esfiltra record sensibili dei clienti.

Esempi di attacchi gMSA

Non ci sono rapporti pubblici o divulgazioni di violazioni che affermino che un attaccante abbia utilizzato un attacco gMSA o Golden gMSA in natura. Tuttavia, esistono ricerche approfondite, PoC, strumenti e linee guida dei fornitori che dimostrano che la tecnica è reale e pratica. Di seguito è riportato un riepilogo delle prove nel mondo reale.

Conseguenze degli attacchi gMSA

I team IT utilizzano gMSA per un accesso automatizzato e ad alto privilegio. Il loro furto può amplificare un incidente, consentendo movimenti laterali furtivi, accesso prolungato e ampia esposizione dei dati. Questo può comportare gravi conseguenze finanziarie, operative, reputazionali e legali.

Obiettivi comuni degli attacchi gMSA: chi è a rischio?

In generale, le grandi imprese, le agenzie governative e le istituzioni finanziarie che gestiscono ambienti complessi di Active Directory con molti gMSA per servizi (SQL, IIS, Exchange, backup) sono tra gli obiettivi più comuni degli attacchi gMSA. Dal punto di vista tecnico, i seguenti componenti di un'infrastruttura IT sono i più a rischio:

Valutazione del rischio

Per valutare il rischio di attacchi gMSA, dovresti considerare tre fattori chiave: il potenziale danno derivante da un attacco, la difficoltà di esecuzione dell’attacco e la probabilità che si verifichi. Insieme, evidenziano perché i gMSA richiedono una forte protezione e monitoraggio.

Come prevenire gli attacchi gMSA

Implementando controlli tecnici rigorosi e pratiche amministrative solide, le organizzazioni possono ridurre il rischio di un attacco di sfruttamento gMSA.

Misure tecniche

Le seguenti misure tecniche possono aiutare a prevenire gli attacchi gMSA e Golden gMSA:

• Configura le liste di controllo degli accessi di sistema (SACL) sulle chiavi radice KDS per registrare ogni tentativo di lettura dell'attributo msKds-RootKeyData. In questo modo, i team di sicurezza vengono avvisati se gli attaccanti cercano di accedere ai segreti utilizzati per derivare le password gMSA.
• Applica il principio del privilegio minimo alle appartenenze gMSA. Per fare ciò, limita quali account e gruppi sono elencati nell'attributo msDS-GroupMSAMembership di un gMSA. Solo i servizi che richiedono effettivamente il gMSA dovrebbero avere accesso. Rimuovere le appartenenze non necessarie aiuta a chiudere potenziali vie di abuso.
• Revisiona regolarmente chi ha il permesso di gestire e utilizzare gMSA. I team di sicurezza dovrebbero controllare le modifiche ai permessi e ai modelli di utilizzo per individuare attività sospette che potrebbero indicare accessi non autorizzati e tentativi di escalation dei privilegi.
• Riduci il valore dell'impostazione ManagedPasswordIntervalInDays in modo che le password gMSA vengano aggiornate più frequentemente. Questo limita la finestra di opportunità per gli aggressori di riutilizzare credenziali compromesse.

Best practice amministrative

Come parte delle migliori pratiche amministrative, le organizzazioni dovrebbero mantenere un controllo rigoroso sul ciclo di vita e sulla gestione delle chiavi di gMSA.

• Crea periodicamente nuove chiavi root KDS e riassegnale ai tuoi gMSA attivi. Questo impedisce che chiavi vecchie o potenzialmente compromesse vengano utilizzate per derivare password gMSA valide.
• Monitora l'Evento ID 4662, che registra i tentativi di accesso agli oggetti della directory. Monitorare questo evento specificamente per gli attributi gMSA può aiutare a rilevare accessi non autorizzati o query sospette.
• Disabilitare proattivamente le gMSA che non sono più in uso e rimuovere le autorizzazioni orfane dai vecchi servizi. Ciò riduce il numero di account disponibili per gli attaccanti, minimizzando la superficie di attacco complessiva.

Come Netwrix può aiutare

La suite Netwrix Identity Threat Detection & Response (ITDR) aiuta le organizzazioni a identificare attività sospette e a proteggere la loro infrastruttura di identity negli ambienti on-premises e ibridi. Offre capacità di visibilità, allerta, risposta e recupero rilevanti per la difesa dei gMSA.

Ecco alcune delle sue capacità principali e come si collegano alla prevenzione o alla mitigazione dei rischi legati a gMSA:

Rilevamento delle minacce

I prodotti Netwrix ITDR, come Threat Manager e Threat Prevention, possono individuare attività sospette relative all'infrastruttura di identity, come modifiche insolite o non autorizzate in Active Directory. Possono monitorare le modifiche e gli accessi a livello di oggetti e attributi in AD (come letture non autorizzate degli attributi msDS-ManagedPassword e msKds-RootKeyData) e possono segnalare modifiche di configurazione rischiose o cambiamenti nella membership di gruppi privilegiati.

Monitoraggio e allerta in tempo reale

Netwrix ITDR fornisce avvisi in tempo reale su eventi critici di Active Directory e modelli di accesso anomali. Questo include il monitoraggio degli account non controller di dominio che tentano di accedere ad attributi KDS sensibili, l'appartenenza a gruppi sensibili e le modifiche agli attributi privilegiati. Queste funzionalità di monitoraggio aiutano a rilevare l'uso improprio di gMSA.

Risposta rapida

Netwrix ITDR supporta azioni di risposta agli incidenti automatizzate o semi-automatizzate nel caso venga rilevata una compromissione, come la disabilitazione degli account, la generazione di avvisi, il ripristino di modifiche indesiderate e l’avvio di indagini forensi. In uno scenario di attacco gMSA, questo significa che puoi rispondere rapidamente quando viene rilevata un’attività sospetta, come disabilitare il gMSA o revocare le autorizzazioni.

Audit di sicurezza e reportistica

Netwrix Auditor fornisce dettagliati audit trail, valori “prima e dopo” per le modifiche AD, report di valutazione del rischio, dashboard e report di conformità. Questi sono utili per tracciare le modifiche ai permessi gMSA, l’utilizzo nel tempo e l’identificazione di configurazioni errate.

Strategie di rilevamento, mitigazione e risposta

Per difendersi dagli attacchi correlati a gMSA, le organizzazioni dovrebbero adottare un approccio proattivo che comprenda la rilevazione precoce, la mitigazione preventiva e una risposta efficace. Ecco alcuni passaggi pratici per rafforzare le tue difese contro le compromissioni della chiave root KDS e di gMSA.

Rilevamento

Per rilevare precocemente un attacco gMSA, i team dovrebbero seguire queste pratiche:

Monitora le letture non autorizzate di attributi critici come msDS-ManagedPassword e msKds-RootKeyData

Questi attributi sono direttamente collegati al recupero della password gMSA e alla generazione offline della password, e sono raramente accessibili al di fuori delle normali operazioni del controller di dominio. Query insolite contro di essi possono indicare tentativi di raccolta delle credenziali. Per rilevarlo, gli amministratori possono abilitare l'auditing del servizio directory in Active Directory e configurare l'Auditing Avanzato della Sicurezza per registrare l'accesso al servizio directory (ID evento 4662).

Verifica gli account non-DC che accedono ad attributi KDS sensibili

Solo i controller di dominio dovrebbero interagire con i dati della chiave root KDS. Monitorare l'accesso da account inaspettati può rivelare un uso improprio dei privilegi o tentativi di movimento laterale.

Combina il monitoraggio con l'analisi

Filtrando le letture sugli attributi sensibili e correlandole con il tipo di account (come gli account non-DC), i team di sicurezza possono rilevare query sospette. Ancora meglio, integrare questi log in una piattaforma SIEM per la correlazione tra eventi, il rilevamento di anomalie e gli avvisi in tempo reale.

Utilizzo normale di base di gMSA tra servizi e server

Questo consente il rilevamento di anomalie quando i gMSA vengono utilizzati al di fuori del loro ambito previsto (ad esempio, un gMSA SQL utilizzato su un server web).

Mitigazione

I team IT dovrebbero affrontare la mitigazione come uno sforzo coordinato e stratificato che non solo interrompe l'accesso attuale dell'attaccante, ma rafforza anche le difese per minimizzare le possibilità di compromissioni future. Di seguito sono discussi alcuni importanti passaggi di mitigazione.

Ricreare gMSA contro una nuova chiave root KDS quando si sospetta una compromissione

Generare una nuova chiave root impedisce a un attaccante di derivare password da artefatti precedentemente esposti, ripristinando la fiducia negli account gestiti.

Ruota le password gMSA eseguendo Test-ADServiceAccount

Forzare un aggiornamento della password garantisce che, anche se le credenziali vengono compromesse, gli aggressori perdano l'accesso ai segreti validi.

Applica la segmentazione e applica l'ambito

Implementa la segmentazione della rete e dei servizi per limitare dove possono essere utilizzati i gMSA. In questo modo, se un livello viene compromesso, gli aggressori non possono facilmente spostarsi in altre aree sensibili.

Testa regolarmente i tuoi playbook di rimedio

Esegui esercizi pratici e tecnici che simulano la rotazione della chiave KDS e il recupero gMSA per assicurarti che le tue procedure siano efficaci e funzionino sotto pressione.

Risposta

Quando si sospetta o si conferma un attacco gMSA, le organizzazioni devono agire con decisione per contenere la minaccia, limitare i danni e prevenire il ripetersi.

Mettere in quarantena i sistemi interessati

Isola gli host compromessi per impedire agli aggressori ulteriori movimenti laterali o l'uso continuato delle credenziali gMSA compromesse. Devi anche isolare i controller di dominio se viene rilevato un accesso sospetto a msKds-RootKeyData o ad altri attributi critici, assicurando che gli aggressori non possano persistere nei servizi di directory.

Disabilita gMSA compromessi

Disabilita immediatamente i gMSA compromessi per bloccare gli avversari dall’utilizzarli per l’autenticazione e attività dannose.

Ruota tutte le credenziali rilevanti e aggiorna i servizi interessati

Ruota tutte le credenziali rilevanti, inclusi gMSA, account di servizio e account amministrativi. Quindi aggiorna i servizi interessati per garantire una ri-autenticazione fluida con i gMSA appena ruotati.

Conservare gli artefatti forensi e avviare un'indagine forense

Un'indagine forense aiuta a determinare l'entità e la causa principale dell'incidente. Assicurati di acquisire i dati del domain controller e della Configuration NC, come i log e gli snapshot NTDS, prima di apportare modifiche di rimedio irreversibili. È importante bilanciare l'urgenza di fermare l'attacco con la necessità di conservare le prove per l'analisi. Successivo:

• Esamina i registri degli eventi, gli avvisi SACL e le anomalie correlate all'identità.
• Cattura dati volatili (come dump di memoria e log di autenticazione) dai sistemi interessati per l'analisi post-incidente.
• Fai attenzione a meccanismi di persistenza come attività pianificate, ACL modificate o account amministrativi ombra che potrebbero essere stati introdotti durante la compromissione.

Questi passaggi possono aiutare a identificare i meccanismi di attacco e a chiudere le falle di sicurezza.

Impatto specifico del settore

L'impatto degli attacchi gMSA non è lo stesso per tutti i settori. Comprendendo le conseguenze specifiche di ciascun settore, le organizzazioni possono dare priorità alle difese in base ai loro asset più preziosi.

Evoluzione degli attacchi e tendenze future

Man mano che le organizzazioni adottano i gMSA per migliorare la sicurezza e semplificare la gestione delle password, gli aggressori stanno affinando le loro tecniche per sfruttare questi account. Le seguenti tendenze evidenziano come gli avversari stiano sfruttando le vulnerabilità dei gMSA e verso dove si sta dirigendo il panorama delle minacce.

Statistiche chiave e infografiche

I gMSA sono progettati con solide funzionalità di sicurezza, ma gli attaccanti che prendono di mira la chiave root KDS possono bypassare queste protezioni. Diamo un’occhiata ad alcuni fatti e statistiche a supporto:

• Gli gMSA ruotano le loro password ogni 30 giorni per limitare l'esposizione delle credenziali. Ma se gli aggressori rubano la chiave root KDS, possono calcolare le password gMSA offline in qualsiasi momento, annullando di fatto la protezione della rotazione.
• Poiché ogni gMSA in un dominio si basa sulla stessa chiave radice KDS per la generazione delle password, compromettere questa singola chiave radice può influire su tutti i gMSA nel dominio. Questo crea un rischio a livello di dominio da un singolo punto di guasto.

Il grafico a barre seguente confronta la finestra di sicurezza prevista (rotazione di 30 giorni) con la finestra di accesso effettiva dell’attaccante (indefinita se KDS è compromesso).

Considerazioni finali

Alla fine, i gMSA sono una lama a doppio taglio: semplificano l'autenticazione dei servizi e rafforzano la sicurezza se gestiti correttamente, ma nelle mani sbagliate possono diventare le chiavi del regno. Quando gli attaccanti falsificano un Golden gMSA, non rubano solo una password; ereditano la chiave principale della tua infrastruttura, con il potere di muoversi silenziosamente tra sistemi e servizi. Il pericolo risiede nella loro invisibilità: si manifestano inosservati finché l'intera azienda non è a rischio. Proteggere le chiavi root KDS, monitorare attività sospette dei gMSA e implementare una forte sicurezza del domain controller sono salvaguardie essenziali per il tuo ambiente Active Directory.