maintaining-engagement-state

エンゲージメント状態の維持

エンゲージメントは数週間に及びますが、セッションはそうではありません。この2つの事実の間にある空白では、作業が繰り返され、調査結果の証拠が失われ、認証情報の出所が追跡できなくなり、設置したことが記録されていないために本番環境に成果物が残されます。

これは、本来の作業に付け足された事務作業ではありません。**来歴があってこそ調査結果を報告でき、成果物台帳があってこそクリーンアップが可能になります。**どちらも、後からターミナルのスクロールバックを見ても再構築できません。

記録に書かれていないことはすべて失われると考えてください。単に忘れられるだけでなく、気づかれないまま失われるため、次のセッションで自信満々に作業をやり直したり、矛盾した作業を行ったりします。

使用する場面

• 1回の作業時間を超えて続くエンゲージメントや調査
• 休憩後に再開するとき、または他の人の作業を引き継ぐとき
• 記録されていない状態のままコンテキストの境界に近づいているとき
• アナリスト、シフト、チーム間で引き継ぐとき
• ターゲットに書き込みを行う処理を実行する前
• 「この認証情報はどのホストから取得したのか」に答えられないとき

使用しない場面

• クライアント向け成果物の作成 — reporting-security-findings を使用してください。このスキルは、そのスキルで使用する生の素材を作成します
• 調査結果が実在するかどうかの判断 — 該当するテストまたは分析スキルを使用し、結果はこちらに記録してください
• 裁判で提出される可能性のある証拠の管理連鎖 — 法的な管理にはこれ以外の正式な要件があります。responding-to-incidents を使用し、組織の顧問弁護士に従ってください
• 1回の作業時間内に完了し、ターゲット上に何も残さない、単独で完結するタスク

6つの記録

これらはリポジトリまたはケースフォルダー内の1つのファイルにまとめ、作業を進めながら更新してください。最後にまとめて再構築するのではありません。

1. スコープと承認

対象範囲内のターゲットと明示的な除外事項、テスト期間、指定連絡先、承認書の保存場所を記録します。除外事項は原文のままコピーしてください。スコープを言い換えることが、誤った環境をテストする原因になります。

さらに1つ項目を記録してください。「対象範囲内」と「到達可能」は別の問題だからです。エグレスモードは、このエンゲージメントで通信が許可されている対象を示します。

モード	許可	拒否
offline	静的解析、ローカルサンプル、エミュレーション	あらゆる送信パケット
lab_only	自分が管理するラボおよびVMの範囲	本番環境、ルーティング可能なものすべて
authorized_target_only	スコープに記載された資産	リストにないものすべて
unrestricted_lab	文書で許可された隔離ラボネットワーク	パブリックインターネット

最初のコマンドを実行する前にモードを指定してください。意図した以上の範囲に何かが到達した後ではいけません。この項目が防ぐのは、よくある2つのミスです。C2ドメインを名前解決してしまう「静的解析のみ」のマルウェアトリアージと、スキャナーが対象範囲外へリダイレクトをたどってしまう、スコープを限定したウェブテストです。このリポジトリのスキルで隔離ラボが必要とされる場合、lab_only か、それより厳しいモードを意味します。

承認はゲートであり、単なるメモではありません。承認が保留中または未取得の場合、ドキュメントの閲覧や計画は問題ありませんが、スキャン、フック、エクスプロイトは許可されません。

2. 認証情報の来歴

認証情報、ハッシュ、トークン、キーごとに、それが何か、どこから来たのか、どのように取得したのか、何に対して使用したのかを記録します。

cred-04  | svc_backup NTLM hash
         | source: SAM dump, WS-014 (10.2.3.14), local admin via CVE-2021-XXXX
         | obtained: 2026-07-27 14:02
         | used on: FS-02 (success), DC-01 (failed, no local admin)
         | provenance: CONFIRMED

来歴は単なる事務処理ではありません。必ず尋ねられる3つの質問に答えるためのものです。

• 本物ですか？ 出所不明の認証情報は仕込まれたものかもしれません。recognizing-deception を参照してください。出所を説明できなければ、その可能性を排除できません。
• スコープ内のものでしたか？ スコープ外のホストから収集した認証情報で到達したものは、すべて汚染されます。
• 影響範囲はどこまでですか？ クライアントが求める是正措置は「これらの特定のシークレットをローテーションすること」です。そのためには一覧が必要です。

追跡できないものには provenance: UNKNOWN と記し、ひそかに使用するのではなく、疑わしいものとして扱ってください。

3. アクセス一覧

取得したアクセスごとに、ホスト、アカウント、権限レベル、方法、そして現在も使えるかどうかを記録します。アクセスは時間とともに失効します。セッションは切れ、パスワードは変更され、ホストは再起動します。持っていたものの一覧は、現在持っているものの一覧ではありません。

4. 成果物台帳 — クリーンアップリスト

対象に対して行ったすべての書き込みを、実行した時点で記録します。 配置したファイル、作成したサービスやタスク、追加したアカウント、レジストリキー、共有、ファイアウォールルール、クラウドリソース、設定の編集などです。

art-07 | WS-014 | C:\Windows\Temp\c2.exe        | dropped 14:02 | REMOVED 18:40
art-08 | DC-01  | scheduled task "WinUpdateSvc" | created 15:10 | PENDING
art-09 | AWS    | IAM user "svc-audit-tmp"      | created 16:22 | PENDING

後から記憶を頼りに作成したリストは、必ず不完全になります。記載漏れしたものは、クライアントの本番環境に残されます。このリストを必要とする関係者は2者います。クリーンアップに使うあなたと、エンゲージメント中および終了後にあなたの成果物と実際の侵入を見分けるクライアントのブルーチームです。

インシデント調査では、同じ台帳に証拠システム上であなたが触れたものも記録することで、あなたの活動を攻撃者の活動と区別できます。

5. 証拠を伴う調査結果

各調査結果について、内容、場所、再現手順、取得した証拠、実証した影響を記録します。証拠は発見した時点で取得してください。それを裏付けた状態は、修復、再起動、または認証情報の変更後には残りません。

6. 行き止まり

最も記録が省かれがちで、セッションをまたいで最も価値のある記録です。何を、何に対して試し、なぜ失敗したかを記録します。

dead-03 | Kerberoast svc_sql | hash cracked? NO after 6h, 14M candidates
dead-04 | SMB signing DC-02  | enforced -- relay not viable
dead-05 | /admin on portal   | 403 from all tested source ranges

これがなければ、次のセッションで6時間かけたクラックをやり直すことになります。否定的な結果を記録することは、最終レポートで「そこには何も見つからなかった」と「調べていない」の違いにもなります。

セッション境界の管理

セッション終了前には、予定どおりの場合もそうでない場合も、記録で次の質問に答えられるようにしておく必要があります。

1. 現在どのアクセス権を持っていて、今も使えますか？
2. まだクリーンアップしていないものを、対象に何か残していますか？
3. 何の作業中でしたか？
4. 他の人が繰り返さないように、何を候補から除外しましたか？

これらは作業しながら記録し、最後にまとめて書かないでください。予期せず終了するセッションこそ、状態が記録されていないセッションです。エンゲージメントの文脈は予告なく失われることがあります。

引き継ぎ

引き継ぎには、同じ記録に加えて、現在の状況、直ちに行う次のアクション、時間制限のある事項（実行中のクラック、期限切れが近いトークン、02:00に実行されるスケジュール済みタスクなど）の3点を記載します。引き継ぎを受けたアナリストが「何をしていたのですか？」と尋ねなければならないなら、引き継ぎは失敗です。

エンゲージメントをまたいで

6つの記録は、エンゲージメントごとにリセットされます。その間で引き継ぐ価値のあるものが2つありますが、どちらも同じ失敗を招きます。記憶から再構成すると、内容が間違ってしまいます。

マシンが実際にできること。 スキルがツールを実行する前に、そのツールが既知のパスに存在し、スキルが想定するフラグに一致するバージョンでなければなりません。/usr/bin/ghidra や jadx の場所を推測し、失敗を対象側の問題としてデバッグするのは、1時間を無駄にするよくある方法です。ツール、実際のパス、バージョンを記載した、マシンごとのローカルなインベントリを管理してください。また、ソケット経由で通信するもの（MCP サーバーやヘルパーデーモン）については、単にインストールされているだけでなく、登録され、応答しているかどうかも記録します。存在している状態と、すぐに使える状態は異なります。ディスク上に MCP バイナリがあっても、サーバーが起動していなければ機能ではありません。このインベントリはマシンごとのもので、共有リポジトリに含めるものではありません。~/.ssh/config と同じように扱ってください。自分だけのものとして、Git の追跡対象から除外し、公開するものからは参照されないようにします。

過去の事例から学んだこと。 完了した事例ごとに、シナリオ、効果のあった手法、行き詰まった点とそれに費やした時間、ツールに関する予想外の出来事を、短く匿名化した記録として残します。次の類似事例は、何もない状態からではなく、記録を検索するところから始められます。シナリオ、手法、対象の特性ごとに記録のインデックスを作り、新しい作業を始める前に記録そのものではなく、まずそのインデックスを読みます。インデックスを作る手間はわずかです。参考用の実例をいくつか登録しておけば、10件目のエンゲージメントを終える前から役立ちます。

記録を安全に保つには、2つの規律が必要です。共有する前ではなく、記録する時点で匿名化すること。実際のドメイン、IP アドレス、トークン、個人識別情報（PII）は、記録を書く時点でプレースホルダーに置き換えます。外部に出すつもりのない記録も、万が一外部に漏れてしまったときに情報が漏えいしないようにします。また、デフォルトではローカルに保管すること。教訓を共有または公開された場所に提供すれば、エンゲージメントの詳細を第三者に渡すことになります。「モデルが匿名化してくれた」は、クライアントに説明できる管理策ではありません。記録を共有する場合は、ワークフローのデフォルトの手順ではなく、記録ごとに意図的に判断し、レビューを行ったうえで決めてください。

退けるべき言い訳

• 「どこから得た情報か覚えている。」 覚えていませんし、次のセッションでも覚えていません。出所を特定できない認証情報は、レポートに使用できず、仕込まれた認証情報とも見分けがつきません。
• 「すべてターミナルの履歴にある。」 履歴には推論も、信頼できるタイムスタンプも、失敗の記録も、導き出した結論もありません。また、セッションが終了すると、よく失われます。
• 「最後にクリーンアップの一覧を書く。」 記憶が最も曖昧になり、一覧が最も長くなるのは、まさに最後です。記憶を頼りに作成した記録は必ず不完全で、抜け漏れは本番環境に残り続けます。
• 「行き詰まった点など誰も必要としていない。」 それは、報告済みの否定的な結果と、調査されていない見落としとの違いです。また、次のセッションで同じハッシュの解析に6時間を費やすのを防ぎます。
• 「作業しながら片付けるので、台帳は不要だ。」 それなら、成果物ごとに1行記録するだけで済み、台帳が役に立つことも証明できます。台帳がなければ、環境を元の状態に戻したことを証明できません。
• 「クライアントが知りたいのは発見事項だけだ。」 来月アラートが発生し、作成したアカウントが自分のものだったかを確認する必要が出るまでは、そうでしょう。所有者不明の成果物は、侵入として調査されます。
• 「失敗を記録すると、エンゲージメントの印象が悪くなる。」 否定的な結果が記録されていないエンゲージメントは、成功したのではなく、手法が不十分だったように見えます。カバレッジも発見事項の一つです。

参考資料

• reporting-security-findings — この記録を使って、成果物を作成します
• recognizing-deception — 出所を特定できない認証情報が、単に整理されていないだけでなく危険である理由
• responding-to-incidents — 正式な証拠取り扱いを含む、調査側の同等資料