Lesson 97 — The Ransomware Alert Was Only the Middle of the Story
The ransomware alert fired at 14:12.
But the attacker had arrived hours earlier.
And encryption was not the end.
The alert was only the middle.

Start before the alert. Continue after it.
Reconstruct initial access, execution, movement, impact and follow-on activity.
Case briefing
Investigation objective
Reconstruct the activity surrounding a ransomware alert, identify what happened before encryption, determine what continued afterwards and establish the true scope of the incident.
Investigator's rule
The detection timestamp is a pivot point, not automatically the incident start time.
Stage 1 — anchor on the alert
| Alert evidence | Next question |
|---|---|
| Device affected | What happened on this device beforehand? |
| Ransomware process | What launched it? |
| Account context | Where else did this identity appear? |
| File changes | Did similar activity occur on other devices? |
Use the alert as an anchor
The ransomware detection gives you a known event around which to investigate. It should not become an artificial boundary that hides earlier attacker activity.
Move backwards first
Parent processes, identities, scripts, remote access and credential activity can explain how the ransomware reached the device.
Stage 2 — investigate before encryption
let Device = "WS-214";
let AlertTime = datetime(2026-09-15 14:12:00);
DeviceProcessEvents
| where DeviceName =~ Device
| where Timestamp between
(AlertTime - 6h .. AlertTime)
| project Timestamp,
AccountName,
InitiatingProcessFileName,
FileName,
ProcessCommandLine,
SHA1
| order by Timestamp ascLook for the setup
Ransomware deployment may be preceded by reconnaissance, credential access, remote execution, security-control changes and staging activity.
Do not search only for ransomware
The earlier stages may use completely different tools and behaviours. Follow the identities, processes, devices and relationships.
Stage 3 — reconstruct the chain
Attack stages explain impact
Understanding the earlier chain helps explain why multiple systems were reachable when ransomware finally executed.
The root problem may be elsewhere
The first encrypted device may not be the initial access point or the system from which deployment occurred.
Stage 4 — find related devices
let SuspiciousHash = "1111111111111111111111111111111111111111";
DeviceProcessEvents
| where Timestamp > ago(12h)
| where SHA1 == SuspiciousHash
| summarize
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
Executions=count()
by DeviceName, AccountName, FileName
| order by FirstSeen ascIndicators help with rapid scope
A known hash, filename or destination can quickly identify related systems while the incident is active.
Then search behaviour
Attackers may use different payloads or renamed files. Search the deployment and execution technique as well as exact indicators.
Stage 5 — investigate after the alert
let AlertTime = datetime(2026-09-15 14:12:00);
DeviceProcessEvents
| where Timestamp between
(AlertTime .. AlertTime + 2h)
| where FileName in~ ("powershell.exe",
"cmd.exe",
"wmic.exe")
| project Timestamp,
DeviceName,
AccountName,
FileName,
ProcessCommandLine
| order by Timestamp ascThe attacker may still be active
An alert does not guarantee that execution stopped. Additional devices, accounts or remote sessions may continue the attack.
Containment creates new evidence
Observe whether activity stops, shifts to another system or uses another identity after defensive actions begin.
Stage 6 — distinguish impact from scope
| Question | Meaning |
|---|---|
| Which devices encrypted files? | Observed ransomware impact |
| Which devices had attacker execution? | Potentially broader compromise scope |
| Which accounts were used? | Identity and credential scope |
| Which systems were accessed before encryption? | Potential exposure beyond encrypted hosts |
| Did data leave beforehand? | Possible extortion or data-exposure impact |
Encrypted devices are not the whole scope
A system can be compromised without being encrypted. Scope attacker access and execution separately from visible ransomware impact.
Look for pre-encryption data access
Ransomware incidents may include data theft or other activity before encryption. Investigate the evidence rather than assuming either presence or absence.
Stage 7 — build the complete timeline
One timeline changes decisions
When all stages are combined, responders can see which access paths existed before encryption and which remain active afterwards.
Update scope continuously
Every new device, account or technique can change containment priorities. The incident boundary is evidence-driven.
Stage 8 — containment priorities
Contain causes as well as symptoms
Stopping one ransomware process is not enough if the attacker still controls credentials, sessions or another compromised system.
Recovery comes after confidence
Restoring systems without understanding active access paths can create opportunities for reinfection or renewed attacker activity.
Stage 9 — incident finding
Write the whole incident
The final finding should explain how the attacker arrived, moved, prepared, executed ransomware and continued after the first detection.
Do not make ransomware the entire story
Encryption may be the most visible impact, but the earlier intrusion often explains how it became possible.
Decision point
Follow the evidence in both directions
Backward investigation explains how the incident developed. Forward investigation shows what happened after detection and whether the attacker remained active.
Challenge the first theory
The next scenario tests another essential SOC skill: changing direction when the evidence disproves the original insider-threat hypothesis.
Lesson 97 key takeaways
- The ransomware alert timestamp is a pivot point, not necessarily the incident start.
- Investigate backwards to identify initial access and preparation.
- Reconstruct execution, credential activity and lateral movement before encryption.
- Search exact indicators for rapid scoping, then broaden to behaviour.
- Investigate forward from the alert to identify continued attacker activity.
- Do not equate encrypted devices with total compromise scope.
- Separate ransomware impact from attacker access and execution scope.
- Assess whether sensitive data was accessed before encryption.
- Contain credentials, sessions, devices and movement paths, not only ransomware processes.
- Build one chronological timeline across the entire intrusion.
- Plan recovery only after active access paths are understood and controlled.
- The loudest alert may sit in the middle of the real incident story.
Module 10 — Complete SOC Investigation Scenarios
Lesson 97 reconstructed the full attack around a ransomware alert instead of treating encryption as the entire incident. Lesson 98 challenges the analyst to abandon an insider-threat theory when the evidence points somewhere else.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 10: Complete SOC Investigation Scenarios
How should a SOC investigate a ransomware alert?
Lesson 97 of the Agent Foskett SOC Analyst Academy shows why a ransomware detection may sit in the middle of a longer intrusion and teaches analysts to investigate activity both before and after the alert.
Reconstructing a ransomware incident timeline
Learn how to identify initial access, execution, credential activity, lateral movement, defence modification, ransomware impact, continued attacker activity and the true scope of compromise.
