In this article, we describe how Hancitor compromises systems based on its infection chain observed in January and February 2021. We cover its unpacking routine, information gathering and command and control (C2) functions, and payload execution techniques.

The malware Hancitor

Hancitor (aka Chanitor) is a downloader which is used to gain initial access to a victim’s computer. Its main purpose is to download and execute a second stage malware payload from one of multiple encrypted URLs contained in the malware itself. This downloader was first seen in 2014 commonly deploying Pony and Vawtrak malware. Like many other malware families we saw Hancitor become active again in early 2021 following the festive period. The first Hancitor malicious spam wave of 2021 started on 12 January, where the malware was distributed as email Word document attachments. Since then, almost every workday we have seen Hancitor activity.

Word Dropper used by Hancitor

On Tuesday 12 January, phishing emails with hyperlinks leading to Word documents reached users’ inboxes. The Word documents were droppers that install and execute the Hancitor downloader. When opened, the user sees a social engineering image telling them that they must click the “Enable editing” button to see the document’s contents.

Figure 1 – Word document lure requesting the user to run the VBA macro.

Analyzing the attachment using oledump shows that not only VBA macros but also an Object Linking and Embedding (OLE) object are embedded in the document. To find out how the OLE object is used and how the malware infection happens, we analyzed the VBA macros using Word’s developer tools.

Figure 2 – Output from oledump showing the VBA macro in the Word document.

The VBA code is distributed over several different modules inside the document and is executed by the Document.Open event. The OLE object is then saved with a “.tmp” file extension into one of the local temp folders under “C:\Users\[username]\AppData\Local\Temp”. As the VBA code does not know where the file was stored, it then recursively searches through all local temp folders.

Figure 3 – VBA macro which moves the tmp file to the templates folder as a DLL.

Once the “.tmp” file is found, it is moved and renamed to the Office templates folder (C:\Users\username\AppData\Roaming\Microsoft\Templates) as “W0rd.dll” and loaded using rundll32.exe. As a second argument, the macro passes the entry function “DllUnregisterServer” to rundll32.exe so that the execution starts correctly.

Figure 4 – VBA macro which runs rundll32.exe to load the malware.

Packed DLL analysis

Briefly looking at the DLL characteristics shows that there are two unknown sections, which could be an indicator of packing being used to obfuscate the malware. Opening the DLL in a debugger and running through the program, focusing on what is happening with the suspicious sections confirms that there is indeed some sort of unpacking happening.

Figure 5 – Sections of the PE file (“W0rd.dll”).

Although the unpacking procedure happens in multiple steps, it can be described in two broad stages:

Decryption Stage 1

First, the malware allocates new memory which is used to copy the data from section “.rdata4” into it. The data, however, is not copied identically from the section to the new memory region because the bytes containing 0x21 are omitted. As soon as the copy operation is finished, the decryption process starts. The first four bytes at the beginning of the newly allocated memory indicate the length of the data that will be decrypted. The algorithm to decrypt the data is simple. It uses an XOR operation with the key and plaintext being incremented after each four-byte operation. To start, the key is initialized with 0xD508. A replication of this algorithm, written in Python, can be found in our GitHub repository.

Figure 6 – Data view of the section containing the encrypted malware.

Looking at the decrypted data and the behavior of the program, we can see that there are multiple areas containing different types of information. The names of Windows API functions are stored in the first 150 bytes. The area after this contains encrypted data. Finally, the executable code used to decrypt the encrypted data is located at the end of the section. Figure 7 shows the structure of the memory section.

Figure 7 – Structure of the encrypted section.

The API function located at the beginning of the memory section are resolved using GetProcAddress. However, instead of being resolved within kernel32.dll, they are resolved in kernelbase.dll. This is important to note because when debugging Hancitor samples, breakpoints are most commonly set on functions from kernel32.dll and thus would not be triggered during execution. After resolving the functions, the second decryption stage occurs.

Decryption Stage 2

As indicated, the decrypted memory structure contains executable code. As expected, the instruction pointer jumps directly to this section, which also contains the decryption algorithm for the second stage. Before the decryption starts, new memory is allocated and the encrypted data from stage 1 is copied to it. The decryption algorithm of stage 2 is generally the same, but uses 0x3E9 as the initialization key. The output of this decryption leads us to a PE file.

Figure 8 – Overview of Hancitor’s decryption procedure.

The copy procedure is done section by section to bring the executable into the loaded form. This technique is called self-injection or PE overwrite. To make the new image runnable, several Windows API functions are resolved using GetProcAddress and directly patched into the memory of the loaded executable. These function addresses vary from installation to installation, so this patching cannot be done by a static unpacker. For all the other decryption procedures described, you can find a static unpacker script in our GitHub repository. To effectively run the new payload, a return to the correct DLL entry point is made. It is important to note that the AddressOfEntryPoint in the optional header does not match the exported functions DllRegisterServer or DllUnregisterServer and it is necessary to run one of the exported functions to start the malware. When using x32dbg to analyze the sample, simply patching the AddressOfEntryPoint to one of the exported functions makes the DLL runnable.

Running Hancitor Malware

As soon as the unpacked executable is running, the malware gathers information about the infected system. The following disassembly shows calls to multiple functions used to collect the information.

Figure 9 – x86 disassembly of Hancitor’s information gathering function.

First, the malware calls a function we named “getComputerInfo”. This function obtains the username, the computer name and the domain of infected system. The subsequent functions collect additional information such as the machine’s public IP address, domain trust information and the computer architecture. The malware identifies the computer’s public IP address by making a HTTP GET request to “hxxp://api.ipify[.]org”, a free public IP address API. All the collected information is then put together into a query string which is generated based on the computer architecture.

Figure 10 – Query string containing system information before being sent to the C2.

To determine the command and control (C2) servers waiting for the data to be sent to, the malware calls a decryption function that uses the RC4 algorithm to get a list of potential C2 URLs.

Figure 11 – URL and build decryption function.

After successfully decrypting the C2 URLs, the data is sent there using a HTTP POST request adding the constructed query string as data. To increase the probability of reaching an active server, the malware iterates over all the decrypted C2 URLs and tries to reach all of them until one of them sends a response.

Figure 12 – C2 communication function.

We assume that based on the received data the C2 server responds with either a simple string which can be decrypted to an active malware download server or with garbage data in the form of a simple string. Although the decoding algorithm of the C2 response looks quite complex, it is actually Base64 decoding, followed by an XOR operation using the key 0x7A. If the decryption leads to a valid URL, the malware initiates a download, which delivers an executable. To execute the binary, Hancitor uses one of the following techniques:

• Create Process
• Create Thread
• Process Hollowing
• Thread Execution Hijacking

Create Process

If the method “Create Process” is chosen, then the malware writes the retrieved executable to disk into the temp folder and executes it using rundll32.exe with “start” as the argument for the entry function.

Create Thread

The Create Thread method is as straightforward as Create Process. The malware simply allocates some memory, writes the malware into it and creates a new thread from it.

Process Hollowing

If the Process Hollowing method is used, a new svchost.exe process is created in a suspended state. The malware then allocates new memory in the newly-created process, writes the executable to it and executes it in a new thread.

Figure 13 – Process creation function.

Thread Execution Hijacking

The final execution method Hancitor supports is Thread Execution Hijacking. This method is mostly the same as the above described Process Injection method. The only difference is that the malware replaces the thread context with the downloaded executable and resumes it afterwards.

Conclusion

This article should give a good overview of Hancitor’s capabilities and behavior as of February 2021.

Indicators of Compromise (IOCs)

A list of IOCs is also available in the HP Threat Research GitHub repository.

Hancitor Word documents:

111a2dc96e082b86a79dd90ec307c977a21c7aee0ddb141d688a17bd65f3661d
40c3eb22a02601cf70a4ae08eeaa5805144386bc13882e5f110c133b1d0ede8e
678da85cecff2cdda8559281dfc8a89f87c44c6371cbda4de4bc9ea5cd2f5cf9
772c897ffdfb824b31d70ea360224714ab9bb83659bd431897cc74dd2defc2f3
080bade36015dd79925bab0975ac0f30f18424bdd1e7836d63c2dee350bdbd69
22043734ed3f774db7a88297286f6ecd56336d755cc19f1bd54f2a2ac58982cd
2ac3b573d70c40c5c0fafe4e5914c723f2322a1c9cd76d232447654604ff8b76
385425e94ed8ac21d7888550743b7a2b89afbeb51341713adb6da89cd63b5aff
3ffe9ef810d01e9f242558ba59e8c7483adb72e087132cb0fd1e55171c45690f
51dd023b55be138ac7cfe7379a55c0a2a46c01cd3b3f96a151b0a27ed9e12485
56f1795abf78f798a51b9224a5deb17aedd924629136832b526c93339f525e56
6cd76e8f33a945b51d20b909495bbc613f78151dbea6c3a7a3a235bfd2167cdf
7b013a271432cc9dea449ea9fcf727ed3caf7ce4cc6a9ba014b3dd880b5668dd
8bcf45c2de07f322b8efb959e3cef38fb9983fdb8b932c527321fd3db5e444c8
99b98b8c7033456ba7840ad99c65347a8026aee62bccbbac6d22ca4b0f5dfa1e
a1ec1a483f549af7e6f26ffe8b2c2ef6ac8c8f0d99349350c1df5eaa327f1ed3
b1502cdbb5aeee57d0a5d38945c64855ba35c25d43a71bd72c3cf31665e5aa62
cab2a47456a2c51504a79ff24116a4db3800b099ec50d0ebea20c2c77739276d
d6755718c70e20345c85d18c5411b67c99da5b2f8740d63221038c1d35ccc0b8
ed3fa9e193f75e97c02c48f5c7377ff7a76b827082fdbfb9d6803e1f7bd633ca

Extracted OLE Object (DLLs):

Ce2449b7f600b0317614419159e9364e1a76613ac0cb112c88be171638573049
0941090d3eb785dbf88fbfafffad34c4ab42877b279129616a455347883e5738
6caccc64a9db7cfce75076ad273d85d108f5b764fcbbb865fd27c91f86cccfad
c5385df4db1e69b06cf36f4481365d1101679a5764d721e369ea1d5d4c4b6b2c
288fdf9c64da0251107df7f1c3283f328279ad581710a9cf71f67e53b0b1684d
c3e06473c4c3d801c962e6c90ccbcab3d532fb5a6649077ea09cd989edf45eaf
cdcd5ee8b80d3a3863e0c55d4af5384522144011b071d00c9c71ae009305f130
43690eaf47245d69f4bda877c562852e4a9715955c2160345cb6cc84b18ca907
00b2312dd63960434d09962ad3e3e7203374421b687658bd3c02f194b172bfe3
372da9447db4ca966a6a9fd45f12519637a562953a88b6d92fb26d3699c14799
878319795a84ebfe5122d6fc21d27b4b94b3c28ad66679f841dec28ccc05e801
82c9bc479ea92c1900422666792877e00256996ce2f931984115598ed2c26f23
edabef17fce2aaca61dbd17a57baf780cd82a2b0189b0cf3c5a7a3ca07e94a44

Unpacked Hancitor (without patched function addresses):

1c55c9e30e3e2a4837afd80e6fc75518494af379835f4b2a7f0eaf815d697951
419fda1fec9e44d7988ceeb9c5742a09198e6fa7f213c23b7c064e56cbd50b40

C2 URLs:

hxxp://requirend[.]com/8/forum.php
hxxp://spabyasiande[.]ru/8/forum.php
hxxp://conlymorect[.]ru/8/forum.php
hxxp://fruciand[.]com/8/forum.php
hxxp://forticheire[.]ru/8/forum.php
hxxp://nentrivend[.]ru/8/forum.php
hxxp://cloolyepervir[.]com/8/forum.php
hxxp://areentthrices[.]ru/8/forum.php
hxxp://syleclisizame[.]ru/8/forum.php

Build IDs:

1301_dsf7823
1101_jh372
2001_6tc3ers

Malware download URLs:

hxxp://anabolicsteroidsbuy[.]info/nedfr.exe