• Sicurezza, Sistemi Operativi
• 18 Novembre 2017

L’Active Directory (AD) se non gestita e monitorata correttamente può diventare un vettore di attacco per l’infrastruttura aziendale. Di seguito elencheremo una serie di tipologie di attacco che possono sfruttare AD come vettore cercano di capire come possono essere prevenute e mitigate.

Attacchi su Active Directory volti a creare una BotNet

Questo tipo di scenari attacco sono stati analizzati da Ty Miller (Managing Director at Threat Intelligence Pty Ltd) e Paul Kalinin (Senior Security Consultant at Threat Intelligence Pty Ltd) nella sessione The Active Directory Botnet tenuta al blackhat USA 2017.

Tali attacchi si basano sul fatto che gli oggetti utente in Active Directory hanno come risaputo un gran numero di attributi che possono essere letti da tutti gli account utenti e computer del dominio, per contare il numero di attributi esposti da un account utente è possibile utilizzare il seguente comando PowerShell:

(Get-ADUser -Identity Username -Properties *).PropertyCount

Gli attributi di un oggetto utente in Active Directory possono essere di vario tipo come Stringa, Numerico, Boolean, Binario, etc. e ogni attributo può contenere dati di diversa dimensione da pochi bytes fino MBytes, di seguito una query PowerShell per vedere nome, tipo e dimensione massima degli attributi degli oggetti utente in Active Directory (a riguardo si veda il post Exploring Active Directory Data Types with PowerShell):

$schema =[DirectoryServices.ActiveDirectory.ActiveDirectorySchema]::GetCurrentSchema()

$schema.FindClass(‘user’).OptionalProperties | Select Name, RangeUpper | Sort RangeUpper -Descending

Gli attributi possono quindi essere utilizzati per l’injection dei dati da parte di una botnet al fine di utilizzarli successivamente da altri computer. Una Active Directory Botnet presenta infatti il seguente schema di funzionamento:

1. Gli host compromessi fanno injection di dati negli attributi del loro account AD ed eseguono query nel dominio per identificare i sistemi compromessi
2. Questo approccio permette al bot master e agli slave di identificare le macchine infette su cui lanciare i comandi le cui risposte saranno memorizzate negli attributi dell’account AD corrispondente all’endpoint e lette poi dall’host che aveva lanciato il comando
3. Le Botnet possono anche implementare una funzione di copertura che consente comunicazioni confidenziali tra gli host e la possibilità di utilizzare proprietà personalizzate di Active Directory per eludere tentativi di rilevamento
4. Questo tipo di attacco fornisce un potente canale di comunicazione che elude i Network Access Controls (NAC) e consente di implementare un Command & Control basato su Active Directory
5. Grazie all’utilizzo degli attributi degli oggetti AD né la Domain separation né la network segmentation possono interrompere la comunicazione
6. Dopo aver stabilità la comunicazione con la Botnet gli attributi binari vengono utilizzati per scaricare file posizioni remote tramite binary-to-text Base64 encoding
7. A questo punto le bots possono comunicare esternamente tramite shell remote che vengono utilizzate anche per eseguire l’exfiltration dei dati all’esterno dell’infrastruttura

La prevenzione di questo tipo di attacchi non può che basarsi sul monitoraggio regolare delle modifiche sugli attributi degli oggetti utenti di AD che non dovrebbero subire Variazioni in modo regolare, ovvero occorre rispettare la quinta legge delle 10 Immutable Laws of Security Administration:

Law #5: Eternal vigilance is the price of security

Nativamente come indicato in Monitoring Active Directory for Signs of Compromise è possibile eseguire l’audit delle Directory Service Changes, ma si noti che vi sono alcune limitazioni (per maggior dettagli si veda Audit Directory Service Changes):

“This subcategory reports changes to objects in AD DS. The types of changes that are reported are create, modify, move, and undelete operations that are performed on an object. Directory service change auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL entries. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema. This subcategory applies only to domain controllers.”

Per maggiori dettagli suul’Auditing di AD si veda anche AD DS Auditing Step-by-Step Guide.

In alternativa è possibile utilizzare prodotti di terze parti, come ad esempio ADAudit Plus di ManageEngine, mentre al momento Advanced Threat Analytics (ATA) non rileva attività malevole basate sulla modifica degli attributi degli oggetti AD, per i dettagli sulle attività sospette rilevate da ATA si veda: Advanced Threat Analytics suspicious activity guide.

AD Discretionary Access Control Lists (DACL) Backdoors

Questo tipo di scenari attacco sono stati analizzati da Andy Robbins (Adversary Resilience Lead at SpecterOps) e Will Schroeder (Offensive Engineer at SpecterOps) nella sessione An ACE Up the Sleeve: Designing Active Directory DACL Backdoors tenuta al blackhat USA 2017 e nel post Active Directory Access Control List – Attacks and Defense del Microsoft Advanced Threat Analytics Team.

Tali attacchi si basano sull’utilizzo del Discretionary Access Control List (DACL) per eseguire privilege escalation in un ambiente di dominio utilizzando come vettore di attacco la creazione di un path di escalation basato sulle permissions degli oggetti AD (DACLs), ma prima di affrontare alcuni potenziali scenari di attacco occorre prima analizzare i concetti su cui questi attacchi si basano.

L’Access Control è implementato assegnando Security Descriptors agli oggetti AD, un Security Descriptor è un set di informazioni collegate ad ogni oggetto e che contiene quattro componenti di sicurezza:

• Il Security identifiers (SIDs) dell’Object Creator (l’utente che ha creato l’oggetto) e del primary group dell’oggetto
• La Discretionary Access Control List (DACL) costituita da access control entries (ACE) che rappresentano i SID di utenti e gruppi a cui sono consentiti o negati i diritti di accesso all’oggetto
• La System Access Control List (SACL) costituita dagli utenti e gruppi a cui è consentito l’auding sull’oggetto
• Un set di control bits che qualificano il significato di un descrittore di protezione o dei singoli membri.

Va precisato che gli accounts built-in privilegiati (Domain Admins, Enterprise Admins, etc) sono protetti dal Security Descriptor propagation (o SDProp) che forza le ACL per impedire modifiche non autorizzate ogni 60 minuti (per default) resettando le permissions a quelle del container AdminSDHolder contenuto nel System container della Domain Partition. Il processo esegue i task in modo recursivo su tutti i membri dei gruppi e disabilita l’eredità su tutti i protected accounts.

Uno scenario di attacco basato sulla Discretionary Access Control List (DACL) è quello che
si basa sulle deleghe di permissions su oggetti AD concessi ad account non-built-in privilegiati. AD consente ad un amministratore di delegare permission a normali account di dominio (utenti, gruppi, computer) senza la necessità di aggiungere tali account a gruppi amministrativi e tra le deleghe comunemente concesse vi sono “Reset Password” (spesso concessa agli utenti helpdesk) e la “Add New Member to a group” (spesso concessa ai proprietari dei business group).

Quindi nel caso in cui venga compromesso un account a bassi privilegi, ma con la delega “Add New Member to a group” che gli permette di aggiungere un utente ad un gruppo che ha a sua volta il privilegio di “Reset Password” su un gruppo che contiene utenti ad elevati privilegi è possibile creare un path di attacco volto alla compromissione di account privilegiati.

Di seguito un schema di esempio di questo path di attacco:

Come illustrato precedentemente un ipotetico attaccante non sarà in grado di eseguire una privileges escalation sui privileged built-in accounts le cui ACL sono protette da SDProp, quindi la modifica alle ACL di default del container AdminSDHolder è sconsigliata perché estende la superficie di attacco del dominio, va comunque precisato che non esistono motivi per cui sia necessario modificare le ACL di default del container AdminSDHolder come riportato nel post Active Directory Access Control List – Attacks and Defense:

“Why would you change AdminSDHolder manually? No idea.

You should be careful with changing the AdminSDHolder, the Exchange team faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. If you have a good reason (as we couldn’t find one) please leave us comments at [email protected].”

Anche in questo caso la prevenzione di questo tipo di attacchi deve innanzitutto basarsi sul monitoraggio dell’infrastruttura inteso come ricerca di potenziali path di attacco e per eseguire tali ricerche è possibile utilizzare un tool open source come BloodHound che utilizzando la teoria dei grafi ricerca relazioni nascoste o non desiderate in un ambiente Active Directory. Un altro tool open source per eseguire l’analisi dei path e delle relazioni in AD, a cui gli stessi autori di BloodHound si sono ispirati, è Active Directory Control Paths. Un terzo tool GUI basato su PowerShell per la creazione di report delle access control lists (DACLs) e delle system access control lists (SACLs) in un ambiente Active Directory è https://github.com/canix1/ADACLScanner, il cui utilizzo è descritto nel post Forensics: Active Directory ACL investigation.

Per l’identificazione di questo tipo di attacchi può anche essere impiegato ATA come indicato nel post Active Directory Access Control List – Attacks and Defense:

“ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.”

Conclusioni

Gli attacchi che hanno come obbiettivo Active Directory sono ovviamente molto pericolosi perché se messi in atto mettono nelle mani dell’attaccante il controllo completo dell’infrastruttura. Per prevenire tali attacchi è necessario gestire attentamente la propria infrastruttura, analizzarla attentamente al fine di scovare preventivamente possibili path di attacco o di escalation e monitorare attentamente comportamenti anomali al fine di bloccare rapidamente eventuali tentativi di compromissione di Active Directory. In altre parole occorre rispettare le 10 Immutable Laws of Security Administration e in particolare oltre alla già citata quinta legge anche la settima:

Law #7: The most secure network is a well-administered one

Dal momento che Active Directory rappresenta il fulcro su cui si basa la sicurezza dell’intera infrastruttura oltre al monitoraggio e analisi è bene adottare anche delle serie politiche per la gestione di account privilegiati a riguardo di veda Securing Privileged Access in cui viene descritto come implementare la protezione degli accessi privilegiati tramite l’utilizzo di account amministrativi separati per attività amministrative, l’adozione di Privileged Access Workstations (PAWs) (a riguarda si veda http://aka.ms/CyberPAW), l’adozione di Local Administrator Password Solution (LAPS) (a riguarda si veda http://aka.ms/LAPS) sia per le workstations che per i server al fine di evitare attacchi Pass-the-Hash and Pass-the-Ticket (per ulteriori informazioni inerenti all’implementazione di queste politiche di sicurezza di veda http://aka.ms/securitystandards).

Sempre nell’ottica di adottare anche delle serie politiche per la gestione di account privilegiati anche le indicazioni fornite nel post Protecting Domain Administrative Credentials circa la best practice di differenziare le credenziali di un amministratore di sistema in base al Tier per cui vengono utilizzate limitando i privilegi di tali credenziali alle sole attività che è necessario svolgere nel Tier:

• Tier 0: attività amministrative su Active Directory
• Tier 1: attività amministrative su server applicativi
• Tier 2: attività non privilegiate di utilizzo dei servizi dell’infrastruttura informatica

Come già discusso anche l’adozione di strumenti di analisi dell’infrastruttura evoluti e basati su machine learning come Advanced Threat Analytics (ATA) possono essere utili nel monitoraggio di tentativi di compromissione, ma come indica la decima delle 10 Immutable Laws of Security Administration non bisogna basare le proprie difese affidandosi ciecamente ad un prodotto di sicurezza:

Law #10: Technology is not a panacea

ATA è sicuramente un ottimo strumento per la rilevazione di vari tipi di attacchi tra cui quelli relativi ad Active Directory (a riguardo si veda Advanced Threat Analytics suspicious activity guide) inoltre la tipicità di questo tipo di prodotto fa sì che sia lecito aspettarsi una sempre maggiore efficacia nel rilevamento dei tentativi di compromissione, ma come detto precedentemente occorre prevedere una difesa della propria infrastruttura basata su più livelli di protezione e monitoraggio. Infatti ATA, al momento, oltre a non avere specifiche funzionalità per il rilevamento di Active Directory BotNet basate sulla modifica degli attributi degli oggetti AD può essere eluso con particolari tecniche descritte nella sessione Evading Microsoft ATA for Active Directory Domination tenuta al blackhat USA 2017 da Nikhil Mittal.