La backdoor LOTUSLITE dell’APT cinese Mustang Panda evolve tecnicamente e amplia i bersagli dal settore bancario indiano alle cerchie diplomatiche sulla penisola coreana.
Autore: Redazione SecurityOpenLab
Mustang Panda non si ferma. A tre mesi dalla scoperta della backdoor LOTUSLITE, il gruppo APT cinese torna con una variante aggiornata dello stesso impianto, due nuove campagne di spionaggio e bersagli che non hanno nulla in comune tra loro: il settore bancario indiano e le cerchie diplomatiche che si occupano della penisola coreana. La nuova ricerca dell'Acronis Threat Research Unit ha tracciato l'evoluzione dell'impianto, documentato le modifiche tecniche introdotte per eludere le regole di detection esistenti e collegato le due campagne grazie a una serie di errori operativi ricorrenti commessi dallo sviluppatore. L'attribuzione a Mustang Panda è moderatamente certa per via delle sovrapposizioni nel codice, nell'infrastruttura e nei pattern comportamentali che erano stati evidenziati nella campagna precedente.
Nel caso della campagna indiana, il vettore di ingresso è stata una email di spear phishing mirato contenente un file CHM (Compiled HTML Help, il formato che Windows usa per i file della guida in linea) denominato Request for Support.chm, individuato su VirusTotal. La nomenclatura è stata appositamente scelta per richiamare le convenzioni dei sistemi di ticketing tipici degli istituti bancari, di modo da creare un contesto plausibile per convincere il destinatario ad aprirlo.
All'interno del CHM si trovano sei oggetti, fra cui una pagina HTML che mostra un pop-up per indurre l'utente a cliccare su Yes, un eseguibile firmato Microsoft e una DLL malevola, che è la variante aggiornata di LOTUSLITE. La pagina HTML contiene anche un reindirizzamento verso un server esterno da cui viene scaricato ed eseguito un file JavaScript servito da un dominio controllato dagli attaccanti.
Il JavaScript svolge l'intero lavoro di consegna ed esecuzione del carico malevolo, sfruttando tre componenti di Windows iniettati in una sezione nascosta della pagina. Il primo usa un processo legittimo di Windows per estrarre il contenuto dell'archivio CHM e depositarlo in una cartella pubblica del sistema. Il secondo lancia l'eseguibile estratto. Il terzo aggira le restrizioni di sicurezza che normalmente bloccherebbero le prime due operazioni. Il tutto avviene in sequenza automatica, senza che l'utente debba fare nulla di più che aver aperto il file iniziale.
Una volta deposti i file, entra in gioco l’ormai ben nota tecnica del DLL sideloading: l'eseguibile usato questa volta è Microsoft_DNX.exe, uno strumento legittimo e firmato digitalmente da Microsoft, che Windows considera quindi affidabile per definizione. Dato che il programma carica automaticamente qualsiasi libreria con il nome atteso presente nella propria directory, è sufficiente piazzargli accanto la DLL malevola perché la esegua. Da notare che tutto avviene sotto l'ombrello di un processo Microsoft che ovviamente non solleva allarmi.
Rispetto alla versione originale documentata a gennaio, i ricercatori di Acronis TRU tracciano questa variante come LOTUSLITE v1.1 e identificano una serie di modifiche incrementali, nessuna delle quali altera l'architettura di fondo, ma tutte orientate a bruciare le regole di detection scritte sulla v1.0.
La prima novità riguarda la struttura interna della DLL: il numero di funzioni esportate cresce da 16 a 22 e il punto di ingresso principale viene rinominato in modo da instradare l'esecuzione verso una funzione chiamata HDFCBankMain (il nome da solo rivela il settore preso di mira). Anche altre funzioni interne vengono rinominate con un prefisso numerico, a suggerire che lo sviluppatore stia mantenendo un sistema di versionamento interno tra una campagna e l'altra.
Sul piano del codice, scompaiono i commenti sarcastici presenti nella v1.0 così che l'impianto risulti più professionale. Cambiano anche due valori che i sistemi di detection usano come firma: un parametro interno che governa la modalità di esecuzione, e un marcatore inserito in ogni pacchetto di comunicazione con il server di comando e controllo. Entrambi svolgono le stesse funzioni di prima, ma con valori diversi quanto basta per rendere inutilizzabili le regole di rilevamento scritte sulla versione precedente.
La modifica più rilevante riguarda il modo in cui l'impianto interagisce con il sistema operativo. Nella v1.0, le funzioni di Windows necessarie all'operatività venivano richiamate direttamente, lasciando tracce visibili a chi analizzava il file. Nella v1.1 ogni singola chiamata passa attraverso un meccanismo indiretto che le risolve in tempo reale, senza lasciar trasparire nulla nell'elenco statico delle dipendenze. Il risultato è un file che, analizzato senza eseguirlo, non rivela nulla delle sue capacità reali.
La persistenza sul sistema viene mantenuta con lo stesso meccanismo della v1.0, attraverso una chiave di registro che fa partire l'impianto automaticamente a ogni avvio. A differenza di prima, però, anche questa logica ora è nascosta dietro lo stesso meccanismo indiretto appena descritto. Infine, scompare il messaggio di errore fasullo sulla corruzione del file Word che nella v1.0 serviva a giustificare all'utente l'assenza di qualsiasi reazione visibile all'apertura del file.
L'analisi della campagna coreana rivela lo stesso impianto, ma un’esca differente: un archivio ZIP presentato come lettera di invito per una riunione di comitato e un eseguibile legittimo usato per il sideloading che si chiamava kwpswnsserver.exe per essere credibile. Anche l'eseguibile host era differente, ma l’autore del codice non ha ripulito il payload dai riferimenti alla campagna precedente.
Nonostante gli sforzi di pulizia, lo sviluppatore ha lasciato una serie di tracce che si sono rivelate elementi chiave per l'attribuzione. Il residuo più significativo è la funzione KugouMain: nella v1.0 la DLL si chiamava kugou.dll, in riferimento all'app musicale Tencent usata per il sideloading. Nella v1.1 il nome del file è cambiato, ma l'export KugouMain è stato mantenuto tale e quale.
Il secondo artefatto è un pop-up che contiene la stringa goldenjackel12 e che corrisponde all'handle X del ricercatore indipendente R3BELF0X, che traccia pubblicamente le campagne di Mustang Panda pubblicando hash e indicatori. La presenza del riferimento all'interno del codice indica che lo sviluppatore è consapevole di essere monitorato e sceglie di segnalarlo esplicitamente nell'impianto, come già accaduto nella v1.0.
Ci sono evidenti similitudini anche nella infrastruttura di controllo: il server di comando e controllo usato nella campagna indiana è lo stesso provider DNS e lo stesso ASN utilizzati nell'infrastruttura della v1.0 e in tutti i casi le comunicazioni avvenivano su porta TCP 443 per mimetizzarsi nel normale traffico HTTPS.
Le indicazioni difensive partono con la necessità di aggiornare le regole di rilevamento: chi aveva costruito signature sulla versione precedente di LOTUSLITE non intercetterà questa variante senza un aggiornamento esplicito, perché i valori usati come firma sono cambiati. Dato che la v1.1 è progettata per non rivelare nulla di sé all'analisi statica, diventa essenziale spostare il focus sul monitoraggio comportamentale in tempo reale, con particolare attenzione ai processi firmati Microsoft che vengono eseguiti da posizioni inusuali, come le cartelle pubbliche del sistema o le directory di dati di programma.
Sul fronte della consegna, la campagna conferma che i file CHM rimangono un vettore attivo e spesso sottovalutato. Le organizzazioni dovrebbero valutare di bloccare o quantomeno monitorare l'esecuzione del processo Windows che gestisce questi file in contesti non amministrativi, con allerta specifica quando viene usato per estrarre contenuti verso directory accessibili a tutti gli utenti.
Sul fronte dell'infrastruttura, il ricorso continuativo a servizi DNS dinamici gratuiti per ospitare i server di comando e controllo suggerisce di includere i sottodomini di questi provider nell'ispezione del traffico in uscita, in particolare quando le comunicazioni presentano combinazioni fisse e ripetitive di intestazioni e identificatori di sessione, che è un pattern anomalo rispetto al traffico legittimo. Gli Indicatori di Compromissione completi pubblicati da Acronis TRU sono consultabili nel report originale e devono essere integrati il prima possibile nei sistemi di rilevamento.