powered by TechFeed
表示モード
主要ニュース

AIエージェントがヘルプデスクツールのゼロデイ2件を連鎖させ、人間の対応が追いつく前にroot奪取 — DIVDへの侵入事例

10月5日、Mayura Kathirが「Autonomous AI Agent Chains Two Zammad Zero-Days in Machine-Speed Cyberattack」と題した記事を公開した。この記事では、自律型AIエージェントがヘルプデスクソフトウェア「Zammad」の2つのゼロデイ脆弱性を連鎖させ、オランダの脆弱性開示機関DIVDに侵入した事例について詳しく紹介されている。

10月5日、Mayura Kathirが「Autonomous AI Agent Chains Two Zammad Zero-Days in Machine-Speed Cyberattack」と題した記事を公開した。この記事では、自律型AIエージェントがヘルプデスクソフトウェア「Zammad」の2つのゼロデイ脆弱性を連鎖させ、オランダの脆弱性開示機関DIVDに侵入した事例について詳しく紹介されている。


「うるさくて、非常に散らかった」攻撃——それでもrootを奪った

今回の攻撃で最も注目すべき点は、攻撃が巧妙ではなかったにもかかわらず成功したことだ。

DIVDは侵入者の挙動を「loud and very messy(うるさく、非常に散らかった)」と表現した。攻撃者は高速で自動化された非決定論的な判断を下し、スクリプト内になぜその行動を取ったのかを説明する異常に冗長なコメントを残していた。これがAIエージェントによる攻撃と判断された根拠の一つだ。

従来の人間主導の侵入と異なり、このエージェントは偵察・脆弱性の悪用・権限昇格・データ窃取を高速かつ連続的に実行した。人間のインシデント対応プロセスが動き出す前に、rootアクセスとデータ窃取が完了していたという。


連鎖した2つのゼロデイ脆弱性

使用されたのは、オープンソースのヘルプデスクプラットフォーム「Zammad」の未公開脆弱性2件だ。なお、以下のCVE番号は元記事に記載された表記をそのまま掲載しているが、通常のCVE採番体系(CVE-西暦-連番)とは形式が異なるため、正式なアドバイザリが公開された際は番号を確認されたい。

CVE-2026-102489(CVSS 8.7)

  • 対象バージョン: Zammad 6.3.0〜6.5.4
  • セッションリークとリモートコード実行(RCE)を可能にする
  • 認証なしでzammadサービスアカウントとしてコード実行が可能
  • Zammad 7.0.0〜7.1.3にも同脆弱性は存在するが、DIVDが評価した環境条件下では悪用不可

CVE-2026-102490(CVSS 8.5)

  • 対象バージョン: Zammad 1.5.0〜7.1.0-alpha
  • ローカルのzammadユーザーからrootへの権限昇格を可能にする
  • RCE経由でなくローカル実行を得た場合でも、この脆弱性は単独で機能する

2つを組み合わせた場合のCVSSスコアは9.4(Critical)。認証なしのリモート攻撃者がrootまで到達できるシナリオが成立する。

※編集部の考察:Sysdigもこの連鎖について独自の分析を公開しており、検出手法を検討する際の参考になる(元記事には含まれない情報源)。


なぜヘルプデスクが標的になるのか

ヘルプデスクシステムは攻撃者にとって高価値の標的だ。これらのシステムには通常、以下が含まれる:

  • サポート対応メール
  • データベース認証情報
  • メール設定・APIトークン
  • インテグレーションシークレット

ヘルプデスクサーバーのrootアクセスは、より広範な企業サービスへのピボットポイント(横移動の起点)になり得る。今回もDIVDのCSIRTチケットシステム、プロジェクト支援環境、コラボレーションプラットフォーム、ソースコードリポジトリ、IT支援システム、そして機密性の高い脆弱性調査データセットへの影響を調査中だ。

ボランティアのメールアドレスが窃取されたことは確認済みで、連絡先情報も取得された可能性があるという。DIVDは、これらの情報がなりすましやフィッシングキャンペーンに悪用されるリスクを警告している。


検出シグナルと対応策

DIVDはMerlon Securityとフォレンジック調査を開始し、Zammad開発元への脆弱性開示、オランダ当局への通知、影響を受けるZammadインスタンスの特定・通知を進めている。ネットワークセグメンテーションによりデータセンター内への横移動は防げたとしている。

Zammadを運用している組織向けに、以下の対応が推奨されている。各項目は単独の設定変更ではなく、段階的に組み合わせて適用することが想定されている。

  • 侵害シグナルの監視: zammadプロセスがシェルを起動する、未知のバイナリを実行する、外部への新規接続を確立するといった挙動をログおよびEDRで継続的に監視する
  • 高信頼度の侵害指標: zammadサービスアカウントがrootへ権限変更、rootが親となる子プロセスの生成、特権パスへの書き込みが確認された場合は即座にインシデント対応を開始する
  • 緊急対応: 影響バージョンを確認し、システム再構築前にZammadおよびリバースプロキシのログを保全する。ログが上書きされると侵害の全容解明が困難になるため、保全を最優先とすべきだ
  • 認証情報のローテーション: サーバー上または接続可能な認証情報をすべて更新する。窃取済みの認証情報が横移動や後続攻撃に転用されるリスクを遮断するためだ
  • ネットワーク制限: ヘルプデスク環境を隔離し、東西通信(内部横移動)を厳しく制限、アウトバウンドはデフォルト拒否にする

今回の事例は、AIエージェントが完璧なステルス性を持たなくても、脆弱性発見から悪用完了までの時間的な「窓」を利用することで、既存の対応プロセスを無力化できることを示している。ゼロデイが絡む局面では、シグネチャベースの検出が利用可能になる前に攻撃が終わっているケースも想定しておく必要がある。


詳細はAutonomous AI Agent Chains Two Zammad Zero-Days in Machine-Speed Cyberattackを参照していただきたい。