• Cloud, Guide, Microsoft 365, Sicurezza, Sistemi Operativi
• 10 Marzo 2020

Non tutte le aziende sono pronte a adottare un approccio cloud-only dismettendo fino all’ultimo server affidandosi unicamente al SaaS.
Questo varia molto da settore a settore, ma per molti il Cloud è un viaggio più che una destinazione.

Per il futuro prevedibile Active Directory rimarrà nelle aziende, continuando ad erogare i servizi più importanti ma spesso invisibili al business come l’autenticazione e la risoluzione dei nomi.
Vista l’importanza del ruolo che ricopre non sorprende che tra i sistemi on-premises
 Active Directory sia l’obiettivo principale di ogni attacco: una volta conquistata la domain dominance l’attaccante ha di fatto le chiavi di casa e può fare quello che desidera con il resto dell’infrastruttura.

Azure Advanced Threat Protection aiuta a rilevare le minacce rivolte all’istanza on-premises di Active Directory.
Azure ATP utilizza dei modelli predittivi di machine learning che permettono di riconoscere una vasta serie di attacchi:

Licenze richieste per utilizzare Azure ATP

Per poter utilizzare Azure ATP è necessario disporre di una delle seguenti licenze per ogni utente dell’Active Directory on-premises:

• Enterprise Mobility + Security 5 (EMS E5)
  
• Microsoft 365 E5
  
• Azure ATP Standalone
  

Non è sufficiente la licenza Office 365 E5 in quanto i piani Office includono solo prodotti di Productivity e hanno limitate funzioni di sicurezza.

Configurazione di Azure ATP

Nei passi di configurazione assumeremo già disponibile un ambiente Active Directory ibrido e l’accesso ad account con privilegi Domain Admins per quanto riguarda Active Directory e Global Admin per quanto riguarda Azure AD.
Se gli ambienti on-premises e cloud sono disgiunti è possibile sincronizzare Active Directory con Azure AD tramite Azure AD Connect, come spiegato nell’articolo Implementare il Single Sign-On (SSO) con Azure AD.

Collegarsi all’indirizzo https://portal.atp.azure.com/ per creare l’istanza di Azure ATP.

NOTA: Se non si collega un sensore entro 60 giorni l’istanza verrà eliminata.

Figura 1 – Creazione istanza Azure ATP

Dopo qualche istante verrà mostrata la Timeline e nella parte superiore della pagina si viene guidati nel setup del tenant.
Premere su Provide a username and password per proseguire nella configurazione.

Figura 2 – Timeline pre-configurazione

Nel caso in cui si stia installando il connettore di Azure ATP su Domain Controllers
Windows Server 2012 e successivi (cosa che raccomandiamo) è consigliato utilizzare un gMSA.
I Group Managed Service Accounts sono account di servizio che gestiscono automaticamente il cambio password, aumentando la sicurezza rispetto agli account utente classici.
Sono supportati anche su altri prodotti come SQL Server, ADFS, Windows Tasks, Servizi e altri prodotti.
Se non è mai stato creato un gMSA è necessario procedere alla creazione della KDS Root Key. Non createne più di una.
Tramite Windows PowerShell su un Domain Controller oppure su una Workstation amministrativa su cui sono installati i Remote Server Administration Tools digitare:

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati il seguente comando PowerShell:

Procedete quindi alla creazione di un gMSA per Azure ATP utilizzando il comando PowerShell:

Creato il gMSA inserire il nome dell’account e il Fully Qualified Domain Name del dominio nella schermata di configurazione, ad esempio test.contoso.com.
Nella Figura 3 è mostrata la configurazione con un gMSA. Se si sceglie di utilizzare un account utente regolare si dovrà inserirne la password.

Figura 3 – Configurazione Account

Premere Download sensor setup per installare il primo agente su un Domain Controller.

Figura 4 – Configurazione Account terminate

Premendo Download verrà scaricato un file Zip che contiene il setup dell’agente ed un file json di configurazione contenente gli estremi della istanza di Azure ATP, è utilizzabile per installare gli agenti necessari a coprire tutti i Domain Controllers.
La Access key che viene generata serve per instaurare la prima comunicazione tra l’agente ed il servizio Azure ATP. Durante il setup viene creato un certificato digitale e la Access key non verrà più utilizzata.
Deve essere conservata con cura e non divulgata, in caso di compromissione si può generare una nuova Access key che sarà utilizzata per le installazioni future, quelle preesistenti non subiscono nessun effetto.

Figura 5 – Download sensor setup

Estrarre lo Zip e copiarne il contenuto su una share di rete o su un percorso locale sul Domain Controller.
Eseguire Azure ATP Sensor Setup.exe per iniziare il processo di installazione.

Figura 6 – Sensor Setup estratto

Selezionare la lingua e premere Next

Figura 7 – Selezione della lingua

Assicurarsi di aver selezionato Sensor e premere Next.
Lo Standalone Sensor è utile nel caso in cui non si voglia installare il sensore direttamente su un Domain Controller ma si voglia utilizzare il port mirroring della scheda di rete del DC per far fluire il traffico verso un server dedicato.
L’opzione di installare uno Standalone Sensor è disponibile solo se si sta installando l’agente su un server che non è Domain Controller e non è comunque raccomandata oltre ad essere più complessa in termini di preparazione dell’infrastruttura.

L’agente richiede almeno 2 Cores e 6 GB di RAM, assicurarsi di disabilitare tutte le features di ridimensionamento a runtime della memoria come Dynamic Memory per Hyper-V e Ballooning per VMWare.
Ogni 10 secondi l’agente verifica che ci siano risorse sufficienti alla normale operatività del Domain Controller, se rileva una situazione di carenza di risorse inizia a scartare il traffico da analizzare, in quel caso si verrà avvisati nella console di Azure ATP. L’operatività del Domain Controller viene sempre privilegiata.

Figura 8 – Selezione Sensor

Confermare il percorso in cui verrà installato l’agente e inserire l’Access key, premere Next

Figura 9 – Path installazione e Access key

Attendere il completamento del setup.
Se non presente verrà installato il .NET 4.7 il quale potrebbe richiedere un riavvio.

Figura 10 – Installazione componenti sensore

Al termine dell’installazione si riceverà l’esito dell’operazione.
È possibile chiudere la finestra premendo su Finish.

Figura 11 – Setup terminato con successo

Sul sistema sono stati appena installati due servizi:

• Microsoft.Tri.Sensor esegue il parsing dei log di sistema e del traffico di rete.
  Il risultato di questa operazione viene inviato ad Azure ATP.
• Microsoft.Tri.Sensor.Updater è il servizio responsabile dell’aggiornamento del sensore all’ultima versione.

Figura 12 – Servizio Sensor in esecuzione

Dopo qualche minuto, si potrà osservare lo stato dell’agente appena installato nella console di Azure ATP.
Ogni sensore è potenzialmente anche Domain Synchronizer per poter fornire ad Azure ATP una replica parziale del dominio su cui è installato. Entro pochi minuti Azure ATP riceverà le informazioni sulla infrastruttura on-premises e sarà in grado di avvertire se alcuni Domain Controllers non hanno l’agente installato.

Figura 13 – Sensore appena installato, warning su altri sensori mancanti

Procedere quindi all’installazione dell’Agent sugli altri Domain Controllers, includendo anche eventuali Read-Only Domain Controllers.

Figura 14 – Installazione completata

Siccome Azure ATP è un servizio SaaS ha una cadenza di aggiornamento serrata, con diversi rilasci ogni mese.
L’agente è un componente fondamentale ed è quindi molto importante che venga mantenuto alla corretta versione.
Esistono due tipi di aggiornamento dell’agente:

• Minori
  
  • Frequenti
  • Non richiedono installazione di pacchetti MSI e non cambiano impostazioni di registro
  • Riavvia il solo servizio dell’agente
  • Non richiedono il riavvio del Domain Controller
• Maggiori
  
  • Rari
  • Richiedono installazioni di pacchetti MSI
  • Riavviano il servizio dell’agente
  • Potrebbero richiedere il riavvio del Domain Controller

L’impostazione raccomandata è quella di consentire gli aggiornamenti automatici e gli eventuali riavvii automatici.
Il servizio aggiorna un agente alla volta, prima di passare al successivo.
Selezionando Delayed Update è possibile ritardare di 72 ore l’installazione degli aggiornamenti, per uno specifico Domain Controller.

Figura 15 – Impostazioni di aggiornamento

Utilizzo di Azure ATP

Una volta terminata l’installazione dei sensori e la configurazione delle impostazioni base è possibile visualizzare i dati che Azure ATP sta raccogliendo sulle attività utente.
Cercando un utente nella barra di ricerca è possibile visualizzarne le attività eseguite

Figura 16 – User Activities

Così come visualizzare gli attributi sincronizzati in Azure ATP tra cui l’appartenenza ai gruppi, informazioni di base sull’account e le impostazioni derivate dall’attributo UserAccountControl.
Nella figura 17 è riportato un utente con impostato il flag Password Never Expires

Figura 17 – User Directory Data

La ricerca non è limitata agli utenti, è possibile cercare anche gruppi, servers, computers e molto altro.
Cercando un file server è possibile vedere chi vi ha avuto accesso, da quale IP e tramite quali protocolli è avvenuta l’autenticazione.

Figura 18 – Computer Activities

Azure ATP non mostrerà da subito gli eventuali rilevamenti nella Timeline perché ha bisogno di 30 giorni di traffico di rete reale per poter fornire delle ipotesi le più accurate possibili.

Simulazione di un attacco

È possibile simulare diversi tipi di attacco seguendo le istruzioni dell’articolo ATP security alert lab e visualizzarli nella Timeline di Azure ATP.
Uno degli scenari utilizzabili è quello di simulare un tentativo di Reconnaissance da parte di un attaccante, uno dei primi passi nella kill chain di un AD on-premises.

Figura 19 – Active Directory Kill chain

Una volta rilevato l’evento Azure ATP lo mostra all’interno della Timeline, premendo sul nome del computer è possibile visualizzarne tutti i dettagli.

Figura 20 – Timeline con Reconnaissance Attack

Leggendo la Timeline dal basso verso l’alto possiamo osservare tutte le azioni intraprese tramite le quali l’attaccante ha carpito molte informazioni sull’infrastruttura interna.
Ha prima tentato di trasferire la zona DNS del dominio, poi ha enumerato tutti gli utenti e computers del dominio, cercato gli amministratori leggendo l’appartenenza ai gruppi privilegiati.
Infine per capire da quale PC è loggato l’amministratore ha elencato tutte le sessioni SMB verso la share SYSVOL del Domain Controller.

Figura 21 – Device Timeline

Il passo successivo è stato quello di rubare una credenziale ad un amministratore, precedentemente identificato tramite la Reconnaissance, tramite un Overpass-The-Hash
Anche questo tipo di attacco viene evidenziato nella Timeline.

Figura 22 – Overpass the hash

Fino ad arrivare alla compromissione totale dell’ambiente, una volta acquisita la DPAPI Master Key un attaccante può de crittografare qualsiasi dato protetto dalla Windows Data Protection API come ad esempio certificati digitali, SQL Server Database protetti da TDE, dati biometrici degli utenti e molto altro.
La compromissione della DPAPI Master Key è solo uno dei tanti metodi disponibili per ottenere la Domain Dominance.

Figura 23 – DPAPI Compromised

Conclusioni

Azure ATP è un potente alleato nel rilevare e visualizzare le minacce alle quali l’ambiente Active Directory
on-premises è sottoposto, non è però in grado di mitigarle.
È necessario che l’ambiente on-premises abbia il giusto disegno architetturale e che siano messe in pratica le corrette prassi amministrative.

Abbiamo già parlato di come mettere in sicurezza Active Directory nell’articolo Active Directory – Tecniche di attacco e di difesa
Sfruttando alcune features introdotte in Windows 10 come Credential Guard è possibile mitigare il furto di credenziali dalla memoria di un sistema compromesso, rendendo ulteriormente difficile la vita ad un attaccante.
Anche le baseline security policy rendono inefficaci molti degli attacchi qui descritti e sono un ottimo punto di partenza, le potete trovare alla pagina Microsoft Security Compliance Toolkit 1.0

La sicurezza non è un risultato ma un processo, è importante rimanere vigilanti sulla propria infrastruttura ed evolverla così come si evolvono gli attacchi informatici.