A Little Splunk MedicinalRub for Your Drovorub Rootkit Questions

On August 13th, 2020, the FBI and NSA jointly released a cybersecurity advisory that disclosed details of a new Linux rootkit named Drovorub. They attributed it to the Russian General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165. Or as we in the private sector like to call them: Fancy Bear, Strontium, APT 28, or Sofacy. My colleague Mick Baccio will explain the reasons behind the disclosure below. Still, anytime the US government is this public about a nation-state adversary’s tooling, it's a good idea to listen and take note.

At a high level, this malware or "rootkit" appears to have been custom developed by the GTsSS. It allows for an adversary to have persistent command and control, file download/upload, port forwarding, and command execution on the host WHILE using advanced methods to hide and evade detection by traditional means. AKA a rootkit. While there are no publicly available samples of this malware yet, we will explain some high-level detection techniques (with a Splunk twist) based off of the advisory, provide a method of detection by our fearless endpoint-splunking savant James Brodsky, and discuss our continuing efforts of detection of this threat (and threats like them) for the long term.

Why?

Few threat actors possess the technical capabilities and history of success that Russia’s GRU has demonstrated over the past five years. If we time-machine back to compromises at DCCC, the DNC, 2018 midterms, even French President Macron's campaign, all activity has been attributed to GRU technical operations. National Counterintelligence and Security Center (NCSC) Director Evanina has stated 2020 election security remains a priority in the Intelligence Community, and continues to direct the IC’s efforts to bolster election security leading into November and beyond. 

The level of detail reported by the NSA and FBI (and the private sector elements that contributed) point to an in-depth knowledge of GRU operational infrastructure. A previously undetected and unknown GRU technical capability has been publicly exposed. The disclosure of Drovorub is a damaging setback because retooling is neither swift nor easy—even for a well-funded intelligence organization like the GRU. 

This advisory is a digital equivalent of a shot across the bow – “we can see you, and we are watching.”

– Mick Baccio

Detection Techniques

I could do a long writeup on the “how” of the Drovorub malware based on the NSA advisory, but instead of reading my notes… just read the advisory. :-) The short story is that the rootkit comprising of the "Drovorub-client" (the actual trojany bit) that is installed on a victim's host and that "client" contains the "Drovorub-kernel" package which is the rootkit that allows Drovorub to hide. The client then communicates to a server/agent backend on the internet that enables the adversary to do his evil work.

^{_{https://media.defense.gov/2020/Aug/13/2002476465/-1/-1/0/CSA_DROVORUB_RUSSIAN_GRU_MALWARE_AUG_2020.PDF page 1}}

So how can you detect Drovorub? It's a good question. Unfortunately, there are no publicly available samples of the rootkit, so the only thing we have to work off at this time is the cybersecurity advisory. Thankfully they give us multiple places to start looking:

Networking

Like all malware that is controlled remotely, there is network traffic that can be analyzed.  Suppose you happen to have Snort deployed on your network. In that case, on page 35, the NSA provides two signatures that will detect client-server communications as long as that traffic is unencrypted. Although the traffic and PCAPS in the advisory are shown as unencrypted, it is possible to bundle TLS with WebSockets for Drovorub to communicate whilst encrypted. So unless you have something breaking encrypted traffic in your network, this may not be the silver bullet we were hoping for. Finally, although the NSA declined to provide direct IOCs in the document, eagle-eyed readers would notice that they cited a blog post by Microsoft Security Response Center. No promises, but I would start pivoting off the IP addresses listed in that document and minimally add them to your Enterprise Security Threat Intelligence Framework.

Host-based

When I describe the difference between rootkits and "malware," I usually explain that rootkits are harder to detect… and Drovorub is no different. According to the NSA, Drovorub intentionally hides many of its artifacts and modifications from an operating system view. Yara signatures may be sufficient to scan and detect the rootkit on a host (and the NSA provides some on page 36/37), but without a Drovorub sample to test on, this author admits a bit of concern of accuracy of detection. Furthermore, the team at Fort Meade provides some great information on how to detect Drovorub using forensic memory analysis. That is a little out of the scope of most Splunk deployments, but if you are interested and/or can do so, you should read up on it!

Finally, there are two glimmers of hope for detection AND prevention. Firstly, the NSA provides a script that can “tickle” (my wording not theirs) the Drovorub client. If the script responds successfully, you have a very long day of work ahead. Secondly, they point out that all of this headache could be avoided by running a Linux kernel of at least 3.7 and activating UEFI Secure Boot on your Linux host. This will allow administrators to load only kernel modules with valid signatures. If this seems overwhelming… don’t worry! Endpoint Savant James Brodsky is to the rescue below, with a fresh-off-the-presses keyboard Splunk TA to help you out with both of these glimmering pieces of hope.

The TA

Let’s pretend like it’s 2014 again. We shall return to the old trick of using the Splunk Universal Forwarder to run scripted inputs to detect potential evil. In this case, we'll leverage one of the simple detection methods described in the NSA/FBI advisory. We created a Splunk Technical Add-On (TA) that probes any Linux system running a Splunk Universal Forwarder for the possible presence of the rootkit. This TA is available on my GitHub, here. 

Deploy this TA, on a linux host, like you would any Splunk TA, (either manually into /etc/apps, via deployment server, via carrier pigeon or another distribution method of your choice). By default, it will execute a scripted input every hour, and run the shell-script based detection from page 35 of the advisory. It will report key-value pairs into Splunk, detailing the outcome of the probe. It will also tell you whether or not the system may have UEFI Secure Boot enabled (an effective mitigation for this rootkit).

The TA's output will appear in your Splunk instance similar to the below (one run showing the system without rootkit, and another run showing potential rootkit infection):

– James Brodsky

Conclusion

Hopefully, this post has provided some context, clarity, and solutions for Splunk customers around the world. To be clear, at this time, this rootkit is not "out in the wild" and appears to be strictly used by an APT group that has specific targets. The majority of organizations around the world will not be affected (at least right now). With that said, we are always working to improve our detections and analytics. Our Splunk Threat Research team will be working on creating new detections that specifically address Linux rootkits and releasing them ASAP over the next week on Splunk’s Security Content Github. When we have more concrete and specific detections for Drovorub, expect a new blog post.

As always, Happy Hunting! :-)