Attack → Defense, End to End

How to read a card

Why this case — what the case teaches and why it was chosen. Concepts first — the building blocks explained for a programmer, so nothing later is magic. The story — the incident in plain language.

ATT&CK chips — between the story and the attack chain sits a row of chips such as T1558.003 Kerberoasting. MITRE ATT&CK is a free public catalog of the methods real attackers use, grouped by the attacker’s goal at each stage (its “tactics”: initial access, persistence, lateral movement, exfiltration and so on). Each method is a “technique” with an ID (Txxxx, with a suffix such as .003 for a more specific variant), so you can look it up at attack.mitre.org and compare it with what your tools claim to detect. Phone and industrial cases use ATT&CK’s separate Mobile and ICS catalogs, and the AI cases use MITRE ATLAS, the equivalent catalog for attacks on AI systems (IDs beginning AML.); those chips carry a label saying so.

Attack chain — each numbered step shows the ATT&CK phase, what the attacker did, why they did it that way, the tool, and the trace it left in telemetry. Telemetry is everything your systems record about what happens on them (logs, process and network events, cloud audit trails); the trace is the specific record this step leaves there, which is what a detection can key on. Above the list, a rail replays the chain once: the attacker’s dot moves from step to step, and each step’s trace drops into a telemetry lane. Each marker is labeled TRACE (a record a rule can key on), FAINT (a trace exists, but ordinary monitoring will not surface it) or NO SIGNAL (nothing stands out from normal activity), and the tag next to it says where it lands: the log or sensor to look in. An amber diamond, NOTICED, marks the step at which the victim first found out (or, on technique cards, the first step the card’s own detection catches), or sits past the arrow when the news came from outside. Detail stays at published-threat-intelligence depth: enough to understand and detect, never a how-to.

Defense — five blocks with reasoning: Detection (the signal and why it is the right one), Tooling (which product category sees it and why), Investigation (steps and why in that order), Response (contain, eradicate, recover, and why), Hardening (what would have prevented it, and the trade-off).

Detection in practice — the detection engineering for that case, in the format that fits the data source: Sigma for logs (a vendor-neutral YAML rule format that converts into the query language of your SIEM, the central platform that collects logs and runs rules over them), YARA for files (patterns of strings and bytes that recognize a malware file), KQL for Microsoft Sentinel / Defender hunting (the query language of Microsoft’s security tools), Falco for containers (rules over what Linux processes do at runtime), and shell / MVT for inventory and forensics (plain commands that answer “do we run the vulnerable version?”, and the Mobile Verification Toolkit, which checks a phone backup for spyware traces). These are starting points, not drop-in production rules: each one carries the logic of the detection, but field names, thresholds and exclusions depend on your environment. Every one needs baselining and false-positive tuning first. Your baseline is what normal activity looks like on your systems; a false positive is an alert on harmless activity; to tune a rule is to add exclusions and adjust thresholds until false positives are rare enough that each alert still gets a serious look, re-testing each time that the rule still catches the attack. Run a new rule in audit mode first (it records matches without alerting anyone). Atomic indicators (specific IPs, file hashes, domains) are trivial for an attacker to change, so they rotate; prefer the behavioral logic. Several cases are deliberately not a SIEM rule and say so: xz-utils and Heartbleed are dependency inventory, Rapid Reset is defended at the CDN edge, Pegasus is mobile forensics, the insider case is behavioral analytics, the deepfake case is a finance control. Heartbleed is undetectable by construction, so its card shows what to do when no rule can help.

Deep dives — two cards carry a full worked method inside them. Card 10 builds one detection end to end (the blue loop: hypothesis, emulation with Atomic Red Team, tuning v1→v4, measuring, documenting). Card 12 runs the offensive mirror (the red / purple loop: authorized adversary emulation and evasion, every concept paired with its defensive counter).

What actually happened — the real outcome with dates and numbers. Lessons and Check yourself — three takeaways and a few questions with hidden answers. Unfamiliar term? Words with a dotted underline show their definition when you hover, focus or tap them, and every one is in the glossary; the Field Map foundations cover the basics.