SOC Prime Bias: 危機的

30 3月 2026 17:07

T1547.006 カーネルモジュールと拡張機能:MITRE ATT&CK 解説

Author Photo
Ruslan Mikhalov SOC Primeの脅威リサーチ責任者 linkedin icon フォローする
T1547.006 カーネルモジュールと拡張機能:MITRE ATT&CK 解説
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

概要

この記事は、攻撃者が Linux のロード可能カーネルモジュールや macOS のカーネル拡張を悪用して持続性を確保し、権限を昇格させる方法を説明しています。MITRE ATT&CK の T1547.006 技術に焦点を当て、Snapekit ルートキットなどの例を参照しています。この方法の主な利点は、再起動を必要とせずに悪意のあるコードを直接カーネルに注入できることです。この技術はカーネルレベルの脅威が非常にステルスで発見が困難であるため、特に危険です。

調査

このレポートは、ルート権限を持つ攻撃者が悪意ある LKM をコンパイルし、それを /lib/modules/ ディレクトリに保存して持続性を持たせ、Snapekit を代表例として利用するシナリオをレビューしています。また、どのようにして悪意のある macOS kext を作成し、 xcodebuildでコンパイルし、 kextloadでロードするかを説明しています。分析は、kworker などのプロセス名を偽装して活動を隠蔽する可能性があることに触れています。

緩和策

防御側は、Secure Boot やモジュール署名ポリシーを施行し、カーネルモジュールのロードイベントを監視し、モジュールディレクトリへの特権アクセスを厳格に制限すべきです。カーネルモジュールの定期的な整合性チェックと /lib/modules/ の監査により、許可されていない追加を表面化することができます。macOS では、System Integrity Protection を有効にし、署名された kext を求めることでリスクを低くします。既知の悪意あるモジュールのハッシュに基づいた検出ルールも防御を強化できます。

対応

予期しないカーネルモジュールのロードが検出された場合、ホストを隔離し、疑わしいモジュールをアンロードし、フォレンジック分析のためにメモリとディスクのアーティファクトを収集します。調査者は、その後、持続化の手法や横移動の兆候を探します。セキュリティパッチを適用し、最低権限の制御を強化して、その後の活動を引き続き監視する必要があります。新しく発見されたインジケーターは、検出シグネチャに追加されるべきです。

攻撃の流れ

この部分はまだ更新中です。通知を受け取るためにサインアップしてください。

通知する

シミュレーション実行

前提条件: テレメトリとベースラインのプリフライトチェックが通過している必要があります。

合理性: このセクションでは、高精度な adversary technique (TTP) の実行について説明し、検出ルールをトリガーするために設計されています。コマンドと記述は、特定された TTP を直接反映し、検出ロジックが期待する正確なテレメトリを生成することを目的としています。

  • 攻撃の説明とコマンド:
    攻撃者は既に rootとして操作し、悪意ある LKM ソースファイルを作成し、それを gcc をコンパイルし、その後モジュールを insmodでロードします。この root 特権を利用し /usr/bin/gccを使用し、カーネルヘッダーのインクルードによって意図された検出条件を満たします (Linux の監査フィールドに正しくマッピングされている場合)。

    1. 悪意あるソースを作成する (evil.c)をロードするとメッセージを出力します。
    2. コンパイル カーネルヘッダーを使用して: gcc -Wall -c evil.c -I /lib/modules/$(uname -r)/build/include -o evil.ko 注意: -I .../include パスには「カーネルヘッダー」というフレーズが含まれています。
    3. モジュールをロードする: カーネルの実行を検証する (例: カーネルの実行を検証する (例: .
    4. Validate で出力されたメッセージを確認)。 で出力されたメッセージを確認)。 for the printed message).
  • リグレッションテストスクリプト:
    以下のスクリプトは、悪意のあるコンパイルおよびロードの一連の流れを自動化します。これは 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