Falling into the TRAP: How the Endgame Platform Stops BadRabbit

BadRabbit

BadRabbit is the latest auto-propagating ransomware making the rounds and disrupting organizations.  We previously went deep into the technical details.  This post will describe our testing of BadRabbit in the presence of our endpoint protection platform.  I didn’t want to rush to join the pack for self-congratulations along the lines of, “Look, Vendor X would have protected you!” posts and emails which make bold, sparse, and often difficult to verify claims.  To be sure, there should be a high level of skepticism and cognitive dissonance when wondering how all these vendors stop every attack, yet such attacks succeed with mass impact on a regular basis.  Even worse, the detection techniques often described in such posts (if one is described at all) may seem exceedingly false positive-prone when thinking about applying the method in a real-world network.

I don’t want to fall into this trap of self-agrandissement with little value added to the conversation. Instead, I will provide detail about how things work when BadRabbit is executed on an endpoint protected by Endgame. I will highlight the core techniques within BadRabbit, and how Endgame stops them, while also contributing to the technical conversation and overall understanding of the attack.  

 

Endgame’s Protection at Work

So would Endgame have stopped BadRabbit?  Yes.  Three of our signatureless, inline preventions come into play against this attack.  I’ll address each in detail.  These preventions described have not been altered after the release of BadRabbit.  They all existed in the form described below prior to the discovery of  BadRabbit.

 

Malware Prevention

The screenshot below is from a virtual machine where we ran BadRabbit with all our preventions turned on.  Endgame MalwareScoreTM prevents the BadRabbit payload DLL (infpub.dat, 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648) from being loaded and executed by rundll32.  Importantly, this was effective with no updates to our software such as signature or model updates.  If you have VirusTotal Intelligence, you can see that Endgame designated this file as malicious with high confidence the first time it was seen in the wild.

Screen Shot 2017-10-25 at 4.36.27 PM.png

Screenshot of Blocking DLL

 

What is Endgame MalwareScoreTM? MalwareScoreTM is our machine learning-powered malware classifier.  Based on gradient boosted decision trees, it blocks execution of malicious files and loads of malicious DLLs inline, on the endpoint, requiring only milliseconds to classify malware. This is done pre-execution so the malicious file(s) never have a chance to load and do damage.

Our researchers and data scientists work tirelessly everyday to continue to improve this capability.  To build a new candidate model, we train on tens of millions (and growing) of carefully chosen malicious and benign samples.  Building a good model is a significant process. The model currently in production took about 6,700 processor hours to build and is backed by years of iterative research and experimentation dedicated to finding the optimal model parameters. Before shipping a model, we conduct a variety of tests, from analysis of samples whose benign/malicious labels which change between models, to analysis of the model’s performance against previous misses, to comparative testing against new in-the-wild samples. This is an art as much as a science.  Model updates are applied when we determine we can impact either the efficacy of detection, lower false positive rates, or usually, both.  This generally happens at a minimum monthly, and updates are applied either automatically via the cloud or through a one line privileged user command from our platform for customers without cloud connectivity.  

That’s all to say that a lot goes into building a malware classifier which performs excellently against both well-known but, perhaps more importantly, against never-before-seen malware like BadRabbit.  As we saw with WannaCry and NotPetya, Endgame MalwareScoreTM is effective in stopping emergent and highly damaging ransomware and other forms of malware.  

Below is screenshot of how BadRabbit looks to a user of our management console when blocking BadRabbit with MalwareScoreTM.  There are no child processes or other activities to be seen.  The ransomware is stopped dead in its tracks.  

 

Screen Shot 2017-10-26 at 2.09.15 PM.png

Screenshot of the MalwareScoreTM Alert after Blocking DLL

 

Process Injection Prevention

Next, we tested what the BadRabbit would do against the rest of our protection platform.  We put MalwareScoreTM prevention into detection-only mode so we could analyze what the malware does next.  Interestingly, a process injection prevention took place.  The screenshot below demonstrates how it looks to the user of our console.

Screen Shot 2017-10-26 at 4.07.22 PM.png

Screenshot of Process Injection Prevention Alert

 

This attack timeline shows the child processes of rundll32.dll before the injection prevention as well as file writes and deletes caused by the process.  

There seems to be little to no discussion of BadRabbit’s in-memory defense evasion techniques. BadRabbit’s payload DLL (infpub.dat) remaps itself into a new (unbacked) memory region within its running rundll32 process. It does this by first allocating new memory with VirtualAlloc and copying the entire contents of the payload DLL’s address space to the new region. Next, it parses the relocation table and performs the required fixes for this new base address where the executable will live. After that, it updates the page protections for the new memory to match what is specified in the executable header (i.e. .text section is marked executable). Execution then jumps to this new memory region. Immediately after this jump, the original payload DLL file on disk is unloaded from rundll32's address space. Then, the original payload DLL file on disk is overwritten with null bytes and then deleted completely. The executable now attempts to run from this new unbacked memory region.  The Endgame injection prevention takes place at this step, identifying it as abnormal.

The BadRabbit authors perhaps used this behavior to hamper forensic analysis of infected machines through deletion of the payload on-disk. The technique used is more sophisticated than traditional batch scripts used for self-deletion.  It also underscores the importance of detection across the entire attack lifecycle, and not just tracking the initial malware components.

It should be noted that this particular prevention alone does not entirely stop the ill effects of the BadRabbit malware because of how it is written.  The main thread of execution creates the scheduled tasks for shutdown and for spawning the diskcryptor client malware on reboot before migrating to stealthier in-memory-only execution blocked by the process injection prevention. However, our user would have been alerted to an issue on this endpoint and a SOC team could begin an investigation.  Additionally, stopping this suspicious execution from unbacked memory blocks the credential dumping step described in the next section which would help control the malware’s spread.  

Overall, this is a good example of a single layer in our overall detection and protection system, even though in this case this layer doesn’t prevent the ultimate effect of file encryption on the targeted system due to the specific sequence of actions taken by the BadRabbit ransomware. Keep in mind, though, that with MalwareScoreTM on, it would never get this far.

 

Credential Dumping Prevention

Now let’s allow the malicious DLL payload and also allow the process injection to take place by putting those protections in detection-only mode.  In this case, if we run BadRabbit, a credential dumping prevention alert appears, as demonstrated in the screenshot below.

Screen Shot 2017-10-26 at 4.51.16 PM.png

Screenshot of Credential Dumping Alert

 

Endgame credential dumping prevention blocks the techniques used by BadRabbit when it attempts to dump credentials.  This hampers the ability of the malware to move laterally, containing its impact in most environments.

Finally, let’s turn off all Endgame prevention capabilities so we can see what the malware does from beginning to end. The screenshot and video below shows Endgame displaying everything BadRabbit does in an interactive attack timeline.  Clearly, we recommend turning on preventions so emergent malware like BadRabbit is stopped before causing damage. However, for this post, exploring BadRabbit without these preventions on provides additional insight for how users can understand attacks quickly and easily with Endgame.  

Screen Shot 2017-10-26 at 5.01.29 PM.png

Screenshot of Complete BadRabbit Execution

 

Video of Endgame Platform in Detection-Only Mode Against BadRabbit

 

Conclusion

The BadRabbit ransomware uses some interesting techniques as it executes, including the stealthy migration and execution techniques described above in the process injection prevention section.  Testing it in the presence of our platform showed that Endgame MalwareScoreTM was  effective on Day 0 in blocking the attack through prevention of malicious module loads. BadRabbit also tripped additional preventions if execution was allowed to continue.

BadRabbit is the third major international ransomware attack this year, and we are likely to see more of these kinds of attacks into 2018. It’s important both to understand the range of techniques employed, as adversaries increasingly benefit from a mix-and-match approach across a range of attack vectors, exploiting opportunities within singular layers of defense. BadRabbit demonstrates why a multi-layer approach to prevention and detection is so necessary. Each layer provides an additional trap, catching even the most evasive of attacks.