In this module
OD1.10 Documented Campaigns — Ransomware Operations
You've seen ransomware investigations and read incident reports. You know the general sequence: access, lateral movement, encryption. This sub maps the exact six-phase operational pattern with detection KQL at each phase, a detection priority stack that tells you which signal to invest in first, and AI-assisted timeline reconstruction for active incidents.
Operational Objective
Ransomware campaigns follow a predictable six-phase sequence not because attackers lack creativity but because the operational economics force similar decisions. The objective is always the same, the timeline is always short, and the constraints produce the same operational logic. Understanding the pattern lets you detect the campaign 24-48 hours before encryption — in the credential access and staging phases where the signal-to-noise ratio is highest.
Learning Objectives
By the end of this sub you will be able to:
- Map a ransomware campaign to the six-phase operational sequence (initial access → discovery → credential access → lateral movement → staging → encryption) with the approximate timing at each phase. The same sequence appears in every documented LockBit, BlackCat/ALPHV, and Royal ransomware incident from 2023-2025. This matters because the sequence is predictable, which means your detection can be pre-positioned at the highest-value phases.
- Prioritize ransomware detection investment using the detection priority stack: credential access (T+2-6hr, highest signal-to-noise) > discovery clustering (T+1hr, earliest signal) > backup destruction (T+24-48hr, last containment window). This matters because most organizations detect ransomware during Phase 6 (encryption) when it's too late — shifting detection to Phase 3 (credential access) gives you 42-70 hours of response time.
- Use AI to reconstruct a ransomware timeline from investigation telemetry during an active incident, producing a structured timeline suitable for the IR report within minutes. This matters because the first hours of ransomware response are the most time-pressured investigation scenario — every minute saved on timeline reconstruction is a minute gained for containment.
Figure OD1.10 — The six-phase ransomware sequence with approximate timing. The detection priority stack targets Phase 3 (credential access) as the highest-value detection point.
The pattern is consistent because the economics are consistent
The objective is always the same, the timeline is always short, and the constraints produce the same operational logic across every RaaS platform and affiliate.
The specific tools vary. The discovery commands vary. The lateral movement protocol varies. The sequence doesn't — because the sequence is dictated by operational logic, not personal preference. Encrypt as much as possible, destroy recovery options, exfiltrate for double-extortion leverage, and do it before the SOC responds.
Phase 1 — Initial access (T+0)
The affiliate activates access purchased from a broker. A single subtle indicator — a dormant account authenticating, a web shell receiving its first POST after weeks of silence.
Detection KQL — dormant account activation:
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| join kind=leftanti (
SigninLogs
| where TimeGenerated between (ago(60d) .. ago(7d))
| where ResultType == "0"
| distinct UserPrincipalName
) on UserPrincipalName
| project TimeGenerated, UserPrincipalName, IPAddress,
DeviceDetail, AppDisplayName, LocationAccounts that authenticated successfully in the last 24 hours with no successful authentication in the preceding 53 days — potential broker access activating.
Phase 2 — Discovery (T+1 hour)
Within the first hour, the affiliate maps the environment. The discovery commands are predictable because the information needed is consistent: domain structure, admin accounts, backup system locations, network topology, and security tools installed.
A typical discovery sequence on a compromised endpoint looks like this in Sysmon Event 1 (Process Create):
09:14:02 whoami /all → confirms user context and group membership
09:14:18 net group "Domain Admins" /domain → identifies domain admin accounts
09:14:35 nltest /dclist:northgateeng → locates domain controllers
09:15:01 net share → lists network shares (backup targets)
09:15:22 systeminfo → OS version, domain membership, patch level
09:15:48 wmic /namespace:\\root\SecurityCenter2 path AntiVirusProduct get displayName
→ identifies EDR/AV installedSix commands in 106 seconds. Any individual command is legitimate — IT admins run net group "Domain Admins" routinely. Six enumeration commands on the same endpoint within two minutes is not routine. The temporal density of reconnaissance commands is the most reliable early detection signal because it fires within the first hour, giving maximum response time before the attacker reaches credential access.
Some affiliates use automated tools instead of individual commands — SharpHound for AD mapping (produces distinctive LDAP query patterns), ADRecon for comprehensive enumeration, or custom PowerShell scripts that wrap multiple queries. The telemetry differs but the timing signature is the same: a burst of enumeration activity on a single endpoint within minutes.
Detection KQL — discovery command clustering:
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName in ("whoami.exe", "net.exe", "nltest.exe",
"systeminfo.exe", "ipconfig.exe", "nslookup.exe")
or (FileName == "powershell.exe" and ProcessCommandLine
has_any ("Get-ADComputer", "Get-ADUser", "Get-ADGroup"))
| summarize CommandCount = count(),
Commands = make_set(FileName),
TimeSpan = datetime_diff('minute', max(TimeGenerated),
min(TimeGenerated))
by DeviceName, AccountName, bin(TimeGenerated, 10m)
| where CommandCount >= 3Phase 3 — Credential access (T+2-6 hours)
The most detection-rich phase of the entire operation. The affiliate needs domain administrator credentials to deploy ransomware domain-wide. Every common harvesting technique produces well-documented, high-confidence telemetry. If you could only invest in one ransomware detection rule, target this phase.
LSASS memory dumping is the most common technique. The affiliate uses Mimikatz, comsvcs.dll MiniDump, NanoDump, or a custom dumper to read credentials from the LSASS process memory. If a domain admin has recently logged into the compromised host, the credential harvest succeeds immediately. Here's what the Sysmon Event 10 (Process Access) looks like:
<EventData>
<Data Name="SourceProcessId">7284</Data>
<Data Name="SourceImage">C:\Users\Public\update.exe</Data>
<Data Name="TargetImage">C:\Windows\System32\lsass.exe</Data>
<Data Name="GrantedAccess">0x1010</Data>
</EventData>GrantedAccess: 0x1010 is PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ — the minimum rights needed to read LSASS memory. A binary in C:\Users\Public\ opening LSASS with these rights is almost certainly credential dumping. The signal-to-noise ratio on this detection is the highest of any ransomware indicator.
Kerberoasting extracts service account password hashes. Service accounts with SPN registrations return Kerberos TGS tickets encrypted with the account's password hash — crackable offline. Windows Security Event 4769 with encryption type 0x17 (RC4) is the detection signal. Modern environments use AES by default, so any RC4 ticket request is anomalous.
DCSync is the nuclear option. If the affiliate has Domain Admin or replication rights, they request password hashes for any account directly from the domain controller using the replication protocol. Event 4662 with GUID {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (directory changes replication) from a source that isn't a domain controller is the detection signal.
Detection KQL — LSASS access:
SysmonEvents
| where EventID == 10
| where TargetImage endswith "lsass.exe"
| where GrantedAccess in ("0x1010", "0x1FFFFF", "0x1410", "0x143a")
| where SourceImage !endswith "\\csrss.exe"
and SourceImage !endswith "\\lsm.exe"
and SourceImage !endswith "\\wmiprvse.exe"
| project TimeGenerated, Computer, SourceImage,
GrantedAccess, SourceUserLSASS access with these specific access rights is almost always malicious. Highest signal-to-noise ratio of any ransomware detection.
Phase 4 — Lateral movement (T+6-24 hours)
With domain admin credentials, the affiliate moves to three categories of target: domain controllers (for domain-wide deployment capability), backup systems (to disable recovery), and high-value file servers (to exfiltrate data for double-extortion leverage).
The movement velocity is the signal. One admin account authenticating to fifteen systems in two hours is anomalous even for the most active IT admin during a maintenance window. Here's what a typical ransomware lateral movement sequence looks like in Windows Security Event 4624 (Logon):
18:30:14 admin.lab → SRV-NGE-DC01 LogonType 3 (Network) — domain controller
18:32:47 admin.lab → SRV-NGE-DC02 LogonType 3 (Network) — second DC
18:35:22 admin.lab → SRV-NGE-BKP01 LogonType 3 (Network) — backup server
18:37:55 admin.lab → SRV-NGE-BKP02 LogonType 3 (Network) — backup server 2
18:40:18 admin.lab → SRV-NGE-FS01 LogonType 3 (Network) — file server
18:42:41 admin.lab → SRV-NGE-FS02 LogonType 3 (Network) — file server 2
18:45:03 admin.lab → SRV-NGE-SQL01 LogonType 3 (Network) — database server
18:47:29 admin.lab → SRV-NGE-APP01 LogonType 3 (Network) — application serverEight systems in 17 minutes. Every authentication is individually legitimate — the admin.lab account has domain admin rights and is authorised to access every system. No individual logon triggers an alert. The pattern — eight systems in seventeen minutes, targeting DCs and backup infrastructure first — is the campaign signal.
The combination of credential access indicators (Phase 3) followed by rapid multi-system authentication is a campaign-level signal that should trigger investigation even if neither phase triggered a high-severity alert independently.
Detection KQL — lateral movement velocity:
SecurityEvent
| where TimeGenerated > ago(4h)
| where EventID in (4624, 4625)
| where LogonType in (3, 10)
| summarize DistinctTargets = dcount(Computer),
TargetList = make_set(Computer), AuthCount = count()
by TargetUserName, bin(TimeGenerated, 2h)
| where DistinctTargets > 5
| order by DistinctTargets descPhase 5 — Staging (T+24-48 hours)
This is the last realistic containment window. The affiliate prepares for encryption by eliminating recovery options and maximising double-extortion leverage.
Backup destruction follows a predictable sequence. The affiliate disables backup services, deletes shadow copies, and may specifically target cloud backup configurations. Here's the typical command sequence you'll see in DeviceProcessEvents:
20:30:14 vssadmin delete shadows /all /quiet → destroys Volume Shadow Copies
20:30:22 wmic shadowcopy delete → redundant deletion (different method)
20:30:45 sc stop veeam → stops Veeam backup agent
20:30:52 sc stop wbengine → stops Windows Backup Engine
20:31:08 net stop SQLBrowser → stops SQL services (database backups)
20:31:25 bcdedit /set {default} recoveryenabled No → disables Windows Recovery EnvironmentEvery command in this sequence is highly anomalous. Shadow copy deletion and backup service stops are not normal administrative operations in any environment. If your detection fires on any of these, encryption is imminent — this is a "drop everything and contain" signal.
Data exfiltration for double-extortion happens in parallel. The affiliate identifies high-value data — financial records, customer databases, HR records, intellectual property — and exfiltrates via cloud storage uploads (MEGA, Google Drive, or a personal OneDrive account created by the attacker), direct HTTPS to attacker infrastructure, or data staged to a compromised DMZ host for bulk transfer. The exfiltrated data provides leverage: "pay the ransom or we publish your data."
Ransomware pre-positioning — the binary is copied to target systems via ADMIN$ shares, Group Policy Object scripts, or direct file copies. The binary sits dormant until the deployment trigger fires.
Detection KQL — backup destruction:
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where (FileName == "vssadmin.exe"
and ProcessCommandLine has "delete shadows")
or (FileName == "wmic.exe"
and ProcessCommandLine has "shadowcopy delete")
or (FileName == "sc.exe"
and ProcessCommandLine has_any ("stop veeam",
"stop wbengine", "stop sql"))
| project TimeGenerated, DeviceName, FileName,
ProcessCommandLine, AccountNameIf this fires, encryption is imminent. Contain immediately.
Phase 6 — Encryption (T+48-72 hours)
Detection here means you missed 48-72 hours of detectable pre-encryption activity. The response is containment (network isolation) and recovery (clean backup restoration, if backups survived staging).
The detection priority stack
- Credential access (T+2-6hr) — highest signal-to-noise, 42-70 hours before encryption
- Discovery clustering (T+1hr) — earliest signal, most response time
- Backup destruction (T+24-48hr) — last containment window, very high signal-to-noise
- Lateral movement velocity (T+6-24hr) — moderate signal-to-noise, scope assessment
- Data exfiltration volume (T+24-48hr) — catches double-extortion staging
STEP 1 — Check your credential access detection
Do you have a rule for LSASS access (Sysmon Event 10)?
Do you have a rule for Kerberoasting (Event 4769, RC4)?
Do you have a rule for DCSync (Event 4662, replication GUIDs)?
If any answer is "no" — that's your highest-priority gap.
STEP 2 — Check your discovery clustering detection
Do you have a rule that detects 3+ enumeration commands
on the same endpoint within 10 minutes?
If not — copy the discovery clustering KQL from this sub
into your SIEM and test it.
STEP 3 — Check your backup destruction detection
Do you have a rule for vssadmin delete shadows?
Do you have a rule for backup service stops?
If not — copy the backup destruction KQL from this sub.
This should be CRITICAL severity with no auto-close.
STEP 4 — Check your lateral movement velocity detection
Do you have a rule for one account authenticating to 5+
systems within 2 hours?
If not — copy the lateral movement KQL from this sub.
STEP 5 — Score your coverage
Phases covered: ___ / 5 (Phase 6 doesn't count — detection
there means you've already lost)
Highest-priority gap: ___
Action: ___Hands-on Exercise — Ransomware Detection Coverage Assessment
Objective: Assess your detection coverage against each phase of the ransomware sequence and identify the highest-priority gap.
Prerequisites: Access to your SIEM analytics rules. No lab VMs required.
Success criteria: You've assessed coverage for each phase and identified your highest-priority detection gap with a specific remediation action.
Challenge: Run the dormant account activation KQL (Phase 1) against your environment right now. If it returns results, investigate them — each one could be a broker's access waiting for activation.
You should be able to do the following without referring back to this sub. If you can't, the sections to re-read are noted.
You're reading the free modules of offensive-security-for-defenders
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.