LockBit continua a distinguersi tra le famiglie ransomware più sofisticate e persistenti in circolazione, grazie all’evoluzione costante delle sue TTP (tattiche, tecniche e procedure). Un recente caso ha evidenziato come l’attore stia facendo largo uso di tecniche di DLL sideloading e masquerading, al fine di compromettere sistemi con un livello di visibilità minimo e un alto tasso di successo operativo.
Il sideloading DLL non è un concetto nuovo, ma LockBit ne ha fatto un’arma chirurgica. In una delle varianti analizzate, l’eseguibile dannoso — tipicamente una versione modificata di CyberArk.Data — viene caricato assieme a una DLL apparentemente legittima, ad esempio wlbsctrl.dll. L’eseguibile ospitante viene camuffato per sembrare una componente autentica di un software enterprise noto, come CyberArk, sfruttando così la fiducia dell’ambiente target e bypassando sistemi di controllo che usano whitelist di applicazioni.
Ma la vera raffinatezza sta nel masquerading. Non si tratta solo di rinominare file: LockBit costruisce le sue esche binarie in modo da imitare file di sistema reali, replicando metadati, icone, e persino timestamp coerenti, così da rendere estremamente difficile l’individuazione tramite i normali controlli forensi.
Durante una compromissione osservata, la catena d’attacco prevedeva l’impiego di uno script batch (run.bat) per invocare l’eseguibile mascherato. Una volta eseguito, questo caricava in memoria la DLL malevola che, a sua volta, stabiliva il canale di comunicazione C2 e orchestrava il deploy del payload ransomware. A livello di IOCs, sono stati osservati hash SHA256 coerenti tra le DLL modificate e le versioni autentiche, ma con leggere discrepanze nei PE header e nelle dimensioni complessive.
Un altro elemento da non trascurare è l’uso di nomi utente e percorsi fittizi. Nella telemetria raccolta, si notano directory come C:\ProgramData\CyberArk\Data\ — assolutamente plausibili — contenere invece strumenti offensivi e loader criptati. Questo ulteriore livello di mimetismo rende inefficaci le policy basate su regole statiche di detection.
Approfondimento tecnico: reverse engineering e IOC estratti
Durante l’analisi del campione di LockBit osservato, l’eseguibile principale risultava essere un dropper camuffato da componente CyberArk, con hash SHA256:
SHA256: 3c87d98ea66b7f93bd5039e843e961b7a81e39ddc2328e4b7b2b1f6dc660a3a1
All’esecuzione, il file CyberArk.Data.exe lanciava una DLL wlbsctrl.dll attraverso il classico meccanismo di DLL sideloading, sfruttando l’ordine di ricerca del sistema operativo. In particolare, la funzione LoadLibraryW() caricava la DLL malevola presente nella stessa directory:
HMODULE hDll = LoadLibraryW(L"wlbsctrl.dll");
if (hDll != NULL) {
FARPROC entry = GetProcAddress(hDll, "DllMain");
if (entry != NULL) {
entry(...); // codice shell
}
}
L’analisi con strumenti come PEStudio e x64dbg ha evidenziato che la DLL conteneva una shellcode offuscata, deoffuscata in memoria attraverso una routine XOR con chiave embedded:
xor eax, eax
mov ecx, [key]
mov esi, [shellcode_start]
decrypt_loop:
xor byte ptr [esi], cl
inc esi
loop decrypt_loop
Una volta in memoria, il codice eseguiva una connessione verso un endpoint C2 hardcoded (esempio non attivo):
hxxp://185.220.102.240:8080/task
A livello operativo, i comandi usati per l’installazione erano mascherati in uno script .bat come:
@echo off
start "" "CyberArk.Data.exe"
Inoltre, tramite Sysmon si è potuto osservare il pattern comportamentale del sideloading:
<EventID>7</EventID>
<ImageLoaded condition="ends with">wlbsctrl.dll</ImageLoaded>
<OriginalFileName>not_matching_system.dll</OriginalFileName>
Questi dettagli, incrociati con l’uso di timestamp manomessi (compilazione retrodatata al 2019), rafforzano l’ipotesi di masquerading a livello file system e metadati PE, verosimilmente generati tramite tool come PEChecksum o Resource Hacker.
LockBit riesce a sfuggire ai controlli anche sfruttando tecniche di persistence minimali, senza scrivere chiavi di registro o installare servizi, ma affidandosi a scheduled tasks temporanei o all’esecuzione da memoria. In ambienti in cui è attivo il controllo sull’uso del disco, questo comportamento fileless rappresenta una minaccia significativa.
A livello di mitigazione, il pattern emerso suggerisce che i controlli basati esclusivamente su firma o su path non siano più sufficienti. È necessario adottare approcci comportamentali, che analizzino l’anomalia nell’interazione tra processi e librerie, e che mantengano una baseline aggiornata delle esecuzioni consentite nei vari segmenti della rete.
💣 LockBit colpisce ancora: sideloading, masquerading e C2 invisibili.
Hai già visto qualcosa di simile nei tuoi ambienti? 🕵️♂️
Condividi tool, IoC e tecniche di detection nel nostro forum! ⬇️💬