このインシデントは現在も調査が続いています。本記事の内容は執筆時点で入手できた情報に基づいており、調査の進展に伴って変わる可能性があります。
2026年9月21日、エージェント型脅威アクター(ATA)が、オランダの脆弱性開示機関DIVD(Dutch Institute for Vulnerability Disclosure)に侵入しました。DIVDは、インターネット上で露出しているシステムを見つけ、所有者に警告するボランティアの非営利団体です。ATAは、ヘルプデスクプラットフォームZammadに存在する未知の脆弱性2件、CVE-2026-102489とCVE-2026-102490を連鎖させて侵入しました。乗っ取ったセッションからroot権限の取得まで、わずか数秒でした。
DIVDによると、同団体は不審な動きに気づいて調査を開始し、侵害を受けていたことを把握しました。DIVDはこのATAを「うるさく、とにかく雑」と表現しています。AIエージェントは非決定的で、機械の速度で行動を一つずつ選んでいくためとみられます。こうしたノイズは、セキュリティチームにとって検知の好機になります。Sysdig Threat Research Team(TRT)がJADEPUFFERなどのATAで確認してきたのと同様に、DIVDへの侵入を行ったAIエージェントも、自らの行動と理由を説明するコメントをコードに残していました。このノイズのおかげでDIVDは1日以内に侵害を特定できました。ただ、攻撃の速さゆえに、それでも手遅れでした。
このエージェントは訓練や設定が不十分だった可能性がありますが、それでもヘルプデスクソフトウェアからDIVDのシステムへと移動し、データを持ち出して目的を達成しました。今回のゼロデイの影響を受けるZammadユーザーがどれだけいるかは不明ですが、同社のWebサイトによると、顧客は2,000社以上、ユーザーは5万5,000人に上ります。本記事では、侵入がどのように進んだのか、そして次の攻撃をCVEを知らなくても高速に検知・対処するにはどうすればよいのかを、現時点で判明している範囲で詳しく解説します。
DIVDで何が起きたのか
2026年10月1日、DIVDはこの侵害でデータが持ち出されたことを確認しました。調査は継続中で、DIVDによるインシデントの理解も今後変わっていく可能性があります。
以下のタイムラインは、DIVDが侵害と脆弱性について作成したケースファイルに基づいています。
|
日付 |
活動内容 |
|
9月21日 |
攻撃者がDIVDのシステムに初めて侵入 |
|
9月22日 |
DIVDが侵入を検知し、データセンター内のすべてのシステムへのアクセスを遮断。Merlon Securityとともにフォレンジック調査を開始。 |
|
9月22日~23日 |
DIVDが脆弱性を分析・再現。 |
|
9月24日 |
DIVDがオランダのデータ保護当局および国家サイバーセキュリティセンターに侵害を報告。あわせて侵害を公表し、Zammadに脆弱性を開示。 |
|
9月26日 |
DIVDが、公開されているZammadインスタンスをスキャンし、脆弱な組織への通知を開始。 |
|
9月29日 |
DIVDがケースファイルと2件のCVEレコードを公開。 |
脆弱性
Zammadは広く導入されているオープンソースのヘルプデスクソフトウェアです。DIVDは、Merlon Securityとともに侵害を調査する中で、どちらの脆弱性も特定しました。これらの脆弱性はDIVDへの攻撃に使われる前には開示されておらず、ゼロデイと位置づけられています。
- バージョン6.3.0~6.5.4に影響するリモートコード実行(RCE)の脆弱性です。バージョン7.0.0~7.1.3にも存在しますが、特定の環境条件のため悪用はできません。6.3.0より前のバージョンへの影響は不明です。
- CVSSスコアは8.7で、重大度は「高」です。権限不要で悪用しやすく、Zammadはインターネットに公開されるWebアプリケーションであるため、Webレベルで露出し、公開インターネットから到達できます。
- バージョン1.5.0~7.1.0-alphaのすべてに影響するローカル権限昇格(LPE)の脆弱性です。
- CVSSスコアは8.5で、重大度は「高」です。悪用しやすく、ローカルアクセスと最小限の権限が必要です。
連鎖させた場合のCVE
- RCEを悪用できるのはバージョン6.3.0~6.5.4のみのため、この連鎖が成立するのもその範囲です。
- CVSSスコアは9.4で、重大度は「緊急」です。
攻撃者の特定
本記事の公開時点で、ATAの背後にいる人間の operator は特定されておらず、犯行声明を出したグループもありません。DIVDはLinkedInで、エージェントがデータを読み取って持ち出したと述べています。ただ、攻撃の正確な目的と影響は、盗まれたデータの分析が進むにつれて、ようやく明らかになり始めたところです。
エージェントの手口
DIVDはすでに攻撃者を「自律型AIエージェント」と特定しており、人間が主導した攻撃ではないことを示す証拠は複数あります。
この攻撃の特徴は次のとおりです。
- 自律的で非決定的な判断:攻撃の流れはあらかじめ計画されたものではありません。ATAは、一つひとつの行動のたびに、機械の速度で次の一手を選んでいました。
- 自己説明型のスクリプト:エージェントはスクリプトのコメントに自らの判断を書き残していました。機械可読性を高めるための一般的な手法です。コメントの一部は、行動を無害なものとして説明していました。たとえば「no phishing」「no spam」といった記述です。
- 自己干渉:エージェントが行ったパスワードスプレーが、自らの中間者(MitM)攻撃を妨げました。
- お粗末な攻撃経路:攻撃は騒々しく雑でしたが、最終的にはタスクを完遂しました。エージェントは、どれだけ散らかし、どれだけ乱暴であっても、タスクを終わらせるために必要なことをします。人間の攻撃経路やスクリプトは、多くの場合その正反対で、より整っていて、より検知を避けようとします。
ステージ1:CVE-2026-102489による初期アクセス
ATAは、RCEのゼロデイ脆弱性CVE-2026-102489を使って初期アクセスを得ました。DIVDはこれを、セッションハイジャックからzammadサービスユーザーとしてのコード実行につながったものと説明しています。
何が検知できるか
Zammadのアプリケーションプロセス(Rails、Puma、およびそのワーカー子プロセス)が、対話型シェルを起動したり、ツールをダウンロードしたり、過去に通信したことのないホストへ外向き接続を開いたりすることは、本来ありません。zammadユーザーが通常実行する内容をプロファイル化しておけば、エージェントが最初に実行するコマンドは目立ちます。セッションハイジャックを調べるには、ログイン直後に新しい接続元アドレスからセッションが使われていないか、想定されるログインフローを飛ばしたリクエストがないかを確認してください。
ステージ2:CVE-2026-102490による権限昇格
ATAは2つ目のゼロデイ脆弱性CVE-2026-102490を1つ目と連鎖させ、zammadユーザーとしてroot権限を取得しました。
注意が必要なのは、1つ目の脆弱性を塞いだホストでも、別の方法でローカル実行権限を得た攻撃者には、この脆弱性が悪用され得る点です。DIVDによると、乗っ取ったセッション(ステージ1)からroot(ステージ2)までは数秒でした。
何が検知できるか
ホスト上のサービスアカウントが実効ユーザーIDをrootに変更することは、決してあってはなりません。これは精度の高いシグナルです。Linuxでは、zammadユーザーによるsetuid系の呼び出し、アプリケーションツリー配下に新たに現れるroot所有の子プロセス、そのアカウントによる特権パスへの書き込みを監視してください。以下は、サービスアカウントによる権限昇格やシェル起動を対象とするオープンソースのFalcoルールで、これらの挙動をカバーします。
- Launch Privileged Container
- Non sudo setuid
- Set Setuid or Setgid bit
- Change thread namespace
- Potential Local Privilege Escalation via Environment Variables Misuse
- sudo potential privilege escalation
ステージ3:認証情報への攻撃
root権限を得たATAは、パスワードスプレーとMitM攻撃を実行しました。ただし、どのシステムやアカウントが標的だったのかは、現時点では不明です。このエージェントは訓練が不十分だったとみられ、パスワードスプレーが自らのMitM攻撃を妨げました。今回の攻撃が騒々しかった一因です。
ヘルプデスクのホストには、通常さまざまな秘密情報が集中しています。Zammadが価値ある標的だったのはそのためです。データベースの認証情報、メールやAPIのトークン、サポートチームが扱うあらゆるシステムのAPIキーが保存されており、root権限があればそのすべてが一度に露出します。
何が検知できるか
設定ファイルや認証情報ファイルの大量読み取り、1つの接続元から多数のアカウントへの認証失敗の急増、ベースライン外のプロセスによるファイルシステム全体へのfindやgrepの走査を確認してください。システムコールレベルのランタイム可視化なら、エージェントが何を名乗っていようと、これらをすべて捉えられます。
ステージ4:データアクセスと持ち出し
Zammadの侵害は、エージェントが他のサービスに到達してデータを移動させるための足がかりでした。今回の標的がDIVDです。ネットワークセグメンテーションとDIVDのインシデント対応により、エージェントが環境のさらに奥へ進むことは防がれました。DIVDは侵害の特定後、データセンター内のすべてのシステムへのアクセスも遮断しています。10月1日時点でも調査は続いていますが、DIVDは予備分析で次のデータが影響を受けたことを確認しました。
- 持ち出しが確認されたデータ:ボランティアのDIVDメールアドレス。
- 持ち出された可能性があるデータ:ボランティアの連絡先情報。
- 侵入口で、侵害の兆候があるもの:CSIRTのチケット管理システム。CSIRTのメールボックスに届いたすべてのメールと返信が含まれますが、DIVDは一部のみが抽出されたとみています。スキャンデータに関する追加の問い合わせ(脆弱なシステムのIPアドレスを含む)、報告された脆弱性、パスワードをマスクした認証情報ダンプの抜粋などが含まれる可能性があります。
- その他の侵害の兆候:プロジェクト支援環境(JiraとConfluence)と、DIVDの業務を支えるITシステム上のシステムデータ。
- 調査継続中:Google Workspace(オフィス・管理業務)、人事システム、ヘルプデスクを含むIT支援システム、Slack、GitHubとGitLabのソースコード、そしてDIVDが保有する機微な調査データ。調査データには、脆弱なシステムのリスト、フィンガープリント、無害化したPoC、ゼロデイ脆弱性の詳細、漏えいした認証情報のダンプなどが含まれます。
- 影響が確認されていないデータ:会計情報、銀行口座、CSIRTへの最初の通知。
盗まれたことが確認されたデータにより、DIVDのボランティアになりすます行為が行われる恐れも出てきました。このため各組織は、ソーシャルエンジニアリングやフィッシングなどの攻撃に厳重に警戒する必要があります。
何が検知できるか
ヘルプデスクのセグメントから、これまで通信したことのない宛先への外向き接続、大容量または異常なアップロード、一時ディレクトリに書き込まれて実行された新しいツールを確認してください。ヘルプデスクのセグメントに、デフォルト拒否(default-deny)のエグレスポリシーを適用すれば、データの持ち出しは気づかれないまま進むのではなく、ブロックされる事象に変わります。
Zammadのゼロデイ脆弱性とATAに対する検知と緩和策
Zammadのアップグレード、またはオフライン化
Zammadをバージョン7.0.0以降にアップグレードするか、インスタンスを完全にオフラインにしてください。これらのバージョンではRCEは悪用できませんが、LPEの脆弱性のリスクは残ります。インスタンスを停止しない場合は、修正版ビルドについてZammadのセキュリティアドバイザリを注視し、それまでの間はzammadユーザーの異常な挙動を環境内で監視してください。
追加のガイダンスと侵害指標(IoC)は、こちらで確認できます。https://csirt.divd.nl/cases/DIVD-2026-00015/
ヘルプデスクの分離
アプリケーションを独立したネットワークセグメントに置き、エグレスはデフォルト拒否とし、内部サービスへのアクセスは厳密に絞り込んでください。侵害されたヘルプデスクホストが、他の何かに到達できてはいけません。DIVDでは、セグメンテーションがエージェントの到達範囲を限定するのに役立ちました。
証拠を保全してから調査
何かを再構築する前に、/var/log/zammadと/var/log/nginxを保管してください。これらに対してDIVDのスクリプトを実行すると、CVE-2026-102489の悪用の痕跡を見つけられます。 ただし、結果が問題なしでも、ホストが無事とは限りません。見慣れないプロセスやファイルも確認してください。攻撃者はroot権限を持っていたため、悪用の兆候が少しでもあれば、ホスト全体が侵害されたものとして扱ってください。そのホストに保存されている、またはそこから到達できるすべての認証情報をローテーションしてください。
シグネチャではなく挙動で検知
ゼロデイにシグネチャはありません。サービスアカウントがシェルを起動する、rootに昇格する、見慣れない宛先に到達するといった挙動の検知に、シグネチャは不要です。権限昇格、アプリケーションプロセス内のシェル、異常な外向き通信を対象とするランタイム検知なら、CVEを知らなくても、上記のすべてのステージをカバーできます。
機械の速度での対応を計画する
数秒でrootに到達するエージェントは、チケットキューの順番を待ってはくれません。精度の高いアラートに対しては、プロセスの強制終了やホストの隔離といった自動封じ込めをあらかじめ承認しておいてください。DIVDが実施したデータセンター全体の遮断も、事前に演習しておくことをお勧めします。
SysdigのクラウドDetection and Response向け555ベンチマークは、一つの基準を示しています。攻撃が完了するより速く、クラウドへの攻撃を検知して対応することを組織に促すものです。
まとめ
今回、盗まれた認証情報はありませんでした。攻撃に必要だったのは、2件のゼロデイ脆弱性とAIエージェントだけです。
DIVDは、露出したシステムを見つけて報告することを本業とするボランティアのセキュリティ組織です。そのDIVDでさえ、侵害に気づいたのは手遅れになってからでした。幸い、このATAは騒々しかったため、DIVDのインシデント対応チームが特定しやすかったとみられます。また、セグメンテーションにより、エージェントが環境の奥へ進んで、さらに多くのデータを持ち出すことは防がれました。
エージェントは高速に動きます。より巧妙に作られたエージェントなら、ノイズを減らすかもしれません。しかし、そこから生じる挙動は変わりません。サービスアカウントがシェルを起動する、プロセスがrootに昇格する、見慣れない外向き接続が発生する。これらは、悪用されたのが既知のCVEでもゼロデイでも、攻撃者が人間でもATAでも、同じように見えます。
この事例が示すのは、ランタイムでの脅威検知とセグメンテーションの必要性です。リアルタイムで検知すれば、数秒でrootに到達し、昼夜を問わず動き続ける攻撃者を暴き出せます。セグメンテーションは、その攻撃者を封じ込めます。機械の速度で動く脅威から守るには、この両方が必要です。
エージェント型脅威アクターへの備えを進めるにあたり、今日、次の3つの問いを自問してみてください。
- ホスト上のサービスアカウントがシェルを起動したり、root権限を取得したりしたとき、数秒以内に把握できますか。
- そのアラートは、ATAが次の一手を終える前に、担当者に届くか、自動対応を発動させられますか。
- ビジネスや重要なアプリケーションを止めずに、ネットワークセグメントを切り離せますか。
一つでも答えが「いいえ」なら、次のゼロデイ脆弱性が現れる前に、ランタイムでの検知と対応の自動化を目指してください。
