In our previous blogs, we took an in-depth journey into the malicious world of the MAN1 malware group. We investigated a malicious macro embedded in a Word document sent via email. Part 1 is available here and Part 2 is available here. The macro was obfuscated and contained not only an encoded binary, but also encoded PowerShell commands.
We were able to catch Hancitor as it attempted to use process hollowing to evade detection. We did this by attaching OllyDbg to Microsoft Word and snatching the binary right as it was pushed into a running process.
This time we’re going to look at the binary Hancitor that we captured. We will be using IDA Pro to reverse engineer the malicious binary and take a deeper look. At the end, we will discuss some changes to this malicious attack used by MAN1.
As with any suspicious emails, you should avoid opening attachments from senders you do not know. Many users automatically open malicious attachments sent via email without a second thought, and the MAN1 group knows this and victimizes those users. You can avoid possible infections by not opening potentially malicious documents and attachments sent by unknown senders.
Remember, the Hancitor sample we examined in Part 1 and Part 2 is associated with the MAN1 Group. As we wrap up analyzing this attack vector by the MAN1 Group, we have been able to learn some of the attackers’ tactics and techniques. We used this knowledge to track their campaign. We continue to watch for and anticipate changes. With that information, we can do a better job of blocking attacks similar to the ones seen with MAN1.
In our previous post, you learned about the 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.
We went over how the macro works by using its own base64 decoder. The payload (Hancitor) was encoded and embedded within a secret form field in the VBA project (the macro). They also used uncommon native Windows API calls to interpret and execute the encoded shellcode instead of using VBA APIs to directly run the binary.
I took you step by step into the makings of the script and we stepped into process by attaching OllyDbg and carving out the binary before it was injected into a running process. Remember, this malware is “fileless.” The macro avoids dropping the file and tries to sneak by anti-malware detection.
Here’s What’s New in Our Research
Today, we are going to look at the malicious binary Hancitor that we carved out from last time. The binary is a small file that includes some system environment checks, an internet connectivity check and a command and control call out, before unlocking a command switch table that the attacker will use to send commands to the infected system.
As you remember from Part 2, the malicious binary was carved out of memory right before being pushed into allocated memory in svchost.exe, illustrated in figure 1 below. We will examine this binary with IDA Pro where we can easily disassemble and analyze it.
Figure 1: Hancitor About to be Pushed Into svchost.exe.
Now that we have the file in IDA Pro, we can see in figure 2 below that the file first checks to see what the computer name and system version is.
Figure 2: Hancitor Querying Computer Name
The first major subroutine is the malware both checking to see if it has a network connection and querying the IP address of the victim. The malware calls out to ‘api.ipify.org’ to get this information, seen in figure 3. After checking for a successful connection (figure 4), the malware will initiate a network POST to the command and control server.
Figure 3: Network and IP Call
Figure 4: Network Response Check
Figure 5 illustrates the POST information which will include basic system reconnaissance information:
System info (GetVersion, GetAdaptersAddresses (physical address and adapter is used to generate a GUID))
Hostname (GetComputerNameA and contact that string with ‘0711’ and the user that the explorer.exe process is running under)
IP (from ‘api.ipify.org’)
System architecture 32 or 64 bit. (GetWindowsVersionInfo)
Figure 5: Network POST Information
After this information is sent to the command and control server, the malware checks for a response to see if there were commands sent from the owner of the server (figure 6). If there was not, the file sleeps and tries again.
If commands were sent, the file exits that subroutine, checks again for the command, and goes to a command switch tables routine to find the right action for the command sent (figures 7 and 8).
Figure 6: Check for Command or Repeat
Figure 7: Second Check for Command Before Going to Switch Table
Figure 8: Switch Table Sub Routine is Called
Figure 9 shows the command switch table which holds a list of cases to be triggered by the command sent from the command and control server. The possible options include:
Case 114: receives command “r”, download secondary file and execute
Case 108: receives command “l”, download a DLL and load w/ parameter
Case 101: receives command “e”, download a DLL and load w/o
Case 98: receives command “b”, download an exe and inject to svchost.exe
Case 99: receives command “c”, download a configuration file
Case 110: receives command “n”, do nothing
Figure 9: Switch Table
The command switch table is where we leave the journey. From this table, the malware will either execute the commands given, or do nothing and end process.
Analyst comment: Given the ability for the malware to receive and execute commands, Hancitor can be considered a remote access tool (RAT), while the malicious Word document with the malicious macro is a type of trojan.
Now, we will talk about some changes that have been made to the macro and the switch table.
Our macro used a lesser known API call ‘CallWindowProcA’ to point to the executable memory location. It used this API to avoid suspicious API calls viewed as ‘red flags’ to an analyst, like ‘Create Process’, ‘WriteProcessMemory’, ‘CreateEvent’, and ’ShellExecute’. Newer versions of the macro are using API calls such as ‘CreateTimerQueueTimer.’
An important thing to remember about these API calls is that they can store temporary data for execution. The attacker understands this and chooses uncommon API calls that have this ability to stay one step ahead. Because these API calls are uncommon, most antivirus products do not have a signature created to catch these calls, thus enabling the attacker to avoid detection.
Other changes include fewer packed binaries being injected into running process and fewer checks. The older versions would check to see where the process was running from and check the file name, as seen in figure 10. If the file had not run before, the malware would unpack and execute via process hollowing (figure 11). Also, other versions of Hancitor have removed ‘terminate process and delete self’ from the command switch table.
Figure 10: File Check
Figure 11: Unpack and Run
MAN1 does not rely on any out-of-the-box malware, but instead relies on specifically crafted and engineered payloads to more easily bypass traditional antivirus solutions. The attackers have already made small changes to the malware since we wrote Part Two of this writeup, two weeks ago, to stay ahead of antivirus solutions.
These small changes could potentially mean that the MAN1 Group is monitoring detection rates or some other statistics in relation to infection rate. You must remember that malware is often a big payday for the bad guys. We expect to see the malware continue to evolve and become more sophisticated.
In any case, if you use our endpoint protection product, CylancePROTECT®, you were already protected from this attack. Cylance’s script control policies will protect you and continue to protect you despite the changes attackers make to the MAN1 Group. If you don't have CylancePROTECT, contact us to learn how our AI based solution can predict and prevent unknown and emerging threats.
Indicators of Compromise (IoCs)
70E5F1C9603B5F4D4741A6810F2F07DCDAEEC063AF7046066D88AA40EF1A00DB (carved binary)
About the Cylance Threat Guidance Team
The Cylance Threat Guidance team examines malware and suspected malware to better identify its abilities, function and attack vectors. Threat Guidance is on the frontline of information security and often deeply examines malicious software, which puts them in a unique position to discuss never-seen-before threats.