T1547.006 Moduli e Estensioni del Kernel in MITRE ATT&CK Spiegato

Riepilogo

L’articolo spiega come gli aggressori abusino dei moduli kernel caricabili di Linux e delle estensioni kernel di macOS per ottenere persistenza ed elevare i privilegi. Si concentra sulla tecnica MITRE ATT&CK T1547.006 e fa riferimento ad esempi come il rootkit Snapekit. Un vantaggio chiave di questo metodo è la capacità di iniettare codice dannoso direttamente nel kernel senza richiedere un riavvio. La tecnica è particolarmente pericolosa perché le minacce a livello di kernel sono altamente furtive e difficili da rilevare.

Indagine

Il report esamina uno scenario in cui un aggressore con privilegi di root compila un LKM dannoso, lo memorizza nella directory /lib/modules/ e lo utilizza per la persistenza, usando Snapekit come esempio rappresentativo. Descrive anche come possano essere creati, compilati con xcodebuild, e caricati via kextload. L’analisi osserva che gli avversari possono mascherare l’attività falsificando nomi di processi come kworker.

Mitigazione

I difensori dovrebbero far rispettare politiche di Secure Boot e di firma dei moduli, monitorare gli eventi di caricamento dei moduli kernel e limitare strettamente l’accesso privilegiato alle directory dei moduli. Controlli regolari di integrità dei moduli kernel e audit di /lib/modules/ possono aiutare a far emergere aggiunte non autorizzate. Su macOS, mantenere abilitata la System Integrity Protection e richiedere kext firmati riduce il rischio. Regole di rilevamento basate su hash noti di moduli dannosi possono anche migliorare la difesa.

Risposta

Quando viene rilevato un modulo kernel inaspettato, isolare l’host, scaricare il modulo sospetto e raccogliere artefatti di memoria e disco per un’analisi forense. Gli investigatori dovrebbero quindi cercare metodi di persistenza e segni di movimento laterale. Applicare patch di sicurezza, rafforzare i controlli del minimo privilegio e continuare a monitorare l’attività successiva. Qualsiasi nuovo indicatore scoperto dovrebbe essere aggiunto alle firme di rilevamento.

Esecuzione di Simulazione

Prerequisito: Il controllo Telemetria e Baseline Pre‑flight deve essere passato.

Motivazione: Questa sezione dettaglia l’esecuzione precisa della tecnica avversaria (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente i TTP identificati e mirano a generare la telemetria esatta prevista dalla logica di rilevamento.

• Narrazione e Comandi di Attacco:
  L’aggressore, già operante come root, crea un file sorgente LKM dannoso, lo compila con gcc includendo esplicitamente gli header del kernel (la stringa “header del kernel” appare nella linea di comando), e infine carica il modulo con insmod. La presenza di root privilegi, l’uso di /usr/bin/gcc, e l’inclusione degli header del kernel soddisfano le condizioni di rilevamento intese (se correttamente mappate ai campi di audit Linux).

  1. Crea sorgente dannoso (evil.c) che stampa un messaggio quando caricato.
  2. Compila con header del kernel: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – nota che il -I .../include path contiene la frase “header del kernel” quando espresso verbalmente nella linea di comando.
  3. Carica il modulo: insmod evil.ko.
  4. Valida l’esecuzione del kernel (ad es., controlla dmesg per il messaggio stampato).

• Script di Test di Regressione:
  Lo script seguente automatizza l’intera sequenza di compilazione e caricamento dannosa. Deve essere eseguito come root e assume che gli header del kernel siano installati.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Prep ione ----------
  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}"
  
  # ---------- Sorgente LKM dannoso ----------
  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
  
  # ---------- Compilazione (contiene "header del kernel" nella linea di comando) ----------
  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."

• Comandi di Cleaning:
  Se preferisci la pulizia manuale, esegui i seguenti comandi dopo la verifica:

  # Rimuovi il modulo (se ancora caricato)
  sudo rmmod evil || true
  
  # Cancella la directory di lavoro
  sudo rm -rf /tmp/malicious_lkm