AI Agent による継続的な攻撃：マルウェアの試行に失敗しても新たな悪意のツールを生成する

AI Agents Don’t Stop When Malware Fails, They Write Another Tool and Keep Attacking

2026/08/14 CyberSecurityNews — AI エージェントがサイバー攻撃の形を変えつつある。これにより、固定された単一のマルウェアに依存するのではなく、アプローチを試行し、失敗を確認すると代替ツールを作成して、同じ目標に向けた活動を継続していく。最近のインシデントが示しているのは、この攻撃形態が理論上のリスクに留まらないという点であり、高度な AI モデルに関連付けられたエージェントが外部システムへ到達し、ソーシャル・エンジニアリングを試みる。あるケースでは、悪意のある Python パッケージが PyPI に配置された。

SentinelLABS が指摘したのは、重要な問題が単一のエクスプロイトや特殊なマルウェア・サンプルにあるのではなく、この問題の本質が持続性にあるという点である。エージェントは試行に失敗した後も作業を継続し、ツールを再構築し、経路が遮断されると別の戦術へ切り替えることで、単一の侵害環境を超えて影響を広げていく。

セキュリティ・チームは、ファイル／コマンド／ネットワーク接続の追跡には慣れているが、エージェント主導の作戦で生成されるのは、単一の標的へ向けた短期間で使い捨てられるツールであり、アナリストが検知ルールを構築する前に破棄されている。SentinelLABS が共有したレポートでは、アクセスを許可されていないシステムを AI エージェントが侵害した 4 件の公開済みインシデントが検証されている。

マルウェアの試行に失敗しても AI エージェントは停止しない

2026年7月に発生した有名なインシデントでは、GPT-5.6 Sol と社内の研究用モデルを利用するエージェントが、自己ホスト型 Artifactory インスタンスに存在する未知の欠陥を発見し、この欠陥を突くために共有メッセージ・ボードを作成して、別々のエージェント同士で情報を交換し、活動を連携できるようにした。さらに、この通信経路が遮断されると、エージェントは Artifactory のリモート・キャッシュを介して通信経路を再構築したと報告されている。

その後、この活動は評価用サンドボックスを脱出して Hugging Face の本番インフラストラクチャへ到達し、約 2 日半にわたり活動を継続した。このインシデントの事後分析では、約 17,600 件のアクションが特定されたが、その大半は失敗しており、この数が示すのは、すべてのステップの成功を必要としない攻撃が成立していたことである。

複数の一般的な弱点が悪用可能な経路を形成するまで、選択肢を試し続ける能力が用いられていた。この挙動は、持続性という概念の意味を変えるものであり、多くの場合、従来のマルウェアにおける永続化とは、再起動後も生き残ることや、スケジュール済みタスクを通じてアクセスを維持することを意味する。

一般的なマルウェアの永続化メカニズムで説明されるように、防御側が検出するのはホスト上に残る安定した変更であるが、AI エージェントは単一の固定ツールに依存することなく持続的に活動できる。

エージェントは、新しいスクリプトの作成や公開 Web サービスの使用だけではなく、検知によって経路が遮断された後に別のシステムへ移行できるため、1 つのアーティファクトを遮断しても、新たな試行が継続される可能性がある。その結果、より高速で柔軟な攻撃サイクルが生じ、オペレーターがエラーを調査して攻撃用コードに対処している間に、失敗を新たな情報として扱うエージェントは次の作業へと移行していく。

防御側は挙動を追跡する必要がある

その他のインシデントが示すのは、この柔軟性がサプライチェーン攻撃やソーシャル・エンジニアリング攻撃へ拡張される可能性である。インターネットに公開されたテスト環境では、Anthropic に関連するモデルが、実在する 3 つの組織へ到達して人々に接触した上で、悪意のある Python パッケージをアップロードしたと報告されており、そのパッケージは 15 台のシステムでダウンロードされ、実行された。

これは、悪意のあるパッケージが開発者の信頼や自動化されたソフトウェア・ビルドを悪用することで生じるリスクであり、最近の PyPI サプライチェーン攻撃でも確認されているシナリオを反映するものである。従来の攻撃と異なるのは、技術的な手法が失敗した後に、成功する可能性が最も高い経路をエージェントが判断して選択する可能性がある点である。

英国 AI Security Institute が説明するのは、実在するオープンソース・プロジェクトの選定、メンテナーの調査、偽の身元情報の作成、有害なコードの提出などを、エージェントが試みた状況である。人間によるレビューにより、最も深刻な活動は阻止されたが、このケースが示しているのは、AI ツールが開発者を支援する場合であっても、コード・レビューには慎重さが必要だという点である。

組織に求められるのは、単一の悪意のあるファイルの特定よりも、通常とは異なる一連の活動の検知を重視することであり、チームにとって必要なことは、エージェントが使用した身元情報／付与されていた権限などの確認であり、それにより、接続先のシステム、アクセス権などを迅速に取り消すための可視性を確保することである。

SentinelLABS のレポートが推奨するのは、インシデントへ発展する可能性がある技術的負債を優先的に解消すること、迅速に修正できないシステムを隔離すること、自動テストやホット・パッチによって容易にアップデートできるようにすることである。公開された認証情報や安全性の低いツールへのアクセスにより、日常的な自動化が深刻なリスクへ変わる可能性があるため、AI コーディング・エージェントのセキュリティ上の欠陥への対応を担うチームにとって、このような対策が重要となる。

エージェントの活動ログに十分な詳細を取り込むことで、インシデント発生後に活動や意思決定の経緯を再構築できるようにする必要がある。セキュリティ・チームに求められるのは、権限の限定や機密性の高いアクションに対する承認の必須化などであり、割り当てられた役割を超えてエージェントが活動していないか、継続的にテストを行うことである。

JFrog Artifactory や PyPI などを舞台に、自動化されたモデルが試行錯誤を繰り返すことで脅威をもたらす事象が注目を集めています。防御側が検知したシグネチャを遮断しても、新たなスクリプトの自動生成／別経路での再試行／サプライチェーンへの汚染といった手法で目標が達成されます。この問題は、適応型ツールが短時間で展開され、検知ルールが回避されるという状況を生み出します。これに対しては、単一ファイルのハッシュ照合によるブロックから、挙動全体のリアルタイム可視化／アイデンティティや権限の即座の取り消し／開発パイプラインでの厳密な承認フローの導入へと、対策を移行することが求められます。