Introduction Xloader is an information stealing malware family that evolved from Formbook and targets web browsers, email clients, and File Transfer Protocol (FTP) applications. Additionally, Xloader may execute arbitrary commands and download second-stage payloads on an infected system. The author of Xloader continues to update the codebase, with the most recent observed version being 8.7. Since version 8.1, the Xloader developer applied several changes to the code obfuscation. The purpose of this blog is to describe the latest obfuscation methods and provide an in-depth analysis of the network communication protocol. We highly recommend reading our previous blogs about Xloader in order to get a better understanding of the malware’s internals.Key TakeawaysFormbook is an information stealer that was introduced in 2016 and rebranded as Xloader in early 2020. The malware continually receives enhancements, with the latest version being 8.7.Xloader version 8.1 introduced additional code obfuscation to make automation and analysis more difficult.Xloader supports a variety of network commands that may be used to deploy second-stage malware payloads.Xloader adds multiple encryption layers to protect network communications and leverages decoys to mask the actual malicious C2 servers.Technical AnalysisIn the following sections, ThreatLabz describes the key code updates introduced in Xloader from version 8.1 onward and the current network communication protocol. It is important to note that Xloader is a rebranded version of FormBook. Therefore, many parts of Xloader contain tangled legacy code that is not used.Code obfuscationThroughout Xloader’s development, the authors have used obfuscation at different stages of execution, such as:Encrypted strings that are decrypted at runtime.Encrypted code blocks consisting of functions that are decrypted at runtime and re-encrypted after execution.Opaque predicates in combination with bitwise XOR operations to decrypt integer values.Xloader still relies on the obfuscated methods listed above with some additional modifications, which are described below.Functions decryption routineAs previously documented, Xloader detects and decrypts each necessary function at runtime. This process involves constructing and decrypting two “eggs”, which mark the start and end of the encrypted function data. The function responsible for decrypting the encrypted functions at runtime has its parameters constructed on the stack. Starting with version 8.1, Xloader builds each parameter without following a specific order and, in some cases, builds each parameter byte by byte.The figure below shows an example of Xloader constructing the eggs prior to version 8.1 (top) with a consistent size and ordering, compared to the latest versions of Xloader (bottom) constructing the egg parameters out of order with varying chunk sizes before calling the decrypt function.Figure 1: Comparison of Xloader egg construction for function decryption.Even though these changes may seem minor, they have a significant impact on automation tooling. Since the order of the encrypted starting and ending arrays are no longer set, the function’s memory layout needs to be reconstructed properly to perform analysis and extract values, as typical pattern matching would not be able to assist. As a result, extracting these values at an assembly level becomes a tedious task. One tool that can be used when analyzing these changes is the Miasm framework, which can statically lift the obfuscated code and reconstruct the stack properly.Code obfuscation and opaque predicatesStarting with version 8.1, Xloader introduced more sophisticated obfuscation for hardcoded values and specific functions. Constant value obfuscation was present in previous versions of Xloader, but it was employed in much simpler cases. An example of an early, simpler constant obfuscation routine is shown below.var1 = 190;
// Sets var1 memory pointer to 0
erase_data_if(&var1, sizeof(var1));
if ( var1 == 0x91529F54 )
out = 0; // Never executed
else
out = (out + 0x6EAD60AC) ^ 0x6C69DE1C; // result: 0x02c4beb0In the latest versions, Xloader encrypts additional constant values. For instance, when adding the typical assembly function prologue bytes (followed by a series of NOP instructions) for a decrypted function, Xloader now decodes the prologue bytes using a bitwise XOR operation, as shown in the figure below.Figure 2: An example of Xloader’s function prologue bytes obfuscation.In addition to the enhancements described above, the custom decryption routine that Xloader uses to decrypt data is now obfuscated. The unobfuscated custom decryption function prior to version 8.1 is shown below.Figure 3: Xloader’s custom decryption routine prior to version 8.1.In the latest versions, Xloader passes a structure parameter that includes hardcoded values. The obfuscated function reads each required structure member and decrypts each value
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: