タグ: malware

AIとサイバー攻撃 ― 道具は道具でしかないという現実

AIの進化は、日々の暮らしから産業、そして国家の安全保障に至るまで、あらゆる領域に影響を及ぼしています。生成AIの登場によって、これまで専門家にしか扱えなかった作業が一般の人々にも手の届くものとなり、効率や創造性は飛躍的に向上しました。しかしその裏側では、AIの力が「悪用」された場合のリスクが急速に拡大しています。

従来、サイバー攻撃の世界では、マルウェアやエクスプロイトコードを作成するために高度な知識と経験が必要でした。逆アセンブルや脆弱性解析といった作業は一部のエキスパートだけが担っていたのです。しかし現在では、AIに数行の指示を与えるだけで、悪意あるスクリプトや攻撃手法を自動生成できるようになっています。これは「専門知識の民主化」とも言えますが、同時に「攻撃の大衆化」につながる深刻な問題です。

最近の「HexStrike-AI」によるゼロデイ脆弱性の自動悪用や、過去にダークウェブで取引された「WormGPT」「FraudGPT」の存在は、AIが攻撃側に強力な武器を与えてしまう現実を如実に示しています。AIは本来、防御や検証、効率化のための技術であるにもかかわらず、使い手次第で攻撃の矛先となりうるのです。こうした事例は、AIを「私たちを助ける武器にも私たちを傷つける凶器にもなり得る中立的な道具」として捉える必要性を、改めて私たちに突きつけています。

HexStrike-AIの衝撃

HexStrike-AIは、本来はセキュリティのレッドチーム活動や脆弱性検証を支援する目的で開発されたAIツールでした。しかし公開直後から攻撃者の手に渡り、数々のゼロデイ脆弱性を悪用するための自動化ツールとして利用されるようになりました。特にCitrix NetScaler ADCやGateway製品の脆弱性（CVE-2025-7775、-7776、-8424など）が標的となり、公開からわずか数時間で実際の攻撃が観測されています。

従来のサイバー攻撃では、脆弱性の発見から実際のエクスプロイト開発、そして攻撃キャンペーンに至るまでには一定の時間が必要でした。防御側にとっては、その間にパッチを適用したり、検知ルールを整備したりする余地がありました。ところが、HexStrike-AIの登場によって状況は一変しました。脆弱性情報が公開されるとほぼ同時に、AIが攻撃手法を生成し、数分〜数十分の間に世界中で自動化された攻撃が開始されるようになったのです。

さらに深刻なのは、このツールが単に脆弱性を突くだけでなく、侵入後に自動的にWebshellを設置し、持続的なアクセスを確保してしまう点です。攻撃は単発的ではなく、継続的にシステム内部に居座る形で行われるため、被害の長期化や情報流出リスクが高まります。AIが複数のツールを統合し、まるで「指揮官」のように攻撃プロセスを統制する構造が、従来の攻撃ツールとの決定的な違いです。

防御側にとっては、これまで以上に迅速なパッチ適用や侵入兆候の検知、そしてAIによる攻撃を前提とした防御の自動化が求められる状況となっています。もはや人間の手作業による防御では時間的に追いつかず、セキュリティ運用そのものをAIで強化しなければならない時代が到来したことを、HexStrike-AIは強烈に示したと言えるでしょう。

AIによる攻撃自動化の広がり

HexStrike-AIは氷山の一角にすぎません。AIを用いた攻撃自動化の動きはすでに複数の事例で確認されており、その広がりは年々加速しています。

まず注目すべきは WormGPT や FraudGPT と呼ばれる闇市場向けAIです。これらはChatGPTのような対話インターフェースを持ちながら、あえて安全装置を外して設計されており、通常なら拒否されるようなフィッシングメールやマルウェアコードの生成を簡単に行えます。これにより、サイバー攻撃の経験がない人物でも、数行の指示を与えるだけで本格的な詐欺メールや攻撃スクリプトを入手できるようになりました。つまり、AIは攻撃の「参入障壁」を取り払い、攻撃者人口そのものを増加させる方向に作用しているのです。

さらに、悪意あるファインチューニングも大きな脅威です。大規模言語モデルにダークウェブから収集した不正なデータを学習させることで、ゼロデイエクスプロイトやマルウェア断片を即座に生成する「攻撃特化型AI」が登場しています。こうした手法は、オープンソースモデルの普及により誰でも実行可能になりつつあり、攻撃能力の拡散スピードは従来の想定を超えています。

また、正規の開発支援ツールである GitHub Copilot や他のコード補完AIも悪用される可能性があります。例えば「特定の脆弱性を含むコード」を意図的に生成させ、それを攻撃用に改変する手法が研究や実証実験で示されており、開発ツールと攻撃ツールの境界があいまいになりつつあります。

このように、AIは「攻撃の効率化」だけでなく「攻撃の大衆化」と「攻撃の多様化」を同時に進めています。攻撃者の知識不足や開発コストがもはや制約にならず、AIが提供する無数の選択肢から最適な攻撃パターンを自動で導き出す時代に突入しているのです。結果として、防御側はこれまで以上に迅速で高度な対策を求められ、静的なルールやブラックリストだけでは追いつけなくなっています。

道具としてのAI

AIを巡る議論でしばしば出てくるのが、「AIは善にも悪にもなり得る」という視点です。これは、古来から存在するあらゆる「道具」や「武器」に共通する特性でもあります。包丁は家庭で料理を支える必需品ですが、使い方次第では凶器となります。自動車は移動を便利にする一方で、過失や故意によって重大事故を引き起こす可能性を持っています。火薬は鉱山開発や花火に用いられる一方で、戦争やテロに利用されてきました。AIもまた、この「中立的な力」を体現する存在です。

HexStrike-AIのような事例は、この現実を鮮明に映し出しています。本来、防御のためのシミュレーションやセキュリティ検証を支援する目的で作られた技術が、攻撃者に渡った瞬間に「脅威の拡張装置」と化す。これは道具や武器の歴史そのものと同じ構図であり、人間の意図がAIを通じて強大化しているに過ぎません。AIは「自ら悪意を持つ」わけではなく、あくまで利用者の手によって結果が決まるのです。

しかし、AIを単なる道具や武器と同列に語るだけでは不十分です。AIは自己学習や自動化の機能を持ち、複雑な攻撃シナリオを人間よりも高速に組み立てられるという点で、従来の「道具」以上の拡張性を備えています。人間が一人で実行できる攻撃には限界がありますが、AIは膨大なパターンを同時並行で試し続けることができるのです。この性質により、AIは単なる「刃物」や「火薬」よりもはるかに広範で予測困難なリスクを抱えています。

結局のところ、AIは人間の意志を増幅する存在であり、それ以上でもそれ以下でもありません。社会がこの「増幅効果」をどう制御するかが問われており、AIを善用するのか、それとも悪用の拡大を許すのか、その分岐点に私たちは立たされています。

安全装置の必要性

武器に安全装置が不可欠であるように、AIにも適切な制御やガードレールが求められます。AI自体は中立的な存在ですが、悪用を完全に防ぐことは不可能です。そのため、「被害を最小化する仕組みをどう設けるか」 が防御側に突きつけられた課題となります。

まず、モデル提供者の責任が重要です。大手のAIプラットフォームは、攻撃コードやマルウェアを直接生成させないためのプロンプトフィルタリングや、出力のサニタイズを実装しています。しかし、HexStrike-AIのように独自に構築されたモデルや、オープンソースモデルを悪用したファインチューニングでは、こうした制御が外されやすいのが現実です。したがって、検知メカニズムや不正利用を早期に察知するモニタリング体制も不可欠です。

次に、利用者側の備えです。企業や組織は、AIによる攻撃を前提としたインシデント対応能力を強化する必要があります。具体的には、脆弱性パッチの即時適用、ゼロトラストモデルに基づくアクセス制御、Webshellなど不正な持続化手法の検知強化などが挙げられます。また、AIが攻撃を自動化するなら、防御もAIによるリアルタイム監視・自動遮断へと移行していかざるを得ません。人間のオペレーターだけに依存したセキュリティ運用では、もはや速度の面で追いつけないのです。

さらに、社会的な枠組みも必要です。法規制や国際的なルール整備によって、AIの不正利用を抑止し、違反者に対して制裁を課す仕組みを整えることが重要です。これに加えて、教育や啓発活動を通じて、開発者や利用者が「AIは無制限に使える便利ツールではない」という認識を共有することも求められます。

結局のところ、安全装置は「万能の防御壁」ではなく、「暴発を減らす仕組み」に過ぎません。しかしそれでも、何もない状態よりは確実にリスクを抑えられます。HexStrike-AIの事例は、AIに対しても物理的な武器と同じく安全装置が必要であることを強く示しています。そして今後は、技術的対策・組織的対応・社会的ルールの三層で、複合的な防御を構築していくことが避けられないでしょう。

おわりに

AIは、料理に使う包丁や建築に使うハンマーと同じように、本質的にはただの道具です。道具はそれ自体が善悪を持つわけではなく、利用者の意図によって役立つ存在にも、危険な存在にもなります。HexStrike-AIやWormGPTの事例は、AIが人間の意志を増幅する中立的な存在であることを鮮明に示しました。問題は「AIが危険かどうか」ではなく、「AIという道具をどのように扱うか」にあるのです。

その一方で、包丁に鞘や取扱説明書があるように、AIにも安全装置や利用規範が必要です。悪用を完全に防ぐことはできませんが、ガードレールを設けることで暴走や誤用を最小化することは可能です。開発者は責任ある設計を行い、利用者はリスクを理解したうえで使い、社会全体としては法的・倫理的な枠組みを整備していく。この三層の仕組みがあって初めて、AIは「人類に役立つ道具」として機能するでしょう。

今回の事例は、AIがすでに攻撃にも防御にも使われる段階にあることを改めて示しました。今後は、防御側もAIを積極的に取り込み、攻撃のスピードに追随できるよう体制を整えていく必要があります。AIを「恐れるべき脅威」として一方的に排除するのではなく、「中立的な道具」として受け入れつつ、適切な安全策を講じることこそが求められています。

AIは、私たちの社会において新たに登場した強力な道具です。その行方は私たち次第であり、活かすも危うくするも人間の選択にかかっています。

参考文献

npm史上最大規模となる自己増殖型ワーム「Shai-Hulud」によるサプライチェーン攻撃

はじめに

2025年9月15日、JavaScript の主要パッケージエコシステムである npm において、これまでにない深刻なサプライチェーン攻撃が発覚しました。攻撃に使われたマルウェアは「Shai-Hulud」と名付けられており、その特徴は単なるパッケージ改ざんにとどまらず、自己伝播（ワーム）機能を備えている点にあります。これにより、感染したパッケージを利用した開発環境や CI/CD 環境から認証情報を奪い取り、さらに別のパッケージを自動的に改ざんして公開するという、従来の攻撃よりもはるかに広範な拡散が可能となりました。

被害は短期間で拡大し、確認されただけでも 200件近い npm パッケージが改ざんされており、その中には広く利用される有名ライブラリや大手企業関連のパッケージも含まれていました。OSS エコシステムは世界中の開発者や企業が依存する基盤であり、サプライチェーン攻撃は一部のパッケージ利用者だけでなく、そこからさらに派生する数多くのソフトウェアやサービスへ影響を与える可能性があります。

今回の Shai-Hulud 攻撃は、サイバー攻撃者がいかに OSS エコシステムを効率的な攻撃対象と見なしているかを改めて示すものであり、npm を利用するすべての開発者・組織にとって重大な警鐘となっています。本記事では、攻撃の概要や技術的な特徴を整理するとともに、想定されるリスクと具体的な対応方法について解説します。

背景

近年、ソフトウェアサプライチェーン攻撃は頻度と巧妙性を増しています。オープンソースパッケージは多くのプロジェクトで基盤的に利用されており，単一の改ざんが間接的に多数のシステムへ波及するリスクを常に伴います。特に JavaScript／npm エコシステムでは依存関係の深さと枝分かれが大きく，一つの小さなユーティリティが数千の最終アプリケーションに取り込まれることが珍しくありません。結果として，攻撃者は影響範囲を指数的に拡大できる利点を得ます。

npm は公開・配布のプロセスを自動化するためにトークンや CI ワークフローに依存していますが，これらは適切に管理されないと大きな攻撃面となります。長期有効の publish トークン，権限が過大な CI ランナー，組織共有の認証情報は侵害時に「自動で書き換える」「自動で公開する」といった自己伝播的な悪用を可能にします。加えて，postinstall 等の実行時フックはビルドや開発環境で任意コードを実行するため，ここに悪意あるコードが紛れ込むと検出が遅れやすい設計上の脆弱性があります。

運用面でも課題があります。開発者は多数の依存を素早く取り込みたいため，package-lock による固定や署名付き配布を怠りがちです。企業では利便性のためにトークンを共有したり，CI 用イメージやランナーを長期間使い回したりする運用が残存します。これらの実務的な慣行は，攻撃者にとって短時間で大規模な被害を生む温床となります。

過去のサプライチェーン攻撃の教訓から，検出と封じ込めには「開発環境・CI・レジストリ」の三点同時対応が必要であることが分かっています。Shai-Hulud のように自己伝播性を持つ攻撃は，これら三領域のいずれか一つでも緩みがあると急速に広がります。したがって，本件は単なるパッケージ単位の問題ではなく，組織の開発・配布プロセス全体を見直す契機として位置づけるべき事象です。

攻撃の技術的特徴

初期侵入

攻撃者は npm の publish トークンや GitHub の Personal Access Token（PAT）などの認証情報を取得して改ざんに利用しました。トークン取得経路としてはフィッシングや公開設定ミス、漏洩した CI 設定などが想定されます。これらのトークンはパッケージ公開権限を直接与えるため，侵害されると改ざんが短時間で実行され得ます。

改ざん手法

改ざん版には postinstall フックやバンドル化された実行スクリプト（例：bundle.js）が組み込まれます。npm install 時に自動実行されるため，開発者や CI が気づきにくく，ビルド段階でコードが動作する設計上の盲点を突きます。

情報収集と流出

実行スクリプトはローカル環境（環境変数、.npmrc 等）とクラウド環境（IMDS 等のメタデータエンドポイント）を探索して認証情報を収集します。収集したデータは攻撃者管理下の GitHub リポジトリやハードコードされた webhook にコミット／POST される仕組みが確認されています。

自己伝播（ワーム化）

感染した環境に残る有効トークンを悪用し，攻撃者は他パッケージを自動で改ざん・公開します。依存関係を介して連鎖的に拡散する点が本件の特徴です。短命で終わらない仕組みになっているため封じ込めが難しくなります。

持続化と権限操作

攻撃スクリプトは GitHub Actions ワークフローを追加したり，リポジトリを private→public に変更するなどして持続化と露出拡大を図ります。これにより単発検出後も再侵害や情報漏えいが継続するリスクが残ります。

検出困難性と難読化

実行コードはバンドル・難読化され，ファイル名やワークフロー名を変えることで痕跡を隠します。postinstall の存在自体が通常の開発フローの一部であるため，単純な目視だけでは発見されにくい設計です。

想定される影響と懸念

1. 認証情報・機密情報の流出と二次被害

改ざんされたパッケージの postinstall や実行スクリプトが開発端末・CI・クラウドのメタデータからトークンやキーを収集し外部に送信します。流出した認証情報は即時に不正利用され、以下の二次被害を引き起こす可能性があります。

  • リポジトリの不正操作（コミット、ワークフロー変更、公開設定切替）によるさらなる改ざん。
  • クラウド資源の不正利用（インスタンス起動、ストレージ操作、データベースアクセス）。
  • サードパーティサービスの乗っ取り（npm、CIサービス、サードパーティAPI）。

2. 依存関係を介した連鎖的な感染拡大

npm の依存グラフは深く広いため、ワーム的に拡散すると多数のプロジェクトに連鎖的影響が及びます。特に共有ライブラリやユーティリティが汚染されると、最終的な配布物や商用サービスにもマルウェアが混入するリスクが高まります。結果として被害の「範囲」と「追跡可能性」が急速に拡大し、封じ込めコストが指数的に増加します。

3. ビルド・デプロイチェーンの汚染と運用停止リスク

CI/CD パイプラインやビルドアーティファクトにマルウェアが混入すると、デプロイ先環境まで影響が及びます。企業は安全確認のためにビルド/デプロイを一時停止せざるを得なくなり、サービス停止やリリース遅延、ビジネス機会の損失につながります。

4. 検出困難性と長期的残存リスク

postinstall 実行や難読化されたスクリプトは発見が遅れやすく、感染が既に広がった後で検出されるケースが多くなります。さらに、改ざんコードが複数ファイルやワークフローに分散して保存されると、完全除去が難しく「再発」や「潜伏」が残るリスクがあります。

5. 信頼性・ブランド・法務的影響

顧客やパートナーに供給するソフトウェアにマルウェアが混入した場合、信頼失墜や契約違反、損害賠償請求につながる可能性があります。規制業界（金融・医療など）では報告義務や罰則が発生する場合があり、法務・コンプライアンス対応の負荷が増します。

6. インシデント対応コストと人的負荷

影響範囲の特定、シークレットのローテーション、CI の再構築、監査ログ解析、顧客対応など、対応工数とコストは大きくなります。特に短時間で多数のチーム・プロジェクトにまたがる場合、人的リソースの逼迫と対応優先順位の決定が課題となります。

7. 長期的なサプライチェーン健全性の劣化

繰り返しの改ざん事件は OSS 利用に対する過度な懸念を生み、外部ライブラリの採用抑制や自家製化（in-house）への回帰を促す可能性があります。これにより開発効率が低下しエコシステム全体の健全性に悪影響が及ぶ恐れがあります。

8. 観測・検出のギャップによる見落とし

短時間に大量の npm publish やワークフロー変更が行われた場合でも、既存の監視ルールでは閾値を超えるまで気付かない運用が珍しくありません。ログ保持期間やログの粒度が不十分だと、フォレンジック調査の精度が低下します。

マルウェアのチェック方法


セキュリティ専門企業のAikido Securityから対策パッケージが提供されています。

github.com
GitHub – AikidoSec/safe-chain: Protect against malicious code installed via npm, yarn, pnpm, npx, and pnpx with Aikido Safe Chain. Free to use, no tokens required.
Protect against malicious code installed via npm, yarn, pnpm, npx, and pnpx with Aikido Sa…

特徴

  • npmやyarnなどのパッケージマネージャのコマンドをラップし、パッケージインストール前にマルウェアチェックを実施します。
  • チェックはAikido Intelというオープンソースの脅威インテリジェンスに照らし合わせて検証します。
  • デフォルトではマルウェアが検出されるとインストールをブロックしてコマンドを終了します。これはユーザーに許可を求めるモードにも設定変更可能です。
  • 対応シェルは、Bash、Zsh、Fish、PowerShell、PowerShell Core
  • Node.js 18以上に対応してます。

といった特徴を持っています。

使い方

npmコマンドを使ってAikido Security Chainパッケージをインストールします。

$ npm install -g @aikidosec/safe-chain

added 110 packages in 6s

29 packages are looking for funding
  run `npm fund` for details

次に以下のコマンドを実行してシェル統合を設定します。

$ safe-chain setup
Setting up shell aliases. This will wrap safe-chain around npm, npx, and yarn commands.

Detected 3 supported shell(s): Zsh, Bash, Fish.
- Zsh: Setup successful
- Bash: Setup successful
- Fish: Setup successful

Please restart your terminal to apply the changes.

使用できるようにするにはターミナルを再起動してください。exec $SHELL -lでも動作しました。

インストールができたかどうかは以下のコマンドで確認します。インストールしようとしているパッケージはマルウェアとしてフラグされている無害なパッケージでシェル統合が成功しコマンドが正常にラップされている場合はブロックが成功します。

$ npm install safe-chain-test
✖ Malicious changes detected:
 - safe-chain-test@0.0.1-security

Exiting without installing malicious packages.

成功すればマルウェアのチェックが有効になっています。このチェックはパッケージのインストール時に行われるため、すでにプロジェクトがある場合は、一旦node_modulesを削除してからnpm installしてください。

$ rm -rf node_modules
$ npm install
✔ No malicious packages detected.
npm warn deprecated source-map@0.8.0-beta.0: The work that was done in this beta branch won't be included in future versions

added 312 packages, and audited 313 packages in 2s

73 packages are looking for funding
  run `npm fund` for details

1 low severity vulnerability

To address all issues, run:
  npm audit fix

Run `npm audit` for details.

これは私が開発中のライブラリで試した結果です。基本的に外部ライブラリに依存していないので、マルウェアは検出されませんでした。

一部開発用パッケージやMCP関連パッケージも標的になっていたので、グローバルインストールされているパッケージについても確認してください。グローバルパッケージの場合は対象パッケージを再度インストールすることでチェックができます。

アンインストール

アンインストールする場合は、

safe-chain teardown

でエイリアスを除去し、

npm uninstall -g @aikidosec/safe-chain

でパッケージをアンイストールし、ターミナルを再起動してください。

CI/CDへの組み込み方法

CI/CDへの組み込み方法についてもガイドされています。

help.aikido.dev
Malware Scanning with Safe Chain in CI/CD environments | Aikido

マルウェアを検知するためにディスクをスキャンするため、多くのパッケージに依存している場合はCIにかかる時間の増大やコスト増大を招く場合があります。影響を考慮して導入の可否を判断してください。

GitHub Actionsでの組み込み方法について見ていきます。

私が実際に使っている.github/workflows/ci.yamlは以下のようになっています。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"

      - run: npm install -g @aikidosec/safe-chain
 
      - run: npm install
      - run: npm run lint
      - run: npm run build --if-present
      - run: npm test

npm installを行う前にパッケージをインストールします。

      - run: npm install -g @aikidosec/safe-chain

      - run: npm install

次にnpm installのコマンドをaikido-npmに差し替えます。

      - run: aikido-npm install

これらの修正を行なった.github/workflows/ci.yamlは以下のようになります。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"

      - run: npm install -g @aikidosec/safe-chain

      - run: aikido-npm install
      - run: npm run lint
      - run: npm run build --if-present
      - run: npm test

以下はGitHub Actionsの実行結果の抜粋です。マルウェアのチェックが成功していることが確認できます。

Run aikido-npm install
Scanning 312 package(s)...
No malicious packages detected.
npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: '@isaacs/balanced-match@4.0.1',
npm warn EBADENGINE   required: { node: '20 || >=22' },
npm warn EBADENGINE   current: { node: 'v18.20.8', npm: '10.8.2' }
npm warn EBADENGINE }

CI/CDへの組み込みも比較的簡単に実施可能です。

まとめ

今回の Shai-Hulud 攻撃は、npm エコシステムにおけるサプライチェーンの脆弱性を突いた、これまでにない規模と性質を持つ事例でした。単なるパッケージ改ざんにとどまらず、インストール時に自動実行されるスクリプトを利用して認証情報を盗み取り、その情報を活用して別のパッケージを改ざんするという「自己伝播」の性質を持つ点が特に深刻です。これにより、短期間で数百件規模のパッケージが感染する事態となり、ソフトウェアサプライチェーン全体の信頼性に大きな影響を与えました。

本記事では、攻撃の仕組みと影響だけでなく、実際に開発者や企業が取るべき対応についても整理しました。具体的には、感染パッケージの特定と除去、シークレットの全面ローテーション、CI/CD 環境のクリーン再構築、リポジトリやログの監査といった即時対応が必須です。さらに、長期的には権限の最小化や ephemeral runner の利用、SBOM の生成とソフトウェアコンポーネント解析、そして Aikido Safe Chain のようなマルウェア検証ツールの活用など、セキュリティを日常の開発プロセスに組み込む工夫が欠かせません。

特に、CI/CD への統合は鍵となります。開発者が手動で確認するだけでは限界があるため、依存関係の取得やビルドのたびに自動でパッケージを検証し、IOC や脅威インテリジェンスに基づいてブロックする仕組みを導入することで、攻撃の拡大を未然に防げます。OSS に依存する開発体制を維持する以上、こうした仕組みは「特別な対策」ではなく「標準的な衛生管理」として定着させる必要があります。

Shai-Hulud は終息したインシデントではなく、今後の攻撃者の戦術を示す前兆と捉えるべきです。攻撃はますます自動化・巧妙化し、検出をすり抜けて広範囲に広がることが想定されます。したがって、本件を単なる一過性の脅威と見るのではなく、ソフトウェアサプライチェーン防御の基盤整備を加速させるきっかけとすることが重要です。OSS エコシステムと開発者コミュニティの健全性を守るためには、開発者一人ひとりがセキュリティ意識を高め、組織全体として持続的な監視と改善の仕組みを整備していくことが求められます。

参考文献

AI駆動型ランサムウェア「PromptLock」の正体 ― 研究プロトタイプが示す新たな脅威の可能性

2025年9月、セキュリティ業界に大きな波紋を広げる出来事が報じられました。スロバキアのセキュリティ企業ESETが、世界初とされるAI駆動型ランサムウェア「PromptLock」を発見したのです。従来のランサムウェアは、人間の開発者がコードを作成・改変して機能を追加してきましたが、PromptLockはその枠を超え、大規模言語モデル（LLM）が自律的に攻撃コードを生成する仕組みを備えていました。これにより、攻撃の効率性や回避能力が従来より大幅に高まる可能性が指摘されました。

当初は未知の脅威が出現したとして警戒が強まりましたが、その後の調査により、実態はニューヨーク大学（NYU）の研究者が作成した学術プロトタイプ「Ransomware 3.0」であることが明らかになりました。つまり、サイバー犯罪者による実際の攻撃ではなく、研究目的で作られた概念実証（PoC）が偶然発見された形です。しかし、AIによる自動化・動的生成がランサムウェアに組み込まれたという事実は、将来のセキュリティリスクを予見させる重要な出来事といえます。

本記事では、PromptLock発見の経緯、研究プロトタイプとの関係性、AI技術の具体的な活用方法、そしてセキュリティ分野における影響や課題について多角的に解説します。

PromptLock発見の経緯

ESETがPromptLockを最初に確認したのは、VirusTotalにアップロードされた未知のバイナリの解析からでした。VirusTotalは研究者や一般ユーザーがマルウェアのサンプルを共有・解析するために利用されるプラットフォームであり、ここに公開されることで多くのセキュリティベンダーが調査対象とします。ESETはこのサンプルを分析する過程で、従来のランサムウェアとは異なる挙動を持つ点に着目しました。

解析の結果、このマルウェアはGo言語で開発され、Windows・Linux・macOSといった複数のOS上で動作可能であることが判明しました。クロスプラットフォーム対応の設計は近年のマルウェアでも増えている傾向ですが、特に注目されたのは「内部に大規模言語モデルを呼び出すプロンプトが埋め込まれている」という点でした。通常のランサムウェアは固定化された暗号化ルーチンやコマンド群を実行しますが、PromptLockは実行時にLLMを通じてLuaスクリプトを動的生成し、その場で攻撃コードを組み立てていくという、従来にない特徴を備えていました。

生成されるスクリプトは、感染した環境内のファイルを列挙し、機密性の高いデータを選別し、さらに暗号化する一連の処理を自動的に行うものでした。暗号化アルゴリズムにはSPECK 128ビットが利用されていましたが、完全な破壊機能は未実装であり、概念実証の段階にとどまっていたことも確認されています。

また、ESETはこのマルウェアに「PromptLock」という名称を与え、「世界初のAI駆動型ランサムウェア」として発表しました。当初は、AIを利用した新種のマルウェアが野に放たれたと解釈され、多くのメディアや研究者が警戒を強めました。特に、マルウェアにAIが組み込まれることで、シグネチャ検知を容易に回避できる可能性や、毎回異なる挙動を取るため振る舞い分析を困難にするリスクが懸念されました。

しかし、後の調査によって、このサンプルは実際の攻撃キャンペーンの一部ではなく、研究者が学術目的で作成したプロトタイプであることが明らかになります。この経緯は、セキュリティ業界がAIの脅威を過大評価する可能性と同時に、AIが攻撃手法に応用されることでいかに大きなインパクトを与えうるかを示した象徴的な事例となりました。

研究プロトタイプとの関係

PromptLockの正体が明らかになったのは、ESETの発表から間もなくしてです。iTnewsの報道によれば、問題のバイナリはニューヨーク大学（NYU）タンドン工科大学の研究チームが開発した「Ransomware 3.0」と呼ばれる学術的プロトタイプにほかなりませんでした。これは、AIを活用してランサムウェアの攻撃ライフサイクル全体を自律的に実行できるかを検証する目的で作られたもので、研究者自身がVirusTotalにアップロードしていたことが後に確認されています。

Ransomware 3.0は、従来のマルウェア研究と大きく異なる点として、大規模言語モデル（LLM）を「攻撃の頭脳」として利用する設計思想を持っていました。研究チームは、システム探索、ファイルの優先度評価、暗号化、身代金要求といった工程を個別にプログラムするのではなく、プロンプトとしてLLMに与え、実行時に必要なコードを生成させるという新しい手法を試みました。これにより、固定化されたシグネチャやコードパターンに依存しない、動的に変化する攻撃を作り出すことが可能になります。

さらに研究では、Windows、Linux、Raspberry Piといった複数のプラットフォームで試験が行われ、AIが敏感なファイルを63〜96%の精度で識別できることが確認されました。これは単なる暗号化ツールとしてではなく、攻撃対象の「価値あるデータ」を自律的に選別する段階までAIが担えることを意味しています。

コスト面でも注目すべき点がありました。研究チームによると、1回の攻撃実行に必要なLLM利用量は約23,000トークンであり、クラウドAPIを利用した場合でも0.70米ドル程度に収まるとされています。オープンソースモデルを活用すれば、このコストすら不要です。つまり、従来のマルウェア開発者が時間と労力をかけて調整してきたプロセスを、誰でも低コストで再現可能にしてしまうポテンシャルがあるのです。

ただし、研究チームは倫理的配慮を徹底しており、このプロトタイプは完全に学術目的でのみ開発されたものです。実際の攻撃に利用される意図はなく、論文や発表を通じて「AIがサイバー攻撃に悪用された場合のリスク」を社会に提示することが狙いでした。今回のPromptLock騒動は、ESETがPoCを未知の脅威として誤認したことで注目を集めましたが、同時に研究成果が現実の脅威と紙一重であることを世に知らしめたとも言えます。

技術的特徴

PromptLock（研究プロトタイプであるRansomware 3.0）が持つ最大の特徴は、ランサムウェアの主要機能をLLMによって動的に生成・実行する仕組みにあります。従来のランサムウェアは固定化されたコードや暗号化アルゴリズムを持ち、シグネチャベースの検知や挙動パターンによる対策が可能でした。しかしPromptLockは、実行のたびに異なるコードを生成するため、既存の防御モデルにとって検出が難しくなります。

1. AIによる動的スクリプト生成

内部に埋め込まれたプロンプトが大規模言語モデル（gpt-oss:20bなど）へ渡され、Luaスクリプトがオンデマンドで生成されます。このスクリプトには、ファイル探索、フィルタリング、暗号化処理といった攻撃のロジックが含まれ、同じバイナリであっても実行ごとに異なる挙動を取る可能性があります。これにより、セキュリティ製品が行う静的解析やヒューリスティック検知の回避が容易になります。

2. クロスプラットフォーム対応

本体はGo言語で記述されており、Windows・Linux・macOSに加え、Raspberry Piのような軽量デバイス上でも動作することが確認されています。IoTデバイスや組み込みシステムへの拡散も現実的に可能となり、攻撃対象の範囲が従来より大幅に拡大する危険性を示しています。

3. 暗号化アルゴリズムの採用

ファイル暗号化にはSPECK 128ビットブロック暗号が利用されていました。これはNSAによって設計された軽量暗号で、特にIoT環境など計算資源が限られるデバイスに適しています。研究プロトタイプでは完全な破壊機能は実装されていませんが、暗号化の仕組みそのものは十分に実用的なものでした。

4. 自動化された攻撃フェーズ

Ransomware 3.0は、ランサムウェアが行う主要フェーズを一通りカバーしています。

  • システム探索：OSやストレージ構造を認識し、標的となるファイルを特定。
  • ファイル選別：LLMの指示により「価値のあるデータ」を優先的に選択。研究では63〜96%の精度で重要ファイルを抽出。
  • 暗号化：対象ファイルをSPECKアルゴリズムで暗号化。
  • 身代金要求：ユーザーに表示する要求文もLLMによって生成可能で、文章の多様性が高まり、単純なキーワード検知を回避しやすい。

5. 実行コストと効率性

研究者の試算によれば、1回の攻撃実行には約23,000トークンが必要で、クラウドAPIを利用した場合は0.70米ドル程度のコストとされています。これはサイバー犯罪の観点から見れば極めて低コストであり、さらにオープンソースモデルを利用すればゼロコストで再現できることから、攻撃の敷居を大幅に下げる可能性があります。

6. 多様な回避能力

生成されるコードは常に変化し、固定化されたシグネチャでは検出できません。また、動的生成の性質上、セキュリティ研究者がサンプルを収集・分析する難易度が飛躍的に高まるという課題もあります。さらに、文章生成能力を利用することで、ソーシャルエンジニアリング要素（説得力のある脅迫文やカスタマイズされた身代金メッセージ）を柔軟に作成できる点も注目されます。

セキュリティへの影響と課題

PromptLock（Ransomware 3.0）が示した最大の教訓は、AIが攻撃側の手に渡ったとき、従来のマルウェア検知・防御の前提が揺らぐという点です。従来のランサムウェアは、コード署名やシグネチャパターンを基にした検知が有効でしたが、AIによる動的生成はこれを回避する仕組みを本質的に内包しています。結果として、防御側は「どのように変化するかわからない攻撃」と対峙せざるを得ません。

1. 防御モデルの陳腐化

セキュリティ製品の多くは既知のコードや振る舞いに依存して検知を行っています。しかし、PromptLockのように実行のたびに異なるスクリプトを生成するマルウェアは、検出ルールをすり抜けやすく、ゼロデイ的な振る舞いを恒常的に行う存在となります。これにより、シグネチャベースのアンチウイルスやルールベースのIDS/IPSの有効性は大幅に低下する恐れがあります。

2. 攻撃者のコスト削減と自動化

研究では1回の攻撃実行コストが0.70米ドル程度と試算されています。従来、ランサムウェア開発には専門知識や開発時間が必要でしたが、AIを利用すれば低コストかつ短時間で攻撃ロジックを作成できます。さらに、LLMのプロンプトを工夫することで「ターゲットごとに異なる攻撃」を自動生成でき、マルウェア作成のハードルは著しく低下します。結果として、これまで攻撃に関与していなかった層まで参入する可能性が高まります。

3. 高度な標的化

AIは単なるコード生成だけでなく、環境やファイル内容を理解した上で攻撃を調整することが可能です。研究では、LLMが重要ファイルを63〜96%の精度で識別できると報告されています。これは「無差別的に暗号化する従来型」と異なり、価値あるデータだけを狙い撃ちする精密攻撃の可能性を意味します。結果として、被害者は復旧困難なダメージを受けるリスクが高まります。

4. 説得力のある身代金要求

自然言語生成能力を活用すれば、攻撃者は被害者ごとに異なるカスタマイズされた脅迫文を作成できます。従来の定型的な「支払わなければデータを消去する」という文言ではなく、企業名・担当者名・業務内容を織り込んだリアルなメッセージを自動生成することで、心理的圧力を増幅させることができます。これはソーシャルエンジニアリングとの融合を意味し、防御はさらに難しくなります。

5. 防御側への課題

こうした背景から、防御側には新しい対応策が求められます。

  • AI対AIの対抗：AI生成コードを検知するために、防御側もAIを活用した行動分析や異常検知が不可欠になる。
  • ゼロトラスト強化：感染を前提としたネットワーク設計、権限の最小化、セグメンテーションの徹底が必須。
  • バックアップと復旧体制：暗号化を回避できないケースを想定し、オフラインバックアップや迅速な復旧計画を備える。
  • 倫理と規制の問題：AIを悪用した攻撃が現実化する中で、モデル提供者・研究者・規制当局がどのように責任分担を行うかも大きな課題となる。

6. 今後の展望

PromptLockは研究プロトタイプに過ぎませんが、その存在は「AI時代のサイバー攻撃」の可能性を明確に示しました。今後は、犯罪組織がこの技術を取り込み、攻撃の効率化や大規模化を進めることが懸念されます。セキュリティ業界は、AIによる脅威を前提とした新たな脅威モデルの構築と、それを支える防御技術の進化を余儀なくされるでしょう。

おわりに

PromptLockは最初こそ「世界初のAI駆動型ランサムウェア」として大きな衝撃を与えましたが、その正体はNYUの研究者が開発した学術的な概念実証にすぎませんでした。しかし、この誤認をきっかけに、セキュリティ業界全体がAIとマルウェアの交差点に強い関心を寄せることとなりました。実際に攻撃に利用されたわけではないものの、AIが従来の防御手法を無力化しうる可能性を示した事実は極めて重大です。

従来のランサムウェア対策は、既知のシグネチャや典型的な挙動を検知することを前提にしてきました。しかし、AIが介在することで「常に異なる攻撃コードが生成される」「標的ごとに最適化された攻撃が行われる」といった新しい脅威モデルが現実味を帯びています。これは、防御の在り方そのものを再考させる大きな転換点であり、単なるマルウェア対策ではなく、AIを含む攻撃シナリオを包括的に想定したセキュリティ戦略が求められる時代に入ったことを意味します。

また、この出来事は倫理的な側面についても重要な示唆を与えました。研究としてのPoCであっても、公開の仕方や取り扱い次第では「現実の脅威」として認識され、社会的混乱を招く可能性があります。AIを使った攻撃研究と、その成果の公開方法に関する国際的なルール作りが今後さらに必要になるでしょう。

PromptLockが「実験作」だったとしても、攻撃者が同様の技術を応用する日は遠くないかもしれません。だからこそ、防御側は一歩先を見据え、AI時代のセキュリティ基盤を構築する必要があります。本記事で取り上げた事例は、その警鐘として記憶すべきものであり、今後のサイバー防御の議論において重要な参照点となるでしょう。

参考文献

モバイルバージョンを終了