T1547.006 Modules du Noyau et Extensions dans MITRE ATT&CK Expliqué

Résumé

L’article explique comment les attaquants exploitent les modules de noyau chargeables Linux et les extensions de noyau macOS pour obtenir la persistance et élever les privilèges. Il se concentre sur la technique T1547.006 du MITRE ATT&CK et fait référence à des exemples tels que le rootkit Snapekit. Un avantage clé de cette méthode est la capacité d’injecter directement du code malveillant dans le noyau sans nécessiter de redémarrage. La technique est particulièrement dangereuse car les menaces au niveau du noyau sont très furtives et difficiles à détecter.

Enquête

Le rapport examine un scénario dans lequel un attaquant avec des privilèges root compile un LKM malveillant, le stocke dans le répertoire /lib/modules/ , et l’utilise pour la persistance, en utilisant Snapekit comme exemple représentatif. Il décrit également comment des kexts macOS malveillants peuvent être créés, compilés avec xcodebuild, et chargés via kextload. L’analyse note que les adversaires peuvent déguiser leur activité en usurpant des noms de processus tels que kworker.

Atténuation

Les défenseurs devraient appliquer des politiques de démarrage sécurisé et de signature des modules, surveiller les événements de chargement des modules du noyau et restreindre strictement l’accès privilégié aux répertoires de modules. Des vérifications régulières de l’intégrité des modules du noyau et des audits de /lib/modules/ peuvent aider à découvrir des ajouts non autorisés. Sur macOS, garder la Protection de l’intégrité du système activée et exiger des kexts signés réduit le risque. Les règles de détection basées sur des hachages de modules malveillants connus peuvent également améliorer la défense.

Réponse

Lorsqu’un chargement inattendu de module de noyau est détecté, isolez l’hôte, déchargez le module suspect et collectez des artefacts de mémoire et de disque pour une analyse judiciaire. Les enquêteurs doivent ensuite rechercher des méthodes de persistance et des signes de mouvement latéral. Appliquez des correctifs de sécurité, renforcez les contrôles de privilèges minimaux et continuez à surveiller toute activité ultérieure. Tout nouvel indicateur découvert devrait être ajouté aux signatures de détection.

Exécution de la Simulation

Condition préalable : Le contrôle de pré-vol Telemetry & Baseline doit avoir réussi.

Rationale : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection.

• Narratif et Commandes d’Attaque :
  L’attaquant, déjà opérant en tant que root, crée un fichier source LKM malveillant, le compile avec gcc tout en incluant explicitement les en-têtes du noyau (la chaîne “kernel header” apparaît dans la ligne de commande), et charge finalement le module avec insmod. La présence de root privilèges, l’utilisation de /usr/bin/gcc, et l’inclusion des en-têtes de noyau satisfont les conditions de détection prévues (s’ils ont été correctement mappés aux champs d’audit Linux).

  1. Créer une source malveillante (evil.c) qui imprime un message lors du chargement.
  2. Compiler avec les en-têtes de noyau : gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – notez que le -I .../include le chemin contient la phrase “kernel header” lorsqu’il est exprimé de manière détaillée dans la ligne de commande.
  3. Charger le module : insmod evil.ko.
  4. Valider l’exécution du noyau (par exemple, vérifier dmesg pour le message imprimé).

• Script de Test de Régression :
  Le script ci-dessous automatise toute la séquence de compilation et de chargement malveillante. Il doit être exécuté en tant que root et suppose que les en-têtes du noyau sont installés.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Préparation ----------
  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}"
  
  # ---------- Source LKM malveillant ----------
  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 (contient "kernel header" dans la ligne de commande) ----------
  echo "[*] Compilation du LKM malveillant..."
  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 terminée."
  
  # ---------- Charger le module ----------
  echo "[*] Chargement du LKM malveillant..."
  insmod "${OBJ}"
  echo "[+] Module chargé. Vérifiez avec dmesg | tail."
  
  # ---------- Garder le module chargé pour observation ----------
  sleep 30
  
  # ---------- Nettoyage ----------
  echo "[*] Déchargement du LKM malveillant..."
  rmmod evil || true
  rm -rf "${WORKDIR}"
  echo "[+] Nettoyage terminé."

• Commandes de Nettoyage :
  Si vous préférez un nettoyage manuel, exécutez ce qui suit après vérification :

  # Retirer le module (s'il est toujours chargé)
  sudo rmmod evil || true
  
  # Supprimer le répertoire de travail
  sudo rm -rf /tmp/malicious_lkm