Ransomware Detection, Containment, and Initial Response

Ransomware IR is the most time-pressured IR scenario. The difference between 100 encrypted files and 100,000 encrypted files is the 30 minutes it takes to identify and stop the spread.

The Ransomware IR Timeline

T+0:00  Alert received — "files have wrong extension on Server-01"
T+0:02  Confirm ransomware: check for encrypted files + ransom note
T+0:05  Identify Patient Zero (source of encryption)
T+0:07  Network isolation of active encryption source
         → firewall block + VLAN change OR unplug network cable
         → Do NOT power off yet (memory evidence)
T+0:15  Memory acquisition from Patient Zero (if possible)
T+0:20  Identify all affected hosts (EDR telemetry / file extension sweep)
T+0:30  Isolate all confirmed affected hosts
T+0:45  Assess backup integrity (can we restore without paying?)
T+1:00  Notify legal counsel (double extortion evidence → potential breach)
T+2:00  Scope complete — brief leadership on containment status and options
T+4:00  Recovery decision: restore vs. negotiate

Confirming Ransomware — First 5 Minutes

# Step 1: Identify encrypted file extension
Get-ChildItem -Path C:\Users\ -Recurse -ErrorAction SilentlyContinue |
  Where-Object {$_.Name -like "*.locked" -or $_.Name -like "*.encrypted" -or
                $_.Extension -notin @('.exe','.dll','.sys','.lnk')} |
  Select-Object -First 20

# Step 2: Find the ransom note
Get-ChildItem -Path C:\ -Recurse -Filter "HOW_TO_DECRYPT*" -ErrorAction SilentlyContinue |
  Select-Object -First 5
Get-ChildItem -Path C:\ -Recurse -Filter "RANSOM_NOTE*" -ErrorAction SilentlyContinue |
  Select-Object -First 5
Get-ChildItem -Path C:\ -Recurse -Filter "README*" -ErrorAction SilentlyContinue |
  Select-Object -First 5

# Step 3: Identify ransomware family (submit to ID Ransomware)
# id-ransomware.malwarehunterteam.com — paste the ransom note or upload encrypted file
# Also: submit encrypted file extension to nomoreransom.org for decryptor availability

# Step 4: Check if encryption is still active
# Look for file system activity:
Get-WmiObject Win32_Process | Where-Object {$_.Name -like "*crypt*" -or $_.Name -like "*enc*"}
# Or watch file system events:
Get-EventLog -LogName Security -EntryType Information -Newest 100 |
  Where-Object {$_.EventID -eq 4663}  # File access events

Stopping Active Encryption

# NETWORK ISOLATION — preferred (preserves memory evidence)
# Option A: Firewall block (PowerShell — runs locally, no network needed)
New-NetFirewallRule -DisplayName "ISOLATE-IR" -Direction Outbound `
  -Action Block -Protocol Any -Profile Any
New-NetFirewallRule -DisplayName "ISOLATE-IR-IN" -Direction Inbound `
  -Action Block -Protocol Any -Profile Any
# Exceptions: leave open only the port needed for forensic evidence collection
# e.g., allow TCP 4444 to forensic server

# Option B: VLAN change (if managed switch accessible)
# Contact network team to move port to quarantine VLAN

# Option C: Physical disconnect (last resort — loses remote access)
# Unplug the network cable

# PROCESS TERMINATION — stop active encryption (emergency only)
# Kill the ransomware process if identified (risks triggering cleanup routine)
$proc = Get-Process | Where-Object {$_.Name -like "*update*"}
Stop-Process -Id $proc.Id -Force -ErrorAction SilentlyContinue

# IDENTIFY Shadow Copy deletion commands in recent history
Get-WinEvent -LogName Security | Where-Object {$_.Message -like "*vssadmin*" -or
  $_.Message -like "*shadowcopy*"} | Select-Object -First 10

T1490 — Shadow Copy Status Check

# Verify if shadow copies still exist (critical for recovery options)
vssadmin list shadows

# If shadow copies exist → protect them immediately
# Block VSS deletion commands via GPO or just document their existence
# Schedule KAPE collection to include VSS via --vss flag

# If shadow copies are deleted (most ransomware does this):
# Check Windows Event Log 8222 for shadow copy deletion event
Get-WinEvent -LogName "Microsoft-Windows-StorageManagement/Operational" |
  Where-Object {$_.Id -eq 8222}

# For LockBit/BlackCat/BlackMatter — they delete VSS before encryption
# Recovery requires external backup or paying ransom

# Backup integrity check
wbadmin get versions
# Lists all Windows Server Backup versions — verify most recent is intact
# Also check: are backup files encrypted? (some ransomware targets backup directories)

Scope Assessment

# Identify all encrypted hosts via EDR (pseudo-code — adjust for your EDR)
# Look for: high volume file rename events, VSS deletion, ransom note creation

# Via Active Directory — find all computers that beaconed the ransomware domain
Get-ADComputer -Filter * -Property LastLogonDate |
  Where-Object {$_.LastLogonDate -gt (Get-Date).AddDays(-1)} |
  Select-Object Name, LastLogonDate

# File extension sweep — find hosts with encrypted extensions
# Velociraptor VQL fleet hunt:
#   SELECT Fqdn, OSPath FROM glob(globs=["C:/Users/**/*.locked"])

# Check event logs across all DCs for ransomware execution timeline
# Event 4688 (process creation) with ransomware binary name
# Event 7045 (service installed) — some ransomware installs as a service

Worked Example

First 30 minutes of a LockBit 3.0 ransomware response

Alert: 2:47 AM — SOC receives alert: 4,000 file rename events in 60 seconds on FILE-SERVER-01.

2:47 — Confirm ransomware

Get-ChildItem \\FILE-SERVER-01\shares\ -Recurse | 
  Where-Object {$_.Extension -eq ".lockbit"} | Select-Object -First 5
# Found: quarterly_report.xlsx.lockbit, employee_data.csv.lockbit
# Ransom note: HLJkNskOq.README.txt — LockBit 3.0 confirmed

2:51 — Isolate FILE-SERVER-01

Network team moves port to quarantine VLAN. Encryption stops immediately.

2:53 — Memory acquisition attempt

# WinPmem on FILE-SERVER-01 (still running, just network-isolated)
.\winpmem_mini_x64_rc2.exe \\forensic-server\case\FILE-SERVER-01_memory.raw
# 64 GB RAM — estimated 64 minutes
# Decision: start memory acquisition, parallel with scope assessment

2:55 — Shadow copy status

vssadmin list shadows
No items found that satisfy the query.

LockBit deleted all VSS before detonation. Recovery requires external backup.

3:00 — Backup integrity verification

wbadmin get versions
Backup Time: 9/1/2024 11:00 PM (yesterday — 3 hours 47 minutes ago)
Volumes: C:, D:
Status: Successful

Backup from 11 PM is intact. Files encrypted between 11 PM and 2:47 AM will be lost.

3:10 — Scope: identify other affected hosts

Velociraptor fleet hunt for .lockbit extension: 3 additional hosts found.

3:15 — Brief leadership

Status: FILE-SERVER-01 isolated (active encryption stopped). 3 additional affected hosts.
Evidence: 64 GB memory acquisition in progress (ETA 3:57 AM).
Backups: FILE-SERVER-01 backup intact (9/1 11 PM). Files after 11 PM are lost.
Options: (1) Restore from backup — lose ~3:47 hours of files.
         (2) Negotiate — leverage TBD pending legal guidance.
         (3) Files lost: estimate ~15,000 files created/modified after 11 PM.
Next 30 min: isolate remaining 3 hosts, begin backup restoration planning.

Retrieval Practice

During a ransomware IR, an analyst proposes immediately rebooting all infected servers to terminate the ransomware processes and stop encryption. What are the risks of this approach and what should be done instead?

Reveal answer

Immediate reboot has three significant risks: (1) Loss of volatile evidence: memory contains the encryption key (some ransomware families, particularly older variants, hold the key in memory for the session duration), C2 beaconing process details, any lateral movement tools still in memory, and authentication tokens. Memory acquisition must occur before reboot. (2) Loss of process information: while the system is running (but network-isolated), the running ransomware process can be identified, dumped, and analyzed. Reboot destroys this. (3) Some ransomware has anti-tamper mechanisms: if the ransomware detects abnormal termination, it may trigger cleanup routines (delete additional files, destroy its own binary, alert the attacker). Correct approach: (1) Network isolation FIRST — this stops the spread and stops encryption of networked shares without powering off. The ransomware can continue encrypting local files in isolation, but the damage is contained to one host. (2) Memory acquisition while isolated — collect memory before any shutdown. (3) Identify the process and determine if memory contains the key. (4) Power off ONLY after memory acquisition is complete or if encryption is actively consuming a critical system that cannot be isolated any other way. (5) Document the decision: if business pressure requires immediate power-off, document in the chain of custody that volatile evidence was not collected and state the business reason.