T1547.006 Módulos de Kernel e Extensões no MITRE ATT&CK Explicados

Resumo

O artigo explica como invasores abusam de módulos de kernel carregáveis do Linux e extensões de kernel do macOS para obter persistência e elevar privilégios. Ele foca na técnica do MITRE ATT&CK T1547.006 e faz referência a exemplos como o rootkit Snapekit. Uma vantagem chave desse método é a capacidade de injetar código malicioso diretamente no kernel sem necessidade de reinicialização. A técnica é especialmente perigosa porque ameaças em nível de kernel são altamente furtivas e difíceis de detectar.

Investigação

O relatório revisa um cenário em que um invasor com privilégios de root compila um LKM malicioso, armazena-o no diretório /lib/modules/ e o utiliza para persistência, usando o Snapekit como exemplo representativo. Também descreve como kexts maliciosos para macOS podem ser criados, compilados com xcodebuild, e carregados via kextload. A análise observa que adversários podem disfarçar atividade falsificando nomes de processos como kworker.

Mitigação

Os defensores devem impor políticas de Secure Boot e assinatura de módulo, monitorar eventos de carregamento de módulos de kernel e restringir estritamente o acesso privilegiado aos diretórios de módulos. Verificações regulares de integridade de módulos de kernel e auditorias de /lib/modules/ podem ajudar a identificar adições não autorizadas. No macOS, manter o System Integrity Protection ativado e exigir kexts assinados reduz o risco. Regras de detecção baseadas em hashes de módulos maliciosos conhecidos também podem melhorar a defesa.

Resposta

Quando um carregamento inesperado de módulo de kernel é detectado, isole o host, descarregue o módulo suspeito e colete artefatos de memória e disco para análise forense. Os investigadores devem então procurar métodos de persistência e sinais de movimentação lateral. Aplique patches de segurança, fortaleça os controles de menor privilégio e continue monitorando atividades subsequentes. Quaisquer indicadores recém-descobertos devem ser adicionados às assinaturas de detecção.

Execução de Simulação

Pré-requisito: O Check de Pré‑voo de Telemetria & Baseline deve ter passado.

Justificativa: Esta seção detalha a execução precisa da técnica do adversário (TTP) projetada para acionar a regra de detecção. Os comandos e a narrativa DEVEM refletir diretamente os TTPs identificados e visam gerar a telemetria exata esperada pela lógica de detecção.

• Narrativa e Comandos do Ataque:
  O invasor, já operando como root, cria um arquivo fonte de LKM malicioso, compila-o com gcc enquanto inclui explicitamente os cabeçalhos do kernel (a string “kernel header” aparece na linha de comando), e finalmente carrega o módulo com insmod. A presença de root privilégios, o uso de /usr/bin/gcc, e a inclusão de cabeçalhos de kernel satisfazem as condições de detecção pretendidas (se foram corretamente mapeadas para campos de auditoria do Linux).

  1. Criar fonte maliciosa (evil.c) que imprime uma mensagem quando carregada.
  2. Compilar com cabeçalhos de kernel: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko – note que o -I .../include caminho contém a frase “kernel header” quando expressa de forma verborrágica na linha de comando.
  3. Carregar o módulo: insmod evil.ko.
  4. Validar execução do kernel (por exemplo, verificar dmesg para a mensagem impressa).

• Script de Teste de Regressão:
  O script abaixo automatiza toda a sequência de compilação e carregamento malicioso. Deve ser executado como root e assume que os cabeçalhos de kernel estão instalados.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- Preparação ----------
  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}"
  
  # ---------- Fonte Maliciosa LKM ----------
  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
  
  # ---------- Compilação (contém "kernel header" na linha de comando) ----------
  echo "[*] Compilando LKM malicioso..."
  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 "[+] Compilação finalizada."
  
  # ---------- Carregue o módulo ----------
  echo "[*] Carregando o LKM malicioso..."
  insmod "${OBJ}"
  echo "[+] Módulo carregado. Verifique com dmesg | tail."
  
  # ---------- Mantenha o módulo carregado para observação ----------
  sleep 30
  
  # ---------- Limpeza ----------
  echo "[*] Descarregando o LKM malicioso..."
  rmmod evil || true
  rm -rf "${WORKDIR}"
  echo "[+] Limpeza completa."

• Comandos de Limpeza:
  Se preferir limpeza manual, execute o seguinte após a verificação:

  # Remova o módulo (se ainda estiver carregado)
  sudo rmmod evil || true
  
  # Exclua o diretório de trabalho
  sudo rm -rf /tmp/malicious_lkm