Diario di un red team: da una singola email di phishing ad amministratore di dominio in sei giorni

Progetto rappresentativo. Dettagli del cliente anonimizzati ed elementi specifici modificati sotto NDA.

Un solo utente ha cliccato su un link un martedì pomeriggio. Entro il lunedì successivo controllavamo il loro Active Directory, avevamo letto l’export delle buste paga e ne avevamo uno screenshot nella nostra cartella del bottino. Nessuno dalla loro parte se ne è accorto fino al quinto giorno.

Questo cliente era orgoglioso del proprio perimetro e, onestamente, aveva ragione di esserlo. VPN irrobustita, EDR su ogni portatile, MFA ovunque. Così, quando ha definito il perimetro di questa valutazione red team, il brief è stato netto: smettete di trattarci come una scansione di vulnerabilità. Trattateci come un avversario che vuole qualcosa di preciso. Partite da zero accessi, arrivate ad amministratore di dominio e vediamo chi se ne accorge.

Ecco il diario, giorno per giorno. I nomi e i numeri sono cambiati. Il percorso è esattamente quello che abbiamo seguito.

Punti chiave

• Una singola credenziale ottenuta con il phishing di solito basta per raggiungere la rete interna. Il perimetro esposto a Internet è raramente ciò che vi salva.
• La strada più rapida verso l’amministratore di dominio non è quasi mai un exploit. Sono configurazioni errate impilate: account con privilegi eccessivi, password di amministratore locale riutilizzate e una delega di Active Directory debole.
• Che un EDR intercetti un payload non è la stessa cosa che il vostro SOC vi risponda. Spesso facciamo molto rumore e restiamo comunque senza risposta per giorni.
• Il Kerberoasting, le credenziali di amministratore locale condivise e le sessioni privilegiate lasciate aperte sono i tre finding che riportiamo in quasi ogni progetto interno.
• Una valutazione red team misura il rilevamento e la risposta, non solo se esiste una falla. È questo a distinguerla da un penetration test standard.

Che cos’è una valutazione red team e perché non fare semplicemente un pentest?

Una valutazione red team è una simulazione guidata da un obiettivo di un attaccante reale, condotta contemporaneamente contro le vostre persone, i vostri processi e la vostra tecnologia. L’obiettivo non è “trovare ogni bug di questa applicazione”. È qualcosa che un criminale vorrebbe davvero: leggere la casella di posta del direttore finanziario, esfiltrare il database dei clienti, mandare in produzione una modifica. Scegliamo un percorso e ci muoviamo verso di esso in silenzio.

Un penetration test risponde a dove sono i buchi. Un red team risponde a cosa succede quando qualcuno ne attraversa uno. Entrambi hanno il loro posto. Ma se avete già svolto qualche pentest e il vostro consiglio di amministrazione si chiede se sopravvivereste a un’intrusione mirata, il pentest ha smesso di essere lo strumento giusto. Vi serve qualcuno che gioca per vincere, con il cronometro in mano, mentre i vostri difensori ignorano i tempi.

Giorno 1: l’email su cui si è cliccato

Non abbiamo inviato a raffica migliaia di messaggi. Il phishing mirato di red team è silenzioso per definizione. Il primo pomeriggio è andato alla ricognizione su fonti aperte: LinkedIn, il blog aziendale, un intervento a una conferenza tenuto da uno dei loro ingegneri, un paio di indirizzi presenti in vecchi data breach. Questo ci ha fornito la convenzione di denominazione delle email ([email protected]) e abbastanza contesto per scrivere qualcosa che un ingegnere indaffarato avrebbe aperto senza pensarci.

Il pretesto era un documento condiviso su una migrazione di strumenti interna, rivolto al team di piattaforma. Non al CEO. Gli ingegneri hanno un accesso più ampio e cliccano su più link. La landing page era un clone impeccabile della loro pagina di accesso Microsoft, servita da un dominio somigliante che avevamo registrato e lasciato invecchiare per due settimane in modo che non sembrasse creato di fresco. L’abbiamo gestita dietro un reverse proxy in stile evilginx, il che significa che abbiamo catturato la password e il cookie di sessione. Quel cookie passa dritto oltre l’MFA.

Due clic nella prima ora. Un accesso completato. Ora avevamo una sessione valida e credenziali valide di un ingegnere di livello intermedio. Si mappa in modo pulito su MITRE ATT&CK T1566 (Phishing) e T1078 (Valid Accounts), ed è da qui che iniziano davvero la maggior parte dei nostri progetti.

Giorno 2: prendere piede e guardarsi intorno

Le credenziali rubate sono una bella cosa. L’esecuzione di codice su un host interno è meglio. Abbiamo cavalcato la sessione fino al loro portale VPN, siamo atterrati in una posizione a bassi privilegi e abbiamo preso piede sulla workstation dell’ingegnere. Questo cambia tutto il gioco. Ora possiamo enumerare il dominio dall’interno.

La nostra prima mossa su qualunque rete interna è una ricognizione silenziosa con BloodHound. Raccogliere i dati di sessione, le ACL e le appartenenze ai gruppi, poi lasciare che il grafo ci dica dove corre il percorso più breve verso l’amministratore di dominio. Non è quasi mai una linea retta. C’è quasi sempre una linea.

# Collect Active Directory data from the foothold (low and slow)
SharpHound.exe --collectionmethods DCOnly,Session --stealth

# Then in the BloodHound UI: mark our compromised user as Owned,
# and run "Shortest Paths to Domain Admins from Owned Principals"

Il grafo si è illuminato. Il nostro ingegnere compromesso faceva parte di un gruppo con diritti di amministratore locale su un cluster di server di build. Quel tipo di gruppo con privilegi eccessivi che nessuno ricorda di aver concesso e che da allora nessuno ha revisionato. Quella è stata la nostra rampa d’accesso.

Giorno 3: Kerberoasting e cracking offline

Qualsiasi utente del dominio può richiedere ticket di servizio Kerberos per gli account che hanno impostato un Service Principal Name. Quei ticket sono cifrati con l’hash della password dell’account di servizio. Quindi li richiedi, li scarichi e li cracchi offline, dove nessuna policy di blocco e nessun alert può raggiungerti. Questo è il Kerberoasting (T1558.003), ed è il trucco più affidabile che abbiamo sulle reti interne.

# Request roastable service tickets with Impacket
GetUserSPNs.py acme-corp.example/j.doe -request -dc-ip 10.10.0.5 -outputfile roast.txt

# Crack offline with Hashcat (mode 13100 = Kerberos TGS-REP)
hashcat -m 13100 roast.txt rockyou.txt -r best64.rule

Un account di servizio craccato in meno di un’ora. La password era Summer2023!, impostata da un essere umano, su un account con una policy senza scadenza e, come si è scoperto, con appartenenza a un gruppo privilegiato. Questo è lo schema ovunque: un account di servizio viene creato una volta, gli vengono concessi più diritti di quelli che gli servono “per sicurezza”, e poi nessuno lo tocca per quattro anni.

Giorno 4: movimento laterale e raccolta di credenziali

Avere l’amministratore locale sui server di build significava che potevamo muoverci lateralmente. Qui siamo stati deliberati. Questa è la fase in cui gli strumenti rumorosi fanno beccare i team, e in cui un SOC competente avrebbe dovuto svegliarsi. Abbiamo evitato di scrivere Mimikatz su disco e abbiamo estratto le credenziali in cache dalla memoria, all’interno del processo, per poi riutilizzare l’hash dell’amministratore locale per autenticarci altrove.

Quella password di amministratore locale era identica su ogni server del segmento. Un hash. Pass-the-hash (T1550.002). Decine di host. Su uno di essi un amministratore aveva lasciato una sessione RDP connessa, e raccogliere quel token ci ha consegnato il contesto di un amministratore di dominio senza mai apprendere la password. Le credenziali di amministratore locale riutilizzate e le sessioni privilegiate dimenticate sono, secondo la nostra esperienza, le due cose che più spesso trasformano un punto d’appoggio circoscritto in una perdita totale.

Giorno 5: amministratore di dominio, e la prima telefonata

Al quinto giorno avevamo in mano un token di amministratore di dominio. Per dimostrare l’impatto senza rompere nulla, abbiamo eseguito un DCSync controllato (T1003.006) per estrarre l’hash dell’account krbtgt, la chiave che consente a un attaccante di forgiare golden ticket e di persistere più o meno per sempre. Non abbiamo costruito il golden ticket in produzione. Abbiamo documentato la capacità e ci siamo fermati lì.

Questo è stato anche il giorno in cui il SOC ha finalmente chiamato il nostro punto di contatto. Il nostro movimento laterale del giorno prima aveva fatto scattare un alert dell’EDR. Il payload è stato segnalato. Ma l’alert è rimasto in coda per buona parte di una giornata prima che qualcuno lo prendesse in carico. La tecnologia ha funzionato. La risposta no. È proprio questo scarto che una valutazione red team esiste per misurare, e che nessuno scanner troverà mai.

Giorno 6: raggiungere l’obiettivo

L’obiettivo concordato era l’accesso a dati finanziari sensibili. Con l’amministratore di dominio, quella parte è stata banale. Abbiamo montato la condivisione di file della finanza, trovato un export delle buste paga e una cartella di PII dei clienti non cifrate, catturato le prove, apposto una marca temporale su tutto e ci siamo ritirati. Nessun dato ha lasciato il loro ambiente. Tempo totale trascorso dal primo clic all’obiettivo: sei giorni, la maggior parte dei quali trascorsi muovendoci lentamente di proposito per verificare se qualcuno stesse guardando.

Cosa abbiamo trovato: le vere cause profonde

Niente di tutto questo ha richiesto uno zero-day. Non era coinvolta neanche una CVE. L’intera catena è stata costruita a partire dalla configurazione e dall’igiene:

• Un MFA che non è sopravvissuto al furto di sessione. Il loro MFA reggeva bene contro il password spraying ed era inutile contro un phishing con reverse proxy che ruba il cookie di sessione. Un MFA resistente al phishing con chiavi hardware FIDO2 spezza la catena il primo giorno.
• Un account di servizio kerberoastabile con una password debole e statica. Un segreto gestito di oltre 25 caratteri, oppure un group Managed Service Account, e smette di essere craccabile.
• Password di amministratore locale condivise. Windows LAPS rende casuale la password di amministratore locale per ogni macchina. Con esso, la nostra scorribanda di pass-the-hash si ferma a esattamente un host.
• Rilevamento senza risposta. L’alert esisteva. Il runbook per agire su di esso in pochi minuti no.

Come di solito viene fermato tutto questo

Ecco la parte scomoda. Spendere di più in strumenti di prevenzione non avrebbe aiutato molto questo cliente. Aveva già buoni strumenti. Ciò che gli mancava era l’igiene di configurazione e un processo di risposta che fosse stato testato sotto pressione. Ruotate e custodite in un vault le credenziali degli account di servizio. Distribuite LAPS. Spostate gli account privilegiati su un MFA resistente al phishing. Suddividete in livelli i vostri account di amministrazione in modo che la compromissione di una workstation non possa raggiungere un token di amministratore di dominio. E soprattutto, eseguite test dal vivo contro il vostro SOC finché un alert non si trasforma in un’azione invece che in una voce in coda.

Come aiuta CyberXplore

Questo è il lavoro che svolgiamo tutto l’anno. Il nostro servizio di valutazione red team conduce simulazioni di avversario guidate da un obiettivo che rispecchiano il modo in cui operano gli intrusi reali: phishing, punto d’appoggio, percorsi di attacco in Active Directory e movimento laterale silenzioso, così scoprite fin dove arriva qualcuno e se il vostro team lo intercetta in tempo. Ricevete una narrazione dell’attacco come quella qui sopra, con ogni passo mappato su MITRE ATT&CK, oltre a una remediation su cui i vostri ingegneri possono agire il lunedì mattina. Se volete sapere come regge il vostro ambiente, richiedete un preventivo e diteci quali sono i vostri gioielli della corona.

FAQ

Quanto dura una valutazione red team?

La maggior parte dei progetti dura dalle tre alle sei settimane dall’inizio alla fine, a seconda del perimetro e di quanta furtività desiderate. L’intrusione attiva di questo diario è durata sei giorni, ma i veri red team spesso si muovono lentamente di proposito per testare il rilevamento nel tempo. Ricognizione, reporting e un workshop di debriefing si aggiungono al calendario.

In cosa una valutazione red team è diversa da un penetration test?

Un penetration test enumera e dimostra le vulnerabilità in un perimetro definito, di solito con i difensori consapevoli che sta avvenendo. Una valutazione red team è guidata da un obiettivo ed è occulta. Mette alla prova insieme persone, processi e rilevamento, e il successo significa raggiungere un traguardo come l’amministratore di dominio o l’esfiltrazione di dati. Se non avete mai svolto un pentest, cominciate da lì. Il red teaming presuppone un ragionevole livello di maturità di base.

Una valutazione red team interromperà i nostri sistemi di produzione?

No. Lavoriamo secondo rigide regole d’ingaggio concordate in anticipo, evitiamo azioni distruttive e ci coordiniamo con un piccolo gruppo fidato dalla vostra parte. I passaggi di prova d’impatto come DCSync vengono eseguiti in modo controllato, e non rimuoviamo mai dati reali dal vostro ambiente. Sicurezza e reversibilità sono scritte nel perimetro.

Dobbiamo dire al nostro team di sicurezza che sta avvenendo?

Di solito solo una piccola “white cell” di stakeholder fidati conosce i tempi, così la risposta del SOC è autentica. È tutto qui il punto. Se i difensori vi stanno aspettando, non imparate nulla sul rilevamento nel mondo reale. Concordiamo in anticipo una parola di sicurezza e i contatti per l’escalation in modo che nessuno insegua un falso allarme fino a farne una crisi.

Cosa otteniamo alla fine?

Una narrazione completa dell’attacco, con ogni passo mappato su MITRE ATT&CK, le prove per ciascun finding, un piano di remediation prioritizzato che i vostri ingegneri possono eseguire, e un debriefing sia per un pubblico tecnico sia per i dirigenti. Il valore non sta nell’elenco dei problemi. Sta nella storia di come si sono concatenati e di cosa spezza la catena.

Con quale frequenza dovremmo svolgerne una?

Ogni anno per la maggior parte delle organizzazioni, oppure dopo un cambiamento importante come una fusione, una migrazione al cloud o l’avvio di un nuovo SOC. Gli ambienti derivano, il personale cambia e le configurazioni errate che ci hanno fatto entrare tendono a reinsinuarsi. Una valutazione red team periodica mantiene oneste la vostra rilevazione e la vostra risposta.