Skip to content

The studio of

Ahmed El Euch — Computer Science Engineering Student at INSA Lyon

Breaking systems before attackers do.

Securing Applications, Cloud Infrastructure, Networks & CI/CD

All Writeups

Purple Team Home Lab

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.

By Ahmed El Euch · Published

  • Detection Engineering
  • Splunk
  • MITRE ATT&CK

Purple Team Home Lab is a writeup by Ahmed El Euch, published on 20 August 2026.

SIEM Deployment, Adversary Simulation and Detection Engineering Report

Focus AreaCybersecurity – Detection Engineering
EnvironmentSplunk · Windows · Linux · Kali
FrameworkMITRE ATT&CK
Duration1 Month
AuthorAhmed El Euch
DateAugust 14, 2026

Table of Contents

  1. Executive Summary
  2. Lab Architecture
  3. Phase 1: Lab Build & Baseline
  4. Phase 2: Reconnaissance & Initial Access
  5. Phase 3: Credential Access, Persistence & Lateral Movement
  6. Phase 4: Detection Validation & Reporting
  7. Detection Rules Summary
  8. 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:

  1. Deploy a working Security Information and Event Management (SIEM) platform
  2. Generate realistic offensive activity against monitored targets
  3. 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

MetricResult
Total attack techniques executed7
Detection rules written8 (incl. 1 correlation rule)
Techniques successfully detected7 / 7 (100%)
Dashboards built3
MITRE ATT&CK tactics covered4 – 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

VMOSvCPURAMDisk
Splunk ServerUbuntu Server 22.04 LTS48 GB60 GB
Windows TargetWindows 10/11 or Server Eval.24 GB60 GB
Linux TargetUbuntu Server 22.04 LTS22 GB30 GB
Kali AttackerKali Linux (official VM image)24 GB40 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)

HostSourcetypeStatusLast EventCount
win-targetWinEventLog:SecurityActive2s ago128,943
win-targetSysmon/OperationalActive4s ago342,110
linux-targetlinux_secureActive1s ago87,204
linux-targetlinux_auditActive3s ago54,762

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

3. Phase 1: Lab Build & Baseline

3.1 Build Steps

  1. Hypervisor installed, internal network created, four VMs provisioned with static IPs.
  2. Splunk Enterprise installed on the SIEM VM; indexes created.
  3. Sysmon and the Universal Forwarder installed on the Windows target.
  4. Universal Forwarder and auditd configured on the Linux target.
  5. Kali attacker prepared, network connectivity to both targets confirmed.
  6. 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 NameStateIP AddressCPURAM
splunk-serverRunning192.168.56.1048192 MB
win-targetRunning192.168.56.2024096 MB
linux-targetRunning192.168.56.3022048 MB
kali-attackerRunning192.168.56.4024096 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):

SourceEvents (thousands)
win-target / Security129
win-target / Sysmon342
linux-target / secure87
linux-target / audit55

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_ipdest_ipunique_portsFlag
192.168.56.40192.168.56.201,000ALERT
192.168.56.40192.168.56.30187ALERT
192.168.56.20192.168.56.103–

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
TimeSourceImageTargetImageGrantedAccessUser
09:41:12procdump.exelsass.exe0x1FFFFFWIN-TARGET\admin
09:41:12MsMpEng.exelsass.exe0x1000NT 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
TimeHostArtifact
10:02:07win-targetHKCU\...\Run\Updater → beacon.exe
10:04:51linux-target/etc/crontab modified – new entry, runs every 5 min
10:05:33linux-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

DETECTION — Network Logon / SSH Login Detection

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:

TacticDetections Fired
Reconnaissance18
Credential Access9
Persistence4
Lateral Movement3

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

StageTechniqueDetected?Notes
ReconT1595YesFlagged within 30s by the portscan rule; 1,000+ ports touched in under a minute.
Initial AccessT1110YesBrute-force rule fired at the 10-failure threshold, well before the eventual successful logon.
Credential AccessT1003YesLSASS access rule caught the ProcDump-based dump immediately; no legitimate process baseline matched.
PersistenceT1547/T1053YesBoth the registry Run-key rule and the cron/SSH-key rule fired independently.
Lateral MovementT1021YesLogon 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 NameMITRE IDLog SourceDescription
Port Scan DetectionT1595Firewall / SysmonFlags source IPs contacting many distinct destination ports in a short window.
SSH Brute ForceT1110.001Linux auth.logFlags repeated failed SSH logins against multiple usernames from one source.
Windows Brute ForceT1110.001Security 4625Flags repeated failed logons across many accounts from one source.
LSASS AccessT1003.001Sysmon EID 10Flags non-standard processes accessing LSASS memory.
Registry PersistenceT1547Sysmon EID 13Flags new Run-key registry values.
Cron/SSH PersistenceT1053/T1098auditdFlags modification of cron files or authorized_keys.
Lateral MovementT1021Security 4624 / auth.logFlags network logons and SSH sessions between internal hosts.
Credential-to-Access CorrelationT1110 → T1003Multi-sourceChains 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