Skip to content

setup.md

Latest commit

 

History

History
179 lines (134 loc) · 6.64 KB

setup.md

File metadata and controls

179 lines (134 loc) · 6.64 KB
Raw

Environment Setup

Deployment guide for the SOC Detection Lab — a centralized Splunk Enterprise instance with Windows and Linux endpoints forwarding telemetry, plus a dedicated attacker VM for controlled attack simulation.

  • Centralized Splunk Enterprise for collection, detection, and alerting
  • Windows 10 and Ubuntu Server endpoints forwarding real telemetry
  • Dedicated Kali Linux attacker VM
  • NAT'd, isolated virtual network for all endpoints

Table of Contents

Lab Components

Component Purpose
Host OS Runs the hypervisor and Splunk Enterprise
Hypervisor Virtualization platform for all VMs (e.g. QEMU/KVM, VirtualBox, VMware)
Windows 10 Endpoint generating Sysmon and Windows Security telemetry
Ubuntu Server Endpoint generating Linux authentication telemetry
Kali Linux Attacker VM used for controlled attack simulation
Splunk Enterprise Centralized log collection, detection, alerting, and visualization
Splunk Universal Forwarder Forwards endpoint telemetry to Splunk Enterprise

Prerequisites

Requirement Notes
Host OS Any OS capable of running a hypervisor — this build uses Arch Linux
Hypervisor QEMU/KVM, VirtualBox, or VMware
Windows 10 VM With Sysmon installed
Ubuntu Server VM —
Kali Linux VM —
Splunk Enterprise Installed on the host
Splunk Universal Forwarder Installed on both endpoints

Network Architecture

All VMs sit on an isolated, NAT'd virtual network. The host handles NAT/masquerading and routes traffic between the internet-facing interface and the internal bridge, so the attacker VM can reach both endpoints directly while remaining isolated from the rest of the network.

                              Internet
                                 │
                          Host Wi-Fi (wlan1)
                                 │
                        ┌─────────────────┐
                        │      Host       │
                        │  (Arch Linux)   │
                        └────────┬────────┘
                                 │
                     iptables/nftables NAT
                          (masquerade)
                                 │
                        virbr0 (bridge)
                        192.168.122.1
                                 │
             ┌───────────────────┼───────────────────┐
             │                   │                    │
          vnet11              vnet12               vnet13
             │                   │                    │
        Kali VM             Ubuntu VM            Windows VM
     192.168.122.10     192.168.122.20       192.168.122.30
Element Role
wlan1 Host's physical interface, provides internet access
virbr0 Virtual bridge, acts as gateway at 192.168.122.1
vnet11 / vnet12 / vnet13 Per-VM virtual interfaces attached to the bridge
iptables/nftables NAT/masquerade rules giving VMs outbound internet access

Because Kali, Ubuntu Server, and Windows 10 share the same bridge, Kali can reach both endpoints directly for attack simulation, and Splunk on the host receives forwarded telemetry from both.

Deployment

1. Install Splunk Enterprise

Install Splunk Enterprise on the host, then:

  • Start the Splunk service
  • Configure the management account
  • Verify access through the web interface
  • Enable receiving on port 9997 (Settings → Forwarding and receiving → Configure receiving → Add new) — required before any forwarder can send data

Telemetry is indexed into Splunk's default main index; no index creation is required.

2. Create the Virtual Machines

VM Purpose Installs
Windows 10 Generates Windows endpoint telemetry Splunk Universal Forwarder, Sysmon
Ubuntu Server Generates Linux authentication telemetry Splunk Universal Forwarder
Kali Linux Executes attack simulations against both endpoints None

3. Configure Log Forwarding

Ubuntu Server — configure the Universal Forwarder to monitor:

/var/log/auth.log

Verify with:

index=main host="ubuntuserver"

Windows 10 — install Sysmon with an appropriate configuration file, then configure the Universal Forwarder to monitor:

  • Microsoft-Windows-Sysmon/Operational
  • Security

Verify with:

index=main source="WinEventLog:Microsoft-Windows-Sysmon/Operational"

index=main source="WinEventLog:Security"

4. Verify Telemetry

Check Query
Linux auth events index=main host="ubuntuserver"
Windows Sysmon events index=main source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
Windows Security events index=main source="WinEventLog:Security"

Detection Validation

Once telemetry is confirmed, execute the attack simulations documented in each detection.

Platform Simulated Activity
Linux SSH brute force, password guessing, username enumeration, user creation, privileged command execution
Windows CMD execution, PowerShell execution, encoded PowerShell, LOLBin execution, scheduled task creation, service creation, local user creation

Each simulation should produce telemetry matching its corresponding SPL detection.

Alerts

A scheduled alert is created for every documented detection. Each alert:

  • Runs on a scheduled interval
  • Triggers when the detection returns results
  • Generates a notable event for analyst review

Alert configuration screenshots are included in each detection document.

Dashboard

Import or recreate the Dashboard Studio dashboard described in docs/dashboards.md, covering:

  • Environment summary KPIs
  • Linux authentication monitoring
  • Windows endpoint monitoring
  • Detection summaries
  • Investigation tables

Related Documentation

Document Description
Architecture Overall lab architecture
Workflow Detection validation workflow
Telemetry Collected telemetry
Detections Detection catalog
Dashboards Dashboard implementation