Formbook è uno dei malware più diffusi in Italia. Abbiamo individuato una campagna di phishing che ne usa una vecchia versione
Formbook: la campagna analizzata dai Seqrite Lab
Recentemente abbiamo individuato una campagna di phishing che distribuisce il malware per il furto password Formbook. Questo malware è piuttosto noto anche in Italia ed è stato tra i più diffusi nel nostro paese nel corso del 2024. In diffusione fin dal 2016, ha subìto molte evoluzioni, in particolare nelle tecniche di elusione dei controlli delle soluzioni di sicurezza.
Formbook è in vendita in noti forum di hacking come malware as a service (MaaS), come possiamo desumere dalle molteplici varianti in circolazione. Se le tecniche di elusione restano le stesse, le analisi hanno mostrato l’uso di diversi livelli prima di distribuire il payload. Tutti i file necessari al download del payload sono caricati direttamente in memoria, proprio per ridurre il rischio di individuazione del malware.
Molte varianti, inoltre, utilizzano la steganografia per nascondere file dannosi entro le immagini, decriptandoli poi per caricarli e richiamarli in memoria.
La variante analizzata in questo caso usa tre fasi prima del payload finale:
- Purchase Order.exe/XXXI.exe
- Arthur.dll
- Montero.dll
- MASM(Final Payload)
Analisi tecnica della campagna Formbook
L’attacco inizia con una email di phishing, quasi sempre di spear phishing. Apparentemente la mail rimanda ad un ordine e reca in allegato un file ZIP. Il contenuto estratto è un file singolo, PurchaseOrder.exe. È un file binario compilato in .NET.
Stage 1: (Purchase Order.exe)
Questa variante nasconde la fase 2 e 3 del malware nelle risorse del file Purchase Order.exe. La risorsa “Hkyl”, come si vede nella figura 2, è il binario della fase 3. Inizialmente il malware resta “dormiente” per 9 secondi, prima di procedere alla decriptazione della fase 2 del payload. Come si vede nella figura 3, recupera i dati criptati della fase 2 dalla risorsa APP presente in Purchase Order.exe. Vengono memorizzati anche, tra le altre cose, 16 byte di chiave di decriptazione per il payload della fase 2 (AP7H9H5OI4478F8CH05FGA).
Prima di decriptare il payload di 2 fase, come si vede in figura 4, crea un 3° array di 256 bite e lo inizializza con un valore da 0 a 255.
Successivamente imposta l’array 3 copiando la chiave da 16 byte in posizione casuale.
Una volta che l’array3 è configurato, il malware esegue un’operazione di XOR sui dati criptati con array3 e salva i risultati nell’array2, che ora contiene il file PE della fase 2, arthur.dll.
Per eseguire il file DLL della fase 2, utilizza InvokeMember() per caricare l’assembly decriptato (Arthur.dll) in memoria tramite il metodo Load. Come mostrato nella Figura 5, non utilizza direttamente la funzione Load, ma ottiene il valore da un oggetto, il cui valore di HJ è Load.
Stage 2 (Arthur.dll)
Una volta caricato in memoria, richiama MainForm.Justy() fal file PE di fase 2 con tre argomenti. Usa quindi questi argomenti nel file PE di fase 2 per ottenere il file PE di fase 3.
Il file PE di fase 2 è offuscato con SmartAssembly. Come mostrato nell’immagine sopra, ci sono tre argomenti per questo metodo:
- WA = “486B796C”=Hkyl (risorsa in PurchaseOrder.exe, Fig 2)
- WZ = “62616F”=bao (chiave di decriptazione per lo stage 3)
- @namespace = “AssessExampleCombatForm”[nome del progetto di PurchaseOrder.exe]
Lo stage 2 resta dormiente per 14 secondi prima di procedere alla decriptazione della fase 3. Questa funzione decripta un’immagine usando una chiave passata come argomento, quindi estrae i valori rossi, verdi e blu da ogni pixel non trasparente nell’immagine. Crea quindi un array.
E’ da questo array che viene ricavato montero.dll, caricato poi subito in memoria con il metodo Assembly.Load. Il malware lo richiama dopo aver ottenuto il metodo principale gnWmyvSdDoAS8VNPBy.ukHjJHqoK1() dal modulo della fase 3.
Stage 3: (montero.dll)
Nel file PE della fase 3, prima di invocare il metodo principale ukHjJHqoK1(), il suo costruttore decripta le impostazioni di configurazione necessarie. Queste impostazioni contengono la chiave di decriptazione per il payload finale, il nome del mutex e se il mutex è abilitato, la posizione dove scaricare il file, il comportamento del download del file e altro. Queste configurazioni vengono memorizzate nell’array [gnWmyvSdDoAS8VNPBy.YiEuqBAod0].
Dopo aver decriptato le impostazioni di configurazione, il malware verifica se il flag Mutex è abilitato (nella 29ª posizione dell’array YiEuqBAod0). Se vero, crea un mutex con il nome “zpkpGXyWHvBpdzNULuLRtAzq”. Se il mutex è già presente, il malware si termina. Questa tecnica è implementata per evitare il rilevamento da parte dei fornitori di sicurezza e per impedire che venga eseguita una seconda istanza dello stesso malware.
Successivamente, verifica se è abilitato il flag per la visualizzazione di una finestra di messaggio (nella 30ª posizione dell’array YiEuqBAod0). Se abilitato, viene visualizzato un pop-up per ingannare l’utente.
Dopo di che, verifica la 10ª posizione dell’array YiEuqBAod0, utilizzata per la funzione di esclusione del percorso del malware. Se abilitato, aggiunge il percorso del malware alle esclusioni e esegue questo cmdlet tramite il binario powershel.exe con attributi in finestra nascosta per evadere la rilevazione da parte degli antivirus e nascondere il proprio comportamento alla vittima.
La quinta posizione dell’array YiEuqBAod0 viene utilizzata per scaricare un altro payload o aggiornare la funzione del task. Se questa flag è abilitata, scarica un altro malware o riceve comandi dal C2 del threat actor e inserisce quel comando in un file XML nella posizione %temp% ed esegue quel file da lì.
Alla seconda posizione dell’array YiEuqBAod0, il threat actor utilizza questa posizione per il “file dropping”. Se questa flag è abilitata, il malware verifica se “qwwnzxGmN.exe” è già presente nella cartella “C:\Users\username\AppData\Roaming” dell’host della vittima. Se il file non è presente, crea una copia del file nascosto come auto-copia del file principale.
Una volta che il file principale si è auto-copiato nella cartella %appdata%Roaming come mostrato nella figura 14, viene aggiunto al percorso di esclusione. Quindi decodifica i dati in base64, che sono stati decriptati nel costruttore del metodo principale della fase 3, in una stringa che è un file XML. Questo file XML contiene un valore che genera un task. Questi valori includono l’attributo nascosto del malware, la persistenza, la funzione abilitata, l’esecuzione del comando del percorso del file, ecc.
Questo file XML viene creato nella posizione %temp% come “.tmp”, quindi aggiorna i valori richiesti nel file XML, come “Location” e “USERID”. Successivamente, crea un task programmato con attributi di finestra nascosta per nascondere il comportamento dalla vittima per la persistenza, come “updates\qwwnzxGmN” e importa quel file XML. Il threat actor elimina il file tmp per evitare tracce agli analisti di sicurezza.
La figura 18 mostra il modulo della fase 3 che decripta il payload finale. La variabile gnWmyvSdDoAS8VNPBy.AtOuOF5iCk = “4kQLt8DIME” è il nome della risorsa (in montero.dll). gnWmyvSdDoAS8VNPBy.NJMuDv6Sv6 = “pqDVZxpXC” è la chiave. Carica la risorsa e la passa al metodo di decriptazione Pp62t2mj9p insieme alla chiave.
Al termine della criptazione il payload finale è in gnWmyvSdDoAS8VNPBy.w9Yu0dnomp.
Una volta decriptato il payload finale nel buffer, il malware controlla la prima posizione dell’array YiEuqBAod0. In base a questo valore, seleziona il processo di destinazione per il process hollowing. L’attaccante ha fornito i valori da 0 a 4. Se il valore è 4, carica il payload finale in memoria utilizzando il metodo Assembly Load ed esegue il punto di ingresso del payload finale.
Se il valore è “1”, seleziona il processo di destinazione come MSBuild.exe per il process hollowing; se il valore è “2”, il processo di destinazione è vbc.exe; se il valore è “3”, il processo di destinazione è RegSvcs.exe. Se nessuno dei valori sopra è presente, seleziona il processo di destinazione come il file genitore.
Nel costruttore della Fase 3, il malware decripta la sequenza delle API per il process hollowing nel metodo bLmuzQDIA5(), memorizzando CreateProcessA. Questo malware crea il processo mirato in base al valore di cui sopra (Fig. 17) e lo avvia in modalità sospesa.
Il metodo je3uFjEe5y() memorizza WriteProcessMemory e decripta la sezione “.text” del payload finale nella memoria del processo mirato.
IOCS di Formbook
6A9F890C529C410FA32793F496E7F200
0DA34A44EE4876DD5E35939AF02F1D32
D751816C3673935BF989716ABD0DAB21
F8EC1BE3F2BD8269DB033375ED1A841E
Individuazione da parte di Seqrite
- Trojan.Formbook.S34651912
Autori: Rumana Siddiqui and Manoj Kumar Neelamegam
Fonte originale: Formbook Phishing Campaign with old Payloads
