Case Study 2: Engineering Detections from a Campaign Report

"We don't have a hunting team yet. But we can read, and we can write rules. Let's turn this report into detections before the adversary turns up." — Detection lead, Northvale Health System (constructed)

Executive Summary

Where Case Study 1 was a hunt — a human searching reactively for an adversary already suspected to be present — this case study is its complement: proactive detection engineering, building automated rules ahead of an adversary, driven entirely by published threat intelligence. Northvale Health System, a regional hospital network, has no dedicated threat-hunting team and a small SOC. A national cybersecurity agency publishes a detailed advisory on a ransomware-affiliated intrusion set targeting healthcare, complete with ATT&CK-mapped techniques. The detection lead, Aisha Okonkwo, turns that advisory into a prioritized set of Sigma rules — deciding what to detect, mapping each technique to data Northvale actually collects, writing the rules with their ATT&CK tags, and discovering (the hard way) that the most dangerous gap is not a missing rule but a missing data source. You will see threat intelligence become detection-as-code, the pyramid of pain dictate where to spend scarce engineering time, and a coverage map expose blind spots before a breach finds them. The scenario, indicators, and figures are constructed for teaching (Tier 3); the techniques, ATT&CK IDs, and Sigma patterns are real. This case is design/build-and- governance-heavy by contrast with Case Study 1's analysis-heavy hunt.

Skills applied: triaging threat intelligence for relevance; extracting techniques (not just indicators) from a campaign report; mapping techniques to required data sources; writing ATT&CK-tagged Sigma rules; prioritizing detection work by the pyramid of pain; coverage mapping as gap analysis; recognizing a data-source gap as the most expensive blind spot.

Background

Northvale Health System runs six hospitals and forty clinics. Like much of healthcare, it is a target-rich, defense-poor environment: legacy clinical systems that cannot be patched without vendor sign-off, medical devices that run unsupported operating systems, a sprawling Active Directory, and a SOC of four analysts who spend most of their day clearing a noisy alert queue. Healthcare is among the most-attacked sectors because the stakes are life-and-death (an encrypted electronic-health-record system can divert ambulances) and the willingness to pay ransom is high.

Aisha Okonkwo leads what passes for detection engineering at Northvale — which, until recently, meant "whatever rules came with the SIEM." She has been trying to make the case for a more deliberate practice. The argument lands when a national cyber agency (in the U.S. this role is played by CISA) publishes a joint advisory on a ransomware-affiliated intrusion set actively hitting hospitals. Unlike a vendor blog full of hashes, this advisory is operational: it describes the adversary's behavior end to end, mapped to MITRE ATT&CK. Aisha reads it not as a warning to file but as a backlog of detections to build.

🔗 Connection: This is the §22.3 pipeline in its purest form — intelligence → detection — and it is the right first move for a team without a hunting capability. You cannot hunt at scale with four analysts, but you can read a high-quality advisory and convert its techniques into durable, automated detections. Detection engineering raises the floor so the small SOC isn't re-discovering known attacks by hand. Hunting (Case Study 1) is the next maturity step; engineering from intel comes first.

The advisory, distilled

Aisha extracts the adversary's behavior from the advisory and lays it out against the ATT&CK kill chain. She is deliberate about separating indicators (which she will load but not rely on) from techniques (which she will engineer detections for), exactly as §22.3 prescribes:

NORTHVALE INTEL TRIAGE  — Advisory AA-2026-HC-09  (TLP:CLEAR)
Relevance: HIGH (explicitly targets healthcare; ransomware end-state).

INDICATORS (load into TIP/SIEM; low-confidence, short-lived — bottom of pyramid):
  - 4 file hashes, 6 C2 IPs, 3 domains.  -> match-only; do not rely on.

TECHNIQUES (engineer detections — top of pyramid, durable):
  Initial Access   T1566.001  Spearphishing Attachment
  Execution        T1059.001  PowerShell
  Persistence      T1547.001  Registry Run Key
  Priv. Esc.       T1548.002  Bypass UAC
  Defense Evasion  T1562.001  Impair Defenses: Disable/Modify Tools (kills AV/EDR)
  Cred. Access     T1003.001  OS Credential Dumping: LSASS Memory
  Discovery        T1018      Remote System Discovery
  Lateral Movement T1021.002  SMB/Windows Admin Shares
  Impact           T1486      Data Encrypted for Impact (the ransomware itself)

⚠️ Common Pitfall: Stopping at the indicators. A less experienced analyst would load the 13 indicators and report "we're covered for AA-2026-HC-09." But the advisory's own context makes clear the infrastructure rotates; those indicators are nearly dead on arrival. The techniques are the durable intelligence — and a ransomware actor cannot reach their objective without performing most of that bottom list (dump credentials, move laterally, disable defenses, encrypt). Engineer for the techniques.

The Build

Phase 1 — Prioritize by the pyramid (and by the kill chain)

Aisha cannot build nine robust detections at once with her team. She prioritizes, using two lenses from the chapter. First, the pyramid of pain: she favors detections on techniques the adversary cannot cheaply change. Second, kill-chain leverage: a detection earlier in the chain (before encryption) buys time to respond, but a detection on a technique the adversary must use is more reliable. She reasons through the tradeoffs:

• Credential dumping (T1003.001) and disabling defenses (T1562.001) are near-mandatory steps for this actor and are behaviorally detectable (touching LSASS memory; stopping AV/EDR services). High value, durable. Build first.
• PowerShell execution (T1059.001) is heavily used but also heavily legitimate in a hospital's IT environment — a naive rule drowns the SOC in false positives. Build, but carefully, keying on suspicious PowerShell (encoded commands, download cradles), not all PowerShell.
• Registry Run Key persistence (T1547.001) and SMB lateral movement (T1021.002) are durable and detectable; build next.
• Spearphishing attachment (T1566.001) is partly covered by the existing email gateway; she notes it as "partial" rather than rebuilding it.
• Data Encrypted for Impact (T1486) — the ransomware itself — is the last thing to happen and the worst time to first detect; a detection here is a last-resort tripwire, not a strategy. She wants to catch the actor long before this.

DETECTION BACKLOG (prioritized)         PYRAMID   FALSE-POS RISK   BUILD ORDER
  T1003.001  LSASS credential dumping    high      low             1
  T1562.001  Disable AV/EDR              high      low             2
  T1547.001  Run-key persistence         high      med             3
  T1021.002  SMB lateral movement        high      med             4
  T1059.001  Suspicious PowerShell       high      HIGH            5 (tune hard)
  T1566.001  Spearphishing attachment    med       (gateway)       partial
  T1486      Ransomware encryption       n/a       low             tripwire only

The prioritization logic rewards a closer look, because it is the heart of detection strategy under scarcity. Aisha is balancing three considerations at once. First, durability (the pyramid of pain): she favors techniques the adversary cannot cheaply change — dumping LSASS, stopping the AV service — over anything an adversary swaps out for free. Second, kill-chain position: a ransomware intrusion is a sequence, and the earlier in that sequence she can detect, the more time the SOC has to respond before the irreversible step (encryption). Catching the actor at credential access or lateral movement means catching them hours or days before they encrypt; catching them at encryption means catching them as the damage is already being done. Third, false-positive cost: a technique like PowerShell is both high-value and high-noise, so it ranks lower not because it's unimportant but because shipping it badly would flood four analysts and get the whole detection program distrusted.

The interplay of these three is why the ransomware-encryption detection (T1486) sits last despite being the most catastrophic technique. It is the worst possible place to first notice the adversary — by the time files are encrypting, every earlier detection opportunity has already been missed, and the SOC's job shrinks from "stop an intrusion" to "limit a disaster." Aisha keeps a tripwire for it anyway (mass file modification with ransomware-like extensions is cheap to detect and a genuine last line), but she is explicit that a program whose best ransomware detection is the encryption itself has already lost. The whole point of mapping the actor's full kill chain is to build detection upstream of impact, so the actor trips a wire while they are still quietly dumping credentials, not while they are loudly encrypting the radiology server.

🔗 Connection: This upstream-detection logic is the same defense-in-depth idea (Theme 4) you have seen applied to prevention throughout the book, now applied to detection. Each ATT&CK tactic the adversary must pass through — initial access, execution, persistence, credential access, lateral movement, impact — is an independent chance to catch them. A detection at each stage means the defender does not have to be right at one single point; an adversary who evades the execution detection may still trip the credential-access or lateral-movement wire. Detection in depth, like defense in depth, assumes any single detector will sometimes fail and stacks independent chances so that one miss is survivable.

Aisha writes each detection as a Sigma rule, tagged with its technique, version-controlled in a git repository so the catalog is reviewed and auditable — the detection-as-code practice from §22.4. Here is the highest-priority one, for credential dumping from LSASS memory:

title: Suspicious Access to LSASS Process Memory
id: 7c0ffee0-1234-4abc-9def-0123456789ab
status: stable
description: >
  Detects a non-system process opening a handle to lsass.exe with access
  rights that permit reading process memory — the core action of credential
  dumping, regardless of which tool performs it.
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: Northvale SOC (A. Okonkwo)
date: 2026/05/14
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_access      # Sysmon Event ID 10 / EDR process-access telemetry
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'                 # PROCESS_VM_READ | PROCESS_QUERY_INFORMATION
      - '0x1410'
      - '0x143a'
  filter_known_good:
    SourceImage|endswith:
      - '\MsMpEng.exe'           # Defender legitimately touches LSASS
      - '\wmiprvse.exe'
  condition: selection and not filter_known_good
falsepositives:
  - Endpoint protection and some monitoring agents legitimately read LSASS;
    suppressed via filter_known_good — review the allowlist quarterly.
level: high

The rule is behavioral in the §22.2 sense: it does not match a hash or a tool name; it matches the action (reading LSASS memory) that credential dumping requires no matter which tool the adversary uses. Change the tool, recompile the malware, rotate the C2 — this rule still fires, because the adversary cannot dump credentials without touching LSASS. That is a top-of-the-pyramid detection, and it is durable precisely because it costs the adversary their objective to evade. Aisha writes the others the same way: T1562.001 keys on the stopping of security services, T1547.001 on writes to autostart registry keys, T1021.002 on the pattern of admin-share access across many hosts from one source.

Here is the second-priority rule, for the adversary disabling endpoint defenses (T1562.001) — a step this ransomware actor performs to blind the very tools meant to catch them:

title: Security Service Stopped or Disabled
id: 0badf00d-2345-4bcd-8ef0-123456789abc
status: stable
description: >
  Detects the stopping, disabling, or deletion of an endpoint-protection
  service (AV/EDR) — a defense-evasion step ransomware actors take before
  encryption to remove the tooling that would otherwise catch them.
references:
  - https://attack.mitre.org/techniques/T1562/001/
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    Image|endswith: '\sc.exe'
    CommandLine|contains:
      - 'stop'
      - 'delete'
    CommandLine|contains|all:
      - 'Sense'        # Defender for Endpoint service (example)
  selection_psh:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'Stop-Service'
      - 'Set-MpPreference -DisableRealtimeMonitoring $true'
  condition: selection_sc or selection_psh
falsepositives:
  - Sanctioned maintenance by IT during agent upgrades — should come from a
    known admin host/account and a change ticket; everything else is suspicious.
level: high

Notice the design choice: rather than chase every possible way to kill a service, Aisha keys on the two most common mechanisms (the sc.exe service-control utility and PowerShell's service cmdlets) and explicitly names the security service. The rule is not exhaustive — a determined adversary could stop the service through a less common API — but it covers the techniques this actor uses and the ones most actors reach for first. Detection engineering is not about catching every theoretical path; it is about raising the cost of the common paths and tagging the rule so a coverage map shows honestly what is and isn't covered. Perfect is the enemy of shipped.

Before deploying either rule, Aisha does the step that separates engineering from wishful thinking: she tests the detection. Using a safe, ATT&CK-mapped test from a library like Atomic Red Team — run only on an isolated lab machine she is authorized to use — she performs the benign equivalent of the technique (e.g., a tool reading LSASS, or sc.exe stop against a dummy service) and confirms the rule actually fires on the telemetry it produces. A detection that has never been tested against the behavior it claims to catch is a hypothesis, not a control. More than once, the test reveals that the rule's logsource doesn't match how her SIEM indexes the data, or that a field name differs from what the Sigma rule assumed — gaps that would have meant silent failure in production, the worst kind, because the rule would appear deployed while catching nothing.

🛡️ Defender's Lens: Each rule carries a filter_known_good block, and writing it is the skill of detection engineering. A hospital is full of legitimate processes that look like attacks — backup agents touching files en masse, management tools using admin shares, Defender reading LSASS. The rule is only deployable once Aisha has characterized the benign reality and suppressed it. This is the false-positive side of the §22.6 tradeoff, handled per-rule and on purpose. A rule without a tuned filter either floods the SOC (and gets ignored) or gets disabled — either way it stops protecting anyone.

Phase 3 — The blind spot: a missing data source

Aisha hits a wall on the most important rule. The LSASS credential-dumping detection (T1003.001) requires process-access telemetry — specifically Sysmon Event ID 10 or equivalent EDR data, recording when one process opens a handle to another. Northvale's SIEM does not collect it. The clinical-workstation fleet runs an aging endpoint agent that produces process-creation logs but not process-access logs. The most durable, highest-value detection she designed cannot fire, because the data it needs does not exist.

This is the case study's central lesson, and it is the harder half of §22.6: a red cell on a coverage map can mean "no rule" or "no data," and the second is the more expensive gap. Writing the Sigma rule took Aisha an afternoon. Closing the data gap — deploying Sysmon (or upgrading the EDR) across thousands of clinical workstations, many of which are locked down by medical-device vendors and cannot be freely modified — is a multi-month, cross-team project requiring change-control, vendor sign-off, and budget. The rule is useless until the data arrives.

NORTHVALE COVERAGE MAP  (excerpt, after the build)
  ███ rule + data    ▒▒▒ rule, partial/legacy data    ░░░ NO coverage

  Initial    Execution  Persist.   Cred.       Defense    Lateral    Impact
  Access                            Access      Evasion    Movement
  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
  │T1566.001│ │T1059.001│ │T1547.001│ │T1003.001│ │T1562.001│ │T1021.002│ │ T1486  │
  │  ▒▒▒    │ │  ▒▒▒   │ │  ███   │ │  ░░░ ◄──│ │  ███   │ │  ▒▒▒   │ │  ▒▒▒   │
  │(gateway)│ │(tuning)│ │        │ │RULE but │ │        │ │(legacy │ │(tripwire│
  │         │ │        │ │        │ │NO DATA! │ │        │ │ EDR)   │ │ only)  │
  └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
                                       ▲
              The rule is WRITTEN and correct — but the SIEM doesn't collect
              process-access telemetry, so it can never fire. The blind spot
              is a DATA gap, not a rule gap, and it's the expensive kind.

Figure CS2.1 — Northvale's coverage after the build. Coverage mapping doubled as a data-source gap analysis: it revealed that the single most valuable detection was blocked not by missing logic but by missing telemetry. The honest report to leadership is not "we have a detection for credential dumping" — the rule exists but cannot fire — but "we have the rule; we are blind until we deploy the data source, and here is what that costs."

Aisha makes exactly that honest report. She does not let the written-but-dead rule inflate a coverage percentage. She presents leadership with a ranked plan: the rules that fire today (persistence, disable- defenses), the rules waiting on the data-source project (credential dumping), and the cost and timeline to close the data gap. The advisory becomes a funded program rather than a filed PDF.

🔄 Check Your Understanding: Aisha wrote a correct, well-tuned Sigma rule for credential dumping, yet her coverage map shows that technique as a red (no coverage) cell, not green. Why is that the honest call — and why is reporting it as "covered" worse than reporting it as a known gap? (Hint: a false- negative blind spot you believe is covered is more dangerous than one you know is open, because you stop watching for it.)

Phase 4 — Reporting honestly, and the maturity step beyond

How Aisha reports this work matters as much as the rules she wrote, because the report is what gets the data-source project funded — and because the temptation to dress it up is strong. The easy version of the report is a single green number: "We assessed advisory AA-2026-HC-09 and now have detections for 7 of 9 techniques — 78% coverage." It would please leadership and it would be a lie of exactly the kind §22.6 warns against. Two of those "detections" are partial (the email gateway, a legacy-EDR lateral-movement rule), one (the most important, credential dumping) cannot fire at all, and the percentage weights the ransomware-encryption tripwire the same as the credential-dumping detection that actually matters.

Aisha reports the truth instead, in a form leadership can act on:

NORTHVALE DETECTION STATUS — Advisory AA-2026-HC-09
  FIRING TODAY (tested, deployed):
    T1547.001 Run-key persistence      ✓
    T1562.001 Disable AV/EDR           ✓
  PARTIAL (existing control / legacy data):
    T1566.001 Spearphishing            ~ (email gateway; not ATT&CK-tested)
    T1021.002 SMB lateral movement     ~ (legacy EDR; coarse)
    T1059.001 Suspicious PowerShell    ~ (tuning in progress; FP risk)
  BLOCKED ON DATA (rule written, cannot fire):
    T1003.001 LSASS credential dumping ✗  <-- needs process-access telemetry
  TRIPWIRE ONLY (last-resort):
    T1486     Ransomware encryption    !  (detects too late to prevent)

  ASK: fund the endpoint-telemetry project (Sysmon/EDR upgrade across the
       clinical fleet) to turn the single most valuable detection from
       BLOCKED to FIRING. Cost/timeline attached. Without it, an adversary
       can harvest every credential in the environment and we are blind.

This report does three things the percentage could not. It tells leadership what is genuinely protected today (so they don't have false confidence). It names the one investment — the telemetry project — that moves the needle most, with a cost attached, converting an abstract "we should improve detection" into a fundable decision. And it states the consequence of inaction in business terms a hospital board understands: blind to credential theft means blind to the step that precedes the ransomware that diverts ambulances. The advisory stops being a PDF in an inbox and becomes a line item in next quarter's budget.

There is a maturity step beyond what Northvale has done here, and Aisha names it as the program's next goal: hunting. Everything in this case study was anticipatory — she built rules ahead of an adversary, driven by an advisory. But, exactly as §22.1 warns, those rules can only catch what the advisory described. The adversary who deviates — who uses a credential-dumping method her rule doesn't cover, or whose campaign isn't in any advisory yet — sails through. Once the telemetry project lands and the data exists, Northvale's next step is to do what Meridian did in Case Study 1: form hypotheses and hunt through that newly-collected data for the adversary activity the rules miss. Detection engineering from intelligence is the right first capability for a small SOC; hunting is the capability that probes the ceiling the rules can't reach. The two cases are not alternatives — they are sequential stages of the same maturing program, and the coverage map is the bridge between them: it tells the engineer what to build and the hunter where to look.

🛡️ Defender's Lens: A small SOC cannot do everything, and pretending otherwise is how teams burn out and boards get blindsided. The discipline on display here is honest prioritization under scarcity: build the durable, high-value detections first; tune them so they don't drown four analysts; report coverage truthfully so the worst gaps get funded rather than hidden; and sequence hunting after you have the data and the automated floor to support it. None of this requires a huge team or budget — it requires reading intelligence well, writing behavioral rules, testing them, and telling the truth about what you can and cannot see. That is detection engineering, and it is within reach of a four-person SOC that thinks clearly.

Discussion Questions

1. Northvale started with detection engineering from intelligence rather than hunting. Given a four-person SOC and a high-quality, ATT&CK-mapped advisory, argue why this is the right first move — and what capability the team must add before it can do the kind of hunt in Case Study 1.
2. Aisha deliberately ranked credential dumping and disabling-defenses above detecting the ransomware encryption itself (T1486). Using the kill chain and the pyramid of pain, explain this prioritization. When, if ever, is a "detect the encryption" tripwire still worth having?
3. The PowerShell detection (T1059.001) was flagged "tune hard" because legitimate PowerShell is everywhere in a hospital. Describe how you would write a detection for suspicious PowerShell that minimizes false positives. Which way are you tuning the false-negative/false-positive tradeoff, and why is that acceptable here?
4. The case argues a missing data source is a more expensive blind spot than a missing rule. Explain why, and describe how mapping coverage against ATT&CK surfaces data gaps that simply "writing more rules" never would.
5. Compare this case to Case Study 1. One built detections proactively from intelligence; the other hunted reactively for a suspected adversary. How do the two feed each other in a mature program — specifically, how would a hunt finding change Aisha's detection backlog, and how would Aisha's coverage map shape what a hunter chooses to hunt?

Your Turn

Take a real, public, ATT&CK-mapped threat advisory (CISA's advisories are ideal and free) for a sector you care about. (1) Triage it for relevance to a fictional organization in that sector. (2) Separate its content into indicators and techniques. (3) Prioritize the techniques into a detection backlog using the pyramid of pain and false-positive risk — justify the order. (4) Write one Sigma rule (logic, ATT&CK tags, a filter block, false positives, level) for your top technique. (5) For that rule, state the data source it requires and assess honestly whether a typical organization in that sector collects it — if not, you have found the expensive kind of blind spot. (6) Sketch the resulting coverage map excerpt, marking each technique green / partial / red and labeling whether each red cell is a rule gap or a data gap. Keep it to three pages.

Key Takeaways

• Detection engineering from intelligence is the right first move for a small SOC. A high-quality, ATT&CK-mapped advisory is a backlog of detections, not a warning to file. Convert techniques into durable, automated rules before the adversary arrives.
• Engineer for techniques, not indicators. The advisory's hashes/IPs/domains are bottom-of-the-pyramid and short-lived; the techniques a ransomware actor must perform (dump credentials, disable defenses, move laterally, encrypt) are durable and behaviorally detectable.
• Prioritize the backlog by the pyramid of pain (favor techniques the adversary can't cheaply change), kill-chain leverage (catch them before impact), and false-positive risk (some techniques, like PowerShell, demand heavy tuning).
• Every deployable rule needs a tuned filter. Characterizing the benign reality (backup agents, management tools, Defender) and suppressing it is the core skill — the false-positive side of the §22.6 tradeoff, handled per rule.
• A missing data source is the most expensive blind spot. A correct rule that cannot fire because the SIEM doesn't collect the telemetry is not coverage. Coverage mapping doubles as data-source gap analysis, and the honest report distinguishes "no rule" from "no data."
• Report coverage honestly. Do not let written-but-dead rules inflate a percentage. A blind spot you believe is covered is more dangerous than one you know is open, because you stop watching for it.