Frida-JIT-unPacker: An Imperva Contribution to the Security Research Community, Presented at Black Hat Asia 2024

In the ever-evolving landscape of cybersecurity threats, the battle against malicious bots is a critical concern for web applications. These bots, in addition to their ability to circumvent application security measures, are usually protected with advanced source code protection to prevent the security community from understanding their mechanisms and developing countermeasures. 

To counter this, Imperva Threat Research developed, released, and presented a new tool designed to overcome specific malware .NET protection, called Frida-JIT-unPacker. In this blog post, we’ll delve into the story of this research and the tool itself.

First of all, let’s outline a few specific types of bot threats and why you may be confronted with them. If you want to read more about these threats, you can look at OWASP’s list of automated threats to web applications.

Credential Stuffing

Credential stuffing attacks involve bots using stolen account credentials to gain unauthorized access to user accounts. The automation of these attacks allows for simultaneous assaults on numerous accounts, leading to widespread unauthorized access and fraud.

Scalping

Scalping bots swiftly purchase inventory of highly sought-after items, such as concert tickets or limited-edition products, making these items unavailable to genuine customers. These bots profit by creating artificial scarcity and reselling the items at high markups.

Scraping

Scraping bots automate the extraction of large amounts of data from websites without permission, which can range from product details to user information. This unauthorized data use can undermine the site’s value and breach privacy policies.

These are just a few examples of how bots can threaten web applications. For a comprehensive list of automated threats, the OWASP Automated Threat Handbook provides detailed information.

Development of Frida-JIT-unPacker

From the need to reverse engineer a particularly advanced .NET bot, protected with a source code protection (packer), we developed a tool we dubbed Frida-JIT-unPacker (FJP). It proved effective for deconstructing the bot, extracting its source code, allowing a deeper analysis, and ultimately providing a mitigation. 

We’re publishing this tool in our GitHub repository to contribute to the Security Research community. We believe this tool can prove useful to researchers dealing with similar or other kinds of malicious .NET software.

How does it work ?

To explain how the tool works, let’s discuss its development story:  When I got access to the bot binary, my first reflex was to open it with the popular DNSpy software in order to read the IL code and decompiled code the software was able to generate (see Fig. 1).

Fig. 1: malicious sample opened with DNSpy software

Surprisingly, no logic was found– only functions with gibberish names and the following expression as body:

Throw new Exception (“[…]”)  At this point, I was not sure if it were a failure of the DNSPy program or some strange behavior in the assembly leading to this. 

How could this software run properly if the logic was not part of the assembly? In order to answer this question, I started to read more about the structure of .NET samples, as I was not very familiar with this format before this research. .NET executable is a subtype of Portable Executable (PE). There are many resources available sharing knowledge about this file format. For the purpose of explaining the tool, we’ll talk about it shortly. 

A PE is separated into multiple native sections, each of them having a dedicated role. The number of the sections as well as their type varies, depending on the executable. The most important one is the .text section. It usually contains the logic of the application. In the case of a .NET sample, it contains the .NET section. The .NET section includes the CLI header and CLI Data:

Fig. 2: Assembly Headers from ECMA 335 II.25.1, Structure of the runtime file format.

This CLI header includes several useful bits of information, including: 

• The token of the entry point method
• The relative virtual address of the metadata tables

These tables are located in the CLI Data.

In these tables, each entity is listed according to its type in ascending order of its index. This is where, for each method, we can find the relative virtual address for its definition (see Fig. 3 for the first entry of the MethodDef table).

Fig. 3: First entry of the Method

In a 64 bit sample, each row consists of 16 bytes of information. It starts with the relative virtual address for the method definition and is followed by additional metadata.

This element is interesting from a reverse engineering perspective, because if we’re able to recover the original definition of method, we’ll be able to reroute the index to the original method definition – assuming we can recover it.

Now, let’s talk a bit about the compilation process of a .NET assembly. The entry point for the compilation is the compileMethod function. This function takes as argument a  CORINFO_METHOD_INFO structure :

Fig. 4: .NET assembly compilation function

This structure is a key element here because it includes valuable information associated with a specific method (body as ILCode, header information …) that can help rebuild it.

Besides this entry point, other key functions enter into play: 

For example, resolveToken is used by the Compiler to determine which entity (methods, types …) is associated with any token embedded in the ILCode. This function takes a single argument of type CORINFO_RESOLVED_TOKEN, at the same time input and output:

Fig. 5: resolved token structure

The list of output handles – generated at runtime – uniquely identify a specific entity.

Fig. 6: Metadata token embedded in IL code

Therefore, even if the tokens are manipulated by the packer, this API provides a way to recover them.

Behavior of the packer

The code protection solution used by the malware was to remove any logic from the .NET section and replace it with fake data, intercept multiple relevant APIs from the CLR (Common Language Runtime), – including CompileMethod, or resolveTolen for example.

Then, the packer would substitute the fake data with the appropriate one during runtime.

Description of the tool

The tool we developed (FJP) uses Frida, the popular dynamic instrumentation toolkit, to intercept communications within the CLR APIs in order to collect the clear data processed by the CLR engine after the packer replaced the encrypted value with the original one. In a few words, this tool exploits Frida’s disassembling capabilities to place hooks with high granularity: at low level functions, outside of likely monitoring points, and at addresses less likely to trigger any anti-reverse engineering mechanism by the packer.

Below is a figure that describes the principle of the tool :

Fig 7: High level representation of the FJP

For confidentiality reasons, we won’t show the source code of the advanced bot mentioned above. However, to illustrate its behavior, we used it to unpack a malware protected with a similar technology.

Fig. 8: Left, packed assembly – Right, recovered one

The innovation of this tool earned it a spot at BlackHat Asia 2024, where we had the opportunity to present our findings to the cybersecurity community. 

Conclusion

Frida-JIT-unPacker represents our contribution to aiding cybersecurity researchers in this ever-evolving cat and mouse game. We remain committed to proactively monitoring and addressing emerging cyber threats in the field. Try it out, join our efforts by contributing to its development, and follow Imperva for the latest updates and insights in cybersecurity innovation. Your input and feedback are vital to advancing our collective security.

Imperva Threat Research is constantly evaluating new bots and their operations to enhance the market-leading Imperva Advanced Bot Protection and to mitigate the most sophisticated automated threats, including all OWASP automated threats. It leverages advanced technology to protect all potential access points, including websites, mobile applications, and APIs, all without affecting the experience of legitimate users.