Chapter 54 — Detecting the attack paths from Part 1

In one sentence

Your attack-path graph (Part 1 Ch 1) is not just an offensive artefact — every chokepoint on it is a candidate detection, and building coverage that way guarantees your detection backlog is prioritised by what would actually hurt, not by what's easy to write a rule for.

Where we are

Part 1 taught you to model attack paths and find chokepoints. Chapters 51-53 gave you the lifecycle, telemetry, and intelligence to build good detections. This chapter closes the loop: turning specific chokepoints from Parts 2-6's labs into a concrete, prioritised detection backlog.

How it works

The method — this is the whole chapter's idea in one paragraph: for every edge in a critical attack path (Part 1 Ch 1), ask "what would this specific step look like in our telemetry (Ch 52), and do we have a detection for it (Ch 51)?" Do this systematically across the paths you've already found in this guide's own labs, and you get a detection backlog that is, by construction, aligned to your actual, demonstrated risk rather than a generic checklist.

Cloud privilege-escalation and credential-theft detections (Part 2):

   IMDS CREDENTIAL THEFT (Part 2 Ch 10's lab)
     - a role's SESSION CREDENTIALS used from a sourceIPAddress outside
       your known VPC/NAT ranges (Part 2 Ch 5's worked example) --
       fastest-signal version of this detection; don't wait for the
       vendor's own finding (GuardDuty et al.) which can lag.
     - IMDSv1 GET requests to the metadata service from a workload (if
       your environment should be IMDSv2-only, ANY v1 usage is itself an
       anomaly worth alerting on, not just successful theft).
   IAM PRIVILEGE ESCALATION (Part 2 Ch 6)
     - the Sigma rule pattern from Ch 51: CreatePolicyVersion +
       SetDefaultPolicyVersion in a short window by a non-admin principal.
     - iam:PassRole immediately followed by a compute-creation call
       (RunInstances, CreateFunction, ...) where the passed role's
       privilege level exceeds the calling principal's own -- this
       DIRECTLY encodes the Ch 6 primitive as a detection.
     - AttachUserPolicy/AttachRolePolicy/PutUserPolicy/AddUserToGroup by
       any principal outside your designated IAM-admin group.
   ORG/GUARDRAIL TAMPERING (Part 2 Ch 7)
     - any attempt to modify an SCP, disable CloudTrail, or leave the
       organisation -- these should be RARE, HIGH-SEVERITY, and, per
       Ch 7's guardrails, mostly PREVENTED outright; any attempt (even a
       denied one) is worth alerting on as reconnaissance/intent.

Kubernetes and container detections (Part 4):

   RBAC ESCALATION (Part 4 Ch 17's lab) -- Kubernetes AUDIT LOG based:
     - `pods.create` (or any workload-kind create) where
       `requestObject.spec.serviceAccountName` differs from the creating
       identity's OWN typical/default SA and isn't the recognised CI/CD
       deploy identity (Ch 51's worked example, in full).
     - `clusterrolebindings.create` or `rolebindings.create` granting
       `cluster-admin` (or any binding to a highly-privileged role)
       outside a recognised platform-team change window.
     - use of the `escalate`, `bind`, or `impersonate` verbs by any
       identity -- these are RARE in legitimate operation; near-zero
       false-positive tolerance justified.
   CONTAINER ESCAPE (Part 4 Ch 15/22's labs) -- RUNTIME telemetry (Falco/
     Tetragon):
     - the specific escape-attempt rule from Part 4 Ch 20 (nsenter -t 1,
       release_agent writes, cgroup mount attempts) -- reuse it directly.
     - a shell spawned in a container using a DISTROLESS/no-shell image
       (Part 4 Ch 20) -- should be a NEAR-IMPOSSIBLE event and therefore
       maximally high-confidence when it occurs.
   ADMISSION/WEBHOOK TAMPERING (Part 4 Ch 16)
     - any create/update of a ValidatingWebhookConfiguration or
       MutatingWebhookConfiguration outside a recognised deployment
       pipeline.

Supply-chain and pipeline detections (Part 3):

   OIDC TRUST ABUSE (Part 3 Ch 12) -- cloud-side: a role assumption via
     the CI OIDC provider where the `sub` claim doesn't match the exact
     expected repo+ref/environment pattern (this should be PREVENTED by
     the trust policy itself, per Ch 12 -- but alert on any attempted
     assumption that the trust policy rejects, as reconnaissance signal).
   UNSIGNED/WRONG-IDENTITY IMAGE ADMISSION ATTEMPTS (Part 3 Ch 13) -- the
     Kyverno/Sigstore admission DENIAL events themselves are a detection
     source: a pattern of denied deployments from an unexpected registry
     path or identity is worth alerting on as a possible compromise
     attempt against the pipeline, not just a routine policy rejection.
   WORKFLOW FILE CHANGES on protected branches (Part 3 Ch 12) -- CI
     platform audit log: any change to `.github/workflows/**` (or your
     platform's equivalent) merged without the required CODEOWNERS
     review.

Web/API attack-path detections (Part 6):

   REQUEST SMUGGLING / DESYNC ATTEMPTS (Part 6 Ch 30) -- WAF/proxy-layer
     logs: requests with BOTH Content-Length and Transfer-Encoding
     headers, or malformed/obfuscated Transfer-Encoding values -- these
     should be RARE from legitimate clients and are a strong signal on
     their own.
   RACE-CONDITION EXPLOITATION ATTEMPTS (Part 6 Ch 35) -- application-
     layer: a burst of near-simultaneous identical requests (same
     idempotency-relevant parameters, e.g. the same gift-card code or
     order ID) from the same session/IP within a sub-second window.
   OAUTH/SAML ATTACK PATTERNS (Part 6 Ch 39) -- IdP and application logs:
     multiple OAuth token exchanges with mismatched `aud`/`iss` rejected
     in a short window (mix-up attempt signature); SAML responses failing
     signature-reference validation (an XSW attempt signature, distinct
     from routine signature failures caused by clock skew -- tune
     carefully).

The prioritisation rule: don't try to build all of these at once. Rank by the SAME formula as Part 1 Ch 1's path-risk scoring — reachability, feasibility, value of the goal, and (now, explicitly) the INVERSE of your current detection coverage. A critical, highly-reachable path with ZERO detection today outranks a merely-plausible path that already has partial coverage.

Worked example

Building the detection backlog from this guide's own labs, end to end.

   Starting point: SecureShop's cumulative attack-path graph across Parts
   1-6's hands-on labs (an attacker really could combine several of
   these, exactly as Part 6 Ch 40's capstone required).

   BACKLOG (excerpt, ranked by the path-risk formula):
     1. [CRITICAL, zero coverage] IMDS credential theft via SSRF
        (Part 2 Ch 10 chain) -> DETECTION: session credentials used from
        outside known ranges. BUILD FIRST.
     2. [CRITICAL, zero coverage] k8s RBAC escalation via serviceAccount-
        Name on pod create (Part 4 Ch 17/22) -> DETECTION: the audit-log
        rule from this chapter. BUILD SECOND.
     3. [HIGH, partial coverage via generic WAF rules] Request smuggling
        attempts against the checkout flow -> DETECTION: the CL/TE-
        header-conflict rule; existing WAF coverage is generic, this adds
        the specific signature. BUILD THIRD.
     4. [HIGH, zero coverage] OAuth token mix-up attempts against the
        multi-IdP support flow -> lower reachability (requires a specific
        multi-IdP client misconfiguration Part 6 Ch 39 already mostly
        fixed) -> BUILD FOURTH, after confirming the fix, as defence in
        depth.
     5. [MEDIUM, existing coverage adequate] generic brute-force login
        attempts -> already well-covered by an off-the-shelf rule; no
        new work needed here despite being a "real" attack path, because
        coverage already matches the risk.

   Each of items 1-4 goes through the FULL Ch 51 lifecycle (hypothesis,
   Sigma rule, unit test, live validation by re-running the ACTUAL lab
   attack from the relevant Part, tune, measure). Item 5 is explicitly
   marked "adequate, no action" -- the backlog isn't just a list of
   things to build, it's a complete risk-vs-coverage picture, and knowing
   what NOT to spend more effort on is as valuable as knowing what to
   build next.

Practice (90 min)

Pull together the attack-path graphs (or just the key findings) from every hands-on lab you've completed in Parts 1-6 of this guide.
For each critical/high-risk path, write down: does a detection exist today? If yes, was it live-validated against the SPECIFIC technique from that lab (not just a generic version)? If no, add it to a backlog.
Score the backlog using the path-risk formula (Part 1 Ch 1) including the detection-coverage-inverse factor from this chapter.
Take the TOP-RANKED item and run it through the full Chapter 51 lifecycle: hypothesis, rule, unit test, live validation by re-running the actual lab attack, tune.
Produce a one-page "detection backlog" document ranking all items, with the top one marked DONE and the rest prioritised for follow-up — this is a real, reusable artefact for an actual security program (Ch 58-59).

Common mistakes

Building detections generically instead of from your own demonstrated attack paths. Generic community content (Ch 51's HM2 level) is a baseline, not a substitute for detections aligned to YOUR specific chokepoints.
No live validation against the exact lab technique. A rule that "should" catch the pattern in theory, never re-run against the actual attack that motivated it, is unproven.
Treating every attack path as equally urgent. Use the same risk-scoring discipline from Part 1 Ch 1 to prioritise the backlog, including the detection-coverage factor.
No explicit "adequate, no action needed" entries. A backlog that only lists gaps, with no record of what's already well-covered, gets re-litigated repeatedly.
Building the detection but never closing the loop back to the labs. Detection engineering (Ch 51) and the offensive labs from earlier Parts should feed each other continuously, not run as separate, disconnected workstreams.

Check yourself

What is the core method this chapter proposes for generating a detection backlog?
Give two detections you could build directly from Part 2's cloud privilege-escalation labs, described precisely enough to write as a hypothesis.
Why does the Kubernetes AUDIT LOG matter for detecting Part 4's RBAC escalation, distinct from Falco's runtime syscall telemetry?
How should you rank items in an attack-path-derived detection backlog?
Why is an explicit "adequate coverage, no action" entry as valuable as a gap entry in this backlog?