Multilingua
Scarica 2200 Greenpass Italiani
Scaricare i greenpass intestati a persone diverse dalla tua per poi utilizzarli è REATO

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
Windows 12 arriva con maggiore AI: aggiornamenti più rapidi e sicuri
Tempo di lettura: 2 minuti. Windows “CorePC” è il successore spirituale di Windows “Core OS” e punta a modernizzare il sistema operativo.

Microsoft sta lavorando nuovamente per creare una versione “moderna” di Windows, introducendo intelligenza artificiale, aggiornamenti più rapidi e una migliore sicurezza all’interno del sistema operativo.
Il progetto CorePC e l’eredità di Windows 10X Il nuovo progetto, chiamato CorePC, segue gli stessi obiettivi di Windows 10X, ma con il supporto nativo per le applicazioni legacy sui dispositivi che lo richiedono. CorePC consentirà di creare nuove configurazioni di Windows che si adattano alle diverse esigenze del hardware dei PC.
Il cambiamento principale tra CorePC e la versione attuale di Windows è la separazione dello stato, proprio come in Windows Core OS. Questa separazione consente aggiornamenti più rapidi e una maggiore sicurezza attraverso partizioni di sola lettura che sono inaccessibili all’utente e alle app di terze parti, simili a quanto avviene in iPadOS o Android.
Innovazioni e compatibilità con le applicazioni legacy
CorePC è progettato per essere una variante modulare e personalizzabile di Windows, adatta a diversi form factor. Microsoft potrà configurare “edizioni” di Windows con diversi livelli di funzionalità e compatibilità delle app. L’obiettivo è mantenere il supporto nativo per le app e i flussi di lavoro legacy, quando necessario.
Fonti interne rivelano che CorePC consentirà a Microsoft di competere con i Chromebook in termini di impronta del sistema operativo, prestazioni e funzionalità. Una versione di Windows che esegue solo Edge, app web, app Android (tramite Project Latte) e app Office, progettata per PC educativi entry-level, è già in fase di test interni ed è del 60-75% più piccola di Windows 11 SE.
Sicurezza, AI e ottimizzazione per il futuro
Microsoft sta anche lavorando su una versione di CorePC che soddisfa le funzionalità attuali del desktop Windows, ma con la separazione dello stato abilitata per aggiornamenti del sistema operativo più rapidi e una maggiore sicurezza. Inoltre, la società sta sviluppando un livello di compatibilità chiamato Neon per le app legacy che richiedono un sistema operativo con stato condiviso.
Infine, Microsoft sta sperimentando una versione di CorePC “ottimizzata per il silicio”, progettata per ridurre il sovraccarico legacy, concentrarsi sulle capacità di intelligenza artificiale e ottimizzare verticalmente le esperienze hardware e software in modo simile a quanto avviene con Apple Silicon. Le esperienze AI saranno fondamentali per Windows nel 2024.
Tuttavia, piani, funzionalità e configurazioni potrebbero cambiare tra ora e quando Microsoft sarà pronta per iniziare a spedire dispositivi con CorePC. La tempistica per la disponibilità di CorePC non è ancora certa, ma si ritiene che Microsoft aspiri a renderlo disponibile in tempo per la prossima versione principale del client Windows nel 2024, con il nome in codice Hudson Valley.
Multilingua
Problemi display iPhone 15: Apple sospende collaborazione con BOE
Tempo di lettura: < 1 minuto. La difficoltà nella realizzazione del display dell’iPhone 15 costringe Apple a interrompere temporaneamente la collaborazione con il produttore cinese BOE

Il produttore cinese BOE avrebbe incontrato problemi nella produzione del display dell’iPhone 15, costringendo Apple a sospendere temporaneamente gli ordini dall’azienda.
Il problema riguarda il taglio Dynamic Island
Il problema riscontrato riguarda il taglio Dynamic Island per la fotocamera frontale e la tecnologia Face ID, ostacolando il piano di Apple di ridurre la dipendenza da Samsung. Apple predilige avere più fornitori per componenti chiave, al fine di ridurre i rischi nella catena di approvvigionamento e avere maggiore potere negoziale. Per il display dell’iPhone 15, Apple aveva pianificato di aggiungere BOE, insieme a Samsung e LG.
I problemi nel display dell’iPhone 15 di BOE
All’inizio del mese, si è appreso che BOE aveva problemi con il taglio Dynamic Island durante le prime fasi di produzione, in particolare con perdite di luce intorno allo slot. Rendimenti bassi e incoerenti hanno fatto sì che l’azienda avesse difficoltà a passare alla produzione di massa.
Apple sospende temporaneamente gli ordini con BOE
Il sito coreano TheElec ha riportato che Apple ha sospeso gli ordini del display dell’iPhone 15 da BOE, con Samsung che ne assumerà la produzione. Tuttavia, si dice che BOE stia facendo progressi nel risolvere il problema, quindi, anche se non riceverà ordini per le prime produzioni pre-lancio, potrebbe essere reinserita nei cicli successivi.
-
L'Altra Bolla2 settimane fa
Perchè la “mostruosa” Elly Schlein non “puzza di antisemitismo”
-
Editoriali2 settimane fa
Il CSIRT risolve i problemi o ha bisogno di fare le denunce alla Postale?
-
Inchieste2 settimane fa
Zuckerberg licenzia altri 10.000 dipendenti, abbandona NFT e Metaverso, e copia Telegram
-
Tech2 settimane fa
Telegram introduce la modalità “risparmio batteria”
-
Inchieste1 settimana fa
Sanremo multato per il conflitto di interessi della Ferragni con Meta
-
Inchieste1 settimana fa
ACN finalista su LinkedIn: spegnetegli i social
-
Inchieste1 settimana fa
Killnet assalta gli ospedali e Phoenix colpisce missione EOSDIS della NASA
-
Inchieste1 settimana fa
Meta vuole sottopagare la Musica italiana, ma va difesa perchè la SIAE è il male