T1547.006 Kernelmodule und Erweiterungen in MITRE ATT&CK erklärt

Zusammenfassung

Der Artikel erklärt, wie Angreifer Linux-Ladbare-Kernel-Module und macOS-Kernel-Erweiterungen missbrauchen, um Persistenz zu erlangen und Privilegien zu erhöhen. Er konzentriert sich auf die MITRE ATT&CK-Technik T1547.006 und verweist auf Beispiele wie das Snapekit-Rootkit. Ein entscheidender Vorteil dieser Methode ist die Fähigkeit, bösartigen Code direkt in den Kernel einzufügen, ohne einen Neustart zu erfordern. Die Technik ist besonders gefährlich, da Bedrohungen auf Kernel-Ebene hochgradig unauffällig und schwer zu erkennen sind.

Untersuchung

Der Bericht untersucht ein Szenario, in dem ein Angreifer mit Root-Rechten ein bösartiges LKM kompiliert, es im /lib/modules/ Verzeichnis speichert und es zur Persistenz nutzt, wobei Snapekit als repräsentatives Beispiel dient. Es wird auch beschrieben, wie bösartige macOS-Kexts erstellt, mit xcodebuild, kompiliert und mit kextloadgeladen werden können. Die Analyse stellt fest, dass Gegner Aktivitäten verschleiern können, indem sie Prozessnamen wie kworker fälschen.

Abschwächung

Verteidiger sollten Secure Boot und Modul-Signierungsrichtlinien erzwingen, Kernel-Modul-Ladeereignisse überwachen und den privilegierten Zugriff auf Modulverzeichnisse streng einschränken. Regelmäßige Integritätsprüfungen von Kernel-Modulen und Audits von /lib/modules/ können unerlaubte Ergänzungen aufdecken. Auf macOS senkt das eingeschaltete Systemintegritäts-Schutzsystem und das Anfordern signierter Kexts das Risiko. Erkennungsregeln basierend auf bekannten bösartigen Modul-Hashes können ebenfalls die Verteidigung verbessern.

Antwort

Wenn ein unerwartetes Kernel-Modul-Laden entdeckt wird, sollte der Host isoliert, das verdächtige Modul entladen und Speicher- und Datenträgerartefakte für die forensische Analyse gesammelt werden. Ermittler sollten dann nach Persistenzmethoden und Anzeichen für seitliche Bewegung suchen. Sicherheits-Patches anwenden, Minimal-Rechte-Kontrollen stärken und die Überwachung auf nachfolgende Aktivitäten fortsetzen. Jegliche neu entdeckten Indikatoren sollten den Erkennungssignaturen hinzugefügt werden.

Simulation der Ausführung

Voraussetzung: Das Vorbereitungs- und Baseline-Preflight-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der Angreifertechnik (TTP), die darauf ausgelegt ist, die Erkennungsregel zu aktivieren. Die Befehle und Erzählungen MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffs-Erzählung & Befehle:
  Der Angreifer, bereits als rootoperierend, erstellt eine bösartige LKM-Quell-Datei, kompiliert sie mit gcc während er ausdrücklich Kernel-Header einschließt (der Ausdruck „Kernel-Header“ erscheint in der Befehlszeile), und lädt schließlich das Modul mit insmod. Die Anwesenheit von root Privilegien, die Nutzung von /usr/bin/gcc, und die Einbeziehung der Kernel-Header erfüllen die beabsichtigten Erkennungsbedingungen (wenn sie korrekt auf Linux-Audit-Felder abgebildet sind).

  1. Erstelle bösartige Quelle (evil.c) die beim Laden eine Nachricht druckt.
  2. Kompiliere mit Kernel-Headern: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – beachten Sie, dass der -I .../include Pfad enthält den Ausdruck „Kernel-Header“, wenn in der Befehlszeile ausführlich ausgedrückt.
  3. Laden das Modul: insmod evil.ko.
  4. Validiere Kernel-Ausführung (z.B. überprüfen dmesg auf die gedruckte Nachricht).

• Regressionstest-Skript:
  Das folgende Skript automatisiert die gesamte böswillige Kompilierungs- und Lade-Sequenz. Es muss als root ausgeführt werden und geht davon aus, dass Kernel-Header installiert sind.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Vorbereitung ----------
  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}"
  
  # ---------- Bösartige LKM-Quelle ----------
  cat < "${SRC}"
  #include 
  #include 
  MODULE_LICENSE("GPL");
  static int __init evil_init(void) {
      printk(KERN_INFO "Evil LKM geladen!n");
      return 0;
  }
  static void __exit evil_exit(void) {
      printk(KERN_INFO "Evil LKM entladen!n");
  }
  module_init(evil_init);
  module_exit(evil_exit);
  EOF
  
  # ---------- Kompilierung (enthält "Kernel-Header" in der Befehlszeile) ----------
  echo "[*] Bösartige LKM wird kompiliert..."
  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 "[+] Kompilierung abgeschlossen."
  
  # ---------- Modul laden ----------
  echo "[*] Lade die bösartige LKM..."
  insmod "${OBJ}"
  echo "[+] Modul geladen. Überprüfen Sie mit dmesg | tail."
  
  # ---------- Modul geladen halten um Beobachtungen zu machen ----------
  sleep 30
  
  # ---------- Aufräumen ----------
  echo "[*] Bösartige LKM wird entladen..."
  rmmod evil || true
  rm -rf "${WORKDIR}"
  echo "[+] Aufräumen abgeschlossen."

• Aufräum-Befehle:
  Wenn Sie eine manuelle Bereinigung bevorzugen, führen Sie nach der Überprüfung Folgendes aus:

  # Entfernen Sie das Modul (wenn noch geladen)
  sudo rmmod evil || true
  
  # Löschen Sie das Arbeitsverzeichnis
  sudo rm -rf /tmp/malicious_lkm