BitMEX sventa il tentativo di hack del Gruppo Lazarus, espone gli IP degli hacker e le carenze operative

BitMEX ha sollevato il velo su un tentativo di hack fallito da parte del Gruppo Lazarus, esponendo errori goffi da parte di un collettivo a lungo legato all'unità di cyber warfare della Corea del Nord.

Secondo un post sul blog rilasciato da BitMEX venerdì, il team ha ora impostato un sistema di monitoraggio interno per monitorare ulteriori infezioni e potenzialmente catturare futuri errori di sicurezza operativa.

Tutto è iniziato quando un dipendente di BitMEX è stato contattato su LinkedIn con una proposta per lavorare a un progetto di marketplace NFT falso, ma l'offerta corrispondeva a una nota tattica di phishing utilizzata da Lazarus, quindi il dipendente l'ha segnalata immediatamente, avviando un'indagine completa.

Il team di sicurezza di BitMEX ha accesso a un repository GitHub condiviso dall'attaccante, che conteneva un progetto Next.js/React. Ma sepolto all'interno c'era codice progettato per far eseguire all'employee inconsapevolmente un payload dannoso sul loro sistema. Il team non ha eseguito il codice, è passato direttamente all'analisi.

BitMEX analizza il malware, trova le impronte digitali di Lazarus

All'interno del repo, gli ingegneri di BitMEX hanno cercato il termine eval, un comune segnale di allarme nel malware. Una riga di codice era stata commentata, ma rivelava comunque l'intento. Se attiva, avrebbe raggiunto “hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726” per recuperare un cookie ed eseguirlo. Quel dominio era stato precedentemente collegato a Lazarus da Unit 42 di Palo Alto Networks, un team che monitora l'attività cibernetica della RPCD da anni.

Un'altra riga era attiva. Ha inviato una richiesta a “hxxp://fashdefi[.]store:6168/defy/v5” ed eseguito la risposta. BitMEX ha recuperato manualmente quel JavaScript e ha scoperto che era pesantemente offuscato. Utilizzando webcrack, uno strumento per deoffuscare il codice, il team ha reportedly rimosso gli strati. L'output finale era disordinato ma leggibile, poiché sembrava tre script diversi fusi in uno.

Una parte del codice conteneva identificatori per le estensioni di Chrome, che di solito indicano malware per il furto di credenziali. Una stringa, p.zi, sembrava malware più vecchio di Lazarus utilizzato nella campagna BeaverTail, un'altra operazione precedentemente documentata da Unit 42. BitMEX ha deciso di non ri-analizzare il componente BeaverTail, poiché era già pubblico.

Invece, si sono concentrati su un'altra scoperta: il codice si connetteva a un'istanza Supabase. Supabase è una piattaforma backend per sviluppatori, simile a Firebase. Il problema? Gli sviluppatori di Lazarus non l'hanno bloccata. Quando BitMEX l'ha testata, sono riusciti ad accedere al database direttamente—senza login, senza protezione.

Gli hacker espongono i log dei dispositivi infetti e i loro IP

Il database Supabase aveva 37 log di macchine infette. Ogni voce mostrava il nome utente, l'hostname, il sistema operativo, l'indirizzo IP, la geolocalizzazione e il timestamp. BitMEX ha notato dei pattern—alcuni dispositivi apparivano ripetutamente, il che li faceva spiccare come macchine per sviluppatori o test. Il formato di denominazione per la maggior parte degli hostname seguiva una struttura 3-XXX.

Molti IP provenivano da provider VPN. Un utente, “Victor”, si connetteva spesso utilizzando Touch VPN. Un altro, “GHOST72”, utilizzava Astrill VPN. Ma poi Victor ha sbagliato. Una voce collegata a lui aveva un IP diverso—223.104.144.97, un IP residenziale a Jiaxing, Cina, sotto China Mobile. Quella non era una VPN. Era probabilmente l'indirizzo IP reale di un operatore di Lazarus. BitMEX l'ha segnalata come un grave errore operativo.

BitMEX ha poi creato uno strumento per continuare a pingare il database Supabase. Dal 14 maggio, lo strumento ha raccolto 856 voci dal database, che risalgono al 31 marzo. Tra queste, c'erano 174 combinazioni uniche di nomi utente e hostname. Il sistema ora funziona in modo continuo, alla ricerca di nuove infezioni o di ulteriori errori da parte degli attaccanti.

Esaminando i timestamp, BitMEX ha scoperto che l'attività di Lazarus diminuisce tra le 8:00 e le 13:00 UTC, che corrispondono alle 17:00 e alle 22:00 a Pyongyang. Questo corrisponde a un orario di lavoro strutturato, fornendo ulteriore prova che il gruppo non è solo un gruppo di hacker freelance, ma un team organizzato.

Il team di sicurezza conferma il pattern di Lazarus e la divisione interna

Il Gruppo Lazarus ha una storia nota di attacchi di ingegneria sociale. In incidenti precedenti come la violazione di Bybit, hanno ingannato un dipendente di Safe Wallet facendolo eseguire un file dannoso. Questo ha loro dato l'accesso iniziale.

Poi un'altra parte del team ha preso il sopravvento, ha accesso all'ambiente AWS e ha modificato il codice front-end per rubare crypto dai cold wallet. BitMEX ha detto che questo pattern mostra che il gruppo è probabilmente diviso in più team—alcuni che fanno il phishing di base, altri che gestiscono le intrusioni avanzate una volta ottenuto l'accesso.

BitMEX ha scritto: «Negli ultimi anni, sembra che il gruppo si sia diviso in più sottogruppi non necessariamente della stessa sofisticazione tecnica». Il team di sicurezza ha affermato che questa campagna ha seguito lo stesso schema. Il messaggio iniziale su LinkedIn era semplice, il repository GitHub era amatoriale.

Ma lo script di post-sfruttamento ha mostrato molta più abilità, chiaramente sviluppato da qualcuno più esperto. Dopo aver deoffuscato il malware, BitMEX è stata in grado di estrarre gli Indicatori di Compromissione (IoC) e inserirli nei propri sistemi interni.

Hanno rinominato le variabili, pulito lo script e seguito il suo funzionamento. La parte iniziale del codice era nuova e, secondo quanto riportato, inviava i dati di sistema (nome utente, IP, ecc.) direttamente in Supabase, rendendo il tracciamento facile… per chiunque trovasse il database aperto.

BitMEX ha anche identificato le macchine utilizzate durante lo sviluppo. Tra gli esempi c'era Victor@3-KZH, utilizzata con Touch VPN e China Mobile. Altre, come GHOST72@3-UJS-2 e Super@3-AHR-2, utilizzavano un mix di Astrill, Zoog e Hotspot Shield. I log mostravano persino account utente come Admin@3-HIJ, Lenovo@3-RKS, GoldRock@DESKTOP-N4VEL23 e Muddy@DESKTOP-MK87CBC. Si trattava probabilmente di ambienti di test allestiti dagli attaccanti.