【ITニュース解説】October 2026 Security Review: Compromised "Legitimate Privileges" and the Boundaries of Distribution and AI Execution

2026年10月に報告されたセキュリティインシデントの分析は、システムを保護するために私たちがこれまで持っていた常識を見直す必要があることを示唆している。攻撃者がどのようにシステムへ侵入したかという初期の段階だけでなく、侵入後に彼らが正規の権限や、ソフトウェアの配布経路、さらにはAIによる自動化といった、一見すると安全に思える手段をどのように悪用し、被害を拡大させていったのかが、今回の分析の中心となっている。

防御側の視点から見ると、単に認証が成功したからといって、それが正当な利用であると決めつけてはならない。また、ソフトウェアが特定の名前を持っていたり、正式な署名が施されていたりするだけで、完全に安全であると判断するのも危険だ。さらに、ニュースなどで「AIが関与した」と聞いただけでは、攻撃が実際にどの程度自律的で成功したのか、あるいはAIが防御にどれほど有効だったのかをすぐに判断できるわけではない。これらの点を深く理解することが、今後のセキュリティ対策の鍵となる。

まず、境界デバイスと認証の段階において、初期のアクセス成功と、その後のシステム設定の変更、秘密の鍵の抽出、トークンの不正利用といった行為を明確に区別する必要がある。例えば、CiscoのSD-WAN製品における認証バイパスの脆弱性（CVE-2026-76504）は、不正なアクセスを許すものだった。一方で、別のCisco SD-WANの脆弱性（CVE-2026-20127）を悪用した「KeyDrift」と呼ばれるマルウェアは、管理プロセス内に埋め込まれ、IPsecキーなどの重要なデータを抽出する能力を持っていた。これらの事例は、入り口の脆弱性と、侵入後に実際に何ができたかという事後的な機能が異なることを示している。

また、認証やトークンに関する信頼の境界が破られた事例は多岐にわたる。Microsoft 365を狙ったフィッシング詐欺（TA419）では、標的が偽のOneDriveサイトに誘導され、パスワードや多要素認証（MFA）のコードが中継されてセッションクッキーが奪われた。Docker Hubでは、アカウントが組織アカウントに変換される際に、攻撃者自身の個人アクセストークン（PAT）が、標的ユーザーの権限で動作するように再割り当てされる可能性があった（CVE-2026-105445）。SAP Cloud SDK for Pythonでは、マルチテナント設定の不備により、OAuth2トークン要求のクライアントIDとシークレットが攻撃者管理下のサーバーに送信される脆弱性（CVE-2026-89111）が見つかった。これらの事例からわかるように、単にMFAを導入するだけでは万能な対策にはならない。フィッシングに強い認証方式の採用、権限移行時の厳格な承認チェック、そして認証情報の送信先を制限するなどの、それぞれの境界に合わせたきめ細やかな対策が必要とされる。

次に、ソフトウェアサプライチェーンの脅威について見てみよう。ソフトウェアが正規の配布チャネルを通じて提供されていても、そのコードが実行される瞬間に信頼が崩れる可能性がある。これは、近年多発しているサプライチェーン攻撃の典型的なパターンだ。例えば、「LiteLLM 1.107.0」というPythonライブラリでは、公式のリリースプロセスを経たPyPIパッケージやDockerイメージに悪意のあるコードが混入していた。これは、公開リポジトリに露出していたマスターキーが不正利用された結果であり、Pythonの起動フックに埋め込まれたコードが、明示的なインポートなしに実行される可能性があった。また、AI支援コーディングツール「Cursor」のマーケットプレイスでは、悪意を持って改変されたClaudeのコード拡張機能が配布され、SSHキーの追加や持続性の確立を試みるコードが含まれていた。さらに、支払い処理画面のスクリプトが悪用され、クレジットカード情報が抜き取られる「Magecart」スタイルの攻撃も確認された。Polymarketという予測市場サイトでは、外部の監視スクリプトが改ざんされ、ユーザーの有効なWebセッションが不正に利用されて資金が移動させられた。これらの事例は、「サプライチェーン攻撃」という一括りの中にも、Pythonの起動フック、エディタの拡張機能、WebサイトのJavaScript、有効なWebセッションなど、コードが実行される境界が非常に多様であることを示している。防御側は、配布されたソフトウェアのハッシュ値だけでなく、いつ、どこで、どのように取得され、更新され、ロードされたのか、その環境で利用可能な秘密情報やセッション権限は何か、そしてその後の通信や活動履歴までを詳細に調査する必要がある。ある研究では、25種類のパッケージマネージャーのうち、Goとvcpkgのわずか2つだけが、デフォルトでダウンロードされる全てのファイルの完全性を検証しているという結果も出ている。ロックファイルがあるだけでは改ざんが検出・停止されるとは限らず、その検証メカニズム自体を個別に確認する必要がある。

最後に、AIがセキュリティに関わる際の誤解についてだ。AIの「関与」、その「成功度」、そして「防御能力」を同一視してはならない。これらを混同すると、現実とは異なる結論を導き出してしまう可能性がある。例えば、Zammadというサポートプラットフォームで発生した実際の侵害事例では、AIエージェントが攻撃の進行に関与したと評価されたが、実際にどのようなモデルが使われ、どんな権限が付与され、どのように人間の指示が与えられたのかは不明だった。一方で、Anthropic社の研究で発表された「自己増殖能力を持つAI」は、隔離された仮想環境での実験であり、実際のネットワークで広がるワームではない。この実験では、特定のAIが全てのノードで自律的に推論と自己複製を行ったわけではなく、異なるAIモデルが連携して動作し、評価システムによる厳密な検証を経て次のエージェントが起動される仕組みだった。さらに、Ciscoが発表した「Project Quarry」は、AIエージェントの多段階攻撃を検出するための新しい技術だが、まだ開発中のアルファ版であり、実際の環境での検出精度や有効性に関する具体的なベンチマークは公開されていない。これらの三つの事例は、それぞれ「実際に発生した侵害の報告」、「隔離された実験環境での能力検証」、そして「検出エンジンの公開」という、異なる種類の証拠と目的を持っている。そのため、これらを同じ尺度で並べて「AI攻撃の成功率」や「防御の有効性」を議論することはできないのである。

これらの分析がシステムエンジニアにとって示唆することは、新しい技術や脅威の名前が登場するたびに個々のアラートを増やすのではなく、**「いつ、どのような権限が与えられ、その権限がどのような経路で使われたのか」**を徹底的に監視することに優先順位を置くべきだということである。境界デバイスのAPI操作から、内部の認証や管理プロセス、サービスアカウントのトークン利用、ソフトウェアの取得からその後の起動フックやWebセッションの操作に至るまで、サービスを横断した証拠を連携させて監視する必要がある。

また、単にパッチを適用した、悪意のあるソフトウェアを削除した、MFAを設定したといったことだけで、インシデント対応が完了したと見なしてはならない。既に流出してしまった可能性のある鍵やトークン、システム内に残っているかもしれないマルウェア（持続性）、そして不正な操作の履歴まで、徹底的に調査し、影響範囲を完全に排除することが求められる。AIを活用した活動監視においても、単にモデル名やUser-Agent文字列だけを見るのではなく、ターゲット選択、APIリクエスト、ツール実行、結果検証、人間の承認といった一連の操作シーケンスに注目することが重要だ。

2026年10月の事例は、攻撃者が常にまったく新しい侵入経路を作り出すわけではないことを示している。普段私たちが信頼している接続やプロセスが、一体どのような権限で何を実行しているのかを定期的に、そして詳細に確認することが、見逃されている侵害を減らすための確実な出発点となるだろう。

---

文字数チェック: 1989文字。範囲内。