Xloader - the next-generation Formbook, is a sophisticated strain of Stealer malware designed to steal user information, operating as MaaS (Malware as a Service), with an extremely affordable price that attackers must pay, which is only around $59 per month. However, this type of malware possesses highly advanced features to evade analysis and detection in the runtime environment.

Today, our team received this Xloader sample, with the hash of d18f7d5b06eb88a6be5bfa39f6aa3cfa, and the special is that the outer wrapper of this sample is written in the .NET architecture, but the inner Xloader payload is in the x86. So, to provide you with the most comprehensive overview of this type of malware, here is a detailed analysis of the Xloader malware - also known as the next-generation Formbook.

1. Overview

As always, here is the malware working flow

2. Step-by-step Analysis

The Sample is written to impersonate an electronic store management file with full functionality.

At first glance, it is very difficult to detect the malicious payload within the program. The malware possesses all the attributes and methods of a typical management program.

The malware payload is written in between the constructor function of the management program, within a class named: frmMain

The malware loads a resource named 'Denp' and proceeds to decrypt it. Afterward, it maps it into memory using Assembly.Load and invokes a method within the decrypted code

After decryption, the resource "Denp" becomes a .DLL file and is mapped into the process.

The decrypted file is a .NET DLL with the hash: 06dc1333af7361fb9ebebe5c4dbe58e4

The malware proceeds to map the DLL file into the process and exports the class named "Heapsort" belonging to the namespace Cafe77.Sorts.

The variable "st" contains parameters related to the image resource named "GPQR."

The image file GPQR contains bytes for crypto encoding and decoding.

In the Heapsort payload, the malware continues to decrypt DLLs one by one and maps them into memory.

The decrypted .DLL file has the hash: d991d37fe496742fb40fd4a0af1f1de1.

This library is also loaded into the process.

In the ReactionDiffusion library, the malware exports the class "ReactionVessel" and executes it within the "ReactionDiffusionLib" namespace.

This class is tasked with decoding data through various XOR algorithms to decrypt "GQPR" resource.

The decoded bitmap resource continues to be a .NET library with the original name "Tyrone.dll," having the hash 4e2d5a256e0b157942804d514696e939. This file contains the Formbook payload.

The malware exports a class named "j2y9MrEohddm17sWCu" from the namespace "UDdwVy85XYgMNYqJt7" within the recently decrypted Tyrone.dll library.

Here, the malware retrieves the addresses of API functions for code injection purposes.

The malware checks if a Mutex named "MARkeK3b" exists; if it does, the malware immediately terminates the program. However, if the Mutex does not exist, the malware proceeds to create the Mutex.

After checking the Mutex, the Formbook payload is dumped by decrypting the resource named "MARkeK3b" within the Tyrone.dll library.

This payload is Formbook, written in the x86 architecture.

The malware creates another process of itself in suspended mode to inject this payload.

The code being injected by using VirtualAllocEx, WriteProcessMemory and ResumeThread.

After successfully injecting the payload, the malware uses "ResumeThread" to start the process it injected code into.

Attach to this process and debug the code, you can refer to this method:

So we got the x86 core of the Formbook malware.

The sample uses the RC4 algorithm to encrypt and decrypt data and retrieves the address of the ntdll library to export functions.

Here, the malware continues to patch in order to modify and decrypt its own payload, resulting in a final payload that is a PE file.

This file has the hash: fe59ba0f2448bff25e7e6e30225bceb3.

The malware continues to manually load this PE file into memory for execution, starting from offset 0x23330.

In the initialization functions, the malware employs various methods to evade debuggers, including:

• Reading the BeingDebugged flag within the PEB (Process Environment Block).

  

• Reading DebugPort via NtQueryInformationProcess.

  

The malware checks a batch of running processes in the system with CRC32 hash values.

The malware checks the name of the currently running process itself. If the name is longer than 32 characters (possibly due to it being automatically hashed by virus databases), the malware immediately terminates the process.

The malware creates a MutexObject based on the value obtained from the computer's username.

After creating the MutexObject, the malware proceeds to create sections that serve the purpose of code injection.

The first selected process for code injection is the child processes of explorer.exe.

The malware then retrieves a batch of PIDs (Process IDs) of other processes that are child processes of the previously obtained explorer.exe process.

Using the upper method, you can attach to the injected process

In the selected child process of explorer.exe chosen for code injection, the malware uses NtCreateFile and NtReadFile to read a randomly chosen executable file in Syswow64. Afterward, it creates this chosen process in suspended mode, and then injects the shellcode.

This process is then mapped by the Formbook process and is resumed for execution.

The malware queries the computer architecture by reading the key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

The malware reads the CurrentBuild key to obtain the processor information.

The malware encodes the victim's machine Username in Base64 hardcoded algorithm.

The information obtained by the malware will include: xloader version, machine information, and the Base64-encoded username.

Here, the malware creates a thread to establish an external connection.

The malware creates a path to the registry to read the victim's webmail information

Some of the information stolen was browsers' saved account information:

• Internet explorer

• opera

• chrome

• firefox

• Vault

Crypto functions are loaded to recover the plaintext of the credentials:

The malware uses a UserAgent named "Window Explorer"

Then, this process searches and injects code into the explorer.exe process, to serve the persistence purpose

The malware generated a path to Program File (x86), with an encrypted user name to store its payload.

3. IOC

Persistance:

• Registry: HKEY_USERS\[User SID]\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• Image: %ProgramFiles(x86)%\[base64 + version]\[random generated].exe

C2C: The malware connects to a long list of legitimate URLs, but these two seem to be the real C&C addresses.

• www [.] aquatic-organisms [.] info

• www [.] usxqe6 [.] cfd