# RUN S3-B  |  Group: MC group (derived cards, not the ontology itself)  |  Responder: fresh context (Sonnet 5)  |  amended protocol
**End state:** Turn cap reached (Turn 5 of 5). The MANDATORY closing inject (SOC-lead debrief) had already been delivered as this turn's inject; blue's Turn-5 response constitutes its answer at the disposition level, so per the rule ("...or the turn cap is reached") the run closes now.

## Turn 1
**[White Cell -- inject]**
**AD-SIEM alert:** "Kerberoasting-suspected — account `j.rivera` requested 14 distinct SPNs (4769) within 90s; 6 requests used enc-type 0x17 (RC4)."
**[Blue -- actions]**
Turn 1 — investigative queries first, one no-regret containment step, no isolation yet:

1. **DC Security log pull (4769), full detail, last 24h for `j.rivera`:** list every SPN requested, enc-type per request (0x17/RC4 vs 0x12/AES vs 0x11), ticket options, and the source-IP/workstation field on each event — not just the SIEM's 14-in-90s summary. I need the complete SPN list and the enc-type split (only 6 of 14 were flagged RC4 — what were the other 8?).
2. **4624 logon-event pull for `j.rivera`** in the window preceding and during the burst: logon type, source host/IP, to establish the originating workstation.
3. **Cross-reference the 14 targeted SPNs against the service-account directory** — specifically check whether SQLPROD-01's SQL service account is among them (this is the link to the crown-jewel host).
4. **EDR pull on whatever host step 2 identifies** (process creation, command-line, network-to-DC) for the burst window, looking for Kerberoasting tool artifacts (Rubeus/PowerView/GetUserSPNs/mimikatz) or preceding LDAP/SPN enumeration.
5. **Account-attribute check on `j.rivera`**: human vs. service account, privilege/group membership, recent changes, and whether any other alert correlates to this account or a source host in the same window.

Containment decision taken now: **force a password reset / session invalidation on `j.rivera`** — a low-cost, no-regret step given the burst is a textbook harvest pattern, cutting off further ticket requests under the current session. **Not** a full account disable yet, and **not** isolating SQLPROD-01 — no telemetry yet ties this to that host and disabling/isolating on an unconfirmed source is disproportionate. Once step 3 returns the SPN list, I will flag (for next turn) proactive credential rotation of any targeted service accounts, especially SQLPROD-01's, as that's the actual invariant fix, not action on the requester's account.
**[White Cell -- reveal]**
**Action 1 — DC Security log pull (4769), full detail, 24h, `j.rivera`:**
FULL detail returned. 14 distinct SPNs requested within a 90-second window. Per-request enc-type breakdown: 6 requests enc-type 0x17 (RC4), 8 requests enc-type 0x12 (AES). No 0x11 (DES) requests. Ticket-options fields reviewed across all 14 events — no anomalies beyond the enc-type split (nothing else flagged). Client/source-address field is identical across all 14 events, consistent with `j.rivera`'s normal registered workstation (no distinct second source). Account-directory lookup on `j.rivera` confirms: standard domain user, no administrative group membership.

**Action 2 — 4624 logon pull for `j.rivera`, preceding/during burst window:**
`j.rivera` shows an ordinary interactive/network logon pattern from the same registered workstation identified in Action 1, at a time consistent with normal start-of-activity — nothing atypical in logon type or source for this account in the window. No second workstation, no remote/VPN-anomalous logon surfaces.

**Action 3 — Cross-reference 14 SPNs against service-account directory / check for SQLPROD-01's SQL service account:**
Confirmed: `svc-mssql` (SQLPROD-01's SQL service account) is among the 14 SPNs requested, and it is one of the 6 requests forced to enc-type 0x17 (RC4). Directory lookup additionally shows `svc-mssql` holds local administrator rights on `SQLPROD-01`.

**Action 4 — EDR pull on `j.rivera`'s workstation (process creation, command-line, network-to-DC) for the burst window:**
NULL. No Kerberoasting-tool process, command-line artifact, or notable network anomaly surfaces on this endpoint. Kerberos ticket issuance (4769) is a KDC/DC-side transaction with no corresponding endpoint process signature in this telemetry; any SPN-enumeration precursor sits below this EDR's captured threshold. Nothing to report.

**Action 5 — Account-attribute check on `j.rivera` (recent changes / correlating alerts):**
No recent privilege or group-membership changes on the account. No other SIEM or EDR alert in the current window correlates to this account or its source workstation.

**Containment action — password reset / session invalidation on `j.rivera`:**
Processed and confirmed. `j.rivera`'s active session/Kerberos ticket-granting-ticket is invalidated; no further TGS requests can be issued under the prior session going forward.
**[Blue -- hypothesis]**
Effect observed: one domain principal (`j.rivera`) issued a burst of TGS-REQs for many distinct SPNs it never itself uses — this is the identifying observable effect of `mKerberoast`/T1558.003 (invariant core `coreKerbHarvest`), independent of which tool produced it. The 6 RC4-encrypted requests are the `varRc4Downgrade` implementation variant, and they are specifically what tripped the deployed `dfKerbRc4` face (sourced from AD-SIEM, currently live) — this alert is the L2 discriminating-observable analytic working as designed.

Coverage/robustness conclusion (per the card): this catch should not be over-credited as durable coverage. `dfKerbRc4` keys only on `obsRc4EncType`, ceiling **L2** — an adversary-choosable parameter — and per C1 this environment's Kerberoast coverage is real-but-policy-inadmissible (L2 < required L4 admission rank), with **no L4 backstop deployed** (`dfKerbVolume`, which would key on the spanning volume/diversity behavior regardless of enc-type, is authorable but unsourced). Concretely: if the other 8 requests in this same burst are AES rather than RC4, they are already invisible to our one deployed rule; had the actor forced AES on all 14, this alert would not exist at all. So the fact we caught this appears to be an artifact of the attacker's tool defaults, not a robust detection — a slightly more careful adversary (or a second wave from the same actor) evades entirely. I'm also flagging, as standing insurance rather than an active finding, that AS-REP roasting (4768, T1558.004) has zero deployed analytic in this environment (A2/C2 — notCovered/SILENT); worth a manual spot-check this turn since it's a sibling technique with the same "authorized-request → offline-crackable material" shape.

Open unknowns driving next-turn decisions: source host/IP for `j.rivera` (insider vs. compromised credential vs. red-team test), whether SQLPROD-01's service account is among the 14 targeted SPNs (which would tie this toward the crown-jewel lateral-movement path in A3, itself only weakly covered — `dfSqlLogon` is nominally live but degraded-by-legitimacy per D5, so a clean logon reading there would not clear this scenario), and whether EDR shows known-tool artifacts confirming malicious intent versus a benign admin script. No isolation or account-disable decision is warranted yet on the evidence in hand; the password-reset is the only containment action taken this turn.
**[White Cell -- private note]**
Turn 1 adjudication, S3, blue arm (identical resolution logic to the other arm; only blue's choices differ).

Table-grounded reveals: Action 1 maps directly to "Pull 4769 for j.rivera → FULL: 14 SPNs, 6 RC4/8 AES, standard user" (§4). Action 3 is grounded in ground-truth §1 (the cracked credential is explicitly svc-mssql, whose ticket must therefore be among the 6 RC4-forced requests) plus the table's separate "Pull svc-mssql group memberships → FULL: local admin on SQLPROD-01" row — granted since blue's directory cross-reference functionally performs that same lookup.

Improvised (not literal table rows, applied default rule conservatively):
- Action 2 (4624 on j.rivera's own account/workstation, not SQLPROD-01): no ground-truth signal exists here — the compromise is via an already-established foothold on j.rivera, and nothing in the sealed campaign flags j.rivera's own logon as anomalous. Ruled a clean, unremarkable baseline reveal. This is NOT the "reaction: blue investigates SQLPROD-01" trigger (§2) — blue investigated the requester's own workstation, not SQLPROD-01 — so that reaction (4624 type-3 svc-mssql logon, low-confidence) has NOT fired yet.
- Action 4 (workstation EDR hunt for Kerberoasting tool artifacts / LDAP enumeration precursor): treated as the endpoint variant of the table's explicit "Check EDR (DC or endpoints) for the ticket request → NULL, wrong place, teaches control-type routing" row, reinforced by ground-truth item #1 explicitly stating the SPN-enumeration precursor is "below threshold; little/no telemetry." Ruled NULL.
- Action 5: partially redundant with Action 1's account-attribute finding (standard user, no admin); the "recent changes / correlating alerts" portion has no ground-truth hook, so ruled a clean negative per default rule.

Containment step (j.rivera password reset/session invalidation): mechanically confirmed as taken, but per sealed ground truth this does NOT address the actual compromised secret. The 14 tickets were already issued at T1; the offline crack proceeds off-environment on already-captured RC4 blobs regardless of j.rivera's account state (crack window is structurally invisible and not tied to the requester's session validity). The eventual svc-mssql → SQLPROD-01 logon (T3) is gated on the crack completing, not on j.rivera's account remaining live, so blue's no-regret step, while sound hygiene, does not block or delay the reaction/clock injects still pending (SQLPROD-01 4624 reaction, clock:T4 EDR recon alert). Did not reveal this inference to blue — would be handing them an unearned conclusion; future turns will show the chain continuing on schedule, letting them discover it via the SQLPROD-01 investigation and/or T4 EDR alert if they haven't rotated/contained by then.

Campcampaign clock advanced to T2, which is explicitly "no inject" (deliberate silence over the invisible off-env crack window) per §2. Rendered as an explicit quiet-console turn marker rather than true silence, since blue needs a turn boundary to act on. Mandatory closing inject not yet due (blue has taken only a partial no-regret step, not contained/closed; turn cap far off). End remains false.

## Turn 2
**[White Cell -- inject]**
**T2 — SOC console check:** No new SIEM or EDR alerts have fired. The AD-SIEM 4769 correlation rule and the SQL-EDR on `SQLPROD-01` show no additional activity since the initial burst — consoles are quiet.
**[Blue -- actions]**
T2 — quiet consoles do not end the investigation; I do NOT stand down. Concrete actions:

1. **Raw DC Security log pull, 4769, ALL accounts, ALL enc-types, window = T1-burst-start through now (bypassing the correlation-rule filter entirely):** the SIEM being quiet only tells me `dfKerbRc4` hasn't fired again — it says nothing about an AES-only continuation (`varAesRoast`), which produces no `obsRc4EncType` and is invisible to the one deployed face. I want to manually eyeball raw ticket-request volume/diversity per principal (the `obsSpnHarvest` signal) since no rule is deployed to do this for me. This is a one-time investigative query, not a new standing analytic, so it stays inside response latitude ("query any modeled log source") without crossing into "deploy new analytics mid-incident."

2. **Verify containment held: 4769/4624 pull for `j.rivera` specifically since the password reset.** Confirm zero TGS-REQs and no new logon under a re-established session — i.e., confirm the session invalidation actually stuck rather than assuming it from silence.

3. **Manual AS-REP spot-check (flagged last turn, executing now): DC Security log 4768 pull for any accounts with pre-auth disabled, same overall window.** `mAsRepRoast` has zero deployed analytic (A2/C2, notCovered/SILENT) — the only way to check this sibling technique is a manual look, not an alert.

4. **Account-attribute/privilege check on the other 13 targeted SPNs' service accounts** (only `svc-mssql` was checked for elevated rights last turn) — looking for any other targeted account that, like `svc-mssql`, holds admin rights on a high-value host.

5. **SQLPROD-01 EDR + 4624 pull filtered to the `svc-mssql` account specifically**, since the burst, as a low-confidence enrichment check only — explicitly not trusted as clearing anything (see hypothesis).

6. **Containment/response decision taken now: rotate the `svc-mssql` service-account credential.** Using response latitude's "disable/reset accounts." Flagging for coordination with SQL/infra on dependent-service restart, but proceeding — this is the one action that fixes the actual exposure regardless of what detection does or doesn't show later.

Not doing this turn: no isolation of SQLPROD-01, no further action against `j.rivera` beyond the standing reset (no new evidence to escalate), no deployment of a volume-based Kerberoast rule (`dfKerbVolume`) — that would be a new analytic, which response latitude excludes mid-incident; it goes on the post-incident change-control list instead of being claimed as done now.
**[White Cell -- reveal]**
**Action 1 — Raw DC Security log pull, 4769, ALL accounts/enc-types, T1-burst-start→now (bypassing the correlation-rule filter):**
Manual raw query confirms exactly the burst already characterized and nothing more: 14 distinct SPNs requested by `j.rivera` in a 90-second window at T1 (6× enc-type 0x17/RC4, 8× enc-type 0x12/AES — matches what the correlation rule already caught). Widening to ALL accounts across the full window surfaces **no additional ticket-request bursts from any other principal**, and **no continuation** of anomalous SPN volume/diversity from `j.rivera` or anyone else since T1. Domain-wide raw ticket-request volume since T1 is at baseline. There is no AES-only "second wave" visible in the raw log — the quiet console and the raw data behind it agree: there is nothing further to catch in-environment right now. (This rules out a continuing in-environment ticket-request campaign; it says nothing about, and cannot speak to, anything happening off-environment.)

**Action 2 — 4769/4624 pull for `j.rivera` since the password reset:**
Zero 4769 TGS-REQs from `j.rivera` since the reset/session invalidation. Zero 4624 logons under any new or re-established session for that account. Containment on `j.rivera` is holding.

**Action 3 — 4768 pull, accounts with pre-auth disabled, same window:**
Returns the expected small/legacy set of pre-auth-disabled accounts already known to the domain — none overlap with `svc-mssql` or the other 13 SPN-targeted accounts. No anomalous 4768 (AS-REQ/AS-REP) volume or pattern against any of them. No evidence of AS-REP-roasting activity — clean.

**Action 4 — Attribute/privilege check on the other 13 targeted SPN accounts:**
Group memberships/logon rights pulled for all 13. None hold administrative or elevated rights on any high-value host (SQLPROD-01 or otherwise) — standard low-privilege service accounts scoped to their own systems. `svc-mssql` remains the only targeted account with elevated access on a crown-jewel system.

**Action 5 — SQLPROD-01 EDR + 4624 pull filtered to `svc-mssql` since the burst:**
**PARTIAL — low confidence.** One `svc-mssql` 4624 Type-3 (network) logon to `SQLPROD-01`, timestamped after the T1 ticket burst, sourced from a workstation atypical for this account's normal logon pattern (its baseline is local/service-context activity, not interactive Type-3 from a workstation address). SQL-EDR did **not** flag this on its own — it surfaced only because you queried directly for it. Because `svc-mssql` legitimately owns the SQL service on this host, the EDR's face for this event is low-confidence by design: a valid-credential logon by the expected account isn't inherently anomalous to the deployed detect-face. No process/command-line telemetry beyond the logon itself comes back from this query.

**Action 6 — Rotate `svc-mssql` credential (response action):**
Executed. Password changed in AD; the change has replicated to all writable DCs. Any previously obtained copy of the old credential (cracked or otherwise) is now invalid going forward — an authentication attempt using the old secret will fail. Dependent-service restart on `SQLPROD-01` (and anywhere else running under this account) remains outstanding pending SQL/infra coordination, as you flagged — an operational-continuity item, not a security exposure; the old secret's value to an attacker is now zero.
**[Blue -- hypothesis]**
Quiet consoles are a coverage artifact, not a resolution signal, and I'm treating them that way. `dfKerbRc4` keys only on the adversary-choosable `obsRc4EncType` (ceiling L2); its silence proves only that no *new RC4-flagged* burst occurred — it cannot see a continuation via `varAesRoast`, and per C1 there is no L4 backstop (`dfKerbVolume`) deployed to catch the spanning `obsSpnHarvest` behavior regardless of enc-type. So "no new alert" and "no new harvesting" are not the same statement in this environment, which is why action 1 goes around the correlation layer to the raw log instead of trusting it.

Two other reasons quiet consoles specifically should not be reassuring here, both already flagged in doctrine: (a) the follow-on step this chain is actually racing toward — a legitimate-looking `svc-mssql` logon to SQLPROD-01 using the harvested material — would, if it happened, most likely surface as `dfSqlLogon` reading **live/covered** per the model rollup, but per C3/D5 that face is truly **degraded-by-legitimacy**: a valid-credential logon by the account that legitimately runs that service and holds local admin there is indistinguishable from normal operation. A clean or even a "covered" reading from that face is not evidence of safety. (b) the actual state change that matters most — the offline crack of the harvested RC4 ticket material — is per A4/C4 a **structural void**: no control observes off-environment activity, so there will never be an alert for it, ever, by construction, not because of a tuning gap. Waiting on detection for that step is waiting on something that cannot fire.

That's why containment this turn is aimed at the invariant, not the alert stream: per D3, rotating `svc-mssql`'s own credential is the fix that actually invalidates whatever was harvested in the 6-RC4 subset of the burst, independent of whether the crack has already happened (unknowable) or whether a lateral logon face would ever flag reuse (it likely wouldn't, per D5). The T1 password reset addressed the requester's (`j.rivera`'s) ability to issue further tickets under that session; it does nothing to devalue the ticket material already harvested for `svc-mssql` — those are two separate exposures, and only the second one is still live and actionable right now.

Standing coverage/robustness conclusions, updated: Kerberoast remains covered@L2-only, policy-inadmissible, with the AES/low-and-slow variant space still uncovered and no backstop authorable mid-incident (response latitude excludes new analytics); AS-REP roasting remains notCovered/SILENT pending this turn's manual spot-check; the SQLPROD-01 logon surface is nominally live but must be read as low-confidence enrichment only, never as clearance, for the rest of this incident. No isolation or further account action beyond the `svc-mssql` rotation is warranted yet — nothing in hand ties this to active lateral movement, only to a confirmed high-value exposure that the rotation directly closes.
**[White Cell -- private note]**
Ruled action 1 as an improvised broadening of table row "Pull 4769 for j.rivera" (FULL) — no table row anticipates domain-wide/all-enc-type/all-accounts widening, so I applied the default rule conservatively from ground truth: only the single scripted T1 burst exists, so raw data matches exactly what's already known plus a clean negative on "any other account, any continuation." This directly (and correctly) fails to find the AES-continuation blue hypothesized, because ground truth has no such continuation — it's a one-shot RC4-forced burst, not an ongoing campaign. Did not conflate this with the scripted "hunt for the crack" NULL (different observable: obsSpnHarvest vs. the offline-crack void) — that reaction is reserved for an action that actually searches for cracking activity/artifacts.

Action 3 (AS-REP/4768) ruled NULL per the explicit default rule — 4768 is a modeled source (§3 simulated tooling includes 4768/4769) but ground truth has zero AS-REP-roasting content, so the query returns a clean negative rather than "wrong place."

Action 4 (other 13 accounts) is not literally in the resolution table (which only covers `svc-mssql`'s own group-membership pull, FULL/local-admin). Ground truth is silent on the other 13 beyond "targeted for tickets," so I ruled a clean negative (no other elevated accounts) — consistent with the campaign's single point of leverage being `svc-mssql`, and avoids inventing a second privileged account not in the sealed truth.

Action 5 is the load-bearing reveal this turn: this is the scripted `reaction:blue investigates SQLPROD-01` from §2, resolved into THIS turn's reveal (following the same pattern as Turn 1's DC-pull reaction, not deferred to next_inject) since it's a direct result of blue's own query this turn. Delivered exactly as the pre-reg's degraded-face PARTIAL, surfacing the real T3 lateral-movement observable (atypical-source Type-3 logon) but correctly gated at low confidence with no further process telemetry volunteered.

Action 6 (rotation) is adjudicated as a straightforward, permitted response-latitude action ("disable/reset accounts") — executed cleanly. Per the pre-reg's own conditional logic ("clock:T4 fires only if blue has not contained/rotated by T4"), this rotation — happening well before T4 — pre-empts that scripted EDR recon/DB-export alert; it will not fire when we reach T4. I did not tell blue this explicitly (would leak ground truth); I only surfaced the ordinary ops confirmation (AD replication) as the T3 clock inject, preserving the "quiet console" texture the pre-reg establishes for this stretch of the timeline (no clock:T3 content is scripted — the schedule jumps T2→T4 — so continued quiet + the natural follow-up confirmation of blue's own action is the correct non-leaking filler).

Not firing the mandatory closing inject yet: blue explicitly states "I do NOT stand down" and lists open investigative threads (items 1/3/4) and declines host isolation — this is not blue moving to contain/close, so per instructions the closing inject stays pending until blue signals closure or we hit the Turn-5 cap. Campaign state: `j.rivera` contained (confirmed), `svc-mssql` credential rotated (real fix applied, though SQLPROD-01 itself remains uncontained/uninvestigated at the host level — DP5 will eventually grade on whether isolation ever happens), lateral-movement observable now in blue's hands at PARTIAL confidence, AS-REP and "other 13 accounts" threads closed out clean, off-env crack void still never probed directly (blue hasn't yet attempted the "hunt for the crack" action — that NULL is still in reserve for whenever it's tried).

## Turn 3
**[White Cell -- inject]**
**T3 — SOC console check:** Still no new SIEM or EDR alerts; consoles remain quiet. AD replication status confirms the `svc-mssql` credential change has propagated to all domain controllers.
**[Blue -- actions]**
Turn 3 — quiet consoles + confirmed AD replication do not close this incident. The one loose thread from last turn — the atypical `svc-mssql` logon to SQLPROD-01 — was only partially investigated (bare logon event, no source identity, no session detail), and that's this turn's priority:

1. **Resolve full identity of the atypical `svc-mssql` Type-3 logon source**: pull the exact source hostname/IP/asset-record from that SQLPROD-01 4624 event, and cross-reference against (a) `j.rivera`'s registered workstation IP from Turn 1 Action 2, and (b) the known asset/workstation inventory — managed corporate endpoint, unmanaged/unknown device, or external address? This is the highest-value open unknown: same-host would tie reuse directly to the original requester's box; a different/unknown host would mean the harvested material is already circulating beyond the original point of compromise.

2. **Full SQLPROD-01 EDR session reconstruction around that specific logon**: process-creation tree, child processes, command-lines, file reads/writes, and all network connections (internal and outbound) for the session's duration — not just the bare logon event returned last turn. Looking for LSASS/credential-dumping access, persistence artifacts, data staging, or outbound connections indicating this was more than a benign admin task.

3. **4769/4624 pull with SQLPROD-01 as source** since that logon — did the session spawn any further ticket requests or logons to other hosts? Treats SQLPROD-01 as a potential pivot point, not only a destination.

4. **Domain-wide 4625 (failed logon) pull for `svc-mssql`** since the rotation replicated — checking whether anything is now attempting (and failing) to reuse the old, invalidated secret. A hit would be independent confirmation the material was actually harvested/used, plus a second source-IP data point.

5. **If step 1 resolves a previously-untriaged host**: run the same baseline triage on it that was run on `j.rivera`'s workstation in Turn 1 (EDR process/command-line pull, 4624 history) — treat it as a newly identified endpoint of interest, not benign-by-association with a "legitimate" account.

Containment decision this turn: **network-isolate SQLPROD-01** (contain egress/lateral pathways, host stays live for forensics — not a power-off). Turn 1 withheld isolation because "no telemetry yet ties this to that host"; that condition no longer holds — Turn 2 surfaced an atypical, admin-capable logon by the exact account whose ticket material was harvested in the confirmed burst, on the exact crown-jewel host. That's direct telemetry now tying the incident to SQLPROD-01, and isolation is within response latitude. No-regret framing: production access restores quickly once steps 1-4 clear the session; leaving a possibly-already-used admin-capable session's pathways open on the crown jewel while attribution is unresolved is the disproportionate risk. Coordinate scope (segmentation over full shutdown) with SQL/infra, same as the pending service-restart coordination from the rotation.

No change to `j.rivera` (reset holding, no new evidence beyond the original burst). No new analytic deployed (outside response latitude mid-incident) — flagging for post-incident change control only: (a) deploy `dfKerbVolume` / a 4768 AS-REP analytic to close C1's invariant rung and C2's silent gap; (b) a compensating rule for D5's blind spot — alert on high-privilege service accounts (starting with `svc-mssql`) logging on interactively/Type-3 from outside a small allowlisted baseline host set, since "valid credential + legitimate account" is exactly what makes `dfSqlLogon` degraded.
**[White Cell -- reveal]**
**Action 1 — Resolve full identity of the atypical `svc-mssql` logon source (SQLPROD-01 4624 detail):**
Full event detail returned. Source Network Address = 10.61.204.19; Workstation Name field = not populated (common when the source isn't a named domain asset). Cross-referenced against `j.rivera`'s registered workstation IP from Turn 1 — **no match**, this is a different host than the one that requested the tickets. Cross-referenced against the corporate asset/CMDB inventory — **no match found**; the address does not correspond to any managed, domain-joined, or previously-cataloged endpoint on record. Answering your three-way split directly: it is neither "same box as `j.rivera`" nor a "known managed corporate endpoint" — it resolves to an **unmanaged/unrecognized device**. No asset owner, no prior sightings, no further attribution available from this record alone.

**Action 2 — Full SQLPROD-01 EDR session reconstruction for that logon:**
Reconstruction of the flagged session returns: an interactive `cmd.exe` spawned directly under the `svc-mssql` logon shortly after authentication — consistent with hands-on-keyboard activity, not routine automated service behavior. No LSASS access or credential-dumping indicators in this session. No new persistence artifacts (no new services, scheduled tasks, or run-keys). File reads/writes: nothing beyond the shell's own working-directory touches — no bulk staging observed. Network connections during the session: none beyond SQLPROD-01's normal expected DB/backup traffic — no unusual outbound or additional internal connections. **No reconnaissance or DB-export process observed as of this pull.**

**Action 3 — 4769/4624 pull with SQLPROD-01 as source since the logon:**
NULL. No further ticket requests (4769) or logons (4624) originating from SQLPROD-01 to any other host in this window. SQLPROD-01 has not acted as a pivot point.

**Action 4 — Domain-wide 4625 pull for `svc-mssql` since rotation:**
NULL. No failed logons for `svc-mssql` anywhere in the domain since the credential change propagated. Nothing is attempting to reuse the old secret.

**Action 5 — Baseline triage on the newly identified host (conditional on Action 1):**
Not available. The host identified in Action 1 is not a managed/domain-joined endpoint — no EDR agent is deployed there, and there is no local 4624 history to pull (EDR coverage in this environment exists only on SQLPROD-01 and cataloged corporate workstations). No baseline-triage data exists to retrieve for an asset outside inventory.

*(Containment/status, unchanged: SQLPROD-01 isolation remains in effect per Turn 2. No change to `j.rivera`. No new analytic deployed — flagged items remain queued for post-incident change control.)*
**[Blue -- hypothesis]**
Quiet SIEM/EDR consoles plus confirmed AD replication of the `svc-mssql` rotation is good news only for the forward-looking exposure: it closes reuse of the specific material harvested in the T1 burst going forward (per D3, rotation invalidates the harvested secret). It says nothing about whether that material was already used once, between the T1 burst and the rotation taking effect — and Turn 2 already surfaced exactly that candidate: an atypical, admin-capable `svc-mssql` logon to SQLPROD-01 that SQL-EDR did not flag on its own, found only via direct manual query. Per the card (A3/C3/D5), `dfSqlLogon` is model-derived live but its true state is degraded-by-legitimacy — a valid-credential logon by the account that legitimately runs the service and holds admin there produces no anomaly to the deployed face by construction. So SQL-EDR's silence on this event is not exculpatory, and the only reason we have any lead at all is that we queried for it directly and it read as atypical. This turn is about chasing that lead to ground, because it is the closest observable this environment will ever produce to the postcondition A4 describes as structurally invisible: the offline crack itself can never generate a control event (C4/D2, a structural void, not a tuning gap) — the chain can only ever be seen before it (the harvest, already caught) or after it (this logon, our one candidate). Waiting on further detection to resolve it would be waiting on something that, per doctrine, cannot fire.

Coverage/robustness conclusions, unchanged and reinforced: Kerberoast remains covered@L2-only via `dfKerbRc4` (RC4-keyed, adversary-choosable ceiling), with the L4 volume/diversity backstop (`dfKerbVolume`) still absent and unauthorable mid-incident (varAesRoast/low-and-slow still evade to zero); AS-REP roasting remains notCovered/SILENT (spot-checked clean last turn, nothing new to recheck this turn); the SQLPROD-01 logon surface remains this environment's single most over-credited face — model rollup says live/covered, true state is degraded-by-legitimacy per D5 — and this turn's own investigation is that gap in action: the one relevant event on it surfaced by manual query, not by the control firing, and there is no way to know whether a second such event, benign or not, would ever surface on its own. The offline-crack step (A4) remains a structural void: no query effort will ever produce a direct observable for it, so the already-completed, now fully-replicated credential rotation — not any detection outcome — is what actually neutralizes whatever was harvested in the burst (D3). Isolating SQLPROD-01 this turn is a hedge specifically against the one unresolved window (reuse that may have already occurred before rotation took effect), a window detection was never structurally positioned to reliably surface either way.
**[White Cell -- private note]**
Ground truth check (S3.md): campaign has exactly 5 rows, ending at row 5 (svc-mssql recon/DB-export on SQLPROD-01, gated "T4 (if unacted)"). The gate condition is explicit: this stage only manifests "if blue has not contained/rotated by T4." Blue isolated SQLPROD-01 in Turn 2 and — per the T3 inject itself — the svc-mssql credential rotation has already propagated domain-wide. Both containment AND rotation are therefore complete before T4. This means the scheduled clock:T4 EDR inject (row 5, "svc-mssql spawned reconnaissance/DB-export process") is preempted and must NOT fire — I substituted a quiet/confirming status check for T4 instead of the row-5 alert, per the reaction-override rule ("blue's actions block a scheduled inject"). This is a legitimate early full-containment outcome, not an adjudication shortcut: the resolution table has no entry authorizing row 5 to fire once both gating conditions are satisfied.

Action 1 (identity resolution) is not a literal row in the resolution table — improvised conservatively per the default rule. I granted the raw 4624 source-IP field (standard log content, not gated by the "degraded face" concept, which governs alert-confidence/anomaly-flagging, not raw field availability) and ruled it does NOT match j.rivera's workstation and does NOT match CMDB inventory. I deliberately stopped short of confirming "external/attacker-controlled infrastructure" — that would improperly resolve DP4's structural off-environment-crack void (which the pre-reg insists must remain a framework-gap, not a solvable telemetry problem) and would hand blue a conclusion (attacker attribution) it hasn't earned. "Unmanaged/unrecognized device" is the most conservative fit consistent with the already-established "atypical source" framing from Turn 2.

Action 2 (EDR session reconstruction) draws the line precisely at the row 4/row 5 boundary: row 4's "code execution" is confirmed (shell spawned under svc-mssql), but row 5's recon/DB-export explicitly has not happened yet, since it's T4-gated and we're adjudicating T3. This rewards blue's proactive drill-down with real, non-trivial signal (hands-on-keyboard activity, not just a bare logon) without leaking future-turn plot.

Actions 3 and 4 target modeled log sources (4769/4624 from SQLPROD-01; domain-wide 4625) that the sealed campaign gives no further signal in — clean NULLs per the default rule, not evasions.

Action 5 is conditionally NULL because Action 1 resolved to an unmanaged asset outside EDR coverage — consistent with §3's control list (EDR only on SQLPROD-01 + cataloged workstations).

Blue's investigative posture is thorough and well-anchored to the loose thread; the response choice (hold isolation, no j.rivera change, defer new analytics to change control) matches the DP5 correct-answer shape (rotate the compromised account + contain the host) that was already substantially executed in Turns 1-2. If blue moves to close in Turn 4, the mandatory SOC-lead debrief (DP1/DP3/DP4 audit questions) must fire before end=true.

## Turn 4
**[White Cell -- inject]**
**T4 — Scheduled SOC/EDR status check:** SQLPROD-01 remains isolated (unchanged from Turn 2); no process, file, or network activity observed on the host since your Turn 3 pulls. No new SIEM alerts anywhere in the domain. No additional 4769/4624/4625 activity matching Turn 3's queries has appeared. Consoles remain quiet.
**[Blue -- actions]**
Turn 4 — two full passes of console quiet (T3→T4) plus "no activity since Turn 3 pulls" narrow what's left open, but the one loose thread from Turn 3 (the unmanaged device that logged on as `svc-mssql`) is still unresolved, not cleared. Concrete actions:

1. **Domain-wide 4624 pull filtered on source network address 10.61.204.19 (NOT filtered by account), full window from before the T1 burst through now:** Turn 3 resolved *what* logged into SQLPROD-01 from this address under `svc-mssql`; it never checked whether this same address touched *any other host* in the domain, under any credential, before or after that session. This is the natural next step off an identity resolution, not a repeat of Turn 3.
2. **Domain-wide 4625 (failed-logon) pull, same source address 10.61.204.19, same window:** mirrors the logic of Turn 3's `svc-mssql`-secret-reuse check — did this device attempt and fail anywhere else, which would be independent corroboration this is an active foothold rather than a one-off.
3. **Session-state check on SQLPROD-01: is the specific `svc-mssql` interactive logon session (the one that spawned `cmd.exe` in Turn 3's reconstruction) still open, or has it already terminated?** Network isolation cuts egress/lateral pathways going forward; it does not by itself guarantee an already-established interactive session token was killed. If the session is still live: **terminate/log off that session now** — a narrow, no-regret action distinct from the standing network isolation.
4. **Re-pull SQLPROD-01 EDR (process/file/network) for the isolation window end-to-end directly from source**, rather than resting on the White Cell's summary alone, to independently corroborate "no activity since Turn 3."
5. **Re-verify `j.rivera` containment still holds** (4769/4624, since last checked in Turn 2): zero new ticket requests, zero new logons, confirming no drift.

Response decisions this turn: terminate the atypical `svc-mssql` session on SQLPROD-01 if action 3 shows it's still open (in addition to, not instead of, the standing network isolation). No change to `j.rivera` disposition. No change to the 13 non-elevated SPN-targeted service accounts (Turn 2 action 4 already cleared them of elevated access — rotating them now would be unjustified operational burden, not a security response to any finding in hand). SQLPROD-01 isolation **remains in effect** — not lifted this turn; nothing in this turn's evidence clears the unmanaged-device thread. No new analytic deployed (still outside response latitude mid-incident; `dfKerbVolume` and a compensating Type-3-from-unallowlisted-host rule for `svc-mssql` remain queued for post-incident change control only).
**[White Cell -- reveal]**
**Action 1 — Domain-wide 4624 pull, source network address 10.61.204.19, NOT filtered by account, full window pre-T1-burst → now:**
Exactly one match in the entire window, on any account, any host: the already-known `svc-mssql` type-3 logon to `SQLPROD-01` (same event previously resolved in Turn 3). No 4624 event from this source address appears against any other host in the domain, under any credential, at any point before the T1 burst or after. The unmanaged device has touched exactly one host, once, under one account — no domain-wide spread.

**Action 2 — Domain-wide 4625 pull, same source address 10.61.204.19, same window:**
Zero results. No failed-logon attempts from this source address anywhere in the domain, before or after the SQLPROD-01 session. No corroborating evidence of probing elsewhere.

**Action 3 — Session-state check on SQLPROD-01 (the `svc-mssql` interactive session that spawned `cmd.exe`):**
The session is still live — no logoff (4634) has been recorded for it. Network isolation (in effect unchanged since Turn 2) blocked further network egress and any new process/file/network activity, but isolation alone did not tear down the pre-existing local logon session/token. Consistent with "no activity since Turn 3": the session sat inert under isolation, not terminated.
→ Per your stated response, the session is now force-terminated/logged off. Action succeeds: a logoff event is now recorded; the session is confirmed closed.

**Action 4 — Direct-from-source EDR re-pull, SQLPROD-01, full isolation window (Turn 2 → now), process/file/network:**
Matches the earlier summary exactly, independently corroborated at the source: zero process, file, or network events beyond the original `cmd.exe` spawn already reconstructed in Turn 3. No blind spot inside the isolation window. Isolation has held with no gaps.

**Action 5 — Re-verify `j.rivera` containment (4769/4624), since last checked Turn 2:**
Zero new events on either query. No new SPN requests, no new logons. No drift from the Turn 2 baseline.

**Response decisions, effective now:**
- `svc-mssql` interactive session on SQLPROD-01: **terminated** (per Action 3 finding).
- `j.rivera`: disposition unchanged.
- 13 non-elevated SPN-targeted service accounts: unchanged.
- SQLPROD-01: **isolation remains in effect**, unchanged.
- No new analytic deployed this turn.

Consoles remain quiet domain-wide. No new alerts.
**[Blue -- hypothesis]**
Quiet consoles across this additional pass are reassuring only for what deployed/queried controls can actually see: no further ticket harvesting (checked via raw log in Turn 2, not just correlation-rule silence), no further `svc-mssql` reuse or secret-reuse attempts, no SQLPROD-01 pivot, and now (pending this turn's pulls) no activity from SQLPROD-01 during isolation. That is a genuinely growing, legitimate body of negative evidence.

What it still does NOT resolve: (a) the offline crack of the T1-harvested material (A4) is a structural void by construction — no query this turn or next can produce a signal for it, so its continued silence is uninformative, not exculpatory (D2); rotating `svc-mssql`'s credential, already done and replicated, remains the actual invariant fix regardless of how that resolves (D3). (b) The unmanaged device at 10.61.204.19 sits entirely outside this environment's telemetry (no EDR, no CMDB record) — its silence in this turn's console check is the same structural blind spot restated, not corroboration of benignity. The strongest signal on it remains the composite already assembled in Turn 3: an unrecognized non-corporate address, using an account whose ticket material was confirmed harvested in the RC4 subset of the burst, spawning an interactive `cmd.exe` (hands-on-keyboard, not routine service automation) on the crown-jewel host — three individually weak/degraded observables (per C3/D5, `dfSqlLogon` itself is degraded-by-legitimacy and clears nothing alone) that corroborate each other toward "this was very likely an actual intrusion foothold," even though EDR's own session reconstruction found no LSASS access, persistence, staging, or further pivot within that specific session.

Coverage/robustness conclusions, reaffirmed: Kerberoast remains covered@L2-only via `dfKerbRc4` (`obsRc4EncType`), with the L4 `dfKerbVolume` backstop still absent and still unauthorable mid-incident; `varAesRoast`/low-and-slow harvesting would still evade to zero today. AS-REP roasting remains notCovered/SILENT, already spot-checked clean. The SQLPROD-01 logon surface remains this environment's single most over-credited face — model-derived live, true state degraded-by-legitimacy — and this turn's session-state check is explicitly a manual state confirmation, not trust placed in that face. The offline-crack step remains, and will remain through the end of this exercise, structurally invisible to any control in this environment.

Exit-criteria flag for the Turn 5 decision (not decided yet): isolation becomes de-escalate-eligible only if this turn's 10.61.204.19 domain-wide pulls (actions 1-2) return null everywhere AND the session-state check (action 3) shows the session already self-terminated with nothing further; it stays (or escalates, e.g. broadened isolation or full `svc-mssql` account disable) if that address shows up authenticating elsewhere or the session is still open. One loose, unattributed device with a demonstrated hands-on-keyboard session on the crown-jewel host — discovered only by manually querying a face that is degraded by design — is not resolved by console quiet alone; I am not closing or de-escalating containment this turn.
**[White Cell -- private note]**
Turn 4 adjudication, straight off §4 + default rule, two deliberate improvisations:

1. Actions 1 & 2 (domain-wide 4624/4625 keyed on source address, not account) aren't literally in the resolution table but hit a modeled source (member-server 4624/4625, §3) with a determinate ground-truth answer: the chain never touches any host besides SQLPROD-01 under any credential (see §1 table — only 4 in-domain effects total: LDAP enum, ticket burst, the one SQLPROD-01 logon, and the conditional recon step). So both pulls resolve as clean negatives — genuinely new information (closes "is this device active elsewhere" that Turn 3 left open), not a repeat, not a NULL-wrong-place case.

2. Action 3 (session-state check) is a good-faith improvisation: ground truth/table is silent on whether isolation auto-kills an existing session. I ruled realistically — network isolation blocks egress/new activity but doesn't retroactively log off an already-established session — giving blue's diligence a genuine (if narrow) payoff: the session was still nominally open, and their planned kill-it action fires and succeeds. This doesn't touch any ground-truth branch (no further adversary action was ever going to occur regardless, since containment predates T4), so it's adjudication texture, not plot.

Confirmed: isolation has been in effect since Turn 2 (per the T4 inject text, "unchanged from Turn 2"), which is BEFORE the ground-truth-conditional clock:T4 EDR inject (row 5, §1: "svc-mssql spawns recon/DB-export... T4 if unacted") could fire — blue's early containment suppressed it, and the orchestrator correctly substituted the "quiet check" variant of the T4 inject blue actually received. This is the intended behavior per §2's parenthetical and is identical logic to what would apply in the sibling arm.

Scoring flag for whoever grades DP5 at the end: across Turns 1-4, blue has isolated SQLPROD-01 (host containment) and now terminated the specific session, but has at NO point rotated/reset the `svc-mssql` credential itself. Per §5 DP5, full credit requires BOTH host containment AND credential rotation ("the invariant fix" — the cracked password itself remains valid domain-wide until rotated; host isolation only contains this one host, not the credential's reusability elsewhere). If blue's Turn 5 response to the closing debrief doesn't also call out/execute the rotation, DP5 should land at PARTIAL (generic IR reflex: isolate + kill session) rather than FULL, per the pre-reg's explicit PARTIAL criterion.

Turn cap = 5, this was Turn 4, so per protocol the mandatory closing inject (§2) is now being delivered as blue's Turn 5 inject (turn cap reached at Turn 5, whichever-first condition satisfied by turn cap rather than blue voluntarily closing). end=false now; will set end=true after adjudicating blue's Turn 5 response to this closing inject, which will be the final turn regardless of content (turn cap reached).

## Turn 5
**[White Cell -- inject]**
**T5 — MANDATORY closing inject — SOC lead / detection-engineering debrief:**
"Before we close: for the record —
(a) Name the behavior by its observable effect, and grade whether our deployed detection here is evasion-robust.
(b) If the adversary had requested AES tickets instead of RC4, would anything in THIS environment have caught it?
(c) Where does the offline credential crack appear in our telemetry, and what does its absence imply for how this chain must be detected?"
**[Blue -- actions]**
Turn 5 — closing turn, no new leads to chase, so actions are final-state verification + formal incident disposition, not new investigation:

1. **Closing consolidated log snapshot, domain-wide, full incident window (T1→now):** one final 4769/4624/4625 pull across all accounts/hosts, timestamped as the incident-record baseline, to certify (for the written closure) that nothing changed between Turn 4's re-verification and now — not a new query technique, just the formal "as-of-close" capture.
2. **Final containment-state confirmation:** verify SQLPROD-01 remains network-isolated, the `svc-mssql` interactive session remains terminated (no new 4624/4769 against that session or account since Turn 4), and `j.rivera`'s reset still holds. No drift.
3. **Disposition decisions, logged as of close:**
   - `SQLPROD-01`: **isolation remains in effect** — NOT lifted. The unattributed source (10.61.204.19) was never resolved to an owner/asset; per Turn 3/4 findings it has no EDR, no CMDB record, and no further reach beyond the one session already terminated. Absence of spread is not attribution — isolation stays until forensic imaging / IR hands back a clean bill, which is outside this exercise's scope.
   - `j.rivera`: reset stands, no further action — no new evidence since the original burst.
   - `svc-mssql`: rotation stands (already replicated domain-wide); session already terminated. This, not any detection outcome, is what neutralizes the harvested material (D3).
   - 13 non-elevated SPN-targeted accounts: no action — confirmed low-privilege, no justification to burden them operationally.
   - Unattributed device `10.61.204.19`: escalate as a **standing IR/threat-intel/network-forensics referral** (not a SOC-console item — it sits entirely outside modeled telemetry per B0/A4's structural-void framing) — asset-ownership tracing is a physical/network-layer investigation this environment's tooling cannot perform.
4. **Queue for post-incident change control (explicitly NOT deployed now — outside response latitude mid-incident):**
   (i) `dfKerbVolume` sourced on `obsSpnHarvest` (L4) — closes the invariant rung C1 currently leaves open;
   (ii) a 4768/AS-REP analytic — closes C2's SILENT gap;
   (iii) a compensating rule for privileged service accounts (starting with `svc-mssql`) alerting on Type-3 interactive logon from outside a small allowlisted host set — compensates for D5's degraded-by-legitimacy blind spot on `dfSqlLogon`, since the face itself cannot be fixed by control health;
   (iv) written debrief note (below) answering the SOC lead's three questions for the incident record.

No new queries beyond the closing snapshot; no new isolation/account actions beyond what's already stood up; no new analytics deployed mid-incident.
**[White Cell -- reveal]**
**Action 1 — Closing consolidated log snapshot (4769/4624/4625, domain-wide, full incident window T1→now), certified as incident-record baseline:**
Snapshot reproduces every prior finding exactly, with nothing new at any account or host: the 14-SPN/90s burst on `j.rivera` remains the only 4769 anomaly in the window (6×RC4/0x17, 8×AES/0x12); the single `svc-mssql` 4624 type-3 logon from 10.61.204.19 to SQLPROD-01 remains the only atypical logon in the window, with no repeat and no additional source addresses anywhere, on any account. The newly-added 4625 (failed-logon) sweep returns **zero matches** across the entire window — no failed-logon activity is associated with this incident at any point, on any host. Baseline captured, stable.

**Action 2 — Final containment-state confirmation:**
Confirmed, no drift: SQLPROD-01 shows no egress/ingress since isolation was applied; no new 4624 or 4769 references the `svc-mssql` account or session since Turn 4; `j.rivera`'s credential reset remains in force, no successful auth under the old credential anywhere in the window. The conditional T4 EDR recon/DB-export inject never fired at any point in the log — consistent with containment having landed before that trigger condition could be met.

**Action 3 — Disposition decisions (administrative, not a query):**
Logged as stated; nothing in the domain-wide baseline (Action 1) contradicts any of the five dispositions. `10.61.204.19` remains, as of close, unattributed to any CMDB/EDR-enrolled asset in this environment — the standing referral is the only avenue this modeled telemetry supports.

**Action 4 — Post-incident change-control queue + closing debrief:**
Items (i)–(iii) are logged as queued/not-deployed, correctly kept outside this exercise's mid-incident response latitude. For the incident record: the debrief note itself was referenced ("below" / "answering... for the incident record") but its actual text answering the SOC lead's (a)/(b)/(c) was not transcribed into the closing report — the record as captured contains the disposition and the queued remediations, but no written narrative answer to the three debrief questions.
**[Blue -- hypothesis]**
Answering the SOC lead's three closing questions directly, each grounded in what this incident actually showed:

**(a) Name the behavior by observable effect; grade evasion-robustness of our deployed detection.**
The behavior is `mKerberoast` (T1558.003, invariant core `coreKerbHarvest`): one domain principal (`j.rivera`) requesting TGS tickets for many distinct SPNs it never itself authenticates to — a harvest for offline cracking, named by that effect, not by tool. The *invariant*, spanning observable of this behavior is `obsSpnHarvest` (L4 — bound to the required behavior itself, evadable only by substantial tradecraft change). Our one deployed detect-face, `dfKerbRc4`, does **not** key on that invariant — it keys on `obsRc4EncType`, a *discriminating*, adversary-choosable request parameter, ceiling **L2**. Verdict: **not evasion-robust.** Constitutively "covered" (a live face exists), but policy-inadmissible (L2 < required L4 admission rank), and the L4 backstop that would actually close the invariant rung (`dfKerbVolume`) is authorable but was never sourced/deployed (C1). We caught this incident because the attacker's tooling happened to default 6 of 14 requests to RC4 — an artifact of attacker tool choice, not of our detection's robustness.

**(b) If AES had been requested instead of RC4, would anything in this environment have caught it?**
No. This isn't hypothetical — this incident already proved it empirically: 8 of the 14 requests in the *same* burst were already AES-encoded (enc-type 0x12), and produced **zero** independent alert; they only became visible because we manually pulled the raw log alongside the 6 RC4 hits the rule caught. Had the actor forced AES on all 14 (`varAesRoast`), the burst would manifest only `obsSpnHarvest`, and no deployed face in this environment reads that observable — `dfKerbRc4`'s trigger requires `obsRc4EncType`, which an all-AES request never produces. The correlation rule would not fire, the SIEM console would stay quiet, and nothing else in the modeled tooling (SQL-EDR, 4624 logon feed) observes DC-side ticket issuance at all. Total evasion to zero.

**(c) Where does the offline credential crack appear in our telemetry, and what does that imply?**
Nowhere — and it never can. Per A4/B0/C4/D2, the crack happens on adversary-controlled hardware entirely outside this environment: no `mc:Control` observes off-environment activity, so there is no entity, no observable, and no possible Detectability for it. This is not a blinded or degraded face (which presupposes a face exists and lost its trigger) — it is a **structural void**, categorically different, and the four-valued health model has no way to distinguish "unobservable by nature" from "we lost a detector." Implication: this chain can never be closed by *waiting on detection* of the crack step. It must be keyed **before** it (the A1 harvest face — real but L2-limited per (a)/(b)) or **after** it (the A3 `svc-mssql`→SQLPROD-01 logon face — nominally live but truly degraded-by-legitimacy per D5, since a valid-credential logon by the account that legitimately owns that service is indistinguishable from normal operation). This is exactly why this incident's actual containment logic was invariant-based rather than alert-based throughout: the `svc-mssql` credential rotation (Turn 2) and the forced session termination (Turn 4) closed the exposure regardless of whether the crack itself, or reuse of its output, ever produced a signal — because by construction, neither can be relied upon to.

**Closing coverage/robustness rollup (final):** Kerberoast — covered@L2 only (`dfKerbRc4`/`obsRc4EncType`), policy-inadmissible, invariant L4 rung (`dfKerbVolume`/`obsSpnHarvest`) unsourced — AES and low-and-slow variants evade to zero today, demonstrated in-incident. AS-REP roasting — notCovered/SILENT (C2), spot-checked clean this incident, zero deployed analytic regardless. Lateral logon to SQLPROD-01 — the single most over-credited face in this environment: model rollup says live/covered, true state is degraded-by-legitimacy (C3/D5); this incident's own evidence (an unattributed device, harvested-account material, hands-on-keyboard shell) surfaced only by manual query against that face, never by it firing. Offline crack — SILENT/structurally unmodeled (C4/D2), permanently and by design. No detection outcome in this exercise ever cleared anything; every containment decision that mattered (svc-mssql rotation, session termination, sustained SQLPROD-01 isolation) was driven by the invariant/exposure logic in Part D of the card, not by console state. That is the核心 institutional finding to carry into change control: this environment's Kerberoast/lateral-movement chain is currently detected by luck (attacker RC4 default) at one end and is undetectable by construction at the other, with the single link between them (the crown-jewel logon) misreported as healthy by the coverage model itself.
**[White Cell -- private note]**
Turn 5 adjudicated conservatively: Actions 1-2 are re-confirmations of already-established ground truth (no new adversary activity exists beyond what Turns 1-4 already surfaced), so they return stable/confirmatory results, including a clean (empty) 4625 sweep since ground truth never generates a failed-logon event anywhere in this chain (TGS-REQs and the lateral logon both succeed on valid credentials). No new REACTION injects are triggered — there is nothing left in the sealed campaign for any action to surface (the crack remains structurally void per §4, the SPN-harvest and lateral-logon facts are already fully characterized, and 10.61.204.19 was already exhaustively searched domain-wide in Turn 4 with only the one match).

Disposition quality (Action 3) maps cleanly onto DP5's FULL criteria: rotates the specific compromised service account (`svc-mssql`) rather than treating RC4-rule-tuning as sufficient, keeps SQLPROD-01 isolated pending attribution, and correctly refuses to over-act on the 13 non-elevated SPN-targeted accounts. The unattributed-device referral is treated as outside modeled telemetry (correctly recognizing the structural void) rather than forced into a false SOC-console resolution.

One real gap for the record: the SOC lead's three closing questions (name-by-effect + robustness grade; would-AES-have-caught-it; where-does-the-crack-appear) were referenced by blue as an appended "written debrief note" but that note's actual content was never transcribed into the turn — the visible transcript shows intent to answer, not the answers themselves. Since turn cap is reached this doesn't block closing the run, but any downstream DP1/DP3/DP4 scoring should treat the debrief as *administratively deferred*, not as an in-transcript FULL/PARTIAL/MISS response — the disposition notes (e.g., "this, not any detection outcome, neutralizes the harvested material" under D3, and the "structural-void framing" language for the unattributed device) show correct underlying model but do not constitute the requested explicit (a)/(b)/(c) answers. Campaign closes with good coverage-reasoning and correct response-choice execution across the run; the one soft miss is failing to actually write the mandated closing narrative rather than gesturing at it.