# ARM-B CARD LAYER — S6: Compromised valid admin account — legitimate-tool abuse (degradation-by-legitimacy) > Doctrine reference. Maneuver space + control inventory + coverage relations for this environment. No incident content. Everything below is standing library knowledge — the maneuver family a mature MC shop keeps on hand for this control inventory, the deployed controls, and the coverage relations expressed as a function of control state — never a record of what happened, in what order, or by whom. **How to read these cards (term key).** - **Maneuver** — an atomic adversary behavior identified by its *objective-rooted observable effect* (MC-A1: "a maneuver's identity is its objective root," not any tool/technique label), written as a Hoare triple: **precondition → mechanism (invariant core) → postcondition**. - **Invariant core / implementation variant** — the core is the part of the mechanism the adversary cannot change without abandoning the goal; carries identity. Variants realize it different ways; the invariant is the primitive intersection across all variants (MC-A8, `InvariantIntersectionRule`). - **Observable / robustness (StP L1–L5)** — a telemetry-visible signal a mechanism manifests as (MC-A8). Robustness is a **ceiling on the analytic**, not a property of whether anything fired: L1 ephemeral < L2 configurable < L3 tool-artifact < L4 core-behavior < L5 invariant/chokepoint. - **Observable role — spanning vs. discriminating** — spanning = grounded in the invariant core, fires regardless of variant; discriminating = grounded in a specific variant, separates variants (or, per mc.ttl §14/§11b, benign from malicious — but this is an **authored, static, type-level** classification of a signal *class*, never a per-occurrence runtime judgment). - **Defensive control (`mc:Control`)** — a sensor whose own `controlStatus` (enforcing > impaired > killed) flows through the graph; `impaired`/`killed` set `degradesTelemetry true` and sever telemetry. - **Detect-face (`mc:Detectability`)** — the face a detection acts on. Four-valued health: **live** (trigger+enrichment intact) / **degraded** (enrichment severed, trigger fires) / **blind** (trigger severed) / **uncertain**. `triggerDependsOn` (lose it → blind) vs. `enrichmentDependsOn` (lose it → degraded). - **Coverage (`mc:coverage` → `covered`/`notCovered`)** — DERIVED, never asserted, per the constitutive CoverageRule (mc.ttl §17b, closing F2): *"a maneuver whose only detection face is blinded is NOT covered; a maneuver with a surviving (non-blind) detection face … IS covered."* > **THE HEADLINE HONESTY FLAG — read this before the matrix.** `faceStatus` has exactly four values, and **none of them means "fires, but the signal is authorized-looking."** In this environment every sourcing Control stays `enforcing` throughout (stated as standing posture below), so every face below is mechanically **live**, and by the rule just quoted every maneuver below is mechanically **covered**. That derivation is correct and unavoidable given the graph — and it is **operationally empty**: it certifies only that an event was logged, not that anything distinguishes it from the same account performing the same action for a legitimate reason. Treat every "covered" verdict in this card layer as **coverage-of-logging, not coverage-of-discrimination**, until Part D's flags are read. Do not let a mechanically-derived `covered` read as an assurance this ontology cannot back. --- ## A. Maneuver cards ### A1 — Authenticated remote interactive logon via a held credential `mRdpLogon` (T1021.001, sibling: generic network logon) **Observable effect:** a domain account authenticates to a remote host over a native Windows remote-logon protocol, establishing an interactive session using a credential it already holds. Named by *this effect* — a valid-credential remote authentication — not by the client program used. **Hoare triple.** - **Precondition —** the account holds the admin credential: `pCredAdminReq` (`rAccount.credentialHeld ⊇ credAdmin`, op `opSubsumes`). This precondition is **exogenous** to this maneuver family (see C.0): nothing below yields it. - **Mechanism (invariant core `coreRemoteLogon`)** — "authenticate to a remote host via a native interactive/network-logon protocol using the held credential." - **Postcondition — PARTIALLY INEXPRESSIBLE.** The intended effect is "the account now has an active interactive session executing on a *new* host" — a change of **position**. mc-core has no location fluent for a process/session (`mc:integrity` is a token/process attribute per WS-2.1/F1, not a host-assignment; a `ManeuverOccurrence` "binds the maneuver's roles to concrete entities," i.e. one process to one host, with no relocation write). This is the **same root gap** that makes lateral movement unauthorable as a maneuver in the Kerberoasting environment (recurring, not scenario-specific — see D7). The nearest expressible surrogate is a re-assertion of `rProc.integrity ⊇ userIntegrity` on the new session, which does **not** capture "on a new host" and should not be read as doing so. **Invariant core / variants.** `coreRemoteLogon` is realized by two authored variants sharing the same core: `varRdp` (T1021.001, RDP/type-10 interactive) and `varNetLogon` (generic network-logon sibling family, e.g. SMB/admin-share or WinRM-style authentication). Both compose the same underlying "authenticate with a held credential over a native remote-admin channel" primitive; the invariant is that authentication event itself, not the specific protocol. **Robustness of the key observable.** The logon-event observable (4624/4625-class, any type winlog1 admits) — **L4 (core-behavior).** Windows' own authentication stack generates this security event as a forced consequence of the logon mechanism; evading it requires abandoning this authentication channel entirely (a substantial tradecraft change, not a parameter tweak). **Role: spanning** — grounded in `coreRemoteLogon`, so it fires for either variant, and for other logon types winlog1 admits generically (its scope statement is "incl. type-10 RDP," i.e. not RDP-exclusive). **Linked detect-face.** `dfRdpLogon` — `sourcedFrom winlog1`, `dependencyLogic required` (single-sourced, no enrichment dependency authored). **Coverage in one line:** mechanically **live → covered** as long as winlog1 is enforcing (standing posture here — see B1). **But** this certifies only that the logon was logged; the face carries no signal for whether the credential is being exercised by its rightful holder or by someone else in custody of it (D1/D3). Do not read "covered" as "would be flagged." --- ### A2 — Remote code execution via native Windows administration `mRemoteExec` (T1047) **Observable effect:** an authenticated account invokes process creation on a remote host through a native Windows management interface, using a credential it already holds. **Hoare triple.** - **Precondition —** the account holds the admin credential: `pCredAdminReq` (same shared pattern as A1; native remote-WMI process creation requires admin-level rights on the target). - **Mechanism (invariant core `coreRemoteExec`)** — "invoke process creation on a remote host via a native Windows management/execution interface, using the held credential." One authored variant, `varWmiExec` (WMI `Win32_Process` creation path). - **Postcondition — PARTIALLY INEXPRESSIBLE**, same root cause as A1 (D7): the effect is "a new process now executes on host N," a position/host-assignment fact with no fluent to write. The nearest surrogate (`rProc.integrity ⊇ userIntegrity` on the new occurrence) does not capture *which* host, and — critically — **does not capture that the same account did this on more than one host.** See D6: a sweep across several hosts by one actor is, at best, several separate `ManeuverOccurrence` instances of `mRemoteExec`; nothing in the graph aggregates "N occurrences, one actor, one narrow window" into a first-class fact. **Robustness of the key observable.** The WMI process-creation trace (hostTelem1's Sysmon/WMI-Activity capture, including parent/child lineage and command line) — **L4 (core-behavior).** WMI-based remote execution cannot occur without the WMI provider creating the process and the operational log capturing it at the ETW layer; evading it means abandoning WMI-based native remoting for a channel hostTelem1 does not instrument. **Role: spanning** — grounded in `coreRemoteExec`, fires regardless of the payload/command line content. **Linked detect-face.** `dfRemoteExec` — `sourcedFrom hostTelem1`, `dependencyLogic required`. hostTelem1 is modeled here as **one** Control whose scope spans the three hosts it is deployed on; the face itself is not per-host. **Unmodeled sibling family (stub — no authored coverage record).** Other native remote-execution mechanisms (service-creation via the Service Control Manager, scheduled-task creation) sit alongside WMI in the same ATT&CK family. Section 3's telemetry description for hostTelem1 names only "remote WMI process-creation events" — it does **not** generalize the way winlog1's logon scope does. These siblings therefore get **no maneuver, no face, no coverage verdict** here; do not infer coverage for them from `dfRemoteExec`'s liveness. **Coverage in one line:** mechanically **live → covered** while hostTelem1 is enforcing (standing posture — B2). Same headline caveat as A1: this is a legitimate, fully-instrumented native-admin mechanism; the face cannot distinguish this account's routine remote-administration workload from the identical mechanism exercised under compromised custody. --- ### A3 — Ad hoc data-staging job via a sanctioned deployment/backup tool `mDataStage` (T1072) **Observable effect:** an authorized account uses the organization's sanctioned backup-and-deployment suite's own job-authoring interface to define an on-demand job scoping data across one or more hosts, including configuring the job's destination. **Hoare triple.** - **Precondition —** the account holds the admin credential: `pCredAdminReq` (job creation of this scope and destination-profile changes are admin-console actions on the sanctioned tool). - **Mechanism (invariant core `coreDataStage`)** — "use a sanctioned deployment/backup tool's own control plane to define a job's data scope and destination." One authored variant, `varAdhocJobCreate` (on-demand/ad hoc job authoring, as opposed to a pre-scheduled recurring job — the environment does not distinguish these at the telemetry level; both would be captured identically by `dfBackupJob`, so no discriminating observable exists between them, see D2). - **Postcondition — NOT EXPRESSIBLE (content gap, distinct in kind from the framework gaps above — see D8).** The intended effect ("a job now holds a defined data scope and an off-tenant destination, packaged but not yet moved") has no home in the seed value vocabulary: `mc-policy`'s only relevant fluents are `mc:Host.dataState {intact, encrypted}` and `mc:Host.exfilState {retained, exfiltrated}` — neither admits an intermediate "staged/scoped/destination-configured" value, and there is no `mc:Entity` subclass for the job object itself. **This maneuver is carried by objective + invariant core (MC-A1 identity), not by a postcondition** — the same authoring move used for Kerberoast's crackable-ticket effect in this library's Kerberoasting-environment card, and explicitly *not* a reason to fabricate a fluent. **Robustness of the key observable.** BackupOps' own audit-log entry (job creation, scope, initiating account, destination-profile change) — **L3 (tool-artifact).** This artifact is bound to *this specific tool's* control plane: an adversary who accomplished the same objective through a different mechanism (a different deployment product, or ad hoc scripted transfer) would not produce it at all. It is genuinely hard to avoid *while remaining inside BackupOps* (you cannot use the console without it logging), but it is evaded by a tool swap, which is what caps it at L3 rather than L4. **Role: spanning** with respect to the one authored variant; no discriminating observable is authored to separate an ad hoc job from a routine one (D2). **Linked detect-face.** `dfBackupJob` — `sourcedFrom bkops1`, `dependencyLogic required`. This is the **sole** modeled instance of the sanctioned-deployment-tool maneuver family in this environment — BackupOps is the only such tool in the control inventory (a control-inventory fact, not a framework gap). **Coverage in one line:** mechanically **live → covered** while bkops1 is enforcing (its own control plane, standing posture — B4). Same headline caveat: every field (initiating account, scope, destination change) is exactly what the account's legitimate, routine console use would also produce, and the face has no way to weigh that. --- ### A4 — Exfiltration over the sanctioned tool's own replication channel `mExfil` (T1537 / T1567.002) — *same maneuver type as this library's raw-HTTPS exfil entry; new variant* **Observable effect:** data configured in a staged job (A3) is moved to an off-tenant, adversary-controlled destination over the sanctioned tool's own established replication mechanism. **This is the identical objective-rooted maneuver — "move data to an adversary-controlled location" — carried elsewhere in this library under a raw-HTTPS variant; MC-A1 identity (objective root, not tool) means the same invariant core covers both.** A mature library's exfiltration entry generalizes across whichever channel realizes it. **Hoare triple.** - **Precondition —** the account holds the admin credential `pCredAdminReq` (destination-profile authorship is an admin-console action, A3) **and** the destination channel is reachable, `pReachReq` (`rChannel.reachability ≥ reachable`) — a standing environmental precondition, satisfied here because the sanctioned tool's own replication tier is, by design, already reachable to its provider's address range. - **Mechanism (invariant core `coreExfil`, reused)** — "move data to an adversary-controlled location." **Variant `varSanctionedToolRedirect`** — realizes `coreExfil` by redirecting the sanctioned tool's own established replication channel to an attacker-controlled destination within the same provider/address range that channel already uses, rather than opening a fresh outbound path. - **Postcondition —** `pExfilDone` (`rTarget.exfilState = exfiltrated`) — reusing the seed `exfilState` fluent exactly as in the raw-HTTPS entry. **Robustness of the key observable.** The outbound network-flow record (destination/volume/protocol) — **L4 (core-behavior).** Moving data off the network over IP cannot occur without producing an egress flow; evading it requires abandoning network egress as the exfiltration channel altogether (e.g. physical media — a different maneuver family). **Role: spanning** — fires regardless of destination or protocol detail, as long as it is IP-based egress. **Linked detect-face.** `dfEgress` — `sourcedFrom netmon1`, `dependencyLogic required`. **Critical robustness/discrimination split (see D2, D4):** the observable's L4 ceiling and netmon1's **allow-list logic** are two *different* things. The flow-record observable is robust — it fires, full stop. What fails is netmon1's allow-list rule, which treats any destination inside the sanctioned provider's already-used address range as known-good. That is a **discrimination** failure in the control's own rule, not a robustness failure in the observable. Raising the observable's robustness further (it is already at the L4 ceiling) does nothing for this; the two axes are orthogonal (mc.ttl §14: robustness "grades ANALYTICS, not observables… CEILING SEMANTICS"). **Coverage in one line:** mechanically **live → covered** while netmon1 is enforcing (standing posture — B5). Same headline caveat, sharpest here: the flow is fully logged and its observable sits at the robustness ceiling, and it is *still* not discriminable from the tool's own sanctioned replication traffic, because the allow-list operates on address range, not on legitimacy of use. --- ## B. Defensive control cards ### B1 — Windows Security Event Log `winlog1` — domain-wide + host audit - **What it is:** domain-wide plus per-host audit logging; `mc:Control`, `controlStatus` enforcing throughout this environment's standing posture. - **What it observes:** logons (4624/4625, including but not limited to type-10 RDP), process creation (4688), account state. - **Detect-faces it sources (trigger):** `dfRdpLogon` (A1) — sole source, `dependencyLogic required`. - **Failure mode:** any status setting `degradesTelemetry true` (impaired/killed) would sever `dfRdpLogon`'s trigger → blind → `mRdpLogon` notCovered. **Not the operative failure mode in this environment** — the control never leaves `enforcing` here; the operative gap is discrimination, not availability (Part D). ### B2 — Sysmon / WMI-Activity Operational log `hostTelem1` — endpoint process/WMI telemetry - **What it is:** endpoint telemetry on the three hosts in scope; `mc:Control`, enforcing throughout. - **What it observes:** remote WMI process-creation, parent/child lineage, command line. Modeled as one Control spanning all three hosts, not three separate instances. - **Detect-faces it sources (trigger):** `dfRemoteExec` (A2) — sole source, `dependencyLogic required`. - **Failure mode:** same structural point as B1 — trigger-loss would blind `dfRemoteExec`, but this control never leaves `enforcing` in this environment. ### B3 — SIEM correlation engine `siem1` — signature/rule-based only; sources no face for this family - **What it is:** a correlation `mc:Control` running signature/rule-based analytics only. **Explicitly carries no behavioral-baseline/UEBA analytic** — nothing here is keyed on an account's own historical norm. - **What it observes:** failed-logon bursts, blocklisted IPs/hashes, known-bad signatures. - **Detect-faces it sources:** **none, for this maneuver family.** `siem1` is a real, enforcing Control in this inventory — unlike present-but-unmodeled telemetry elsewhere in this library — but it has **no authored Detectability** keyed on "valid-credential, sanctioned-tool sequence," because it has nothing pattern-matchable to key on: no blocklist hit, no failed-logon pattern, no known-bad hash is present anywhere in this maneuver family by construction (every step uses a valid credential and a sanctioned tool). **Important:** this is not "an authorable face that merely isn't deployed" (contrast the Kerberoasting environment's `dfKerbVolume`, which *is* authorable at a higher robustness rung and simply undeployed). Here, **even a hypothetically deployed correlation rule over this exact sequence would still resolve through the same four-valued `faceStatus`**, which has no value for "authorized-looking." Adding more signature-engine rules does not close this gap (D1/D4). ### B4 — BackupOps console + audit log `bkops1` — the sanctioned tool's own control plane - **What it is:** the organization's sanctioned backup/deployment suite's own control plane; `mc:Control`, "always enforcing" per its own stated posture. - **What it observes:** job creation, scope, initiating account, destination-profile changes. - **Detect-faces it sources (trigger):** `dfBackupJob` (A3) — sole source, `dependencyLogic required`. - **Failure mode:** structurally as B1/B2. Not the operative gap here — this control's own audit trail is complete and intact throughout; the gap is that a routine, authorized use of the same console would populate the identical fields. ### B5 — Network egress monitor `netmon1` — perimeter, allow-list keyed - **What it is:** perimeter egress monitor; `mc:Control`, enforcing throughout. **Allow-lists the cloud-storage provider bkops1 itself already replicates to** — a standing configuration fact of this control, not an incident detail. - **What it observes:** outbound flow destination/volume/protocol (metadata only). - **Detect-faces it sources (trigger):** `dfEgress` (A4) — sole source, `dependencyLogic required`. - **Failure mode:** structurally as above. The operative gap is the allow-list's discrimination logic (destination-range membership, not legitimacy of use) — see A4 and D2/D4. ### B6 — AD / identity system — precondition substrate, not a detect-face source for this family - **What it is:** the domain directory; holds `mc:Account` state for the account in question — `credentialHeld`, enabled/non-expired, group membership, lockout count. - **What it observes (as state, not telemetry):** `d.alvarez`'s `credentialHeld` value (`⊇ credAdmin`), account-enabled flag, no-lockout flag. This is the shared precondition substrate for **all four** maneuvers above (C.0). - **Detect-faces it sources:** **none.** `credentialHeld` is a StateVariable read as a *precondition test*, not a telemetry feed with a `Detectability` attached. There is, in any case, no state variable on `mc:Account` for whether the current holder of a valid credential is its rightful owner (D3) — so even if a face were authored here, it would have nothing to key on. - **Topology note (standing environment fact, not incident narration):** this environment's topology includes an ordinary, non-admin-tier workstation as a distinct entity from the admin-tier hosts. Nothing in the `pCredAdminReq` precondition test references *which* entity the session originates from — a credential satisfying `credentialHeld ⊇ credAdmin` satisfies every precondition above identically regardless of source-host typicality. The model has no notion of "typical operating position for this credential" at all. --- ## C. Coverage relations ### C.0 — Precondition-supply structure (standing maneuver graph, type-level) This is library structure, not an incident chain. All four maneuvers (`mRdpLogon`, `mRemoteExec`, `mDataStage`, `mExfil`) **separately require** `pCredAdminReq` as an **external, exogenous** precondition — unlike this library's Black-Basta-style chain (where `mCred` *yields* the admin credential that unlocks downstream maneuvers), **nothing in this maneuver family establishes `pCredAdmin`; it is only ever consumed.** `mExfil` additionally requires `pReachReq` (destination reachability), satisfied here as a standing fact of the sanctioned tool's own replication tier. - **Chokepoint consequence (doctrine, not a prescribed action):** invalidating `pCredAdminReq` — i.e. revoking or rotating the credential — would remove the shared precondition of **all four** maneuvers simultaneously, a genuine chokepoint. **No prevent-locus `DefenderManeuver` is authored anywhere in this environment to invalidate it proactively**, and no react-locus `DefenderManeuver` instance carries the revoke/rotate action either — both function slots are structurally empty here, consistent with this library's recurring prevent/react-emptiness finding. A responder can derive *which lever matters* (C.0) but finds no authored defender maneuver to enact it. ### C.1 — Coverage matrix | Maneuver | Detect-face | Sourcing control | Robustness ceiling (role) | Constitutive verdict | Policy-graded (rank ≥ 4 / L4+) | What "covered" does NOT mean here | |---|---|---|---|---|---|---| | A1 `mRdpLogon` | `dfRdpLogon` | winlog1 (enforcing) | **L4** (spanning) | **covered** (live) | **admits** | not distinguishable from the account's routine remote logon | | A2 `mRemoteExec` | `dfRemoteExec` | hostTelem1 (enforcing) | **L4** (spanning) | **covered** (live) | **admits** | not distinguishable from routine remote administration; no cross-host aggregation exists even if it were (D6) | | A3 `mDataStage` | `dfBackupJob` | bkops1 (enforcing) | **L3** (spanning) | **covered** (live) | **inadmissible** (< 4) | not distinguishable from a routine job; sub-threshold on the robustness overlay *and* on discrimination — two independent failures, not one | | A4 `mExfil` | `dfEgress` | netmon1 (enforcing) | **L4** (spanning) | **covered** (live) | **admits** | allow-list keys on address range, not legitimacy; robust and covered and still non-discriminating | **Read the "admits" column carefully — it is not a discrimination signal either.** `pol:coverageAdmissionRank = 4` (StP L4+) is a **robustness**-graded overlay: it asks only "would this observable survive a technique swap," never "can this occurrence be told apart from an authorized one." A1/A2/A4 clearing the bar and A3 falling short of it are both **real, independent facts about evasion-resistance** — neither result says anything about the legitimacy-discrimination gap that is this environment's actual operational problem. Do not read "admits" as "trustworthy." ### C.2 — Per-maneuver residual-gap notes - **A1 (RDP logon):** single-sourced on winlog1; L4/spanning; mechanically covered. Residual: the model has no axis for "this logon's source host is atypical for this credential" (B6) even though that fact is present in the environment's own topology. - **A2 (remote exec):** single-sourced on hostTelem1; L4/spanning; mechanically covered. Residual: even a maximally live face here cannot represent "one actor, several hosts, one narrow window" as a single fact (D6) — the individuating pattern this environment's topology would need lives entirely outside what any single face, however live, can carry. - **A3 (data staging):** single-sourced on bkops1; L3/spanning; mechanically covered but **inadmissible** under the robustness overlay. Residual: this is the one maneuver where robustness-graded policy would (correctly, on its own terms) flag "don't fully trust this" — but for the wrong reason (evadability by tool-swap), not the operative reason (indistinguishability from routine use even *without* a tool swap). - **A4 (exfil via sanctioned channel):** single-sourced on netmon1; L4/spanning; mechanically covered and robustness-admitted. Residual: the sharpest case in this environment — full marks on every axis this ontology grades (logged, live, robust, admitted), and still zero discrimination, because the axis that would matter (is this destination authorized *for this occurrence*) is not one the allow-list or `faceStatus` can express. ### C.3 — The headline statement (repeat, load-bearing) **Every maneuver in this environment is mechanically `covered`, at `live` face health, sourced from a Control that never leaves `enforcing`, and three of four clear the robustness-graded admission bar — and none of that is evidence that any of this would be flagged for review.** The constitutive CoverageRule (mc.ttl §17b) derives `covered` correctly from face-health + control-state exactly as designed; the derivation is not wrong, it is **answering a question other than the one that matters here.** `faceStatus`'s four values (live/degraded/blind/uncertain) have no fifth value for "fires, but authorized-looking," and the `discriminating`/`spanning` `ObservableRole` split is an authored, static, type-level classification of a signal *class* — not a per-occurrence judgment that could flip because this particular holder of a valid credential is not its rightful owner. **Any statement of the form "the SIEM/EDR/logs covered this, so it would have been caught" is false reassurance and is not supported by this card layer.** --- ## D. Card-authorability report (framework-gap channel) **D1 — Degradation-by-legitimacy is inexpressible (the headline gap).** *Needed:* a `faceStatus` value, or an input to the CoverageRule, for "trigger fires and enrichment is intact, but the acting party's authorization for this specific occurrence cannot be verified." *Why the TBox can't:* `faceStatus` is derived *only* from Control-state (`enforcing`/`impaired`/`killed` via `degradesTelemetry`) and `triggerDependsOn`/`enrichmentDependsOn` dependency health — no predicate anywhere reads "does the acting party hold valid/authorized credentials **for this occurrence**." With every Control here enforcing and every trigger+enrichment intact (B1–B5), the rule **must** derive `covered` for all four maneuvers; there is no alternate derivation path and no fifth value. This is a missing **axis in the constitutive rule**, not a missing instance. *Consequence:* a card-reliant responder reproduces `covered` for every step (C.1) and, absent this flag, has no card-grounded reason to distrust it — the single most dangerous read this environment invites. **D2 — The "discriminating" `ObservableRole` and `Primitive`-tier benign/malicious predicate are the wrong layer.** *Needed:* a way to mark, or compute, that a *specific occurrence* of `dfRdpLogon`/`dfRemoteExec`/`dfBackupJob`/`dfEgress` is malicious rather than benign. *Why the TBox can't:* `mc:observableRole` (`spanning`/`discriminating`) is authored, static, and type-level — assigned once to a signal *class*, checked against its grounding by the `ObservableRoleConsistencyShape` (WS-1.5). Even authoring one of these four Observables as `discriminating` would still resolve, per occurrence, only through the same trigger/enrichment/Control-state machinery feeding `faceStatus` — it cannot flip based on runtime custody of the credential. `mc:Primitive`'s own definition states the closest thing to what's needed and rules it out in the same breath: "discrimination is a predicate over primitive attributes learned from the joint benign/malicious distribution — not a bespoke malicious primitive" (mc.ttl §11b) — i.e. even the primitive tier's discrimination concept is a *learned, static* predicate over a signal class, not a live judgment about who is presently exercising a valid credential. *Consequence:* the vocabulary that sounds closest to solving this (discriminating role, primitive-tier discrimination) is structurally the wrong altitude; a responder who goes looking for it in the cards will find it and still get no per-occurrence answer. **D3 — `mc:Account`/`credentialHeld` tracks privilege level, not custody.** *Needed:* a state variable for "this valid, unexpired, non-revoked credential is presently held by someone other than its rightful owner." *Why the TBox can't:* `credentialHeld`'s lattice (`credNone < {credUser, credAdmin} < credUserAdmin`) records *which privilege level* an account currently holds, never *who* is currently exercising it. B6's topology fact — an atypical, non-admin-tier source host for this credential — is present in the environment but plays no role in any precondition test; `pCredAdminReq` is satisfied identically regardless of source-host typicality. A maneuver occurrence whose only precondition is `credAdmin` is, by construction, indistinguishable from the legitimate owner exercising the same access. This is the root cause feeding D1. **D4 — No behavioral-baseline / UEBA / just-in-time-access vocabulary on `DefenderManeuver`.** *Needed:* a `DefenderManeuver` that can express "flag this occurrence against this account's own historical norm" or "require a bounded, purpose-scoped grant before this precondition can be satisfied." *Why the TBox can't:* `DefenderManeuver`'s three relations — `invalidates` (prevent, removes a precondition pattern), `observesFace` (detect, realizes an existing `Detectability`), `evicts` (react, reverses a postcondition pattern) — can only act on conditions the maneuver graph already expresses. None can compare an occurrence to a baseline or gate a precondition behind an external authorization token. `siem1`'s own stated absence of a UEBA analytic (B3) is the environment-specific instance of this framework-level absence — deploying more signature rules on `siem1` would not close it, because the gap is in what `DefenderManeuver` can express, not in what `siem1` happens to run. *Consequence:* the response class that would actually help here (behavioral baselining, JIT/scoped privileged access) is not authorable, only disclosable as absent. **D5 — No business-process / change-management telemetry class.** *Needed:* a queryable fact for "was this configuration/data-movement action authorized by a change record." *Why the TBox can't:* `bkops1`'s audit fields (job creation, scope, initiating account, destination-profile changes — B4) are exhaustively enumerated in this environment's control inventory and none of them is a change-ticket/authorization record; more fundamentally, `mc:Entity`/`mc:Control`/`mc:Observable` are telemetry/technical-control classes, and a change-management record is neither a persistent stateful entity in that sense nor a telemetry-visible manifestation of a mechanism (MC-A8). *Consequence:* even the one out-of-band tell this kind of environment could in principle offer has no home in the model at all — not degraded, not silent-by-absence-of-instance, but categorically unauthorable. **D6 — No cross-face / cross-maneuver correlation combinator.** *Needed:* a construct joining *sibling* `Detectability` instances belonging to different maneuvers/occurrences that share an actor or session — e.g. "this account, these three hosts, this narrow window, a brand-new destination." *Why the TBox can't:* `mc:DependencyLogic` (`required`/`redundant`/`triggerPlusEnrichment`/`kOfN`) combines only the *dependencies of one Detectability* (B1–B5 confirm each of the four faces here is single-sourced, `required`, with no dependency on any sibling face). The one other candidate, `mc:Investigation`, is built to observe **one** discriminating variable to answer **one** investigative question (mc.ttl §1) — it has no construct for synthesizing four separate `Detectability` instances, each `sourcedFrom` a *different* Control (B1/B2/B4/B5), into one composite judgment. *Consequence:* the individuating pattern that would separate this account's ordinary work from anomalous use — one account, narrow window, an atypical breadth of hosts (A2), a brand-new destination (A4) — lives entirely in a cross-face join the framework has no place to author. **D7 — Position/session-location change is unmodeled (recurring gap).** *Needed:* a maneuver postcondition expressing "the adversary's session now executes on a new host." *Why the TBox can't:* `mc:integrity` is a token/process attribute, not a host-assignment fluent (WS-2.1/F1); `ManeuverOccurrence` binds one process to one host with no relocation write; `reachability` is a static precondition between positions, not a movement. This is the same gap already on record for this library's lateral-movement card in the Kerberoasting environment, recurring here for `mRdpLogon` (A1) and `mRemoteExec` (A2) under a different mechanism family. *Consequence:* A1/A2 are authored as stubs on their postcondition side (identity carried by objective + invariant core, MC-A1), and a responder expecting a "now on host N" fact from the cards gets none. **D8 — Intermediate "staged/configured-but-not-yet-transferred" data state has no seeded value — a policy-content gap, not a framework gap.** *Needed:* a fluent value between `retained` and `exfiltrated` (or an entity for the job object itself) to carry `mDataStage`'s (A3) postcondition — "scoped, destination configured, nothing moved yet." *Why the seed vocabulary can't:* `mc-policy`'s `exfilState {retained, exfiltrated}` is a two-value nominal fluent on `mc:Host`; there is no `mc:Entity` subclass for a job/backup-set object and no intermediate value. **This is distinct in kind from D1–D7:** the constitutive machinery (`StateVariable`/`admitsValue`) already supports adding an intermediate value or a new Entity subclass — `mc-policy.ttl` explicitly invites extending its seed vocabularies "per corpus." It is a closeable content gap, not a constitutive limitation; it is listed here, not silently patched, because this card layer stays strictly inside the currently-loaded TBox/policy and does not invent new classes or values to paper over it. *Consequence:* A3 is authored as an objective+invariant-core stub on its postcondition side, same authoring move as A1/A2/D7 but for a different (policy-level) reason. --- ### Validation footer - **One invariant core per maneuver:** `mRdpLogon`→`coreRemoteLogon`, `mRemoteExec`→`coreRemoteExec`, `mDataStage`→`coreDataStage`, `mExfil`→`coreExfil` (reused from this library's raw-HTTPS exfil entry, new variant `varSanctionedToolRedirect`) — satisfied in every A-card, no maneuver assigned more than one core. - **Robustness stated as an observable ceiling only**, never as a realized analytic score or a property of a maneuver/face: L4 (dfRdpLogon, dfRemoteExec, dfEgress' observables), L3 (dfBackupJob's observable) — each graded per §14's ceiling semantics. - **Coverage presented as DERIVED**, never asserted: every verdict in Part C follows face-health + control-state (all controls stationary at `enforcing`) per the CoverageRule (mc.ttl §17b); no coverage or robustness verdict is asserted for the unmodeled sibling families (A2's native-exec siblings) or for the account-custody question (D3) — those are stated SILENT/unauthorable, not inferred. - **Objective vocabulary extension flagged, not hidden:** `objLateralMovement` (TA0008) and `objCollection` (TA0009) are authored additions to `mc-policy`'s seed `Objective` value set, exercising the extensibility `mc-policy.ttl` itself documents ("extend per corpus") — an instance-level addition to an existing extensible class, not a change to `mc.ttl`'s constitutive classes/properties. - **No retired constructs used** (no AMC, ORTG, forcedness, chokepointCoupling, `covers`-as-coverage, `transition`-as-unit, six-fork state model, or `react` in place of `respond`); canonical names used throughout (`Detectability`, `DependencyLogic`, `respond`, `EvidenceClaim`, `subsumes`). - **No incident timeline, sequencing, or occurrence-level narrative appears anywhere above** — every claim is either a standing control-inventory/topology fact from this environment's Part 3 (environment model) or a doctrine-level maneuver/robustness/coverage construction, never a record of what happened, when, or in what order.