By Gergely Revay | November 15, 2022
This post will discuss the solution to the specific technical challenges we faced when analyzing the malware described in the blog “Fake Hungarian Government Email Drops Warzone RAT.” The final payload in that campaign, Warzone RAT, was deployed through a chain of increasingly obfuscated .NET binaries. Each stage loaded the next from somewhere in the binary, decoded it, loaded it into memory, and invoked a function to pass the control-flow to the next stage. Such a multi-stage loader can make dynamic analysis difficult because every time the malware sample is restarted, navigating through the different stages can be challenging. To circumvent this problem, we created standalone executables from the various stages to enable more efficient debugging. This is what we are going to discuss in this post.
Problem statement
Figure 1 shows the deployment chain of the Warzone RAT in this particular attack. The phishing email contained a zip file. That zip file contained the binary 1) shown in Figure 1.
Figure 1 – The unpacking process
Once 1) is executed, it loads 2), KeysNormalize.dll a .NET Dynamic-Link Library (DLL) that was unpacked to memory. It is run by invoking one of its functions (sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY()). This post discusses how 3) can be recovered using debugging. One approach is to dump KeysNormalize.dll from memory using dnspy as a debugger. It had been obfuscated with the obfuscation tool called SmartAssembly.
To find out what the third stage is (Metal.dll) and then dump it into a file, we need to be able to debug KeysNormalize.dll. But before we can do that, we face the following challenges:
- How do we run the KeysNormalize.dll independently of the executable that originally unpacks and runs it in memory?
- How do we create an environment for KeysNormalize.dll where it can drop the next stage, as in the original malware?
