Agent Foskett Academy • SOC Analyst Academy • Module 10 • Lesson 97 • Complete SOC Investigation Scenarios

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.

Never let the loudest alert define the boundaries of the incident.
Agent Foskett reconstructing a ransomware incident timeline
Start before the alert. Continue after it.

Reconstruct initial access, execution, movement, impact and follow-on activity.

✓ Before
✓ Alert
✓ After
✓ Scope

Case briefing

08:43 Suspicious sign-in 09:18 PowerShell execution 10:06 Credential activity 11:22 Lateral movement 13:47 Security tools modified 14:12 RANSOMWARE ALERT 14:16 Encryption expands 14:24 More devices affected THE ALERT DID NOT MARK THE BEGINNING. OR THE END.

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 evidenceNext question
Device affectedWhat happened on this device beforehand?
Ransomware processWhat launched it?
Account contextWhere else did this identity appear?
File changesDid 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

01-before-the-ransomware-alert.kql
12345678910111213
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 asc

Look 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

INITIAL ACCESS 08:43 ↓ EXECUTION 09:18 ↓ CREDENTIAL ACCESS 10:06 ↓ LATERAL MOVEMENT 11:22 ↓ DEFENCE MODIFICATION 13:47 ↓ RANSOMWARE 14:12 THE ENCRYPTION EVENT WAS THE RESULT OF EARLIER ACTIVITY.

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

02-scope-ransomware-process.kql
1234567891011
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 asc

Indicators 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

03-after-the-ransomware-alert.kql
12345678910111213
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 asc

The 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

QuestionMeaning
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

08:43 INITIAL ACCESS 09:18 EXECUTION 10:06 CREDENTIAL ACTIVITY 11:22 LATERAL MOVEMENT 13:47 DEFENCES MODIFIED 14:12 RANSOMWARE ALERT 14:16 ENCRYPTION 14:24 SECOND DEVICE 14:31 CONTAINMENT 14:38 NEW ACCOUNT ACTIVITY THE STORY CONTINUED AFTER THE ALERT.

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: ACTIVE IDENTITIES KNOWN COMPROMISED DEVICES REMOTE ACCESS PATHS MALICIOUS EXECUTION EXPOSED CREDENTIALS ONGOING MOVEMENT DO NOT ONLY CHASE ENCRYPTED FILES. STOP THE ATTACK CHAIN.

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

FINDING The ransomware alert at 14:12 was not the start of the incident. Evidence shows suspicious access, PowerShell execution, credential activity and lateral movement during the preceding hours. Encryption continued onto additional devices after the initial alert. ASSESSMENT: Multi-stage intrusion with ransomware impact. The true compromise scope extends beyond devices that were encrypted. NEXT: Contain active access. Scope identities and devices. Preserve evidence. Assess data exposure. Plan controlled recovery.

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

A Investigate only the encrypted device B Start the timeline at the alert timestamp C Investigate backwards and forwards from the alert, scope all related activity and contain the attack chain D Restore immediately and investigate later BEST DECISION: C THE LOUDEST ALERT IS NOT ALWAYS THE WHOLE INCIDENT.

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.

Next: Lesson 98 — The Insider-Threat Hypothesis Was Wrong

Continue your SOC Analyst training

Module 9 focuses on turning validated investigation findings into transparent, tested and operationally useful detections.

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.