T1547.006 Модулі ядра та розширення у MITRE ATT&CK – Пояснення

Резюме

Стаття пояснює, як зловмисники використовують завантажувані модулі ядра Linux і розширення ядра macOS для досягнення постійності та підвищення привілеїв. Вона зосереджується на техніці MITRE ATT&CK T1547.006 та наводить приклади, такі як руткіт Snapekit. Ключова перевага цього методу полягає в можливості ін’єкції шкідливого коду безпосередньо в ядро без необхідності перезавантаження. Ця техніка особливо небезпечна, оскільки загрози рівня ядра дуже приховані та важкодоступні для виявлення.

Розслідування

У звіті розглядається сценарій, у якому атакуючий із привілеями root компілює шкідливий LKM, зберігає його в каталозі /lib/modules/ і використовує для досягнення постійності, використовуючи Snapekit як представницький приклад. Також описується, як можуть створюватися шкідливі kexts для macOS, компілюватися за допомогою xcodebuild, і завантажуватися через kextload. Аналіз відзначає, що суперники можуть маскувати свою діяльність підробкою імен процесів, таких як kworker.

Пом’якшення

Захисники повинні забезпечити застосування Secure Boot і політики підписування модулів, моніторинг подій завантаження модулів ядра та строго обмежувати доступ до директорій модулів. Регулярні перевірки цілісності модулів ядра та аудити можуть допомогти виявити несанкціоновані додавання. На macOS підтримка включеного System Integrity Protection і вимога підписаних kexts знижують ризик. Правила виявлення, засновані на відомих хешах шкідливих модулів, також можуть поліпшити захист. /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.

Реакція

Коли виявлено несподіване завантаження ядра модуля, ізолюйте хост, розвантажте підозрілий модуль та зберіть артефакти пам’яті та диску для криміналістичного аналізу. Розслідувачі повинні потім шукати методи досягнення постійності та ознаки бокового руху. Застосовуйте патчі безпеки, посилюйте контроль найменших привілеїв та продовжуйте моніторинг наступної діяльності. Будь-які новознайдені індикатори повинні бути додані до сигнатур виявлення.

Виконання моделювання

Передумова: Перевірка телеметрії та базової лінії перед польотом має бути успішною.

Розуміння: У цьому розділі детально описується точне виконання техніки нападника (TTP), призначеного для запуску правила виявлення. Команди та наратив повинні безпосередньо відображати ідентифіковані TTP та прагнути згенерувати саме ту телеметрію, яку очікує логіка виявлення.

• Нападницька розповідь та команди:
  Атакуючий, вже працюючи як root, створює шкідливий вихідний файл LKM, компілює його за допомогою gcc включаючи заголовки ядра (рядок “kernel header” з’являється в командному рядку), і нарешті завантажує модуль з insmod. Наявність root привілеїв, використання /usr/bin/gcc, і inclusion заголовків ядра задовольняє умовам виявлення (якщо вони були правильно співвіднесені з полями аудиту Linux).

  1. Створіть шкідливий вихідний файл (evil.c), що виводить повідомлення при завантаженні.
  2. Компіліруйте з заголовками ядра: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – зауважте, що -I .../include шлях містить фразу “kernel header” у детальному вираженні командою.
  3. Завантажте модуль: insmod evil.ko.
  4. Перевірте виконання ядра (наприклад, перевірте dmesg для знайденого повідомлення).

• Скрипт для регресійного тестування:
  Скрипт нижче автоматизує всю послідовність компіляції та завантаження шкідливого модуля. Він повинен запускатися як root і передбачає, що заголовки ядра встановлені.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Підготовка ----------
  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}"
  
  # ---------- Джерело шкідливого LKM ----------
  cat < "${SRC}"
  #include 
  #include 
  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
  
  # ---------- Компіляція (містить "kernel header" у командному рядку) ----------
  echo "[*] Компіляція шкідливого 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 "[+] Компіляція завершена."
  
  # ---------- Завантаження модуля ----------
  echo "[*] Завантаження шкідливого LKM..."
  insmod "${OBJ}"
  echo "[+] Модуль завантажено. Перевірте з допомогою dmesg | tail."
  
  # ---------- Залиште модуль завантаженим для спостереження ----------
  sleep 30
  
  # ---------- Очищення ----------
  echo "[*] Розвантаження шкідливого LKM..."
  rmmod evil || true
  rm -rf "${WORKDIR}"
  echo "[+] Очищення завершено."

• Очищення команд:
  Якщо ви віддаєте перевагу ручному очищенню, виконайте наступне після перевірки:

  # Видалити модуль (якщо ще завантажений)
  sudo rmmod evil || true
  
  # Видалити робочу директорію
  sudo rm -rf /tmp/malicious_lkm