Key Points
Xloader is a popular information stealing malware family that is the successor to Formbook.
In early 2020, Formbook was rebranded as Xloader and the threat actors moved to a malware-as-a-service (MaaS) business model, renting C2 infrastructure to customers.
Xloader implements different obfuscation methods and several encryption layers to protect critical parts of code and data from analysis.
The developers behind this malware family continue to update the code with improved obfuscation and encryption layers with each new version that is released.
In January 2023, Zscaler ThreatLabz identified a new variant of Xloader that identifies itself as version 4.3 with several modifications including additional obfuscation.
Introduction
Xloader is a rebranded version of the Formbook information stealing malware, which has been sold in criminal forums since 2016. The threat actors behind this malware family have been updating and improving the code regularly. In early 2020, the malware was rebranded as Xloader. In early 2022, the threat actors released Xloader version 2.9, which introduced significant improvements to obfuscate the malware code and data including the list of command-and-control (C2) servers. In October 2022, ThreatLabz identified a new Xloader version labeled as 3.9. In January 2023, the threat actors released Xloader version 4.3. Across Xloader versions, the group has modified the malware’s obfuscation techniques including adding numerous layers of encryption with code that recursively decrypts other blocks of code until reaching the core functionality that decrypts the most sensitive data (also encrypted with multiple layers).
This blog post analyzes the encryption algorithms used by Xloader to decrypt the most critical parts of the code and the most important parameters of the malware’s configuration. The analysis is performed on the latest version of Xloader 4.3. ThreatLabz has also created an IDA Python script to decrypt Xloader’s code and data to facilitate analysis.
Technical Analysis
Basic Algorithms and Structures
Formbook and Xloader have evolved along the years with new layers of obfuscation added in each new version. However, there is a set of basic algorithms that have been used since the first versions of Formbook. These algorithms are combined in different ways to decrypt other blocks of code and data. The primary algorithms that are shared between different versions of Xloader are the following:
Custom RC4: an RC4-based algorithm with two additional layers based on subtraction operations.
Custom buffer decryption algorithm: a custom algorithm used by Xloader, mainly used to decrypt the first encryption layer of the PUSHEBP data blocks (described in the following sections).
Custom SHA1: a SHA1 hash is calculated and the result is reversed DWORD by DWORD.
There is also a large global data structure that is used to store important information. When Xloader is executed, this structure is allocated and initialized with information from PUSHEBP data blocks, or from hardcoded values in the code. This structure contains data and encryption keys that are used by other parts of the code. Previous blog posts have referred to this structure as the ConfigObj, with fields that are used to store flags, encryption parameters, pointers, etc. The most important offsets in the ConfigObj structure are identified in Table 1.
Offset
Description
Size
0x00
Value 0xffffffff
0x04
0x04
Pointer to a second PE header used for process injection (e.g., explorer.exe)
0x04
0x08
Result of RtlGetProcessHeaps()
0x04
0x48
Branch ID – XLNG (XORed with 0x3c)
0x04
0x90
Pointer to an extended config (located in memory following the ConfigObj structure)
0x04
0x2DC
Decrypted content of the PUSHEBP block 2, which is an array of API hashes
0x220
0x510
Array of library and process names hashes
0x254
0x828
Seed of a random number generator (RNG) used by the malware
0x4
0x83C
Flag indicating that Xloader has generated the parameters necessary for the communications with the C2
0x4
0x970
The Xloader version number (XORed with 0x3c)
0x4
0x990
RC4 key used to decrypt other parameters
0x14
0x9A4
RC4 key used to decrypt other parameters (this key is the SHA1 of the decrypted content of the PUSHEBP block 5)
0x14
0xCE8
RC4 key used to decrypt the C2s list
0x14
Table 1. Important Xloader 4.3 ConfigObj fields.
Encrypted PUSHEBP Data Blocks
Throughout the Xloader code there is a set of encrypted data blocks with the structure shown in Figure 1.
Figure 1. Xloader PUSHEBP encrypted block
This structure is designed to resemble the beginning of a function, but are in fact blocks of encrypted data such as encryption keys and encrypted strings. These data blocks are decrypted using a custom buffer decryption algorithm. Table 2 shows the PUSHEBP encrypted blocks that were found in Xloader 4.3.
PUSHEBP Block Number
Description
Size
PUSHEBP Block 1
Encrypted strings
0xA82
PUSHEBP Block 2
API CRCs
0x222
PUSHEBP Block 3
Encryption key involved in C2 communications
0x15
PUSHEBP Block 4
Encryption key used to decrypt other data
0x14
PUSHEBP Block 5
Hardcoded C2
0x78
PUSHEBP Block 6
API CRCs
0x310
Table 2. PUSHEBP encrypted block contents
Encrypted PUSHEBP Functions
Formbook and Xloader also contain functions that decrypt code. An example function to decrypt code (prior to Xloader 2.9) is shown in Figure 2.
Figure 2. Encrypted code in earlier versions of Xloader and Formbook
This code starts with the well-known function preamble push ebp / mov ebp, esp, followed by a tag identifying the encrypted code (0x49909090 in Figure 2), the encrypted code, and an ending tag 0x90909090.
In older versions, the code was decrypted using a custom RC4 algorithm with a key stored in the ConfigObj structure. In Xloader version 2.9, the code retained the custom RC4 algorithm and added a layer of encryption with a second key built on the stack, as shown in Figure 3.
Figure 3. Decryptor of the PUSHEBP functions in Xloader version 2.9
In Xloader version 4.3, there are still PUSHEBP encrypted functions. However, the tags identifying the start and the end of the encrypted code have changed, and now they appear to be random bytes. Figure 4 shows an example of an encrypted function in Xloader 4.3.
Figure 4. Encrypted PUSHEBP function (Xloader version 4.3)
Figure 5 shows the code that decrypts a PUSHEBP function (e.g., the function DecryptCriticalCodeType1_Set_909090909090), which accepts two encrypted tags and an ID value. Inside the decryptor, another 0x14 byte key is constructed dynamically in the sub-function init_key_encrypted_funcs, XORed with a DWORD (XOR key 1) and XORed again with the ID value passed as an argument and another hardcoded DWORD (XOR key 2). The resulting 0x14 byte key will be used to decrypt the encrypted code using Xloader’s custom RC4 algorithm. The same RC4 key is also used to decrypt the encrypted TAG1 and TAG2, which are passed as arguments to the decryptor to derive the starting and ending tags that delimit the encrypted PUSHEBP function.
Figure 5. PUSHEBP function decryption code (Xloader version 4.3)
After the code is decrypted, the delimiter tags are replaced by 90 90 90 90 90 90 (NOP) opcodes. Figure 6 shows an encrypted function before and after being decrypted.
Figure 6. Example PUSHEBP function decrypted (Xloader version 4.3)
Encrypted NO-PUSHEBP Functions
In Xloader version 4.3, a new type of encrypted function without the push ebp / mov ebp esp preamble has also been introduced. The limits of the encrypted code are located by searching for two tags that identify the start and the end of the block. Figure 7 shows the code responsible for determining the limits of a NO-PUSHEBP encrypted function.
Figure 7. NO-PUSHEBP decryption code limit identification and layer 1 decryption (Xloader version 4.3)
The custom Xloader RC4 algorithm is again used to decrypt the encrypted code with two layers and two different keys. The encryption key for the first layer is calculated in another function and stored in the global structure ConfigObj (the value is the result of Xloader’s custom SHA1 algorithm of the decrypted content of the PUSHEBP data block number 5). The encryption key for the second layer is built on the fly: an initial key is built on the stack and XORed with a DWORD (XOR key), producing the final key (Xloader never hardcodes exact values including for encryption keys and delimiter tags). Figure 8 shows the code involved in the decryption of the second layer for one of the encrypted NO-PUSHEBP functions.
Figure 8. NO-PUSHEBP layer 2 decryption (Xloader version 4.3)
After the code is decrypted, the tag before the encrypted code is replaced by the opcodes EC 8B 55 (push ebp / mov ebp esp function preamble). The tag after the encrypted code is replaced by 90 90 90 90 (NOP) opcodes.
Encrypted Configuration
The most important parameters of Xloader’s configuration are stored in the PUSHEBP encrypted data blocks or calculated from hardcoded constants (that are also obfuscated).
Encrypted Strings
The encrypted strings in Xloader are stored in the PUSHEBP data block 1. All the PUSHEBP data blocks have to be decrypted with the custom buffer decryption algorithm as explained before. Once the block is decrypted, the result is a sequential list of items that have the following format:
struct encrypted_string {
BYTE length;
BYTE content[length];
}
Each string is decrypted with the custom Xloader RC4 algorithm and an encryption key stored at offset 0x990 in the ConfigObj. This RC4 key is generated in the function shown in Figure 9.
Figure 9. Generation of the RC4 key for encrypted strings (Xloader version 4.3)
ThreatLabz has reproduced this algorithm to decrypt the encrypted strings in Xloader 4.3 in Python. The code is available in our GitHub repository here.
Encrypted C2s
The Xloader configuration contains a C2 that is stored separately from another list of C2 domains. The C2 that is stored separately was thought to be Xloader’s real C2 and the other C2s were used as decoys. However, in more recent versions of Xloader, real C2s are likely hidden among the list of decoy C2s. In fact, the author behind Xloader has made significant efforts to protect the list of C2s that were previously thought to be decoys.
Hardcoded C2
The code shown in Figure 10 is responsible for decrypting the hardcoded Xloader C2.
Figure 10. Hardcoded C2 decryption (Xloader version 4.3)
The code in Figure 10 combines a set of operations based on Xloader’s various encryption algorithms and the data stored in the PUSHEBP data blocks to generate the encryption key necessary to decrypt the hardcoded C2 (which is stored in the PUSHEBP data block 5).
C2 List
As previously mentioned, there is another list of C2s that may contain decoy C2s and real C2s. In Formbook and in earlier versions of Xloader, these were stored as an encrypted string with no additional layers of encryption. In Xloader 2.9, the developers introduced an additional custom RC4 layer and Base64 encoding for the C2 list as shown in Figure 11.
Figure 11. Additional encryption layer for the C2 list (Xloader version 2.9)
In Figure 11, the function StringsDecryptor2 decrypts the first layer of the encrypted strings. In version 2.9, an additional Base64 layer is decoded followed by a layer of custom RC4 decryption. In Xloader version 4.3, they have added an additional encryption layer to this C2 list. Figure 12 shows the code responsible for decrypting these new layers.
Figure 12. New encryption layer for Xloader’s C2 list (Xloader version 4.3)
In the new version, the C2 list is first Base64 decoded and a custom RC4 layer is decrypted. A table of 4 byte keys is built on the stack. Each position of the table corresponds to a C2. Once decrypted, this custom RC4 layer is Base64 encoded again. After the new additional decryption layer is complete, Xloader decrypts the same layers as version 2.9: decoding the Base64 layer again and decrypting an additional custom RC4 layer with a key stored in a sub-structure of the ConfigObj. The way that this key (for the last RC4 layer) is generated has also changed in Xloader 4.3. Figure 13 shows the code generating the RC4 key for the last encryption layer of the C2 list.
Figure 13. Key generation for the final encryption layer of the C2 list (Xloader version 4.3)
As shown in Figure 13, the key is built on the stack and it is XORed with a value from the ConfigObj that was initialized previously in a different part of the code. Once this last layer is decrypted, the plaintext C2s are obtained.
Branch ID and Version Number
In previous versions, the Xloader branch ID and version number were sent in the registration packet to the C2. The format of the registration packet (before the last two RC4 layers) was the following:
XLNG
Bot ID
Version Number
Operating System
Base64(Username)
XLNG is the tag for the Xloader branch (FBNG was the branch ID for Formbook).
In Xloader version 4.3, the registration packet sent to the C2 includes an additional encryption layer as shown in Figure 14.
Figure 14. Xloader 4.3 Registration packet with additional PKT2 layer
This new encryption layer is marked with the tag PKT2. Communications are performed in the context of explorer.exe (previously injected). However, this registration packet is built in the first injected process (a hollow process) and copied to the context of explorer together with the rest of the injected code. That first injected process exits after injecting into explorer, so the registration packet under the last encryption layer marked with the PKT2 tag is no longer in plaintext after the first injected process terminates.
The PKT2 packet is built in one of the NO-PUSHEBP encrypted functions. That function is decrypted and executed in the context of the first injected process. The code first builds a string with the same format as the registration packet in previous Xloader versions as shown in Figure 15.
Figure 15. Registration packet with the new PKT2 encryption layer
However, as we can see in Figure 15, Xloader 4.3 introduces a NULL character separating the bot ID and the malware version number. This added NULL byte is likely a coding error.
Figure 16 shows how the first registration packet is constructed (marked with XLNG tag) and encrypted with RC4 and encoded with Base64, and then concatenated to the PKT2 tag to generate the final registration packet.
Figure 16. Xloader version 4.3 registration packet construction
However, because of the coding error previously mentioned (an extra NULL character after the bot ID) the final registration data contains just two fields for the XLNG branch and bot ID as shown below:
XLNG
Bot ID
The PKT2 tag is then prepended with the RC4 and Base64 encoded data as follows:
PKT2
RC4_BASE64(registration_data)
As a result, the version_number, operating_system and user_name is never sent to the C2. This bug will likely be fixed in future versions of the malware.
Figure 16 also shows that the branch ID and version number are no longer hardcoded unlike previous versions, with the encrypted version number and branch ID decrypted with an XOR key (0x3c).
Tools
Zscaler ThreatLabz has developed an IDA script to decrypt the Xloader’s encrypted code. The code is available in our GitHub tools repository here.
Conclusion
Since its inception, the Formbook and Xloader malware families has been a prominent threat. The threat actors behind it continue to update and improve the malware code in an effort to hinder analysis. In the most recent version, the threat actors increased the level of complexity yet again with additional layers of encryption for critical parts of the code and important data. However, Zscaler researchers have been able to unravel these obfuscation layers and analyze the key components of the malware code.
Cloud of Sandbox Detection
Zscaler’s multilayered cloud security platform detects Xloader and Formbook indicators at various levels, as shown below:
Win32.PWS.XLoader
Win32.PWS.Formbook
Indicators of Compromise
Variant
Version
SHA256
Botnet
XLoader
4.3
9e1b4f2d408e187ca641c0c16269069d0acabe5ae15514418726fbc720b33731
6qne
XLoader
4.3
f55ce0741ed4615bae5646c644b3a971323ac344b12693495d5749c688d5d489
6qne
XLoader
4.3
3bd86f3906f59f627bf65664d2bfacf37a29dbaafeae601baf5eeb544396f26c
6qne
XLoader
3.9
8e12b85676aaf45a93c91e2db2065151e19f184907da6d85701ac3b13d0e6052
nvp4
XLoader
3.9
6a726fb5c93adbae0f3061b40b19745587c0114deb86bd72c90acdd69242cbe0
nvp4
Network Indicators
Type
Domain
Harcoded C2 domain
jourmoe[.]com
C2 list domain
060jinbo[.]com
C2 list domain
10086253[.]vip
C2 list domain
117ygh9x[.]com
C2 list domain
365-8119[.]com
C2 list domain
365heji[.]com
C2 list domain
4tx[.]ru
C2 list domain
667fm[.]com
C2 list domain
991-touring[.]info
C2 list domain
abttt[.]win
C2 list domain
adacaranya[.]com
C2 list domain
allforfun[.]online
C2 list domain
allison2patrick[.]online
C2 list domain
applicationsdown[.]store
C2 list domain
apsocreto[.]online
C2 list domain
avdeeva[.]info
C2 list domain
betfury-platform[.]net
C2 list domain
bilpoinsaat[.]net
C2 list domain
bocc[.]live
C2 list domain
bookinbournemouth[.]co[.]uk
C2 list domain
botanica-online[.]ru
C2 list domain
byfuture[.]biz
C2 list domain
canlicerrahi[.]xyz
C2 list domain
ceu84g[.]com
C2 list domain
chiyiqian[.]net
C2 list domain
christmatoy[.]com
C2 list domain
cinemamaxz[.]com
C2 list domain
coffeelectro[.]online
C2 list domain
dedmorozvidos[.]store
C2 list domain
difozaa[.]life
C2 list domain
dugebitv4[.]xyz
C2 list domain
eatgre[.]wiki
C2 list domain
expertponto[.]com
C2 list domain
farmanow[.]xyz
C2 list domain
flippingfrenzy[.]com
C2 list domain
g2fm[.]co[.]uk
C2 list domain
ginaandhipa[.]com
C2 list domain
graciesvoice[.]info
C2 list domain
guzmanmodels[.]com
C2 list domain
habka[.]online
C2 list domain
hal-skincare[.]com
C2 list domain
hiufouwnwk[.]shop
C2 list domain
hjiqa[.]com
C2 list domain
huifeng-tech[.]com
C2 list domain
identowel[.]com
C2 list domain
inigrey[.]com
C2 list domain
ituyiut[.]wang
C2 list domain
jimtrosper[.]com
C2 list domain
kajainterior[.]com
C2 list domain
loaddown[.]vip
C2 list domain
mgconsultantlogistics[.]com
C2 list domain
myif471ok9ipidk2kkl[.]xyz
C2 list domain
najdlegend1[.]com
C2 list domain
nnhuigou[.]com
C2 list domain
ogei[.]app
C2 list domain
poweroffer[.]net
C2 list domain
realtxt[.]co[.]uk
C2 list domain
seeword[.]site
C2 list domain
solutionsquik[.]net
C2 list domain
themas5erofssuepnse[.]cyou
C2 list domain
uevj[.]win
C2 list domain
vowlashes[.]co[.]uk
C2 list domain
wanknumbers[.]co[.]uk
C2 list domain
wsavxrg[.]shop
C2 list domain
zzaen[.]com
References
https://www.zscaler.com/blogs/security-research/analysis-xloaders-c2-network-encryption
https://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/
https://www.netscout.com/blog/asert/formidable-formbook-form-grabber
https://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I?utm_source=blog&utm_campaign=deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I
https://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii?utm_source=blog&utm_campaign=deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii
https://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-in-phishing-campaign-part-iii
https://www.fireeye.com/blog/threat-research/2017/10/formbook-malware-distribution-campaigns.html
https://research.checkpoint.com/2021/top-prevalent-malware-with-a-thousand-campaigns-migrates-to-macos/
https://research.checkpoint.com/2021/time-proven-tricks-in-a-new-environment-the-macos-evolution-of-formbook/
https://research.checkpoint.com/2021/stealth-is-never-enough-or-revealing-formbook-successors-cc-infrastructure/
https://research.checkpoint.com/2022/xloader-botnet-find-me-if-you-can/
The post Technical Analysis of Xloader’s Code Obfuscation in Version 4.3 appeared first on Security Boulevard.
Read MoreSecurity Boulevard
Views: 0
