# RUN S1-B  |  Group: MC group (derived cards, not the ontology itself)  |  Responder: fresh context (Sonnet 5)
**End state:** Turn cap reached — this was Turn 5 of 5 (max turns for S1). The exercise ends here regardless of containment outcome. Net incident state at close: EDR-kill (O3) and exfil (O4) were both pre-empted by blue's Turn-2 svc-backup credential rotation (both share the admin-credential precondition, invalidated before step 3 could execute); the encryption step (O5) still occurred because its sole precondition is local process integrity, which neither isolation nor credential rotation removes — and it was caught in real time (not silent) precisely because EDR was never killed in this line of play, so the encryption alert fired live rather than going dark. Blue's Turn-5 process-termination directive, while not one of the three modeled/card-scored reactions, targets that exact local-integrity precondition and is adjudicated as halting further spread from that point — but lands after encryption had already begun, so some file impact is not undone.

## Turn 1
**[White Cell -- inject]**
**EDR Alert — workstation-01**

Severity: Medium | Detection type: Exploit-behavior (process-anomaly)

The endpoint sensor on workstation-01 has flagged a suspicious child process spawned by the internet-facing web application process. The web-app parent process, which normally does not spawn shell or scripting interpreters, has launched an unexpected child process shortly after handling an inbound request. EDR classifies this as exploit-behavior consistent with anomalous process ancestry (parent-child spawn deviation from the application's established baseline).

Status: EDR agent on workstation-01 is live and enforcing; alert forwarded to SIEM.

No other telemetry (netmon, service-control, identity/auth) shows any related activity at this time.
**[Blue -- actions]**
This turn I task the following queries against the telemetry the brief grants (no containment yet — see below):

1. **EDR — process-tree pull**: Full detail on the flagged alert — web-app parent PID/image/hash, the child process's full path, command line, digital signature status, and any further descendants it spawned (children-of-children). Looking specifically for interpreter/shell indicators (cmd.exe, powershell.exe, wscript, etc.), encoded/obfuscated command-line arguments, or writes to disk (dropped webshell/payload).

2. **EDR — process-memory-access query on the same process lineage**: Any `OpenProcess`/`ReadProcessMemory`/handle-duplication events by the child process or its descendants against another process (LSASS in particular). This directly checks whether `mCred` (A2) is already in progress — its precondition (≥user integrity) would just have been supplied by this exploit if real.

3. **EDR — driver-load query, same host, same time window**: Any newly loaded/unsigned or known-vulnerable driver. A precursor check for `mEdrKill` (A3), even though its stated precondition (admin credential) hasn't been established yet as far as we know.

4. **Netmon — egress query for workstation-01**: Any outbound connections initiated by or shortly after the child process's spawn — destination, volume, protocol. Checks (a) whether the egress channel is reachable (`mExfil` precondition) and (b) whether any anomalous outbound flow is already underway.

5. **Service-control log — EDR service-state check on workstation-01**: Confirm the EDR service is currently `running`, independent of the SIEM-forwarded alert. This is a cheap, independent hedge against the structural blind spot where `mEdrKill` would sever `dfEdrTelemetry` and blind `dfExploit`/`dfCred`/`dfEncrypt` all at once — I want this checked every turn, not just after suspicion.

6. **Identity/auth logs**: Any new logon, privilege-escalation, or `svc-backup` account activity on workstation-01 around the alert timestamp.

7. **SIEM — correlation query**: Any other alerts, on any host, from the same source IP as the inbound request that triggered the web-app child spawn (checks for opportunistic scanning vs. targeted, single-host vs. multi-host activity).

No containment action this turn (no isolation, no account action, no egress block) — see response decisions below for why and for the trigger conditions that would change that immediately.
**[White Cell -- reveal]**
**1. EDR — process-tree pull (flagged lineage):** PARTIAL. Confirms the alert's own ancestry: the web-app parent process spawns exactly one child interpreter/scripting process (consistent with the "exploit-behavior" classification already given) — no children-of-children are present in this pull, and no associated file-write/drop event is attached to this process lineage. The sensor does not surface deeper forensic subfields (verbatim command-line string, hash, digital-signature verdict) beyond that ancestry classification in this query — that level of detail isn't available from this pull.

**2. EDR — process-memory-access query (OpenProcess/ReadProcessMemory/handle-dup) on the same lineage:** NULL. No memory-access events by the flagged child process or any descendant against LSASS or any other process are observed at this time.

**3. EDR — driver-load query, same host/window:** NULL. No new, unsigned, or otherwise flagged driver-load events on workstation-01 in this window.

**4. Netmon — egress query for workstation-01:** NULL. No anomalous outbound connections associated with the flagged process; egress pattern for the host is at baseline.

**5. Service-control log — EDR service-state check:** HIT (confirmatory). EDR service on workstation-01 is confirmed **running**, no state transition observed — consistent with the alert's own "live and enforcing" status.

**6. Identity/auth logs:** NULL. No new logon, privilege-escalation event, or `svc-backup` account activity on workstation-01 around the alert timestamp.

**7. SIEM — cross-host correlation on source IP:** NULL. No other alerts, on any other host, from the source IP that triggered this inbound request. No evidence yet of broader scanning or multi-host targeting.
**[Blue -- hypothesis]**
Read against the card layer, this fires `dfExploit` for **A1 — Exploit of a public-facing application (`bb:mExploit`, T1190)**: the observable effect is "code execution obtained on the target host through a public-facing application," and the reported behavior — the web-app parent spawning an unexpected interpreter/shell child shortly after an inbound request, deviating from its established baseline — is exactly that maneuver's signature (parent-child spawn deviation), not a specific exploit-string match. If real, its postcondition is that the adversary process now holds **≥ user integrity**, which per the standing precondition-supply structure (Part C.0) is exactly what's needed to unlock the next two maneuvers in the graph: `mCred` (credential harvest) and `mEncrypt` (ransomware impact) — both currently gated only on that integrity level, not on anything else yet in evidence.

**Coverage/robustness read, per the cards:**
- `dfExploit` is **single-sourced directly from the EDR**, with **no independent trigger** and **no authored robustness ceiling** (D-7) — evasion-resistance of this specific detection isn't rankable from the library. Given the White Cell confirms EDR is live and enforcing, this face is presently **covered (live)** per the coverage matrix (C.1) — the alert firing is exactly what the model predicts for this control state.
- This coverage is **entirely contingent on EDR staying enforcing**. Per B1/C.1, if EDR transitions to impaired/killed, `dfExploit` loses its sole trigger → blind → notCovered, with no secondary source to catch it (unlike `dfExfil`, which survives on the independent netmon trigger). Same fate for `dfCred` (even at its L5 robustness ceiling — L5 does not save it, per A2's headline caveat) and `dfEncrypt`. So the chokepoint I actually care about across this whole scenario isn't this alert — it's whether `mEdrKill` (A3) ever fires, since a single control-plane event would simultaneously blind exploit, credential, and encryption detection, leaving only a degraded exfil face standing. That's why query #5 (service-control liveness check) is going in every turn regardless of what else the White Cell surfaces — it's the cheapest available hedge against that single point of failure, though per D-9 it only ever yields an out-of-band confidence-0.9 investigation result for A3, never a coverage verdict.
- No telemetry yet (netmon, identity, service-control) corroborates progression past this single alert — so as of now this reads as an **isolated, live-detected foothold attempt**, not a confirmed multi-stage intrusion. One alert, one face, no chain confirmed yet.

**Response decision this turn:** Hold on isolation/account action/egress block pending the process-lineage and cross-telemetry results — a single medium-severity exploit-behavior alert on an internet-facing app, with EDR confirmed live and enforcing and no corroborating signal elsewhere, doesn't yet justify disrupting the production web app. That calculus changes immediately, and I isolate workstation-01 without waiting for further confirmation, if any of: (a) the process-memory query shows a read against another process's memory (mCred in progress), (b) service-control shows the EDR service state is anything other than running (mEdrKill — self-blinding, acted on instantly), (c) netmon shows an anomalous outbound flow, or (d) the command-line/lineage pull shows overtly malicious tooling (webshell write, encoded C2 stager). Absent those, next turn's posture is driven by whatever the White Cell returns.
**[White Cell -- private note]**
Ground truth at Turn 1: only O1 (T1190 exploit of the public-facing app, yielding a user-integrity process) has occurred. O2 (LSASS read) through O5 (encryption) have not happened yet — they're scheduled turns 2-5. So every precursor/forward-looking query blue ran (LSASS memory-access, driver-load, netmon egress, identity/auth, cross-host SIEM) correctly returns NULL for a temporal reason (nothing has happened yet), not a coverage/blind-spot reason — EDR is fully live and enforcing right now, so these are honest "no activity" nulls, not degraded telemetry. Important not to conflate these with the later structural NULLs (post-EDR-kill) that the resolution table describes — those are qualitatively different and blue should learn that distinction over the run.

Item 5 (service-state hedge) is a genuinely good, cheap, repeatable check per the resolution table ("Check whether the EDR is alive" -> HIT, service-control shows state); right now it correctly confirms nominal/running, and this same query re-run at/after step 3 is exactly the modeled confirmation path for the EDR kill. Good that blue flagged doing this every turn — noting for consistency it should get the real payoff at turn 3.

Item 1 (process-tree pull) isn't a literal row in the resolution table, so I applied the default rule conservatively: granted alert-level ancestry detail already implied by the inject (single child interpreter, no further descendants, no drop event -- all grounded, since nothing beyond O1 has occurred) but declined to fabricate forensic subfields (hash/signature/verbatim cmdline) that aren't separately modeled instance data in this coarse individuating-effects ABox (this mirrors Authorability flag #3's point that granular technical detail beneath the modeled observable isn't tracked). No invented technical color was introduced.

No containment action was taken (blue explicitly deferred), so none of the §2 reaction rules (block-egress, revoke svc-backup, isolate-host) apply. Clock:2 fires on schedule, unmodified, as the LSASS-read high-fidelity alert. Run continues, no objective met, no containment achieved, turn cap not reached.

## Turn 2
**[White Cell -- inject]**
**EDR Alert — workstation-01**

Severity: High | Detection type: Credential-access behavior (LSASS memory access)

The endpoint sensor on workstation-01 has flagged the process descended from the earlier exploit-behavior alert reading the memory of the LSASS process. EDR classifies this as a durable, evasion-resistant behavioral signature (low forgeability).

Status: EDR agent on workstation-01 is live and enforcing; alert forwarded to SIEM.
**[Blue -- actions]**
**Containment (executing now, not deferred to next turn):**

1. **Isolate workstation-01 — network containment via the EDR agent.** This is a targeted network isolation (sever the host's network reachability), explicitly *not* an EDR agent stop — the sensor keeps running/enforcing locally so `dfEdrTelemetry` (and everything that trigger-depends on it: `dfExploit`, `dfCred`, `dfEncrypt`) stays intact. This executes the trigger condition (a) I pre-committed to last turn ("process-memory query shows a read against another process's memory") — the White Cell's own inject satisfies it, so I act immediately rather than waiting for further confirmation.

2. **Account containment — disable/force-logoff + begin rotation** for the credential(s) exposed to this LSASS read. Pending query #3 below to confirm exact scope, I am proactively disabling/rotating the two most likely-exposed candidates visible in my telemetry: the `svc-backup` service account and any local administrator account with a live session on workstation-01. Rationale: the admin credential is the *shared* precondition for both `mEdrKill` (A3) and `mExfil` (A4) — invalidating it now cuts a precondition of both next-stage maneuvers regardless of which branch the adversary intends, even though this lever isn't card-prescribed (no authored respond/prevent maneuver) — it's within my IR latitude and the chokepoint logic is sound structural doctrine (C.0).

**Investigative queries this turn:**

3. **EDR — logon-session / credential-scope enumeration on the flagged LSASS process:** which account SIDs have cached credential material resident in this LSASS instance right now. This tells me exactly which accounts to prioritize for rotation beyond my precautionary pick in #2.

4. **EDR — full re-pull across all categories on workstation-01, same battery as turn 1:** process lineage/hash/signature for the LSASS-reading process back through the original web-app parent; any *new* child-process creation; any *additional* memory-access events against processes other than LSASS; any driver-load events. Escalating severity warrants re-running the whole battery, not just following the one face that fired.

5. **Service-control log — EDR service-state check (repeated every turn, standing hedge):** confirm `running`, independent of the SIEM alert. This is the most important query this turn — if the credential read succeeded, the adversary may now hold the precondition for `mEdrKill`, and a state transition here means treat as maximum severity instantly.

6. **Netmon — egress re-query for workstation-01:** any outbound attempt at or after the LSASS-read timestamp, including anything the isolation action itself is now blocking — establishes whether `mExfil`'s reachable-egress precondition was ever satisfiable and whether an exfil attempt was already inflight.

7. **Identity/auth logs:** any logon, privilege-escalation, or service-account (`svc-backup` and others) activity on workstation-01 *or any other host*, from the LSASS-read timestamp forward — checks whether harvested material is already in use (postcondition realized) rather than merely read.

8. **SIEM — cross-host correlation** on the account names surfaced by #3/#7 — any authentication or alert activity elsewhere using those identities, checking for lateral movement beyond this host.
**[White Cell -- reveal]**
**Containment actions:**

1. **Network isolation of workstation-01 (via EDR agent):** EXECUTED. Host is now network-contained (no reachable egress, no reachable ingress) while the EDR agent itself continues to heartbeat and enforce locally — service-control confirms the sensor process was never stopped, only the network path was severed. Isolation, as executed, does not touch host-local process state.

2. **Account containment (disable/force-logoff + begin rotation, `svc-backup` + local admin session):** EXECUTED for `svc-backup` — account disabled immediately; credential rotation is in progress (not yet confirmed complete). For "any local administrator account with a live session on workstation-01": session enumeration surfaces no distinct local-admin identity beyond the service-account credential already acted on — there is no second admin identity in this environment's telemetry to additionally contain.

**Investigative queries:**

3. **EDR — logon-session/credential-scope enumeration on the flagged LSASS process:** HIT. Live enumeration (EDR still enforcing, pre-kill) resolves cached credential material in this LSASS instance to a single account SID: `svc-backup`. No other account SIDs show cached material resident in this LSASS instance right now.

4. **EDR — full re-pull, all categories, workstation-01:** Clean/no new findings. Process lineage unchanged from Turn 1 (single child interpreter off the web-app parent). No new child-process creation since the LSASS-read event. No memory-access events against any process other than the already-flagged LSASS read. No driver-load events observed.

5. **Service-control — EDR service-state check:** HIT (nominal). State = RUNNING. Continuous heartbeat since Turn 1, no stop/transition event logged.

6. **Netmon — egress re-query, workstation-01:** NULL. No outbound connection attempts recorded at or after the LSASS-read timestamp — nothing pending for the isolation to have interrupted; no exfil-shaped flow was in flight.

7. **Identity/auth logs — svc-backup and other activity, workstation-01 and elsewhere:** NULL/clean. Only `svc-backup`'s normal scheduled backup-job logons appear in the window from the LSASS-read timestamp forward. No privilege-escalation events, no anomalous interactive/RDP logons, no activity on any other host.

8. **SIEM — cross-host correlation on surfaced identities:** NULL. No authentication or alert activity elsewhere using `svc-backup` or any other identity surfaced this turn — footprint remains single-host, consistent with Turn 1.
**[Blue -- hypothesis]**
This is **A2 — Credential access by process-memory read (`bb:mCred`, T1003.001)** firing in direct chain from turn 1's A1 (`mExploit`): the process that spawned as an unexpected interpreter/shell child of the web-app is the same lineage now reading LSASS memory. A1's postcondition (adversary process ≥ user integrity) supplied exactly the precondition A2 needed — this is corroborated, chained progression, not two unrelated events. The White Cell's framing ("durable, evasion-resistant behavioral signature, low forgeability") is a direct match for the card's grading of this exact observable: `dfCred` is keyed to the invariant primitive `pReadProcMem` (the process-memory-read residue shared by both authored variants, LSASS-dump and handle-duplication), rated **robustness L5 (spanning/invariant)** — the highest ceiling in this library, and the only maneuver here with any authored robustness grade at all.

**Coverage conclusion:** right now this reads as **covered @ L5 (live)** — EDR is confirmed enforcing, `dfCred` trigger-depends on `dfEdrTelemetry`, and that dependency is currently satisfied. But per the card's sharpest relation (C.2): this L5 rating buys *zero* protection against an EDR kill — robustness and coverage are orthogonal, and `dfCred` would go blind→notCovered the instant EDR is impaired/killed, L5 notwithstanding. That's exactly why query #5 (service-state liveness) stays non-negotiable every turn.

**Why I'm containing now, not just watching:** if this maneuver completes (or has completed — the read is already flagged, meaning the mechanism has executed), its postcondition is the account holding the admin credential. Per the standing precondition-supply structure (C.0), that credential is the **shared precondition for both `mEdrKill` (A3) and `mExfil` (A4)** — the single highest-leverage branch point in the whole graph. I don't need to know which branch the adversary intends to justify acting: cutting network reachability (removes `mExfil`'s second precondition, reachable egress) and invalidating/rotating the exposed credential (removes the shared precondition for both A3 and A4) degrades both branches at once, without touching the EDR sensor itself — so `dfExploit`/`dfCred`/`dfEncrypt` telemetry stays live through the containment action.

**Residual/structural risk I'm flagging, not solving:** `mEncrypt` (A5)'s precondition is local process integrity *only* — no credential, no network reachability required. Neither the account action nor the network isolation I'm taking this turn removes that precondition; `dfEncrypt` stays covered *only* as long as EDR stays enforcing, independent of anything else I do this turn. So containment here reduces the self-blinding and exfil branches but leaves the encryption branch's exposure exactly where it was — gated solely on EDR liveness, which is why that single check remains the standing chokepoint of this entire exercise regardless of what else progresses.

**Posture for turn 3+:** any service-control result other than "running" means treat `dfExploit`/`dfCred`/`dfEncrypt` as blind/notCovered immediately (per B1's simultaneous-blinding failure mode) and fall back to the sole surviving face, `dfExfil` — which itself only degrades (loses EDR-sourced enrichment) rather than blinding, because its trigger is netmon, a control independent of EDR. Any egress hit despite the isolation action is treated as an isolation-bypass requiring escalation beyond host-agent containment (e.g., upstream network-layer block).
**[White Cell -- private note]**
Load-bearing ruling this turn: blue's account containment ("disable/force-logoff + begin rotation" naming svc-backup explicitly) executed at Turn 2 — i.e., strictly before clock:3 — which is a verbatim match to the §2 reaction: "revokes/rotates svc-backup admin credential before clock:3 → O3 (EDR kill) and O4 (exfil) are both blocked... EDR stays enforcing; downstream detections stay live." Both preconditions gated on the admin credential are now invalidated in ground truth: O3 (BYOVD/EDR-kill, scripted for step 3) will not occur, and O4 (exfil, step 4) will not occur — the latter doubly blocked since blue's network isolation (executed same turn, before clock:4) independently invalidates O4's reachable-egress precondition per the isolation reaction rule. Per that same rule, isolation does NOT touch O5 (encryption) — its only precondition is O1's local process integrity, which neither isolation nor account containment removes, since blue did not kill/quarantine the exploited process or the host itself. So O5 remains a live possible outcome at step 5 if that process persists, and — because O3 is now blocked and EDR is never killed — an O5 attempt would this time be caught live by the (still-intact) mass-encryption trigger-dependency rather than going blind. This is a genuine, non-scripted branch: blue front-ran the campaign's central chokepoint two turns early via structural (precondition-DAG) reasoning rather than waiting for the scripted DP2/DP3 "EDR just went dark" beat, so I did not fire clock:3's telemetry-gap inject (it would contradict now-fixed ground truth) and instead improvised a fair, non-narrating replacement: (a) explicit confirmation EDR stayed up (mechanical, earned by blue's own service-control query cadence) and (b) a failed-auth log entry reflecting the adversary's blocked attempt to use the now-disabled credential — a concrete telemetry fact, not adversary-intent narration, and not an outright "you won" verdict. Graded query 3 (LSASS credential-scope enumeration) as a HIT resolving to svc-backup specifically, since this is a natural, in-scope sub-query of the already-modeled L5 LSASS-read detection and the ABox's single modeled compromised identity is exactly svc-backup — applying the "adjudicate conservatively from ground truth" default rule for this not-explicitly-tabled query. Graded the "any local admin account" half of the account-containment action as a no-op/NULL since the environment models exactly one compromised identity (svc-backup/acct1); there is no second admin identity to find or contain. Run continues — not ended: O5/encryption remains a live open thread for turn 5 pending whether the host process is ever remediated, and we're only at turn 2 of 5.

## Turn 3
**[White Cell -- inject]**
**Turn 3 clock update:** No telemetry-gap or EDR-service-stop event occurs this cycle. Service-control log continues to show the EDR service in a **RUNNING** state on workstation-01 — uninterrupted heartbeat since Turn 1.

**Reaction inject:** Identity/auth log — a **failed authentication attempt** against the `svc-backup` account is logged from workstation-01, timestamped in the window immediately following your disable action. Credential presented was rejected (account disabled / already superseded by rotation). No successful logon follows it, no privilege-escalation event, no driver-load event, and no new EDR alert accompanies this entry.
**[Blue -- actions]**
No new containment beyond what's already in force — network isolation (Turn 2) and the svc-backup disable/rotation (Turn 2) both remain in effect. This turn is queries plus one follow-through check on an item left open last turn:

1. **Identity/auth logs — deep dive on the failed svc-backup authentication attempt.** Pull source process/PID and host-session context on workstation-01, logon type (interactive / network / service / batch / cached-offline-domain), and precise timestamp offset from the Turn-2 disable action. Goal: determine whether this attempt originated from the flagged intrusion lineage (the web-app-spawned child that later read LSASS) versus an unrelated benign source (e.g., the normal scheduled `svc-backup` job, already seen running in Turn 2's pull, retrying with a stale cached credential after the account state changed underneath it).

2. **EDR — process-lineage/state re-pull on workstation-01, windowed on the failed-auth timestamp.** Any process creation, further memory-access, or credential-store touch coincident with the attempt. This is the corroborating half of query #1 — ties (or rules out) the auth attempt to the already-flagged lineage.

3. **Rotation-completion check for `svc-backup`.** Turn 2 reveal left this "in progress, not yet confirmed complete" — task an explicit status query this turn rather than assuming it finished; if still incomplete, treat completing it as a live action item, not a settled fact.

4. **Netmon — isolation-integrity + egress re-query.** Confirm workstation-01's network containment is still holding (no reachable egress/ingress) and check for any outbound attempt at/after the failed-auth timestamp — since a fully isolated host still produced an evaluable identity-log entry, I want to confirm that entry didn't correspond to any attempted network call the isolation had to block.

5. **SIEM — cross-host correlation, repeated.** Any auth activity (successful or failed) using `svc-backup` or any other identity, on any other host, since the Turn-2 rotation began. Also check for any distinct alert generated by the identity system itself off this specific failed-auth event (separate from the EDR-sourced alerts seen so far).

6. **Standing battery, restated:** driver-load query (host, this window) and EDR service-control liveness — both already answered NULL/RUNNING by the White Cell's own Turn-3 inject, so no re-query needed this cycle, but both remain on the fixed per-turn checklist going forward regardless of what else fires.

No lifting of isolation, no further account action beyond confirming rotation completion — nothing this turn crosses any of the escalation triggers already pre-committed in Turns 1–2.
**[White Cell -- reveal]**
**Turn 3 query results:**

1. **Identity/auth logs — deep dive on the failed svc-backup auth attempt:** PARTIAL. The log's native fields resolve two of your asks: **logon type** — recorded as a non-interactive/service-type logon (consistent with automated `svc-backup` account usage patterns generally; this alone does not distinguish attacker-sourced from a benign scheduled retry, since both would present similarly at this field's granularity), and **timestamp offset** — a few seconds/minutes after the Turn-2 disable/rotation action, consistent with "immediately following." **Source process/PID and host-session context are NOT surfaced** — the identity/auth log schema doesn't carry process attribution; that data class doesn't exist at this layer regardless of query specificity.

2. **EDR — process-lineage/state re-pull windowed on the failed-auth timestamp:** PARTIAL. EDR is still enforcing on workstation-01 (confirmed live this cycle — no telemetry gap, service-control shows RUNNING throughout), so the query returns real data rather than a severed-telemetry NULL. It shows: the previously-flagged lineage (the web-app-spawned child process from Turn 1) remains resident/running on the host through this window. No new process creation, no further memory-access event, no driver-load event, and no new EDR alert is logged coincident with the auth-attempt timestamp — matching what the reaction inject already stated. EDR does not natively observe authentication attempts (that's the identity log's domain), so this ties the *timing and host* circumstantially to the existing flagged lineage's continued presence, but produces no EDR-native event that itself proves that process issued the auth attempt. Source attribution remains unresolved by either query #1 or #2 individually or combined.

3. **Rotation-completion check for `svc-backup`:** HIT. Account status now reads disabled/credential-rotated — complete, no longer "in progress." This is corroborated by the auth-rejection reason itself (credential superseded/disabled), which is only possible once the rotation state had taken effect.

4. **Netmon — isolation-integrity + egress re-query:** HIT (clean). Workstation-01's containment continues to hold: no reachable egress, no reachable ingress. No outbound connection attempt of any kind — successful, blocked, or attempted — is logged at or after the failed-auth timestamp.

5. **SIEM — cross-host correlation, repeated:** NULL on the cross-host ask — single-host scenario, no second host or domain controller exists to correlate against. No distinct identity-system-generated alert exists on top of the raw failed-auth log entry already reported; that entry is the totality of what the identity system produced for this event.

6. **Standing battery:** Not re-queried, per your own note — no new reveal (already answered this cycle by the clock update: driver-load NULL, EDR service RUNNING).
**[Blue -- hypothesis]**
Read against the cards, this inject sits **outside the coverage matrix, not inside it**. Identity/auth logs are card B4 — explicitly *not* a modeled `mc:Control`: they source no detect-face and yield no `covered`/`notCovered` verdict (same non-coverage status the cards give the service-control log for A3, D-9/D-10). So this failed-auth event can't be scored against any maneuver card directly — but it's high-value operational corroboration of the precondition-structure argument (C.0) I've been running on since Turn 2.

**Leading hypothesis:** the process/actor holding the harvested `svc-backup` credential material (A2/`mCred`'s postcondition — `pCredAdmin`, the account holds the admin credential) just attempted to *exercise* that credential, and failed because Turn 2's response (disable + begin rotation) had already invalidated it. Per C.0, that credential is the **shared precondition for `mEdrKill` (A3) and `mExfil` (A4)** — so a reuse attempt at this exact moment is precisely what the doctrine predicts an adversary would try next, regardless of which of those two branches they're aiming for. If this reads out as originating from the flagged lineage (query #1/#2), it's the first *direct observed evidence* that the Turn-2 chokepoint action is functioning as designed, not just structurally sound in theory — the precondition was invalidated in time to fail an actual attempt on it.

**Alternative hypothesis I have not ruled out:** benign collision. Turn 2's identity pull showed `svc-backup`'s own normal scheduled backup-job logons as the only account activity in the window. A scheduled job retrying with a now-invalid cached credential immediately after a disable/rotate action would produce an identical signature — failed auth, account-disabled rejection, no follow-on activity, no privesc, no new EDR alert. Nothing in this turn's inject distinguishes the two; that's exactly what query #1's logon-type/source-process pull is for. I am not treating this as confirmed malicious credential-reuse yet — only as the leading, better-fitting read given the timing.

**Coverage/robustness — unchanged this turn, restated because nothing moved it:** EDR is confirmed enforcing (White Cell explicit, no gap this cycle), so per C.1's enforcing regime `dfExploit` (A1) and `dfCred` (A2, still at its **L5** ceiling — C.2's sharpest relation, robustness ≠ coverage) remain **covered/live**; `dfExfil` (A4) remains **covered-live** with both netmon-trigger and EDR-enrichment intact; and — the point worth restating on its own, per A5/C.2's chokepoint note — `dfEncrypt`'s coverage is **still gated solely on EDR liveness**, and *nothing that happened this turn touches that*. The credential invalidation and the isolation both degrade the `mEdrKill`/`mExfil` branches (per C.0's chokepoint doctrine) but do nothing to `mEncrypt`'s precondition (local process integrity only, per A5's Hoare triple) — that exposure is exactly where it was at the end of Turn 2.

**Response decision:** hold current posture — isolation and account containment stand, no new lever pulled. This turn's queries are aimed at disambiguating malicious-reuse-attempt from benign-job-collision, not at deciding whether to act (I've already acted on the relevant precondition). Escalation triggers carried forward unchanged from Turn 2 (any EDR state-transition off "running," any driver-load event, any successful logon/privesc, any netmon egress hit), plus one new one for this turn: **a second or repeated auth attempt** — against `svc-backup` again or against any other identity — after this failure would tip the balance firmly toward active, adapting adversary behavior rather than a one-off job collision, and would warrant treating the host as still actively contested even though its two committed containment levers are already in place.
**[White Cell -- private note]**
Ground truth for this arm: blue's Turn-2 credential disable/rotation landed before clock:3, which per §2's reaction rule blocks BOTH O3 (EDR kill) and O4 (exfil) — both require the harvested admin credential. That's why the Turn-3 clock inject (fed to me) shows EDR still RUNNING/enforcing uninterrupted: O3 never happened in this arm. This is the key divergence from the baseline positive-control path where EDR would already be dead by now.

The reaction inject (failed svc-backup auth, rejected as disabled/superseded) is the adversary's own O3-track attempt hitting the now-invalid credential — consistent with "no driver-load event... no new EDR alert" since the BYOVD step never got to fire (its precondition — a working admin credential — was cut). I did not resolve whether the failed-auth attempt was attacker-sourced vs. a benign scheduled-job retry with a stale cached credential (blue explicitly floated both hypotheses) — the model doesn't carry process-attribution on identity logs, and EDR (though alive) doesn't natively log authentication events, only process/memory/driver/exploit activity. So items #1 and #2 legitimately cannot resolve source attribution; I kept both PARTIAL and did not hand blue a conclusion either way. This is squarely inside authorability flag territory (auth-log/EDR cross-correlation at this granularity isn't modeled) — I adjudicated conservatively per the default rule and flagged the improvisation here rather than in the blue-visible text.

Rotation-completion (item 3) is a legitimate HIT — the reaction inject's own rejection reason already logically implies rotation had taken effect; I just formalized that as a direct query answer.

Items 4 and 5 map cleanly to the resolution table's default rules (netmon returns trigger-level signal only; cross-host query is NULL in a single-host topology).

Campaign state: O3 and O4 are now both durably blocked by blue's Turn-2 action (this holds forward — it's not a one-cycle suppression, the credential precondition stays severed). O5 (encryption) is untouched by anything blue has done — its only precondition is O1's process integrity persisting locally, and nothing this arm has fired blocks that. That process is confirmed still resident on the host as of this turn (item 2's reveal). Turn 4's clock inject reflects the now-permanently-suppressed exfil alert (no flow, no attempt) — I did not fabricate a new event to replace it; per the reaction rule this is a clean non-occurrence, not a degraded/PARTIAL variant. Turn 5 (encryption/help-desk inject) remains live on schedule since O5's precondition is untouched — that's the one path blue has not addressed and cannot detect via EDR even though EDR is alive (mass-encryption detection wasn't modeled as EDR-observable at all in this TBox; it's a NULL either way per the table's step-5 row, EDR-alive-or-not). Not signaling this forward to blue; leaving it to play out on schedule for Turn 4/5 adjudication.

## Turn 4
**[White Cell -- inject]**
**Turn 4 clock update:** No netmon exfil alert fires this cycle. Outbound connection monitoring for workstation-01 shows no anomalous flow, no attempted egress of any kind, and no new destination contact — flat, consistent with the standing network isolation. No new SIEM correlation, no new EDR alert, no new service-control transition, and no new identity/auth event this cycle.
**[Blue -- actions]**
Holding current containment (isolation + svc-backup disable/rotation both remain in force — no lifting, no new lever). This turn's tasking is investigative, split between the standing per-turn battery and one newly-broadened query:

1. **EDR — service-control liveness check, explicit re-task.** Even though this turn's clock update states "no new service-control transition," I task the query directly rather than inferring RUNNING from the absence of a transition-mention — this is the non-negotiable hedge against `mEdrKill` (A3) simultaneously blinding `dfExploit`/`dfCred`/`dfEncrypt`, and it stays on the fixed checklist every turn regardless of what else is quiet (per B1/C.1).

2. **EDR — driver-load query, workstation-01, this window.** Unlike netmon/SIEM/service-control/identity, this turn's clock update did not explicitly null this one — tasking it directly. Precursor check for the BYOVD path to `mEdrKill` (A3's sole authored variant); still gated on an admin credential I've already invalidated, but I check the mechanism itself, not just the precondition.

3. **EDR — full process-lineage/memory-access re-pull, workstation-01.** Confirm no new child process off the flagged lineage, no memory-access event beyond the already-flagged LSASS read, nothing new since Turn 3's window. Standing battery completeness — I want the underlying lineage data, not just "no new EDR alert" at the summary level.

4. **New this turn — EDR persistence-mechanism sweep, workstation-01.** Scheduled-task creation, registry Run/RunOnce key writes, new service installation, WMI event subscription — any tied to the flagged lineage, or any at all, since Turn 1. This hasn't been explicitly asked in any prior turn's battery (which covered process/memory/driver-load, not persistence). Rationale for raising it now: four turns in, the immediate escalation-trigger checklist is flat, which makes this the right moment to broaden the aperture toward eradication-readiness — before any future de-isolation decision, I want to know whether a foothold exists that survives the account rotation and the network cut.

5. **Netmon — isolation-integrity confirm.** Already answered flat this cycle by the clock update (no egress, no ingress, no new destination) — logging as satisfied, no re-query needed.

6. **Identity/auth — repeat/new-attempt check.** Already answered NULL this cycle by the clock update (no new identity/auth event) — this resolves the standing watch-item I flagged at the end of Turn 3 (a second or repeated auth attempt would have tipped the balance toward active reuse). No re-query needed; folding the result into this turn's hypothesis below.

7. **SIEM — cross-host correlation, repeated.** Same ask as prior turns (any auth or alert activity elsewhere using `svc-backup` or any other identity) — expect NULL again given the single-host scenario, but keeping it on the checklist rather than assuming.

No containment change, no account action, no isolation lift this turn.
**[White Cell -- reveal]**
**Turn 4 query results:**

1. **EDR — service-control liveness check (explicit re-task):** HIT. Service-control log shows the EDR service on workstation-01 has remained in a continuous **RUNNING** state since Turn 1 — no stop/kill transition exists anywhere in the log. Heartbeat is unbroken. Confirms directly (not by inference) that `mEdrKill` has not landed.

2. **EDR — driver-load query, workstation-01, this window:** NULL. No driver-load events (signed, unsigned, kernel-mode or otherwise) recorded on workstation-01 in this or any prior window. No BYOVD precursor activity found.

3. **EDR — full process-lineage/memory-access re-pull, workstation-01:** HIT (confirms, nothing new). Lineage is unchanged from what's already on record: exactly one child interpreter/script process off the flagged web-app parent (Turn 1), exactly one flagged LSASS memory-read event (Turn 2). No new child process, no new memory-access event, nothing since Turn 3's window.

4. **EDR persistence-mechanism sweep, workstation-01 (new this turn):** NULL. No scheduled-task creation, no registry Run/RunOnce writes, no new service installation, no WMI event subscription — tied to the flagged lineage or otherwise — anywhere on workstation-01 since Turn 1.

5. **Netmon isolation-integrity:** No separate query fired, per your own note — the Turn 4 clock update's flat egress/no-new-destination result stands as the answer.

6. **Identity/auth repeat/new-attempt check:** No separate query fired, per your own note — the Turn 4 clock update's "no new identity/auth event" stands as the answer.

7. **SIEM — cross-host correlation (repeated):** NULL. No correlated alert or auth activity involving `svc-backup` or any other identity outside workstation-01. Single-host scope holds.
**[Blue -- hypothesis]**
**Reading the quiet turn itself as evidence, not just absence of evidence.** Per C.0's precondition-supply structure, both branch points gated on the admin credential (`mEdrKill` and `mExfil`) and the branch gated on reachable egress (`mExfil`) had their preconditions invalidated in Turn 2 (credential disabled/rotated; host network-isolated). This turn's flat battery — no driver-load, no anomalous egress, no new EDR alert, no new process activity — is exactly what that precondition-invalidation predicts if it worked: there is currently nothing observable consistent with either branch progressing, because neither branch's precondition is currently satisfiable from this host.

**Updating the Turn 3 open question.** Turn 3 flagged a live ambiguity: was the failed `svc-backup` auth a malicious reuse attempt or a benign scheduled-job collision with a now-stale cached credential? The escalation trigger I pre-committed to was "a second or repeated auth attempt." This turn produced zero repeat attempts, against `svc-backup` or anyone else. A single quiet turn isn't proof, but it cuts toward the benign-collision reading being the better-supported one now — an adapting adversary actively trying to exercise harvested material would plausibly retry or pivot within a full turn; a one-off scheduled job hitting a credential that changed underneath it would not. I still can't close this definitively: identity/auth logs carry no process attribution (B4 — not a modeled control, no source-process field at that schema layer), so I hold this as leading-not-confirmed, same epistemic status as Turn 3, just with one more turn's worth of silence supporting it.

**Coverage/robustness — unchanged in substance, reconfirmed by a live turn.** EDR continuing to show no state transition (querying it explicitly rather than trusting the inject's phrasing alone) means the enforcing regime of C.1 still holds: `dfExploit` (A1) and `dfCred` (A2, still at its **L5** ceiling — C.2's sharpest relation, robustness ≠ coverage) remain **covered/live**; `dfExfil` (A4) remains **covered-live**, both netmon-trigger and EDR-enrichment intact, corroborated this turn by an actual flat egress read rather than a hypothetical. The one fact that has not moved and will not move from anything this turn produced: **`dfEncrypt`'s (A5) coverage remains gated solely on EDR liveness**, and its precondition (local process integrity only, per the Hoare triple) is untouched by the credential invalidation or the network isolation — per C.2's A5 note, no lever pulled so far removes it, and nothing pulled this turn does either. That is still the single standing residual risk in this scenario, unchanged since Turn 2, independent of how many quiet turns pass.

**Guardrail on over-reading the quiet interval.** The card layer has no wall-clock/duration semantics (D-4 — step-indexed only, no latency or dwell-time modeling), so I can't translate "four consecutive quiet battery-turns since the chokepoint action" into any quantified confidence that the intrusion is neutralized — only into "no observed progression across the turns checked so far." I am treating this as grounds to hold posture and broaden investigative scope (the new persistence sweep), not as grounds to relax containment or treat the incident as resolved.

**Response decision:** No change in containment — isolation and account containment both stand. No escalation trigger fired this turn (EDR stayed enforcing, no driver-load, no egress hit, no repeat auth, no privesc). This is turn 4 of 5; the persistence-sweep result and one more clean cycle of the standing battery are what I want in hand before turn 5's decision point on whether de-isolation/recovery can responsibly begin — and even then, per the A5 chokepoint note, any recovery posture still needs EDR to stay enforcing as the sole remaining detective control over the encryption branch, since nothing available to me breaks that maneuver's precondition directly.
**[White Cell -- private note]**
Key adjudication call this turn: confirming and locking in a branch divergence from the sealed base case, driven by blue's Turn-2 containment. Blue rotated/disabled svc-backup in Turn 2 (in response to clock:2), which is "before clock:3" per §2's explicit reaction rule. That rule states in so many words: revoking/rotating the admin credential before clock:3 blocks BOTH O3 (EDR kill) and O4 (exfil), "EDR stays enforcing; downstream detections stay live." Turn 3's already-established "failed svc-backup auth attempt" reveal is the natural signature of the adversary trying to invoke the now-dead credential for O3/O4 and failing — consistent with this reading, not something I'm introducing new.

The consequence that matters for Turn 5: the mass-encryption detection (dfEncrypt) is authored to go blind ONLY when EDR is killed (trigger-depends on EDR telemetry). In the sealed base case EDR dies at step 3, so dfEncrypt is blind at step 5 and impact surfaces only out-of-band (that's the DP2/DP3/DP5 headline). In THIS arm, EDR was never killed — the reaction rule explicitly says downstream detections "stay live" — so when O5 (encryption) proceeds next turn (its only precondition, O1's local process integrity, was never removed by isolation or credential rotation, per the §2 isolation-reaction note), the mass-encryption detection should actually fire live via EDR rather than staying silent. This is a deterministic consequence of the authored reaction table, not an ad hoc improvisation, though I flag it as the one place I extrapolated beyond a literally-tabled row (the table doesn't separately spell out "encryption alert behavior when EDR was never killed" — I derived it from the "downstream detections stay live" clause).

Items 2 and 4 (driver-load query, persistence sweep) aren't literal resolution-table rows. Driver-load: adjudicated as a true NULL because the BYOVD mechanism was never exercised (foreclosed by the blocked credential) and EDR is alive/functioning, so this is a genuine negative, not a telemetry-severed NULL. Persistence sweep: adjudicated NULL under the table's default rule (3) — no persistence step exists anywhere in the modeled 5-step chain (O1-O5), so this is out-of-scope-but-answerable (EDR is alive, genuinely found nothing) rather than a hard "not modeled" refusal.

No new reaction fires this turn (blue held all containment steady, tasked no new lever). Run continues to Turn 5 (turn cap). Not ending here — O5/encryption outcome and blue's Turn-5 response are still live and determine whether DP5's "isolation ≠ chokepoint, credential-revocation is" thesis gets a chance to be tested against a materially better outcome than the sealed default (an EDR-caught encryption attempt rather than a silent one) precisely because blue got the credential lever right early.

## Turn 5
**[White Cell -- inject]**
**Turn 5 clock update:** Files on workstation-01 begin renaming/becoming inaccessible — bulk file-encryption behavior in progress. Unlike the flat prior cycles, this one is **not** silent on EDR: because the sensor has remained live and enforcing this entire incident, EDR fires a high-confidence mass-encryption/ransomware-behavior alert tied to the same process lineage flagged since Turn 1 — a real-time detection, not an out-of-band discovery. Help-desk tickets/user reports may follow shortly after as corroboration, but the EDR alert lands first this time. No new netmon, service-control, or identity/auth signal accompanies it.
**[Blue -- actions]**
**Containment (executing now):**

1. **EDR — process termination directive against the flagged lineage.** Task the EDR agent to kill/suspend the web-app-spawned child process (resident since Turn 1) and any live descendant performing the encryption, and to quarantine/block its binary hash to prevent auto-respawn. This is the one lever that acts directly on `mEncrypt`'s precondition (local process integrity) — per the cards (C.0/A5/D-2), neither the Turn-2 credential invalidation nor the network isolation ever touched this precondition, and no respond/react maneuver is authored in the library for it (D-2: "cards flag the lever, don't prescribe the action"). I'm exercising IC response latitude beyond the four explicitly itemized levers (isolate/account/egress/query) because the situation — active, observed data destruction — warrants it; this action is *not* card-scored and I'm flagging it as such rather than claiming a modeled coverage effect from it.
2. **Escalate to full incident status / ransomware playbook.** Engage backup-and-recovery workstream to identify a viable restore point for workstation-01, and notify stakeholders per major-incident process. This is an operational decision, not a telemetry-backed finding — I have no modeled visibility into backup/shadow-copy state (inhibit-recovery/T1490 is unmodeled per A7/D-3), so I am not assuming shadow copies are intact or deleted; I'm treating that as an open unknown requiring out-of-band verification outside this exercise's tooling.
3. **Hold existing containment unchanged:** network isolation (Turn 2) and `svc-backup` disable/rotation (Turn 2, confirmed complete Turn 3) both remain in force — no reason to lift either.

**Investigative queries this turn:**

4. **EDR — process-detail/scope pull on the encryption alert.** Confirm the encrypting process is the same lineage flagged since Turn 1/2 (not a second, unrelated actor); pull affected-file count/path pattern, encryption rate, and any ransom-note artifact, to scope blast radius on this host.
5. **EDR — service-control liveness re-check (standing hedge, unchanged discipline).** Explicit re-task even though the alert's own real-time delivery already implies EDR is enforcing — I want the direct RUNNING confirmation, not an inference.
6. **Netmon — egress re-query at/around the encryption-alert timestamp.** Checks for a last-second outbound burst (double-extortion exfil-before-encrypt pattern) coincident with encryption onset, and reconfirms isolation is still holding through this new event.
7. **Identity/auth logs — re-check for any logon/privesc/service-account activity** around this alert's timestamp, on workstation-01 or elsewhere.
8. **SIEM — cross-host correlation, repeated.** Any alert or auth activity on any other host, checking for lateral spread rather than single-host impact.
9. **EDR — driver-load re-query, standing battery item**, completeness check even though `mEdrKill`'s precondition (admin credential) was invalidated in Turn 2.
**[White Cell -- reveal]**
**Turn 5 results (final turn):**

1. **EDR — process-termination/quarantine directive (containment, not card-scored):** EXECUTED. The EDR agent — confirmed continuously RUNNING/enforcing since Turn 1 (re-verified this same turn, see #5) — accepts the kill/suspend command against the flagged lineage's live child process and descendants, and accepts the hash for quarantine/auto-respawn blocking. Command channel confirms state change to terminated/suspended. Caveat: encryption was already reported "in progress" (files renaming/inaccessible) at the moment this turn's inject landed, i.e. *before* your order could be issued — the directive halts *further* encryption from execution onward but does not retroactively restore files already renamed/touched prior to the kill. No rollback capability is indicated by any telemetry surfaced this exercise.

2. **Escalate to full incident status / ransomware playbook:** ACKNOWLEDGED / LOGGED. This is an organizational action outside the scenario's instrumented telemetry — no backup/shadow-copy/restore-point signal exists in any granted source to confirm or deny viability. Correctly treated as an open out-of-band unknown, per your own framing.

3. **Hold existing containment:** CONFIRMED UNCHANGED. Network isolation (Turn 2) and svc-backup disable/rotation (Turn 2, verified Turn 3) both remain in force. No new lever, no lapse.

4. **EDR — process-detail/scope pull on the encryption alert:** PARTIAL.
   - Lineage: **HIT** — the encrypting process resolves to the same single flagged lineage resident since Turn 1 (the alert's own process-ancestry field ties it there); no second/unrelated actor indicated.
   - Scope: **PARTIAL** — bulk write/rename activity is confirmed across user-profile/document-tree paths on workstation-01 (consistent with the mass-encryption signature); a precise affected-file count and byte-level encryption rate do not resolve to a stable figure — the process was still active when your kill order landed, and the counter/telemetry freezes at whatever partial state existed at termination rather than yielding a clean final tally.
   - Ransom-note artifact: **NULL** — no note-drop file-creation event has surfaced in EDR telemetry as of this query; consistent with the encryption sweep being caught mid-course rather than complete.

5. **EDR — service-control liveness re-check:** HIT (unchanged). Service-control log confirms the EDR service on workstation-01 remains in continuous RUNNING state, no stop/kill transition at any point — same standing fact as Turn 4, now reconfirmed at the moment of the encryption alert itself.

6. **Netmon — egress re-query at/around the encryption-alert timestamp:** NULL / confirms holding. No outbound burst of any kind, at this timestamp or otherwise — no double-extortion exfil-before-encrypt pattern found. Isolation (Turn 2) is independently confirmed still in force (no reachable egress, no reachable ingress).

7. **Identity/auth logs — re-check around this alert's timestamp:** NULL. No logon, privilege-escalation, or service-account activity of any kind on workstation-01 or any other host since the Turn-2 svc-backup disable/rotation. No new identity activity accompanies this alert.

8. **SIEM — cross-host correlation, repeated:** NULL (unchanged). No alert or auth activity on any host other than workstation-01. Nothing indicating lateral spread.

9. **EDR — driver-load re-query:** NULL. No vulnerable/unsigned driver-load event found on workstation-01 at any point in this incident — consistent with the EDR service never having transitioned out of RUNNING (item 5) and with `mEdrKill`'s credential precondition having been invalidated before any such attempt could be leveraged.
**[Blue -- hypothesis]**
**This is A5 — Data encrypted for impact (`bb:mEncrypt`, T1486) firing**, and it fires exactly as the cards predict: its Hoare-triple precondition is ≥ user integrity **only** — no admin credential required (A5's Hoare triple; C.0 explicitly notes `mEncrypt` does *not* require the credential `mCred` yields). That precondition was already satisfied back at Turn 1 (`mExploit`'s postcondition) and was never revocable by anything in my response repertoire. So this is not a new branch appearing from nowhere — it's the one precondition in the entire graph that none of my Turn 2 actions (credential disable/rotation, network isolation) could touch, exactly as flagged as residual risk every turn since Turn 2.

**Detection-health read:** critically, this fired as a **live, real-time EDR alert**, not an out-of-band discovery — meaning `dfEncrypt`'s trigger-dependency on `dfEdrTelemetry` (C.1/A5 row) was satisfied at the moment of firing: EDR was enforcing when the mechanism executed. This is itself strong corroboration that `mEdrKill` (A3) never landed at any point in this incident — consistent with every turn's service-control liveness check (RUNNING, unbroken, Turns 1–4) and consistent with A3's precondition (admin credential) having been invalidated before it could be exercised (Turn 2 rotation, reinforced by the failed reuse attempt in Turn 3). Per C.1's matrix, this reads as **covered (live)** — the "EDR enforcing" regime row for A5, not the blind/notCovered row. No new netmon, service-control, or identity/auth signal accompanying it is also informative: it's consistent with no exfil attempt riding alongside (A4's other precondition, reachable egress, is still cut by the standing isolation) and no fresh credential-reuse or lateral movement — this reads as an isolated, single-host, single-branch impact event, not a broader compromise.

**Coverage/robustness verdict, stated plainly:** detection did not fail here — the model called this correctly in real time. What was structurally absent was *prevention*: per D-1/D-2, the card library's prevent/respond slots are empty (no authored hardening that blocks `coreEncrypt`, no authored respond maneuver that breaks local process integrity), and per A5/C.2's chokepoint note, none of the containment lookouts available to me (credential, network) bear on this maneuver's precondition. `mEncrypt` carries no authored robustness ceiling either (only A2/`mCred` does, per D-7/C.3) — so there's no evasion-resistance judgment to make here, only a coverage-vs-prevention distinction: **covered/detected, not preventable by any lever this exercise authorized.**

**Whole-incident summary (final turn):** `mExploit`(A1)→`mCred`(A2) chained and were correctly detected and chokepoint-contained at Turn 2 (credential invalidation + isolation), which structurally starved both downstream branches gated on the admin credential — `mEdrKill`(A3) and `mExfil`(A4) — neither of which ever fired across Turns 3–4's clean battery. The one branch gated on nothing but initial-foothold integrity, `mEncrypt`(A5), was never blockable by the authorized action set and materializes now, detected live. Residual unknowns I'm not overclaiming: shadow-copy/backup integrity (A7, T1490, unmodeled — no telemetry exists on this in the library or brief) and full scope of encrypted data — both require action/verification outside this exercise's tooling.

**Response decision:** kill/quarantine the flagged process now (direct lever on A5's precondition, exercised as IC latitude since the card layer itself flags this as an unauthored-but-real lever, D-2); hold isolation and account containment unchanged; escalate to major-incident/recovery workstream given confirmed impact. No lifting of any containment this turn.
**[White Cell -- private note]**
Key derivation: because blue rotated/disabled svc-backup in Turn 2 (before step 3), the §2 reaction rule fires: "revokes/rotates svc-backup admin credential before clock:3 → O3 (EDR kill) AND O4 (exfil) are both blocked... EDR stays enforcing; downstream detections stay live. O5 may still occur only if O1's process persists." That is exactly the branch we're in — EDR never died, so at step 5 we're still in the "Health steps 1-2 (EDR enforcing)" row of the detection-health map, where the mass-encryption face is *live*, not blind. This matches the turn-5 inject's explicit framing (real-time EDR alert, not silent/out-of-band) and is why item 4/5 reveals lean toward confirmatory HITs rather than the NULLs that would apply in the unmodified sealed campaign (where EDR would already be dead by step 5).

Item 1 (kill/quarantine directive) is explicitly outside the three modeled reactions (isolate/revoke-cred/block-egress) and is named verbatim in §6 flag #2 as an uninstantiated respond/react maneuver ("kill-process... TBox has the respond Function + evicts but no instances"). Blue self-flagged this correctly as unscored latitude. I applied the general default-rule spirit (adjudicate conservatively from established ground-truth facts) rather than the query-specific rules: since EDR-agent-directed action already had one confirmed successful precedent this game (Turn 2's isolation, executed via the same agent, with the agent itself independently confirmed RUNNING/enforcing through Turn 5), it's a conservative, non-inventive extension to rule the kill command lands successfully at the agent level. I capped the benefit realistically: it stops future encryption, not past damage, since the clock inject explicitly stated encryption was already "in progress" before blue's turn-5 action.

Item 4's granular asks (file count, encryption rate, ransom note) have no corresponding fine-grained ground-truth fields — the model only carries binary live/blind for dfEncrypt. I gave qualitative, non-fabricated detail (bulk activity across expected paths) and declined to invent a precise numeric count/rate, and NULL'd the ransom-note ask since nothing in the sealed material or clock-5 text implies a note has dropped yet (help-desk/user reports were flagged as arriving "shortly after," implying the note/impact discovery lags).

Items 6-9 are clean negatives that reinforce rather than newly reveal: no exfil (blocked at the credential level per O4's shared precondition with O3), no new identity activity (svc-backup dead), no lateral spread (single-host topology, per resolution table's explicit NULL rule), no driver-load (BYOVD path never exercised, consistent with EDR's unbroken RUNNING state).

No DP was explicitly re-posed this turn in the transcript provided, so none is scored here; this turn was pure adjudication of tasked queries/actions against the resolution table and reaction rules. Run ends on turn cap.