This is a composite scenario — not a real breach report — built to show how the rules in this catalogue chain together across a full attack lifecycle, not just as isolated alerts. Every detection referenced below is a real rule in this catalogue, not a hypothetical.
Stage 1 — Initial Access: SSH brute force on an exposed jump box
The environment has a Linux bastion host with SSH exposed to the internet for remote administration — a common setup for small ops teams without a VPN. An attacker finds it via routine internet-wide scanning and starts a password-spraying run against common usernames (admin, ubuntu, deploy).
Within a few minutes, ten failed sshd authentication attempts land from the same source IP — well past normal noise from mistyped passwords or stale automation credentials.
Detected by: LIN-2001 — SSH Brute Force — a threshold rule watching for a burst of failed sshd auth events from one source IP inside a 5-minute window.
If sshd's LogLevel isn't set to VERBOSE, this detection has no source IP to group on at all — the rule's audit-policy notes exist for exactly this reason.
Stage 2 — Privilege Escalation: a stale sudo exception
The eleventh attempt succeeds — a shared deploy account with a weak, reused password. The account has limited privileges, but a NOPASSWD sudo exception left over from an old deployment script (deploy ALL=(ALL) NOPASSWD: /usr/bin/vim) lets the attacker escalate to root through vim's shell-escape (:!sh), a well-known "living off the land" sudo bypass.
Detected by: LIN-2002 — Suspicious Sudo Command Execution — flags sudo invocations of binaries commonly abused for privilege escalation (editors, pagers, interpreters) rather than trying to enumerate every possible misconfiguration.
Stage 3 — Lateral Movement: pass-the-hash into the domain
The bastion host, as bastions often do, has a cached credential from a prior administrative RDP session — an NTLM hash left behind by a Windows sysadmin who logged in from it months ago and never rotated it. The attacker extracts it and uses it directly against a domain controller without ever knowing the plaintext password — classic pass-the-hash.
The resulting logon is a network logon (LogonType 3) authenticated via NTLM rather than Kerberos, in a domain that's Kerberos-default — a strong low-noise tell.
Detected by: WIN-1005 — Suspicious NTLM Network Logon (Possible Pass-the-Hash)
Stage 4 — Persistence: a new privileged account
With domain access, the attacker doesn't want to depend on one stolen hash. They create a new local account on the domain controller and add it to the local Administrators group — durable access that survives the original credential being rotated.
Detected by: WIN-1003 — New User Added to a Privileged Local Group
Stage 5 — Impact & Exfiltration: AWS root account usage
The domain controller's admin happens to also hold the organization's AWS root credentials in a password manager entry synced to their profile — a common real-world credential-sprawl problem, not a hypothetical one. The attacker finds it, logs into the AWS root account directly (bypassing IAM entirely, and any IAM-level guardrails with it), disables the CloudTrail trail, and exfiltrates data from an S3 bucket before anyone notices the logging gap.
Detected by: AWS-3002 — AWS Root Account Usage — root usage should be a rare, tracked, ticketed event; any unplanned root API call or console login is inherently suspicious per the CIS AWS Foundations Benchmark.
What this chain actually shows
No single stage here is exotic — brute force, a stale sudo rule, a cached hash, a new admin account, an unrotated root credential. Each one individually is the kind of thing that's easy to dismiss as "just one alert." The value of mapping a full chain like this is seeing that five unremarkable-looking detections, correlated across three platforms, tell a complete story — and that the actual root causes (verbose SSH logging off by default, a leftover sudo exception, an unrotated cached hash, root credentials sitting in a password manager) are all things a defense-in-depth review would catch before stage one, not just detect after the fact.