Threat Thursday: Hancitor Malware

Summary

Emerging in-the-wild in 2013, Hancitor (also known as Chanitor) malware relies on social engineering techniques, such as appearing to be from the legitimate document signing service DocuSign®. This malware deceives victims into allowing its malicious macro code to execute, thus dropping itself onto the victim’s machine.

After connection with its command-and-control (C2) infrastructure, Hancitor will attempt to download a wide range of further malicious components, depending on its operators’ latest malicious campaign.

Most recently, Hancitor has been observed downloading known-malware family Ficker (also known as FickerStealer) as well as a Cobalt Strike beacon payload onto victims’ devices.

Operating System

Risk & Impact

Technical Analysis

An attack by Hancitor malware initially begins with a malspam email that directs the victim to a webpage that serves a fake document. These malspam emails can use a variety of different lures. Recently, the malware has often posed as email from the legitimate and popular document signing utility DocuSign:

Figure 1: Example of fake DocuSign email

To further the appearance of being a genuine DocuSign email, the malware operators include support links redirecting the user to real DocuSign material. However, the link embedded in the “View Invoice” button shown above is not legitimate.

Victims who have been tricked into clicking this link will be redirected to a fake DocuSign download page containing a Trojanized Microsoft® Word document. This file contains the initial Hancitor payload as a Microsoft® Office document macro. Hancitor can also be delivered via Trojanized Microsoft® Excel® sheets, which operate in a similar fashion. As macros are automatically disabled by Microsoft, the malware relies on social engineering to deceive the victim into allowing macro execution.

Upon opening a Trojanized document, the victim will see a warning which reads: “Security Warning: Macros have been disabled.” This is the usual notification you’d expect to see when opening any macro-embedded Office document. To combat this security feature, the Trojanized Word document contains text that explains that the victim would need to enable these macros and waive these warnings, as “This document is protected.” This text is shown in Figure 2. Enabling these macros will allow the malicious code to execute:

Figure 2: Trojanized document containing Hancitor malware

After allowing the malicious macros, the code will drop the core Hancitor dynamic-link library (.DLL) and use further internal malicious commands to execute it.

Recently observed samples were typically dropped on the victim’s system in the following locations:

• %AppData% \Roaming\Microsoft\Word\Startup\
• %AppData% \Roaming\Microsoft\Template\

Note that these locations can vary, and they are not restricted or limited to just these two directories.

Another macro will attempt to run the malicious .DLL via RunDll32.exe, which is a command-line utility included on all Windows® devices. The malware contains an exported function found embedded in the malicious document, which is then used to execute Hancitor. This exported function is not limited to a specific name, and it is often unique to each sample:

Figure 3: Running of the Hancitor DLL

Once dynamically running, Hancitor will reach out to the web API at api[.]ipify[.]org. This is a simple public IP address web API used by the malware to gather the external IP address of the newly infected victim device. The malware likely uses this as an anti-virtualized environment check, as the malware will not reach out to its C2 infrastructure if it doesn’t get a successful response to this API call.

For further persistence, each sample of Hancitor contains three C2 URLs. These URLs are generated by the malware when it’s running, before attempting to reach out to them. The malware uses these multiple C2 servers as a fallback in case one is taken down or otherwise becomes unresponsive. The malware will attempt to cycle through these servers until it gets a legitimate response back.

Command and Control Check-in

After a successful DNS query to one of its C2 servers, the malware will send back a POST Request (as seen below) to identify a newly infected victim:

Figure 4: POST Request to Hancitor C2

Hancitor operates multiple ‘Build IDs’ that vary per sample, which are used to identify the specific build and campaign of the malware. Upon successful infection, the POST Request back will include the following information:

Once this request is received, the malware will attempt to reach out to another malicious URL containing the payload of the latest Hancitor campaign.

Command & Control Response

If a C2 server is up, it will respond with 200 OK, indicating that the response has succeeded. A single encoded string is returned with this response, as seen below:

Figure 5: Encoded response back from the C2

This string is Base64 encoded. However, it also has four extra bytes at its beginning, which is likely included to try to thwart both human and automated analysis. These bytes can be discarded and sliced from the Base64 encoded string.

Hancitor traditionally also uses an “Exclusive Or” (XOR) cipher in its payload from the C2 server, which uses the HEX key 0x7A. This can be manually decoded to reveal the true output of the response back from the server:

Figure 6: Decoding C2 payload

Once decoded, we can see that the response back includes another malicious URL that references a Windows executable to download. Hancitor will generate a GET Request to this URL to download this file onto the victim’s machine.

Hancitor Commands

As well as the download link to the additional malware, Hancitor can also receive important information about what it is downloading and how to start it as a new process on the victim’s device.

This can be observed within the decoded payload sent back by the C2; in this instance, it appears as the “b:” before the URL. Over the years, these commands have developed and changed, with Hancitor relying on five core commands:

Figure 7: Executable (MZ) payload downloaded from malicious URL

During recent analyses, this downloaded file was confirmed to be a known sample from the malware family Ficker. This has been observed as a consistent part of Hancitor latest’s malware campaigns, after Hancitor successfully reaches out to its C2 infrastructure. In early 2021, the malware of choice was Cuba ransomware, which is a C++ based malware targeting Windows systems in both North and South America, as well as in Europe.

Hancitor will download this additional malicious component and inject it into a new instance of the legitimate Windows service host process SvcHost.exe, where the threat (most recently Ficker) will carry out its own malicious activities.

Ficker Information Stealer

Ficker will next create mutexes on the victim’s device, then it will again use the web API, api[.]ipify, before establishing its own C2 server connection.

Ficker is a Rust-based* information stealer that focuses on the following functionality:

• Saving browser credentials (both Chromium and Mozilla-based)
• Stealing cryptocurrency wallet information
• Saving screenshots
• Grabbing file information
• Gathering system information

*Find out more about the malicious use of Rust and other exotic programming languages in our new white paper, Old Dogs, New Tricks: Attackers Adopt Exotic Programming Languages.

Examples of the above-mentioned functionality can be seen in the image below:

Figure 8: Example of decoded FickerStealer traffic – system information

After communication by Ficker, Hancitor reaches out to its C2 infrastructure again. In our analysis, it got a response of “{n:}” as seen below, which indicates it was not giving any download commands. No further actions were taken at that time.

Figure 9: Hancitor receiving a {n:} command

Cobalt Strike

Once Hancitor has established C2 traffic, it will often retrieve follow-up checks from its C2 servers. It will choose from one of its five core commands.

After initially dropping Ficker, Hancitor can also drop Cobalt Strike stagers to further compromise a victim’s machine by dropping yet more malware. While this tool was initially developed by legitimate network penetration testers, Cobalt Strike has grown incredibly popular among malware operators due to its robust capabilities.

YARA Rule

The following YARA rule was authored by the BlackBerry Research & Intelligence Team to catch the threat described in this document:

Indicators of Compromise (IoCs)

At BlackBerry, we take a prevention-first and AI-driven approach to cybersecurity. Putting prevention first neutralizes malware before the exploitation stage of the kill-chain.

By stopping malware at this stage, BlackBerry® solutions help organizations increase their resilience. It also helps reduce infrastructure complexity and streamline security management to ensure business, people, and endpoints are secure.

BlackBerry Assistance

If you’re battling Hancitor malware or a similar threat, you’ve come to the right place, regardless of your existing BlackBerry relationship.

The BlackBerry Incident Response team is made up of world-class consultants dedicated to handling response and containment services for a wide range of incidents, including ransomware and Advanced Persistent Threat (APT) cases.

We have a global consulting team standing by to assist you providing around-the-clock support, where required, as well as local assistance. Please contact us here: https://www.blackberry.com/us/en/forms/cylance/handraiser/emergency-incident-response-containment.