131 أسطر
4.2 KiB
Markdown
131 أسطر
4.2 KiB
Markdown
# 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 `*.encrypted` or `*.locked`
|
||
- Ransom note file: `READ_ME_TO_DECRYPT.txt`
|
||
- Sudden spike in Block Storage write IOPS
|
||
- Applications returning file-not-found errors
|
||
|
||
**Immediate Actions:**
|
||
1. Alert the security team and management — declare a P1 incident.
|
||
2. Do NOT pay the ransom at this stage.
|
||
3. Do NOT reboot or shut down the instance (preserves memory evidence).
|
||
4. 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.
|
||
|
||
```bash
|
||
# 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 |
|
||
|
||
```bash
|
||
# 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.
|
||
|
||
1. **Check which files are encrypted:**
|
||
```bash
|
||
# On a forensic copy only
|
||
find /mnt/forensic-copy -name "*.encrypted" -o -name "*.locked" | wc -l
|
||
```
|
||
|
||
2. **Identify ransomware family** (from ransom note + file extensions).
|
||
|
||
3. **Check intrusion timeline** — review access logs from the past 48 hours:
|
||
```bash
|
||
grep -i "POST\|PUT" /var/log/nginx/access.log | tail -500
|
||
journalctl --since "48 hours ago" | grep -E "error|fail|unauthorized"
|
||
```
|
||
|
||
4. **Identify the attack vector:**
|
||
- Phishing email with malicious attachment?
|
||
- Exposed RDP/SSH with weak credentials?
|
||
- Vulnerable web application?
|
||
- Compromised supply chain dependency?
|
||
|
||
5. **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.
|
||
|
||
1. Identify the last clean backup snapshot (before encryption):
|
||
```bash
|
||
ghaymah-cli storage snapshot list --volume-id vol-xxxx
|
||
# Look for the last snapshot BEFORE the ransomware event timestamp
|
||
```
|
||
|
||
2. Create a new volume from the clean snapshot:
|
||
```bash
|
||
ghaymah-cli storage volume create-from-snapshot \
|
||
--snapshot-id snap-clean-xxxx \
|
||
--name restored-volume-$(date +%Y%m%d)
|
||
```
|
||
|
||
3. Attach the restored volume to a clean, rebuilt instance.
|
||
|
||
4. Verify data integrity before bringing services back online:
|
||
```bash
|
||
# 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
|
||
|
||
1. Re-add restored instance to the load balancer.
|
||
2. Monitor for any re-infection indicators (file modification spikes).
|
||
3. Send internal status update: scope, services affected, ETA for full recovery.
|
||
4. Prepare customer/stakeholder disclosure notification (if PII was exposed).
|
||
5. 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
|