Introduction
In a previous post, we took a long journey into the malicious world of Man1 group. We investigated a malicious macro embedded in a Word document sent via email. The macro is just the first phase of the attackers’ nefarious plot.
Today, we will dive deeper into the macro and look at the point where the macro transforms itself from VisualBasic to machine instructions. We’ll pick up where we left off, walking the reader through the steps of loading the raw code into memory, decoding the malware and providing details on how to extract the malware from a debugged process.
Impact
Remember, the Hancitor sample we examined in Part 1 is associated with the Man1 Group. As we dig deeper into the Man1 Group, we can learn the attackers’ tactics and techniques in order to track their campaign and watch for/anticipate changes. With that information, we can do a better job of blocking attacks similar to the ones we’re seeing with Man1.
In fact, between the time we started this journey today, a few changes to the malicious macro have been noted. Making changes to malicious files or payloads is a common tactic leveraged by attackers, as it aids in avoiding detection and it’s much easier than recreating the wheel by creating brand new malware.
We will cover those tactics and changes as we ascertain more about the malware and its behavior. Part three of this research will be published shortly and you will get to see the subtle changes.
Last Time
In our previous post, you learned about Man1 group’s primary method of attack. Attackers were sending malicious emails containing Word documents with malicious and interesting macros. We also talked about some of their techniques, tactics and procedures (TTP), such as the servers they used and the format of the uniform resource locator (URL) for connecting to their command and control servers (Figure 1).
Figure 1: Examples of Man1 Using Hancitor URLs
That macro was no ordinary macro, but one that was given extra care: the author took the time to write their own base64 decoder and the payload (Hancitor) was encoded and embedded within a secret form field in the VBA project (the macro). They also used native Windows API calls used to interpret and execute the encoded shellcode instead of using VBA APIs to directly run the binary. This helped the macro get past common anti-malware checks to inspect malicious use of these API calls.
I took you step by step into the makings of the script. We left it right at the end where the macro was going to decode, then inject its secret payload into a running process. Remember, this malware is “fileless.” The macro avoids dropping the file and tries to sneak by anti-malware detection.
Analyst comment: Microsoft Word has a developer tool that you can debug the script with. We will be using it for this VB macro.
Here’s What’s New in Our Research
This time, we are going to look at one spot in the macro where some magic is happening. We will be decoding the binary and seeing it before it is pushed into a process to avoid detection. From last time, we identified a specific memory location allocated by the macro script. We are going to use that important information soon, as it’s key to this attack. The memory location will be called, as you’ll see, which results in some interesting things.
There are two important pieces to look at before we can find the good stuff. The first value to this call is the memory offset (‘achlorhydrice’ +’porzana’), which is a function pointer within the code (Figure 2).
The second value is a string that goes to the path to our file for a handle. These actions will redirect code execution to shellcode. We need to set a breakpoint here so we don’t get lost. We are going to attach Ollydbg to this memory offset location and capture Hancitor.
Figure 2: These Actions Redirect Code Execution to the Malware’s Shellcode.
After we are attached to the WinWord executable and we have found the mem offset (achlorhydrice +porzana) from the VB macro, we add a breakpoint in OllyDbg. Then, step back into the macro and OllyDbg will hit on the breakpoint we set (Figure 3).
Figure 3: Add the Mem Offset (achlorhydrice +porzana) From the VB Macro and Add a Breakpoint in OllyDbg.
From there, the shellcode uses a function similar to LoadLibrary called LdrLoadDll. The function calls were embedded in the shellcode and, once they execute, we can see how they load the requested library (Figure 4).
It’s important that we recognize the use of this undocumented function in NTDLL. This indicates an advanced understanding of the low-level mechanisms of Windows. These guys are sneaky, and this advanced level of knowledge helps them continue to try and evade anti-malware detection.
Figure 4: The Shellcode Loads a Function Similar to LoadLibrary, Called LdrLoadDll
After initialization, the shellcode searches memory for a marker to lead it to the XOR encoded Hancitor. POLA is the 4-byte name we are looking for (Figure 5).
The base64 encoded binary is adjacent to the marker. The ASCII string ‘TVqQ’ represents the first 3 bytes of a base64 encoded MZ header (the third byte is variable). The specific POLA marker is unique to Hancitor, and it tells us where to look for the malicious binary.
Figure 5: Secret Code POLA
After Hancitor is in the clear, we can carve the binary out (Figure 6) and continue to analyze it with another tool and get even more useful information, such as a command switch table that can be used to execute specific functions in the malware without the need to rewrite the code.
Figure 6: Binary Starts at MZ
Conclusion
We still aren’t done breaking down Hancitor yet, but now you can see how intelligent this three-stage attack method is at getting the attackers what they want. The advanced knowledge of the low-level workings of Windows make these attackers considerably more sophisticated than most we see in the wild.
Man1 doesn’t rely on any out-of-the-box malware, but is instead crafted and engineered carefully to more easily bypass anti-malware solutions. You can expect that, when they shift to another attack chain, the malware involved will be even more intricate.
You can also see why some antivirus (AV) vendors can’t detect the malicious macro, making it a good choice for the Man1 Group to use as a delivery method. Users can avoid becoming a victim by not opening attachments from unknown senders.
If you use our endpoint protection product, CylancePROTECT®, you were already protected from this attack. You can rest assured that Cylance’s script control policies will protect you.
If you don't have CylancePROTECT, contact us today to learn how our AI-based solution can predict and prevent unknown and emerging threats.
Indicators of Compromise (IoC)
SHA-256 Hashes:
a7f37337ebacabe6f5e76981651ea3cafda56f99830fd22d28b5495e76dd8480
Filenames:
Order_234073185.doc
