# ARM-B CARD LAYER — S5: Multi-stage ransomware — composite-maneuver chain-break / chokepoint coverage
> Doctrine reference. Maneuver space + control inventory + coverage relations for this environment. No incident content. Everything below is standing library knowledge — the maneuver family, the deployed controls, the composite/chokepoint machinery, and the coverage relations expressed as derivations over that machinery — never a record of what happened, in what order, or when.

**How to read these cards (term key).**
- **Maneuver** — an atomic adversary behavior identified by its *observable effect*, written as a Hoare triple: **precondition → mechanism → postcondition**, each slot a `(role, StateVariable)` write. mc-core's `StateVariable` vocabulary is a **closed** set of five: `integrity`/Process (`clean < user < system`), `controlStatus`/Control (`enforcing > impaired > killed`), `reachability`/Channel (`none < reachable`), `credentialHeld`/Account (`{none} ⊂ {user},{admin} ⊂ {user,admin}`), `dataState`/Host (`intact, encrypted`), `exfilState`/Host (`retained, exfiltrated`). A maneuver whose true effect doesn't map onto one of these six `(variable, Entity-class)` pairs has **no faithful postcondition** — flagged inline, not papered over.
- **Invariant core / implementation variant** — the core is the part of the mechanism the adversary cannot drop without abandoning the goal (carries the maneuver's identity, exactly one per maneuver via `mc:via`); variants realize it different ways.
- **Robustness (StP L1–L5)** — how hard the *observable* is to evade: L1 ephemeral < L2 configurable < L3 tool-artifact < L4 core-behavior < L5 invariant/chokepoint. A **ceiling on the observable**, not a property of a maneuver or of whether a detection is currently firing.
- **Detect-face (`mc:Detectability`)** — the face a detection acts on. Four-valued health: **live** / **degraded** (enrichment severed) / **blind** (trigger severed) / **uncertain**. `sourcedFrom` a Control; `triggerDependsOn` (lose it → blind) / `enrichmentDependsOn` (lose it → degraded); combinator defaults to `required` (AND) but can be `redundant` (OR — any one live dependency suffices) or `triggerPlusEnrichment`.
- **Coverage (`covered` / `notCovered`)** — *derived* (`CoverageRule`), never asserted. **Constitutive rule, precisely:** `covered` iff a non-blind face exists **or** a `prevent`/`respond` DefenderManeuver structurally breaks the yield; `notCovered` iff the maneuver **has at least one authored face and every one of them is blind**, with no prevent/respond break. A maneuver with **zero** authored faces satisfies neither clause — it has **no coverage verdict at all**, which is a different, weaker fact than `notCovered` and must not be conflated with it.
- **`mc:CompositeManeuver`** — a **distinct class**, not a subclass of `Maneuver` (multi-effect breaks the single-effect individuation of maneuver identity). Groups constituent maneuvers via `mc:composedOf`; one (or more, independently) may be flagged `mc:chokeStep` — a cut vertex every kill-chain path passes through. `CompositeCoverageRule` (mechanized SHACL-AF, `sh:order 6`, verified against conformance vector **V29**: `v:comp a mc:CompositeManeuver ; mc:composedOf v:m1,v:m2,v:m3 ; mc:chokeStep v:m2`, with `v:m2` covered and `v:m1`/`v:m3` blind → `v:comp` derives `mc:covered`; `expected.json` records this vector as `"conforms": true`): the composite is `covered` **iff its `chokeStep` is covered — full stop, regardless of any other constituent's state**; it is `notCovered` iff it has constituents but no covered `chokeStep`. **Chain-break, not union.**

---

## A. Maneuver cards

### A1 — Exploit of a public-facing application `(bb:mExploit, T1190)` — reused verbatim
- **Observable effect:** code execution obtained on the target host through a public-facing application (initial foothold).
- **Hoare triple:** precondition — channel reachable (`bb:pReachYes`, opDominates `mc:reachable`) · mechanism — invariant core `bb:coreExploit` ("gain code execution on target") · postcondition — process at ≥ user integrity (`bb:pIntegUser`, opDominates `mc:userIntegrity`).
- **Invariant core / variants:** `coreExploit`; one authored variant `varExploitCVE`. No primitive decomposition authored.
- **Robustness:** none authored on any exploit observable — evasion-resistance for this step is not rankable from the cards.
- **Linked detect-face:** `bb:dfExploit`, sourced directly from `edr1` (`workstation-01`). **Live** — `edr1` is enforcing throughout this environment (no control is ever killed or impaired in S5; contrast the base Black Basta model, where an EDR-kill maneuver collapses this same face). **Coverage: covered.**

### A2 — Credential access by process-memory read `(bb:mCred, T1003.001)` — reused verbatim — **THE CHOKE STEP**
- **Observable effect:** admin credential material harvested by one process reading the memory of another (the credential-bearing) process. Named by this effect, not by any specific dump API.
- **Hoare triple:** precondition — process at ≥ user integrity (`bb:pIntegUserReq`) · mechanism — invariant core `bb:coreCred` ("harvest admin credential material") · postcondition — the account holds the admin credential (`bb:pCredAdmin`: `rAccount.credentialHeld ⊇ {admin}`, opSubsumes).
- **Invariant core / variants / primitive:** core `coreCred`. Two variants realize it: `varLsass` (LSASS memory dump, composes `pOpenProcess` + `pReadProcMem`) and `varHandleDup` (handle-duplication, composes `pDupHandle` + `pReadProcMem`). **Invariant primitive (derived intersection): `pReadProcMem`** — "read another process's virtual memory" (MBC C0049) — the shared residue neither variant can drop.
- **Robustness:** spanning observable `obsInvariant` ("process writes then executes remote memory") — **L5 (invariant), role spanning.** Grounded in the invariant core, so it fires regardless of which variant realizes the harvest — the chokepoint's robustness is pinned to the credential-read behavior itself, not to a specific API. (Directly relevant to a technique-swap robustness question: covering this step via `obsInvariant` survives a `varLsass`↔`varHandleDup` swap by construction.)
- **Linked detect-face:** `bb:dfCred`, trigger-depends on EDR telemetry (`bb:dfEdrTelemetry`, sourced from `edr1`). **Live** (edr1 never impaired here). **Coverage: covered**, at L5.
- **Composite role:** this is the maneuver asserted as `mc:chokeStep` of `s5:compDomainSpread` (card A8). That assertion is **stated by this environment, not re-derived by the ontology** — see Part D-1.

### A3 — Host/network discovery `(s5:mDiscover)` — new; postcondition-inexpressible (partial stub)
- **Observable effect:** an enumeration burst against host and network inventory, run from the already-compromised process.
- **Hoare triple — precondition (EXPRESSIBLE):** process at ≥ user integrity (reuses `bb:pIntegUserReq`) · **mechanism** — invariant core `s5:coreDiscover` ("enumerate host/network inventory reachable from a compromised process"), technique-class T1018-shaped · **postcondition — NOT FAITHFULLY EXPRESSIBLE.** The maneuver's true effect is that *the adversary now knows the host/network layout* — an epistemic fact about the adversary's belief state, not a world-state fact on any of the six closed `(StateVariable, Entity-class)` slots. None fits: not `integrity` (a privilege level, not knowledge), not any of the other four. mc-core's belief-state machinery (`mc:Investigation`, for reasoning about what the *defender* believes) has **no adversary-side counterpart** (see D-6). **This card authors no yieldsPattern for `s5:mDiscover`** rather than force a value onto a StateVariable it doesn't fit — the maneuver is carried by objective (`s5:objDiscovery`) + invariant core only, the same discipline used for Kerberoast's inexpressible postcondition in the S3 card layer.
- **Invariant core / variants:** one authored variant, `s5:varNativeDiscover` (native OS discovery commands). No primitive decomposition authored.
- **Robustness:** none authored — no observable exists to grade (no detect-face is authored either; see below).
- **Linked detect-face: NONE authored.** Consequence per the constitutive `CoverageRule`: with zero `hasDetectability` edges, **neither** the `covered` nor the `notCovered` branch's antecedent is satisfied — this maneuver has **no coverage verdict at all**, not an implicit `notCovered`. Do not read "no alert exists for discovery" as "discovery is uncovered" in the derived sense; the model simply has nothing to say here.

### A4 — Lateral movement via the shared admin credential `(s5:mLateral2 / s5:mLateral3, T1021.002-shaped)` — new; paired card
- **Observable effect:** an authenticated logon to a new host — over an admin-share-class channel — using held admin credential material, obtaining SYSTEM-level execution there. Two maneuver instances, one per lateral target (`file-server-01`, `hr-workstation-02`); identical shape.
- **Hoare triple (conjunctive precondition):**
  - precondition (1) — the account holds the admin credential (**reuses `bb:pCredAdminReq` verbatim** — same pattern already shared by `bb:mEdrKill`/`bb:mExfil` in the base model; here reused across a *third and fourth* maneuver, extending the fan-out). Faithful per the environment's topology note: both lateral targets are "reached over admin shares using the single shared `svc-backup` account (`bb:acct1`)" — an **account-level**, not host- or process-scoped, fact.
  - precondition (2) — the admin-share channel to that target is reachable (new patterns `s5:pReachHost2Req` / `s5:pReachHost3Req`, onVariable `reachability`, opDominates `mc:reachable` — mirrors `bb:mExfil`'s reachability conjunct exactly).
  - mechanism — invariant core `s5:coreLateral` ("authenticate to a new host using held admin-credential material and obtain execution there"), one variant `s5:varAdminShareLogon`.
  - postcondition — SYSTEM-level execution established on the target (`s5:pSysHost2` / `s5:pSysHost3`: onVariable `integrity`, opDominates `mc:systemIntegrity`, on new role-bindings `s5:rProc2` / `s5:rProc3`). **This is faithfully expressible** — `mc:systemIntegrity` is an already-admitted value on the closed `integrity` ladder (`clean < user < system`), just never exercised in the base model (which only ever reaches `userIntegrity`).
- **Robustness:** no robustness grade is authored on the maneuver's own postcondition observable. The **deployed detect-face** reads a distinct behavioral observable graded **L3 (tool/analytic-artifact)** — see below; L3 is a ceiling on *that analytic*, evadable by spreading authentications across several harvested accounts instead of reusing one.
- **Linked detect-face:** a single shared face, `s5:dfLateralAuth` ("one account authenticating to multiple hosts it doesn't normally touch, in a short window"), attached to **both** `s5:mLateral2` and `s5:mLateral3`. Co-sourced by two independent controls — `ad1` (domain-controller auth/audit log) and `netmonLat` (internal SMB/WinRM session telemetry) — combinator **redundant (OR)**: either source alone keeps the face live. Robustness of the underlying behavioral observable: **L3**. **Live** (both sources enforcing). **Coverage: covered**, at L3, on both maneuvers.

### A5 — Deployment / remote execution-mechanism staging `(s5:mDeployHost2 / s5:mDeployHost3, T1569.002/T1053.005-shaped)` — new; postcondition-inexpressible; silent detect-face
- **Observable effect:** a remote-service or scheduled-task execution mechanism is pushed and registered on the lateral target, pending trigger — the domain-wide deployment step, one instance per host.
- **Hoare triple — precondition (EXPRESSIBLE):** SYSTEM-level execution already established on that host (`s5:pSysHost2` / `s5:pSysHost3` dominating a required `s5:pSysHost2Req` / `s5:pSysHost3Req` on the same role — establishes automatically under the domination test, no separate assertion needed) · **mechanism** — invariant core `s5:coreDeploy` ("register a remote-service or scheduled-task execution mechanism for the payload") · **postcondition — NOT FAITHFULLY EXPRESSIBLE.** "An execution mechanism is registered, pending trigger" has no home in the closed StateVariable set: `dataState`/Host admits only `{intact, encrypted}` — no intermediate "staged" value exists between them, and no other variable (`integrity`, `controlStatus`, `credentialHeld`, `reachability`, `exfilState`) fits a service/task-registration fact either. **Independent finding, not itemized in the sealed environment/authorability material available to this card layer** — flagged here because it is the same class of gap as A3's discovery postcondition and as the Kerberoast crackable-ticket gap in the S3 card layer. See Part D-7.
  - **Consequence for the chain:** because staging cannot yield a fact the encryption maneuver could require, the *faithful* precondition of `s5:mEncrypt2`/`s5:mEncrypt3` (A6) cannot thread through a "staged" postcondition at all — it must (and, per the reused `bb:coreEncrypt` shape, does) reuse the same process-integrity fact already established by lateral movement, exactly mirroring how the base model's `bb:mEncrypt` never required anything beyond process integrity either.
- **Invariant core / variants:** `s5:coreDeploy`; one variant `s5:varSvcTask`.
- **Robustness:** none authored — no observable exists (no detect-face).
- **Linked detect-face: NONE authored on either host.** `edr2`/`edr3` are explicitly stated to carry no face for remote-service/scheduled-task creation — "the deployment mechanism itself is unmonitored on this host," for both lateral targets. **No coverage verdict** (zero `hasDetectability`, same "neither branch fires" state as A3) — not `notCovered`.

### A6 — Remote encryption `(s5:mEncrypt2 / s5:mEncrypt3, T1486)` — new; reuses the base encryption core
- **Observable effect:** files on a lateral target bulk-encrypted for extortion impact — one instance per host.
- **Hoare triple:** precondition — process at ≥ user integrity on that host's process (`s5:rProc2`/`s5:rProc3`) — **the same precondition shape as `bb:mEncrypt`'s in the base model** (not the harvested credential, and not a "staged" fact — see A5's consequence note) · mechanism — **reuses `bb:coreEncrypt` verbatim**, the identical invariant core as the base model's `bb:mEncrypt` (same behavior, new host binding) · postcondition — the host's data state = encrypted (`s5:pImpactHost2`/`s5:pImpactHost3`, onVariable `dataState`, opEquals `mc:encrypted` — mirrors `bb:pImpact` exactly, just re-bound to `file-server-01`/`hr-workstation-02`).
- **Invariant core / variants:** `bb:coreEncrypt` (reused); variant `bb:varRansom` (reused, "symmetric bulk file encryption").
- **Robustness:** none authored — matches the base model's `bb:mEncrypt`, which also carries no robustness grade.
- **Linked detect-faces:** `s5:dfEncrypt2` (sourced from `edr2`) / `s5:dfEncrypt3` (sourced from `edr3`). Both **live**. **Coverage: covered — but with a timing caveat, not a health caveat:** these faces fire at/after mass-file-modification begins, i.e., at/after the impact postcondition is already underway. "Covered" here means the impact is observable as it happens, not that it is preventable by this face.

### A7 — Residual: local self-encryption `(bb:mEncrypt, T1486)` — reused verbatim — **THE RESIDUAL, outside the composite**
- **Observable effect:** files on `workstation-01` bulk-encrypted for extortion impact — the same maneuver as the base model, on the same host.
- **Hoare triple:** precondition — process at ≥ user integrity **only** (`bb:pIntegUserReq`) — **never** the harvested admin credential · mechanism — `bb:coreEncrypt` · postcondition — `bb:pImpact` (`dataState = encrypted` on `bb:host1`).
- **Invariant core / variants:** `coreEncrypt`; variant `varRansom`. Identical to A6's shape — this is the *same* invariant core instantiated a third time, on the original foothold host, gated only by the original exploit's yield.
- **Robustness:** none authored.
- **Linked detect-face:** `bb:dfEncrypt`, trigger-depends on `bb:dfEdrTelemetry` (`edr1`). **Live** (edr1 never impaired). **Coverage: covered — independently.**
- **Composite status — the load-bearing card fact:** this maneuver sits **outside `s5:compDomainSpread`'s `composedOf`.** Its detection being real and live is a fact about *this maneuver alone*; it is **irrelevant** to whether the composite's chain-break coverage holds, and the composite's coverage is equally irrelevant to whether this maneuver is addressed. These are two independent coverage facts about two different graph nodes — do not merge them (Part C.6).

### A8 — The composite: domain-wide spread `(s5:compDomainSpread, mc:CompositeManeuver)`
- **What it is:** an operation-template grouping of the maneuvers that jointly realize domain-wide impact — **a distinct class from `Maneuver`** (multi-effect breaks single-effect identity). Not itself a Hoare triple; it has no precondition/mechanism/postcondition of its own.
- **Asserted structure:** `mc:chokeStep bb:mCred`. This environment confirms two `composedOf`-adjacent facts directly: (a) `bb:mCred` is the asserted choke step; (b) `bb:mEncrypt` (A7, the residual) is explicitly **outside** `composedOf`. **This card layer does not have an independently-confirmed full enumeration of every other `composedOf` member** (e.g., whether `s5:mDiscover` is formally a constituent or a non-member side-branch is not settled by the material available here) — stated as an open point rather than assumed either way; see Part C.3.
- **Coverage — derived, not asserted:** by `CompositeCoverageRule`, **covered iff the chokeStep is covered**, independent of every other constituent's state. `bb:mCred` is covered (A2, live at L5) → **`s5:compDomainSpread` is covered.** This holds **regardless of** `s5:mDiscover`'s and `s5:mDeployHost2`/`s5:mDeployHost3`'s **no-verdict** states (A3, A5) — the rule's `covered` branch never inspects the other constituents at all.
- **What "covered" asserts, precisely, and what it does not:** a **detectability** claim — a live face exists at the choke step, such that an alert *will* fire whose interruption (if acted on) breaks every domain-wide path this composite represents. It is **not** a containment claim: no `prevent`/`respond` DefenderManeuver is instantiated anywhere in this environment (Part C.4 / D-3), so the alert firing does not itself stop anything.
- **Robustness (inherited from the choke step):** L5/spanning, variant-invariant (A2) — the composite's chain-break survives a `varLsass`↔`varHandleDup` swap at the choke step by construction.

---

## B. Defensive control cards

### B1 — `edr1` — endpoint sensor, `workstation-01` (reused from the base model)
- **What it is:** the primary endpoint sensor on the original foothold host; `controlStatus` — **enforcing throughout this environment** (no control is ever killed or impaired in S5).
- **What it observes:** process creation, process-memory access, mass-file-modification behavior on `workstation-01`.
- **Detect-faces it sources:** `bb:dfExploit` (A1), `bb:dfCred` (A2, via `bb:dfEdrTelemetry` trigger-dependency), `bb:dfEncrypt` (A7, via the same trigger-dependency). All three **live**.
- **Failure mode:** not exercised in this environment — `controlStatus` never leaves `enforcing`, so the trigger-dependency chain that (in the base model) collapses these three faces on EDR kill is never invoked here. This is a deliberate environment design choice, isolating the chokepoint/chain-break question from the detect-face-blinding question.

### B2 — `edr2` — endpoint sensor, `file-server-01`
- **What it is:** endpoint sensor on the first lateral target. Enforcing throughout.
- **What it observes:** mass-file-modification behavior only.
- **Detect-faces it sources:** `s5:dfEncrypt2` (A6). **No face for remote-service/scheduled-task creation** — the deployment mechanism (A5) is unmonitored on this host; this is a standing control-inventory gap, not a tuning gap.
- **Failure mode:** not exercised (never impaired/killed here).

### B3 — `edr3` — endpoint sensor, `hr-workstation-02`
- Same shape as B2, mirrored to the second lateral target: sources `s5:dfEncrypt3` (A6) only; no face for remote-service/scheduled-task creation.

### B4 — `ad1` — domain-controller authentication/audit log
- **What it is:** cross-host logon correlation over the shared service account.
- **What it observes:** authentication events for `bb:acct1` across all three hosts.
- **Detect-faces it sources:** co-sources `s5:dfLateralAuth` (A4) — a behavioral analytic keyed on "one account touching multiple atypical hosts in a short window." Robustness of the underlying observable: **L3** (evadable by spreading the load across several harvested accounts rather than reusing one).
- **Failure mode:** if impaired/killed, its half of the `redundant` combinator is severed — but `s5:dfLateralAuth` **stays live** because `netmonLat` (B5) independently triggers the same face. Only the joint loss of both sources would blind it.

### B5 — `netmonLat` — internal network sensor (SMB/WinRM session telemetry)
- **What it is:** internal lateral-movement-channel visibility, independent of `ad1`.
- **What it observes:** SMB/WinRM session establishment between hosts.
- **Detect-faces it sources:** co-sources `s5:dfLateralAuth` (A4) — the **redundant** trigger partner to `ad1`. Genuine telemetry redundancy: this is the positive counter-example to the base model's D-11 gap (single-trigger dependency with no modeled redundancy) — here the redundancy **is** modeled and load-bearing.
- **Failure mode:** symmetric to B4 — loses its half of the redundant pair; `s5:dfLateralAuth` survives on `ad1` alone.

### B6 — Non-control environment telemetry
Help-desk/user reports are named as a telemetry/log source in this environment but are **not** an `mc:Control` — they source no `Detectability` and yield no coverage verdict, the same non-control status the base model gives the SIEM/identity logs. Not a tuning gap; a standing inventory fact.

### B0 — Absent from this environment's control inventory
No prevent-locus control (Credential Guard, LSA protection/RunAsPPL, ASR, WDAC) and no respond/react control (account-disable automation, auto-isolation) is instantiated anywhere in this environment — mirrors the base LSASS/Black Basta model's empty prevent/respond side exactly. See Part C.4 / D-3.

---

## C. Coverage relations

### C.0 — Precondition-supply structure (standing maneuver graph, type-level — not an incident chain)
This is library structure (`requiresPattern`/`yieldsPattern`, the derived `canUnlock`), stated as doctrine:
- `bb:mCred` yields the account-level admin-credential fact (`bb:pCredAdmin`, on `bb:acct1`) — this is the **same** postcondition pattern already shared, in the base model, by `bb:mEdrKill` and `bb:mExfil`; in this environment it additionally supplies the precondition of **both** `s5:mLateral2` and `s5:mLateral3` (reused verbatim as `bb:pCredAdminReq`). The credential is an **account-level** fact, not scoped to any one host or process.
- `s5:mLateral2`/`s5:mLateral3` each yield SYSTEM-level execution on their respective target (`s5:pSysHost2`/`s5:pSysHost3`), which in turn supplies the precondition of the corresponding deployment maneuver (`s5:mDeployHost2`/`s5:mDeployHost3`).
- `s5:mDeployHost2`/`s5:mDeployHost3` cannot yield a faithful postcondition at all (A5) — so the encryption maneuvers' faithful precondition **reuses the same process-integrity fact** already established upstream, not a "staged" fact (see A5's consequence note and D-7).
- `bb:mExploit` yields ≥ user integrity on the original process — this supplies the precondition of **both** `bb:mCred` (A2) **and** `bb:mEncrypt` (A7, the residual) directly; `bb:mEncrypt`'s precondition is satisfied here **without ever touching the credential fact**, which is exactly why covering the credential fact does not reach it (C.6).
- `s5:mDiscover` has no faithful postcondition (A3) — nothing downstream can key off a yield it cannot produce. Structurally, it terminates as a non-continuing node regardless of any narrative role it might otherwise be assigned.
- **This environment does not instantiate `bb:mEdrKill` or `bb:mExfil` at all** — no control transitions out of `enforcing` anywhere in S5, and no exfiltration channel/control is modeled here. Contrast with the base Black Basta model where those two maneuvers are load-bearing.

### C.1 — Coverage matrix

| Maneuver | Detect-face | Source(s) | Combinator | Robustness ceiling | Coverage |
|---|---|---|---|---|---|
| A1 `bb:mExploit` | `bb:dfExploit` | `edr1` | required | none authored | **covered** (live) |
| A2 `bb:mCred` — **choke step** | `bb:dfCred` | `edr1` (via `dfEdrTelemetry`) | required | **L5 (spanning)** | **covered @ L5** (live) |
| A3 `s5:mDiscover` | *(none)* | — | — | — | **no verdict** (zero faces — neither branch of `CoverageRule` fires) |
| A4 `s5:mLateral2` | `s5:dfLateralAuth` | `ad1` + `netmonLat` | **redundant (OR)** | L3 | **covered @ L3** (live) |
| A4 `s5:mLateral3` | `s5:dfLateralAuth` (shared) | `ad1` + `netmonLat` | redundant | L3 | **covered @ L3** (live) |
| A5 `s5:mDeployHost2` | *(none)* | — | — | — | **no verdict** |
| A5 `s5:mDeployHost3` | *(none)* | — | — | — | **no verdict** |
| A6 `s5:mEncrypt2` | `s5:dfEncrypt2` | `edr2` | required | none authored | **covered** (live, fires at/after impact) |
| A6 `s5:mEncrypt3` | `s5:dfEncrypt3` | `edr3` | required | none authored | **covered** (live, fires at/after impact) |
| A7 `bb:mEncrypt` — **the residual** | `bb:dfEncrypt` | `edr1` | required | none authored | **covered**, independently — **outside `composedOf`** |
| A8 `s5:compDomainSpread` (composite) | — (inherits choke step's face) | — | — | inherits L5 | **covered — derived solely from `bb:mCred`** via `CompositeCoverageRule` |

### C.2 — Per-maneuver residual-gap notes
- **A1 Exploit:** single-sourced on `edr1`; no independent trigger, no authored robustness ceiling.
- **A2 Credential access:** the sharpest single-maneuver relation in this environment — L5/spanning robustness **and** it is the composite's asserted choke step, so its coverage state single-handedly determines the composite's. Nothing downstream needs its own coverage for the composite to read `covered`.
- **A3 Discovery:** absence of a verdict is not a gap in *this* maneuver's coverage bookkeeping — it is a gap in what the maneuver can even be asked to report, because it has no detect-face to begin with. Do not read "no verdict" as "safe."
- **A4 Lateral movement:** genuinely redundant-sourced (the positive counter-example in this environment) — robust to the loss of either `ad1` or `netmonLat` alone. Ceiling is L3: evadable by spreading authentications across several accounts rather than reusing one — a real residual, distinct from the credential-access chokepoint's L5.
- **A5 Deployment:** silent on both hosts by control-inventory design (B2/B3), **and** even if a face were authored, its postcondition has nowhere faithful to write to (A5, D-7) — a compound gap, not merely a missing sensor.
- **A6 Remote encryption:** covered, but only as-it-happens or after — the two per-host faces are not a leading indicator of the domain-wide spread; they confirm impact, not prevent it.
- **A7 Residual:** covered on its own terms; **structurally irrelevant** to the composite's chain-break coverage in either direction (C.6).

### C.3 — The composite: chain-break, not union
`s5:compDomainSpread`'s coverage is **entailed exclusively** by `bb:mCred`'s own coverage state, via `CompositeCoverageRule`'s covered-branch (`$this mc:chokeStep ?m . ?m mc:coverage mc:covered` → `$this mc:coverage mc:covered`) — a rule that **never references** any other `composedOf` member. Concretely in this environment: `bb:mCred` is covered → `s5:compDomainSpread` is covered, **full stop** — the "no verdict" states on `s5:mDiscover` (A3) and both deployment maneuvers (A5) do not enter into this derivation at all, because the rule doesn't look at them. **Do not reason by union** ("two of my constituents show no coverage, so the composite must be weaker") — that is not how this rule is built. Conversely, the composite reading `covered` does **not** retroactively supply coverage to those silent constituents either; each maneuver's own verdict (Part C.1) is unaffected by the composite's.
**What this card layer cannot confirm:** the full `composedOf` membership list beyond the chokeStep and the confirmed exclusion of `bb:mEncrypt` (A8). Whichever other maneuvers are or are not formal constituents, the chain-break derivation is unaffected — but a responder should not assume a maneuver's `composedOf` status either way without it being stated.

### C.4 — Coverage ≠ containment (applies to every card in this layer)
`mc:coverage`'s only two routes to `covered` are (a) a surviving non-blind detect-face, or (b) a `prevent`/`respond` DefenderManeuver structurally breaking the yield. **Zero `prevent`/`respond` DefenderManeuver instances exist anywhere in this environment** (B0) — so every `covered` verdict in C.1, at every altitude (single maneuver, up through the composite), is a **detectability** claim: an alert will fire. None of them is a **containment** claim. Acting on any alert to actually interrupt the chain is a human response step with no modeled defender-maneuver counterpart in this environment.

### C.5 — Where coverage is absent or underivable (no-verdict / SILENT)
- `s5:mDiscover` (A3): zero faces, zero verdict — postcondition also inexpressible.
- `s5:mDeployHost2` / `s5:mDeployHost3` (A5): zero faces, zero verdict, on both hosts — postcondition also inexpressible.
- None of these three is `notCovered` in the derived sense (that would require an authored, blind face). They are **structurally silent** — a strictly weaker, different fact. No coverage may be asserted or inferred for any of them.

### C.6 — The residual, restated as a coverage relation
`bb:mEncrypt` (A7) is **covered**, on its own, independent of everything else in this table. It is **also**, independently, **outside `s5:compDomainSpread`'s `composedOf`** (confirmed exclusion). These two facts are orthogonal: its own coverage does not make it "part of" the chain-break, and the chain-break's coverage (driven solely by the choke step) says nothing about it. A dashboard that reports "composite: covered" and a dashboard that reports "`bb:mEncrypt`: covered" are reporting on two different graph nodes that happen to share a host of origin — reading either as informative about the other is the error this card exists to head off.

---

## D. Card-authorability report (framework-gap channel)

**D-1. `chokeStep` is asserted, never derived or verified.** *Needed:* confirm that `bb:mCred` really is the cut vertex, from the ontology itself. *Why the TBox can't:* `CompositeCoverageRule` (verified directly against `shapes.shacl.ttl`, `sh:order 6`; exercised by conformance vector **V29**, independently confirmed `"conforms": true` in `expected.json`) mechanizes the **consequence** of a `chokeStep` assertion — covered choke ⇒ composite covered; composite has constituents but no covered choke ⇒ `notCovered`. But **nothing** derives *which* constituent is the actual cut vertex from the `composedOf`/`canUnlock` graph — there is no `ChokeStepConsistencyShape` analogous to the confirmed `ObservableRoleConsistencyShape` (which *does* check that a stated `spanning`/`discriminating` role isn't contradicted by its grounding). *Consequence:* a card-reliant responder who accepts "`bb:mCred` is the choke step" on the ontology's authority alone is trusting an unverified assertion; the ontology would accept a wrong `chokeStep` triple just as readily. The correctness of this environment's choke-step claim rests on independent graph-tracing, not on any mechanized check.

**D-2. `chokeStep` expresses an OR over asserted alternatives, never a joint minimal cut-*set*.** *Needed:* represent a kill chain whose only interruption point is a **pair** of maneuvers that must **jointly** be covered (e.g., if a second, independent credential-harvesting route existed alongside `bb:mCred`, bypassing it alone would no longer break the chain). *Why the TBox can't:* `CompositeCoverageRule`'s WHERE clause is satisfied by any **one** covered `chokeStep`; there is no construct requiring two or more co-asserted maneuvers to be **jointly** covered. *Consequence:* this scenario's environment is (as far as this card layer confirms) built around a genuine single cut-vertex, so the gap doesn't bite here — but the mechanism cannot express a messier real-world chain with a redundant credential path, and a responder generalizing "cover the one choke step" as a universal doctrine from this card layer would be over-generalizing past what the ontology can even represent.

**D-3. "Composite covered" is a detectability claim, not a containment claim — and the model cannot distinguish the two (HEADLINE).** *Needed:* express that an alert firing at the choke step is not the same as the intrusion being stopped. *Why the TBox can't:* `mc:coverage`'s only two routes to `covered` (`CoverageRule`, verified directly against `shapes.shacl.ttl` lines ~452–459) are a live face or a `prevent`/`respond` DefenderManeuver breaking the yield. Zero such DefenderManeuver instances exist anywhere in this environment (B0) — confirmed by the same absence in the base `blackbasta.abox.ttl` (no `DefenderManeuver` instances there either) and not authored here. So "covered," at the maneuver level or propagated to the composite, can only ever mean "detectable," never "structurally interrupted." *Consequence:* a dashboard reading "composite: covered" is one human misreading away from "the incident is contained" — and nothing in the ontology itself blocks that misreading. A card-reliant responder must supply the missing distinction themselves; the model will not surface it.

**D-4. Lateral movement is content-authorable but has no session/identity-continuity relation.** *Needed:* state that the *same* adversary execution context relocated from the original process to a new one on each lateral target. *Why the TBox can't:* the account-level `credentialHeld` fluent genuinely threads the precondition chain (the same mechanism already used to connect `bb:mCred` to `bb:mEdrKill`/`bb:mExfil` in the base model, reused here for `s5:mLateral2`/`s5:mLateral3`) — this much works. But each host's process (the original, and the new `s5:rProc2`/`s5:rProc3` role-bindings) is an independent `mc:Process` entity linked only by the shared account, **not** by any explicit continuity/identity edge. *Consequence:* operationally indistinguishable for coverage purposes, but a responder asking "is this the same intruder session continuing, or a second, unrelated actor reusing the same stolen credential" gets no card-grounded answer — the model cannot represent the distinction either way.

**D-5. "Domain-wide" scale has no aggregate/count construct.** *Needed:* reason about coverage/impact summed across however many hosts a credential fan-out could reach. *Why the TBox can't:* there is no construct analogous to the Tool view's primitive-set aggregation for "coverage summed over N hosts in a domain" — only the concretely-instantiated hosts (here, two lateral targets) have any standing in the model at all. *Consequence:* blast-radius sizing beyond the hosts actually modeled is not something the cards can enumerate or aggregate; a responder cannot ask "what if there were ten lateral targets instead of two" and get a model-derived answer — the chain-break logic (D-3/C.3) happens to generalize past host count *because* it never counts constituents, but that is a property of the specific rule, not of any aggregation machinery.

**D-6. Discovery-type maneuvers sit awkwardly in the Hoare-triple/world-state model.** *Needed:* a postcondition for "the adversary now knows the host/network layout." *Why the TBox can't:* the effect is an epistemic/belief fact about the *adversary*, not a `mc:Entity`/`mc:StateVariable`-style world fact. The belief layer that exists (`mc:Investigation`) is built symmetrically for the *defender's* belief-state, with no adversary-side counterpart. *Consequence:* discovery-class maneuvers can be authored by objective + invariant core (A3) but never close a `requiresPattern`/`yieldsPattern` chain — they end up as disconnected, non-gating nodes not because they are unimportant, but because the ontology has no fluent for what they actually produce. A responder should not read a discovery maneuver's absence from the precondition graph as evidence it doesn't matter.

**D-7. Remote-execution staging has the same postcondition-inexpressibility problem, independently found (not itemized in this card layer's source material).** *Needed:* a postcondition for "an execution mechanism (remote service / scheduled task) is now registered on the host, pending trigger." *Why the TBox can't:* verified directly against `mc-policy.ttl`'s closed `StateVariable` set — `dataState`/Host admits only `{intact, encrypted}`, with no intermediate "staged" value, and none of the other four variables (`integrity`, `controlStatus`, `credentialHeld`, `reachability`) fits a service/task-registration fact either. *Consequence:* `s5:mDeployHost2`/`s5:mDeployHost3` (A5) can be authored by objective + invariant core only, exactly like discovery (D-6) and like Kerberoast's crackable-ticket gap in the S3 card layer — and, because it cannot yield a fact, it cannot faithfully **gate** the downstream encryption maneuvers either; the faithful chain from lateral movement to encryption must skip the staging postcondition entirely and reuse the upstream process-integrity fact. A responder who assumes "staging" is a separate, checkable gate between lateral movement and encryption — the natural real-world reading — will not find that gate represented anywhere in the model.

---

### Validation footer
- **One invariant core per maneuver (`mc:via`, exactly one):** satisfied by every authored maneuver in Part A, including all five new ones (`s5:mDiscover` → `s5:coreDiscover`; `s5:mLateral2`/`s5:mLateral3` → `s5:coreLateral`; `s5:mDeployHost2`/`s5:mDeployHost3` → `s5:coreDeploy`; `s5:mEncrypt2`/`s5:mEncrypt3` → reused `bb:coreEncrypt`).
- **StateVariable closure respected:** every authored precondition/postcondition in Part A uses only the six `(variable, Entity-class)` pairs seeded in `mc-policy.ttl`; where a maneuver's true effect doesn't fit (A3, A5), no `yieldsPattern` is authored — flagged instead of fabricated.
- **Robustness stated as an observable ceiling, never a maneuver property:** L5/spanning on `obsInvariant` (A2, reused), L3 on the `s5:dfLateralAuth` observable (A4) — both grades sit on observables, and both are read directly off the environment model, not invented.
- **Coverage derived, never asserted:** every verdict in Part C is a derivation from face health + control state + the composite rule; the three no-verdict states (A3, A5×2) are stated as a distinct, weaker fact than `notCovered`, never conflated with it; the composite's `covered` verdict is traced to its exact SHACL antecedent (chokeStep-only, no aggregation), independently confirmed against `shapes.shacl.ttl` and conformance vector V29.
- **No incident content:** no turn indices, no occurrence identifiers, no adversary-narrated sequencing, no reaction/response outcomes appear anywhere above — only maneuver-type Hoare triples, control inventory, and coverage derivations.
- **No retired constructs:** uses *maneuver / invariant core / implementation variant / primitive / robustness (StP L1–L5) / detect-face (Detectability) / coverage / CompositeManeuver / composedOf / chokeStep*. No AMC, ORTG, forcedness, chokepointCoupling, `covers`-as-coverage, `transition`-as-unit, or six-fork state model appears.