Introduction
Like all great malware stories, it starts with an email. Inside the email, a poorly written bait story catches your eye. Before you know it, you’ve opened a Microsoft Word document that has an embedded Visual Basic for Applications (VBA) macro script. You fell for it, hook, line, and sinker, and now the malicious document has fired off that macro.
The Actor
Don’t feel bad. The Man1 Group has been sending these emails for some time now, long enough for their attacks to garner attention from analysts that have developed a timeline of the group’s malicious campaigns. The campaigns contained different malware families. Analysts have been able to track the subtle tricks and routines in the packers and crypters used by Man1.
In April 2015, Man1 was using Dyre malware. Dyre downloads a binary from compromised websites. These downloaded files usually include a man1.exe file. Other networking tools, techniques, and procedures (TTP) were noticed by analysts, such as the servers used and URL construction for connecting to their command and control servers. Man1 overlapped some TTPs, thus making it possible to connect campaigns using different malware families.
In this post, we will look at their most recent campaign using Hancitor, also known as Chanitor.
Figure 1 (source: http://www.threatgeek.com/2016/07/tracking-man1-crypter-actor.html)
The Macro
This macro is no ordinary macro. Nay, this is a special macro that was given love. The author took the time to write their own base64 decoder. Why? Because the payload, a malicious binary called Hancitor, is encoded and embedded within a secret form field in the VBA project (Figure 3).
Analyst comment: Microsoft Word has a developer tool that you can debug the script with. We will be using it for this VB macro.
The macro can determine the architecture of the victim’s system on which it is running and has the ability to execute correctly on either 32-bit or 64-bit systems (Figure 2). If the VBA macro is running on 32-bit Windows, the process that will be created is: "%windir%\explorer.exe". If it is 64-bit, the process created will be: "%windir%\SysWOW64\svchost.exe".
Figure 2: 64 or 32?
But, if you are looking for the macro to drop the payload, it won’t. Instead, it will hollow out the Explorer.exe process and execute malicious code there. Ultimately, loading code in this manner does not limit the malware in any way. However, an important benefit of process hollowing avoids writing the malicious code to disk. Most AV vendors are unable to detect this process.
Next, the VB script extracts encoded shellcode from a form field, injects it in the running Explorer.exe process, and executes it. First, the macro assigns the payload to a variable. In Figure 3, two versions of the same malware follow the same pattern for hiding the payload in the tab of a form. In the sample we will be following along with, the payload is assigned to ‘solder’.
Figure 3. The Payload in a Form Field Still Encoded and Embedded.
After some complicated running around in the function ‘household’, ‘solder’ will become ‘closet’ (Figure 4). Let’s go look at ‘household’. In function ‘household’, you can see variable ‘discrimination’ is the payload. ‘Discrimination’ is considered a string at this point. Our payload will be painfully moved, byte by byte, to an array called marmot.
Figure 4. 'Solder' is the Payload. ‘Closest’ is the Result ‘Solder’ Running Through Function ‘Household’.
Figure 5. Payload Being Moved Around
Next, in our handy VB debugger, we can watch each char being moved because it is being sent to ‘bathtub’ first. If you were to step into this script, you could watch this happen, byte by byte. After manually converting the string to a byte array, the macro XORs the payload (Figure 6) and moves the data to a local byte array (Figure7). Each character is assigned its own element.
Figure 6. Marmota (Payload array) Being XOR’d
As we start to get to the end of the macro which is also the start of the exploit, we get to the base64 decoder in function ‘household’ (Figure 7). Next up on this journey is ‘Achlorhydric’. ‘Achlorhydric’ is the memory offset set up by ‘phyllostomidae’ (kernel32, VirtualAlloc) to store the base64 decoded payload (Figure 8).
Figure 7. Base64 Decoder in Function ‘Household’.
Figure 8. Achlorhydric is the Mem Offset Set Up by Phyllostomidae (kernel32, VirtualAlloc) to Store Base64 Decoded Payload.
This next part is the fun part. Now, an attacker can use the information found to attach to a debugger, like OllyDbg, and get the payload. The macro calls for the payload using the memory location from ‘jilted’ (payload location) and base64 decoded byte array ‘bogart’, which is the memory location to raw shellcode (Figure 9). In this macro, we not only have a payload to carve out, but we have encoded shellcode to find as well!
Figure 9. Calls Using Mem Location From ‘Jilted’ and Base64 Decoded Byte Array ‘Bogart’ (Bogart is Mem Location to Unencoded Shell).
Now that the code has been copied to executable memory, the macro sets up and API calls for CallWindowProcA (‘antique’). CallWindowProcA allows the malware to avoid suspicious API calls, like ShellExecute and CreateProcess. This macro is very sneaky (Figure 10). The first value to this call is the memory offset (‘achlorhydrice’ +’porzana’) and that is a function pointer within the code. 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.
Now, if you want to have some extra fun, you can attach OllyDbg to memory offset location and get Hancitor. Hancitor is the malicious binary that this macro was designed to execute. Remember, this end part of the macro is where a process will be hollowed and Hancitor will run.
Figure 10. These Actions Redirect Code Execution to the Malware’s Shellcode.
Impact
The macro used by the Man1 Group is no ordinary macro. The macro can determine the architecture of the victim’s system on which it is running and has the ability to execute correctly on either 32-bit or 64-bit systems. Then, it will hollow out memory in the Explorer.exe process and execute malicious code there to avoid writing to disk. Most antivirus (AV) vendors cannot detect this process.
Once it does this, the macro finally allows a malicious binary called Hancitor to run. Once executed, the binary drops an intermediate payload that further downloads additional malware that performs data theft and connects to a command and control (C2) server.
In a follow-up piece, we'll take a closer look at Hancitor and demonstrate the flexibility and configurability of this malware. Allowing this macro to successfully load Hancitor into memory and execute it opens up the user to a wide range of potential follow-on attacks.
Conclusion
Thank you for taking the analyst’s journey through the macro with me. As you can see, it’s a sophisticated macro. With two different hidden gems to find in the macro, how can you not take it apart?
You can also see why some 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. If you don't have CylancePROTECT, contact us to learn how our AI based solution can predict and prevent unknown and emerging threats.
If you are using CylancePROTECT, you can rest assured that Cylance’s script control policies will protect you.
Figure 11. Cylance Has Stopped the VB Script.
Indicators of Compromise (IOCs)
SHA-256 Hashes
a7f37337ebacabe6f5e76981651ea3cafda56f99830fd22d28b5495e76dd8480
da56ac3755b1fb2d3fa777633dac1c8a9c237175ed1410a5e3eb715e2c61344e
Filenames:
Order_234073185.doc
3ba542e20f93a5257856597e1ec525dc.doc (possibly changed by user)
