The Drovorub-kernel module is being loaded into memory using unique string signatures, indicating potential persistence and privilege escalation capabilities. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate advanced persistent threat activity before it leads to data exfiltration or system compromise.
YARA Rule
rule APT_APT28_drovorub_kernel_module_unique_strings {
meta:
description = "Rule detects the Drovorub-kernel module based on unique strings"
author = "NSA / FBI"
reference = "https://www.nsa.gov/news-features/press-room/Article/2311407/nsa-and-fbi-expose-russian-previously-undisclosed-malware-drovorub-in-cybersecu/"
date = "2020-08-13"
score = 75
strings:
$s_01 = "/proc" wide ascii
$s_02 = "/proc/net/packet" wide ascii
$s_03 = "/proc/net/raw" wide ascii
$s_04 = "/proc/net/tcp" wide ascii
$s_05 = "/proc/net/tcp6" wide ascii
$s_06 = "/proc/net/udp" wide ascii
$s_07 = "/proc/net/udp6" wide ascii
$s_08 = "cs02" wide ascii
$s_09 = "do_fork" wide ascii
$s_10 = "es01" wide ascii
$s_11 = "g001" wide ascii
$s_12 = "g002" wide ascii
$s_13 = "i001" wide ascii
$s_14 = "i002" wide ascii
$s_15 = "i003" wide ascii
$s_16 = "i004" wide ascii
$s_17 = "module" wide ascii
$s_18 = "sc!^2a" wide ascii
$s_19 = "sysfs" wide ascii
$s_20 = "tr01" wide ascii
$s_21 = "tr02" wide ascii
$s_22 = "tr03" wide ascii
$s_23 = "tr04" wide ascii
$s_24 = "tr05" wide ascii
$s_25 = "tr06" wide ascii
$s_26 = "tr07" wide ascii
$s_27 = "tr08" wide ascii
$s_28 = "tr09" wide ascii
condition:
all of them
}
This YARA rule can be deployed in the following contexts:
This rule contains 28 string patterns in its detection logic.
Scenario: A system administrator is manually compiling or installing a kernel module for a legitimate security tool (e.g., SELinux, AppArmor, or a custom kernel patch).
Filter/Exclusion: Check for the presence of known security tool binaries or directories (e.g., /usr/sbin/sestatus, /etc/apparmor/, or /usr/src/linux-headers-*) in the process command line or parent process chain.
Scenario: A scheduled job runs a script that temporarily loads a kernel module for network interface configuration (e.g., ip or ethtool utilities used in automation scripts).
Filter/Exclusion: Exclude processes with command lines containing ip, ethtool, or nmcli, or filter by user (e.g., root or network service account) and check for known network management tools.
Scenario: A developer is testing a custom kernel module in a development environment (e.g., using insmod or modprobe to load a module for debugging or testing).
Filter/Exclusion: Exclude processes with command lines containing insmod, modprobe, or make and check for presence of a development environment directory (e.g., /home/dev/kernel-testing/).
Scenario: A system update or patching process (e.g., using yum, apt, or dnf) temporarily loads a kernel module as part of the update process.
Filter/Exclusion: Exclude processes with command lines containing yum, apt, dnf, or update-manager, and check for presence of package manager directories (e.g., /var/cache/apt/, /var/log/yum/).
Scenario: A legitimate enterprise application (e.g., a virtualization platform like KVM or a container runtime like Docker) requires loading a kernel module for hardware acceleration.
**