Multilingua

XLoader/FormBook: Encryption Analysis and Malware Decryption

Tempo di lettura: 6 minuti. Xloader is a stealer, the successor of FormBook

Sostieni l'informazione di Matrice Digitale con un click. Seguici su Google News

Pubblicato

1 anno fa

in data

30/03/2023

Redazione

Tempo di lettura: 6 minuti.

Today ANY.RUN’s malware analysts are happy to discuss the encryption algorithms of XLoader, also known as FormBook. And together we’ll decrypt the stealer’s strings and C2 servers.

Xloader is a stealer, the successor of FormBook. However, apart from the basic functionality, the unusual approaches to encryption and obfuscation of internal structures, code, and strings used in XLoader are also of interest. Let’s take a detailed look at the encryption of strings, functions, and C2 decoys.

IceXLoader ha infettato migliaia di vittime in tutto il mondo

Ecco il malware che eluce i blocchi impostati da Microsoft sulle VBA

DotRunpeX diffonde diverse famiglie di malware tramite annunci pubblicitari

Gookit all’attacco di organizzazioni sanitarie e finanziarie

Encryption in XLoader

First, we should research 3 main cryptographic algorithms used in XLoader. These are the modified algorithms: RC4, SHA1, and Xloader’s own algorithm based on a virtual machine.

The modified RC4 algorithm

The modified RC4 algorithm is a usual RC4 with additional layers of sequential subtraction before and after the RC4 call. In the code one layer of subtractions looks like this:

       # transform 1
       for i in range(len(encbuf) – 1, 0, -1):
           encbuf[i-1] -= encbuf[i]

       # transform 2
       for i in range(0, len(encbuf) -1):
           encbuf[i] -= encbuf[i+1]

The ciphertext bytes are subtracted from each other in sequence from right to left. And then they go from left to right. In the XLoader code it looks like this:

Function performing RC4 encryption

The modified SHA1 algorithm

The SHA1 modification is a regular SHA1, but every 4 bytes are inverted:

   def reversed_dword_sha1(self, dat2hash):
       sha1Inst = SHA1.new()
       sha1Inst.update(dat2hash)
       hashed_data = sha1Inst.digest()
       result = b””
       for i in range(5):
          result += hashed_data[4*i:4*i+4][::-1]
       return result

Xloader’s own virtual machine algorithm

The last algorithm is a virtual machine that generates one to four bytes of plaintext, depending on the current byte of the ciphertext. Usually, this algorithm is used as an additional encryption layer, which will be discussed later. The entry of the VM decryption routine looks like this:

An example of transformations in a virtual machine’s decryption routine

Decrypting XLoader Strings

Next, let’s investigate how the string encryption works in XLoader. All byte arrays containing encrypted strings or key information are located in special kinds of blobs.

An example of a blob with encrypted data

As you can see in the screenshot above, this blob is a function that returns a pointer to itself, below this function are the bytes you are looking for.

In order to decrypt strings, first a key is generated. The key is generated from 3 parts, to which the above-described functions are applied.

Key generation function to decrypt strings

Here K1_blob, K2_blob, and K3_blob are functions that return data from the blocks described above, and the string length is an argument for them.

The functions VM_Decrypt, RC4_with_sub_Layer and sha1_* are modified algorithms that we discussed earlier.

Schematically, the key generation algorithm can be represented by the following diagram.

Here E and K are the data and the key that is fed to the input of the RC4 function, respectively, and K1, K2, and K3 are the data obtained from the K1_blob, K2_blob, and K3_blob functions.

Scheme of key generation to decrypt strings

The strings themselves are also stored as a blob and are covered by two layers of encryption:

VM_decrypt
RC4 that uses the key obtained above.

At the same time, RC4 is not used for the whole blob at once.

After removing the first layer, the encrypted strings themselves are stored in the format:

encrypted string length – encrypted string

Consequently, to decrypt the strings, we need to loop through this structure and consistently decrypt all the strings.

Function for decrypting strings

Below is an example of the encrypted data after stripping the first layer. Length/string pairs for the first 3 encrypted strings are highlighted in red.

The first 3 encrypted strings

The same strings after decryption:

The first 3 lines after decoding

Along with the encrypted strings, C2 decoys are also stored there. They are always located at the end of all decrypted strings, beginning and ending with the f-start and f-end strings.

Decrypting XLoader’s C2 Servers

Next, let’s see how the main C2 encryption works. The main C2 is located elsewhere in the code, so you can get it separately from the C2 decoys.

Code snippet demonstrating C2 decryption.

To decrypt it, as well as to decrypt the strings, 3 keys are used. The C2 decryption scheme is shown below:

EC2 is the encrypted C2
DC2 is the decrypted C2

The algorithm itself is a 3 times sequential application of the RC4 algorithm with 3 different keys.

C2 decoys’ decryption scheme

Also, in newer versions of XLoader C2 decoys, which usually lie along with all the other strings, turn out to be covered by an additional layer of encryption, and, at first glance, it is completely unclear where exactly the decryption of these strings occurs.

Since XLoader has several entry points, each responsible for different non-intersecting functionality, with many functions turning out to be encrypted.

The C2 decoys are decrypted inside the XLoader injected into Explorer.exe. And in this case, it is passed to netsh.exe, which also contains XLoader via APC injection.

The C2 life cycle in different XLoader modules

In order to understand how a C2 decoy is encrypted, first of all, you need to understand how the functions are encrypted.

It’s actually quite simple. RC4 is used as the encryption algorithm. This time, the key is hardcoded and written right in the code and then xored with the 4-byte gamma.

After that, you should find pointers to the start and end of the function. This is how you do it: a unique 4-byte value is placed at the beginning and end of each encrypted function. The XLoader looks for these values and gets the desired pointers.

Code snippet demonstrating the decryption of the function

Then the function is decrypted, control is given to it, and it similarly searches for and decrypts the next function. This happens until the function with the main functionality is decrypted and executed. So, functions should be decrypted recursively.

The key to decrypting C2 decoys consists of 2 parts and is collected separately at two different exit points. One exit point gets the 20-byte protected key, and the second gets the 4-byte gamma to decrypt the key.

Example of extracted XLoader malware configuration

Applying the above algorithms we can extract the configuration from Xloader, including C2, C2 decoys, and strings. For your convenience, we have integrated automatic extraction of the Xloader configuration into ANY.RUN interactive sandbox — just run the sample and get all the IOCs in seconds.

Extracted malware configuration in ANY.RUN

Examples of successfully executed samples:

Example 1

Example 2

Example 3

Sum it up

In this article we discussed the encryption in xLoader stealer. It is based on both add-ons to existing algorithms and self-written algorithms.

The main tricky part of the decryption process is the key generation and the fact that the XLoader functionality is split into modules that can be run in different processes. Because of this, in order to extract strings, we have to decrypt the executable code, among other things.

Fortunately, ANY.RUN is already set up to detect this malware automatically, making the relevant configuration details just a click away.

Appendix

Analyzed files

Sample with new C2 decoys encryption

Title	Description
Name	MT10320221808-004. pdf.exe
MD5	b7127b3281dbd5f1ae76ea500db1ce6a
SHA1	6e7b8bdc554fe91eac7eef5b299158e6b2287c40
SHA256	726fd095c55cdab5860f8252050ebd2f3c3d8eace480f8422e52b3d4773b0d1c

Sample without C2 decoys encryption

Title	Description
Name	Transfer slip.exe
MD5	1b5393505847dcd181ebbc23def363ca
SHA1	830edb007222442aa5c0883b5a2368f8da32acd1
SHA256	27b2b539c061e496c1baa6ff071e6ce1042ae4d77d398fd954ae1a62f9ad3885

Argomenti correlati:analisi anyrun cybercrime ESCLUSIVA Formbook malware xloader

Prossima

Ufficiale: E3 cancellato per scarso interesse dei produttori di videogiochi

Da non perdere

Windows 12 arriva con maggiore AI: aggiornamenti più rapidi e sicuri

Prosegui la lettura

Multilingua

Microsoft Svela VASA-1: modello AI che crea video Iperrealistici

Tempo di lettura: 2 minuti. Microsoft introduce VASA-1, un modello IA che produce video iperrealistici di volti umani parlanti, progettato per la creazione di personaggi virtuali

Sostieni l'informazione di Matrice Digitale con un click. Seguici su Google News

Pubblicato

1 giorno fa

in data

18/04/2024

Livio Varriale

Microsoft Svela VASA-1: modello AI che crea video Iperrealistici

Tempo di lettura: 2 minuti.

Microsoft ha recentemente introdotto un nuovo modello di intelligenza artificiale (IA), denominato VASA-1, che può generare video iperrealistici di volti umani parlanti partendo da una sola foto e un clip audio. Questa tecnologia promette di rivoluzionare il modo in cui i video vengono generati, aggiungendo un livello di realismo senza precedenti.

Caratteristiche e funzionalità di VASA-1

Il modello VASA-1 di Microsoft è capace di creare video di volti umani che parlano con movimenti labiali sincronizzati all’audio, espressioni facciali e movimenti della testa che conferiscono un aspetto naturale al video. Questo modello di generazione video, che non verrà rilasciato come prodotto o API al pubblico, è pensato per l’uso in creazioni di personaggi virtuali realistici.

Capacità Tecniche del Modello

VASA-1 può generare video con una risoluzione di 512 x 512 pixel a 40 FPS e supporta la generazione di video online con una latenza di partenza trascurabile. Il modello è inoltre in grado di rendere video lunghi fino a un minuto da una singola immagine statica, offrendo agli utenti un controllo granulare su diversi aspetti del video come la direzione dello sguardo principale, la distanza della testa, le modifiche emotive e altro ancora.

Potenziali applicazioni e preoccupazioni etiche

Oltre alle applicazioni nella creazione di assistenti virtuali e personaggi interattivi, il modello VASA-1 ha il potenziale di essere utilizzato in campi come l’istruzione, l’accessibilità e il supporto terapeutico. Tuttavia, la capacità del modello di generare video iperrealistici solleva anche preoccupazioni sul suo possibile uso non etico, in particolare nella creazione di deepfake. Microsoft ha sottolineato che intende utilizzare questa tecnologia principalmente per sviluppare tecniche avanzate di rilevamento delle falsificazioni e per promuovere il benessere umano, ribadendo il suo impegno nello sviluppo responsabile dell’IA.

Con il lancio di VASA-1, Microsoft non solo spinge i confini della tecnologia video IA, ma apre anche un dialogo importante su come queste tecnologie possano essere utilizzate in modo responsabile. Mentre le potenzialità di VASA-1 sono vaste, il controllo etico e l’implementazione responsabile saranno cruciali per determinare il suo impatto futuro nella società.

Prosegui la lettura

Multilingua

Botnet multiple sfruttano vulnerabilità nei router TP-Link

Tempo di lettura: 2 minuti. Scopri come le botnet sfruttano una vulnerabilità nei router TP-Link per orchestrare attacchi, e come per proteggere i tuoi dispositivi.

Sostieni l'informazione di Matrice Digitale con un click. Seguici su Google News

Pubblicato

2 giorni fa

in data

17/04/2024

Livio Varriale

Tempo di lettura: 2 minuti.

Una vulnerabilità di sicurezza vecchia di un anno nei router TP-Link Archer AX21 (AX1800) sta attirando l’attenzione di numerose operazioni di botnet malware. Identificata come CVE-2023-1389, questa falla critica di iniezione di comandi non autenticata nella API locale attraverso l’interfaccia di gestione web del TP-Link Archer AX21 è stata ampiamente sfruttata nonostante le patch rilasciate.

Dettaglio della Vulnerabilità

La falla CVE-2023-1389, scoperta e segnalata agli inizi del 2023 tramite la Zero-Day Initiative (ZDI), ha portato TP-Link a rilasciare aggiornamenti di sicurezza per il firmware nel marzo 2023. Nonostante ciò, il codice di exploit divenne pubblico poco dopo, innescando una catena di attacchi mirati.

Escalation degli attacchi Botnet

Da marzo 2024, i dati di telemetria di Fortinet hanno registrato tentativi di infezione giornalieri che spesso superano i 40.000 e talvolta arrivano fino a 50.000, segno di un’attività malintenzionata in crescita. Almeno sei operazioni di botnet, incluse tre varianti di Mirai e la botnet denominata “Condi“, hanno intensificato gli attacchi sfruttando questa vulnerabilità.

Tattiche delle Botnet

Ogni botnet impiega metodologie diverse per sfruttare la vulnerabilità e stabilire il controllo sui dispositivi compromessi:

AGoent: Scarica ed esegue script che recuperano ed eseguono file ELF da un server remoto, cancellando poi i file per nascondere le tracce.
Variante di Gafgyt: Specializzata in attacchi DDoS, scarica script per eseguire binari Linux e mantenere connessioni persistenti ai server C&C.
Moobot: Avvia attacchi DDoS, scaricando ed eseguendo uno script per ottenere file ELF, eseguendoli in base all’architettura, e poi rimuovendo le tracce.
Miori: Utilizza HTTP e TFTP per scaricare file ELF, eseguendoli e utilizzando credenziali codificate per attacchi brute force.
Variante di Mirai: Scarica uno script che a sua volta recupera file ELF compressi usando UPX, monitora e termina strumenti di analisi dei pacchetti per evitare rilevamenti.
Condi: Usa uno script downloader per migliorare i tassi di infezione, impedisce i riavvii del dispositivo per mantenere la persistenza e scandisce e termina processi specifici per evitare rilevamenti.

Consigli per la sicurezza

Gli utenti dei router TP-Link Archer AX21 sono incoraggiati a seguire le istruzioni del produttore per l’aggiornamento del firmware, cambiare le password di amministrazione predefinite con altre uniche e lunghe, e disabilitare l’accesso web al pannello di amministrazione se non necessario.

Questo scenario di attacchi continua a evidenziare l’importanza di mantenere i firmware dei dispositivi aggiornati e di adottare pratiche di sicurezza robuste per proteggere le reti domestiche e aziendali dai malintenzionati.

Prosegui la lettura

Multilingua

GPT-4 mostra capacità di sfruttare vulnerabilità leggendo Avvisi di Sicurezza

Tempo di lettura: 2 minuti. Scopri come GPT-4 può sfruttare vulnerabilità reali, un rischio emergente per la sicurezza informatica che richiede misure proattive.

Pubblicato

2 giorni fa

in data

17/04/2024

Livio Varriale

Tempo di lettura: 2 minuti.

Un recente studio condotto da quattro scienziati informatici dell’Università dell’Illinois a Urbana-Champaign ha dimostrato che il modello di linguaggio GPT-4 di OpenAI è in grado di sfruttare vulnerabilità reali nei sistemi informatici leggendo semplicemente le descrizioni delle vulnerabilità, come quelle riportate nei CVE (Common Vulnerabilities and Exposures).

Metodologia della ricerca

I ricercatori hanno testato GPT-4 su un set di 15 vulnerabilità, denominate “vulnerabilità di un giorno”, che sono state rese note ma non ancora corrette al momento del test. Queste vulnerabilità includono problemi classificati come di “criticità elevata”. GPT-4 è riuscito a sfruttare con successo l’87% di queste vulnerabilità, un risultato significativamente superiore rispetto ad altri modelli come GPT-3.5 e diversi scanner di vulnerabilità open-source.

Implicazioni e potenziali futuri

I risultati suggeriscono che i modelli di linguaggio avanzati potrebbero diventare strumenti potenti per gli hacker, potenzialmente superando le capacità degli attuali script kiddie. GPT-4 ha mostrato di poter eseguire autonomamente i passaggi per effettuare determinati exploit che gli scanner di vulnerabilità open-source non riescono a rilevare. Questa capacità si estende a seguire i link contenuti nelle descrizioni dei CVE per ottenere ulteriori informazioni, rendendo questi agenti molto efficaci nell’exploitation.

Risultati specifici e limitazioni

La ricerca ha evidenziato che negare a GPT-4 l’accesso alla descrizione del CVE ha ridotto drasticamente la sua efficacia, abbassando il tasso di successo dal 87% al 7%. Questo sottolinea l’importanza delle informazioni dettagliate nel facilitare gli exploit. Tuttavia, i ricercatori hanno notato che il modello ha fallito nell’exploitare due delle 15 vulnerabilità a causa di problemi specifici relativi all’interfaccia utente o alla barriera linguistica (una descrizione in cinese).

Conclusioni e raccomandazioni

Questo studio evidenzia l’urgenza di misure di sicurezza proattive, come l’aggiornamento regolare dei pacchetti software quando vengono rilasciate patch di sicurezza, per contrastare le potenziali minacce rappresentate dall’uso di modelli di linguaggio avanzati per scopi malevoli. I ricercatori hanno sottolineato che “la sicurezza attraverso l’oscurità” non è una strategia sostenibile e sperano che i loro risultati spingano verso una maggiore consapevolezza e azioni preventive.

Riflessioni finali

Questo studio sottolinea come l’intelligenza artificiale, particolarmente in forma di grandi modelli di linguaggio, stia diventando una doppia lama, con capacità che possono essere utilizzate tanto per scopi costruttivi quanto distruttivi. L’adeguamento delle politiche di sicurezza informatica diventa quindi essenziale per prevenire l’abuso di tali tecnologie.

Prosegui la lettura