Multilingua
XLoader/FormBook: Encryption Analysis and Malware Decryption
Tempo di lettura: 6 minuti. Xloader is a stealer, the successor of FormBook
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:
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 |
Multilingua
Manjaro Linux 24.0 “Wynsdey” debutta con Linux Kernel 6.9
Tempo di lettura: < 1 minuto. Manjaro Linux 24.0 “Wynsdey” è stato rilasciato con Linux Kernel 6.9, portando miglioramenti significativi in termini di performance e sicurezza.
Manjaro Linux ha lanciato ufficialmente la versione 24.0, denominata “Wynsdey”, arricchita dal recente Linux Kernel 6.9. Questo aggiornamento porta significativi miglioramenti al popolare sistema operativo basato su Arch, confermando il suo impegno nel fornire un’esperienza utente avanzata e accessibile.
Dettagli del rilascio
Manjaro 24.0 “Wynsdey” si distingue per l’implementazione del Linux Kernel 6.9, che include nuove funzionalità e miglioramenti della sicurezza. L’aggiornamento del kernel promette una migliore gestione delle risorse hardware, ottimizzazioni delle performance e supporto esteso per nuovi dispositivi hardware. Gli utenti di Manjaro possono aspettarsi un’esperienza più fluida e sicura grazie a questi sviluppi.
Innovazioni e Caratteristiche
Oltre all’aggiornamento del kernel, Manjaro 24.0 introduce varie migliorie nell’ambiente desktop e nelle applicazioni di sistema. Queste modifiche sono volte a migliorare l’usabilità e a offrire una configurazione più intuitiva, rendendo il sistema operativo adatto tanto agli utenti esperti quanto a quelli alle prime armi con Linux.
Il lancio di Manjaro Linux 24.0 “Wynsdey” rappresenta un passo importante per la distribuzione, consolidando la sua reputazione come una delle scelte più stabili e affidabili per gli utenti Linux. Con l’aggiunta del Linux Kernel 6.9, Manjaro non solo migliora la sua compatibilità hardware ma anche la sua efficienza e sicurezza complessive. Con l’introduzione di miglioramenti sostanziali e l’attenzione continua verso l’accessibilità e la funzionalità, Manjaro Linux 24.0 “Wynsdey” si conferma una scelta eccellente per chi cerca un sistema operativo potente e versatile.
Multilingua
Sony Xperia 1 VI: anteprima del nuovo display
Tempo di lettura: 2 minuti. Sony rivela nuovi dettagli sul display dell’Xperia 1 VI, incluso un cambio nel rapporto d’aspetto e aggiornamenti tecnologici
Sony si prepara a lanciare il suo nuovo smartphone di punta, l’Xperia 1 VI, con un evento programmato per venerdì 17 maggio ed un’anteprima recente ha messo in luce alcune delle caratteristiche salienti del display del dispositivo, suggerendo cambiamenti significativi rispetto ai modelli precedenti.
Nuove innovazioni nel Display
L’Xperia 1 VI introdurrà una “nuova tecnologia di display”, che sembra essere una versione aggiornata del motore BRAVIA, già impiegato nei televisori BRAVIA del 2024. La novità più rilevante riguarda il cambio del rapporto d’aspetto, passando da un ultra-wide 21:9 a un più tradizionale 19.5:9. Questo cambio mira a offrire una migliore esperienza d’uso quotidiana e potrebbe attrarre un pubblico più ampio.
Cambiamenti nelle Specifiche del Display
Il pannello, che si prevede sarà di 6.5 pollici, potrebbe abbandonare la risoluzione 4K, che è stata una caratteristica distintiva della serie Xperia 1 dal 2019. Questa decisione potrebbe riflettere un tentativo di Sony di ottimizzare l’efficienza energetica e ridurre i costi, pur mantenendo alte prestazioni di visualizzazione.
Con il lancio imminente dell’Xperia 1 VI, gli appassionati di tecnologia e gli utenti Sony sono in attesa di conferme ufficiali riguardo queste anticipazioni. Le modifiche al rapporto d’aspetto e alla tecnologia del display segnano una nuova fase per la serie Xperia, con Sony che cerca di adattarsi alle preferenze in evoluzione dei consumatori e alle esigenze del mercato. Questo aggiornamento è cruciale per Sony, poiché l’Xperia 1 VI potrebbe stabilire nuovi standard per il design e le funzionalità dei futuri dispositivi mobile della compagnia.
Multilingua
Aggiornamento HyperOS per la Serie Xiaomi Mi 11X
Tempo di lettura: 2 minuti. Xiaomi Mi 11X riceve l’aggiornamento HyperOS: miglioramenti significativi in termini di personalizzazione, animazioni e prestazioni.
Xiaomi ha recentemente rilasciato l’aggiornamento HyperOS per la sua serie Mi 11X, che comprende i modelli Mi 11X e Mi 11X Pro. Questo aggiornamento porta con sé una serie di miglioramenti e funzionalità, marcando un passaggio significativo dall’interfaccia MIUI precedentemente utilizzata dall’azienda.
Dettagli dell’aggiornamento
- Mi 11X: Questo modello ha ricevuto l’aggiornamento HyperOS basato su Android 13, accompagnato dalla patch di sicurezza di marzo 2024. L’aggiornamento ha una dimensione di 1,6 GB.
- Mi 11X Pro: Questo dispositivo ha ricevuto l’aggiornamento HyperOS basato sull’ultimo sistema operativo Android 14, insieme alla patch di sicurezza di aprile 2024. L’aggiornamento per il Pro è significativamente più grande, con una dimensione di 4,8 GB.
Caratteristiche di HyperOS
HyperOS introduce una serie di cambiamenti rispetto a MIUI, con un forte focus sulla personalizzazione. Gli utenti possono ora godere di più opzioni di personalizzazione che mai, insieme a miglioramenti nelle animazioni e ottimizzazioni delle prestazioni. Questi cambiamenti rendono l’interfaccia utente più fluida e reattiva.
Panoramica della Serie Mi 11X
Lanciata nel 2021, la serie Mi 11X, destinata principalmente al mercato indiano, include il Mi 11X e il Mi 11X Pro, che sono versioni ribattezzate dei Redmi K40 e Redmi K40 Pro. Entrambi i dispositivi sono dotati di display Super AMOLED da 6.67 pollici con un refresh rate di 120Hz, ideali per il gaming e il consumo multimediale. Il modello base è alimentato dal chipset Snapdragon 870, mentre il modello Pro dal più potente Snapdragon 888. Originariamente, questi dispositivi erano lanciati con Android 11.
Con l’aggiornamento alla HyperOS, Xiaomi Mi 11X e Mi 11X Pro, scopri la serie su Amazon, si arricchiscono di nuove funzionalità che migliorano ulteriormente l’esperienza utente, rendendo questi dispositivi ancora più competitivi nel mercato degli smartphone. L’aggiornamento testimonia l’impegno continuo di Xiaomi nel fornire software aggiornato e funzionale ai suoi utenti che possono attendere la sostituzione.
- Inchieste1 settimana fa
Perchè il motore di ricerca OpenAI fa paura ai giornalisti?
- L'Altra Bolla1 settimana fa
Meta arriva l’intelligenza artificiale per la Pubblicità
- L'Altra Bolla1 settimana fa
TikTok: azione legale contro Stati Uniti per bloccare il divieto
- L'Altra Bolla1 settimana fa
Meta testa la condivisione incrociata da Instagram a Threads
- L'Altra Bolla1 settimana fa
X sotto indagine dell’Unione Europea
- Robotica6 giorni fa
Come controllare dei Robot morbidi ? MIT ha un’idea geniale
- Smartphone1 settimana fa
Xiaomi 14 e 14 Ultra, problemi di condensa nelle fotocamere
- Smartphone1 settimana fa
Google Pixel 8a vs Pixel 8: quale scegliere?