The Tokyo Nomad
← プレイブック一覧へ
プレイブック / ARTEX型侵入

ARTEX対応プレイブック：防御・検知・監視・封じ込め・復旧

36の判断と9つの作業でARTEX型侵入に対応。Sentinel・Falconのハント、監視計画、証拠テンプレート、検証付き復旧条件を図解します。

公開日: 38 分で読めます
事案の発生時期: 再利用可能な対応ガイド・2026年11月4日確認出典確認日: 2026/11/4

30秒でわかる要点

このガイドの対象
ARTEX型侵入への再利用可能な運用手順。36判断、9作業、最初の1時間、10枚の図、監視計画、Sentinel・Falconのハント例を収録。
対応するチーム
SIEM、EDR、IT運用、委託先リスク、法務・プライバシー
最初のアクション
非公開の案件を開き、テストの許可と実際の影響を確認。被害システム・自社ハーネスの分岐を選び、承認された封じ込めと証拠保全を並行する。
不確実性・注意点
時間間隔、マーカー、公開コンソールだけでAI使用や侵害とはしない。再利用KQLは構文解析、CQLは静的レビューのみ。実テナントの検索、監視導入、封じ込めは未実行。
ARTEX対応プレイブック。9つの作業と36の証拠に基づく判断で防御、検知、監視、対応を行い、被害システムと自社ハーネスの分岐を分ける。
実務への示唆

AIへの帰属を待たず、実証した無許可の影響に対応する。API、ID、ホスト、自社ハーネスの封じ込めを分け、対象側で復旧を確かめる。

起きた操作から対応を選ぶ

AIハーネスは、APIの発見、IDの試行、データ変更、ツール実行、結果確認という既存の作業を速く回せます。その操作を許す認可と実行の境界を守ります。ARTEXを使ったという評価と、実証した無許可の操作を別に扱います。

本稿は9つの作業と36の判断、10枚の図、監視計画、コピー用テンプレート4本を備えた独自の運用ガイドです。新しい侵害の報告やベンダー公式手順ではありません。AIハーネスのハンティングフレームワークとARTEXの攻撃パターン分析を、具体的な対応へつなぎます。

被害が確かなら、封じ込め、証拠保全、連絡を並行します。 番号の作業をすべて終えるまで封じ込めを待つ手順ではありません。防御と監視は平常時も続けます。変更は組織で許可された担当が行い、このページがテナントを操作したりアラートを導入したりすることはありません。

初動、防御、検知、監視、調査、封じ込め、根絶、復旧、連絡の9作業。無許可の影響が確かなら封じ込めへ直接進み、証拠と連絡は並行する。準備と監視は全期間で繰り返す。

独自の運用図。各分岐は本文の表にも掲載。不明は担当と次回確認を付けて追跡します。

最初の1時間：帰属より対応の統制

以下は連携の目安であり、1時間で復旧できるという保証ではありません。進行中の被害が確かなら、承認済みの封じ込めを直ちに行います。

確認時点 操作と残す結果
最初の5分 案件を開き、対応責任者を決め、元アラートと対象アプリ・主体・端末を記録する。
最初の15分 既知の連絡先でテストの許可を確認。被害システム、自社ハーネス、両方を選び、封じ込めと保全を開始する。
最初の30分 実際のAPI操作、ID変更、サーバー実行を確認。信頼できるID、保持の限界、継続中の不正操作を残す。
1時間以内の初回確認 対象側で制御の結果を確認し、監視計画、事実と不明点の報告、次の担当を決める。パスワード変更や静穏だけで終えない。
証拠の状態 判断
タイトル、マーカー、時間間隔、共有コールバック先の一致 所有者、認可、平常時の基準を調べる。AIの分類器でも、自動隔離のトリガーでもない。
不審な操作が関連するが許可は不明 主体・対象・プロセスを照合し、サービス担当の認可判断を得て、釣り合う封じ込めを検討する。
進行中の無許可アクセス・変更・実行が確か 承認済み制御で直ちに封じ、効果の確認と残存アクセスの調査を並行する。

担当、証拠、判断のルール

SOC/SIEMは初動、収集の健全性、時系列。AppSec/API/SREはアプリ境界と安全な可用性。IAMは人とワークロードのID。EDR/DFIRはホストの証拠と隔離。ハーネス・基盤担当は管理面、ワーカー、モデル提供元の資格情報。業務担当はデータと処理の確認。法務・プライバシーは通知義務。対応責任者は優先順位、リスク、復旧の判断を担います。

該当する判断ははい・いいえ・不明・該当なしで記録します。いいえにも対象範囲と証拠が必要です。不明は未解決タスク、該当なしには理由と確認者を付けます。発生・取り込み時刻、対象・主体・端末ID、認可結果、証拠参照、操作と結果、担当、次回確認UTCを残し、生のBearerトークンを関連キーにしません。

36判断の記録表をダウンロード。空欄は非公開の案件用です。表計算へ入る文字列は信頼せず、記入済みの案件記録や秘密情報を公開サイトへアップロードしません。

0. 初動：影響と判断権限を決める

実際に起きた操作から対応の分岐を選びます。ARTEXに似たツールが見えただけで侵害とはしません。不正アクセス、業務データの変更、不正な実行の証拠があれば、帰属の確定を待たずに封じ込めを判断できます。

判断R01〜R04：初動：影響と判断権限を決める。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R01. 無許可の操作が実際に起きた証拠はあるか？ 実証された経路を封じ、インシデントを開始する。 許可と実際の状態を確認し、手がかりを追跡する。 元イベント、対象の結果、演習期間、担当者による独立した確認。 対応責任者＋SOC
R02. 承認済みのテストに含まれるか？ 対象、実施者、期限を確認し、範囲外も調べる。 所有者の確認まで認可を未解決として扱う。 承認範囲、変更記録、テスト担当者、既知の連絡先。 SOC＋テスト責任者
R03. 自社が運用するハーネスの管理画面も関係するか？ 管理面の分岐を開き、ワーカーと秘密情報も対象にする。 被害側の証拠を調べ、第三者の画面にはアクセスしない。 所有ホスト、導入記録、プロキシ監査、ワーカー台帳。 基盤担当＋DFIR
R04. 判断権限と安全な調査用アクセスは準備できているか？ 封じ込め、証拠、業務の担当と次回報告時刻を決める。 信頼できる管理端末と別の連絡経路を確保する。 案件ID、承認された役割、連絡先、サービス依存関係。 対応責任者

具体的な操作手順

  1. アクセス制限した案件を一つ開き、UTC、報告者、テナント、アプリ、対象リソース、端末ID、実際の結果を記録します。仮説は別の欄に残します。
  2. 既知の連絡先で演習承認を確認します。「authorised」というUser-Agent、ログイン済みのアカウント、演習ツールの名前は、操作の許可を意味しません。
  3. 被害システム、自社ハーネス、または両方を選びます。攻撃元らしいARTEXの画面は、保有ログや保存済み観測から確認する手がかりであり、第三者へログインする許可ではありません。
  4. 各境界を変更できる担当者を決めます。安全な管理端末と別の連絡経路を使い、緊急アクセス用アカウントと重要業務の依存関係を保護します。
  5. 進行中の侵害や、特権アクセスに関する重大な不明点は責任者へ連絡します。承認済みの緊急封じ込めを、完全なフォレンジック取得のために遅らせません。

確認する結果： 実際の影響、認可の判断または未確認点、対応の分岐、担当者が案件に残っている。

1. 防御：ハーネスが利用できる境界を閉じる

平常時にも、対応と並行しても行う作業です。業務APIと自社のテスト基盤を保護します。リバースプロキシやログイン画面は、見えるページだけでなく管理用の経路も守る必要があります。

判断R05〜R08：防御：ハーネスが利用できる境界を閉じる。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R05. 公開アプリとテスト用コンソールを把握しているか？ 所有者、版、入口、オリジン、許可経路を記録する。 クラウド台帳、DNS、入口設定、資産台帳を照合する。 独立した台帳、導入設定、自社資産の公開面の観測。 IT運用＋基盤担当
R06. すべての機密操作で認可を強制しているか？ 別経路、項目、テナント、非同期出力も試験する。 修復中は脆弱な操作を制限する。 サーバー側の方針、管理下の拒否試験、業務担当。 AppSec＋API担当
R07. ワーカーと資格情報の権限は制限されているか？ 最小権限、実行の分離、プロバイダーの上限を確認する。 不要なホスト権限と広すぎる共有資格情報を取り除く。 ワーカー権限、Dockerソケット、秘密情報、保存セッション。 基盤担当＋IAM
R08. 操作とログ不足を観測できるか？ 信頼できる主体、対象、結果、収集の健全性を残す。 不足する層に記録を加え、現在の死角を記録する。 プロキシ・アプリ監査、IDログ、端末台帳、正常な確認イベント。 SOC＋SRE

具体的な操作手順

  1. 本番、開発、提携先、直接オリジンへの経路を台帳化します。自社コンソールは版、待受アドレス、認証プロキシ、許可された運用者、ワーカーも記録。公開検索の対象は許可済み資産に限定します。
  2. 管理面をプライベートアクセスやVPNと認証ゲートウェイで保護します。ログインページだけでなくAPIとWebSocketも確認。初期資格情報を変更し、その製品の失効とアイドルセッション制御を試験します。
  3. 対象、機能、項目、テナントの認可をサーバーで強制します。不要な公開登録や一括操作を制限します。レート制限は修復中の被害抑制には使えますが、遅い不正アクセスを許可する根拠にはなりません。
  4. ワーカーを本番の秘密情報や他の処理から分離します。ホストのマウント、Dockerソケット、クラウドのメタデータ、保存ブラウザーセッションを確認。モデル・クラウド資格情報を限定し、対応可能なら使用量や費用を監視します。
  5. 信頼できる主体ID、対象ID、認可結果、要求とプロセスの関連付けを記録します。収集の健全性も残します。無制限な本文・トークンの記録を避け、必要な生データは別途保護します。

確認する結果： 管理下の無許可操作がサービス側で拒否され、既知の正常イベントが調査基盤へ届く。

2. 検知：手がかりを実際の影響へつなぐ

ARTEXは一般的なクライアント、スクリプト、IDを組み合わせます。ツール名や見かけの速度より、操作の結果を重視します。後述のハント一覧は調査の入口であり、自動判定ではありません。

判断R09〜R12：検知：手がかりを実際の影響へつなぐ。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R09. 探索の後にAPIの書き込み成功や読み戻しがあったか？ 呼び出し元、正確な対象、認可、変更後の状態を取得する。 探索がなくても否定せず、他の手がかりを調べる。 S1・C1・C5、信頼できる要求ID、アプリ監査。 SOC＋API担当
R10. ファイル、アカウント、コマンドに報告済みの特徴があるか？ イベントを保全し、承認済み演習と親プロセスを確認する。 派生版は特徴を消せるため、動作も調べる。 S2・C3、元イベント、演習の承認記録。 SOC＋EDR
R11. Webワーカーが想定外の子プロセスを起動したか？ コマンド、プロセスID、許可を確認し、不正実行を封じる。 別の実行経路と記録の範囲を確認する。 C2、親子関係、ホスト所有者、保守履歴。 EDR＋アプリ担当
R12. 認証失敗やアプリ主体の変更に不審点があるか？ 結果と承認を確かめ、対象へのアクセスと永続化を追う。 確認したID、期間、ログの範囲を記録する。 S3・S4、サインイン・ディレクトリ監査、主体のオブジェクトID。 IAM＋SOC

具体的な操作手順

  1. 調査済みのアプリ、端末、主体から始めます。Sentinelのワークスペースと表、Falcon製品、パーサー、対象、期間、保持、読み取り権限を検索前に記録します。
  2. APIでは探索、受理された変更、同じ対象の読み戻し、途中のエラーを保全します。共有IPを同じ認証セッションとみなさず、クエリパラメーターで対象を選ぶならパス以外の正規化キーを使います。
  3. 端末ではサーバーから親子プロセス、コマンド、作成ファイル、接続先へ進みます。Pythonやcurlという名前だけではAIエージェントの証拠になりません。
  4. パスワード失敗、認証成功、ディレクトリ変更、データ側の利用を分けます。失敗だけのスプレーも確認し、共有アドレスからの成功をそのまま攻撃成功と判断しません。
  5. 時間間隔やマーカーは優先順位の材料にします。悪意やARTEXへの帰属を述べる前に、独立した担当者と監査記録で許可と状態を確認します。

確認する結果： エスカレーションする手がかりに、実際の影響、関連ID、承認確認、次の証拠要求が付いている。

3. 監視：証拠に基づくウォッチを運用する

監視には担当者、データで分かる範囲、許可された対応が必要です。時間間隔だけで隔離を開始しません。監視表の頻度は自社で合意する運用案であり、実証済みの検知SLAではありません。

判断R13〜R16：監視：証拠に基づくウォッチを運用する。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R13. 必要な記録は今回の監視に十分な鮮度と範囲があるか？ 遅延、サンプリング、範囲を記録して監視を続ける。 収集担当へ連絡し、期間を観測不能として残す。 確認イベント、収集の稼働信号、遅着、資産台帳。 SIEM基盤担当
R14. 信頼できる主体と正確な対象・端末を関連付けられるか？ 認可を確かめ、別の層でも影響を裏付ける。 確度の低い手がかりとし、関連付けを修正する。 主体・対象・プロセスのキー、プロキシの信頼とNAT。 SOC＋データ担当
R15. 進行中の無許可操作を確認したか？ 承認済みの封じ込めを実施し、結果を検証する。 環境が正常とは断定せず、調査と基準の確認を続ける。 対象側監査、想定外の実行、資格情報変更、承認。 対応責任者＋制御担当
R16. 監視担当と例外の失効時刻は決まっているか？ 次回確認を記録し、演習例外を限定する。 監視に依存する前に担当者と期限を決める。 通知先、当番の受領、限定した例外と期限。 SOC責任者

具体的な操作手順

  1. 監視表について当番、通知先、監視自体が止まった場合の連絡経路を決めます。「イベントなし」を静穏とせず、実際の収集遅延を確かめます。
  2. 発生時刻と取り込み時刻を分けます。各ソースに既知の正常イベントが届くか確認し、サンプリング、保持期間、再構成できない区間を記録します。
  3. 定期化の前に、遅着を含む限定期間、カーソルやイベントIDでの重複排除、パーサー、処理量、通知条件を検証します。公開ハントは手動調査の例であり、本番アラートとして導入済みではありません。
  4. 結果100件や入力上限に達したら時間を分割し、未処理分を残します。切り詰めた結果を総件数や、後続活動が止まった証拠にはしません。
  5. 対応中は拒否件数だけでなく受理された操作も見ます。演習例外に期限を設け、承認済みイベントで連絡を試験。誰が受け取り、何を確かめたかを記録します。

確認する結果： 正常な確認イベントが見え、収集停止も検知でき、各通知に担当と承認された次の操作がある。

4. 調査：確度を誇張せず範囲を決める

正確な資産とIDを軸に活動を再構成します。アラート時刻は侵入開始時刻とは限らず、APIの応答件数をそのまま人数や持ち出し件数にはできません。

判断R17〜R20：調査：確度を誇張せず範囲を決める。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R17. 最も早い露出時点の範囲を定められるか？ 根拠のある期間に余裕を加えて検索する。 観測できる期間を保全し、それ以前の不明点を明示する。 リリース・設定履歴、最初の証拠、保持、時計のずれ。 DFIR＋サービス担当
R18. Web・端末・IDの証拠を安全に関連付けられるか？ 確認済みキーと発生時刻で時系列を作る。 仮説を並べたまま、不足する関連情報を要求する。 主体、対象、要求、プロセスのID、解決方法と遅延。 SOC＋DFIR
R19. 実際のデータアクセスや業務状態の変更を確認したか？ 対象、返却データ、転送、人数を分けて数える。 到達可能な範囲と不明点を記録し、窃取とは断定しない。 対象監査、応答情報、出力ジョブ、通信、データ担当。 データ担当＋法務・プライバシー
R20. 盗まれた資格情報で別サービスやワーカーへ届くか？ 許可範囲と追加された永続化まで調べる。 確認した資格情報と依存経路を記録する。 資格情報台帳、対象主体、プロバイダーログ、ワーカー権限。 IAM＋基盤担当

具体的な操作手順

  1. エッジ、アプリ、ID、EDR、ストレージ、導入記録の原本を取得します。取得者、UTC期間、ハッシュ、アクセス制御、保持、欠損を記録。案件データを公開リポジトリに置きません。
  2. 最初のアラートだけでなく、脆弱な導入や資格情報露出の最も早い可能性を追います。保持されていれば過去も確認し、記録が途切れる箇所を明示します。
  3. 確認済みの主体、対象、プロセスIDで時系列を作ります。共有IP、プロキシのヘッダー、User-Agent、ホスティングの国は補助情報であり、所有者や帰属の証明にはしません。
  4. アプリ・データ担当に、実際に返却・変更した対象と項目を確認します。要求数、固有レコード、重複、影響人数を分け、HTTP成功だけで件数を決めません。
  5. 自社ハーネスではプロジェクト、エクスポート、ジョブ、保存セッション、モデルキー、SSH・クラウド資格情報、ホストの信頼境界も含めます。利用されたプロバイダーや委託先のIDも調べます。

確認する結果： 実証された影響、到達可能な範囲、不明な期間を時系列で分け、重要な未確認点に担当がいる。

5. 封じ込め：無許可の経路を止める

実際に悪用されている境界を封じます。ネットワーク隔離、API認可、人のセッション、アプリ資格情報は別の制御です。可能な証拠は並行して保全し、完全な取得のために進行中の被害を放置しません。

判断R21〜R24：封じ込め：無許可の経路を止める。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R21. 脆弱なAPIや出力経路をまだ利用できるか？ 認可するサービスで制限し、迂回経路も閉じる。 管理下のデータで拒否を確かめ、待機中の出力も見る。 バックエンド結果、直接オリジン・旧版、ジョブ、キャッシュ。 API担当＋SRE
R22. ホストで無許可の実行が起きた確かな証拠はあるか？ 承認済みの端末封じ込めとプロセス証拠の保全を行う。 時間間隔だけでは隔離せず、調査を続ける。 ホストID、親子プロセス、承認、業務依存関係。 EDR＋対応責任者
R23. 人またはワークロードの資格情報が悪用されているか？ 発行元と対象に適切な制御を適用し、効果を確認する。 付与権限、既存セッション、別の資格情報も確認する。 ユーザーとサービス主体の区別、トークン受理、監査。 IAM＋アプリ担当
R24. 侵入者が自社ハーネスやワーカーを使えるか？ 管理アクセスを制限し、不正なジョブを安全に止める。 制限を緩める前にワーカー、保存セッション、監査を確認する。 自社導入、稼働ジョブ、プロキシ・認証監査、秘密情報の範囲。 基盤担当＋対応責任者

具体的な操作手順

  1. 承認者、対象、UTC、業務影響、戻す条件を記録します。重要業務と調査用アクセスを守りながら、効果のある承認済み制御を選びます。
  2. APIでは認可を強制するサービスで対象機能を停止・制限します。旧版、直接オリジン、提携経路、出力ジョブ、キャッシュ、署名付き出力も確認。WAF遮断や後の403は、先の変更が戻った証拠にはなりません。
  3. 実行を確認したホストはFalconのaidやDefender DeviceIdを照合してから、許可された封じ込めを使います。実際の結果とEDR管理通信を確認。ホスト隔離だけではクラウド資格情報は失効しません。
  4. 人のIDでは侵害されたアクセスを制限し、セッションや回復方法も扱います。アプリ主体では業務依存を確認して資格情報、付与権限、ロールを調べます。発行済みアクセストークンは、有効期限や対象側の拒否まで受理される場合があります。
  5. 自社ハーネスでは管理面の到達性を閉じ、未承認のワーカー作業を止めます。取得可能なジョブ・認証の証拠を残し、安全な管理端末から露出資格情報を更新。ホスト権限やDockerソケットへのアクセスがあればホスト全体も対象にします。

確認する結果： 新たな管理下の確認で、実証された不正操作が対象側で拒否され、残る経路を追跡している。

6. 根絶：原因と残存アクセスを取り除く

ARTEXは作業を統括する基盤であり、一つの固定マルウェアや永続化手順ではありません。APIだけの事案では端末マルウェアがなくても業務データが変わります。サーバー侵害ではハーネスが不要になった後もアクセスが残り得ます。

判断R25〜R28：根絶：原因と残存アクセスを取り除く。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R25. 侵入経路や認可の欠陥を修復したか？ 同等の経路を試験し、修復した版を記録する。 代替制御を続け、修復担当者を追跡する。 原因の証拠、導入・設定の差分、拒否試験。 開発＋AppSec
R26. 永続化と未承認の変更を調べたか？ 証拠を記録し、担当の承認で不正なアクセスを除去する。 範囲調査を続け、不足する製品の専門担当を決める。 ロール、権限付与、資格情報、ジョブ、起動・遠隔アクセス設定。 IAM＋DFIR
R27. 露出した秘密情報とセッションを最後まで処理したか？ 更新、古いアクセスの拒否、依存サービスの健全性を確認する。 対象を制限し、資格情報台帳を完成させる。 秘密情報の範囲、プロバイダーログ、失効の挙動、更新記録。 IAM＋各サービス担当
R28. ホストやワーカーを引き続き信頼できるか？ 根拠を残し、設定とセンサーの健全性を確認する。 整合性を確認できなければ信頼できるソースから再構築する。 実行権限、ホストへの到達、正常なソース、フォレンジック結果。 DFIR＋基盤担当

具体的な操作手順

  1. 実証した原因を修復します。サーバー側認可、管理面の公開、脆弱な構成要素、資格情報の侵害などを分け、ツール名の拒否リストだけで修復としません。
  2. 対象製品の永続化を確認します。ディレクトリの資格情報・所有者、アプリ権限・ロール、SSH、タスク、サービス、自動起動、遠隔ツールなど、該当するものを調べます。可能なら除去前に証拠を残します。
  3. 侵害されたIDとワーカーから外側へ追います。最初のアプリの削除や一つのパスワード変更では、別主体に追加した資格情報や別サービスの保存セッションは取り除けません。
  4. 安全な環境からモデル、クラウド、SSH、アプリの資格情報を更新します。発行元と対象で古いアクセスの拒否を確認し、不審な利用・課金を監視。依存先と調整し、未記録の緊急資格情報を残しません。
  5. ホスト実行やコンテナー実行基盤の制御で整合性が崩れた場合は、信頼できる再構築と、そのホストから届く秘密情報の処理を計画します。業務データは担当者が照合し、後続の正当な取引を無条件に上書きしません。

確認する結果： 実証した入口が修復され、残存アクセスを確認し、秘密情報と状態の変更に担当と確認結果がある。

7. 復旧：明示した条件を満たして再開する

復旧は新たな試験に基づく業務判断です。静かなダッシュボード、脆弱性チケットの完了、ホスト隔離だけで、古いアクセスが対象側で拒否されるとは確認できません。

判断R29〜R32：復旧：明示した条件を満たして再開する。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R29. 以前の不正操作を管理下の拒否試験で拒否できるか？ 対象の経路と役割ごとに結果を記録する。 該当経路を制限したまま、失敗した境界を修復する。 管理下のアカウント・記録、応答結果、バックエンド監査。 AppSec＋API担当
R30. 承認された業務処理とデータは正常か？ 戻す権限を決め、限定範囲から再開する。 広く使う前に状態を照合し、代替手段を試験する。 業務確認、復元対象、ジョブ、信頼できるソース。 業務担当＋SRE
R31. 復旧中の観測は健全か？ 遅着を処理し、再び受理される不正操作を監視する。 記録を復旧し、観測の空白を未解決のまま残す。 収集確認、端末台帳、遅延、検索の未処理分。 SOC＋基盤担当
R32. 残留リスクと監視終了条件は承認されているか？ 対応・業務の承認を得て、再開するトリガーを残す。 担当、期限、記録した制限を付けて監視を延長する。 リスク受容、トークン・セッション確認、代表的な業務周期。 対応責任者＋業務担当

具体的な操作手順

  1. 管理下のIDと記録だけで試験します。問題の操作、役割・テナントをまたぐ拒否、旧API、オリジン、非同期出力を確認し、HTTPコードだけでなく実際の応答と状態を残します。
  2. 発行元と対象に適した、承認済みで非破壊の方法で古い資格情報・セッションを確認します。更新コマンドの成功だけで、すべての古いアクセストークンが無効とは判断しません。
  3. 業務担当が変更された記録、承認、エクスポート、待機ジョブを照合します。安全な管理で限定した通信・処理から戻し、元の欠陥を黙って復活させない戻し方を用意します。
  4. ソースとセンサーの健全性を再確認し、遅着を処理してから監視が静かだと述べます。EDRとは独立した台帳も照合。記録なしは、停止中、別製品、取り込み不足かもしれません。
  5. 露出範囲、トークン・セッションの挙動、収集遅延、代表的な業務周期で観察期間を合意します。一律24時間を安全条件にせず、新しい証拠や未処理データがあれば延長し、案件を再開する権限を決めます。

確認する結果： 拒否試験と業務試験に成功し、観測が健全で、残留リスクの担当を明示した再開承認がある。

8. 連絡と改善：証拠を残して完了する

「AIを使った可能性」を結論にせず、影響と判断を説明します。通知義務は対象データ、契約、適用法で決まり、ARTEXだから一律の期限になるわけではありません。

判断R33〜R36：連絡と改善：証拠を残して完了する。はい・いいえの分岐は続く表にも掲載し、不明は担当者を決めて追跡する。

独自の判断図。該当する判断を全て確認し、表の証拠で不明点を解決します。

判断 はい いいえ 証拠・不明点の確認 主担当
R33. 報告は事実、評価、不明点を分けているか？ 担当と次回確認時刻を付けて対象を限定した報告を送る。 根拠のない帰属、件数、復旧宣言を先に修正する。 証拠参照、確認した結果、確度の説明。 対応責任者＋広報
R34. 通知と契約上の義務を評価したか？ 必要な宛先、期限、完了の証拠を追跡する。 法務・プライバシーへデータと義務の評価を割り当てる。 法域、データ分類、契約、発見・認識時刻。 法務・プライバシー
R35. 終了条件と残るリスクを記録したか？ 独立した確認、承認、継続監視を記録する。 案件や残留リスクのタスクに期限を付けて追跡する。 完了条件、承認した例外、証拠保持、引き継ぎ。 対応責任者＋業務担当
R36. 演習と教訓を運用制御へ反映したか？ 境界を再試験し、検知と対応の担当を更新する。 机上演習と具体的な変更を割り当てる。 試験記録、通知への対応、観測不足、変更担当。 SOC責任者＋開発

具体的な操作手順

  1. 確認したアクセス・変更、封じ込め、業務影響、データ範囲、不明点、次の操作を報告します。評価にとどまるなら「ARTEX型」と書き、タイトル、IPの国、時間間隔から攻撃者を名指ししません。
  2. 法務・プライバシーへ時系列、データ分類、関係者、契約を渡します。特定の国や一律72時間を前提にせず、適用される報告の起算点を管理します。通知義務の評価に帰属の確定を待つ必要はありません。
  3. 可能なら別の確認者が復旧条件を見ます。受容した残留リスクに担当と期限を記録し、可視性の不足を「問題なし」とはしません。
  4. 組織の証拠保持方針に従って原本と操作記録を保存します。生の資格情報、Cookie、顧客データ、無制限なプロジェクト出力ではなく、必要箇所を除いた要約を共有します。
  5. 承認済みテスト、無許可API変更、盗まれたアプリ資格情報、自社ハーネス乗っ取り、ログ停止の5事例を机上演習します。期待する判断と引き継ぎを記録し、未承認の攻撃基盤を動かさずに合意した制御を試験します。

確認する結果： 業務・対応責任者が終了または明示した残留リスクの追跡を承認し、各教訓に変更担当と検証がある。

監視計画：各ウォッチを次の行動へつなぐ

監視計画をダウンロード。以下は対応中に人が確認する頻度の案であり、SentinelやFalconに設定済みのスケジュールではありません。当番体制、収集遅延、業務の重要性で合意します。監視の前提は、そのソースが稼働しているという証拠です。

監視 証拠と確認事項 確認頻度 判断・対応 担当
M01 収集の健全性：プロキシ、ID監査、EDRの確認イベント 対応中は5分ごと 確認イベントなし、または合意した遅延を超えたら収集担当へ連絡し、空白を記録する。 SIEM基盤担当
M02 受理されたAPI操作：S1・C1・C5と対象側監査 対応中は5分ごと 正確な主体と対象を裏付け、無許可操作を確認したら封じ込めへ進む。 SOC＋API担当
M03 IDの結果と変更：S3・S4と対象のログ 対応中は5分ごと 承認と変更対象を確認し、担当と資格情報・付与権限・ロールを調べる。 IAM＋SOC
M04 サーバー実行とマーカー：C2・S2・C3 EDR通知と対応中15分ごとの確認 親子関係と認可を調べ、名前だけでなく不正実行の証拠で封じる。 EDR＋DFIR
M05 外向き転送とコールバック：S5・S6・C4 対応中は15分ごと 持ち出しと述べる前に、方向、要求単位、プロセスとデータの関係を確認する。 SOC＋データ担当
M06 台帳とセンサーの照合：S7と独立したCMDB 毎日、および復元・導入の後 古い記録、別EDR、取り込み不足を確認し、記録なしだけで侵害とはしない。 IT運用
M07 自社ハーネス：プロキシ・認証監査、ジョブ、プロバイダー利用 自社ハーネスの対応中は15分ごと 未承認ジョブとアクセスを止め、秘密情報、不審なモデル利用・課金を調べる。 基盤担当
M08 復旧試験、遅着、残存アクセス 制御変更の都度、および合意した観察期間中 古いアクセスの拒否と業務を確認し、新証拠や未処理があれば延長する。 対応責任者＋業務担当

ハントの選択と実例4本

項目の要件、誤検知、見落としは完全なハント集と対応表にあります。以下の被害側の13例はフレームワークから変更せず再利用しています。ZIPにはC7という固定版Cairnのコンソール例もありますが、その経路をARTEX共通のものとして使いません。

Sentinelは24時間、S7だけ7日間のセンサー記録です。Falconの画面では直近1時間を指定します。全例が結果100件を上限とし、Webの連続操作・間隔の例は古い方から最大10,000入力を扱います。多い場合は期間を分割し、コネクター、読み取り権限、既知の正常イベントを確認してから結果なしを解釈します。

ハントとダウンロード データと調査目的
S1 · 探索に続くAPI書き込み ASIM _Im_WebSession
S2 · 報告されたプローブファイル DeviceFileEvents (Defender ingestion)
S3 · 失敗だけのスプレーも調べる SigninLogs
S4 · ワークロードのサインイン後の変更 AADServicePrincipalSignInLogs + AuditLogs
S5 · 近いサイズの外向き通信の反復 CommonSecurityLog (CEF proxy)
S6 · コールバックサービスへの接続 DeviceNetworkEvents (Defender ingestion)
S7 · 資産台帳とセンサーの差を調べる DeviceInfo (Defender ingestion) + supplied inventory
C1 · 同じリソースへの書き込みと読み戻し CPS web logs + neighbor()
C2 · Webプロセスが起動するシェル等 ProcessRollup2
C3 · プロセス内の報告済みマーカー ProcessRollup2
C4 · コールバック先のDNS調査 DnsRequest
C5 · 書き込みエラーから成功への反復 CPS web logs + neighbor()
C6 · 対象を絞った操作間隔のプロファイル CPS web logs + neighbor()

S1：探索に続く、受理された変更

ASIMのWeb記録で同じ送信元IPとホストを結びますが、同じセッションとは確認できません。絶対URL、EventResultDetailsの数値HTTPコード、/api/の変更経路を前提とするため、自社パーサーと経路に合わせます。成功応答にも認可と状態の確認が必要です。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Sentinel: ASIM _Im_WebSession; last 24 hours, one app and one source IP, at most 100 pairs.
// Requires absolute Url, SrcIpAddr, HttpRequestMethod and numeric HTTP status in EventResultDetails.
let AppHost = "REPLACE_WITH_APP_HOST";
let SourceIP = "REPLACE_WITH_SOURCE_IP";
let Events = materialize(_Im_WebSession(starttime=ago(24h), endtime=now())
    | where SrcIpAddr == SourceIP
    | extend Parsed = parse_url(Url)
    | extend Host = tolower(tostring(Parsed.Host)), Path = tostring(Parsed.Path),
        Method = toupper(HttpRequestMethod), Status = toint(EventResultDetails)
    | where Host == tolower(AppHost)
    | project TimeGenerated, SrcIpAddr, Host, Path, Method, Status);
let Discovery = Events
    | where Method == "GET" and Status between (200 .. 299)
    | where Path matches regex @"(?i)(\.js\.map$|/openapi\.json$|/swagger\.json$|/\.env(?:\.[^/]+)?$|/\.git/config$|\.(?:sql|bak)(?:\.gz)?$)"
    | project SrcIpAddr, Host, ReadTime = TimeGenerated, ReadPath = Path;
Discovery
| join kind=inner (Events
    | where Method in ("POST", "PUT", "PATCH", "DELETE") and Status between (200 .. 299)
    | where Path startswith "/api/"
    | project SrcIpAddr, Host, WriteTime = TimeGenerated, WritePath = Path, Method, Status
    ) on SrcIpAddr, Host
| where WriteTime between (ReadTime .. (ReadTime + 10m))
| project ReadTime, WriteTime, SrcIpAddr, Host, ReadPath, WritePath, Method, Status
| order by WriteTime desc
| take 100

S4：ワークロードのサインイン後のディレクトリ変更

公開クライアントAppIdではなく、テナントのサービス主体オブジェクトIDを使います。同一主体と30分以内という関連であり、同一トークンや不正な永続化の証明ではありません。正確な変更対象、承認、後続アクセスを確認し、別のマネージドID経路も補います。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Sentinel Entra workload sign-ins + directory audit; needs both ingestions and read permission.
// Use a tenant service-principal object ID, not a public client AppId. Last 24h; at most 100 pairs.
let Principal = "REPLACE_WITH_SERVICE_PRINCIPAL_OBJECT_ID";
let Starts = AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(24h) .. now())
    | where ServicePrincipalId == Principal and ResultType in~ ("0", "Success")
    | project PrincipalId=ServicePrincipalId, SignInTime=TimeGenerated, IPAddress, ResourceDisplayName;
let Changes = AuditLogs
    | where TimeGenerated between (ago(24h) .. now())
    | where Result =~ "success"
    | extend PrincipalId=tostring(InitiatedBy.app.servicePrincipalId)
    | where PrincipalId == Principal
    | where OperationName matches regex @"(?i)(credential|certificate|secret|owner|role)"
    | project PrincipalId, ChangeTime=TimeGenerated, OperationName, TargetResources, CorrelationId;
Starts
| join kind=inner Changes on PrincipalId
| where ChangeTime between (SignInTime .. (SignInTime + 30m))
| project SignInTime, ChangeTime, PrincipalId, IPAddress, ResourceDisplayName,
    OperationName, TargetResources, CorrelationId
| order by ChangeTime desc
| take 100

C2：想定外のWebワーカーの子プロセス

FalconのProcessRollup2を一つのセンサーaidへ限定します。選んだWebワーカー名の直接の子だけを対象にするため、Javaで動くサーバーや間接的な起動には別の確認が必要です。保守と正当なHTTPクライアントを基準に、実際の親子関係を調べます。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Falcon Insight EDR / Advanced Event Search. REQUIRED time picker: last 1 hour.
// One sensor AID; requires ProcessRollup2 with parent name and command-line telemetry.
// Direct web-worker children only; baseline approved maintenance before alerting. Output at most 100 groups.
#event_simpleName=ProcessRollup2 aid="REPLACE_WITH_FALCON_AID"
| ParentBaseFileName=/^(w3wp|httpd|apache2|nginx|php-fpm[0-9.]*|tomcat[0-9]*)(\.exe)?$/i
| FileName=/^(cmd|powershell|pwsh|bash|sh|dash|curl|wget)(\.exe)?$/i
| groupBy([aid, ComputerName, ParentBaseFileName, FileName], function=[count(as=Executions), collect([CommandLine, ParentProcessId, TargetProcessId], limit=10)], limit=100)
| head(limit=100)

C6：AIと断定せず操作間隔を記述する

信頼できるuser.idを含むCPSのWebログをFalcon NG-SIEMへ取り込む必要があり、端末センサーだけではHTTPパスを取得できません。0〜600秒の間隔だけを集計し、長い無操作時間は除外。分位点は補助情報であり、ARTEX共通の帯や自動封じ込めの判断ではありません。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Falcon NG-SIEM CPS web logs. REQUIRED time picker: last 1 hour.
// Profile only: no universal 2-25s or 25-31s AI threshold. Compare with the app's baseline and independent evidence.
// One source/app, principal required. Oldest 10,000 inputs retained; at most 100 groups.
#type="REPLACE_WITH_WEB_PARSER" source.ip="REPLACE_WITH_SOURCE_IP" url.domain="REPLACE_WITH_APP_HOST" user.id=* url.path=*
| sort(@timestamp, order=asc, limit=10000)
| t := @timestamp
| groupBy([source.ip, url.domain, user.id], function=neighbor(include=[t, url.path], prefix=prev), limit=max)
| GapSeconds := (t - prev.t) / 1000
| test(GapSeconds >= 0 and GapSeconds <= 600)
| groupBy([source.ip, url.domain, user.id], function=[count(as=Gaps), count(url.path, distinct=true, as=DistinctPaths), min(GapSeconds, as=MinGap), max(GapSeconds, as=MaxGap), percentile(field=GapSeconds, percentiles=[10,50,90])], limit=100)
| Gaps >= 20
| head(limit=100)

他の調査も結果を区別します。 S3は選んだ無効資格情報・ロック・不明アカウントの失敗を数え、すべてのMFA操作を失敗にはしません。S2・C3の報告済みマーカーは変更できます。S6・C4は共有コールバック先の接続・DNSの手がかりであり、持ち出しの証明ではありません。S5はHTTP処理ごとに一つのイベントと、端末から宛先へのSentBytesが必要。一定量の通信は正常なテレメトリーでも起きます。S7には独立した台帳が必要で、センサーが見たことのないホストをイベント検索だけで列挙できません。

Sentinelへ取り込むDefender表はTimeGenerated、Defender Advanced HuntingはTimestampです。Defender DeviceId、Falcon aid、クライアントAppId、テナントの主体オブジェクトIDを混同しません。C1・C5・C6には信頼できる主体が必要。対象IDがクエリにあればurl.pathだけでなく正確な対象キーを使い、POSTで作った対象はC1以外でLocation・対象IDを照合します。

自社ARTEXは実際の管理、タスク、出力、WebSocketの経路を台帳化し、プロキシ・認証監査を取得します。C7のCairn固有パスを、そのARTEX版の識別や保護の条件にはしません。

コピー用の運用テンプレート4本

記入済みのものは制限した案件用の保管先に置きます。秘密情報や顧客データの貼り付けではなく、証拠の参照を残します。

初動と証拠のカード

案件ID／対応責任者：
分岐：被害システム／自社ハーネス／両方
UTC：最も早い露出の可能性／最初の実証された影響／最後の観測
演習承認：担当／範囲／期限／確認記録
資産：テナント／主体オブジェクトID／ホスト／正確な対象／DeviceIdまたはaid
実証された影響：
評価と残る未確認点：
証拠参照／ハッシュ／保管制限／取得者：
封じ込めの権限／業務依存：
次の担当／次回報告UTC：

監視の合意と引き継ぎ

案件ID／監視ID／当番／通知先：
ソース／パーサー／既知の正常な確認イベント：
発生時刻の期間／取り込み遅延／許容する遅延：
対象：信頼できる主体／リソース／ホスト：
限定した検索期間／遅着の重なり／カーソルまたは重複排除キー：
入出力上限／未処理への対応／保持：
条件→確認者→承認された操作：
演習の例外：範囲／担当／期限：
収集停止への対応／次回確認UTC：

封じ込めの変更と確認

案件ID／制御担当／承認者／実施者：
対象：正確な経路／ホスト／主体／ジョブ：
操作UTC／変更記録／業務影響：
変更前の影響の証拠参照（非公開）：
操作／期待する拒否／安全な戻し条件：
新たな確認：対象側の結果／イベントID／UTC：
残るトークン／ジョブ／別経路：
依存先／受容したリスク／次の担当と確認UTC：

復旧条件と案件終了の引き継ぎ

案件ID／対応責任者／業務担当／独立した確認者：
侵入・認可の修復：版／経路／証拠：
永続化と露出秘密情報：範囲／除去・更新／古いアクセスの試験：
業務状態と許可された処理の試験：
管理下の拒否試験とバックエンド監査の参照：
収集の健全性／遅着／未処理分：
観察期間／担当／終了条件／再開トリガー：
残留リスク：担当／期限／明示した受容：
法的通知の判断／証拠保持／承認UTC：

出典とレビューの範囲

2026年11月4日レビュー。 作業の構成、判断、監視頻度、テンプレート、図は独自の運用上の整理です。NIST SP 800-61 Rev. 3の公開ページは対応ライフサイクルの一般的な参考であり、NIST公式の対応表や36判断の義務を示すものではありません。今回、そのページは環境のネットワーク方針により取得できませんでした。

  • 取得した一次情報： Unit 42の10月30日ARTEXノートはAPI・IDの試行と受理された変更を説明し、AI使用の行動上の評価には限界を示しています。JPCERT/CCの10月8日公開・23日更新の注意喚起は、API、JSP Webシェル、AI基盤の悪用を別の事例として整理しています。APIのケースBやJSPのケースDから、その事例のARTEX使用を特定することはできません。
  • ハントの出典： フレームワーク記事、固定版の上流確認、Microsoftの表定義、ダウンロード内のレビュー記録。一部の静的マーカーは同記事で説明した、サイト所有者提供のRST参考文に由来し、ARTEX全般で新たに実証した特徴ではありません。
  • クエリの限界： 再利用するZIPのKQL 7本はMicrosoft.Azure.Kusto.Language 12.4.1の構文解析を通過しましたが、ワークスペース項目の結合や検索実行ではありません。Falcon CQLは静的レビューのみです。本稿の例はSentinel・Falconの実テナントでは未実行であり、監視ルールや対応操作も導入していません。

本稿のためにコンソールへのアクセス、初期パスワードの試行、全世界検索、スキャン、攻撃基盤・マルウェアの実行は行っていません。検知率や確実な封じ込め時間も主張しません。運用前に許可された担当者と手順・クエリを検証してください。

関連手順：APIデータ漏えい、アカウント侵害、クラウドキー漏えい、委託先侵害。ホストの証拠はDFIR講座も参照してください。

プレイブック一覧へ →Read in English ↗