Offensive Security for Defenders Cheatsheet
Think like the attacker, defend better. The attacker operational lifecycle seen from the blue side, each phase paired with what it leaves for you to detect. Not how to attack, how attackers operate, so you stop seeing isolated alerts and start seeing the operation. No account needed.
The best defenders understand how attackers operate, because individual alerts only become an intrusion when you can see the operation behind them. This reference walks the attacker lifecycle from the defender's side: each phase, what the attacker is trying to achieve, and the detection it leaves behind. It is offensive knowledge for defensive use, the detections run in Sentinel and Defender XDR; there is no operational offense here, only the defensive read of it.
Why defenders need offensive thinking
Picture three alerts in the queue on a normal morning: a discovery command, a service creation, an outbound connection. Triaged individually, each looks low and gets closed, and the metrics look fine, three alerts handled, queue clear. Triaged as a sequence, they are the first thirty minutes of an intrusion. The triage was technically correct and the outcome was wrong, because the analyst was matching alerts to rules instead of matching activity to an attacker's plan, and rules fire on events while attackers operate in sequences. This is the gap offensive thinking closes. When you know the phases an operation moves through, the second alert stops being an unrelated low-severity event and becomes the predicted next step of the first, so you pull the thread instead of closing the ticket. The same knowledge changes what you build: you stop writing rules that fire on single events and start writing detections that recognize the sequence, which is both higher-fidelity and far harder for the attacker to evade.
The offensive lifecycle
Attackers do not work the way the kill-chain diagrams suggest, in tidy linear steps; they work in phases with intent, looping and adapting. But the phases are real, and knowing them gives a defender a predictive model: when you see one phase, you know what the attacker is likely to do next and where to look for it. The lifecycle below is the mental model, not a checklist.
| Phase | What the attacker is doing (and what it leaves) |
|---|---|
| Target selection & recon | Researching you from public sources. Largely invisible, but it shapes everything next. |
| Infrastructure | Standing up C2 and redirectors. Leaves network patterns once it talks to you. |
| Payload & delivery | Building access tailored to your stack. The delivery method is a clue to what they know. |
| Initial access | The foothold. The first on-host or in-tenant telemetry. |
| Post-compromise actions | Discovery, credentials, lateral movement, persistence. The richest detection window. |
| Objectives | Collection, exfiltration, impact. The endgame, and the most costly to miss. |
Infrastructure and delivery as intelligence
When you observe a piece of attacker infrastructure or a delivery chain, it is not just an indicator to block and forget, it is intelligence about the adversary that most defenders throw away. A payload chain tailored to evade your specific EDR tells you they did reconnaissance on your stack, which means this is a prepared, targeted operation rather than a commodity one, and you should expect patience and follow-up. A redirector standing in front of the C2 tells you they are protecting infrastructure they intend to reuse, so the indicator you just blocked will reappear behind different front-end addresses, and the durable detection is the behavior, not the IP. Reading the offense this way turns a single block into a working understanding of who you are dealing with and what they will try next, which is the difference between swatting indicators and actually contesting an adversary.
| What you observe | What it tells you (the defensive read) |
|---|---|
| Stack-specific evasion | They researched your defenses; expect a prepared, targeted operation, not opportunistic. |
| Redirector in front of C2 | Infrastructure they protect and reuse; block the redirector, hunt for the pattern again. |
| Living-off-the-land delivery | They want to blend with legitimate tooling; your behavioral detection matters more than signatures. |
| Noisy, generic payload | Opportunistic or commodity; lower sophistication, but still in. |
The first 30 minutes
The minutes immediately after an attacker gains access are the highest-value detection window in the entire intrusion. The attacker follows a predictable priority order, orient (discovery), then harvest credentials, then establish persistence and C2, because each enables the next. That predictability is the defender's advantage: a burst of discovery commands from one process is the opening move, and detecting the sequence (not each command alone) catches the operation while it is still small.
// Sentinel KQL: Post-Compromise Discovery Sequence Detection
// Detects 4+ distinct discovery commands from the same parent
// process within 5 minutes. This is the discovery phase fingerprint.
let discoveryCommands = dynamic(["whoami.exe", "net.exe", "net1.exe",
"ipconfig.exe", "nltest.exe", "systeminfo.exe", "tasklist.exe",
"arp.exe", "nslookup.exe", "hostname.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName in~ (discoveryCommands)
| summarize
CommandCount = dcount(FileName),
Commands = make_set(FileName),
FirstCmd = min(TimeGenerated),
LastCmd = max(TimeGenerated)
by DeviceName, InitiatingProcessFileName,
InitiatingProcessId, AccountName
| where CommandCount >= 4
| extend DurationSeconds = datetime_diff('second', LastCmd, FirstCmd)
| where DurationSeconds < 300 // 5 minu
The detection above keys on the sequence: several distinct discovery commands from the same parent process in a short window. No single command is alarming, the pattern is, which is exactly the campaign-view the opening scenario was missing.
Credential operations
Once oriented, the attacker goes for credentials, because credentials are how a single foothold becomes domain-wide access. Understanding what they harvest and how they use it (dumping LSASS, forging tickets, reusing tokens) tells you the detections that matter most: the access to credential stores, and the anomalous use of credentials that follows.
// Defender XDR: Golden Ticket Detection (TGS without TGT)
// A Golden Ticket produces Event 4769 (TGS request) without
// a preceding Event 4768 (TGT request) for the same account.
let tgt = IdentityLogonEvents
| where Timestamp > ago(24h)
| where ActionType == "LogonSuccess"
| where Protocol == "Kerberos"
| project TgtTime = Timestamp, TgtAccount = AccountName;
let tgs = IdentityQueryEvents
| where Timestamp > ago(24h)
| where ActionType == "KerberosServiceTicketRequest"
| project TgsTime = Timestamp, TgsAccount = AccountName;
tgs
| join kind=leftanti tgt on $left.TgsAccount == $right.TgtAccount
| project TgsTime, TgsAccount, Alert = "TGS without TGT — possible Golden Ticket"
| order by T
This correlates the phases: discovery commands followed by LSASS access from the same process tree, the post-compromise sequence (orient then harvest) rendered as a single high-confidence detection.
Lateral movement and evasion
Lateral movement is how the intrusion spreads from the first host to the objective, and attackers favor the protocols that blend in (DCOM, WinRM, RDP, SMB) precisely because they are legitimate admin tools. The defensive read is to know which remote-execution protocols your environment actually uses, so the attacker's use of one you do not stands out against the baseline.
// Defender XDR: DCOM Lateral Movement
// Detects mmc.exe or explorer.exe spawning cmd/powershell
// from a network logon context (DCOM execution).
DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName in~ ("mmc.exe", "explorer.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "rundll32.exe")
| where InitiatingProcessLogonId != 0
| join kind=leftouter (
DeviceLogonEvents
| where LogonType == "Network"
| project LogonId, RemoteIP
) on $left.InitiatingProcessLogonId == $right.LogonId
| where isnotempty(RemoteIP)
| project Timestamp, DeviceName, InitiatingProcessFileName,
FileName, ProcessCommandLine, RemoteIP,
Alert = "DCOM lateral movem
DCOM lateral movement is a good example of the principle: rarely used legitimately, so its appearance, a process spawned via the DCOM path on a remote host, is high-signal when you are watching for it.
Campaign reconstruction
Campaign reconstruction is the skill the opening scenario was missing: taking the scattered alerts and assembling them into the single operation they actually were. It runs backward, from the alert you caught to the full chain, and forward, from what you know to what the attacker probably did that you did not catch. The offensive lifecycle is the frame that makes this possible, each phase implies the ones before and after, so finding one lets you hunt for the rest.
| Reconstruction move | What it recovers |
|---|---|
| Anchor on the known alert | The one detection that fired; establish its phase in the lifecycle. |
| Work backward | What must have happened before this phase? Hunt for the initial access and discovery. |
| Work forward | What does this phase enable next? Hunt for the credential use, lateral movement, objective. |
| Build the timeline | Order the recovered events; the gaps are your detection blind spots. |
Threat-informed defense
The payoff of offensive thinking is prioritization: you cannot detect everything, so you invest where it matters most against the adversaries you actually face. Threat-informed defense uses the attacker lifecycle to decide which detections earn their place, the high-value, hard-to-evade chokepoints, over a long tail of low-value rules that fire on noise.
| Principle | In practice |
|---|---|
| Detect at chokepoints | Phases the attacker cannot skip (credential access, lateral movement) are the durable detections. |
| Detect sequences, not events | The pattern across phases is harder to evade than any single indicator. |
| Prioritize by adversary | Cover the techniques your likely threats actually use, from real campaign reporting. |
| Close the blind spots first | The reconstruction gaps are where the next attacker walks unseen; fix those before adding rules. |
The morning queue: a whoami/net group burst on a workstation (closed as "admin activity"), a 7045 service creation on a server an hour later (closed as "software install"), an outbound connection to a new host (closed as "unknown, low risk"). Each was triaged correctly in isolation. Through the lifecycle lens they are one chain: discovery, then lateral movement via a created service, then C2, phases 1, 4, and 5 of a single operation.
The defensive fix: a detection that correlates discovery-then-service-creation-then-new-C2 across hosts and time would have fired once, as one incident, instead of three closed alerts. That correlation is only obvious once you think in attacker phases, which is the entire point.
Quick lookup
| Attacker phase | What to detect |
|---|---|
| Discovery (orient) | Multiple distinct discovery commands from one parent in a short window |
| Credential access | LSASS access, ticket anomalies (Golden Ticket), correlated after discovery |
| Lateral movement | DCOM/WinRM/RDP from sources that do not normally use them; 7045 service creation |
| C2 establishment | New outbound to a rare destination, correlated with prior on-host activity |
| Defense evasion | The blinding act itself: AMSI/ETW tampering, log clearing |
| The campaign | Sequences across phases, not single events; the gaps are blind spots |
From recognizing the operation to defending against it
This cheatsheet is the lifecycle and the defensive read. Offensive Security for Defenders teaches the whole thing: how attackers plan and operate, the detection for every phase, campaign reconstruction, and building a threat-informed defense around how real adversaries actually work.
Explore the course