Hancitor can be grouped into the category of downloaders that are often responsible for delivering further malware families into a compromised network. Recently, it has been observed delivering the Ficker Stealer , Cobalt Strike, and the Cuba ransomware among others. It is usually distributed to the victim via malicious spam campaigns that are intermittent in nature. In this Malware Analysis Spotlight, we will look at Hancitor’s behavior and ability to deliver an information stealer.
View the VMRay Analyzer Report for the Hancitor Infostealer
Analysis of Hancitor’s Configurations
If we extract the buildID from Hancitor’s configuration, we are able to notice the fact that Hancitor seems to be distributed in waves. The malspam with a particular build is sent for a period of time, after which there is a pause in the distribution before a new wave of malspam distributes another build (Figure 1). Some of the spam waves produce more unique samples than others but the overall trend is pointing upwards. Usually, each batch has a unique configuration containing a new buildID and new C&C URLs (see Extracted Configurations for a non-exhaustive list of configurations).
Figure 1: Line graph where the points on the x-axis indicate the date extracted from the config and the y-axis indicates the number of samples associated with a buildID.
Hancitor Analysis
The usual execution chain starts with malicious emails containing an embedded Google Docs URL. Those URLs point the user to a domain controlled by the threat actor. There, the victim is prompted to download a document. This dropped document is responsible for extracting and loading a DLL. The method that the malicious document uses to achieve execution is usually a VBA macro that is executed when the document is opened (Figure 2). The initial DLL is an intermediate stage responsible for extracting and running Hancitor.
Figure 2: Malicious document telling the user to enable editing.
The VBA macro’s main responsibility is to execute the embedded DLL. The DLL doesn’t require a specific entry point to run, but it’s still invoked with one. The passed entry point isn’t used by this initial DLL, but by the actual Hancitor payload at a later stage of the execution process. For Hancitor to run, it’s necessary to start it by calling one of its exported functions. The name of the function is hard-coded inside the macro code (Figure 3).
Figure 3: VMRay Analyzer – Excerpt of the macro responsible for starting the embedded DLL (top) and a VTI tracking the dropped file (bottom)
The document’s macro is loading the DLL by using the rundll32 utility. By observing the process creation in the VMRay Analyzer we can also see the passed command line arguments. The called entry point corresponds exactly with one of Hancitor’s exported functions (Figure 4).
Figure 4: Monitoring of the rundll32 processes in VMRay Analyzer (left) and the export directory of Hancitor (right).
The initial DLL is a packer that is responsible for decrypting, decompressing, and loading the Hancitor payload. The compression library used by the packer is aPLib . aPLib became quite popular with malware authors due to its small footprint and relatively good compression and decompression speed. Nonetheless, the smart memory dumping of the VMRay Analyzer includes the memory dumps of each stage which also contain the final uncompressed Hancitor payload (Figure 5).
Figure 5: VMRay Analyzer – The final Hancitor payload extracted from one of the buffers (top) and the corresponding matching YARA rule (bottom).
The DLL itself and the techniques it uses are very similar to the ones previously used by, e.g., Dridex . When it’s finally Hancitor’s turn to take over the execution flow, it first tries to initiate a connection to its C&C server. Usually, each Hancitor binary knows about three C&C URLs which are embedded in its configuration file. It gathers information about the infected host system (adapter addresses and the volume serial number) and uses that to generate a unique ID. It also checks the external IP address and the AD domain, if the host is part of any. It then bundles it all into the initial request to the server (Figure 6). Some of that information is used by the C&C server to deliver a specific payload. For example, in recent Hancitor campaigns it has been seen delivering Cobalt Strike if the host was part of an AD domain.
Figure 6: VMRay Analyzer – VTI rules matching the host discovery (left) and the C&C network connection containing the beacon string (right).
The response sent by the server is XORed and base64 encoded. The 1-byte XOR key required to decrypt the data is hard-coded inside the routine responsible for decoding. When the data is decoded, the command is extracted and validated. Then it’s processed and the corresponding action is taken. In this analysis, Hancitor downloads a secondary payload from a server which it receives from its C&C (as part of the response). It then starts svchost.exe and injects it with the downloaded payload (Figure 7). In this particular case, the delivered payload is a stealer.
Conclusion
Although the capabilities of Hancitor itself didn’t really change over the past years, the combination of a multi-step delivery process and different packers, still allows it to avoid detection and deliver further malware families successfully. VMRay Analyzer’s dynamic analysis plays an important role in the detection process and can provide defenders with timely information necessary to protect their networks.
IOCs
Initial document
SHA256:
e431a1bb2efcf6000f5bac4e19673d6deb9de7997dba5f65bae7779cd19e5cafHancitor DLL
SHA256:
82E13456113A950EE0FE06975CEC093B2D78F91E75D482428ECFA274EC7D2555
Extracted Configurations
Hancitor configuration in the MWCP schema:
{‘key’: [b’b27242d151accab3′], ‘missionid’: [‘3011_hjdfsfg’], ‘c2_url’: [‘hxxp://propywast[.]com/8/forum.php’, ‘hxxp://aribliffored[.]ru/8/forum.php’, ‘hxxp://frosemodynd[.]ru/8/forum.php’]}
