~/bad_june.dat

Il 9 Giugno 2021, alle ore 01:58 CEST, l’azienda per la quale lavoro ha subito il fermo dei servizi più clamoroso dalla sua nascita.

10 Giugno, circa 06:45 CEST

Sono ancora a casa, mezzo addormentanto e in attesa che la tazza di caffè americano che ho appena tracannato entri in circolo.
Come di consueto apro le email per leggere l’esito dei backup serali, scremare qualche email di poca importanza e consulare il calendario delle attività quotidiane.
Qualcosa non mi tornava: visivamente, la prima cosa che mi colpisce è il numeratore delle mail da leggere: oltre 100.000, tutte da parte dell’antivirus.

Result: Virus successfully detected, cannot perform the Clean action

Scorro velocemente le mail a campione, tutte uguali, riportano solo host diversi.
Fra le varie email di segnalazione anche quelle da parte di colleghi del turno serale i quali notificano che – tutto d’un tratto – non si riescono più a collegare ai server remoti: le linee di produzione sono bloccate, gli ordini non entrano a sistema, i robot nei magazzini di oltre 6 paesi nel mondo sono immobili. Il “sistema” è fermo, tutto tace.

Arrivo in ufficio intorno le 07:30, il tempo di rendermi presentabile e mettermi in auto. Ancora l’utenza deve entrare, il dubbio che non sarà una giornata facile ormai è diventato una consapevolezza quando entrando la portineria ha dovuto innalzare la sbarra a mano in quanto “i sistemi non rispondono”. Camminando per entrare in ufficio, scorgo dal corridoio una serie infinita di computer con un BSOD.
Se l’inferno informatico ha un volto, credo sia questo.

Collego il laptop e inizio l’analisi.
Praticamente tutto ciò che è Windows è stato compromesso, siamo stati vittima di un attacco hacker ben congeniato. Tutti i server sono stati abilmente criptati.
Le NAS hanno avuto la peggio, formattate, con i volumi cancellati a basso livello. Più avanti la notizia che non sarà possibile recuperare alcun dato.

La gestione dell’incidente

Per quanto è ben chiaro nella mia mente cosa è successo nelle 12 giornate seguenti, l’idea di questo thread è quello di analizzare non solo i fatti accaduti ma anche – e sopratutto – come sono state gestite le risorse in un momento così critico. Ovviamente scrivere questa pagina non ha lo scopo di insegnare niente a nessuno, vorrei anche solo sperare che almeno una persona lo legga e capisca cosa ho fatto io (errori e non) e che ne faccia tesoro se mai si dovesse trovare a fronteggiare una crisi come quella che ho dovuto coordinare io. E’ bene tenere a mente che il caos ha regnato sovrano e nella confusione, senza un piano ben studiato “a bocce ferme”, i tempi di fermo si possono dilungare esponenzialmente.
Pertanto, la prima cosa da fare è essere onesti: vi hanno colpito e affondato.

Non perdete tempo ad accusare il collega che non ha fatto bene il suo lavoro, a sottolineare quanto il management sia stato sordo alle vostre richieste di budget e non accusatevi di nulla.
Se non siete nel mood giusto, fate come ho fatto io: ho staccato il telefono, sono andato a prendermi un caffè e – una volta calmo – mi sono messo a sedere.
La parola d’ordine che accompagnerà tutto il vostro lavoro sarà: CALMA.

La prima domanda da porsi è: cos’è stato compromesso? Qual’è il perimetro impattato? Ricordatevi che nessuno meglio di voi conosce i sistemi che amministrate pertanto prendetevi il vostro tempo e analizzateli uno ad uno.
Personalmente, non appena ho capito che tutte le VM Windows erano state compromesse, ho deciso di bloccare tutto il traffico in ingresso e in uscita da e verso il data center: disconnesse tutte le sedi in MPLS, disabilitati tutti i tunnel IPSec, chiuso tutto il traffico da e verso internet ed infine ho disabilitato tutte le schede di rete dall’hypervisor così che le macchine non parlassero più neanche sulla stessa subnet.
In pratica avevo bisogno che tutto “tacesse” sulla rete.
Successivamente ho creato un nuovo segmento di rete sul vCloud e l’ho collegato al virtual firewall e su quest’ultimo ho creato solo una regola che permettesse tutto il traffico da questa nuova LAN alla sola WAN.
Visto che la prima segnalazione dell’AV era datata intorno le 02:00AM, su questo segmento di rete, ho eseguito il primo restore dal backup offsite del giorno 09/10 dato che le VM completano i salvataggi non oltre la mezzanotte. Il server che ho deciso di ripristinare è il primo domain controller.

La prima analisi

Per prima cosa ho deciso di analizzare il traffico di rete, andando a sniffare tutto il traffico in uscita. Impostata la regola sul firewall, l’ho lanciata e messa in ascolto di modo che loggasse su un server remoto (previa generazione di una chiave di crittografia e regola di inbound traffic sul sito ricevente). Non che mi interessasse individuare il (o i) C2, ma sicuramente se ci fossero state altre investigazioni future da parte delle autorità competenti, questi dati sarebbero stati di aiuto.

Come immaginavo il DC restorato non presentava file criptati, certo è che quel server fosse compromesso.
Ho scaricato tutti gli eventi presenti in memoria dall’event viewer e mi sono concentrato sugli eventi 4624 (logon OK), 4625 (logon failed) e 4634 (account logoff).
La prima cosa che saltava all’occhio erano una serie di eventi 4624 e 4634 in orari notturni da parte dell’utente “administrator”, pertanto ho continuato l’analisi a ritroso per vedere quando questi eventi hanno avuto inizio.
Ahimè la fortuna non è stata dalla mia parte, gli eventi registrati saturavano il buffer e i log andavano indietro solo di qualche giorno ad indicare che l’attaccante era da un po’ di tempo dentro la nostra rete. Inoltre, giusto per aggravare la situazione, i logon erano originati server diversi.

Facciamo un passo indietro per capire come funziona un attacco mirato, diciamo che è composto generalmente da 5 fasi (tralasciando le fasi legate al ransomware):

• Fase 1: analisi del perimetro esterno in cerca di servizi con vulnerabilità note
• Fase 2: exploit della/e vulnerabilità trovate
• Fase 3: installazione backdoor sul primo host compromesso
• Fase 4: privilege escalation
• Fase 5: lateral moving

La mia idea era quella di capire quando l’attacco ebbe origine (punto 3) così da individuare il primo restore point “buono”.
Sfortunatamente, non avendo ai tempi un log collector, sono stato costretto a restorare sistematicamente la stessa VM a ritroso e a fare il lavoro a mano. Potete immaginare il tempo che ha richiesto fare un’analisi del genere.

Il restore point del 15 Maggio ha finalmente evidenziato quando l’attacco ebbe origine.
Una serie consistente di eventi 4625 intorno le 03:00 AM da una sola VM remota: un’applicazione web basata su un vecchio server 2012. L’analisi quindi si è spostata su questo server, pertanto sono andato a restorare l’immagine del 14 Maggio nella speranza che i tentativi di exploit non fossero precedenti.

La causa

Il 14 Maggio intorno le ore 11PM siamo stati colpiti e affondati.
Un’applicazione web remota, poco utilizzata (e quindi caduta nel dimenticatoio) è stata l’origine dei nostri mali.
L’attaccante, sfruttando una vulnerabilità nota di un componente web installato (e mai patchato), è riuscito a inoculare ed eseguire il primo beacon. Più avanti scoprii che servii all’attaccante il tappeto rosso dal momento che questa vulnerabilità permetteva una RCE senza autenticazione. Vergogna su di me, ma non siamo qui per auto commiserarci.
A questo punto abbiamo due date: il 14 Maggio il gruppo ha avuto accesso alla rete mediante l’exploit; il 10 Giugno, terminata la fase di ricognizione, ha sferrato il ransomware indisturbato.
Praticamente hanno avuto un mese di tempo per analizzare tutta la superficie da colpire, esfiliare tutti i dati ed infine lanciare l’attacco vero e proprio.

Le azioni per la ripartenza

Come ho scritto prima, individuata la timeline dell’evento, si è proceduto così:

• ripristino di tutti i server al restore point del 14 Maggio
• ripristino di tutti i dati dei database server al 09 Giugno
• restore dei DC al 14 Maggio per recuperare i ruoli
  • rigenerazione del golden ticket
  • cambio di tutte le password amministrative
  • creazione di nuovi DC per trasferire i ruoli
  • depromozione dei vecchi DC
  • rigenerazione per la seconda volta del golden ticket
  • cambio per la seconda volta di tutte le password amministrative
• ri-abilitato le regole di traffico per la raggiungibilità infra-sede
• re-installazione di oltre 200 PC client compromessi

In numeri:
– 1 analista e coordinatore del team 
– 5 persone fornitori esterni che restoravano le VM
– 3 colleghi a supporto per re-installare tutti i PC
– 12 giorni consecutivi da 18 ore di lavoro
– innumerevoli caffè per stare svegli 

Considerazioni finali sull’accaduto, azioni sul breve e lungo periodo e gestione delle risorse

Non tutti i mali vengono per nuocere.
Nel mio caso l’azienda ha capito nella maniera più dolorosa che la cybersecurity è una priorità e come tale deve essere trattata, indipendentemente dal proprio core business; d’altro canto io ho imparato a gestire le emozioni mie e quelle dei miei collaboratori.

Lavorare per 18 ore serrate al giorno è stressante. E lo stress – tuo e quello degli altri – fa commettere errori.
Per lenire lo stress ho diviso il team in micro gruppi e dato loro dei piccoli compiti da svolgere e a questi “task” ho dato delle timeline indicative.
Terminate le timeline facevo il punto con i gruppi di lavoro con l’intento di capire se avessero terminato il task assegnato: se non mi riportavano anomalie, allora dividevo il gruppo sparpagliando i singoli membri in altri gruppi dove invece mi segnalavano problemi.
Tenevo costantemente aggiornato un diario delle attività effettuate, dei task assegnati, i nominativi delle persone del gruppo che l’avevano in carico e i nomi delle persone: volevo evitare che due persone che “non si prendevano bene” lavorassero insieme.
La sera alle 20:30, cascasse il mondo, si andava sempre al ristorante a mangiare tutti assieme e pregavo tutti di non parlare di lavoro!

Ha funzionato.
Con difficoltà, ma ha funzionato!

Infine, alla luce di quanto accaduto sono state finalmente approvate quelle manovre correttive a breve e a lungo termine che – con fatica – ho cercato negli anni di far approvare. Inoltre, taluni accorgimenti, sono stati frutto di una collaborazione stretta con fornitori esterni che mi hanno aiutato moltissimo a capire le dinamiche dell’incidente e le manovre correttive per innalzare il livello di sicurezza generale.
Di seguito un elenco che spero anche a voi possa venir utile.

• limitare al massimo la superficie esposta a internet, privilegiando gli accessi VPN dove possibile e filtrando gli indirizzi sorgente
• abilitazione di un servizio di WAF per i siti esposti
• limitare l’accesso a internet dei server ai soli servizi necessari
• implementazione di un backup offsite per tutti i server
• aggiornamento periodico di tutti i sistemi operativi client e server
• MFA per accessi VPN e servizi core
• sanificazione delle password (cambio periodico) su tutti i servizi gestiti
• installazione di un EDR su tutti i client e server
• segmentazione e microsegmentazione di tutti i siti perferici oltre che delle reti del data center
• implementazione di protocolli di analisi quali DPI/IPS/IDS
• implementazione di un SIEM per la raccolta, l’aggregazione e la correlazione di tutti i log (SO, router, switch, firewall, etc)
• implementazione di un servizio SOC h24 7/7 per il monitoraggio degli eventi aggregati
• creare un recovery plan e mantenerlo aggiornato

EOF