Browse your product documentation including release notes and installers
*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 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:
Learn more on the Hancitor malware family on the Carbon Black blog: Read More
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.
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.
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.
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).
Follow the same steps as the action rule, except the action is “Classify Process (Hidden)”
This is exactly the same as step 3, and the classification must match.
Navigate back to <servername>\shepherd_config.php and change the value under ShowHiddenCustomRules to false.
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.
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:
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.
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?