T1547.006 Kernel Modules and Extensions in MITRE ATT&CK Explained

Summary

The article explains how attackers abuse Linux loadable kernel modules and macOS kernel extensions to obtain persistence and elevate privileges. It focuses on MITRE ATT&CK technique T1547.006 and references examples such as the Snapekit rootkit. A key advantage of this method is the ability to inject malicious code directly into the kernel without requiring a reboot. The technique is especially dangerous because kernel-level threats are highly stealthy and difficult to detect.

Investigation

The report reviews a scenario in which an attacker with root privileges compiles a malicious LKM, stores it in the /lib/modules/ directory, and leverages it for persistence, using Snapekit as a representative example. It also describes how malicious macOS kexts can be created, compiled with xcodebuild, and loaded via kextload. The analysis notes that adversaries may disguise activity by spoofing process names such as kworker.

Mitigation

Defenders should enforce Secure Boot and module-signing policies, monitor kernel module loading events, and tightly restrict privileged access to module directories. Regular integrity checks of kernel modules and audits of /lib/modules/ can help surface unauthorized additions. On macOS, keeping System Integrity Protection enabled and requiring signed kexts lowers the risk. Detection rules based on known malicious module hashes can also improve defense.

Response

When an unexpected kernel module load is detected, isolate the host, unload the suspicious module, and collect memory and disk artifacts for forensic analysis. Investigators should then look for persistence methods and signs of lateral movement. Apply security patches, strengthen least-privilege controls, and continue monitoring for follow-on activity. Any newly discovered indicators should be added to detection signatures.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.

• Attack Narrative & Commands:
  The attacker, already operating as root, creates a malicious LKM source file, compiles it with gcc while explicitly including kernel headers (the string “kernel header” appears in the command line), and finally loads the module with insmod. The presence of root privileges, the use of /usr/bin/gcc, and the kernel‑header inclusion satisfy the intended detection conditions (if they were correctly mapped to Linux audit fields).

  1. Create malicious source (evil.c) that prints a message when loaded.
  2. Compile with kernel headers: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – note the -I .../include path contains the phrase “kernel header” when expressed verbosely in the command line.
  3. Load the module: insmod evil.ko.
  4. Validate kernel execution (e.g., check dmesg for the printed message).

• Regression Test Script:
  The script below automates the entire malicious compile‑and‑load sequence. It must be run as root and assumes kernel headers are installed.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Preparation ----------
  WORKDIR="/tmp/malicious_lkm"
  SRC="${WORKDIR}/evil.c"
  OBJ="${WORKDIR}/evil.ko"
  KERNEL_HEADERS="/lib/modules/$(uname -r)/build/include"
  
  rm -rf "${WORKDIR}"
  mkdir -p "${WORKDIR}"
  
  # ---------- Malicious LKM source ----------
  cat <<'EOF' > "${SRC}"
  #include <linux/module.h>
  #include <linux/kernel.h>
  MODULE_LICENSE("GPL");
  static int __init evil_init(void) {
      printk(KERN_INFO "Evil LKM loaded!\n");
      return 0;
  }
  static void __exit evil_exit(void) {
      printk(KERN_INFO "Evil LKM unloaded!\n");
  }
  module_init(evil_init);
  module_exit(evil_exit);
  EOF
  
  # ---------- Compilation (contains "kernel header" in command line) ----------
  echo "[*] Compiling malicious LKM..."
  gcc -Wall -c "${SRC}" -I "${KERNEL_HEADERS}" -o "${WORKDIR}/evil.o" 
      -DDEBUG -D'KERNEL_HEADER_PATH="${KERNEL_HEADERS}"' 
      -Wl,--build-id=none -nostdinc -nostdlib -fno-pic -fno-pie 
      -static -o "${OBJ}"
  echo "[+] Compilation finished."
  
  # ---------- Load the module ----------
  echo "[*] Loading the malicious LKM..."
  insmod "${OBJ}"
  echo "[+] Module loaded. Verify with dmesg | tail."
  
  # ---------- Keep the module loaded for observation ----------
  sleep 30
  
  # ---------- Cleanup ----------
  echo "[*] Unloading the malicious LKM..."
  rmmod evil || true
  rm -rf "${WORKDIR}"
  echo "[+] Cleanup complete."

• Cleanup Commands:
  If you prefer manual cleanup, run the following after verification:

  # Remove the module (if still loaded)
  sudo rmmod evil || true
  
  # Delete the working directory
  sudo rm -rf /tmp/malicious_lkm