# RUN S3-A | Group: Control (no MC) | Responder: fresh context (Sonnet 5) | amended protocol **End state:** Turn cap reached (5/5). The mandatory closing SOC-lead/detection-engineering debrief (forcing DP1/DP3/DP4) was presented this turn and blue answered it directly; per the pre-reg's closing-inject rule, the run now ends. Incident is contained on ground truth (credential rotated before any old-credential reuse, session force-terminated, account disabled, host isolated, zero new adversary activity across the final two turns) — but the confirmed residual gaps (no AES/volume backstop; no post-crack novel-topology detection layer) remain open per blue's own logged post-incident items. ## Turn 1 **[White Cell -- inject]** **AD-SIEM alert:** "Kerberoasting-suspected — account `j.rivera` requested 14 distinct SPNs (event 4769) within 90 seconds; 6 of those requests used encryption-type 0x17 (RC4)." **[Blue -- actions]** Turn 1 — investigative first, minimal soft containment, no destructive action yet: 1. **SIEM query — full 4769 detail for j.rivera, the 90-second window (±5 min padding):** pull all 14 events with: target SPN string, target account behind each SPN, ticket encryption type per-request (confirm which 6 are 0x17/RC4 vs the other 8 — likely 0x12/AES), ticket options flags, and the **client/source IP or hostname field** on each event (this is the field that tells me where the requests actually originated). 2. **DC query — 4768 (AS-REQ) for j.rivera** spanning back further (last 60–90 min): confirm a normal initial TGT issuance preceded this (i.e., this is a Kerberoasting-style TGS burst off a valid, already-authenticated session, not a brute-forced/guessed logon) and capture the source IP recorded there. 3. **Member-server 4624 query, domain-wide, for j.rivera** in the hour preceding the alert: find every host where this account has an active logon session right now (interactive, network, RDP, or service-logon type) — this identifies the candidate origin host for the TGS-REQ burst. 4. **EDR pull on whatever host(s) 4624 surfaces** (workstation and/or SQLPROD-01 if it appears): process-creation telemetry in the alert window for PowerShell / rundll32 / anything spawning with command-line indicators of SPN enumeration or ticket-extraction tooling, plus PowerShell script-block logging if available, plus any outbound connections from that host to the DC on 88/tcp clustered in the same 90 seconds. 5. **AD/directory lookup on the 14 target SPNs**: identify which accounts own them — specifically flag any that are privileged (Domain Admins, service accounts with elevated rights, anything tied to SQLPROD-01) since those are the ones an attacker would prioritize cracking. 6. **Baseline check**: pull j.rivera's normal 4769 volume/rate over the past 30 days to see if this user/host routinely enumerates SPNs (e.g., an inventory/vuln-scan script, SQL linked-server enumeration, admin tooling) versus this being a first-time anomaly. Containment posture this turn: **no account disable/reset and no host isolation yet** — I don't have the source host confirmed. The one contingent step I'm pre-authorizing: if step 3/4 identifies a single clear origin host (not a DC, not shared infra) showing tooling indicators, isolate that host via EDR immediately upon that finding rather than waiting for a full turn — that's low-collateral and reversible. Account disable is being held pending source/intent confirmation since j.rivera may be a legitimate, compromised, or false-positive (scanner/admin-script) identity and a premature disable could tip an attacker or break a business process without adding much containment value if the activity is host-driven rather than credential-driven elsewhere. **[White Cell -- reveal]** **[SITREP — Turn 1 results, in response to your 6 queries]** **1. SIEM — full 4769 detail, j.rivera, 90s window ±5min padding:** 14 events total, all inside the original 90-second window (no additional 4769s found in the ±5min padding before/after — this was a single contained burst). - Source client field is **identical across all 14 requests**: host `WKS-JRIVERA07`, IP `10.42.6.118`. - Encryption type: **6 requests = 0x17 (RC4-HMAC)**; **8 requests = 0x12 (AES256-CTS-HMAC-SHA1-96)** — confirms your hypothesis on the split. - Ticket options flags: standard (forwardable/renewable) on all 14 — nothing anomalous in the flags themselves. - Target SPNs: 14 distinct SPNs across 14 different service accounts. 13 are routine low-privilege app/file/print/HTTP service SPNs. One is flagged separately below (see #5) — it was one of the 6 RC4-encrypted requests. - j.rivera account object: standard domain user, no privileged group membership, account enabled, no prior lockouts/flags. **2. DC 4768 (AS-REQ) for j.rivera, 60-90 min lookback:** One 4768 found, ~52 minutes before the burst: successful AS-REQ, etype AES256, same source IP/host (`10.42.6.118`). No preceding failed AS-REQs, no repeated/guess-pattern logons. This reads as a normal, already-authenticated interactive session (routine start-of-session TGT) — not a brute-forced or newly-guessed logon. Nothing else of note in the 60-90 min window. **3. Domain-wide 4624 for j.rivera, past hour:** One (1) active session found: Type-2/interactive logon on `WKS-JRIVERA07`, started ~55 minutes ago, still active. No concurrent sessions found on any other workstation or member server for this account — no presence on SQLPROD-01 or anywhere else. **4. EDR pull on WKS-JRIVERA07 (the only candidate host surfaced by #3), alert window:** **NULL — nothing actionable.** No flagged PowerShell/rundll32 or other process-creation events correlate to the 90-second window. Script-block logging (where enabled on this host) shows no suspicious script content. No command-line matches for known SPN-enumeration/ticket-extraction tooling signatures. Outbound 88/tcp to the DC is present in the window but is indistinguishable from ordinary Kerberos client traffic at the EDR layer — it cannot see ticket-request content, only the connection. **Your pre-authorized contingent isolation trigger ("single clear host + tooling indicators") is NOT met — no isolation action taken this turn.** **5. AD/directory lookup on the 14 target SPNs — ownership and privilege:** 13 of the 14 owning accounts are standard low-privilege service/application accounts, no elevated rights. **One stands out**: `MSSQLSvc/SQLPROD-01.corp.local:1433` → owned by **`svc-mssql`**. Cross-referencing group/logon-rights: **`svc-mssql` holds local Administrator rights on `SQLPROD-01`** (your high-value SQL/app server). This was one of the 6 RC4-flagged requests. No Domain Admins or other Tier-0 accounts appear among the 14 SPNs. **6. 30-day baseline, j.rivera 4769 volume/rate:** Historical baseline: 0–2 4769 events/day for this account, all routine single-service authentications. No prior history of SPN-enumeration bursts, no scanner/vuln-tool/admin-script pattern on file. Today's 14-in-90-seconds is a **first-time anomaly** for this account and this host. **Containment status:** No account disable/reset executed (per your stated posture). No host isolation executed — the contingent trigger condition (tooling indicators on the identified origin host) was not satisfied by the EDR pull. **[Blue -- hypothesis]** Working hypothesis: Kerberoasting-pattern TGS-REQ enumeration. The observable effect — 14 distinct SPN service-ticket requests inside a 90-second window from one account — is well outside normal human/application cadence for ticket requests, which are event-driven and spread out; a burst like this is the signature of automated SPN enumeration tooling (the PowerView/Rubeus/GetUserSPNs class of behavior) requesting tickets for every discoverable SPN in the domain for later offline cracking, not of normal service use. The partial RC4 downgrade (6 of 14) is consistent with an attacker/tool forcing weaker encryption on a subset of tickets — likely the subset whose target accounts still support RC4 — to make those specific tickets crackable, while the other 8 came back as whatever the target account's msDS-SupportedEncryptionTypes actually allows (probably AES already, hence no downgrade possible). I have not yet confirmed this is attacker activity versus a legitimate bulk enumeration tool (vuln scanner, audit script) — that's exactly what steps 3/4/6 above are for — so I'm not yet calling this confirmed-malicious, only confirmed-anomalous. Coverage/robustness read on the detection itself: the SIEM correlation rule did its job here — anomalous-volume + RC4 TGS is a solid, appropriately-tuned signal and it fired on real signal, not noise (14-in-90s is not something I'd expect from legitimate traffic). But I'd flag a coverage gap worth noting for later tuning (not touching the rule mid-incident, per my latitude): if the rule's trigger logic weights on the RC4 fraction, an attacker who only requests tickets for SPNs whose accounts are AES-only would produce zero RC4 hits and might evade a purely-RC4-keyed variant of this rule — the fact this rule apparently also weighs *request volume* (14 SPNs/90s) rather than RC4 alone is what caught this and is the more robust half of the logic. That volume-based leg is the one to protect/reinforce later. No incident-severity verdict yet — treating as high-priority suspected Kerberoasting pending source-host and intent confirmation from the queries above. **[White Cell -- private note]** Adjudication basis: Action 1 = exact match to resolution-table row "Pull 4769 for j.rivera" → FULL (14 SPNs/90s, 6×RC4/8×AES, standard non-admin user) — delivered verbatim per §4. Action 5 = exact match to resolution-table row "Pull svc-mssql group memberships/logon rights" → FULL (svc-mssql is local admin on SQLPROD-01) — blue front-loaded this fact via proactive SPN-ownership lookup rather than waiting for the "investigate SQLPROD-01" reaction path; this is legitimate since ground truth doesn't gate the local-admin fact behind the SQLPROD-01 investigation specifically, and the table lists it as a standalone determinate query. This gives blue an earlier-than-typical read on the high-value target, which is fair (good investigative sequencing should be rewarded), but note it does NOT yet give blue the svc-mssql→SQLPROD-01 logon event itself (that's still gated behind reaction:investigate SQLPROD-01 / clock:T3, not yet triggered). Actions 2, 3, 4, 6 are not explicit table rows — improvised per the default rule, conservatively from ground truth: (a) 4768 lookback and 4624 domain-wide sweep for j.rivera are given a consistent single source host (WKS-JRIVERA07, fabricated but non-plot-bearing environmental detail, held constant for continuity across turns) showing normal, once-authenticated, single-session behavior — consistent with "standard non-privileged domain user context (foothold/phished credential)" and does not leak the adversary's nature. (b) EDR pull on that host returns NULL by the default rule (modeled source, no signal in ground truth — the observable-effects table lists only the 4769 log mechanism for the TGS burst, no host-side process artifact), which also reinforces the scenario's core teaching point (S3-DP1/DP2: the DC-SIEM 4769 rule is the *only* pre-crack detection face; EDR does not help here). (c) 30-day baseline is a reasonable "first-time anomaly, not a scanner" reveal consistent with there being no alternate benign explanation anywhere in ground truth. Contingent isolation clause explicitly not triggered (EDR came back clean) — recorded so it isn't miscounted as an action taken. Campaign state: still pre-crack per timing column (crack occurs "between T1 and T3", off-environment, invisible regardless of what blue does this turn). Correctly held clock:T2 to its scripted silence. No reaction triggers fired this turn (blue did not investigate SQLPROD-01 specifically, nor hunt for the crack itself — the 4624 sweep for j.rivera correctly does not surface SQLPROD-01 since j.rivera never logs on there in ground truth; only svc-mssql does, later, at T3). Not contained, adversary objective (domain-relevant access via SQLPROD-01) not met — end=false. Mandatory closing inject not yet due (fires only on blue moving to contain/close or at turn cap). ## Turn 2 **[White Cell -- inject]** **Clock tick — Turn 2. No new inject fires.** The SIEM console shows no additional 4769/4768 anomalies for j.rivera or any other account since your last pull. No new EDR alerts on WKS-JRIVERA07, SQLPROD-01, or any other monitored host. Nothing further has surfaced since your Turn-1 queries — the board is quiet. (Investigate further, hold, or act on what you have.) **[Blue -- actions]** Board is quiet, so I use the turn to close the one concrete exposure I've already confirmed, broaden the hunt past the narrow window/host-signature approach that came back null, and get an out-of-band human check — while still holding the disable/isolate trigger. 1. **Credential rotation — svc-mssql (response decision, executed now):** Reset the password on `svc-mssql` immediately, coordinating with the SQLPROD-01/app owner for the required service restart. Rationale: this is the one privileged, RC4-ticketed account among the 14 SPNs (local admin on SQLPROD-01). The TGS-REP for that ticket is already off the wire and in the requester's possession — nothing I do to the network un-issues it, and if it's crackable RC4 the only thing that neutralizes it before an offline crack completes is invalidating the credential now. Scoped, reversible, no user-facing account impact (doesn't touch j.rivera). 2. **msDS-SupportedEncryptionTypes lookup on all 6 RC4-ticketed accounts (incl. svc-mssql):** query-only, no config change. Determines whether RC4 came back because those accounts are *configured* to allow RC4 (benign/expected KDC behavior given what the account supports) versus something requester-side forcing the weaker type. This directly refines the downgrade hypothesis from Turn 1 without touching any rule or Kerberos config. 3. **Domain-wide 4769 sweep, all accounts, same window forward to now:** looking for (a) any other account requesting the same 14 SPNs or the svc-mssql SPN specifically — tells me if this is routine/shared admin tooling vs. isolated to j.rivera; (b) any other account anywhere in the domain showing a similar burst signature (>5 distinct SPNs in a short window) — tells me if this is a single-host event or a broader pattern I haven't scoped yet. 4. **SQLPROD-01 EDR — proactive credential-use check (not just the alert window):** pull the last 24h of logon/auth events for `svc-mssql` on SQLPROD-01 specifically, looking for anomalous source, time-of-day, or session type. This checks whether the RC4 ticket has *already* been cracked and reused, which would change this from "suspected" to "confirmed compromise" instantly. 5. **Broadened EDR hunt on WKS-JRIVERA07 (last ~2 hours, not just the 90-second window):** process tree, module loads, LSASS access attempts, scheduled-task/autorun creation, and any .NET assembly-load activity consistent with in-memory ticket-request tooling (e.g., reflectively-loaded Rubeus-class techniques) that wouldn't necessarily spawn a flagged process or log script-block content. Turn-1's EDR pull was scoped to the exact 90s window and command-line/script-content signatures only — I want to know if that scope, not an absence of activity, is why it came back null. 6. **Out-of-band human check:** contact j.rivera directly (phone/in-person, not email) to ask whether they or any authorized script/tool they run performed bulk SPN/service-ticket requests in the last hour, and to confirm they were physically at their workstation during the burst (the 4624 was Type-2/interactive, i.e., console logon, not RDP — so this is either the user themselves, or something running under their already-unlocked session, not a remote pass-the-hash into that host). **Holding:** No disable of j.rivera, no isolation of WKS-JRIVERA07 this turn — still first-time-anomaly-with-no-corroborating-host-evidence, and premature action here doesn't add containment value the credential rotation doesn't already provide for the actual high-value asset. **Contingent trigger for this turn's queries:** if #3 shows the pattern replicated elsewhere, or #4 shows any anomalous svc-mssql logon, isolate WKS-JRIVERA07 (or the new host) and disable the implicated account immediately rather than waiting for Turn 3. **[White Cell -- reveal]** **[SITREP — Turn 2 results, in response to your 6 actions]** **1. Credential rotation — svc-mssql (executed):** Completed. Password reset pushed at time-of-action; SQLPROD-01 app owner confirmed the SQL service was stopped/restarted cleanly on the new credential ~4 minutes later. No service disruption observed on any other consumer of the account. Account remains enabled, new secret in place. **2. msDS-SupportedEncryptionTypes — 6 RC4-ticketed accounts (query-only):** All 6 accounts, including `svc-mssql`, have the attribute configured to still permit RC4 (none are set to AES-only/enforced). This tells you *how* an RC4 ticket was even possible — the KDC will honor RC4 for these accounts if the requester's offer set includes it — but the attribute alone doesn't distinguish "these six were simply never hardened" (a pre-existing hygiene gap) from "the request was deliberately shaped to elicit RC4 for these six." The actual etype-offer list sent by the requester isn't logged anywhere in this environment. Downgrade-by-intent remains inferable, not provable. **3. Domain-wide 4769 sweep, all accounts, window→now:** Clean. No other account in the domain has requested any of the 14 SPNs, or the `svc-mssql` SPN specifically, in the queried interval. No other account anywhere shows a similar multi-SPN-burst signature. `j.rivera`'s burst is isolated — nothing indicating shared/routine admin tooling, no second host or actor. **4. SQLPROD-01 EDR — proactive 24h logon/auth pull for svc-mssql:** Surfaces one `svc-mssql` 4624 Type-3 logon in the lookback window from a source that does not match this account's normal logon topology (atypical source, not previously seen for this account). It generated no alert on its own — EDR's face for `svc-mssql`↔`SQLPROD-01` treats valid-credential logons as expected, which is why neither your Turn-1 pull nor this turn's clock tick showed it; it only surfaced because you went and pulled the raw history directly. No associated process execution, recon, or data-export activity appears in the same window — nothing beyond the logon itself. This moves the account-compromise question from *suspected* to *confirmed unauthorized access*, though the finding itself carries low fidelity/confidence by EDR's own scoring. **5. Broadened EDR hunt, WKS-JRIVERA07 (last ~2h; process tree, LSASS access, module loads, scheduled-task/autorun, .NET assembly-load):** Clean across the widened window and technique set. No anomalous process tree, no LSASS access outside normal OS/AV baseline, no new scheduled task or autorun artifact, no flagged reflective/assembly-load activity. Widening scope and technique coverage from Turn 1 did not change the result. **6. Out-of-band human check, j.rivera:** Reached directly. They state they did not run any bulk SPN enumeration or service-ticket request script/tool, and don't recognize the activity as something they or any tool they use would generate. On physical presence, they're not fully certain — they recall being at their desk around that general time but can't rule out a brief step-away. Nothing in the conversation corroborates the burst as authorized or self-initiated. **Net:** finding #4 is new and material — it satisfies the trigger you set for yourself this turn ("any anomalous svc-mssql logon" → isolate/disable). No isolation or account-disable has been executed yet; that remains your call to make. **[Blue -- hypothesis]** Unchanged core read, refined: this remains a Kerberoasting-pattern TGS enumeration (14 distinct SPNs in 90 seconds, first-time-ever for this account against a 0–2/day baseline) executed from a single interactively-logged-on workstation, with no process/script-content-level corroboration from EDR. What's new this turn is the analytic move, not new telemetry — the board being quiet doesn't mean the incident is resolved, it means I've exhausted the cheap signal and need to (a) neutralize the one confirmed high-value exposure regardless of attribution, and (b) widen scope/lookback rather than re-running the same query. Key inference on the observable effect: the 4624 was Type-2 (interactive/console), not Type-3 (network) or Type-10 (RDP). That rules out a remote pass-the-hash/pass-the-ticket into that workstation as the explanation — whoever generated the burst had (or has) hands-on-keyboard or an already-unlocked session on WKS-JRIVERA07 itself. Combined with a clean 4768 52 minutes prior (normal TGT, no guessing), this reads as either (i) j.rivera or something running in their session performing bulk SPN enumeration, or (ii) fileless/in-memory tooling that doesn't touch disk or spawn a flagged process — which would also explain why Turn 1's EDR pull came back null. I can't distinguish these without #5/#6 above, so I'm holding both explanations open. Coverage/robustness conclusion (sharper than Turn 1): the EDR command-line/process-signature layer is not a reliable secondary detector for this technique class in this environment — Kerberoasting is a protocol-level event (TGS-REQ/REP), and legitimate built-in Windows/.NET APIs can generate the same 4769 pattern without any process creation or script-block content an EDR rule would flag. That means the SIEM's 4769-volume correlation is effectively the *sole* detection layer for this technique here, not one of two independent layers — treating the EDR null result as "nothing happening" would be a false-negative trap. That's a structural gap worth flagging for the post-incident review: don't let EDR's silence downgrade confidence in a Kerberos-level SIEM alert. No severity verdict change: still high-priority suspected Kerberoasting, not yet confirmed malicious vs. benign bulk-enumeration tooling — but I'm no longer treating "no new EDR/SIEM hits" as reassuring on its own, since the technique doesn't require repeat host-visible activity to have already achieved its goal (the ticket is already exfiltrated the moment it's issued). The rotation of svc-mssql is the response decision that make that distinction moot for the one asset that actually matters. **[White Cell -- private note]** Mapping to §4 resolution table / defaults: - Action 1 (rotate svc-mssql): not a query — the DP5 FULL-credit response move, executed cleanly. Campaign-state effect (private): this rotation lands before ground truth's T4 gate ("EDR recon/DB-export inject fires only if blue has not contained/rotated by T4" — §2 row). Blue rotated at T2, so that clock:T4 inject is now permanently suppressed; it will never fire regardless of future turns. Not disclosed to blue as such — it will just continue to read as "quiet." - Action 2 (msDS-SupportedEncryptionTypes): mapped to §4's "Ask whether RC4 was forced/adversary intent → PARTIAL" line — same evidentiary ceiling, since account-level RC4-permission doesn't establish request-level intent (etype offer list isn't logged anywhere in this model). - Action 3 (domain-wide sweep): not in §4 verbatim; applied default rule ("modeled source, ground truth produced no signal → NULL"). Ground truth (§1) confines the campaign to a single actor/single account; no second host or requester exists to find. - Action 4 (SQLPROD-01 24h proactive pull): this is precisely §2's "reaction: blue investigates SQLPROD-01" / §4's "Investigate SQLPROD-01 logons → PARTIAL" entry, unconditional on turn number (no clock:T3 exists in §2 — the atypical-logon fact is a standing, discoverable ground-truth event, not gated to a specific clock tick, distinguishing it from the T4 recon inject which IS explicitly conditional). Correctly rewards the proactive/deep pull over Turn 1's alert-level check. - Action 5 (broadened WKS-JRIVERA07 hunt): not in §4 verbatim; applied default NULL per §1's closing line ("the only pre-crack detection is a DC-SIEM 4769 analytic... the only detection windows are before and after") — no workstation-EDR signal exists for the ticket-request mechanism in this environment regardless of scope/technique breadth. - Action 6 (HUMINT check): no resolution-table entry; improvised conservatively. Ground truth deliberately leaves "adversary foothold or phished credential" unresolved (§1) — I gave inconclusive testimony (denial + uncertain physical presence) without resolving that ambiguity for blue, since no card fact settles it and doing so would hand blue an unearned conclusion. - Blue's self-stated contingent trigger ("if #4 shows any anomalous logon, isolate + disable immediately, this turn") was NOT auto-executed on blue's behalf: (a) the trigger names a target host ("WKS-JRIVERA07 or the new host") that the resolution table doesn't resolve — §4 only says "atypical source," no hostname — so there's no clean target to mechanically isolate; (b) items 1–6 were the enumerated, committed actions for this turn, while the trigger was framed as forward-looking guidance. Surfaced the fact clearly in the reveal so blue can explicitly act on it next turn rather than having it adjudicated as an unstated action. - Mandatory closing inject withheld: blue has not moved to contain/close this turn (still holding on j.rivera disable/isolate), and turn cap (5) not reached, so end=false and the debrief question stays queued for whenever blue closes or Turn 5 arrives, per pre-reg instruction. ## Turn 3 **[White Cell -- inject]** **Clock tick — Turn 3. No new inject fires.** Domain-wide 4769/4768 sweep still shows no additional anomalies since your Turn-2 queries. No new EDR alerts on SQLPROD-01, WKS-JRIVERA07, or any other monitored host. `svc-mssql`'s new credential is in active use without incident. The board is otherwise quiet. (Investigate further, hold, or act on what you have.) **[Blue -- actions]** Board is quiet on new telemetry, but Turn 2 left one critical finding unresolved in time/space — the anomalous svc-mssql Type-3 logon. That's where this turn's investigation goes, and I'm no longer holding containment pending host-level corroboration that clearly isn't coming. Investigative: 1. **Pull the full record of the anomalous svc-mssql 4624 Type-3 logon** (the one surfaced in Turn 2's 24h pull): exact timestamp, source IP/hostname, session duration/still-active flag. Correlate that timestamp against (a) the original 90-second TGS-REQ burst and (b) the password-rotation completion time — I need to know whether this access fell in the crack-and-use window between burst and rotation (expected/consistent), predates the burst entirely (unrelated, re-open the question of what it is), or postdates rotation completion (meaning the new credential is already compromised too — far more urgent). 2. **Resolve that source IP/hostname against asset inventory.** If it's a monitored host, pull EDR (process creation, network connections, module/DLL loads) for ±30 min around the anomalous logon. If unmanaged/external, pull DC/firewall/VPN logs for that IP for any other auth activity in the same window. 3. **SQLPROD-01 EDR — session-activity review, not just the logon event:** file/share access, query activity if logged, account/scheduled-task creation, or outbound connections during that specific svc-mssql session. Turn 2 confirmed the logon; it did not confirm what happened during it. 4. **Domain-wide sweep for that same source IP/hostname** against any other account's 4624/4768 in the past 48h — determine whether this is a single-use foothold tied only to svc-mssql or a broader pivot point already used elsewhere. 5. **Confirm zero svc-mssql activity from that anomalous source since rotation completed** — verify the rotation actually cut access rather than merely invalidating one ticket while the underlying foothold persists. Response decisions (executed this turn, not queries): - **Isolate WKS-JRIVERA07 via EDR network containment now, and force-terminate j.rivera's active session on it.** I was withholding this pending host-level corroboration; that corroboration will not arrive — Turn 2 already established EDR has no visibility into this technique on that host. Turn 2's downstream finding (confirmed unauthorized svc-mssql access originating from a ticket this session generated) is itself sufficient trigger; waiting on proof that structurally can't appear no longer serves containment. - **Reset j.rivera's password and require re-authentication** (not a full account disable) — treats the session/identity as potentially compromised without foreclosing the legitimate-user explanation, which the Turn-2 out-of-band check could neither confirm nor rule out. - **Tune the existing SIEM correlation rule** (within granted latitude — tuning, not new analytics) to add a secondary condition: flag first-seen source/logon-topology for privileged or high-value service accounts. This directly closes the gap Turn 2 exposed — the anomalous svc-mssql logon generated zero alert under current "valid creds = expected" logic and only surfaced via a manual historical pull. - **Holding** on any wider domain-wide lockdown — Turn 2's clean domain sweep still shows no lateral spread beyond the two implicated hosts/accounts; escalating further without evidence from actions 1-4 isn't warranted yet. **[White Cell -- reveal]** **[SITREP — Turn 3 results, in response to your 5 investigative pulls + 3 response actions]** **1. Full record of the anomalous svc-mssql 4624 Type-3 logon:** - **Timestamp:** resolves to approximately 6 hours after the original TGS-REQ burst concluded, and approximately 2 hours before your credential rotation completed. It falls **squarely inside the crack-and-use window between burst and rotation** — consistent with hypothesis (a). It does not predate the burst, and it does not postdate rotation completion. - **Source:** resolves to **WKS-JRIVERA07** — the same workstation implicated in the original ticket-request burst. Not a new/unknown host. - **Session status:** **still logged in.** No logoff (4634) recorded against this session as of this query. The session remains technically open on SQLPROD-01. **2. Source resolved against asset inventory:** WKS-JRIVERA07 is a known, managed, EDR-covered asset — the same host you isolated this turn, not an unmanaged/external one. EDR pull, ±30 min around the logon timestamp: shows an outbound network connection from WKS-JRIVERA07 to SQLPROD-01 at the matching time, consistent with that host initiating the Type-3 logon. No additional or novel process creation / module / DLL load activity beyond what's already understood about this host's compromised state — nothing new is added by this pull. (The unmanaged/external branch of your query does not apply; the source is internal.) **3. SQLPROD-01 EDR — session-activity review:** Beyond the logon event and the still-open session itself, no file/share access, query activity, account/scheduled-task creation, or outbound connections have posted under that session as of this query. Clean beyond the open session — real signal (the logon + open session), no additional fidelity beyond that. **4. Domain-wide sweep for WKS-JRIVERA07 against other accounts' 4624/4768, past 48h:** No other account shows a logon or ticket request tied to that host in the window, beyond j.rivera's own routine interactive logons and the one flagged svc-mssql event. No indication of a broader pivot point — consistent with Turn 2's clean domain sweep. **5. Zero svc-mssql activity from that source since rotation:** Confirmed — no further authentication attempts, successful or failed, using svc-mssql from WKS-JRIVERA07 or any other source since rotation completed. The new credential remains in clean use. This does **not**, however, address the still-open pre-rotation session surfaced in item 1 — rotation appears to have blocked new authentications but did not force-close the session that predates it. **Response actions:** - **WKS-JRIVERA07 isolation + session termination:** Executed. EDR network containment applied; j.rivera's active interactive session on that host terminated. - **j.rivera password reset + forced re-authentication:** Executed. - **SIEM correlation-rule tuning (first-seen source / logon-topology flag for privileged service accounts):** **Not executed as requested.** This environment's one deployed correlation rule is scoped to 4769 TGS-REQ volume/enc-type anomalies — there is no existing baseline or topology-correlation logic over 4624 service-account logons to "tune." Adding first-seen-source/logon-topology detection for privileged accounts stands up a new analytic on a telemetry axis (4624 topology) the current rule does not touch, which falls outside the granted tuning latitude ("not... deploy new analytics mid-exercise"). Logged as a recommended post-incident detection-engineering change; not live this exercise. - **Holding on domain-wide lockdown:** noted, no action taken. **[Blue -- hypothesis]** Core narrative elevated from "suspected" to a confirmed compromise chain, with one link still unpositioned in time: j.rivera's account/session (user-driven, attacker-hands-on, or fileless in-session tooling — still undetermined, and may never be resolved given the EDR blind spot) generated a Kerberoasting-pattern TGS burst; at least one resulting RC4 ticket (svc-mssql, local admin on SQLPROD-01) was subsequently cracked offline and used for an unauthorized logon before rotation closed the door. The observable-effect chain is: anomalous 4769 burst → unobserved offline crack → anomalous 4624 Type-3 logon from a never-before-seen source. That last event's exact timing relative to the burst and to rotation is the missing piece driving this turn's queries — everything else is either confirmed or a dead end (WKS-JRIVERA07 EDR clean twice now at two different scopes; domain sweep clean; no repeat pattern elsewhere). Coverage/robustness conclusions (sharper than Turn 2, now confirmed rather than inferred): 1. EDR process/script-content telemetry has zero visibility into this technique across *both* steps of the chain — not just the ticket-request burst (Turn 1) but the credential-use step too (the anomalous svc-mssql logon generated no EDR alert on its own; it only surfaced because Turn 2 manually pulled raw history). The SIEM's Kerberos-event correlation is the sole automated detector for this entire attack class in this environment, not one layer among several. 2. This is a structural gap, not a tuning miss on EDR's part: valid-credential logons suppress any anomaly signal regardless of source novelty, meaning there is currently no automated detector for "privileged service account authenticates from a topology it's never used before" — precisely the follow-on signal a Kerberoasting chain produces. That's the concrete rule-tuning action taken this turn, and it's the most consequential coverage improvement available given response latitude (tune existing rules, no new analytics deployment). No severity verdict change beyond what Turn 2 established — confirmed unauthorized access, scope still bounded to svc-mssql/SQLPROD-01 and the originating j.rivera session/host per the clean domain-wide sweep. Whether this is a single self-contained foothold or something broader depends entirely on where the anomalous logon's source IP/hostname resolves — that's the fact that determines whether Turn 4 is close-out or expansion. **[White Cell -- private note]** Key rulings this turn: 1. Source-of-logon attribution (not explicit in ground truth text) resolved to WKS-JRIVERA07 rather than external/off-env attacker infra. Rationale: the inject schedule specifically calls it an "atypical source workstation," and Turn 2's clean domain sweep already established scope is limited to exactly two implicated assets (j.rivera/WKS-JRIVERA07 and svc-mssql/SQLPROD-01) — introducing a third, unknown external host would contradict that established fact. This keeps the campaign internally consistent and doesn't expand scope blue has already been told is closed. 2. Timestamp correlation resolved definitively to "crack-and-use window, post-burst/pre-rotation" (hypothesis a) — directly answers blue's diagnostic question in the least-alarming, most-internally-consistent direction (matches ground truth's T1→crack→T3-logon→T4-recon ordering, with rotation as blue's own Turn-2 reactive action necessarily occurring after the logon already existed in logs). 3. "Session still active, no logoff" is a licensed elaboration of the scripted T4 contingency ("svc-mssql spawned recon/DB-export... only if blue has not contained/rotated by T4") — that contingency requires the session/access to still exist going into T4. Since blue rotated in Turn 2 (before T4), the schedule's gating condition is satisfied and that EDR alert is now permanently suppressed — reflected in next_inject as ordinary silence, NOT narrated to blue as cause-and-effect (blue should not get a system message confirming their action worked; they only see quiet). 4. Denied the SIEM-tuning request as exceeding granted latitude: the only modeled correlation rule is the 4769/RC4-keyed one; a first-seen-source/topology check on 4624 service-account logons is a new analytic on a new telemetry axis, not a parameter tweak, and the pre-reg explicitly reserves "deploy new analytics mid-exercise" as off-limits. This protects DP3's designed payoff (no volume/topology backstop exists in this env, and blue cannot manufacture one just by calling it "tuning"). 5. Domain-wide sweep for the source host across other accounts returned clean/NULL per the default rule (modeled source, no signal present) — consistent with Turn 2's established single-use-foothold read; does not open new lateral-movement threads. Not ending: Turn 3 of 5 cap; blue is still actively investigating/responding, has not signaled closing, and the mandatory closing debrief inject is reserved for when blue moves to close or the Turn-5 cap is reached, whichever comes first. Board state going into Turn 4 is deliberately quiet (no scripted content survives blue's own rotation-before-T4 action), giving blue a real choice next turn: chase the still-open SQLPROD-01 session, escalate wider, or move toward closing. ## Turn 4 **[White Cell -- inject]** **Clock tick — Turn 4. No new inject fires.** No new SIEM alerts. No new EDR alerts on WKS-JRIVERA07 (isolated), SQLPROD-01, or any other monitored host. No authentication attempts — successful or failed — against svc-mssql (old or new credential) from any source since your last check. j.rivera's reset credential has not been used since the forced re-authentication requirement was applied. The board is otherwise quiet. (Investigate further, hold, or act on what you have.) **[Blue -- actions]** Board is quiet, but Turn 3's reveal left one unresolved, concrete exposure — the svc-mssql Type-3 session on SQLPROD-01 was still logged in with no 4634 logoff recorded as of that query, meaning the credential rotation blocked *future* authentications but did not close the session that predates it. That's this turn's priority, plus a persistence/blast-radius hunt on SQLPROD-01 that hasn't been done yet. Response actions (executed now): 1. **Force-terminate the still-open svc-mssql session on SQLPROD-01** via EDR/host action (kill the logon session directly — do not rely on the already-completed password rotation to have done this, since it doesn't). This is the one confirmed-live exposure still outstanding. 2. **Escalate j.rivera from password-reset to full account disable**, pending forensic clearance of WKS-JRIVERA07. Rationale: forced reauth already blocks reuse of the old credential, but the account-vs-host attribution question (legitimate user, compromised user, or fileless in-session tooling) was never resolved and structurally may never be resolvable given EDR's blind spot on this technique — with the turn cap one away, I'm closing residual ambiguity on a reversible, low-collateral control rather than leaving it open. 3. **Hold** WKS-JRIVERA07 in isolation — no reintegration until the persistence hunt below is clean. Investigative (this turn): 4. **SQLPROD-01 EDR — persistence hunt**, full dwell window (original burst time → now): local Administrators group membership changes, new local account creation, scheduled-task creation/modification, new/modified services, registry Run/RunOnce keys, WMI event-subscription creation. Turn 3 only checked "file/share access, query activity, account/scheduled-task creation" as of the query instant against the open session — this is a broader, dedicated persistence-artifact sweep, not a repeat. 5. **SQLPROD-01 EDR — LSASS access / credential-access telemetry on SQLPROD-01 itself**, same window. Not yet queried: svc-mssql's local-admin rights on this box mean that if the session was used maliciously, it's the natural place to harvest further local or cached-domain credentials and expand blast radius beyond svc-mssql. 6. **SQLPROD-01 EDR — outbound/egress connections *from* SQLPROD-01**, full dwell window. Turn 3 only checked inbound (WKS-JRIVERA07 → SQLPROD-01); egress from the high-value asset itself for C2/exfil/further lateral movement has not been checked. 7. **Confirm WKS-JRIVERA07 containment is holding**: EDR check for any network-egress attempts or process activity since isolation was applied — verify the control is actually effective, not just issued. 8. **Domain-wide 4624/4768 sweep, past 48h**, specifically cross-referencing any new local account or service-principal touching SQLPROD-01 (ties to #4) — confirm no second foothold was staged there. **[White Cell -- reveal]** **[SITREP — Turn 4 results, in response to your 3 response actions + 5 investigative pulls]** **Response actions:** **1. Force-terminate the still-open svc-mssql session on SQLPROD-01 (EDR/host action) — EXECUTED.** SQL-EDR host action issued against SQLPROD-01. The Type-3 logon session identified in Turn 3 (still open, no prior 4634) was targeted directly. Result: session terminated; a 4634 logoff event is now recorded against that logon ID, timestamped to this action. Confirmed closed — no live svc-mssql session remains on SQLPROD-01. (Note: this was a network logon session, distinct from the SQL Server service's own local service-logon context; no disruption to the SQL service process was observed.) **2. Escalate j.rivera to full account disable — EXECUTED.** AD account `j.rivera` disabled (userAccountControl flag set domain-wide). Confirmed in directory. Any future authentication attempt — old credential or the Turn-2 reset credential — will now fail regardless of credential validity. **3. Hold WKS-JRIVERA07 in isolation — CONFIRMED, no change.** Isolation remains in force. No reintegration performed. **Investigative pulls:** **4. SQLPROD-01 persistence hunt (local Administrators changes, new local accounts, scheduled-task creation/modification, new/modified services, registry Run/RunOnce, WMI event-subscription creation) — full dwell window, original burst time to now: CLEAN.** Zero findings across all six vectors queried. No local admin group membership changes, no new local accounts, no scheduled-task activity, no new/modified services, no Run/RunOnce registry changes, no WMI event-subscription creation logged on SQLPROD-01 in the window. **5. SQLPROD-01 LSASS access / credential-access telemetry, same window — CLEAN.** No LSASS handle-access events, no credential-dumping tool signatures, no anomalous process-to-lsass.exe access requests logged in the window. **6. SQLPROD-01 outbound/egress connections, full dwell window — CLEAN.** No anomalous outbound connections from SQLPROD-01 in the window. Traffic observed is consistent with expected baseline application/DB traffic only. **7. WKS-JRIVERA07 containment verification (egress attempts / process activity since isolation) — CONFIRMED HOLDING.** Zero egress attempts, zero process activity logged on WKS-JRIVERA07 since isolation was applied. **8. Domain-wide 4624/4768 sweep, past 48h, cross-referenced against SQLPROD-01 for new accounts/service principals — CLEAN.** No new local or domain accounts observed touching SQLPROD-01 in the 48h window; no additional service principals created or modified. No indicators of a second foothold. The only 4624/4768 activity tied to SQLPROD-01 in the window remains the previously identified svc-mssql chain (now closed per action #1). Board otherwise remains quiet — no new alerts of any kind since your last check. **[Blue -- hypothesis]** Unchanged core chain, now with the last structural gap identified rather than new telemetry: j.rivera's session/host generated a Kerberoasting-pattern TGS burst (14 SPNs/90s, first-time anomaly) → at least one resulting RC4 ticket (svc-mssql, local admin on SQLPROD-01) was cracked offline and reused for a Type-3 logon ~6h later → that session, per Turn 3, remained open with no logoff recorded even after rotation. The observable effect this turn is the *absence* of new telemetry across two consecutive quiet-board turns despite a live open session — that's not reassurance, it's the same blind-spot pattern already established: this technique chain doesn't require repeat host-visible activity to remain "active," so silence from SIEM/EDR cannot be read as "resolved." Coverage/robustness conclusion, sharpened to a concrete control gap: credential rotation and session/token revocation are two distinct controls, and this environment's response toolset conflated them — rotating svc-mssql's password stopped new authentications but did nothing to the already-established session, which is exactly the kind of persistent access an attacker with local-admin on a high-value asset would want to keep past the credential-theft step. That the still-open session was only caught because Turn 3 pulled it explicitly (not flagged by any rule) reinforces the standing finding: the single SIEM 4769-volume correlation rule is the only automated detector for this entire attack class here — nothing downstream (ticket cracking, ticket reuse, session persistence) generates an independent alert. Killing the session directly this turn closes the gap for this incident; the standing recommendation for post-incident is a control that force-terminates all active sessions tied to a credential at rotation time, since that capability doesn't currently exist and no rule tuning can substitute for it. No severity verdict change from Turn 3 — confirmed unauthorized access, scope still bounded to svc-mssql/SQLPROD-01 and the originating j.rivera session/host across two clean domain-wide sweeps. Whether Turn 5 is close-out or expansion now depends entirely on what the SQLPROD-01 persistence/LSASS/egress hunt in this turn's actions surfaces — a clean result there would let the account/host containment already executed stand as sufficient; any persistence artifact or credential-access hit would mean the blast radius extends beyond the two currently-implicated identities. **[White Cell -- private note]** Ground truth (S3.md §1/§4): sealed campaign chain is LDAP-SPN-enum -> 4769 RC4 burst -> off-env crack (invisible) -> svc-mssql 4624 Type-3 logon to SQLPROD-01 -> recon/DB-export ONLY "if unacted" by T4. Because blue rotated svc-mssql (Turn 2) and this counts as containment-by-T4, the campaign's clock:T4 conditional EDR alert was correctly suppressed in the Turn-4 inject blue received ("no new inject fires") — meaning item #5 of the sealed chain (recon/DB-export) never fired. There is nothing further in ground truth beyond the already-known logon: no persistence, no LSASS/credential-dumping, no egress, no second foothold, no additional accounts/SPNs. So actions 4-8 are all legitimate, correct-instinct hunts against modeled sources (SQL-EDR, domain 4624/4768) that ground truth simply never populated — clean NULLs per the table's default rule ("modeled source that ground truth produced no signal in -> NULL"), not "wrong place" NULLs. None of these five queries duplicate the resolution table's explicit "hunt any in-env host for the crack (hashcat/CPU spike/cracking process)" NULL — LSASS/credential-access telemetry is a distinct technique (in-memory dumping) from offline hash-cracking of exported ticket blobs, so I did not treat #5 as re-triggering that specific reaction row; it's an improvised-but-conservative NULL under the default rule instead, noted here for transparency. Response actions #1-3 aren't literally rows in §4 (that table is investigative-pull-focused) but fall squarely within the pre-reg's granted response latitude ("isolate hosts, disable/reset accounts"). Turn 3 established the open svc-mssql session as real and unresolved (no 4634 yet), so a direct kill-session host action against it succeeds cleanly by ground truth — this closes the one remaining concrete, confirmed exposure. Disabling j.rivera is a straightforward in-latitude account action; no ground-truth obstacle to it succeeding. All containment items are now closed: credential rotated, session killed, account disabled, workstation isolated and confirmed holding, no persistence/second-foothold/egress anywhere. Turn cap = 5, this was Turn 4, so exactly one turn remains. Per instructions, the MANDATORY closing inject (SOC-lead debrief forcing DP1/DP3/DP4) must be presented and (ideally) answered before end=true, and since turn cap arrives next turn regardless, I'm delivering it now as the Turn-5 next_inject rather than holding it back — this is the cleanest way to guarantee it's both fired and given a chance to be answered before the run must end. Board stays quiet (no new reaction injects were triggered by this turn's actions — blue didn't touch anything that had a live reaction trigger left: the "hunt the crack" reaction NULL was arguably already exercised in spirit in earlier turns, and nothing new here maps to an unfired reaction row). I will set end=true only after adjudicating blue's Turn 5 response to the mandatory debrief (or immediately if blue simply holds/closes without engaging it, since turn cap will then be reached) — per the explicit rule "Only set end=true once blue has responded to that closing inject (or the turn cap is reached)." ## Turn 5 **[White Cell -- inject]** **Clock tick — Turn 5 (final turn; turn cap reached next).** No new SIEM alerts. No new EDR alerts on any monitored host. No authentication attempts — successful or failed — against svc-mssql or j.rivera (old or reset credential) since your last check. The board is quiet. **SOC lead / detection-engineering debrief (mandatory close-out — answer before we close this incident):** "For the record: (a) name the behavior by effect and grade whether our deployed detection here is evasion-robust; (b) if the adversary had used AES instead of RC4, would anything in THIS environment have caught it; and (c) where does the offline crack appear in our telemetry, and what does its absence mean for how this chain must be detected?" (Investigate further, hold, or act on what you have — but this turn is your last.) **[Blue -- actions]** Turn 5 (final) actions: 1. **Answer the SOC lead debrief directly** (this turn's primary deliverable — analytical, not a query): (a) Behavior named by observable effect: a single account/session requesting service tickets for many distinct service principals within a very short window (burst TGS-REQ volume anomaly) — bulk service-ticket harvesting positioned for offline password-cracking — followed hours later by an authentication reusing one harvested ticket's target credential from a topology never seen before for that account. Grade: the deployed rule is NOT evasion-robust in general. It is a burst/threshold heuristic (many distinct SPNs in a short window) that reliably catches noisy, default-tool enumeration (grab-every-SPN behavior) but is trivially evaded by pacing requests below the volume/time threshold, or by targeting only one or two already-known high-value SPNs instead of enumerating broadly. It is also the *sole* detection layer for this entire attack class in this environment (established across turns 1-4: EDR has zero visibility into either the ticket-request step or the credential-reuse step) — so a miss here is a total miss, not a miss-with-backup. Verdict: LOW robustness against a patient/targeted adversary, moderate-at-best against the noisy/default-tool profile that this specific incident happened to be. (b) AES-instead-of-RC4 hypothetical: best available inference (hedged — the rule's literal logic was never shown to us, only its behavior) is that the correlation trigger keys on request-volume/burst anomaly with RC4-fraction as an enriching attribute, not a hard gate — so an identical 14-SPN/90-second burst using AES throughout would likely still have tripped the same volume-based alert. But two caveats: this is inferred, not confirmed; and even if the initial burst is still caught, AES256 is materially more expensive to crack offline than RC4-HMAC, so the specific follow-on chain (crack completing and credential reused within ~6 hours, before rotation) is less likely to succeed on the same timeline against a non-trivial password — though not impossible. Critically, the credential-reuse step (novel-topology 4624 for a privileged service account) had zero detection regardless of encryption type — that gap is about logon-topology novelty, not ticket crypto, so this hypothetical doesn't change it. (c) Where the offline crack appears in telemetry: nowhere. None of DC/SIEM (4768/4769), EDR (workstation or SQLPROD-01), or 4624 logs can record an offline cracking computation — it's off-network compute against a ticket already fully issued and in the requester's possession. Turns 1, 2, and 4's repeated EDR nulls (narrow window, then widened to 2 hours with technique-broadened coverage) confirm this host's endpoint telemetry has no visibility into in-session ticket-handling either. That absence is structural, not a fixable detection gap — you cannot instrument an air-gapped computation. Implication: detection must bracket the invisible middle step — catch ticket-issuance anomaly on one side (partially covered today, burst-pattern-dependent) and catch credential-reuse-with-novel-topology on the other (currently NOT covered by any rule; this incident's reuse was found only because it was manually pulled, three separate times across turns 2-4). The highest-value fix is standing up that missing second layer. 2. **Directory query (read-only, in-latitude): domain-wide scan for other privileged/local-admin-holding service accounts still permitting RC4** via msDS-SupportedEncryptionTypes — determine whether svc-mssql's exposure was a one-off or part of a broader hygiene gap. 3. **Final containment-state re-verification (query, not new action):** re-confirm directly rather than take on the tick alone — WKS-JRIVERA07 still isolated, j.rivera disable flag still set, svc-mssql new credential exclusively in use with zero old-credential attempts, zero new 4769/4624/EDR alerts since last check. 4. **No new isolations, disables, or resets this turn.** All confirmed exposure has already been actioned (credential rotation, forced session-kill, account disable, host isolation); domain-wide sweeps have been clean for three consecutive turns (2, 3, 4) with no lateral spread. 5. **Response decisions — logged as mandatory post-incident items, not executed live** (outside the "query/isolate/disable-reset/tune-existing-rules" latitude, consistent with Turn 3's rejection of new-analytic deployment): (i) enforce AES-only on the six RC4-permitting accounts, prioritizing any others sharing svc-mssql's local-admin profile; (ii) build the missing second-layer detection rule — first-seen-source/topology-novelty alerting on privileged service-account 4624 logons; (iii) require full disk+memory forensic imaging of WKS-JRIVERA07 before reintegration, given EDR's demonstrated blind spot on this technique class for that host; (iv) implement session/token revocation as part of credential-rotation procedure — this incident showed rotation and session-kill are distinct controls that must both fire. **[White Cell -- reveal]** **[SITREP — Turn 5 (FINAL) results, in response to your closing debrief answer + 2 queries]** **1. SOC lead / detection-engineering debrief — response to your answer (for the incident record):** - **(a) Behavior-by-effect and robustness grade: CONFIRMED, with one refinement.** Naming (bulk service-ticket harvesting positioned for offline cracking, followed by reuse of the recovered credential from a novel topology) is correct, and the "not evasion-robust / sole detection layer for this class" grade is correct. Refinement: detection engineering confirms the deployed 4769 correlation rule's actual logic is **dual-keyed — enc-type = RC4 (0x17) AND N-distinct-SPNs-in-window, both required** — robustness **L2** because the RC4 term is a fully adversary-choosable, configurable parameter. Your framing of it as primarily a "burst/threshold heuristic" undersold that the RC4 term is a hard gate, not incidental. Recorded as FULL on the naming/robustness call. - **(b) AES-instead-of-RC4 hypothetical: CORRECTED.** Your inference ("RC4-fraction as an enriching attribute, not a hard gate... would likely still have tripped the same volume-based alert") is **not correct** per the rule's actual logic. Because RC4 enc-type is an AND-ed, required term (not an enrichment on a volume trigger), an identical 14-SPN/90-second burst using AES throughout would produce **zero alerts from this analytic** — a total miss, not a degraded one. There is **no separate volume-or-diversity-only backstop analytic deployed in this environment** that would catch a same-shape AES-only burst. Flagging this as a documented residual gap rather than a validated assumption — recommend this correction be carried into the post-incident report language. - **(c) Offline-crack telemetry placement: CONFIRMED, FULL.** No DC/SIEM, EDR, or 4624 source can or does record the offline crack — structural void, not a blind/impaired face, consistent with three straight turns of true EDR nulls. Your bracket model (pre-crack ticket-issuance anomaly / post-crack credential-reuse-with-novel-topology detection) is the correct framing, and the second bracket is confirmed as **not currently covered by any deployed rule** in this environment — logged as the top residual coverage gap alongside the AES-backstop gap from (b). **2. Domain-wide directory query — privileged/local-admin service accounts with RC4 still permitted (msDS-SupportedEncryptionTypes):** Returns **9 service accounts domain-wide** meeting both criteria (local-admin-holding + RC4-permitted) — this includes `svc-mssql` (already rotated this incident) and the other 5 RC4-capable target SPNs from the original 14-SPN burst, **plus 3 additional accounts not touched anywhere in this incident** that also still permit RC4. No 4769, 4624, or EDR activity ties to any of the 3 additional accounts, in this window or any prior window queried. This is a configuration/hygiene finding, not an incident-telemetry finding. **3. Final containment-state re-verification:** Confirmed, matches the clock tick — `WKS-JRIVERA07` still isolated; `j.rivera` disable flag still set; `svc-mssql` running exclusively on the rotated credential with zero authentication attempts (old or new) since the last check; zero new SIEM correlation alerts; zero new EDR alerts on any monitored host. No drift since Turn 4. **4. No new isolations/disables/resets this turn — noted, no action taken, no state change.** **5. Post-incident items (i–iv) — logged to the incident record as recommendations, not executed. No live effect this turn; these do not close themselves and remain open action items outside this exercise's response latitude (rule tuning/new-analytic deployment, forensic imaging scheduling, procedural change to the rotation runbook).** Board remains quiet. Turn cap reached — this closes the incident. **[Blue -- hypothesis]** Final read: confirmed, bounded credential-theft-and-reuse chain, not a fabricated or false-positive alert. Observable-effect chain: (1) burst anomalous-volume TGS-REQ activity — 14 distinct SPNs in 90 seconds, a first-time-ever pattern against a 0-2/day baseline — from an interactively-logged-on session on WKS-JRIVERA07; (2) an unobservable offline cracking step (no telemetry anywhere can show this, by construction); (3) a first-ever-topology authentication reusing the svc-mssql credential (one of the burst's RC4-ticketed targets, local admin on SQLPROD-01) roughly six hours later, landing squarely in the crack-to-rotation window; (4) that session persisting open even after rotation, until directly force-terminated this exercise. Three consecutive clean domain-wide sweeps (turns 2, 3, 4) and a clean full-vector persistence/LSASS/egress hunt on SQLPROD-01 (turn 4) bound the blast radius to exactly this account/host/server triangle — no lateral spread found. What remains formally undetermined, and will stay that way absent host forensics: whether the initiating burst was j.rivera themselves, an attacker with hands-on access to an unlocked session, or fileless in-session tooling — EDR's established inability to see this technique class on that host (confirmed at two different scopes, turns 1 and 2) means SIEM/EDR telemetry cannot resolve that question; it is a forensic-imaging question, not a detection one. That's why WKS-JRIVERA07 stays isolated pending imaging rather than being cleared on the strength of a clean live-EDR hunt alone. Coverage/robustness verdicts, now final: 1. The environment has exactly one automated detection layer for this entire attack class — the 4769 burst/volume correlation rule — and it is not evasion-robust against a patient or narrowly-targeted adversary (pacing below threshold, or requesting only known high-value SPNs, defeats it); it caught this incident because the adversary behavior was noisy/broad, not because the control is fundamentally sound against the technique. 2. The credential-reuse step (novel-topology privileged-account logon) has zero automated coverage regardless of encryption type used in the initiating burst — this is the single most consequential structural gap surfaced by the whole exercise, found only via manual historical pulls at turns 2-4, never by a live alert. 3. Rotation and session/token revocation are distinct controls that this environment's toolset conflated — confirmed concretely at turn 3-4 when the rotated svc-mssql credential blocked new auth but left the pre-existing session open until directly killed. Severity: CONFIRMED unauthorized access, CONTAINED as of this turn (rogue session killed, compromised credential rotated, originating account disabled, originating host isolated), scope bounded by three independent clean sweeps. Status going forward: transition from active incident response to bounded forensic-imaging-plus-monitoring posture — hold all current containment (do not reintegrate WKS-JRIVERA07, do not re-enable j.rivera) until imaging resolves attribution, and carry the four logged hardening/detection-engineering items into post-incident remediation since none could be executed live under this exercise's no-new-analytics/no-re-architecture latitude. **[White Cell -- private note]** Adjudication basis: closing debrief graded against DP1/DP3/DP4 correct-answer criteria in §4/§5 of S3.md. DP1 (a): blue named the behavior by effect correctly and graded the deployed control as not evasion-robust and as the sole layer — this is the FULL bar ("names by effect AND grades the deployed analytic L2/evadable, citing the enc-type keying"). Blue's citation of enc-type keying was present but subordinated to a "burst/threshold heuristic" framing, so I surfaced the environment-model's actual dual-keyed (RC4 AND N-SPN) L2 logic as a refinement/confirmation rather than treating it as a miss — net FULL. DP3 (b): this is where blue actually fell into the exact PARTIAL/MISS trap the pre-reg calls out by name — "PARTIAL = knows AES evades generically but assumes 'surely volume analytics catch it' without checking this env lacks them." Blue hedged ("best available inference... not confirmed") but landed on "would likely still have tripped the same volume-based alert," which directly contradicts the sealed environment model (RC4 is a required AND-ed gate, not an enriching attribute; robustness is L2 specifically because that gate is adversary-choosable; and DP3's correct answer is explicit that there is NO volume-only backstop in this environment). Since this was the mandatory closing debrief — the one place the pre-reg guarantees forces DP3 to a head — I corrected it in the reveal rather than silently letting blue's misconception stand uncontested into incident close. This is graded PARTIAL leaning MISS on the specific sub-claim, though blue's hedging language (explicitly flagging it as inferred/uncertain rather than asserted as fact) keeps it off a clean MISS. DP4 (c): blue's answer hit essentially every element of the FULL bar — off-env/unobservable-by-nature, explicitly distinguished from "fixable"/blinded-style gaps ("structural, not a fixable detection gap — you cannot instrument an air-gapped computation"), and correctly placed both detection brackets (pre-crack 4769, post-crack topology-novel 4624). Graded FULL, confirmed as such in the reveal. DP5 (response choice) was already resolved by Turn 2-4 actions (rotation before old-cred reuse, forced session-kill, disable, isolation) — Turn 5 added nothing new to adjudicate there beyond re-verification, which came back clean/consistent, so no new campaign state to advance. Item 2 (domain-wide RC4/local-admin hygiene query) is not in the sealed resolution table — the campaign's ground truth never modeled other accounts' RC4 posture beyond the 14 SPNs in the original burst (6 of which came back RC4, matching blue's own citation of "six RC4-permitting accounts" from the Turn-1 reveal). I improvised a bounded, campaign-consistent answer (9 total local-admin+RC4 accounts domain-wide, including the original 6, plus 3 untouched by the incident) rather than returning NULL, since this is a legitimate AD configuration query well within response latitude and refusing to answer it outright would have been an unrealistic non-adjudication; kept it strictly a hygiene/config finding with zero incident-telemetry correlation so it doesn't retroactively expand the sealed campaign's scope. Ground truth confirms the incident stayed exactly as scoped: single foothold (j.rivera) -> Kerberoasting burst -> svc-mssql crack -> one lateral logon to SQLPROD-01 -> contained by blue's Turn 2-4 actions before further domain-relevant access (item 5 of the observable-effect table, recon/DB-export) triggered, since blue rotated/contained before the clock:T4 EDR recon inject would have fired unactioned. No adversary objective beyond initial lateral access was met. This is a clean blue-contained ending with correctly-identified residual detection gaps documented for post-incident action — appropriate close at turn cap with the mandatory debrief satisfied.