mid-engagement-ir-detection

このスキルを使用するタイミング

次の場合に使用します。

• SOC による監視が有効なターゲットに対して、アクティブテストを実施している
• 脆弱性が確認された検出結果が、再確認時に再現しなくなった
• ベースラインのタイミングが予期せず変化した（3 倍遅くなる、突然のエラー、新しいヘッダーなど）
• テスト期間ごとにレスポンスサイズが変わる
• セッション開始時にはなかった WAF Cookie やヘッダーが新たに現れる
• テスト期間ごとにロックアウト率／エラー率が変わる（特に、認証情報攻撃の LOCKED 件数）
• エンゲージメントが「侵害を前提とする」または「ホワイトボックス」であり、クライアントがテストを把握している

次の場合は使用しないでください。

• バグバウンティ（クライアントはあなたが活動していることを知らず、リアルタイムの IR もありません）
• 純粋な偵察（状態変化が発生しない）
• 単発の脆弱性スキャン（時間的な側面がありません）

---

中核となる洞察

有能な SOC が稼働する実際のレッドチームエンゲージメントでは、ターゲットのセキュリティ状態は静的ではありません。テスト中のトラフィックに応じて変化します。こうした状態変化は、次のとおりです。

1. それ自体が価値ある検出結果（IR の対応力に関する肯定的な運用上の観察）
2. 確認の証拠（エンゲージメント中のパッチ適用は、元の脆弱性が実在した証拠）
3. 分類のシグナル（WAF ルールの導入とコード修正では、修正の深さが異なります）

アンチパターン：再現に失敗したことを、元のシグナルが誤検知だった証拠として扱うこと。変更前に取得した元の PoC のアーティファクトも、依然として脆弱性の検出結果です。

---

手順 — 変更前に取得し、その後に差分を確認する

アクティブテストの前に：

# Capture pre-test fingerprint of the target
fingerprint = {
    "ts_pre": time.time(),
    "ip_seen": "<operator-src-ip>",
    "baseline_response_time_ms": <measure>,
    "baseline_response_size_bytes": <measure>,
    "response_headers": <capture set>,
    "waf_cookies": <list>,
    "lockout_count_in_state": <count from o365_attempts.json>,
}

engagement_log/fingerprint_pre.json に保存します。

テスト中：

各テスト結果を、完全なコンテキスト（タイムスタンプ、IP、ペイロード、レスポンスコード、レスポンスサイズ、レスポンス時間、関連する場合はヘッダー）とともに、追記専用の JSONL に記録します。

テストセッション終了後、または再確認で初めて失敗した時点で：

fingerprint_post = same structure
delta = {
    "baseline_time_change_ms": post.time - pre.time,
    "baseline_size_change_bytes": post.size - pre.size,
    "new_headers_appeared": post.headers - pre.headers,
    "new_waf_cookies": post.cookies - pre.cookies,
    "new_lockouts": post.locked_count - pre.locked_count,
}

重要な差分があれば、取り消すのではなく、調査してください。

---

主な 3 つの IR 観察事項

観察事項 1 — エンゲージメント中の WAF ルール導入

症状：

• 元のペイロードに対するレスポンスが同一で、再確認時にシグナルがまったくない
• ボディサイズがベースラインと同一（ログインページのリフレクション）
• ペイロードに関係なく、タイミングがベースラインに戻る
• レスポンスに新しい Cookie またはヘッダーがある（例：cf-bm、__cf_bm、awselb）
• URL／ボディ内の特定のキーワードが、異なるレスポンスコード（403、406、429）を引き起こすようになった

確認方法： WAF 回避バリアントを使って再試行します。

• ペイロードの URL エンコード方法を変える（%27 と %5cu0027 など）
• リクエストメソッドを変える（POST → PUT、GET → POST）
• Content-Type を変える（form-urlencoded → multipart）
• リクエスト間隔を長くする（5s → 60s）
• キーワードの大文字と小文字を混在させる（SLEEP → SlEeP）

WAF 回避バリアントでシグナルが再び現れる場合、緩和策は WAF 層にあります（回避可能）。

WAF 回避バリアントでもブロックされる場合、緩和策はコード内にある可能性が高いです。

検出結果のテンプレート：

Subject: Mid-engagement mitigation deployed for <vulnerability X>
Observation: At engagement timestamp T0, vulnerability <X> on <endpoint> was
confirmed via <PoC>. At T0+<minutes>, recheck via the original payload no longer
reproduces the timing/error/size differential. <WAF-evasion variant> [does/does
not] restore the signal.

Description: This pattern is consistent with the client SOC observing engagement
traffic and deploying a mitigation in real time. Mitigation depth assessment:
[at-WAF, bypassable] vs [in-code, durable].

Impact (positive): Client SOC has both detection-grade visibility into application
traffic AND the authority to deploy mitigations within ~<minutes> of detection.

Impact (caveat): The original vulnerability did exist and was exploitable for at
least the engagement window before mitigation. If the mitigation is at the WAF
layer only, the underlying code-level flaw remains exploitable via alternative
payloads.

Recommendation:
1. Verify the mitigation is in code (parameterized queries, input sanitization),
   not just at the WAF layer.
2. Audit the codebase for the same root cause across sister applications.
3. (Positive) Document the IR responsiveness as a capability metric.

観察 2 — 同時進行中の攻撃者

症状：

• 1 ユーザーにつき 1 回の試行というルールを守っているにもかかわらず、AADSTS50053（LOCKED）の応答が多数返される
• ロックアウトがアルファベット順、または別のソートキーに沿って集中している
• エンゲージメント中に新たなロックアウトが発生する（実施前後の差分）
• LOCKED の割合が想定ベースラインを超えている（今回のエンゲージメントでは全試行の 11％ → 危険信号）

計算による確認：

• あなたのルール：ユーザー 1 人につき、そのユーザーの生涯で 1 回だけ試行
• Smart Lockout の既定値：失敗した試行が 10 回に達するとロックアウトされ、ロックアウト期間は 60 秒から始まり、その後のロックアウトごとに延長される（固定の 10 分間ではありません）
• したがって、ツールのログでユーザーごとに試行が正確に 1 回であること（バースト再試行、並列 goroutine による重複送信、ツールの設定ミスがないこと）が確認できれば、数学的に Smart Lockout を引き起こすことはありません — 断定する前に、journal.jsonl でユーザーごとの試行が 1 回であることを確認してください
• したがって、期間中に蓄積した新たな AADSTS50053（実施前後の差分による）はすべて他者が引き起こしたものです。既存のロックは正規ユーザー自身の失敗、または以前のテスト実行による可能性があるため、外部の第三者によるものと判断するのは、新たに蓄積したロックに限ってください

確認方法：

• ロックされたアカウントをアルファベット順に並べ、まとまっている場合は、攻撃者がソート済みのユーザー名リストを使用しています
• セッション開始前と終了後のロックアウト件数を比較します — セッション中に新しいロックが発生していれば、攻撃者は「今まさに」活動中です
• 既知のアクティブな「システム」アカウント（noreply@、info@、oc@）をプローブします — ロックされている場合、攻撃者はサービスメールボックスにも攻撃を仕掛けています（通常は MFA が免除されているため、攻撃者にとって価値が高いアカウントです）

所見テンプレート：

Subject: Active external password-spray campaign detected during engagement

Observation: During M365 ROPC validation against the <tenant> Entra tenant, <N>
unique principals returned AADSTS50053 (Smart Lockout) when probed with a single
password attempt at safe pace. Our tool journal (journal.jsonl) confirms exactly
1 attempt per user with no duplicate sends, so under the Smart Lockout default
(lockout after 10 failed attempts) we cannot have caused these lockouts. The
attribution below applies to the <K> NEW locks that accumulated during our
engagement window between <timestamp_start> and <timestamp_end> (per before/after
diff); pre-existing locks are not attributed to this campaign.

Description: The pattern (alphabetical clustering, real-time accumulation,
including system mailboxes) is consistent with an external attacker performing
a username-list-driven password spray attack against the tenant.

Impact: An external adversary is actively attempting to compromise corporate
M365 accounts. The attacker has knowledge of the user-email schema and a
password-guess wordlist. <List of locked accounts is now in attacker's hands>
(Smart Lockout differentiates valid from invalid usernames).

Recommendation (CRITICAL — within 24h):
1. Open a P1 incident with the SOC. Pull Entra sign-in logs for the <N> locked
   accounts over the last 30-60 days. Identify source IPs and time windows.
2. Apply Conditional Access rule blocking sign-ins from outside <expected geo>
   for non-admin accounts.
3. Enable Identity Protection's User Risk policy with auto-reset on high risk.
4. Force tenant-wide password reset for all <N> previously-locked accounts.
5. Audit service accounts for MFA exemptions; ensure all human-interactive
   accounts have phishing-resistant MFA.

Evidence: engagement_log/poc/m365/locked_accounts.txt (<N> entries with timestamps)

観察 3 — 検知に起因するレート制限／IP ブロック

症状：

• 通常の応答が続いた後、特定の IP からの応答が 403／429／451 になる
• 特定の IP で応答が大幅に遅くなる（ベースラインの 3 倍以上）
• TLS ハンドシェイクが失敗する、または接続中に RST が発生する
• 以前は名前解決できていたホストに対して、DNS が突然 NXDOMAIN を返す
• ある IP からは一部のホストにアクセスできるが、別の IP からはアクセスできない

確認方法：

• 別の IP に切り替えて再試行します — 動作する場合は、レート制限またはブロックされています
• DNS 応答の TTL を比較します — TTL が突然短くなった場合は、アクティブな緩和策が導入されています
• CDN によって導入された制限がないか、Server:、Via:、CF-Cache-Status: ヘッダーを確認します

所見テンプレート（運用上の注記。通常は低／情報レベルの重大度）：

Subject: Engagement traffic detected — IP <X> rate-limited at <timestamp>

Observation: After ~<N> requests in <window> from IP <X>, target <hostname>
began returning <code> for all subsequent requests. Rotation to IP <Y>
restored normal responses.

Description: Active anti-automation control at the perimeter (CDN/WAF/origin).

Impact (positive): Volumetric anti-automation is functional.

Impact (caveat): Rotation defeats this control trivially (cloud VMs cost <$5).
A patient adversary or spray-from-residential-proxies attacker is not affected.

---

状態差分 — 重要な手法

次の 3 つの状態を維持します。

1. engagement_log/baseline.json — セッション開始時に取得

{
  "ts": "2026-05-08T13:00:00",
  "source_ip": "<operator-src-ip>",
  "targets": {
    "https://target.example.com/login": {
      "baseline_response_time_ms": 584,
      "baseline_response_size_bytes": 11966,
      "headers_seen": ["Server: Apache", "X-Powered-By: PHP/8.0.26"],
      "set_cookie_names": ["PHPSESSID"]
    }
  },
  "m365": {
    "lockout_count": 247,
    "valid_creds_count": 0
  }
}

2. engagement_log/journal.jsonl — 追記専用のテストログ

各テストで次の内容を記録します。

{"ts":"...","ip":"...","tool":"...","target":"...","payload":"...","resp_code":...,"resp_size":...,"resp_ms":...,"verdict":"...","notes":"..."}

3. engagement_log/state_changes.jsonl — 観測された差分

状態の変化を検知したら、次の内容を追記します。

{"ts_observed":"2026-05-08T14:30:00","change_type":"baseline_time_shift","target":"https://<employee-app-host>/<app>/login.php","baseline_pre_ms":24412,"baseline_post_ms":90403,"interpretation":"likely WAF rule deployed","actions_taken":["tested WAF-evasion variants — no signal restoration","documented as IR-mitigation finding"]}

この 3 つ目のファイルが、所見の証拠となります。すべてのエントリが所見候補です。

---

ツール — 状態変化の自動検知

# Bash watcher — runs every 5 min during engagement, alerts on shifts

cd "$ENGAGEMENT_DIR"

# Re-measure baseline timing on key targets
for target in "$@"; do
  ms=$(curl -sk -o /dev/null -w "%{time_total}" "$target" --max-time 30)
  ms_int=$(echo "$ms * 1000" | bc | cut -d. -f1)
  echo "$(date -u +%FT%TZ) $target $ms_int" >> baseline_history.log
done

# Diff against pre-session baseline
python3 - << 'PY'
import json, time
baseline = json.load(open("engagement_log/baseline.json"))
for line in open("baseline_history.log"):
    parts = line.strip().split()
    ts, target, ms = parts[0], parts[1], int(parts[2])
    if target in baseline["targets"]:
        pre = baseline["targets"][target]["baseline_response_time_ms"]
        if abs(ms - pre) > pre * 0.5:  # >50% shift
            print(f"ALERT {ts} {target} time {pre} -> {ms}")
PY

M365 でのロックアウト件数の追跡について：

# Run every 30 min during M365 spray
LOCK_COUNT=$(grep -c '"AADSTS50053"' engagement_log/o365_results.jsonl)
echo "$(date -u +%FT%TZ) lockout_count $LOCK_COUNT" >> lockout_history.log
# Diff first vs last to surface delta

---

「単一シグナル撤回」ルール

脆弱性が確認された所見が再現しなくなった場合：

1. 元の PoC は削除しないでください。 元のタイムスタンプ、ペイロード、応答キャプチャは永久に残します。
2. 新しい状態を詳細に記録してください。 再確認時の応答はどうなっていますか？ 何が変わっていますか？
3. 「判定不能」とする前に、少なくとも 3 つの別のベクターを試してください。
4. どれもシグナルを回復できない場合、「T0 時点で脆弱性を確認、T0+ 時点で緩和策を確認、緩和の深度：[WAF | code]」として記録してください。
5. 両方の状態をレポートに記載します。 元の所見と IR の観察結果の両方です。

この規律によって、「趣味のスキャン」とプロフェッショナルなレッドチーム活動が区別されます。クライアントが求めているのは、脆弱性と緩和策のタイムラインであり、静的な状態だけではありません。

---

これが所見となる理由 (クライアントへの提案)

クライアントに「14:24 に SQLi を確認し、14:55 までに対策がデプロイされました。これが元の PoC であり、修正がコードに入っているかを今なお検証すべき理由はこちらです」と伝えるとき:

• 脆弱性が存在したことを確認した (監査人グレードの証拠)
• 対策がデプロイされたことを確認した (SOC にとってポジティブな運用上の所見)
• 深さの問いを特定した (WAF かコードか — 修復コストが異なる)
• レッドチームの価値を示した (バグと IR の対応力の両方を証明した)

これは「SQLi を確認した」だけよりも価値の高い成果物です。なぜなら、エンゲージメントの運用面の全体像を捉えているからです。

---

避けるべきアンチパターン

• 「再チェックが失敗 → 誤検知。」 いいえ。再チェックが失敗したのはターゲットが変わったからです。その変化を調査してください。
• 「もう脆弱ではないので、所見を破棄する。」 いいえ。脆弱でした。所見は残ります。「現在の状態: 緩和済み」という注記を追加してください。
• 「彼らがパッチを当てた、任務完了。」 いいえ。WAF ルール != コード修正。深さを検証してください。
• 「彼らのパッチを観測したことをクライアントに伝えない。」 いいえ、伝えてください。これは彼らの IR に関するポジティブな所見です。
• 「ロックされたアカウントのリストを含めない — 我々が引き起こしたと思うだろう。」 いいえ。計算とジャーナリングの規律が、あなたが引き起こしていないことを証明します。計算とともにリストを含めてください。

---

隣接スキルへの橋渡し

• redteam-mindset — より広い規律のフレームワーク。このスキルはその具体的な適用例です
• m365-entra-attack — M365 / Smart Lockout の差分に関する具体的なケース
• evidence-hygiene — PoC 証拠を適切に取得し墨消しする方法
• report-writing — IR 観測のための所見テンプレート
• bb-methodology — このスキルはバグバウンティには不適切であることに注意 (そこにはリアルタイムの IR がありません)

---

一行まとめ

あなたのエンゲージメントは足跡を残します。その足跡はターゲットを変えます。両方の状態を捉えてください。どちらも所見です。

---

関連スキルとチェーン

• redteam-mindset — このスキルは、より広いレッドチーム規律の具体的な適用例です。エンゲージメントの流れ: エンゲージメント開始時に redteam-mindset をロード → ベースライン取得の習慣を組み込む → テスト中に応答パターンが変化したら、mid-engagement-ir-detection が起動して SOC パッチ状態を新たな所見として捉える (防御アクションの観測 = クライアント能力の指標であり、「バグが修正されたので所見を失う」ということではありません)。
• evidence-hygiene — エンゲージメント中の IR 検出は 2 つの状態 (パッチ前とパッチ後) を生みます。両方とも規律ある証拠取得が必要で、そうでなければ 2 つ目の所見を擁護できません。エンゲージメントの流れ: セッション開始時にベースラインのスクリーンショット + タイムスタンプ付きのリクエスト/レスポンスダンプ → 応答の変化を検出 → 明示的なタイムスタンプ差分を伴う 2 回目の取得セット → 両方をまとめてパッケージ化。
• m365-entra-attack — 現代のエンゲージメントにおいて、エンゲージメント中の IR シグナルの最も豊富な単一ソースです。エンゲージメントの流れ: M365 スプレーが AADSTS50053 ロックアウトを誘発 → ベースラインのロックアウトポリシーを取得 → テスト中にロックアウトウィンドウが変化した場合 (例: 60 分から 24 時間へ)、mid-engagement-ir-detection がポリシー変更を所見として捉える (「エンゲージメント中に CA ポリシーが強化された。防御対応を測定」)。
• enterprise-vpn-attack + vmware-vcenter-attack — 重要インフラの CVE 悪用は最もノイズの多い活動です。SOC が数時間以内にパッチを当てることを想定してください。エンゲージメントの流れ: VPN/vCenter の CVE を確認 → 悪用試行の前にベースラインを取得 → テスト中にアプライアンスが更新されたら、防御アクションの所見として捉える → 元の CVE と IR 対応の両方を報告する。
• redteam-report-template — IR 観測の所見は、成果物内で独自の Subject を持ち、技術的脆弱性の所見とは異なる枠組みで提示されます。エンゲージメントの流れ: mid-engagement-ir-detection が行動変化イベントを捉える → triage-validation の 7-Question Gate (具体的には:「この行動変化は自分の活動に起因するか?」) → redteam-report-template が明示的なタイムラインと検出レイテンシ指標を伴う「クライアント能力の観測」としてパッケージ化。