4.2 KiB
Emergency Plan — First 60 Minutes of Ransomware Incident
Scenario: All Block Storage files on Ghaymah cloud are encrypted with a ransom message.
⏱ Minute 0–5: Detect & Confirm
Trigger Indicators:
- Files renamed to
*.encryptedor*.locked - Ransom note file:
READ_ME_TO_DECRYPT.txt - Sudden spike in Block Storage write IOPS
- Applications returning file-not-found errors
Immediate Actions:
- Alert the security team and management — declare a P1 incident.
- Do NOT pay the ransom at this stage.
- Do NOT reboot or shut down the instance (preserves memory evidence).
- Take a forensic snapshot of the current Block Storage volume to preserve evidence. Do not restore from this snapshot — it may contain encrypted files. Restore from the last clean backup taken before the encryption event.
# Forensic snapshot — evidence preservation only
ghaymah-cli storage snapshot create --volume-id vol-xxxx --name ransomware-forensic-$(date +%Y%m%d)
⏱ Minute 5–15: Isolate
Goal: Stop the ransomware from spreading to other systems.
| Action | Method |
|---|---|
| Isolate the infected instance | Remove from load balancer pool immediately |
| Block all outbound traffic | Apply deny-all egress firewall rule to the instance |
| Revoke instance API credentials | Rotate IAM keys/tokens used by the instance |
| Disconnect Block Storage | Detach volume to prevent further encryption |
| Alert other teams | Notify DB admins, network team, management |
# Detach Block Storage volume
ghaymah-cli storage volume detach --instance-id inst-xxxx --volume-id vol-xxxx
# Apply deny-all network rule (Ghaymah firewall)
ghaymah-cli network firewall add-rule \
--instance inst-xxxx \
--direction egress \
--action deny \
--priority 1
⏱ Minute 15–30: Assess the Damage
Goal: Understand the scope of encryption and identify the attack vector.
-
Check which files are encrypted:
# On a forensic copy only find /mnt/forensic-copy -name "*.encrypted" -o -name "*.locked" | wc -l -
Identify ransomware family (from ransom note + file extensions).
-
Check intrusion timeline — review access logs from the past 48 hours:
grep -i "POST\|PUT" /var/log/nginx/access.log | tail -500 journalctl --since "48 hours ago" | grep -E "error|fail|unauthorized" -
Identify the attack vector:
- Phishing email with malicious attachment?
- Exposed RDP/SSH with weak credentials?
- Vulnerable web application?
- Compromised supply chain dependency?
-
Check for legitimate decryption tools: Search security databases (NoMoreRansom.org) — some ransomware strains have free decryptors.
⏱ Minute 30–45: Begin Recovery
Goal: Restore services from the last clean backup.
-
Identify the last clean backup snapshot (before encryption):
ghaymah-cli storage snapshot list --volume-id vol-xxxx # Look for the last snapshot BEFORE the ransomware event timestamp -
Create a new volume from the clean snapshot:
ghaymah-cli storage volume create-from-snapshot \ --snapshot-id snap-clean-xxxx \ --name restored-volume-$(date +%Y%m%d) -
Attach the restored volume to a clean, rebuilt instance.
-
Verify data integrity before bringing services back online:
# Check file counts match expected find /mnt/restored -type f | wc -l # Run application health checks curl -f http://localhost:8080/health
⏱ Minute 45–60: Restore Service & Communicate
- Re-add restored instance to the load balancer.
- Monitor for any re-infection indicators (file modification spikes).
- Send internal status update: scope, services affected, ETA for full recovery.
- Prepare customer/stakeholder disclosure notification (if PII was exposed).
- Preserve the forensic snapshot for later analysis and potential law enforcement reporting.
Incident Commander Checklist
- P1 alert sent to all stakeholders
- Infected instance isolated (firewall + load balancer)
- Block Storage detached
- Forensic snapshot taken
- Clean backup identified
- Restoration in progress
- Communication sent to affected parties
- Legal/compliance team notified