CyberMalwareUse caseXDR

How to deobfuscate a malware dropper

RustyStealerDropper Use case

Hidden in your system and here to stay for a long time. Malware droppers might be considered by some as “only” being a way to delivery another malware, but detecting and deobfuscating them can be a real headache for you and your teams, as their impacts on infrastructures may be fatal.

Malware droppers do indeed show a remarkable capacity in remaining undetected, sometimes for a long amount of time. And this makes them a very stealthy threat for any security team. On average, it takes teams 78 days before finding and removing them.

Being able to deobfuscate them is essential to ensure any type of cyberprotection. In this article, our experts will show you how they deobfuscated a malware dropper. With this particular sample, they encountered a case of live obfuscation, that we will analyse later on. First, let’s use this case for some reminders.

A reminder: what are malware droppers?

The goal of a malware dropper is to get a malicious software, a payload, into your system. The dropper is the first step of a cyberattack. Thanks to the dropper, the malicious software will get into your system and be concealed. The malware dropper can get any type of threat into your system: ransomware, rootkits, trojans…

In the dropper sample used by our Threat Intelligence experts in this article, the RustyStealer malware is designed to steal sensitive information from infected systems: usernames, passwords, and any other type of credentials.

But how does the malware dropper get to your systems? Threat actors have found a lot of ways to get to their victims. Currently, several types of malware droppers exists. Email attachments, infected USB drives, or social engineering are widly known. But malware droppers can go a step further: botnets, keyloggers, or zero-day-exploit droppers are also used, amongst a lot of others.

In this use case, our experts worked on a DLL-Based Dropper: the dropper enters the system through Dynamic Link Libraries and contains a malicious software waiting to be executed.

How do they stay in your systems?

Once they got into your infrastructure, malware droppers will stay in order to execute their payload. Several tactics are used to evade detection. Layered obfuscation, encryption or decryption… are just a few examples of the techniques. Knowing these tactics is of course the key for the detection of malware droppers and the protection of your infrastructure.

For example, rather than deploying clear text malicious payload on the targeted devices, threat actors use droppers to execute this payload in the memory of the system, without being readable on the hard drive. This makes the attribution and detection harder for security teams.

Many droppers hide their payloads in resource and XOR with a static encryption key, which provides a quick packing feature (T1027.002) to evade automatic detection.

Deobfuscating a malware dropper: a use case

Our experts used the following sample of a RustyStealerDropper to analyse live obfuscation:



While obfuscation usually takes place during the development stage of the malware, live obfuscation occurs during the execution of the malicious software. The payload is changed dynamilcaly during the execution, making it very hard to find by using static analysis methods.

In our use case, the malware dropper is a Delphi executable (an executable file created using the Delphi programming), which contains a huge amount of code. Yet, the particularly interesting routines within it are remarkably small in terms of code size, consisting of only a few bytes.

Figure 1: Sample overview

Immediately, our experts spotted a suspicious resource which seems to contain scrambled data:

Figure 2: Sample resources

In this case, the obfuscated data is the dropped Dynamic Link Library (DLL), commonly used to store executable code and shared libraries in Windows environments. The decryption process of this DLL occurs in two distinct waves, each contributing to the gradual restoration of the original code and functionality.

In the first wave, the decryptor is decrypted:

Figure 3: First obfuscation wave

Once this process is completed, the decryptor is used to decrypt and load the DLL:

Figure 4: Last obfuscation wave

At this point, our experts used the TEHTRIS Sandboxes to finalize the deobfuscation. The sandbox will intercept the payload of the RustyStealerDropper in memory and still has some heuristics to statically reconstruct the encryption key along with the payload.

Once the sandox has done its job, it generates a very straight forward code to extract the payload from the original sample.

Figure 5: Script to download the payload

With this code, SOC analysts can decrypt the DLL to further understand why the binary was launched. As shown bellow, the TEHTRIS Threat Intelligence provides very detailed information on the threat, allowing analysts to finalize their investigation.

Figure 6: TEHTRIS Sandbox analysis report


Well hidden in plain sight… The use case showed just how stealthy a malware dropper can be. On top of that, live obfuscation is an additional challenge for security teams, and requires expertise and specialized tools. But with the right cybersecurity equipment, the deobfuscation can be achieved and the payload also downloaded and neutralized.

To protect their systems, security teams shouldn’t only rely on traditional cybersecurity tools. Threat Intelligence, and specifically sandboxes, are crucial in order to detect and neutralize these type of sophiscated threats.