HijackLoader amplia le tecniche di attacco per aumentare l’elusione della difesa

Redazione RHC : 28 Febbraio 2024 16:14

Autori: Donato Onofri e Emanuele Calvelli Endpoint Security & XDR CrowdStrike

CrowdStrike, è una realtà leader nel settore della sicurezza informatica relativamente alla protezione dalle minacce informatiche avanzate e la risposta agli incidenti. Ha da sempre collaborato con Red Hot Cyber, e questo anno ha sponsorizzato la Red Hot Cyber conference 2024 come sponsor Platinum. Non perdetevi lo speech di Donato Onofri, Senior Red Team Engineering di CrowdStrike il 20 di Aprile alla RHC Conference 2024 che si terrà al Teatro Italia di Roma. Lo speech dal titolo “HijackLoader Evolution: Interactive Process Hollowing”, entrerà nel dettaglio di questa nuova minaccia scoperta da CrowdStrike e dettagliata in questo articolo.

• HijackLoader continua a diventare sempre più popolare tra gli avversari per l’installazione di payload e strumenti aggiuntivi
• La versione più recente di HijackLoader impiega tecniche sofisticate per intensificare la sua complessità e aggirare le difese
• CrowdStrike rileva questa nuova variante di HijackLoader utilizzando il machine learning e le capacità di rilevamento basate sul comportamento

I ricercatori di CrowdStrike hanno identificato un modello di HijackLoader (alias IDAT Loader) che impiega tecniche di evasione sofisticate per aumentare la complessità della minaccia.

HijackLoader, uno strumento sempre più popolare tra gli avversari per l’implementazione di payload e strumenti aggiuntivi, continua a evolversi mentre i suoi sviluppatori sperimentano e migliorano le sue capacità.

Grazie alla recente analisi di un campione di HijackLoader, i ricercatori di CrowdStrike hanno scoperto alcune nuove tecniche pensate per aumentare le capacità di elusione dei sistemi di difesa del loader. Lo sviluppatore del malware ha utilizzato una tecnica standard di hollowing dei processi abbinata a un trigger aggiuntivo attivato dalla scrittura del parent process su una pipe. Questo nuovo approccio ha il potenziale per aggirare le difese più silenziosamente.

La seconda variante prevede invece una combinazione insolita di tecniche di doppelgänging e hollowing dei processi. Questa variazione aumenta la complessità dell’analisi e le capacità di elusione della difesa di HijackLoader. I ricercatori hanno anche osservato altre tecniche di sgancio utilizzate per nascondere l’attività del malware.

Questo post è dedicato alle varie tecniche di evasione impiegate da HijackLoader in fasi diverse del malware.

Analisi dell’HijackLoader

Profilo della catena di infezione/trasmissione

Il campione di HijackLoader analizzato da CrowdStrike applica un comportamentocomplesso distribuito in più fasi, dove nella prima fase l’eseguibile (streaming_client.exe) nasconde al suo interno una configurazione utilizzata in parte per la risoluzione dinamica delle API (usando la struttura PEB_LDR_DATA senza l’utilizzo di altre API) per proteggersi dall’analisi statica.

Successivamente, il malware utilizza le API WinHTTP per verificare se il sistema dispone di una connessione Internet attiva collegandosi a https[:]//nginx[.]org.

Se la verifica della connessione ha successo, l’esecuzione continua stabilendo una connessione verso un indirizzo remoto per scaricare il blob di configurazione del secondo livello. Se il primo URL indicato qui di seguito fallisce, il malware prosegue attraverso il percorso seguente:

• https[:]//gcdnb[.]pbrd[.]co/images/62DGoPumeB5P.png?o=1
• https[:]//i[.]imgur[.]com/gyMFSuy.png;
• https[:]//bitbucket[.]org/bugga-oma1/sispa/downloads/574327927.png

Dopo aver ottenuto la configurazione di secondo livello, il malware esamina il buffer scaricato e verifica la presenza dei byte iniziali di un’intestazione in formato PNG. Quindi procede alla ricerca del valore magico C6 A5 79 EA, che precede la chiave XOR (32 B3 21 A5 per questo campione) utilizzata per decriptare il resto del blob di configurazione.

Figure 1. HijackLoader Key Retrieving and Decrypting

Dopo la decodifica XOR, la configurazione viene espletata mediante l’API RtlDecompressBuffer con COMPRESSION_FORMAT_LZNT1. Dopo aver decompresso la configurazione, il malware carica una DLL di Windows legittima, specificata nel blob di configurazione (in questo caso C:\Windows\SysWOW64\mshtml.dll).

Durante la seconda fase, lo shellcode indipendente recuperato dal blob di configurazione viene iscritto nella sezione .text della DLL appena caricata, prima di essere eseguita.

Il codice shell indipendente del secondo stadio di HijackLoader esegue quindi alcune attività di evasione (descritte in dettaglio più avanti) per aggirare gli hook impostati in modalità utente utilizzando Heaven’s Gate, e inietta il successivo codice shell in cmd.exe. L’iniezione del codice shell del terzo stadio avviene tramite una variante del processo di hollowing che inietta una mshtml.dll  nel nuovo processo figlio di cmd.exe appena generato.

Lo shellcode di terza fase esegue un bypass dell’hook in modalità utente prima di iniettare il payload finale (un beacon Cobalt Strike per questo campione) nel processo figlio logagent.exe.  Il meccanismo di iniezione utilizzato dal codice shell di terza fase sfrutta le seguenti tecniche:

• Process Doppelgänging primitivo: questa tecnica viene utilizzata per nascondere una sezione transazionale (mshtml.dll) nel processo remoto per contenere il payload finale.
• Process/DLL Hollowing: questa tecnica viene utilizzata per iniettare lo shellcode del quarto stadio deputato all’evasione, prima di passare all’esecuzione del payload finale all’interno della sezione transattiva del passaggio precedente.

La Figura 2 illustra in dettaglio la strategia di attacco di questa variante di HijackLoader.

Figure 2. HijackLoader — Infection Chain

Principali Tecniche di Evasione Utilizzate da HijackLoader e Shellcode

Le principali tecniche di elusione impiegate da HijackLoader comprendono metodi per bypassare gli hook, come Heaven’s Gate, e svincolarsi rimappando le DLL di sistema monitorate dai sistemi di sicurezza. Inoltre, il malware impiega variazioni del process hollowing assieme a una tecnica di iniezione che sfrutta il transacted hollowing, combinando tecniche di transacted section e process doppelgänging con il DLL hollowing.

Bypass dell’Hook: Heaven’s Gate e Sganciamento

Come altre varianti di HijackLoader, questo modello implementa un bypass dell’hook in modalità utente usando Heaven’s Gate (quando viene eseguito in SysWOW64) – questo è simile alle versioni esistenti (funzione x64_Syscall).

Questa funzionalità di Heaven’s Gate è una tecnica potente che consente di eludere gli hook in modalità utente inseriti in SysWOW64 ntdll.dll chiamando direttamente il comando syscall nella versione x64 di ntdll.

Ogni richiamo a Heaven’s Gate utilizza i seguenti argomenti:

• Il numero della syscall
• Il numero di parametri della syscall
• I parametri (in base alla syscall)

Questa variante di codice shell incorpora un meccanismo aggiuntivo per bypassare gli hook ed eludere quelli in modalità utente che i sistemi di sicurezza possono aver inserito nella ntdll x64. Questi hook sono tipicamente utilizzati per monitorare sia la ntdll x32 che quella x64.

Durante questa fase, il malware rimappa la sezione .text della ntdll x64 utilizzando Heaven’s Gate per chiamare NtWriteVirtualMemory e NtProtectVirtualMemory e sostituire la ntdll mappata in memoria con il .text di una nuova  ntdll letta dal file C:\windows\system32\ntdll.dll. Questa tecnica di svincolo viene utilizzata anche nel processo che ospita il payload finale di Cobalt Strike (logagent.exe) nel tentativo finale di eludere il rilevamento.

Variazione del Process hollowing

Per iniettare il codice shell successivo nel processo figlio cmd.exe, il malware utilizza le tecniche comuni di hollowing dei processi. Ciò comporta la mappatura della DLL legittima di Windows mshtml.dll nel processo di riferimento / target, e quindi la sostituzione della sezione .text con il codice shell. Un ulteriore step necessario per attivare l’esecuzione del codice shell remoto è descritto in dettaglio successivamente.

Per impostare l’hollowing, il modello crea due pipe che vengono utilizzate per reindirizzare lo Standard Input e lo Standard Output del processo figlio (specificato nel citato blob di configurazione – C:\windows\syswow64\cmd.exe), inserendo gli handle delle pipe in una struttura STARTUPINFOW generata con l’API CreateProcessW.

È possibile osservare una netta distinzione tra questa modalità e il tipico process hollowing “standard”: nel process hollowing standard, il processo figlio viene solitamente creato in uno stato di sospensione. In questo caso, invece, il processo figlio non viene creato esplicitamente in uno stato di sospensione, facendolo apparire meno sospetto. Poiché il processo figlio è in attesa di un input dalla pipe creata in precedenza, la sua esecuzione è in attesa di ricevere i dati da quest’ultima.

Di conseguenza, il nuovo cmd.exe appena generato leggerà l’input dalla pipe STDIN, in attesa di nuovi comandi. A questo punto, il suo EIP (Extended Instruction Pointer) è diretto verso il ritorno della syscall NtReadFile.

La sezione seguente illustra i passi compiuti dallo shellcode di secondo livello per impostare il processo figlio cmd.exe, utilizzato per eseguire le successive iniezioni per l’esecuzione del payload finale.

Il processo padre streaming_client.exe avvia una NtDelayExecution per attendere che cmd.exe termini il caricamento. Successivamente, leggerà la DLL legittima di Windows mshtml.dll dal file system e procederà al caricamento di questa libreria in cmd.exe come sezione condivisa.

Ciò avviene utilizzando la tecnica Heaven’s Gate per:

• creare un oggetto sezione condivisa utilizzando NtCreateSection  
• mappare tale sezione nel cmd.exe remoto utilizzando NtMapViewOfSection

Quindi sostituisce la sezione .text della DLL mshtml con uno shellcode dannoso utilizzando:

• Heaven’s Gate per chiamare NtProtectVirtualMemory su cmd.exe per impostare i permessi RWX sulla sezione .text della sezione mshtml.dll precedentemente mappata
• Heaven’s Gate chiama NtWriteVirtualMemory sulla sezione .text della DLL per bloccare il modulo e scrivere lo shellcode di terzo livello.

Infine, per attivare l’esecuzione dello shellcode iniettato in remoto, il malware utilizza:

• Heaven’s Gate per sospendere (NtSuspendThread) il thread remoto principale;
• un nuovo CONTEXT (utilizzando NtGetContextThread e NtSetContextThread) per modificare l’EIP e puntare allo shellcode scritto in precedenza;
• Heaven’s Gate per recuperare (NtResumeThread) il thread remoto principale di cmd.exe

Tuttavia, poiché cmd.exe attende l’input dell’utente dalla pipe STDINPUT, lo shellcode iniettato nel nuovo processo non viene realmente eseguito alla ripresa del thread.

Il loader deve compiere un ulteriore passo:

• il processo padre streaming_client.exe deve scrivere (WriteFile) una stringa \r\n alla pipe STDINPUT creata in precedenza per inviare un input a cmd.exe dopo aver lanciato NtResumeThread. In questo modo si riprende l’esecuzione del thread primario al punto di ingresso dello shellcode nel processo figlio cmd.exe.

Variazione del Threadless Process Hollowing: analisi del processo

Abbiamo replicato con successo la tecnica di threadless process hollowing per capirne l’attivazione tramite pipe. Una volta trascritto lo shellcode come indicato, è necessario attivarlo. L’attivazione avviene nel momento in cui un programma effettua una syscall, mentre il thread attende che il kernel restituisca un valore.

In sostanza, il threadless process hollowing technique prevede le seguenti fasi:

• CreateProcess: questo passaggio prevede la creazione del processo cmd.exe per iniettare il codice dannoso indirizzando STDIN e STDOUT alle pipe. Si noti che questo processo non viene sospeso, il che lo fa apparire meno sospetto. In attesa di leggere l’input dalla pipe, la syscall NtReadFile imposta lo stato del suo thread principale su Waiting e _KWAIT_REASON su Executive, segnalando che è in attesa dell’esecuzione delle operazioni del codice kernel e del loro ritorno.
• WriteProcessMemory: qui viene trascritto lo shellcode all’interno del processo figlio cmd.exe .
• SetThreadContext: in questa fase, il genitore imposta le condizioni per reindirizzare il flusso di esecuzione del processo figlio cmd.exe all’indirizzo dello shellcode scritto in precedenza, modificando l’EIP/RIP  nel thread CONTEXT remoto.
• WriteFile: qui i dati vengono scritti sulla pipe STDIN, inviando un input al processo cmd.exe. Questa azione riprende l’esecuzione del processo figlio dall’operazione NtReadFile, innescando così l’esecuzione dello shellcode. Prima di tornare allo spazio riservato all’utente, il kernel legge e ripristina i valori salvati nella struttura _KTRAP_FRAME  (contenente il valore del registro EIP/RIP) per riprendere dal punto in cui è stata chiamata la syscall. Modificando il CONTEXT nel passaggio precedente, il loader dirotta la ripresa dell’esecuzione verso l’indirizzo dello shellcode senza la necessità di sospendere e riprendere il thread, cosa che questa tecnica solitamente richiede.

Hollowing transazionale² (Sezione transazionale/Doppelgänger + Hollowing)

Il malware trascrive il payload finale nel processo figlio logagent.exe generato dallo shellcode di terzo livello in cmd.exe creando una sezione transazionale da mappare nel processo remoto. Successivamente, il malware inietta lo shellcode del quarto stadio in logagent.ex caricando e inserendo un’altra istanza di mshtml.dll nel processo target. Una volta iniettato, lo shellcode di quarta fase esegue la tecnica per bypassare gli hook precedentemente menzionata, prima di eseguire il payload finale allocato preventivamente dalla sezione transazionale.

Hollowing della Sezione Transazionale

Similmente alla duplicazione (doppelgänging) dei processi, l’obiettivo di una sezione transazionale è quello di creare una sezione maligna furtiva all’interno di un processo remoto sovrascrivendo la memoria del processo legittimo con una transazione.

In questo caso, lo shellcode di terza fase eseguito all’interno di cmd.exe colloca una sezione transazionale dannosa utilizzata per ospitare il payload finale nel processo figlio logagent.exe. Lo shellcode utilizza il seguente metodo:

• NtCreateTransaction per creare una transazione
• RtlSetCurrentTransaction e CreateFileW con un nome di file fittizio per sostituire il documentato CreateFileTransactedW
• Heaven’s Gate per richiamare NtWriteFile in un ciclo, scrivendo lo shellcode finale sul file in pezzi da 1.024 byte.
• Creazione di una sezione supportata da quel file (Heaven’s Gate chiama NtCreateSection)
• Rollback della sezione creata precedentemente utilizzando Heaven’s Gate per chiamare NtRollbackTransaction.

Le implementazioni simili esistenti sono state osservate pubblicamente in questo progetto che implementa l’hollowing delle transazioni.

Una volta creata la sezione transazionale, lo shellcode genera uno stub di funzione in fase di esecuzione per nascondersi dall’analisi statica. Questo stub contiene una chiamata all’API CreateProcessW  per generare un processo figlio sospeso  logagent.exe (c50bffbef786eb689358c63fc0585792d174c5e281499f12035afa1ce2ce19c8), precedentemente abbandonato da cmd.exe nella cartella %TEMP%.

Dopo la creazione del processo target, questo modello utilizza Heaven’s Gate per:

• Leggere il suo PEB chiamando NtReadVirtualMemory per recuperare il suo indirizzo di base (0x400000).
• Sbloccare l’immagine logagent.exe nel processo logagent.exe utilizzando NtUnMapViewofSection
• Svuotare la sezione transazionale creata in precedenza all’interno del processo remoto rimappando la sezione allo stesso indirizzo di base (0x400000) con NtMapViewofSection

Process Hollowing

Dopo che lo shellcode del terzo stadio all’interno di cmd.exe inietta il payload finale di Cobalt Strike all’interno della sezione transazionale del processo logagent.exe , continua a svuotare il processo di destinazione per scrivere il quarto stadio dello shellcode, utilizzato infine per eseguire il payload finale (caricato nella sezione transazionale) nel processo remoto. Lo shellcode di terza fase mappa la DLL legittima di Windows C:\Windows\SysWOW64\mshtml.dll nel processo di destinazione prima di sostituire il suo .text con il codice shell di quarta fase ed eseguirlo tramite NtResumeThread.

Questo shellcode aggiuntivo di quarta fase scritto in logagent.exe esegue attività di evasione simili allo shellcode di terza fase eseguito in cmd.exe (come indicato nella sezione di bypass dell’hook) prima di passare l’esecuzione al payload finale.

Copertura Falcon

CrowdStrike impiega un approccio su più livelli per il rilevamento delle minacce informatiche utilizzando il machine learning e gli indicatori di attacco (IOA). Come illustrato nella Figura 3, le capacità di apprendimento automatico del sensore CrowdStrike Falcon® sono in grado di rilevare e prevenire automaticamente HijackLoader nelle fasi iniziali della catena di attacco, ossia non appena il malware viene scaricato sul computer della vittima. Le capacità di rilevazione basate sul comportamento (IOA) sono in grado di riconoscere il comportamento dannoso in varie fasi della catena di attacco, anche quando si utilizzano tattiche come i tentativi di iniezione di processi.

Figure 3. CrowdStrike Falcon Platform Machine Learning and IOA Coverage for the HijackLoader Sample

Indicators of Compromise (IOCs)

File	SHA256
streaming_client.exe	6f345b9fda1ceb9fe4cf58b33337bb9f820550ba08ae07c782c2e142f7323748

La seguente tabella mappa le tattiche, le tecniche e le procedure (TTP) di HijackLoader riportate al framework MITRE ATT&CK®.

ID	Technique	Description
T1204.002	User Execution: Malicious File	The sample is a backdoored version of streaming_client.exe, with the Entry Point redirected to a malicious stub.
T1027.007	Obfuscated Files or Information: Dynamic API Resolution	HijackLoader and its stages hide some of the important imports from the IAT by dynamically retrieving kernel32 and ntdll API addresses. It does this by parsing PEB->PEB_LDR_DATA  and retrieving the function addresses.
T1016.001	System Network Configuration Discovery: Internet Connection Discovery	This variant of HijackLoader connects to a remote server to check if the machine is connected to the internet by using the  WinHttp API (WinHttpOpenRequest and WinHttpSendRequest).
T1140	Deobfuscate/Decode Files or Information	HijackLoader utilizes XOR mechanisms to decrypt the downloaded stage.
T1140	Deobfuscate/Decode Files or Information	HijackLoader utilizes RtlDecompressBuffer to LZ decompress the downloaded stage.
T1027	Obfuscated Files or Information	HijackLoader drops XOR encrypted files to the %APPDATA% subfolders to store the downloaded stages.
T1620	Reflective Code Loading	HijackLoader reflectively loads the downloaded shellcode in the running process by loading and stomping the mshtml.dll module using the LoadLibraryW and VirtualProtect APIs.
T1106	Native API	HijackLoader uses direct syscalls and the following APIs to perform bypasses and injections: WriteFileW, ReadFile, CreateFileW, LoadLibraryW, GetProcAddress, NtDelayExecution, RtlDecompressBuffer, CreateProcessW, GetModuleHandleW, CopyFileW, VirtualProtect, NtProtectVirtualMemory, NtWriteVirtualMemory, NtResumeThread, NtSuspendThread, NtGetContextThread, NtSetContextThread, NtCreateTransaction, RtlSetCurrentTransaction, NtRollbackTransaction, NtCreateSection, NtMapViewOfSection, NtUnMapViewOfSection, NtWriteFile, NtReadFile, NtCreateFile and CreatePipe.
T1562.001	Impair Defenses: Disable or Modify Tools	HijackLoader and its stages use Heaven’s Gate and remap x64 ntdll to bypass user space hooks.
T1055.012	Process Injection: Process Hollowing	HijackLoader and its stages implement a process hollowing technique variation to inject in cmd.exe and logagent.exe.
T1055.013	Process Injection: Process Doppelgänging	The HijackLoader shellcode implements a process doppelgänging technique variation (transacted section hollowing) to load the final stage in logagent.exe.