APT34 torna con un arsenale aggiornato

Check Point, storico partner di Euro Informatica, ha scoperto le prove di una nuova campagna del gruppo di hacker iraniano APT34 (aka OilRig), contro quello che sembra essere un obiettivo libanese, utilizzando una nuova variante backdoor chiamata SideTwist.

APT34 torna con un arsenale aggiornato

Check Point, storico partner di Euro Informatica, ha scoperto le prove di una nuova campagna del gruppo di hacker iraniano APT34 (aka OilRig), contro quello che sembra essere un obiettivo libanese, utilizzando una nuova variante backdoor chiamata SideTwist.

Dal leak degli strumenti di APT34 nel 2019 da parte di “Lab Dookhtegan”, il gruppo di hacker ha attivamente riorganizzato e aggiornato il proprio arsenale di payload per cercare di evitare il rilevamento, creando diverse varianti di malware il cui scopo finale è rimasto lo stesso: ottenere il punto d’appoggio sul dispositivo mirato.

A partire dalla campagna DNSpionage nel 2018, APT34 è stato osservato per l’uso di documenti contenenti malware inviati tramite messaggi LinkedIn ad utenti alla ricerca di un lavoro. Questa attività è proseguita fino al 2019 con l’operazione HardPass , in cui la piattaforma LinkedIn è stata utilizzata allo stesso modo.

Nell’ultima campagna di gennaio un file presentato a VirusTotal dal Libano (un obiettivo comune per APT34) contiene anche uno di questi documenti.

Nel seguente articolo analizziamo l’ultima catena di infezioni utilizzata dagli aggressori e approfondiamo la nuova variante di malware.

Analisi Iniziale

L’analisi è iniziata con un documento Microsoft Word chiamato come l’offerta di lavoro.

Fig 1: documento con macro dannose

Il documento esca cerca chiaramente di apparire come un documento normale, offrendo varie posizioni nella società di consulenza IT di Ntiva, una società con sede in Virginia, negli Stati Uniti.

Tuttavia, una volta che l’utente attiva le macro incorporate (ovviamente dannose), viene attivato l’intero flusso di infezione:

Fig 2: Flusso del malware

Primo passo: Macro dannose con DNS tunneling

Le macro utilizzate da APT34 si sono evolute nel corso degli anni, ma mantengono sempre il proprio stile e i tratti distintivi:

  • Verifica della presenza di un mouse connesso al PC (tecnica Anti-Sandboxing).
  • Impronta digitale iniziale del dispositivo di destinazione e invio delle informazioni al server C2.
  • Rilascio dell’eseguibile incorporato su disco con estensione “doc” (che in seguito verrà rinominato in “.exe”).
  • Registrazione di un’attività di pianificazione di Windows che avvii l’eseguibile ogni X minuti.

Fig 3: Le funzioni VBA chiamano il grafico generato da Vba2Graph

Nella funzione macro delle chiamate possiamo vedere che dalle funzioni Document_Open e Document_Close sono presenti più chiamate alla funzione esterna DnsQuery.

APT34 è noto per il suo uso intensivo del DNS tunneling attraverso molti dei loro diversi strumenti, e questa volta questa funzione si è fatta strada anche nella fase iniziale delle macro.

Una volta eseguite le macro, le richieste DNS vengono utilizzate per tornare all’attaccante e informarlo sulla fase corrente dell’esecuzione, nonché per fornire alcune informazioni identificabili della vittima.

Fig 4: frammento di macro dannose, responsabile dell’invio di query DNS

In questa fase, l’aggressore utilizza il servizio DNS tunneling requestbin.net disponibile pubblicamente, al fine di ottenere aggiornamenti sull’avanzamento dell’infezione delle macro. In questo modo l’infrastruttura di proprietà dell’aggressore non è esposta.

Di seguito è riportata una dimostrazione delle informazioni che l’attaccante vedrebbe sul sito requestbin.net, dopo che una vittima esegue le macro dannose:

  • Nome utente: John
  • Nome host: John-pc

Fig 5: Le richieste di macro visualizzate su “requesbin.net”, con indirizzo IP di origine e timestamp oscurati

I dati codificati sono derivati ​​dalle informazioni del PC, nel modo seguente:

Fig 6: dati DNS codificati

Secondo passo: Payload SideTwist

La backdoor in questa fase è una variante che non abbiamo mai visto nelle precedenti operazioni di APT34, ma fornisce funzionalità semplici e simili ad altre backdoor utilizzate dal gruppo: DNSpionage e TONEDEAF e TONEDEAF2.0 .

La funzionalità della backdoor include il download, l’upload e l’esecuzione dei comandi della shell.

Terzo passo: Persistence

In questa catena la permanenza del malware viene effettivamente stabilita già nelle prime due fasi e non ha un meccanismo di persistenza vera e propria.

L’attività pianificata denominata SystemFailureReporter eseguirà il payload ogni 5 minuti:

Fig 7: attività pianificata su una macchina infetta

La backdoor dipende molto da questo meccanismo, perchè ogni volta che si avvia, esegue solo un singolo comando fornito dal server e si spegne immediatamente, fino a quando non viene riavviato dalla scheduled task.

Inizializzazione

La backdoor inizia raccogliendo le informazioni di base sulla macchina della vittima e calcolando un identificatore della vittima lungo 4 byte, basato sul nome utente, sul nome del computer e sul nome di dominio dell’ambiente di destinazione. Questo identificatore verrà utilizzato nella comunicazione C&C follow-up.

Fig 8: codice per raccogliere informazioni identificabili

Subito dopo il malware verificherà che il file update.xml non esista davvero e, in caso contrario, si arresterà stampando a video il debug utilizzando la funzione OutputDebugString:

“Installa visual studio 2017 e riprova”

Fig 9: Codice per verificare che la prima fase sia stata eseguita

Poiché lo scopo di questa funzione è stampare le informazioni di debug il testo non sarà visibile all’utente normale.

La backdoor

La comunicazione della backdoor con il server C&C  (sarmsoftware[.]com) è HTTP basata sulla porta 443 con la porta 80 come fallback.

La backdoor utilizza due diverse tecniche per le comunicazioni in uscita ed in entrata con il server C&C, anche se in entrambi i casi viene utilizzato lo stesso algoritmo di crittografia.

Richiesta di comando

La backdoor contatta il server C&C nel seguente URL utilizzando una richiesta GET:

sarmsoftware[.]com/search/{identifier}

Fig 10: falsa pagina Flickr

La risposta a questa richiesta è nascosta nel codice sorgente della seguente pagina sosia di Flickr:

La risposta viene restituita alla backdoor all’interno del codice HTML, nel seguente formato:

/*Encrypted_Message_Encoded_with_Base64*/

Fig 11: comandi C&C incorporati nel codice

Dopo che questa stringa base64 è stata decodificata e decrittografata , il contenuto di testo normale è nel seguente formato separato da pipe:

Fig 12: formato dei dati crittografati

  • Numero di comando : un numero di indice in esecuzione per tenere traccia dei comandi eseguiti. Se impostato su un numero diverso da -1, la backdoor dovrebbe procedere all’esecuzione del comando, in base all’ID comando. Altrimenti, ignora e termina.
  • ID comando: può essere uno dei seguenti comandi:
    • 101 – Shell Command: esegue il comando Shell allegato {Arg1}nell’argomento.
    • 102 – Scarica file: scarica un file che può essere trovato nel {Arg2}percorso sul server e lo salva su disco con il {Arg1}nome.
    • 103 – Carica file: carica un file locale {Arg1}sul server.
    • 104 – Shell Command (duplicate): esegue il comando Shell allegato {Arg1}nell’argomento.

Comunicazione dei risultati

Dopo che la backdoor ha eseguito un comando arbitrario sulla macchina della vittima, restituisce il risultato del comando eseguito al server, allo stesso URL di prima, ma in una richiesta POST invece di un GET:

sarmsoftware[.]com/search/{identifier}

Il formato del POST è un semplice JSON, basato sul numero di comando fornito dal server C&C e sul risultato crittografato dell’esecuzione del comando:

Fig 13: formato dei dati dei risultati

Crittografia delle comunicazioni

Come base per la comunicazione crittografata, gli aggressori utilizzano il generatore Mersenne Twister.

I primi 4 byte di ogni messaggio crittografato sono il seme per il Mersenne Twister, da utilizzare per la decrittazione del resto del messaggio.

La comunicazione Base64 crittografata può essere decrittografata utilizzando il seguente frammento di Python:


def decode(msg):
bs=base64.b64decode(msg)
seed=int.from_bytes(bs[:4],byteorder='big')
rng = mersenne_rng(seed)
k=rng.get_random_number()
key=int.to_bytes(k,length=4,byteorder='little')
dec="".join([chr(bs[i]^key[(i-4)%4]) for i in range(4,len(bs))])
return dec

Attribuzione

Entrambe le macro dannose, la backdoor, il targeting e le tecniche utilizzate in questa operazione, sono tutte in linea con le campagne segnalate in precedenza e attribuite ad APT34.

Il documento

Oltre al fatto che, come nelle precedenti operazioni APT34, ancora una volta vediamo l’utilizzo di documenti di offerte di lavoro per incoraggiare la vittima ad abilitare le macro, ci sono anche delle somiglianze tecniche.

  • Lo stesso nome di variabile beacher era presente nella vecchia campagna DNSpionage:

Fig 14: nome di variabile nel vecchio codice delle macro

  • La funzionalità principale delle macro è rimasta la stessa di una precedente campagna APT34 : le macro dannose utilizzano la funzione MouseAvailable per l’evasione e creano un’attività pianificata per eseguire un payload incorporato nel documento.

Somiglianza di comunicazione C&C

È noto che le backdoor di APT34 DNSpionage e TONEDEAF ricevono comandi dai server cercando pattern specifici nascosti all’interno del contenuto HTML di un sito Web dall’aspetto legittimo.

Nel nostro caso gli aggressori hanno utilizzato una pagina sosia di Flickr, mentre nelle campagne precedenti sono stati utilizzati sosia GitHub , Wikipedia e Microsoft .

Ulteriori malware APT34

Durante l’analisi della campagna, oltre a questo sono stati caricati altri documenti relativi ad APT34 e annotati dai ricercatori di malware su Twitter .

Questi documenti utilizzavano lo stesso requestbin.netcome servizio di DNS tunneling nelle macro iniziali e fornivano un altro degli strumenti di firma del gruppo: una variante della backdoor basata su .NET chiamata Karkoff, che utilizzava server di scambio rivolti a Internet come metodo di comunicazione con gli aggressori.

I documenti ritrovati sottolineano la portata delle operazioni dell’APT34 contro obiettivi in ​​Medio Oriente, e specialmente in Libano:

Karkoff (MD5: ab25014c3d6f77ec5880c8f9728be968) includeva le credenziali per un server di scambio appartenente al governo libanese ( mail.army.gov[.]lb), che potrebbero essere un’indicazione di una lunga compromissione della loro rete.

Conclusione

L’APT34 appoggiato dall’Iran non mostra alcun segno di rallentamento, spingendosi ulteriormente in Medio Oriente, con un focus costante sul Libano, utilizzando operazioni informatiche offensive.

Pur mantenendo il suo modus operandi e riutilizzando le vecchie tecniche, come esaminato sopra, il gruppo continua a creare strumenti nuovi e aggiornati per ridurre al minimo il possibile rilevamento dei propri strumenti da parte dei fornitori di sicurezza.

In questa pubblicazione abbiamo analizzato la più recente variante backdoor implementata dalle campagne di offerte di lavoro in corso, una tecnica che hanno impiegato con successo almeno dal 2018.

Cyberteam in collaborazione con Check Point protegge da questo attacco APT e lo previene fin dai primi passi.

Comments are closed.