はじめに
Checkpoint Researchのマルウェア分析チームが報告した内容です。
中国の攻撃者がマルウェアの開発環境を削除し忘れたため、攻撃者がマルウェア作成にどのようなアプローチを行っているのかAIを活用している証拠と合わせて非常に貴重な情報が得られています。
実際に今回作成されたマルウェアを使った攻撃により被害が出ている事例は確認できていませんが、すでに攻撃者がAIを活用しながら攻撃を組み立てている事実に変わりがなく攻撃者がAIを活用し新たな攻撃手法を生み出す時代に突入しています。
Voidlinkとは
今回の中国の攻撃者が消し忘れた開発環境において作成されていた
AI（LLM）によって短期間で生成された、クラウド・Kubernetes 環境を主戦場とする次世代の攻撃フレームワークです。
従来の「OSやファイルを侵害するマルウェア」とは異なり、クラウドのアイデンティティ（IAM / API Keys / Secrets）を奪取し、API 経由で横展開するという、現在のクラウド利用実態に完全に最適化された設計を持っています。
アーティファクトのタイムスタンプを根拠に、AIを用いて約1週間で88,000行を超えるコードが生成されたと推定しています。
ここで重要なのは、AIがコードの一部を書くだけでなく、複雑なソフトウェアの計画・実装・改善を支援し活用されているという点です
check Point Research（以下、CPR）は、VoidLinkの初期サンプルを発見しました。Linuxを中心に、クラウド・コンテナ・Kubernetes環境での活動を想定したフレームワークとして報告しています。
本記事では、開発にAIが関与した根拠、技術的な特徴、運用者が確認したい防御ポイントを整理します。
1. 「AI生成マルウェア」をどう捉えるか
まず、次の2つは分けて考える必要があります。
| 区分 | AIの利用方法 |
|---|---|
| 開発時のAI利用 | 設計、コード生成、テスト、修正などをAIが支援する |
| 実行時のAI利用 | 動作中のプログラムがLLMを呼び出し、その出力を利用する |
VoidLinkで注目すべきなのは、主に開発時のAI利用です。AIへの指示や開発計画、仕様書、テストレポートなど、開発プロセスへのAIの関与を示す情報があります。
中国の攻撃者によるAIの関与を示す開発の証拠
調査の手がかりとなったのは、開発者側が外部からアクセス可能な状態で残していたソースコード、バージョン履歴、ログ、AIへのプロンプト関連ファイルです。
さらに、AI開発環境「TRAE」に関連するヘルパーファイルが残っており、元の指示の一部を確認できました。
開発方法は、**仕様駆動開発（Spec Driven Development：SDD）**です。アーキテクチャや仕様、作業計画を整理し、それらを実装の土台として利用する流れが示されています。
攻撃者が痕跡を残したミスとAIを利用した証拠
攻撃者が犯したOPSECのミス、つまり攻撃者の誤算です。
通常、高度な攻撃者は自分の痕跡を徹底的に消します。使ったツール、書いたコード、残したログ、すべてを削除してから撤退するのが鉄則です。
しかし今回の攻撃者は、開発中のサーバーに大量の痕跡（アーティファクト）を残したまま、外部からアクセスできる状態にしていました。
OPSECのミスによって発見されたフォルダーの中に、TRAEというツールの痕跡がありました。
TRAEとは何か。簡単に説明します。
TRAEはAIエージェントを組み込んだ次世代型のプログラミング開発環境です。通常の開発環境と何が違うかというと、開発者がAIに対して「こういうものを作りたい」と指示するだけで、AIが自律的にコードを書き、テストし、改善まで行ってくれます。つまりAIがソフトウェアエンジニアチームの役割を担うツールです。
そのTRAEのヘルパーファイルがソースコードと一緒に残されていました。
ファイルの内容は中国語で高度に構造化されており、AIへの指示が細かく記載されていました。
特に興味深いのがこの部分です。AIに対して**「アーキテクチャレビューと分析のみを行い、ステルスや侵入に関する技術的な実装は行わないこと」と明示的に指示していました。
つまり攻撃者は最初からAIの安全機能を意識し、直接「マルウェアを作れ」と命令するのではなく、設計書の分析という形で巧みにAIを誘導していたのです。
これがVoidLinkの開発にAIが深く関わっていたことを示す、最初の決定的な証拠でした。
先ほどのスライドで、AIへの指示に「ステルスや侵入の実装はしないこと」と明記されていたことをお伝えしました。
では実際にどうやってマルウェアを開発させたのか。
答えは仕様駆動開発（Spec Driven Development）**です。
まず「c2 architecture.txt」という設計書を作成し、それをAIに渡して「アーキテクチャを分析し実装せよ」と指示しました。
「マルウェアを作れ」とは一度も命令していません。
設計書の分析という形を取ることで、AIの安全機能を回避しながら、実質的にフル機能のマルウェアを開発させることに成功したのです。
AIを悪用する手口として、これまでに見たことのない極めて巧妙なアプローチです。
先ほどTRAEを使って開発が進められたとお伝えしました。その証拠が、サーバーに大量に残されていたMarkdownファイルです。
Markdownファイルとは、エンジニアが設計書やメモを書く際に使う文書形式です。
これらのファイルを見ると、AIがまるでプロの開発チームのマネージャーのように振る舞っていたことがわかります。
開発は3つのチームに分割されていました。コードの書き方の標準、テスト結果のレポート、そして20週間分のスプリント計画まで、すべてAIが生成していました。
スプリントとは開発作業を短い期間に区切って進める手法で、大規模なソフトウェア開発でよく使われます。
つまりAIは単にコードを書いただけでなく、プロジェクト全体の計画・管理・品質基準までを担っていたのです。
一人の人間がAIを使って、まるで数十人規模の開発チームを動かすようにVoidLinkを作り上げていたということです。
ここからは、VoidLinkの開発においてAIがどのように活用されたかをお見せします。
このドキュメントはAIが生成したアーキテクチャ設計書です。タイトルは「VoidLink-2025 三端功能対照分析」、つまり3つのコンポーネントの機能関係を分析したものです。
3つのコンポーネントとは何か。下の図をご覧ください。
C2 Server（Go言語） が司令塔です。攻撃者が操作するサーバーです。
Implant Core（Zig言語） が実行部隊です。標的のコンピューターに埋め込まれるエージェントです。
Loader0（Zig言語） が侵入担当です。インプラントを標的に送り込む役割を担います。
そして下のドキュメントを見てください。「The GhostWire Bible」と題されたこの文書には、機密レベルとして「Top Secret / Red Team Internal」と明記されています。
Red Teamとは本来、企業のセキュリティを検証するために擬似的な攻撃を行う専門チームのことです。しかしここでは明らかに攻撃ツールの開発に使われています。
AIに対して「これはRed Team用のツールだ」と説明することで、安全機能を巧みに回避していたと考えられます。
タイトルは「VoidLink-2025 ベンチマーク成熟C2深度改善計画」。つまりVoidLinkを既存の有名なC2フレームワークと比較して、自らの弱点を把握し改善するための文書の痕跡がありました。
ベンチマークの対象はCobalt Strike、Sliver、Mythicという3つの有名なC2フレームワークです。
比較表を見てみましょう。
アーキテクチャの設計では、SliverやMythicがプラグインを自由に追加できる柔軟な設計なのに対し、VoidLinkはプラグイン間の結合度が高いという弱点が指摘されています。
ファイルレス実行では、既存ツールが複数の実行手法を持つのに対し、VoidLinkは一つの手法しか持たないという課題が明記されています。ファイルレス実行とは、ファイルをディスクに書き込まずにメモリ上だけで動作する技術で、検知が非常に困難です。
トラフィック偽装では、VoidLinkの通信パターンが検知されやすいという弱点が指摘されています。
重要なのは、これらの弱点が後続バージョンで実際に改善されていることが確認されている点です。
つまりAIを使って競合分析を行い、PDCAサイクルを回すように自らを進化させていたのです。これは単なるコード生成を超えた、非常に高度なAI活用と言えます。
そして最も驚くべき事実がこれです。
タイムスタンプの分析から、VoidLinkはアイデアを思いついてからバージョン1.0が完成するまで、わずか1週間だったと推定されます。
その間に生成されたコードの量を見てください。
インプラントコア（Zig言語）が53,873行、C2サーバー（Go言語）が29,721行、プラグイン（C言語）が約5,000行、合計約88,594行です。
88,594行というのがどれほどの量か、少し説明します。一般的なソフトウェアエンジニアが1日に書けるコードは、品質を保ちながらであればせいぜい数十行から数百行です。つまり通常の開発では、このコード量を書くだけで数ヶ月から1年以上かかる計算になります。
それがわずか1週間です。
私たちはここで当初の仮説を完全に見直すことになりました。「これだけの開発は複数人のチームによるものだ」と考えていましたが、証拠を総合すると単独の個人による開発である可能性が非常に高いのです。
AIを使えば、ソフトウェア開発の知識を持つ一人の人間が、1週間でフル機能のC2フレームワークを作れる時代が来ているということです。
これが本日最も皆さんにお伝えしたいメッセージの一つです。
2. VoidLinkの機能概略 クラウド環境を意識した設計
実行環境の識別
VoidLinkがクラウド関連情報やメタデータ、コンテナ環境の情報などを利用して、自身の実行環境を識別できます。
また、cgroupやnamespaceなどの情報を使ったコンテナ環境の検出や、KubernetesのServiceAccountに関する情報の確認しています。
防御側にとって重要なのは、ホスト単体の状態に加えて、そのワークロードにどの権限を与えているかまで確認することです。
同じコンテナ侵害でも、読み取り専用の権限しか持たない場合と、広範囲のリソースを変更できる場合では、想定すべき影響が異なります。
監視環境に応じた挙動の調整
VoidLinkがセキュリティツールや監視環境を確認し、通信間隔や活動速度などを調整する「Adaptive Stealth」を実現しています。
ただし、環境に応じて処理を切り替える機能の存在だけでは、実行時にAIが判断している証拠にはなりません。条件分岐やスコアリングによる実装でも、適応的な挙動は実現できます。
運用面では、短時間の大量通信だけでなく、低頻度で継続する不審な活動も調査対象に含める、という考え方が重要です。
3. モジュール構成と管理画面
VoidLinkは、Plugin APIを通じて機能を拡張するモジュール構成を採用しています。ファイル操作やネットワーク関連の機能などをコアAPIとして提供する設計があります。
プラグイン数は、管理画面の説明では「37種」と表記されています。多数の機能を追加・管理できる構造に注目します。
管理画面には、インプラントの管理だけでなく、認証情報、プラグイン、タスク、通信などを扱う機能がまとまっています。
4. ファイルレス実行と隠蔽をどう理解するか
ディスク上のファイルだけに依存しない監視
memfd_createやexecveatを利用した、メモリ上でのロード・実行を実現しています。
ディスク上のファイル作成を中心とした検知では見えにくくても、調査・監視の対象には次のようなものがあります。
- プロセスの生成と親子関係
- システムコールや実行イベント
- 外部へのネットワーク接続
- クラウドAPIの呼び出し
- 認証情報の利用状況
これらの可視性は、監視製品の対応範囲や設定、ログの取得条件によって変わります。
特定のシステムコールを使ったという理由だけで悪性と判定せず、実行元や通信先などの文脈と組み合わせる必要があります。
環境に応じた隠蔽手法
VoidLinkが実行環境に応じて、ユーザー空間やカーネルに関係する複数の隠蔽手法を選択する設計が実装されています。
ただし、eBPF自体は正規の監視や性能分析にも使う技術です。eBPFの利用を一律に悪性とみなすのではなく、誰が、どの権限で、どのようなプログラムをロードしたかを確認することが重要です。
また、「プロセスを隠すこと」と「再起動後も活動を継続できること」は別の性質です。隠蔽機能の存在だけから、永続化まで成立すると判断しないようにします。
5. 認証情報とNHIが防御上の重要ポイント
IAMに関連する認証情報、APIキー、CI/CDのSecrets、Gitの認証情報、KubernetesのServiceAccountなどを重要な対象として挙げています。
ここで登場する NHI（Non-Human Identity） は、アプリケーションやワークロードなど、人間以外の主体が利用するアイデンティティを指します。
実務では、主体そのものと、その主体として認証するためのキーやトークンを分けて管理すると整理しやすくなります。
影響範囲を決めるのは、付与された権限
認証情報が漏洩したからといって、必ずクラウド全体を操作できるわけではありません。影響は、その認証情報の権限、利用条件、有効期限、アクセス先のポリシーなどに左右されます。
同様に、KubernetesのServiceAccountトークンを取得しただけで、必ずクラスタ管理者になれるわけでもありません。
そのため、侵害時には端末やコンテナの隔離に加え、次の確認が必要です。
- そのワークロードから参照可能だった認証情報
- 認証情報に付与していた権限
- 不審な利用履歴
- 失効やローテーションが必要な範囲
コンテナを再作成しただけで対応を終えず、外部に持ち出された可能性のある認証情報まで確認する、という考え方が重要です。
6. VoidLinkの具体的な画面
バイナリ解析では技術的な仕組みが、ダッシュボードからは攻撃者の意図と運用の実態が、それぞれ見えてきます。この2つの視点を組み合わせることで、VoidLinkの全貌を立体的に把握することができました。
では実際にダッシュボードを見ていきましょう。
（ダッシュボード機能一覧）
VoidLinkのパネルが持つ全機能を、3つのカテゴリに整理しました。
まず左の列、Dashboard（ダッシュボード）です。 ここはいわば司令塔です。 Implants（感染エージェントの管理）、Terminal（リモート操作）、Builder（インプラントの生成）という3つの機能が含まれます。攻撃者はここから全体を俯瞰し、感染ホストを一元管理します。
次に中央の列、Attack（攻撃モジュール）です。 ここは実際の攻撃行動を実行する機能群です。 Reconnaissance（偵察）、Credentials（認証情報の窃取）、Persistence（永続化）、Lateral Movement（横断的移動）、Process Injection（プロセスインジェクション）、Hidden Modules（モジュールの隠蔽）、Wipe Evidence（証拠の消去）が含まれます。侵害後にやるべきことが一通り揃っています。
そして右の列、Infrastructure（インフラ管理）です。 ここはVoidLink自身を維持・隠蔽するための機能群です。 Tunneling（通信トンネルの構築）、File Management（ファイル管理）、Plugin Management（プラグイン管理）、Task Management（タスク管理）、Setup（初期設定）が含まれます。
この3分割は非常に重要な意味を持っています。 「侵入する・暴れる・維持する」 という攻撃のライフサイクル全体が、一つのパネルから完結して操作できる設計になっているのです。
この設計思想こそがVoidLinkを単なるマルウェアではなく、フルスペックのC2フレームワークと呼ぶ最大の理由です。
（インプラント）
感染エージェントの管理画面です。36台中5台がオンライン、29台がオフラインでした。研究チームが発見した時点では、これらが実際の被害者のマシンなのかテスト環境なのかは判断できませんでした。ホスト名「VM-0-17-tencentos」からTencent Cloudの使用が示唆されています。
（認証情報）
認証情報収集モジュールの画面です。SSHキー・SSH設定、Bashヒストリー、環境変数（APIキー・トークン）、ブラウザパスワード・Cookie、AWS認証情報、GCP証明書などを選択的に収集できます。ソフトウェアエンジニアやクラウド管理者を標的としている可能性が高く、サプライチェーン攻撃への転用も懸念されます。
（ステルス）
ルートキット機能の管理画面です。LKM・eBPF・プロセス/ポート/ファイル隠蔽を操作者がGUIから直接制御できます。netstat/ss出力からのポート隠蔽、ps/top出力からのプロセス隠蔽、ls/find出力からのファイル隠蔽、そして/proc/PID/exeシンボリックリンクの隠蔽に対応しています。
（カスタマイズ可能なインプラントのビルド）
インプラントのビルド設定画面です。ターゲット種別（Bundle/Implant/Stage1/Loader0）、通信プロトコル、回避レベル（コード整合性チェック・SMC・アンチサンドボックス）、ワンタイムリンク、シンボル情報の有無など、多岐にわたるオプションを選択できます。研究チームはシンボル情報付きのバイナリを初期段階で入手できたため、解析が大幅に容易になりました。
（プラグイン）
37種のプラグインが搭載されたプラグイン管理画面です。偵察系（net_ifconfig_v3、port_scanner_v3など8種）、証拠隠滅系（history_wipe_v3、log_wiper_v3など3種）、パッケージング系（k8s_exec_v3、docker_escape_v3、k8s_privesc_v3など3種）が含まれます。KubernetesとDockerに特化したプラグインが、クラウドネイティブ環境を強く意識していることを裏付けています。
7. 運用者が確認したい防御チェックリスト
防御策は、Linux・コンテナのランタイム監視、クラウド監査ログ、IAMの最小権限化、Secrets管理などを組み合わせる構成です。
以下は、それを運用上の確認項目として整理したものです。すべての項目を満たせば安全を保証できる、という意味ではありません。
ワークロードの可視性
- Linux・コンテナ・Kubernetesが監視対象に含まれている
- ファイル検査に加え、プロセスや実行イベントを確認できる
- 監視エージェントの停止やログ欠落を把握できる
- 短命なPodの終了後も、必要なログを参照できる
IAMと認証情報
- ワークロードごとの権限と所有者を把握している
- 不要な管理権限や広すぎるアクセス許可を削減している
- 長期有効なキーを減らし、短期認証情報の利用を検討している
- GitやCI/CDに保存したSecretsを棚卸ししている
- 漏洩時の失効・交換手順と担当者が決まっている
ログと調査
- クラウド監査ログの取得対象を確認している
- 必要な操作が実際に記録されることをテストしている
- ワークロードの挙動とAPI操作を時系列で突き合わせられる
- ログの保存期間と改ざん対策を、調査要件に合わせて設定している
初期侵入の予防
- インターネット公開資産と不要な公開設定を把握している
- 脆弱性や設定不備を、外部からの到達性と合わせて優先順位付けしている
- 委託先や開発基盤からのアクセス権限を見直している
8. AI時代の防御で変えるべきこと
侵入後の検知・対応に加えて、外部公開資産、脆弱性、設定不備などを継続的に把握し、侵入につながる条件を減らす考え方を示しています。
AIを活用した開発によって攻撃ツールの改良が速くなるなら、防御側も「導入した時点で完了」という運用から離れる必要があります。
まず取り組みたいのは、大規模な仕組みの追加よりも、次のような具体的な確認です。
- 重要なワークロードが持つ権限を説明できるか。
- そのワークロードで不審な実行が起きたとき、調査に必要な情報が残るか。
- 認証情報の漏洩を想定した失効・交換を実施できるか。
- 公開設定や権限の変更を、継続的に把握できるか。
まとめ
VoidLinkの事例で注目したいのは、中国の攻撃者によりAIが開発工程に深く関与している点と、クラウド環境を意識した機能が一つのフレームワークにまとまっている点です。
防御側には、Linuxやコンテナの実行状況に加えて、IAM、Secrets、クラウドAPIの利用状況を横断的に確認する視点が求められます。
また攻撃者がAIを使い脆弱性や設定ミスをスキャンしてくる外部侵入攻撃対策には弊社のAIを使ったペネトレーションテストAEV（Agentic Exposure Validation）をおすすめいたします。少し高度なペネトレーション1回と同じぐらいのコストでAIを用いて多いときで1万回を超える疑似攻撃を54回/年レポート合わせて行うことができます。詳細は下記リンクをご参照ください
