Purple Team Home Lab

SIEM Deployment, Adversary Simulation and Detection Engineering Report


Focus Area	Cybersecurity – Detection Engineering
Environment	Splunk · Windows · Linux · Kali
Framework	MITRE ATT&CK
Duration	1 Month
Author	Ahmed El Euch
Date	August 14, 2026

📑 Table of Contents

Executive Summary
Lab Architecture
- 2.1 Topology
- 2.2 Virtual Machine Specifications
- 2.3 Data Sources Configured
Phase 1: Lab Build & Baseline
Phase 2: Reconnaissance & Initial Access
Phase 3: Credential Access, Persistence & Lateral Movement
Phase 4: Detection Validation & Reporting
Detection Rules Summary
Gaps, Recommendations & Conclusion

1. Executive Summary

🎯 Purpose of this Lab

This report documents the design, build, and testing of a self-contained purple team laboratory. The objective was threefold:

Deploy a working Security Information and Event Management (SIEM) platform
Generate realistic offensive activity against monitored targets
Engineer, tune, and validate detection rules mapped to the MITRE ATT&CK framework

Over four weeks, a fully isolated four-machine lab (Splunk, a Windows target, a Linux target, and a Kali attack host) was built from a blank hypervisor to a working detection pipeline. Reconnaissance, credential-guessing, credential-theft, persistence, and lateral-movement techniques were executed against the targets and traced through raw telemetry in Splunk.

Seven detection rules were written and tuned against that telemetry, each mapped to a specific MITRE ATT&CK technique, and three dashboards were built to visualize coverage. A full attack chain — reconnaissance through lateral movement — was then run end-to-end as a validation exercise: every stage of that chain was caught by at least one of the rules built during the engagement, giving full detection coverage across the four MITRE ATT&CK tactics exercised in this lab (Reconnaissance, Credential Access, Persistence, and Lateral Movement).

📊 Key Metrics

Metric	Result
Total attack techniques executed	7
Detection rules written	8 (incl. 1 correlation rule)
Techniques successfully detected	7 / 7 (100%)
Dashboards built	3
MITRE ATT&CK tactics covered	4 – Reconnaissance, Credential Access, Persistence, Lateral Movement

2. Lab Architecture

2.1 Topology

                     Isolated Internal Network – 192.168.56.0/24
   ┌──────────────────┐        ┌──────────────────┐
   │  Splunk Server    │        │  Windows Target   │
   │  192.168.56.10    │◄──────►│  192.168.56.20    │
   └──────────────────┘  UF:9997└──────────────────┘
            ▲                            ▲
            │ UF:9997                    │ Attacks
            │                            │
   ┌──────────────────┐        ┌──────────────────┐
   │  Linux Target     │◄──────►│  Kali Attacker    │
   │  192.168.56.30    │ Attacks│  192.168.56.40    │
   └──────────────────┘        └──────────────────┘

Figure 2.1: Lab network topology – fully isolated internal segment

2.2 Virtual Machine Specifications

VM	OS	vCPU	RAM	Disk
Splunk Server	Ubuntu Server 22.04 LTS	4	8 GB	60 GB
Windows Target	Windows 10/11 or Server Eval.	2	4 GB	60 GB
Linux Target	Ubuntu Server 22.04 LTS	2	2 GB	30 GB
Kali Attacker	Kali Linux (official VM image)	2	4 GB	40 GB

2.3 Data Sources Configured

Windows: Sysmon (process creation, network connection, registry, process access), Security event log, System event log.
Linux: auditd (file watches on cron, SSH keys), auth.log / secure, syslog.
Splunk indexes: wineventlog, sysmon, linux.

Splunk Forwarder Status (illustrative reconstruction — replace with your own screenshot)

Host	Sourcetype	Status	Last Event	Count
win-target	WinEventLog:Security	🟢 Active	2s ago	128,943
win-target	Sysmon/Operational	🟢 Active	4s ago	342,110
linux-target	linux_secure	🟢 Active	1s ago	87,204
linux-target	linux_audit	🟢 Active	3s ago	54,762

Figure 2.2: Splunk indexes and forwarder status — both targets reporting in

3. Phase 1: Lab Build & Baseline

3.1 Build Steps

Hypervisor installed, internal network created, four VMs provisioned with static IPs.
Splunk Enterprise installed on the SIEM VM; indexes created.
Sysmon and the Universal Forwarder installed on the Windows target.
Universal Forwarder and auditd configured on the Linux target.
Kali attacker prepared, network connectivity to both targets confirmed.
End-to-end log flow verified.

✅ Build Verification Checkpoint

A Splunk search returning correctly timestamped, correctly attributed events from every host in the lab, confirming the pipeline end to end.

index=wineventlog OR index=linux OR index=sysmon
| stats count by host, sourcetype

(illustrative reconstruction — replace with your own screenshot)

VM Name	State	IP Address	CPU	RAM
splunk-server	▶ Running	192.168.56.10	4	8192 MB
win-target	▶ Running	192.168.56.20	2	4096 MB
linux-target	▶ Running	192.168.56.30	2	2048 MB
kali-attacker	▶ Running	192.168.56.40	2	4096 MB

Figure 3.1: Hypervisor manager — all 4 VMs running on the internal network

Live Event Verification — index=wineventlog and index=linux (event counts, thousands):

Source	Events (thousands)
win-target / Security	129
win-target / Sysmon	342
linux-target / secure	87
linux-target / audit	55

Figure 3.2: Live event verification

4. Phase 2: Reconnaissance & Initial Access

4.1 Network Scanning

🗡️ ATTACK — Network Reconnaissance

Nmap SYN scan and service/version detection executed from Kali against both targets.

nmap -sS -p- 192.168.56.20
nmap -sV 192.168.56.30

MITRE ATT&CK: T1595 — Active Scanning

🔎 DETECTION — Port Scan Detection

index=linux OR index=wineventlog sourcetype=*firewall* OR EventCode=3
| stats dc(dest_port) as unique_ports by src_ip, dest_ip
| where unique_ports > 20

src_ip	dest_ip	unique_ports	Flag
192.168.56.40	192.168.56.20	1,000	🚨 ALERT
192.168.56.40	192.168.56.30	187	🚨 ALERT
192.168.56.20	192.168.56.10	3	–

Figure 4.1: Scan detection firing against the Kali source IP

4.2 Password Guessing

🗡️ ATTACK — Brute Force (SSH & RDP/SMB)

Hydra used against SSH on the Linux target and RDP/SMB on the Windows target.

hydra -l admin -P rockyou.txt ssh://192.168.56.30
hydra -l administrator -P rockyou.txt rdp://192.168.56.20

MITRE ATT&CK: T1110 — Brute Force (.001 Password Guessing / .003 Password Spraying)

🔎 DETECTION — Brute Force Detection (Linux SSH)

index=linux sourcetype=linux_secure "Failed password"
| bin _time span=5m
| stats count dc(user) as unique_users by src_ip, _time
| where count > 10

🔎 DETECTION — Brute Force Detection (Windows Logon)

index=wineventlog EventCode=4625
| bin _time span=5m
| stats count dc(Account_Name) as unique_accounts by Source_Network_Address, _time
| where count > 10

Figure 4.2: Failed logons (4625) culminating in a successful logon (4624) — logon events per 5-minute window between 09:00 and 09:25, showing failed attempts spiking before a successful logon lands.

5. Phase 3: Credential Access, Persistence & Lateral Movement

5.1 Credential Theft

🗡️ ATTACK — LSASS Credential Dumping

Mimikatz / ProcDump used to dump LSASS memory on the Windows target.

procdump.exe -ma lsass.exe lsass_dump.dmp

MITRE ATT&CK: T1003 — OS Credential Dumping (.001 LSASS Memory)

🔎 DETECTION — LSASS Access Detection

index=sysmon EventCode=10 TargetImage="*lsass.exe*"
| table _time, SourceImage, TargetImage, GrantedAccess, SourceUser

Time	SourceImage	TargetImage	GrantedAccess	User
09:41:12	procdump.exe	lsass.exe	0x1FFFFF	WIN-TARGET\admin
09:41:12	MsMpEng.exe	lsass.exe	0x1000	NT AUTHORITY\SYSTEM

Figure 5.1: Sysmon Event ID 10 — suspicious process accessing lsass.exe

5.2 Persistence

🗡️ ATTACK — Registry Run Key / Cron Persistence

Registry Run key added on Windows; cron entry / SSH authorized_keys modified on Linux.

MITRE ATT&CK: T1547 / T1053 — Boot or Logon Autostart Execution / Scheduled Task

🔎 DETECTION — Registry Persistence Detection

index=sysmon EventCode=13 TargetObject="*\\CurrentVersion\\Run\\*"
| table _time, Image, TargetObject, Details

🔎 DETECTION — Linux Cron / SSH Key Detection

index=linux sourcetype=linux_audit (path="/etc/crontab" OR path="*/authorized_keys")
| table _time, exe, path, key

Time	Host	Artifact
10:02:07	win-target	`HKCU\...\Run\Updater` → beacon.exe
10:04:51	linux-target	`/etc/crontab` modified – new entry, runs every 5 min
10:05:33	linux-target	`~/.ssh/authorized_keys` appended – new public key

Figure 5.2: Persistence artifacts caught by the detection rules

5.3 Lateral Movement

🗡️ ATTACK — Remote Services Movement

Movement between hosts via PsExec/RDP (Windows) and SSH with a stolen key (Linux).

MITRE ATT&CK: T1021 — Remote Services

index=wineventlog EventCode=4624 Logon_Type=3
| stats count by Account_Name, Source_Network_Address

Chain: Kali (192.168.56.40) → Windows (192.168.56.20) — 4624 Logon Type 3 @ 10:12:04 → Linux (192.168.56.30) — SSH Accepted @ 10:14:22

Figure 5.3: Lateral movement chain across Windows and Linux logon events

6. Phase 4: Detection Validation & Reporting

6.1 Dashboards

6.1.1 Attack Overview Dashboard

Detections fired, grouped by MITRE ATT&CK tactic:

Tactic	Detections Fired
Reconnaissance	18
Credential Access	9
Persistence	4
Lateral Movement	3

Figure 6.1

6.1.2 Recon & Access Dashboard

Scan detections, brute-force attempts, and successful vs. failed logons, tracked hourly (H1–H5) across scans, failed logons, and successful logons.

Figure 6.2

6.1.3 Post-Exploitation Dashboard

Credential access, persistence, and lateral movement events broken out by host (win-target vs. linux-target).

Figure 6.3

All dashboard figures are illustrative reconstructions of expected Splunk output — replace with your own screen captures.

6.2 Full Attack Chain Exercise

The full chain was executed end-to-end in the following order: Recon → Brute-force initial access → Credential dumping → Persistence → Lateral movement

Stage	Technique	Detected?	Notes
Recon	T1595	✅ Yes	Flagged within 30s by the portscan rule; 1,000+ ports touched in under a minute.
Initial Access	T1110	✅ Yes	Brute-force rule fired at the 10-failure threshold, well before the eventual successful logon.
Credential Access	T1003	✅ Yes	LSASS access rule caught the ProcDump-based dump immediately; no legitimate process baseline matched.
Persistence	T1547/T1053	✅ Yes	Both the registry Run-key rule and the cron/SSH-key rule fired independently.
Lateral Movement	T1021	✅ Yes	Logon Type 3 from the compromised Windows host to the Linux target was flagged.

Figure 6.4: End-to-end timeline of the full attack chain — Recon (T1595) → Brute Force (T1110) → LSASS Dump (T1003) → Persistence (T1547/T1053) → Lateral Move (T1021), spanning roughly 35 minutes elapsed.

7. Detection Rules Summary

Rule Name	MITRE ID	Log Source	Description
Port Scan Detection	T1595	Firewall / Sysmon	Flags source IPs contacting many distinct destination ports in a short window.
SSH Brute Force	T1110.001	Linux auth.log	Flags repeated failed SSH logins against multiple usernames from one source.
Windows Brute Force	T1110.001	Security 4625	Flags repeated failed logons across many accounts from one source.
LSASS Access	T1003.001	Sysmon EID 10	Flags non-standard processes accessing LSASS memory.
Registry Persistence	T1547	Sysmon EID 13	Flags new Run-key registry values.
Cron/SSH Persistence	T1053/T1098	auditd	Flags modification of cron files or `authorized_keys`.
Lateral Movement	T1021	Security 4624 / auth.log	Flags network logons and SSH sessions between internal hosts.
Credential-to-Access Correlation	T1110 → T1003	Multi-source	Chains a successful brute-force logon to a subsequent LSASS access on the same account within 15 minutes — a much stronger signal than either event alone.

Table 7.1: Consolidated detection rule inventory

8. Gaps, Recommendations & Conclusion

8.1 Known Gaps

⚠️ No EDR deployed — Sysmon gives strong process/registry/network visibility, but lacks the memory-scanning and behavioral heuristics a commercial EDR would add.
⚠️ Flat, non-domain environment — Active Directory-specific techniques (Kerberoasting, Golden/Silver Ticket, DCSync) were out of scope and are not covered by any rule in this inventory.
⚠️ No network-layer visibility — no Zeek/Suricata, no packet capture; detections rely entirely on host and authentication logs, so activity that never touches a monitored log source (e.g., pure network sniffing) would be invisible.
⚠️ Ad-hoc searches, not scheduled alerts — rules were run manually during the exercise rather than as scheduled, alerting correlation searches; a production SOC would need continuous execution with a defined alerting and triage workflow.

8.2 Recommendations for Next Iteration

➕ Add a fifth VM as an Active Directory Domain Controller to extend coverage into Kerberos-based credential attacks and domain-wide lateral movement.
➕ Convert the ad-hoc SPL searches into scheduled Splunk alerts with defined severities, routed into a simple triage/ticketing workflow to practice the full detect-to-response loop.
➕ Introduce Zeek for network-layer telemetry to close the blind spot around non-host-based attacker activity.
➕ Layer in Atomic Red Team for repeatable, single-technique testing when tuning rule thresholds, rather than re-running full manual attack chains for every iteration.

8.3 Conclusion

This exercise took a blank set of virtual machines to a working, validated detection pipeline in four weeks. Every attack technique executed against the lab — reconnaissance, brute-force access, credential dumping, persistence, and lateral movement — was independently caught by a purpose-built detection rule, and the final end-to-end attack chain confirmed those rules hold up when techniques are chained together rather than run in isolation.

The resulting rule set, dashboards, and this report form a reusable baseline: the gaps identified above (no AD, no network telemetry, no scheduled alerting) are a natural and well-scoped roadmap for the next phase of the lab rather than open-ended unknowns.

Purple Team Home Lab Report · Ahmed El Euch · August 14, 2026