Final Submission for Ghaymah SecOps Assessment
هذا الالتزام موجود في:
659
task5-ransomware/ransomware_response_plan.md
Normal file
659
task5-ransomware/ransomware_response_plan.md
Normal file
@@ -0,0 +1,659 @@
|
||||
# Ransomware Incident Response Plan
|
||||
## Ghaymah Block Storage Encryption Event
|
||||
|
||||
> **Document ID:** GH-RANSOM-IRP-2026-001
|
||||
> **Classification:** CONFIDENTIAL — EMERGENCY RESPONSE
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
This playbook outlines the exact procedures for containing, eradicating, and recovering from a Ransomware encryption event affecting Ghaymah Block Storage volumes. The strategy heavily emphasizes **Immutable Backups** and mandates wiping the Kubernetes infrastructure prior to data restoration to prevent reinfection.
|
||||
|
||||
## Incident Overview
|
||||
**Scenario:** An attacker compromises a Kubernetes pod, escalates privileges, and executes ransomware, encrypting all attached Block Storage volumes. A ransom note is dropped.
|
||||
**Objective:** Contain the spread within 60 minutes, eradicate the persistence mechanism, and restore operations from immutable snapshots with a Recovery Time Objective (RTO) of 2 hours.
|
||||
|
||||
## Response Matrix
|
||||
|
||||
| Phase | Goal | Key Actions |
|
||||
|-------|------|-------------|
|
||||
| **Containment** | Stop encryption spread | Isolate network, detach storage, freeze IAM. |
|
||||
| **Eradication** | Remove attacker | Wipe infected namespaces, rotate keys. |
|
||||
| **Recovery** | Restore services | Rebuild from clean images, restore immutable snapshots. |
|
||||
|
||||
---
|
||||
|
||||
## Containment
|
||||
*(First 60 Minutes)*
|
||||
|
||||
### T+0 to T+5 Minutes — IMMEDIATE ACTIONS (Automated + Manual)
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════════════════╗
|
||||
║ ⚠️ RANSOMWARE DETECTED — EXECUTE IMMEDIATELY — DO NOT DELAY ║
|
||||
╠══════════════════════════════════════════════════════════════════════════╣
|
||||
║ 1. DO NOT SHUT DOWN affected systems (preserves memory forensics) ║
|
||||
║ 2. DO NOT PAY the ransom ║
|
||||
║ 3. DO NOT attempt to decrypt files with unknown tools ║
|
||||
║ 4. DO NOT communicate with the attacker ║
|
||||
╚══════════════════════════════════════════════════════════════════════════╝
|
||||
```
|
||||
|
||||
| Time | Action | Owner | Method |
|
||||
|------|--------|-------|--------|
|
||||
| T+0 | **ALERT**: Declare ransomware incident via PagerDuty P1 | SOC L1 | n8n automated trigger from Wazuh FIM alert |
|
||||
| T+1 | **ISOLATE NETWORK**: Apply emergency deny-all NetworkPolicies to ALL namespaces | SOC L2 | kubectl + n8n playbook (see below) |
|
||||
| T+2 | **DISCONNECT STORAGE**: Detach Block Storage volumes from compromised pods | Platform Team | Ghaymah API: `ghaymah bs detach` |
|
||||
| T+3 | **PRESERVE EVIDENCE**: Create forensic snapshots of all affected volumes | SOC L2 | Ghaymah API: `ghaymah bs snapshot create` |
|
||||
| T+4 | **FREEZE IAM**: Rotate ALL API keys and tokens; disable external access | IAM Team | n8n playbook → Ghaymah IAM API |
|
||||
| T+5 | **NOTIFY**: Alert CISO, Legal, and Executive leadership | Incident Commander | Automated Slack/Email via n8n |
|
||||
|
||||
### n8n SOAR Playbook — Ransomware Auto-Containment
|
||||
|
||||
```
|
||||
Trigger: Wazuh FIM alert (file integrity monitoring) detecting mass
|
||||
file modifications + known ransomware extensions (.encrypted,
|
||||
.locked, .cry, .crypt)
|
||||
|
||||
Workflow:
|
||||
1. [Wazuh Webhook] → Receive FIM alert
|
||||
2. [Validate] → Check if >100 files modified in <5 min (ransomware pattern)
|
||||
3. [CRITICAL PATH - Parallel Execution]:
|
||||
├── [Network Isolation]
|
||||
│ └── kubectl apply emergency-deny-all to all namespaces
|
||||
├── [Storage Protection]
|
||||
│ ├── Lock all Block Storage snapshots (set immutable flag)
|
||||
│ └── Create emergency snapshots of unaffected volumes
|
||||
├── [IAM Lockdown]
|
||||
│ ├── Revoke all active API tokens
|
||||
│ ├── Force-rotate all service account keys
|
||||
│ └── Disable all external API access
|
||||
└── [Alerting]
|
||||
├── PagerDuty P1 to SOC + Platform + CISO
|
||||
├── Slack #incident-response channel
|
||||
└── Email to legal@ghaymah.systems
|
||||
4. [Evidence Collection]
|
||||
├── Capture pod memory dumps (if possible)
|
||||
├── Export K8s audit logs for last 24h
|
||||
└── Preserve network flow logs
|
||||
5. [Create War Room] → Auto-create Slack channel #ransomware-ir-{date}
|
||||
```
|
||||
|
||||
### T+5 to T+15 Minutes — SCOPING & ASSESSMENT
|
||||
|
||||
| Time | Action | Details |
|
||||
|------|--------|---------|
|
||||
| T+5 | **Identify Patient Zero** | Review Wazuh FIM alerts chronologically. Identify first pod/volume with file modifications. Check K8s audit logs for initial compromise vector. |
|
||||
| T+7 | **Determine Blast Radius** | List all affected Block Storage volumes: `ghaymah bs list --status=attached`. Check which namespaces/pods have encrypted files. |
|
||||
| T+10 | **Identify Ransomware Variant** | Analyze ransom note format, file extension, and encryption method. Upload sample to VirusTotal/MalwareBazaar (use isolated network). Check ID Ransomware (id-ransomware.malwarehunterteam.com). |
|
||||
| T+12 | **Assess Data Impact** | Determine what data was encrypted: PII, financial, source code, configs. Check if data was also exfiltrated (double extortion check). |
|
||||
| T+15 | **Initial Situation Report** | Brief Incident Commander with: variant, blast radius, data impact, backup status. |
|
||||
|
||||
### T+15 to T+30 Minutes — CONTAINMENT DEEPENING
|
||||
|
||||
```bash
|
||||
# 1. Network micro-segmentation — isolate every namespace
|
||||
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: ransomware-emergency-isolate
|
||||
namespace: ${ns}
|
||||
spec:
|
||||
podSelector: {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
EOF
|
||||
done
|
||||
|
||||
# 2. Kill all non-essential workloads
|
||||
kubectl get deployments -A -o json | jq -r '
|
||||
.items[] |
|
||||
select(.metadata.namespace != "kube-system") |
|
||||
select(.metadata.namespace != "security-tools") |
|
||||
"\(.metadata.namespace)/\(.metadata.name)"
|
||||
' | while read deploy; do
|
||||
ns=$(echo $deploy | cut -d/ -f1)
|
||||
name=$(echo $deploy | cut -d/ -f2)
|
||||
kubectl scale deployment $name -n $ns --replicas=0
|
||||
done
|
||||
|
||||
# 3. Protect unaffected backups — set immutable flags
|
||||
ghaymah bs snapshot list --format=json | jq -r '.[].id' | while read snap_id; do
|
||||
ghaymah bs snapshot update $snap_id --immutable=true --retention-days=90
|
||||
done
|
||||
|
||||
# 4. Capture forensic artifacts
|
||||
kubectl logs -l app=affected-service --all-containers --since=24h > /forensics/pod_logs_$(date +%s).log
|
||||
kubectl get events -A --sort-by='.lastTimestamp' > /forensics/k8s_events_$(date +%s).log
|
||||
```
|
||||
|
||||
## Eradication
|
||||
After containment, the environment must be aggressively scrubbed to remove persistence.
|
||||
|
||||
| Time | Action | Details |
|
||||
|------|--------|---------|
|
||||
| T+30 | **Identify Entry Vector** | Analyze K8s audit logs to determine initial compromise. |
|
||||
| T+35 | **Malware Analysis** | Determine if decryption is possible without paying ransom. |
|
||||
| T+45 | **Wipe Infrastructure** | Delete the compromised namespace entirely. Do not attempt to "clean" infected pods. |
|
||||
|
||||
---
|
||||
|
||||
## Recovery
|
||||
*(Disaster Recovery Strategy)*
|
||||
|
||||
### Recovery Checklist
|
||||
- [ ] 1. Verify integrity of pre-incident snapshots (check for IOCs).
|
||||
- [ ] 2. Reprovision K8s namespace from clean IaC templates.
|
||||
- [ ] 3. Deploy fresh, signed container images.
|
||||
- [ ] 4. Create new Block Storage volumes from verified immutable snapshots.
|
||||
- [ ] 5. Attach new volumes to fresh pods in isolated network state.
|
||||
- [ ] 6. Validate application logic and data consistency.
|
||||
- [ ] 7. Re-expose service to public internet.
|
||||
|
||||
### Recovery Execution Order
|
||||
|
||||
When a ransomware event occurs, recovery MUST follow this exact sequence to prevent reinfection:
|
||||
|
||||
1. **Verify Integrity of Snapshots:** Do not blindly restore. Scan the target snapshot for IOCs to ensure the backup itself isn't compromised (the attacker may have been dwelling for days).
|
||||
2. **Rebuild Infrastructure (Clean Room):** Delete the compromised namespace entirely. Do not attempt to "clean" infected pods. Reprovision the namespace and deploy fresh, signed container images from the trusted registry.
|
||||
3. **Restore Data to New Volume:** Create a *new* Ghaymah Block Storage volume from the verified snapshot. Do not overwrite the encrypted volume (preserve it for forensics).
|
||||
4. **Attach and Validate:** Attach the new volume to the fresh pods in a network-isolated state. Validate application startup and data consistency.
|
||||
5. **Re-expose Service:** Update NetworkPolicies and Ingress routes to allow traffic back to the restored service.
|
||||
|
||||
**Why this specific order?**
|
||||
If you restore the data *before* wiping the infrastructure, the malicious processes still running in memory will immediately re-encrypt the restored data. If you expose the service *before* validating, you risk exposing broken applications or unresolved backdoors to customers.
|
||||
|
||||
### RPO/RTO Definitions for Ghaymah
|
||||
### Technical RPO & RTO Justification (Ghaymah Architecture)
|
||||
|
||||
| Metric | Definition | Target | Technical Justification |
|
||||
|--------|-----------|--------|-------------------------|
|
||||
| **RPO (Recovery Point Objective)** | Maximum acceptable data loss | **4 hours** | Ghaymah Block Storage volumes are snapshotted every 4 hours via automated CronJobs. This limits absolute data loss to a 4-hour window, which is acceptable for the staging and telemetry datasets without impacting operational continuity. |
|
||||
| **RTO (Recovery Time Objective)** | Maximum acceptable downtime | **2 hours** | Recovery involves 3 stages: Namespace isolation (10m), Block Storage recovery from snapshot (30m), and QA validation before traffic routing (80m). The automated pipeline ensures the 2-hour SLA is consistently met during drills. |
|
||||
|
||||
---
|
||||
|
||||
### 3-2-1 Backup Rule Implementation on Ghaymah
|
||||
|
||||
```text
|
||||
+-----------------------------------+
|
||||
| [Copy 1: Production] |
|
||||
| Ghaymah Block Storage (Live Data) |
|
||||
| * AES-256 Encrypted SSD |
|
||||
+-----------------------------------+
|
||||
|
|
||||
v (Automated Snapshot Every 4h)
|
||||
+-----------------------------------+
|
||||
| [Copy 2: Snapshots] |
|
||||
| Ghaymah Region A (Same Region) |
|
||||
| * 30-Day Retention |
|
||||
| * IMMUTABLE Flag (WORM) |
|
||||
+-----------------------------------+
|
||||
|
|
||||
v (Daily Cross-Region Replication)
|
||||
+-----------------------------------+
|
||||
| [Copy 3: Offline Vault] |
|
||||
| Ghaymah Region B (Disaster Rec.) |
|
||||
| * 90-Day Retention |
|
||||
| * Air-Gapped IAM Policies |
|
||||
+-----------------------------------+
|
||||
```
|
||||
|
||||
### Backup Automation (Kubernetes CronJob)
|
||||
|
||||
```yaml
|
||||
# backup-cronjob.yaml — Automated 3-2-1 backup on Ghaymah
|
||||
apiVersion: batch/v1
|
||||
kind: CronJob
|
||||
metadata:
|
||||
name: ghaymah-backup-321
|
||||
namespace: backup-system
|
||||
spec:
|
||||
schedule: "0 */4 * * *" # Every 4 hours
|
||||
concurrencyPolicy: Forbid
|
||||
successfulJobsHistoryLimit: 5
|
||||
failedJobsHistoryLimit: 3
|
||||
jobTemplate:
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
serviceAccountName: backup-operator
|
||||
containers:
|
||||
- name: backup
|
||||
image: registry.ghaymah.systems/backup-operator:v1.2.0
|
||||
env:
|
||||
- name: GHAYMAH_API_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: backup-credentials
|
||||
key: api-key
|
||||
- name: REGION_B_API_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: backup-credentials
|
||||
key: region-b-api-key
|
||||
command:
|
||||
- /bin/bash
|
||||
- -c
|
||||
- |
|
||||
set -euo pipefail
|
||||
|
||||
echo "[BACKUP] Starting 3-2-1 backup cycle..."
|
||||
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
|
||||
|
||||
# COPY 2: Create immutable snapshots
|
||||
for vol_id in $(ghaymah bs list --format=json | jq -r '.[].id'); do
|
||||
echo "[BACKUP] Snapshotting volume: ${vol_id}"
|
||||
SNAP_ID=$(ghaymah bs snapshot create \
|
||||
--volume-id "${vol_id}" \
|
||||
--name "auto-backup-${TIMESTAMP}" \
|
||||
--immutable true \
|
||||
--retention-days 30 \
|
||||
--format=json | jq -r '.id')
|
||||
echo "[BACKUP] Created snapshot: ${SNAP_ID}"
|
||||
done
|
||||
|
||||
# COPY 3: Cross-region replication (daily — check if midnight run)
|
||||
HOUR=$(date +%H)
|
||||
if [ "${HOUR}" == "00" ]; then
|
||||
echo "[BACKUP] Running daily cross-region replication..."
|
||||
for snap_id in $(ghaymah bs snapshot list \
|
||||
--created-after "$(date -d '-4 hours' +%Y-%m-%dT%H:%M:%S)" \
|
||||
--format=json | jq -r '.[].id'); do
|
||||
ghaymah bs snapshot replicate \
|
||||
--snapshot-id "${snap_id}" \
|
||||
--target-region region-b \
|
||||
--immutable true \
|
||||
--retention-days 90 \
|
||||
--api-key "${REGION_B_API_KEY}"
|
||||
echo "[BACKUP] Replicated to Region B: ${snap_id}"
|
||||
done
|
||||
fi
|
||||
|
||||
# Cleanup old snapshots beyond retention
|
||||
ghaymah bs snapshot prune --older-than 30d --dry-run=false
|
||||
|
||||
echo "[BACKUP] 3-2-1 backup cycle complete."
|
||||
restartPolicy: OnFailure
|
||||
```
|
||||
|
||||
### Recovery Procedure
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# recover_from_ransomware.sh — Restore from 3-2-1 backups
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
echo "╔══════════════════════════════════════════════════════╗"
|
||||
echo "║ GHAYMAH RANSOMWARE RECOVERY — BACKUP RESTORATION ║"
|
||||
echo "╚══════════════════════════════════════════════════════╝"
|
||||
|
||||
# Step 1: Identify last clean snapshot (pre-ransomware)
|
||||
echo "[RECOVERY] Finding last clean snapshot..."
|
||||
RANSOMWARE_TIME="2026-07-27T03:00:00Z" # Set to time of first encryption
|
||||
|
||||
CLEAN_SNAPSHOTS=$(ghaymah bs snapshot list \
|
||||
--created-before "${RANSOMWARE_TIME}" \
|
||||
--immutable true \
|
||||
--sort-by created_at \
|
||||
--order desc \
|
||||
--limit 5 \
|
||||
--format=json)
|
||||
|
||||
echo "[RECOVERY] Available clean snapshots:"
|
||||
echo "${CLEAN_SNAPSHOTS}" | jq -r '.[] | " ID: \(.id) Created: \(.created_at) Volume: \(.volume_id)"'
|
||||
|
||||
# Step 2: Create new volumes from clean snapshots
|
||||
echo "[RECOVERY] Restoring volumes from snapshots..."
|
||||
echo "${CLEAN_SNAPSHOTS}" | jq -r '.[0].id' | while read snap_id; do
|
||||
NEW_VOL=$(ghaymah bs create \
|
||||
--from-snapshot "${snap_id}" \
|
||||
--name "recovered-$(date +%Y%m%d)" \
|
||||
--encrypted true \
|
||||
--format=json | jq -r '.id')
|
||||
echo "[RECOVERY] Created recovery volume: ${NEW_VOL} from snapshot: ${snap_id}"
|
||||
done
|
||||
|
||||
# Step 3: Deploy clean application pods with recovered volumes
|
||||
echo "[RECOVERY] Deploying clean application stack..."
|
||||
kubectl apply -f /recovery/clean-deployment-manifests/
|
||||
|
||||
# Step 4: Verify data integrity
|
||||
echo "[RECOVERY] Verifying data integrity..."
|
||||
kubectl exec -it recovery-validator -- /scripts/verify_data_checksums.sh
|
||||
|
||||
echo "[RECOVERY] ✅ Restoration complete. Verify application functionality."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Preventative Architecture Against Lateral Movement
|
||||
|
||||
### 3.1 Defense-in-Depth Architecture
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────────────┐
|
||||
│ ANTI-RANSOMWARE DEFENSE LAYERS │
|
||||
│ │
|
||||
│ Layer 1: PERIMETER │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • WAF with ransomware payload detection │ │
|
||||
│ │ • Email gateway with attachment sandboxing │ │
|
||||
│ │ • DNS filtering (block known malicious domains) │ │
|
||||
│ │ • DDoS protection (prevent distraction attacks) │ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ Layer 2: NETWORK (Zero Trust) │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • Default-deny NetworkPolicies on ALL namespaces │ │
|
||||
│ │ • mTLS between all services (Istio service mesh) │ │
|
||||
│ │ • Egress filtering — block all except approved destinations │ │
|
||||
│ │ • Network segmentation — isolate sensitive data zones │ │
|
||||
│ │ • IDS/IPS (Wazuh + Suricata) on east-west traffic │ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ Layer 3: IDENTITY (Zero Trust) │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • MFA mandatory on ALL accounts (no exceptions) │ │
|
||||
│ │ • Short-lived tokens (15 min access, 24h refresh) │ │
|
||||
│ │ • Disable automatic SA token mounting in K8s │ │
|
||||
│ │ • Just-in-Time (JIT) privileged access for admin tasks │ │
|
||||
│ │ • Impossible travel detection (Wazuh rule 100207) │ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ Layer 4: ENDPOINT / CONTAINER │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • Read-only root filesystem on ALL containers │ │
|
||||
│ │ • Drop ALL Linux capabilities │ │
|
||||
│ │ • Seccomp profiles (restrict syscalls) │ │
|
||||
│ │ • Falco runtime detection (detect file encryption patterns) │ │
|
||||
│ │ • Wazuh FIM on Block Storage mount points │ │
|
||||
│ │ • No privileged containers (Pod Security Standards: restricted)│ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ Layer 5: DATA │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • 3-2-1 backup rule (implemented above) │ │
|
||||
│ │ • IMMUTABLE snapshots (cannot be deleted by ransomware) │ │
|
||||
│ │ • Separate IAM for backup operations (blast radius limit) │ │
|
||||
│ │ • Quarterly backup restore drills │ │
|
||||
│ │ • Block Storage volume-level encryption (CMEK) │ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ Layer 6: DETECTION & RESPONSE │
|
||||
│ ┌────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ • Wazuh FIM: detect mass file modifications in <5 min │ │
|
||||
│ │ • n8n SOAR: automated containment within 60 seconds │ │
|
||||
│ │ • Canary files: honeypot files that trigger alerts on access │ │
|
||||
│ │ • Elastic ML: detect anomalous storage I/O patterns │ │
|
||||
│ │ • 24/7 SOC monitoring with <15 min response SLA │ │
|
||||
│ └────────────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.2 Lateral Movement Prevention — Specific Controls
|
||||
|
||||
#### 3.2.1 Kubernetes-Level Controls
|
||||
|
||||
```yaml
|
||||
# anti-lateral-movement.yaml
|
||||
|
||||
# 1. Deny inter-namespace communication by default
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: deny-cross-namespace
|
||||
namespace: production
|
||||
spec:
|
||||
podSelector: {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
ingress:
|
||||
- from:
|
||||
- podSelector: {} # Only allow same-namespace traffic
|
||||
egress:
|
||||
- to:
|
||||
- podSelector: {} # Only allow same-namespace traffic
|
||||
- to: [] # Allow DNS
|
||||
ports:
|
||||
- protocol: UDP
|
||||
port: 53
|
||||
---
|
||||
# 2. Restrict volume access — pods can only mount their own PVCs
|
||||
apiVersion: constraints.gatekeeper.sh/v1beta1
|
||||
kind: K8sRestrictedVolumes
|
||||
metadata:
|
||||
name: restrict-volume-types
|
||||
spec:
|
||||
match:
|
||||
kinds:
|
||||
- apiGroups: [""]
|
||||
kinds: ["Pod"]
|
||||
parameters:
|
||||
allowedVolumeTypes:
|
||||
- configMap
|
||||
- emptyDir
|
||||
- projected
|
||||
- secret
|
||||
- downwardAPI
|
||||
- persistentVolumeClaim # Only named PVCs, no hostPath
|
||||
---
|
||||
# 3. Block hostPath mounts (prevent node-level lateral movement)
|
||||
apiVersion: constraints.gatekeeper.sh/v1beta1
|
||||
kind: K8sBlockHostPath
|
||||
metadata:
|
||||
name: block-host-path
|
||||
spec:
|
||||
match:
|
||||
kinds:
|
||||
- apiGroups: [""]
|
||||
kinds: ["Pod"]
|
||||
```
|
||||
|
||||
#### 3.2.2 Canary File Detection (Early Warning System)
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Canary File Monitor — Early ransomware detection via honeypot files.
|
||||
Deploy as a DaemonSet sidecar on Ghaymah Block Storage-mounted pods.
|
||||
"""
|
||||
|
||||
import os
|
||||
import hashlib
|
||||
import time
|
||||
import json
|
||||
import requests
|
||||
from pathlib import Path
|
||||
|
||||
CANARY_DIR = "/data/.canary"
|
||||
CANARY_FILES = [
|
||||
"IMPORTANT_DO_NOT_DELETE.docx",
|
||||
"financial_report_2026.xlsx",
|
||||
"customer_database_backup.sql",
|
||||
"credentials_backup.txt",
|
||||
"company_secrets.pdf"
|
||||
]
|
||||
CHECK_INTERVAL = 30 # seconds
|
||||
WAZUH_WEBHOOK = "http://wazuh-manager:55000/api/webhook/canary"
|
||||
N8N_WEBHOOK = "http://n8n.security-tools:5678/webhook/ransomware-canary"
|
||||
|
||||
def create_canary_files():
|
||||
"""Create honeypot files with known checksums."""
|
||||
os.makedirs(CANARY_DIR, exist_ok=True)
|
||||
checksums = {}
|
||||
for filename in CANARY_FILES:
|
||||
filepath = Path(CANARY_DIR) / filename
|
||||
content = f"CANARY-{filename}-{os.urandom(32).hex()}"
|
||||
filepath.write_text(content)
|
||||
checksums[str(filepath)] = hashlib.sha256(content.encode()).hexdigest()
|
||||
|
||||
# Save checksums
|
||||
checksum_file = Path(CANARY_DIR) / ".checksums.json"
|
||||
checksum_file.write_text(json.dumps(checksums))
|
||||
return checksums
|
||||
|
||||
def check_canary_files(expected_checksums):
|
||||
"""Check if any canary file has been modified, renamed, or deleted."""
|
||||
for filepath, expected_hash in expected_checksums.items():
|
||||
path = Path(filepath)
|
||||
|
||||
if not path.exists():
|
||||
# File deleted or encrypted (renamed)
|
||||
alert_ransomware(f"Canary file DELETED/ENCRYPTED: {filepath}")
|
||||
return True
|
||||
|
||||
current_content = path.read_text()
|
||||
current_hash = hashlib.sha256(current_content.encode()).hexdigest()
|
||||
|
||||
if current_hash != expected_hash:
|
||||
# File content modified (encrypted in place)
|
||||
alert_ransomware(f"Canary file MODIFIED: {filepath}")
|
||||
return True
|
||||
|
||||
return False
|
||||
|
||||
def alert_ransomware(message):
|
||||
"""Send emergency alert to Wazuh and n8n."""
|
||||
alert_payload = {
|
||||
"alert_type": "ransomware_canary",
|
||||
"severity": "CRITICAL",
|
||||
"message": message,
|
||||
"hostname": os.uname().nodename,
|
||||
"timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
|
||||
"action_required": "IMMEDIATE CONTAINMENT"
|
||||
}
|
||||
|
||||
try:
|
||||
requests.post(N8N_WEBHOOK, json=alert_payload, timeout=5)
|
||||
except Exception as e:
|
||||
print(f"[ALERT FAILED] {e}")
|
||||
|
||||
print(f"🚨 RANSOMWARE DETECTED: {message}")
|
||||
|
||||
def main():
|
||||
print("[CANARY] Initializing canary file monitoring...")
|
||||
checksums = create_canary_files()
|
||||
print(f"[CANARY] Created {len(checksums)} canary files in {CANARY_DIR}")
|
||||
|
||||
while True:
|
||||
if check_canary_files(checksums):
|
||||
print("[CANARY] ⚠️ RANSOMWARE ACTIVITY DETECTED — Alert sent")
|
||||
# Don't exit — keep monitoring for forensic timeline
|
||||
time.sleep(CHECK_INTERVAL)
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
|
||||
#### 3.2.3 Wazuh FIM Configuration for Ransomware Detection
|
||||
|
||||
```xml
|
||||
<!-- /var/ossec/etc/ossec.conf — File Integrity Monitoring for ransomware -->
|
||||
<ossec_config>
|
||||
<syscheck>
|
||||
<!-- Monitor Block Storage mount points -->
|
||||
<directories check_all="yes" realtime="yes"
|
||||
report_changes="yes">/data</directories>
|
||||
<directories check_all="yes" realtime="yes">/mnt/block-storage</directories>
|
||||
|
||||
<!-- Alert on known ransomware file extensions -->
|
||||
<alert_new_files>yes</alert_new_files>
|
||||
|
||||
<!-- Frequency: check every 60 seconds for rapid detection -->
|
||||
<frequency>60</frequency>
|
||||
|
||||
<!-- Ignore legitimate temp files -->
|
||||
<ignore>/data/.tmp</ignore>
|
||||
<ignore>/data/cache</ignore>
|
||||
</syscheck>
|
||||
</ossec_config>
|
||||
```
|
||||
|
||||
```xml
|
||||
<!-- Custom Wazuh rule for ransomware detection -->
|
||||
<group name="ghaymah,ransomware,fim,">
|
||||
|
||||
<!-- Mass file modification (ransomware encryption pattern) -->
|
||||
<rule id="100300" level="15" frequency="50" timeframe="300">
|
||||
<if_group>syscheck</if_group>
|
||||
<field name="syscheck.event">modified</field>
|
||||
<description>⚠️ RANSOMWARE ALERT: 50+ files modified in 5 minutes on Block Storage. Possible encryption in progress!</description>
|
||||
<mitre>
|
||||
<id>T1486</id> <!-- Data Encrypted for Impact -->
|
||||
</mitre>
|
||||
<group>ransomware,data_encrypted,gdpr_IV_33,</group>
|
||||
<options>alert_by_email</options>
|
||||
</rule>
|
||||
|
||||
<!-- Known ransomware file extensions -->
|
||||
<rule id="100301" level="14">
|
||||
<if_group>syscheck</if_group>
|
||||
<field name="syscheck.path">\.encrypted$|\.locked$|\.cry$|\.crypt$|\.ransom$|\.wasted$</field>
|
||||
<description>⚠️ RANSOMWARE: File with ransomware extension detected: $(syscheck.path)</description>
|
||||
<mitre>
|
||||
<id>T1486</id>
|
||||
</mitre>
|
||||
<group>ransomware,ransomware_extension,</group>
|
||||
<options>alert_by_email</options>
|
||||
</rule>
|
||||
|
||||
<!-- Ransom note detection -->
|
||||
<rule id="100302" level="15">
|
||||
<if_group>syscheck</if_group>
|
||||
<field name="syscheck.path">README.*RANSOM|HOW.*DECRYPT|RECOVER.*FILES|!README!</field>
|
||||
<description>⚠️ RANSOMWARE: Ransom note detected: $(syscheck.path)</description>
|
||||
<mitre>
|
||||
<id>T1486</id>
|
||||
</mitre>
|
||||
<group>ransomware,ransom_note,</group>
|
||||
<options>alert_by_email</options>
|
||||
</rule>
|
||||
|
||||
<!-- Canary file modification -->
|
||||
<rule id="100303" level="15">
|
||||
<if_group>syscheck</if_group>
|
||||
<field name="syscheck.path">.canary/</field>
|
||||
<description>⚠️ RANSOMWARE: Canary file modified/deleted! Early detection triggered.</description>
|
||||
<mitre>
|
||||
<id>T1486</id>
|
||||
</mitre>
|
||||
<group>ransomware,canary_triggered,</group>
|
||||
<options>alert_by_email</options>
|
||||
</rule>
|
||||
|
||||
</group>
|
||||
```
|
||||
|
||||
### 3.3 Preventative Architecture Summary
|
||||
|
||||
| Control | Purpose | Prevents |
|
||||
|---------|---------|----------|
|
||||
| Default-deny NetworkPolicies | No lateral network movement | Ransomware spreading pod-to-pod |
|
||||
| Read-only root filesystems | Pods cannot write to container FS | Ransomware binary dropping |
|
||||
| Immutable backups | Backups cannot be encrypted/deleted | Double extortion (backup destruction) |
|
||||
| Separate IAM for backups | Compromised app creds can't touch backups | Backup compromise during attack |
|
||||
| Canary files | Detect encryption within 30 seconds | Late detection |
|
||||
| Wazuh FIM (real-time) | Detect mass file changes instantly | Encryption completing before alert |
|
||||
| n8n automated containment | Respond in <60 seconds | Human delay in containment |
|
||||
| mTLS service mesh | Encrypted, authenticated inter-service traffic | MitM for ransomware C2 |
|
||||
| Egress filtering | Block unauthorized outbound connections | Ransomware C2 callback & data exfil |
|
||||
| JIT privileged access | Admin access only when needed, time-limited | Privilege escalation for ransomware deployment |
|
||||
|
||||
---
|
||||
|
||||
## Appendix: Tabletop Exercise Schedule
|
||||
|
||||
| Quarter | Exercise | Focus Area |
|
||||
|---------|----------|------------|
|
||||
| Q1 | Backup Restore Drill | Validate RPO/RTO by restoring from Region B backups |
|
||||
| Q2 | Ransomware Simulation | Deploy fake ransomware in staging; test detection & containment |
|
||||
| Q3 | Lateral Movement Test | Red team attempts to move across namespaces post-compromise |
|
||||
| Q4 | Full IR Simulation | End-to-end ransomware scenario: detection → containment → recovery |
|
||||
|
||||
|
||||
المرجع في مشكلة جديدة
حظر مستخدم