Azure Annihilation

Ormai la moda del “Cloud” è uno stile IT sdoganato in tutto il mondo. Il termine significa “nuvola” ed identifica una rete informatica che mette a disposizioni innumerevoli servizi attraverso la rete internet e disponibili da remoto sotto forma di architettura distribuita. Malgrado ciò che molti possono pensare, il cloud computing non è così recente come si pensa. I primi “comunicator” erano terminali dotati solo di schermo e tastiera i cui dati venivano inviati ad un centro di calcolo remoto.

Il buon senso dovrebbe guidarci su un semplice paradigma: “Ad oggi, una marea dei nostri dati sono in mano a “sconosciuti”: chiamate, foto, posizioni, agende, appuntamenti, spostamenti, numero di volte in cui clicchiamo lo schermo, perfino ciò che si dite finisce sul Cloud e dato in pasto alle IA, che profilano per poi proporre le più svariate pubblicità. Persino aziende di Cyber Sicurezza pagano stati esteri per fare da SOC ad aziende italiane, ma poiché servono sempre il “dio denaro”, sono destinate a restare sempre un passo indietro, azzoppate dagli idoli che loro stesse servono e venerano”.

La verità è che anche molti esperti del settore tendono a credere che sia possibile demandare a terzi la gestione della propria infrastruttura non dovendosi preoccupare, ad esempio, di tutti quei problemi tecnici legati alla Cyber Sicurezza.

Generalmente “non assumersi le proprie responsabilità” non è mai una grande idea. Non dico che il cloud sia di per sé sbagliato, dico solo che andrebbe utilizzato attentamente applicando ancora più accortezze di quante ne useremmo per il nostro ambiente “on-premises”.

Kerberos

Il protocollo di autenticazione di Microsoft fu sviluppato al Massachusetts Institute of Technology (MIT) e prende il nome dal mitologico mastino a tre teste a guardia dell’ingresso degli inferi, su cui regnava il dio Ade. Ognuna delle teste era in grado di scorgere il passato, il presente ed il futuro.

Il protocollo consente a due parti (ad esempio un client ed un server) di autenticarsi a vicenda su un canale di rete non sicuro. Entrambe le due parti coinvolte, fanno riferimento ad una terza parte che fa da “garante” tra le due: il server Kerberos. Da qui il nome del protocollo che vede coinvolte tre parti:

• Il KDC (Key Distribution Center)
• Il client che richiede l’accesso
• Il servizio di cui il client sta tentando di ottenere l’accesso

Kerberos: Flusso di Autenticazione

Il “garante” che abbiamo citato in precedenza, in un’infrastruttura di rete è rappresentato dal Domain Controller (DC). Il Domain Controller è il server che si occupa delle richieste di autenticazione all’interno di un dato Dominio. Per assolvere al suo scopo il DC ottempera anche altri ruoli: Authentication Server (AS) e Ticket Granting Service (TGS).

Vediamo adesso quale è il flusso di autenticazione nel dettaglio:

1. Il Client invia una richiesta di ticket-granting-ticket (TGT) all’AS. La richiesta contiene: timestamp criptato più hash NT dell’utente
2. Se l’AS decripta il messaggio, invia al client il TGT
3. Il client una volta ottenuto il TGT, può inviare al TGS il suo TGT più il dettaglio del servizio a cui vuole accedere
4. Il TGS risponde con il Service Ticket più la Session Key
5. Il client adesso può autenticarsi utilizzando il Service Ticket.

In poche parole, il client chiede al “garante” un biglietto di riconoscimento (TGT), ottenuto il biglietto (di fatto significa che ha soddisfatto dei requisiti) lo ripresenta al “garante”, con anche la richiesta del servizio a cui desidera accedere. Il garante gli risponde fornendogli un lasciapassare (Service Ticket) che potrà utilizzare per autenticarsi al servizio.

Il sistema centralizzato, cuore di Windows Server, che si fonda sui concetti di Dominio e di Directory e che poggia le sue fondamenta sull’autenticazione Kerberos è chiamato Active Directory.

Azure Active Directory (Azure AD) è il servizio in Cloud di Active Directory basato su IaaS (Infrastructure-As-A-Service).

Creiamo adesso il nostro ambiente Azure.

Registrazione

Prima di settare il nostro ambiente Azure AD, è necessario registrarsi al seguente link: https://azure.microsoft.com/en-us/free/ e clicchiamo su Start Free.

Clicchiamo su Create Account.

Una volta loggati con il nostro account ci ritroveremo difronte alla schermata Create Your Azure free account dove dovremo compilare i vari campi.

Creazione di un nuovo Tenant

Un tenant Azure AD è un’istanza specifica di Azure AD che include account e gruppi.

1. Nel menù di ricerca digitiamo Azure Active Directory e clicchiamo su Create

2. Nel menù configuration, inseriamo:
   1. Il nome dell’Organizzazione: hack3rjournal
   2. Il nome del nostro Dominio: hackerjournal
   3. Ed infine la regione: Italy

3. Spostiamo nella scheda Review + Create e confermiamo i dati, selezionando il pulsante Create in basso a sinistra.

Complimenti, avete appena creato il vostro primo Azure AD Tenant!

Il nuovo Tenant è stato creato con il dominio: hack3rjournaloutlook.onmicrosoft.com

Azure Reconnaissance

Supponiamo adesso che il nostro obiettivo sia attaccare il dominio appena creato. Come già sappiamo dallo scorso numero di Hacker Journal, una delle fasi più importanti di un attacco è la raccolta di informazioni sul target.

Abbiamo appena visto che creando un Azure AD tenant (o anche O365), viene creato automaticamente il dominio:
.onmicrosoft.com

Il primo nostro passo sarà quello di richiedere i record DNS ed identificare le informazioni contenute nei record TXT e MX (se queste sigle non vi dicono niente, vi rimando al numero di Hacker Journal 260). Microsoft ha due opzioni per validare il dominio:

1. Un TXT record che contiene il valore MS= con un TTL di 3600 secondi.
2. Un MX record con priorità alta: ms.msv1.invalid con un TTL di 3600 secondi.

Nel nostro caso, la data organizzazione utilizza Azure AD con applicazioni Software-as-a-Service (SaaS). L’attaccante può verificarlo dai record MX e TXT del DNS o dai “federation records” come: adfs.targetdomain.com, sso.targetdomain.com, sts.targetdomain.com .

I campi che dovremo cercare e che indicano la presenza di Azure AD sono, ad esempio:

1. Il record: *.mail.protection.outlook.com
2. Il record: MS=ms76565273

Ma c’è un altro modo per verificare se una data organizzazione sta utilizzando Azure:

Possiamo navigare al seguente URL: https://login.microsoftonline.com/getuserrealm.srf?login=user@&xml=1

• Lo username può essere quello che desideriamo
• Dobbiamo solamente sostituire all’interno dell’URL il campo con il nome del dominio della nostra vittima. Ad esempio: edu

Una volta che avremo dato “enter” ci apparirà la pagina corrispondente con le seguenti informazioni:

6
2
hackerjournal@hac3rjournal.edu
Managed
hac3rjournal.edu
false
HACKER JOURNAL FAKE SPA
microsoftonline.com
urn:federation:MicrosoftOnline

Il campo che a noi interessa è il valore Managed per il che indica la presenza di Azure AD e O365 (altre opzioni sono “Unknow” o “Federation”.

Una volta che abbiamo constatato che la data organizzazione utilizza Azure AD, potremmo optare per un attacco di Password Spraying.

Password Spraying Attack

Un brute-force attack cerca di ottenere un accesso non autorizzato di un singolo account facendo “guessing” della password. Questo approccio è inutilizzabile poiché l’account sarebbe bloccato dopo un numero di tentativi, che variano solitamente da tre a cinque (e ne dovremmo fare molti di più).

Ciò che dovremmo fare, invece, è vedere la questione da un altro punto di vista: in un attacco di tipologia “spray” si prova una singola password su molteplici account e poi si passaalla successiva della lista. Questa tipologia di attacco ci permette di evitare frequenti e continui blocchi dell’account, in quanto viene eseguito un singolo tentativo di accesso per ogni utente.

Dato che gli ambienti cloud espongono pubblicamente i loro portali di login, essi rappresentano un ottimo bersaglio per questo tipo di attacco. Di fatto, le campagne di Password Spray prendono come target le Single-Sign (SSO) e le applicazioni basate sul Cloud che utilizzano i protocolli di “federated-authentication”.

User Enumeration

La prima cosa da fare sarà quindi procurarci una lista di utenti su cui mettere a segno il nostro Spray Attack. Per farlo, abbiamo diverse opzioni: una è quella di ottenere una lista di dipendenti, attraverso l’utilizzo di classiche tecniche di OSINT (ad esempio sfruttando LinkedIn) e poi determinare il criterio con cui l’organizzazione crea le sue e-mail. Ad esempio nome.cognome@dominio.edu oppure prima-lettera-del-nomecognome@dominio.edu

Attack!

Una volta che la lista delle email target è pronta, non ci resta che utilizzare il nostro script per portare l’attacco.

In questo esempio utilizzeremo o365spray. Lo script in Python è scaricabile su GitHub al seguente indirizzo: https://github.com/0xZDH/o365spray

Per eseguirlo dovremmo dare allo script i permessi di esecuzione, utilizzando il comando:

chmod +x o365spray.py

Adesso potremo lanciare il nostro comando:

./o365spray.py --spray -U usernames.txt -p Pass123! --count 2 --lockout 5 --domain dominio.edu

Analizziamo il comando nel dettaglio:

• ./o365spray.py: lanciamo il nostro script
• –spray: scegliamo l’opzione per lanciare uno Spray Attack
• -U usernames.txt : la lista dei nostri username. Le email degli utenti che abbiamo raccolto precedentemente
• -p Pass123! : la singola password che vogliamo provare su tutti gli account
• –count 2 : Numero dei tentativi che vogliamo effettuare (2 tentativi)
• –lockout 5 : Reset Time per la Lockout Policy, in minuti ( 5 minuti)
• –domain dominio.edu : il dominio che vogliamo attaccare

Una volta che avremo ottenuto le credenziali di accesso al dominio, potremo decidere di utilizzare vari tool per effettuare una ricognizione interna della sua struttura.

Authenticated Reconnaissence

Esistono diversi modi per effettuare la nostra ricognizione. Uno è quello di utilizzare uno script PowerShell che carpisce le user info, group membership e company information.

La prima cosa che dovremo fare per utilizzarlo sarà installare i moduli MsOnline. Apriamo PowerShell con i privilegi di amministratore e digitiamo i seguenti comandi:

• Install-Module MSOnline
• Install-Module -Name AzureAD

Una volta che i nostri moduli saranno installati, scarichiamo il tool da GitHub al Link: https://github.com/nyxgeek/o365recon

Estraiamolo in una directory a scelta e, utilizzando sempre la nostra Command Line Interface (CLI) di PowerShell, navighiamo nella directory dove è presente lo script.

Avviamolo digitando il nome dello script, preceduto da . . Dopo un breve check dei moduli installati da parte dello script, ci apparirà la schermata di LogIn.

Post-Exploitation

Effettuata la nostra ricognizione, dovremo eseguire tutte quelle attività di Pivoting ed escalation necessarie per raggiungere il nostro obiettivo. In questa fase ci viene incontro PowerZure che ci aiuta ad identificare misconfiguration o privilegi non assegnati correttamente. Le sue funzioni sono:

• Mandatory: Operazioni da effettuare per prime
• Operational: Funzioni che innescano processi su Azure
• Information Gathering: Raccolta d’Informazioni
• Secret Gathering: Funzioni con l’obbiettivo di collezionare informazioni categorizzate come “secret”
• Data Exfiltration: Funzioni per esfiltrare/estrarre dati

È possibile scaricare PowerZure al seguente link: https://github.com/hausec/PowerZure

In molti credono che una volta penetrati all’interno di un sistema, l’attacco sia terminato. In realtà, siamo solo all’inizio.
Vediamo adesso una delle possibili strategie d’attacco che possiamo impiagare per prendere il controllo completo e mantenere la persistenza all’interno di Azure AD, che ci permette di introdurre diversi concetti.

DCSync – Attacking PHS

L’attacco DCSync sfrutta il protocollo di replica fra i domini per “imitare” il Domain Controller. Se l’attacco ha successo, tutte le password nel dominio vengono compromesse.

Il Password Hash Synchronization (PHS) è l’account usato da Azure AD Connect, per sincronizzare la password hash dell’Active Directory on-premises con quella di Azure AD. Riuscendo a prendere il controllo di questo account, possiamo attuare il “dcsync attack”.

Quindi il nostro primo step sarà quello di identificare su quale server è installato Azure AD Connect. Per farlo dobbiamo localizzare l’account di sincronizzazione, denominato da Microsoft: MSOL_nnnnnnnnnn . Il campo “Description” dell’account identifica la macchina su cui è in esecuzione AzureAD Connect.

Ci basterà quindi utilizzare il seguente comando, sfruttando il modulo di PowerShell AD, per estrapolare il campo “Description”:

Get-ADUser -filter 'name -like "Msol*"' -Properties Description

Il nostro secondo passo nell’attacco sarà quello di recuperare la password dell’account di sincronizzazione dal Credential Manager e decriptarla con le chiavi DPAPI (metodo di crittografia utilizzato per i dati che non vengono mai letti al di fuori dell’host che la utilizza), per farlo abbiamo due possibilità:

1. Utilizzare uno script in PowerShell : https://gist.github.com/xpn/f12b145dba16c2eebdd1c6829267b90c
2. Utilizzare il tool adconnectdumo : https://github.com/fox-it/adconnectdump

Entrambi sfruttano le chiavi DPAPI dal server per la decriptazione.

L’ultimo nostro passo, sarà quello di sfruttare il tool MIMIKATZ per l’attacco di DCSync. MIMIKATZ è un tool open sourceb creato da Benjamin Delpy, per dimostrare le vulnerabilità del protocollo di autenticazione di Microsoft. Fu creato nel 2007, ma è tutt’ora un’arma efficacissima.

Solitamente in una struttura Active Directory, gli amministratori di sistema configurano più di un domain controller. Ogni Domain Controller possiede una copia del Database dell’Active Directory. Ogni aggiornamento fatto all’interno del database (tipo la creazione di un utente) deve essere propagato fra gli altri Domain Controller. L’insieme delle metodologie e protocolli utilizzati per sincronizzare tale database prende il nome di Active Directory Replication.

Il seguente comando di MIMIKATZ (senza opzioni extra) seleziona automaticamente il dominio ed il domain controller automaticamente, ed estrae le credenziali dal domain controller attraverso il protocollo di replica: Directory Replication Service Remote (DRSR).

mimikatz “kerberos::dcsync /user:administrator”

A questo punto, il gioco è fatto: una volta ottenute le credenziali dell’amministratore di dominio, possiamo usare dcsync per connetterci al Domain Controller ed estrarre le credenziali “madri” del sistema di autenticazione Kerberos. I dati possono essere utilizzati per creare un Ticket Granting Ticket (TGT) “speciale”, chiamato: Golden Ticket.

Il Golden Ticket prende il nome dal film “La Fabbrica di Cioccolato” ed è il biglietto d’oro che permette l’accesso completo a tutte le meraviglie della Fabbrica. Analogamente nell’Active Directory il Golden Ticket è la “matrice” di tutti i Ticket che ci permette di utilizzare i permessi massimi per il massimo tempo, compromettendo l’account di sistema denominato: krbtgt.

Quando l’attaccante utilizza il Golden Ticket la prima interazione è una richiesta per ottenere il “Service Ticket” (fare riferimento alla Figura #1) denominata TGS-REQ utilizzando il “Gold-Ticket Granting Ticket”. Non avviene alcun invio di credenziali o AS-REQ/AS-REP. In altre parole, equivale a presentarsi al nostro “garante” (il Domain Controller) dicendo: “Guarda il biglietto che possiedo: è quello con i più alti permessi! Forniscimi quindi l’accesso al servizio che desidero!”.

Finalmente abbiamo compromesso il dominio e ce ne siamo assicurati il pieno controllo!

Ma questo non è che solo un assaggio degli attacchi che potremmo mettere in atto per prendere il controllo e mantenere la persistenza all’interno di Azure AD. Molti altri attacchi sono possibili, tra cui: Skeleton Key, Silver Ticket, Pass-the-Hash, Token Forging, etc…