Dealing with Drovorub

Inside the frightening malware for Linux newly discovered by the NSA.

For my first post here on Substack, I decided to write a summary of the advisory released by the NSA this August on the new malware toolset targeting Linux operating systems, Drovorub.

Drovorub, meaning “woodcutter” in Russian, is a complex set of malicious software the NSA has attributed to Unit 26165 of the Russian General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS). The group is associated with APT28—also known as Fancy Bear—thought to have been involved (with its other Russia-linked counterpart, APT29 or “Cozy Bear”) in the Russian interference in the 2016 election. Bleeping Computer reports that one reason for this attribution is an IP address for Strontium (Microsoft’s codename for APT28) that had accessed Drovorub simultaneously.

Overview

Drovorub consists of four central components: a Command and Control (C2) server (Drovorub-server), an implant (Drorub-client), a kernel rootkit (Drovorub-kernel), and a file transfer tool (Drovorub-agent). The graphic from the report displaying these seperate parts is provided below:

The server allows for control of the client and agent and manages the connections via a MySQL database. The client is able to hide itself using the kernel module rootkit and is controlled by the attacker via the server. The agent may or may not be installed on the actor’s own infrastructure. It forwards network traffic and transfers files to and from the client with the server acting as an intermediary.

Technical details

The server config file is given in JSON and provided below in example format:

We can see that it includes various database and networking information as well as the path to the private RSA key. The NSA has said the purpose of the “phrase” field is unknown.

The client’s configuration file includes boolean variables used to tell whether or not it is successfully being hidden by the rootkit as shown below. The methods used by the rootkit to achieve persistence are advanced but all publicly known.

For network communications, JSON messages are sent to and from the server and client via WebSockets. Once the deployed client opens a WebSocket connection to the server, it begins the series of steps in the authentication process shown below.

Evation techniques used by the kernel module rootkit include “process hiding, file hiding, socket hiding, netfilter hiding, and hiding from raw socket receives.”

Detection and mitigation

The biggest challenge in detecting Drovorub unsurprisingly comes from the persistence measures by the kernel module rootkit, thus rendering live response techniques largely ineffective. However, NIDS such as Suricata and Zeek that have the capacity to dynamically de-obfuscate WebSocket masking may be able to detect the C2 messages. The advisory specifies memory analysis as being the most effective tool in detecting the kernel module rootkit and contains an entire section on using Volatility for analysis. Being quite familiar with Volatility, I’d like to go over it in detail. It should be noted that all of the figures in the advisory use Volatility version 2—version 2.6 specifically—not the newer Volatility 3. Obviously, memory acquisition through tools like LiME must be used initially for memory acquisition. The Volatility plugin linux_hidden_modules has been shown to locate the kernel module successfully under the name dr_mod.

The module can then be dumped from memory using the plugin linux_moddump for use in analysis. The client itself may be found using linux_psxview, commonly used to detect hidden processes, where it will be listed under the name dr_client.

linux_psaux can also be used for the same result where linux_procdump can be utilized to dump the client’s process.

linux_lsof can detect the open network socket used for receiving C2 messages.

To find details on this socket, you can run linux_netstat. The result will provide the IP addresses and port numbers the socket is using in addition to its PID.

Lastly, the advisory provides details on using the strings.exe utility and grep for string analysis of Drovorub as well as Snort and YARA rules for detecting its components—two of the YARA rules serving to be run against the dumped kernel module and client respectively.

For mitigation, the advisory recommends upgrading to Linux kernel version 3.7 or later for kernel signing enforcement and to load only modules with valid digital signatures which can be done by activating UEFI Secure Boot. These measures are only a means of preventing persistance of the kernel module and are not protection against the initial vector.