Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Threat Advisory: Hancitor and Process Hollowing

Threat Advisory: Hancitor and Process Hollowing

*Due to the nature of this class of attack, it is highly recommended that you read this entire advisory.  Process Hollowing is a technique purposely designed to evade whitelisting.*

The Hancitor malware family has produced several variants over the past several months. The variations have been similar, but changed enough to bypass protections that are signature-based.

Hancitor malware has been witnessed to leverage Process Hollowing, a technique explicitly designed to evade whitelisting.  To give you context, the latest payloads appear to be causing Microsoft Word to spawn legitimate Microsoft processes, svchost.exe and explorer.exe, and then using those to host the malicious code.  Below are actions we believe you should take to either prevent, or, at minimum, detect when this is occurring.  The actions are easy and should be quick to implement, but you’ll want to be careful in making sure that you do not prevent legitimate uses of these core Windows binaries.

Hancitor Malware Summary

Hancitor is a family of malicious documents that uses Visual Basic for Applications (VBA) macros to perform various activities centered around downloading additional payloads.  The VBA macros contain a large amount of obfuscation and rely on the user to have macros enabled.  The Hancitor family has been seen downloading and executing remote payloads using PowerShell, process hollowing into svchost.exe and explorer.exe, and dropping embedded executables. 

The payload involves both known trojans and custom code used to download and execute arbitrary payloads.  The family is well written and fault-tolerant with custom protocols and verification for communication on both client and server side to ensure that the malware runs successfully.  Below are details from the Hancitor sample with the following hash:

2A6ED4487DF71F0ADFFEBEB42C6DD183A422FBF948DBF77E7F1631DCDEAAE524

Learn more on the Hancitor malware family on the Carbon Black blog: Read More

Preventing the attack with Cb Protection

You can use custom rules in Cb Protection (formerly Bit9) to prevent this attack (and many other similar attacks), by controlling word, and optionally, other office applications. The simplest case would be to create a rule that blocks svchost.exe or explorer.exe from being launched by winword.exe. This is trivial to do using a custom software rule. In most environments, this should be safe to do, however, it is always recommended to create the rule first as a report rule and monitor. This way, you will have visibility into whether or not this occurs legitimately in your environment before switching to a block action.

Of course, applications other than svchost.exe or explorer.exe could be targeted. In this case, you could first monitor your environment to see what if anything winword typically spawns, then write the rule to only allow that behavior. While this is not trivial to accomplish, it will prevent word from spawning other applications that could be abused in this manner. Using rules to control word and other office applications can go a long way towards preventing them being leveraged in attacks such as these.

Step 1 – Activate hidden rule fields

  • Navigate to <CarbonBlackProtectionServer>\Shepherd_config.php
  • And as seen below, change the field “ShowHiddenCustomRules” from false to true.

BLOG PHOTO 1.png

Step 2 – Create the “Action” rule first.

Internal rules are ranked in reverse order when entered, so the action rule needs to be entered first, and the classification rule needs to be entered second.

Set the rule type to Internal with Execute and Block.

Enter the MS Office Processes in the Process fields.

Enter the target launched processes in the Path Or File field.

Save the rule.

BlOG PHOTO 2.jpg

Step 3 – Edit the “Action” rule.

If you filter the view by one of the processes, you’ll see a screen something like the one below.

Ignore the rules ending in (hidden).  Edit the one that does not say (hidden) at the end.

Blog photo 3.jpg

You will see new Advanced Property fields.  The one you want is “Process Classificaton”.

Enter msmalspawn (or whatever you want, but it needs to be consistent).

blog photo 4 .jpg

Step 4 – Creation the “Classification” rule

Follow the same steps as the action rule, except the action is “Classify Process (Hidden)”

blog photo 5.jpg

Step 5 – Edit the “Classification” rule.

This is exactly the same as step 3, and the classification must match.

blog photo 6.jpg

Step 6 – Turn off “ShowHiddenCustomRules”

Navigate back to <servername>\shepherd_config.php and change the value under ShowHiddenCustomRules to false.

blog photo 7.png

Alternative Actions

You can also choose “Report” under the action field to get an event saying that this condition has been met, allowing you to respond to it versus automating it.  This is often how many companies will start and then move it to Block once they are comfortable with it.

Detecting the Attack with Cb Response

For those using Cb Response, a watchlist looking for child processes of winword.exe would be a good way to detect this. You could specifically look for child processes explorer.exe or svchost.exe to identify this particular activity. You can use:

  • process_name:winword.exe AND
  • (childproc_name:svchost.exe) OR (childproc_name:explorer.exe)

You can modify this to expand your scope and fit your environment.

By understanding the underlying mechanisms of the Hancitor family, you can properly protect against the threat with Carbon Black. Despite the signature changes over the variants, the general behavior has continued along a similar path. As a result, by defending with both signatures and behavioral protections, your enterprise will be much safer.

Labels (2)
Comments

Found this to be very helpful.  Thank you!  Just a note...based on a validation test we performed, we did find sample malware try to use svchost.exe from the syswow64 directory.  Added appropriate paths to the "Path or File" field and following test of sample was blocked successfully.

I'm a little confused by the instructions.  The first screenshot shows the creation of a rule called "Act on msmalspawn...", but the next one where we are supposed to modify it (step 3), is named differently (it's the classify rule that we've not created yet).  Were the screenshots done out of order/incorrectly, or am I just reading this thing wrong?  It looks like it doesn't matter, as the change I'm making is the same for both rules, but I just want to be sure.

In addition, if we want to start it in report only, do we do that to the main rule once the hidden configs are disabled?  And do we set both rules, classify and act, as report, or just enable the classify rule and set the act to report before enabling?

Article Information
Author:
Creation Date:
‎11-23-2016
Views:
4183
Contributors