Tim Beasley Consulente senior per la risposta agli incidenti

Non tutti i gruppi pericolosi presenti in Active Directory sembrano rischiosi.

Mi occupo di risposta agli incidenti, analisi forense delle identità e ripristino dopo violazioni da abbastanza tempo da avere un elenco in continua evoluzione di gruppi AD che vengono liquidati come “niente di grave”. Operatori di backup. Operatori di stampa. Operatori di server. Quelli di cui nessuno si preoccupa perché non sono amministratori di dominio.

Perché dovrebbe interessarti? Perché agli hacker non serve il ruolo di amministratore di dominio . Quando si tratta di questi gruppi, basta un solo gruppo trascurato con le autorizzazioni giuste — e nessuno che lo tenga d’occhio.

È proprio questo lo schema che questa serie è destinata a infrangere.

In ogni articolo di questa serie, esamineremo più da vicino un gruppo di sicurezza AD selezionato e ne analizzerò i seguenti aspetti:

  • I diritti specifici di cui gode quel gruppo
  • I rischi che possono comportare
  • In che modo gli hacker ne abusano effettivamente
  • Cosa controllare oggi nel proprio ambiente

Alla fine di questa serie, avrai a disposizione un vero e proprio elenco di gruppi poco conosciuti che meritano di essere approfonditi.

Leggi questo primo post sugli operatori di backup e avrai a disposizione una lista di controllo concreta per l'audit e il monitoraggio che potrai mettere in pratica già questa settimana. Poi torna a trovarci per il prossimo gruppo della lista.

Immergiamoci in questa storia.


Quali diritti hanno realmente gli operatori di backup?

Questo è uno di quei gruppi di Active Directory che sembrano noiosi… ma che in realtà sono pericolosi.

Gli amministratori di sicurezza tendono a sottovalutarlo perché non è appariscente come il gruppo “Domain Admins”. È un errore. In realtà, questo gruppo dispone di privilegi che possono consentire abusi gravi e, se finiscono nelle mani sbagliate, catastrofici.

I membri di Backup Operators hanno:

  • SeBackupPrivilege: Leggi qualsiasi file presente nel sistema, ignorando gli ACL NTFS
  • SeRestorePrivilege: Scrivere o sovrascrivere qualsiasi file presente nel sistema, ignorando ancora una volta gli ACL
  • SeShutdownPrivilege: Spegnere il sistema
  • Possibilità di effettuare l'accesso locale per impostazione predefinita sui controller di dominio e sui server

Perché i privilegi degli operatori di backup creano un problema a livello di dominio — in poco tempo

I diritti di questo gruppo sono tecnicamente diritti locali, ma su un controller di dominio hanno un impatto immediato sull’intero dominio. Un operatore di backup compromesso può accedere a un controller di dominio, spegnerlo oppure leggere, scrivere e sovrascrivere file critici indipendentemente dalle autorizzazioni NTFS. Ciò include ntds.dit, rami del Registro di sistema, file binari protetti, percorsi dei servizi e destinazioni delle attività pianificate.

ntds.dit è il database AD, quindi è qui che la situazione diventa “game over”. Se un malintenzionato riesce a creare una copia shadow di quel file e a sottrarre il SYSTEM alveare, possono estratto gli hash NTLM degli utenti del dominio, le chiavi Kerberos, i segreti relativi a DPAPI e le credenziali degli account di servizio con privilegi in modalità offline.

Traduzione: Ti controllano.

Si tratta sostanzialmente di un attaccoDCSync… senzaricorrere a DCSync. I team che si proteggono da tali attacchi spesso monitorano i diritti di replica, l’attività sulla porta 4662 o altri indicatori di replica. Gli operatori di backup possono aggirare tali controlli copiando direttamente il database: stesso risultato finale, percorso diverso e molto più facile da trascurare.

Anche i diritti di ripristino sono importanti. Un malintenzionato può sovrascrivere i file protetti, sostituire file binari come sethc.exe o utilman.exe, modificare i file eseguibili dei servizi o cambiare le destinazioni delle attività pianificate.

In altre parole, un operatore di backup compromesso può sottrarre le chiavi e inserire una backdoor.


Anche senza accesso al controller di dominio, il rischio rimane comunque grave

Su qualsiasi server su cui l'account possa effettuare l'accesso, gli operatori di backup possono leggere tutto, compresi i file di proprietà di SYSTEM. Tale accesso può rendere visibili i dati del Registro di sistema, le directory delle applicazioni, gli archivi di backup e qualsiasi altra cosa salvata su disco, partendo dal presupposto che le autorizzazioni NTFS la proteggano. (AH! MACCHÉ!)

Ciò significa spesso che sono accessibili le credenziali degli account di servizio, le credenziali di dominio memorizzate utilizzate dalle app o dai processi di backup, le stringhe di connessione ai database, i token API, le informazioni Kerberos e le chiavi private dei certificati.

Gli operatori di backup rappresentano spesso un trampolino di lancio durante gli attacchi, non l’obiettivo finale.


Percorsi di crescita professionale degli operatori di backup

Gli aggressori possono inoltre sfruttare i diritti di ripristino per scrivere DLL dannose in percorsi protetti, sostituire i file binari dei servizi, modificare le impostazioni di avvio o di ripristino e forzare l'esecuzione come SYSTEM.

Poiché gli account del gruppo "Backup Operators" vengono spesso considerati affidabili, possono finire sui server di backup, sfuggire ad alcuni controlli di sicurezza o operare con un livello di controllo inferiore rispetto ai gruppi amministrativi più evidenti.


Perché le persone sottovalutano i rischi legati al gruppo degli operatori di backup

Me lo sento dire continuamente:

  • «Non sono amministratori.»
  • «Non possono modificare gli oggetti AD.»
  • «Gli account di backup devono disporre di un accesso esteso.»
  • «Il nostro sistema di monitoraggio è già in grado di individuare gli abusi nella replica.»

Tutto questo va in fumo non appena un malintenzionato copia il ntds.dit e il registro.


«Allora, cosa facciamo?»

È semplice: svuotare il gruppo, monitorare le variazioni nell'appartenenza e mantenerlo vuoto. Se nel gruppo "Operatori di backup" non c'è nessuno, nessuno potrà abusarne.

Questa è la risposta ideale e, francamente, quella che vorrei che più squadre accettassero prima che un fornitore le convinca a fare qualcosa di avventato.

Ma raramente è così semplice. Nel campo della risposta agli incidenti, lo vedo continuamente:

  • Un fornitore afferma che la propria applicazione “richiede” operatori di backup.
  • Gli account vengono aggiunti al gruppo.
  • Tutti vanno avanti.

Se ti ritrovi in questa situazione, l’obiettivo è ridurre il rischio nel modo più deciso possibile e smettere di considerare questi conti come di basso impatto.


Primo: applicare la suddivisione in livelli

Gli account degli operatori di backup devono essere considerati come identità adiacenti al Livello 0. Se un account può consentire a un malintenzionato di accedere al database AD, alle informazioni riservate o ai server più sensibili, si tratta di un account di Livello 0.

  1. Lasciare il gruppo vuoto, monitorare le variazioni nell'appartenenza e considerare qualsiasi eccezione come un rischio elevato.
  2. Non consentire mai agli operatori di backup di accedere ai controller di dominio a meno che non vi sia alcuna alternativa valida. Utilizzare Deny log on locally e Deny log on through Remote Desktop Services. E limitare l'accesso a questi account esclusivamente a determinati server di backup.
  3. Monitorare gli accessi interattivi. Gli account degli operatori di backup dovrebbero comportarsi come identità di servizio, non come persone che utilizzano la tastiera.
  4. Abilita il controllo avanzato dell'accesso ai file su ntds.dit, il SYSTEM hive, repository di backup e percorsi di configurazione delle applicazioni. Segnalare le “letture impossibili”, come ad esempio 4663—rispetto ai file a cui l'account non dovrebbe avere accesso tramite il solo NTFS.
  5. Fai attenzione agli attrezzi come ad esempio diskshadow.exe, vssadmin.exe, wbadmin.exe, ntdsutil.exe, e esentutl.exe, in particolare sui DC, al di fuori delle finestre di backup o da sessioni interattive.
  6. Ridurre il raggio d'azione degli impatti utilizzando gMSA, API specifiche per l'applicazione, strumenti di backup moderni con privilegi ridotti e, ove possibile, un'infrastruttura di backup dedicata o isolata.

Come verificare gli abusi relativi al privilegio SeBackupPrivilege

Revisione contabile SeBackupPrivilege Il suo utilizzo è complicato perché Windows non registra i dati SeBackupPrivilege was used direttamente.

È possibile vedere quando vengono assegnati privilegi speciali a un accesso, ma non esiste un evento chiaro che indichi il privilegio esercitato su un file specifico. Il rilevamento si basa sul contesto, sull’accesso ai file, sul comportamento dei processi e sulla correlazione.

Inizia con l'evento 4672, che mostra quando un utente effettua l'accesso e riceve SeBackupPrivilege o SeRestorePrivilege. Indica quando è iniziata la sessione e restringe il campo di ricerca. Gli operatori di backup sui DC, sui server non dedicati al backup o nelle sessioni interattive dovrebbero risaltare immediatamente.

Quindi abilita il controllo avanzato del file system e applica le SACL a ciò che conta davvero:

  • C:\Windows\NTDS\ntds.dit
  • Il SYSTEM alveare
  • SAM
  • Repository di backup
  • Directory di configurazione delle applicazioni

Eventi come il 4663 e, se del caso, il 4656, indicano ciò che è stato effettivamente toccato.

Il segnale più evidente è la “lettura impossibile”, ovvero una lettura riuscita di un file a cui l’utente non dovrebbe poter accedere in base alle sole autorizzazioni NTFS. Se l’account è di tipo “Operatore di backup”, è proprio il privilegio di backup ad aver reso possibile tale operazione.

  • 4672: Chi ha effettuato l'accesso con il privilegio
  • 4663: Quali file protetti o percorsi di snapshot sono stati letti
  • 4688: Quale processo o strumento ha reso possibile tutto ciò?
  • Contesto: dove è successo, quando è successo, se è stato interattivo e se aveva senso dal punto di vista operativo

La telemetria relativa alla creazione dei processi aggiunge un ulteriore livello. Abilita 4688 con la registrazione da riga di comando e monitorare ntdsutil.exe, diskshadow.exe, wbadmin.exe, esentutl.exe, vssadmin.exe, nonché comandi "copy" o PowerShell diretti verso percorsi sensibili. La combinazione di 4672, 4688, e 4663 è qui che iniziano i rilevamenti ad alta affidabilità.


Come individuare gli abusi delle copie di ombra

L'uso improprio delle copie shadow merita un'attenzione particolare perché rappresenta uno dei modi più "puliti" per aggirare i blocchi sui file e copiare in modo invisibile dati sensibili da un sistema in funzione. Su un DC, ciò significa solitamente che ntds.dit e il SYSTEM hive. In altri contesti, può riferirsi a strutture di registro, segreti delle applicazioni e materiale di backup.

Per individuarlo con precisione, sono necessari il monitoraggio della creazione dei processi, il monitoraggio del file system nei percorsi sensibili e la visibilità sugli accessi con privilegi. La registrazione da riga di comando è fondamentale perché il nome del processo da solo non permette di stabilire se un’istantanea sia stata creata, divulgata o copiata.

Tra gli indicatori ad alto segnale figurano vssadmin.exe, diskshadow.exe, wbadmin.exe, ntdsutil.exe, e esentutl.exe gestito da un non-SYSTEM utente, specialmente su un server DC, al di fuori delle finestre di backup note o da una sessione interattiva. Gli script DiskShadow avviati da directory temporanee meritano un'attenzione particolare.

Uno degli indicatori più significativi è l'accesso a percorsi che contengono HarddiskVolumeShadowCopy. Legge da quei percorsi, concentrandosi in particolare su ntds.dit, SYSTEM, o SAM—di un non-SYSTEM L'utente dovrebbe essere considerato responsabile di abuso fino a prova contraria.

  • 4672 mostrando SeBackupPrivilege assegnato a un operatore di backup o a un account con privilegi analoghi
  • 4688 che mostra l'esecuzione di strumenti correlati a VSS, quali diskshadow, vssadmin, wbadmin, ntdsutil, o esentutl
  • 4663 che mostra le letture da un percorso di copia shadow, ntds.dit, il SYSTEM alveare, SAM, oppure un altro bersaglio protetto
  • Attività che si verifica in un breve intervallo di tempo, in particolare su un controller di dominio o su un altro sistema di livello 0
  • L'utilizzo interattivo, la tempistica ad hoc o l'esecuzione al di fuori della normale pianificazione dei backup aumentano ulteriormente la fiducia

In conclusione: “Backup Operators” merita attenzione

"Backup Operators" sembra innocuo, ma in pratica si avvicina pericolosamente alla compromissione totale del dominio.

L'abuso di questo gruppo su un DC può esporre il database delle directory, aggirare i sistemi di rilevamento incentrati sulla replica, raccogliere credenziali offline e garantire la persistenza tramite la sostituzione di file protetti. Anche senza accesso al DC, gli stessi diritti possono esporre le credenziali dei servizi, i segreti delle applicazioni e i percorsi di escalation in tutto il parco server.

La risposta corretta consiste nel considerare questi account come altamente sensibili. Mantenere il gruppo vuoto ogni volta che è possibile, limitare i punti in cui gli account possono effettuare l'accesso, monitorare gli accessi con privilegi e l'accesso ai file sensibili, prestare attenzione al comportamento delle copie shadow e presumere che la compromissione sia critica fino a quando non si possa escludere l'accesso ai dati rilevanti.

Segui la discussione sugli operatori di backup 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