AIが2026年の脅威の様相を根本から変えた4つの理由

Image

シニアサイバーセキュリティ・ストラテジスト

Image

脅威の様相は長年、見慣れた形をしていました。熟練した人間がマルウェアを書き、既知の脆弱性をスキャンし、盗んだデータや企業環境へのアクセス権をダークウェブのフォーラムで売買する、というものです。このタイプの脅威は今も存在しています。ただ、もはや防御側が対処すべき唯一の形ではなくなりました。

筆者はこの4年間、Sysdig脅威リサーチチーム(TRT)で活動してきました。その間、攻撃はますます高速化してきました。脆弱性は勧告公開から数時間で悪用され、攻撃は数分で完結するようになっています。しかし最近、私たちは構造的にまったく異なる何かを記録し続けています。攻撃者がAIを「利用する」だけでなく、AI自体がリアルタイムで計画・実行・適応を行う攻撃を目にするようになったのです。

過去6か月の間に、エージェント型AIが脅威の様相を根本から変えつつあることを示す4つの明確なテーマが浮かび上がってきました。これらのテーマはいずれもSysdig TRTが「実際の攻撃」で観測したものであり、予測ではなく、調査と現場での証拠の積み重ねから導かれたものです。

1. エージェント型脅威アクターの登場

Sysdig TRTが最近観測した最も重大な変化は、AIが攻撃を最初から最後まで一貫して実行するケースが増えていることです。

私たちはエージェント型脅威アクター(ATA)を、攻撃能力が人間の手作業ではなくAIエージェントによって発揮される攻撃者として定義しています。手作りであれAI開発であれ、ツールキットを使うのはAIエージェント自身です。つまり、AIエージェントは環境からの出力を読み取り、次に何をすべきかをリアルタイムで判断し、各ステップで人間が意思決定を挟むことなく攻撃を継続的に実行します。

ATAと、AIが開発したツールキットを使う人間、あるいは環境内を移動しながらLLMにプロンプトを入力する人間との違いは「自律性」にあります。人間が介在するモデルでは、人間の思考が入る部分に攻撃タイムライン上の明確な断絶が生まれ、エージェントの攻撃スクリプトの変化からプロンプトの推移がうかがえます。一方、ATAは立ち止まりません。

アクセス獲得からデータ窃取まで、わずか4ステップ

2026年5月、Sysdig TRTはあるATAが、marimoの脆弱性(CVE-2026-39987)を突破口とする初期アクセスから、社内データベースからのデータ窃取に至るまでを1時間足らず、わずか4ステップの侵入拡大で完遂する様子を目撃しました。人間の誘導なしに、このエージェントは認証情報を抽出し、それを使ってSSH秘密鍵を取得し、さらにそれを用いて下流のサーバーに対してSSHセッションを確立していきました。

コマンドの流れにはコメントが紛れ込んでおり、機械が読み取ることを前提に構築されたコマンド群からは、この攻撃がLLMによって、LLMのために作られたものであることが一目瞭然でした。Sysdig TRTがこの攻撃を分析した結果、ステップ間に躊躇がなく、遅延もなく、人間の攻撃者であれば決してスクリプトに書き込まないような痕跡がペイロード内に残されていることが判明しました。

コンテナエスケープとKubernetesシークレット

別の作戦では、Sysdig TRTはあるATAがコンテナからエスケープし、Kubernetesのシークレットをダンプする様子を捕捉しました。これは、自律型攻撃がアプリケーション層を越えてオーケストレーション層(ワークロードのスケジューリング、シークレット、クラスタ構成を自律的に制御する層)にまで及んだ初めての事例です。

コンテナエスケープからKubernetesシークレットの窃取に至るこの種の攻撃連鎖は、実行に高度な専門知識を要するため、人間の攻撃者が仕掛けるケースはあまり見られません。今回の事例は、事前の知識がまったくなくても、攻撃者がエージェントに一連の攻撃を連結させることができることを示しています。

エージェント型ランサムウェア

そして登場したのがJADEPUFFERです。これはエージェント型ランサムウェアとして初めて文書化された事例であり、恐喝作戦全体が最初から最後までAIエージェントによって主導されました。このエージェントはインターネットに公開されたLangflowインスタンスに1年前から存在していた脆弱性を発見し、環境を列挙していきました。特にLLMおよびクラウドプロバイダーに関連する高価値な鍵や認証情報、暗号資産ウォレット、データベースや設定ファイルを狙って探索し、収集していったのです。人間はAIに標的を指し示しただけで、あとはすべてAIが自律的に処理しました。

エージェントは目的の標的、すなわちMySQLデータベースとAlibaba Nacos設定サービスを稼働させている本番サーバーにたどり着くと、1,300件を超える設定エントリを暗号化し、LLMが生成した身代金要求文、ビットコイン支払いアドレス、Proton Mailの連絡先を記載した恐喝用テーブルを作成しました。この攻撃が意味するところは深刻です。かつてランサムウェアには専門的なスキルが必要でしたが、今やランサムウェア作戦を実行できるかどうかは、AIエージェントを稼働させるのにかかるコストだけで決まるようになっているのです。

このランサムウェア攻撃の最中、JADEPUFFERは最初のログイン試行に失敗しました。しかしエージェントは原因を診断し、わずか31秒、15行のコードで修正済みのペイロードを再送しました。

ペイロードには自然言語による推論やステップごとの注釈も含まれていました。この注釈は重要な意味を持ちます。ペイロードにアクセスできれば、LLMが生成したコードと人間が書いた攻撃コードを見分ける最も分かりやすい手がかりの一つになるからです。他のATAの攻撃にもこうした痕跡は残されていましたが、こうしたAI生成のスクリプトの痕跡は、実行時に検知可能な振る舞いのシグナルなのです。

2. AIインフラそのものが標的に

JADEPUFFERは、Sysdig TRTが複数のキャンペーンにわたって追跡してきたパターンの一例に過ぎません。もう一つ浮かび上がってきた潮流は、AIインフラが攻撃者にとって意図的な優先標的になっているということです。その「理由」は、そのインフラが往々にして何を保持しているかにあります。

認証情報の宝庫

AIインフラでは、本来あるべきでない場所に認証情報が保管されているケースが多く見られ、機密データへの接続を伴うことも多く、デフォルトパスワードが変更されないまま放置されていることも珍しくなく、時にはアクセス経路がインターネットに露出したままになっています。つまりAIインフラは、組織がAIアプリケーション構築のために導入しているツール群を明らかにしてしまうという点で、まさに宝の山なのです。

Langflow、LMDeploy、Marimo、LiteLLM、PraisonAIといった類似のフレームワークは、現代のAI開発を支える結合組織のような存在です。これらはモデル呼び出しをオーケストレーションし、認証情報の仲介を行い、クラウドAPIに触れ、本番データのすぐそばに位置しています。しかもこれらは、組織がデータベースやAPIの周辺で長年かけて築いてきたような堅牢化が施されないまま、インターネットに公開されたインフラ上に急ピッチで展開されているのが実情です。一つでも悪用されれば、OpenAIのAPIキー、Anthropicの認証情報、AWSアクセスキー、クラウドストレージトークン、データベース接続文字列まで、同じ環境からすべてを持ち去られかねません。もはや単なる足がかりではなく、攻撃者もそれを承知しています。

JADEPUFFERもこれを裏付けています。Langflowインスタンスが侵入口となり、エージェントは明確に高価値な認証情報や鍵を狙って探索しました。その後標的となった本番のMySQLサーバーとNacos設定サービスにも、認証情報とデータが満載でした。

モデルへのアクセス権の窃取

Sysdig TRTは2024年5月に「LLMjacking」という用語を作り、攻撃者が盗んだクラウド認証情報を使ってホスト型モデルAPIにアクセスし、AI計算資源を吸い上げる手口を表現しました。当時の試算では、LLMjackingの被害者は1日あたり最大46,000ドルもの請求を受けかねないとされていました。2025年までに、この手口はリバースプロキシインフラの販売を通じて数十億トークン分もの盗難コンピュートを仲介する、産業化されたブラックマーケットへと成熟しました。

組織が自前でモデルをローカル稼働させるようになるにつれ、攻撃対象領域は再び姿を変えてきました。直近の事例では、攻撃者が被害者の認証なしで公開されていたOllamaサーバーを推論エンジンとして利用し、自律型攻撃ツールを構築しました。この点については、今年初めの時点で130か国以上において推定175,000台のOllamaインスタンスが公開状態にあると報告されています。潜在的な攻撃対象領域の広さには驚かされます。

自組織のAIスタックが資産インベントリに含まれていなければ、それは死角だと言っても過言ではありません。自社の環境にどのようなAIインフラが、どこに存在しているかを把握できれば、こうした脅威が組織に到達するリスクを大幅に減らせます。第一歩は、AI部品表(AIBOM)を用いてインフラを特定することです。そこから先のリスク低減は、ID管理、実行時の検知、外部公開範囲の縮小といった基本的なセキュリティ衛生管理の話になります。

3. 時間的猶予は消滅した

大半の脆弱性管理プログラムには、いまだに「時間的余裕がある」という前提が組み込まれています。開示後の時間、評価と優先順位付けの時間、パッチ適用を計画する時間、といった具合です。しかし、この前提はもはや成り立ちません。AIの活用があらゆる場面で当たり前になった今、アプリケーションは急速に構築され、それ以上の速さで破られています。時間は、これまで以上に重要な要素になっています。

脆弱性の公開が号砲となる

Sysdig TRTはここ数か月、悪用に至るまでのタイムラインを記録し続けてきました。パターンは一貫しており、その数字は驚くべきものです。

  • PraisonAI認証バイパス: マルチエージェント・オーケストレーションプラットフォームが4時間足らずで悪用
  • Marimo RCE: リアクティブPythonノートブックプラットフォームが10時間足らずで悪用
  • LMDeploy SSRF: LLM推論エンジンが12時間で悪用
  • Langflow RCE: エージェントおよびRAGパイプライン構築用ビジュアルフレームワークが20時間で侵害
  • LiteLLM SQLインジェクション: LLMゲートウェイが36時間で悪用

上記の数字は、CVE付与後の悪用タイムラインですらありません。これらの攻撃の多くは、CVEが割り当てられるよりも前、GitHub Security Advisory(GHSA)の段階から始まっていました。今日では、脆弱性の開示そのものが号砲となります。開示情報が概念実証(PoC)の説明を含んでいるため、攻撃者はLLMを使ってものの数秒でエクスプロイトを組み立てられるからです。

侵入されれば、時間はさらに加速する

攻撃者がクラウド環境に侵入した後には、また別の時間軸の課題が待ち構えています。Sysdig TRTは2023年、クラウド攻撃が平均して10分以内、しかも最初から最後まで一貫して展開されるという結論に至り、クラウドの検知・対応に関する555ベンチマークを最初に確立しました。このSysdig 555ベンチマークは「検知に5秒、トリアージに5分、対応に5分」を意味します。つまり、防御側がクラウドの脅威を阻止するために使える時間はそれだけしかないのです。

それ以来、AI主導型やAI支援型の攻撃においても、この数字は当てはまり続けています。例えば前述のmarimoの脆弱性では、攻撃者が被害者の環境から認証情報を収集するのにわずか3分しかかかりませんでした。別のAI支援型侵入事例では、攻撃者が管理者権限を取得するまでに8分しかかからず、その後リソースデータを窃取し、LLMjackingキャンペーンを展開しました。

555ベンチマークは、セキュリティチームが現代の攻撃に対応できるだけの最低限の運用テンポを設定するために策定されました。この時間軸は、組織にとって今まで以上に重要な意味を持つようになっており、エージェント型の検知・対応能力を運用しているチームこそが、攻撃に先んじるために必要な速度で動けているのです。

4. 攻撃者によるモデルの操作

攻撃者は、AIモデルに自分たちの「仕事」を代行させる方法も学び取っています。意外に思われないかもしれませんが、セキュリティ業界全体としてもこうした進化を予測し、各モデルに安全ガードレールを実装してきました。それでも、攻撃者はあきらめません。

モデルのジェイルブレイク

2026年6月、Sysdig TRTは複数の脅威アクターが「Capture The Flag(CTF)」を装う形で悪意あるプロンプトを包み込み、LLMの安全フィルタを回避しようとする様子を観測しました。正規のセキュリティ演習であるかのように要求を装うことで、攻撃者は本来なら拒否されるはずの、実際に動作するCVEエクスプロイトの生成をモデルに承諾させていたのです。

このCTF型ジェイルブレイク手法はLLMのセキュリティ上の失敗事例ではありますが、モデルが出力するエクスプロイトスクリプトには明確な鑑識的痕跡が残ります。攻撃者がプロンプト内で要求したエクスプロイトのCVE番号が、そのままコマンドヘッダー、パスワード、IAMログのエントリに紛れ込んでしまうのです。こうした痕跡は、防御側が探すべき新たなシンプルな検知シグナルとなります。

では、脅威アクターがこうした痕跡を偽装し、防御側を欺くために利用する方法を発見するまで、あとどれくらいかかるでしょうか。ここでもまた、時間との闘いが続いています。

ガードレール除去済みモデル

一方で、ガードレールが一切ないモデルを操作できるのなら、わざわざプロンプト操作に手を煩わせる必要があるでしょうか。上でも触れたSysdig TRTの直近のLLMjacking調査が重要な理由は、攻撃者が被害者のLLMへのアクセス権を盗んで自律型ツールを構築したという点だけではありません。使われていたLLMは「abliterated(除去)」処理が施されたLlama-3.3-70Bモデル、つまり安全ガードレールが取り除かれたバージョンのモデルだったのです。このモデルには制限が一切なく、運用者側にコストも一切かかりませんでした。

これら2つの手口を合わせて考えると、攻撃者がAIモデルを、入手可能性や利便性に応じて悪用・操作・窃取すべき「資源」として認識していることが分かります。自前でホストするモデルのエンドポイントはすべて攻撃対象領域となり、AIのAPIキーはすべて標的となり、モデル自体も、そこにアクセスできる者にとっては何らかの形で攻撃連鎖の一部品になり得るのです。

防御側にとっての意味

これら4つのテーマはそれぞれ独立していますが、組み合わさることで複合的な脅威となり得ます。

想像してみてください。エージェント型脅威アクターが、AIパイプラインツールのCVE付与前の欠陥を開示からわずか数時間で悪用し、堅牢化されていなかった認証情報を盗み出し、ガードレールを剥ぎ取られたモデルを動かす盗難コンピュート資源上で作戦全体を実行する——。このキャンペーン全体が1時間足らず、下手をすれば数分で完結してしまうかもしれません。

これは単なる仮定の連鎖ではありません。実際、これはJADEPUFFERそのものの描写だと言ってもよく、そこにSysdig TRTがこれまで記録してきたLLMjackingやモデル操作の手口が加わったものだと考えられます。JADEPUFFERのような攻撃、あるいは類似のATAで使われたLLMが、ガードレール除去済みであったり、盗難コンピュートで稼働していたりする可能性は十分にあり得ることです。

こうした攻撃は従来とは異なりますが、検知は可能です。少なくとも現時点では、LLMが生成したコードは自らの動作を語り、推論に注釈を付け、人間の運用者ならわざわざ行わないような形で構造化された出力を生成します。

JADEPUFFERのペイロードには、注入されたスクリプト内に自然言語によるステップごとの根拠説明が含まれていました。VAPTフレームワークのオーケストレータープロンプトには、ツール自身のアーキテクチャに関する詳細なドキュメントが記載されていました。これらはブロックすべきシグネチャではなく、ATAのペイロードを確認できるのであれば、探すべき行動パターンなのです。つまりモデルは攻撃対象領域の一部になり得る一方で、インテリジェンスの情報源にもなり得るということです。既知のシグネチャに合わせて調整された検知手法では、実行のたびに新たなペイロードを書き出すエージェントを見逃してしまいます。

同様に、パッチサイクルを前提とした脆弱性管理では、開示から数時間以内に始まる悪用を見逃してしまいます。そして、AIインフラのあらゆる隙間や信頼境界を網羅していないセキュリティツールでは、攻撃連鎖の残りを可能にしている認証情報の保管場所を見逃してしまいます。

ワークロードとAIインフラ全体にわたって、実際に何が実行されているのかをリアルタイムで可視化する実行時可視性こそが、その基盤となります。これこそが、こうした攻撃が求める速度と粒度で機能する制御手段なのです。

本記事で言及した各調査結果の詳しい技術リサーチ内容や、最新の調査結果をフォローするには、sysdig.com/threat-researchをご覧ください。

翻訳元: https://webflow.sysdig.com/blog/four-ways-ai-has-fundamentally-changed-the-threat-landscape-in-2026

ソース: webflow.sysdig.com