Lab Architecture

Platform Overview

• Telemetry model: Dual-layer collection via network gateway (Suricata IDS) and endpoint agent (Sysmon + WinEventLog), forwarded to Splunk for centralised analysis.
• Architecture: Gateway IDS provides flow-level visibility; the Windows endpoint is instrumented with Sysmon, providing multi-category host telemetry including process execution, file system activity, registry modifications, DNS queries, network connections, image loading, raw disk access, process access and injection indicators, WMI persistence artefacts, named pipe monitoring, clipboard activity, and process tampering detection.
• Scope: Detection logic validation, log ingestion, and cross-index correlation within a small-scale environment.
• Constraints: Non-production scale, single analyst, no enterprise distributed architecture, no EDR functionality, no cloud connectivity testing.

Endpoint Telemetry Scope

The Windows endpoint uses Sysmon to provide multi-category host telemetry across process execution, file system activity, registry modifications, DNS queries, network connections, image loading, raw disk access, process access behaviour, WMI persistence artefacts, named pipe monitoring, clipboard activity, and process tampering detection.

Active Sysmon event coverage in this environment:

Process activity

• Event ID 1 - ProcessCreate
• Event ID 5 - ProcessTerminate

Process access / injection indicators

• Event ID 8 - CreateRemoteThread
• Event ID 10 - ProcessAccess

Process tampering

• Event ID 25 - ProcessTampering

File system activity

• Event ID 2 - FileCreateTime
• Event ID 11 - FileCreate
• Event ID 15 - FileCreateStreamHash
• Event ID 23 - FileDelete

Raw disk access

• Event ID 9 - RawAccessRead

Registry activity

• Event ID 12 - RegistryObjectCreate/Delete
• Event ID 13 - RegistryValueSet
• Event ID 14 - RegistryObjectRename

Network activity

• Event ID 3 - NetworkConnect

DNS activity

• Event ID 22 - DNSQuery

Image / module loading

• Event ID 7 - ImageLoad

WMI persistence telemetry

• Event ID 19 - WmiEventFilter
• Event ID 20 - WmiEventConsumer
• Event ID 21 - WmiEventBinding

Named pipe monitoring

• Event ID 17 - PipeCreated
• Event ID 18 - PipeConnected

Clipboard monitoring

• Event ID 24 - ClipboardChange

System telemetry

• Event ID 4 - Sysmon Service State Change
• Event ID 6 - DriverLoad
• Event ID 16 - Sysmon Configuration Change

1. Overview

Lab Name: SOC Lab v1

Purpose: Construct a small-scale monitoring environment for ingesting and analysing host and network telemetry.

Scope:

• Single analyst environment
• Non-production scale
• Controlled test network

Architecture Overview

Diagram: SOC Lab v1 showing attack traffic flow, gateway inspection, endpoint telemetry collection, and centralised analysis in Splunk.

2. Environment Summary

2.1 Host Platform

• Host OS: Windows 11 Pro
• Hypervisor: Hyper-V
• Host hardware: Multi-core consumer CPU, 32 GB RAM, SSD-based storage.

2.2 Virtual Machines

VM Name	Role	OS	Notes
Ubuntu-24.04-Splunk-Enterprise	SIEM	Linux	Ubuntu 24.04 server build - Memory 4096MB, 8 Processors, VHD 60GB (Gen1)
Ubuntu-24.04-Suricata	Gateway/IDS	Linux	Ubuntu 24.04 server build - Memory 4096MB, 8 Processors, VHD 20GB (Gen1)
Win11-25H2-UF	SplunkUF/Sysmon	Windows 11 Pro	Win11Pro - Memory 4096MB, 8 Processors, VHD 43GB (Gen2)
Kali-2025.4-Test	Simulate attacks	Linux	Kali 2025.4 - Memory 4096MB, 8 Processors, VHD 25GB (Gen2)

3. Network Design

3.1 Network Segments

Network	Type	Addressing	Purpose	Comments
NAT	NAT	192.168.100.1	Internet access only
InternalLab	Internal	10.0.0.0/24	Monitored lab traffic	Enable MAC address spoofing for the gateway ‘VM as a router’

4. Tooling and Components

4.1 SIEM Platform

• Platform: Splunk Enterprise
• Deployment type: Full deployment (trial)
• Primary purpose in lab: Analysis, dashboards, pivots, reports

4.2 Network Sensor

• Tool: Intrusion Detection System
• Function: Detect incoming traffic, forward logs to Splunk with UF
• Traffic visibility: Default gateway (sees all traffic coming through eth0 interface)

4.3 Endpoint Telemetry

• Source OS: Win11-25H2-UF
• Telemetry collected: WinEventLog/Sysmon
• Forwarding method: Splunk Universal Forwarder

5. Data Collection

5.1 Log Sources

Source	Log Type	Destination
Win11-25H2-UF	Sysmon (operational)	sysmon
Win11-25H2-UF	Security event log	security
Win11-25H2-UF	System event log	wineventlog
Win11-25H2-UF	Application event log	wineventlog
Ubuntu-24.04-Suricata	EVE.JSON (alerts, flows, DNS, HTTP, TLS)	suricata_eve
Ubuntu-24.04-Suricata	Suricata stats / engine metrics	suricata_stats

5.2 Ingestion Validation

Logs validated via direct index searches (e.g. index=sysmon, index=suricata_eve) using a 24-hour time range. Non-zero event counts and recent timestamps confirmed successful ingestion and correct index routing.

6. Detection and Analysis

6.1 Test Activity Summary

16 controlled tests executed: 4 network-observable (scanning, brute-force, reconnaissance) and 12 host-only (command execution, persistence, process injection, WMI, scheduled tasks, discovery, DNS, tool transfer).

7. Findings

Observed Strengths

• Endpoint telemetry generated reliable evidence across multiple activity categories, including process execution, file system events, registry persistence activity, DNS queries, network connections, process access behaviour, and WMI persistence activity (Sysmon Event IDs 19, 20, and 21, confirmed in T1546.003).
• Network scanning and brute-force activity produced observable flow and alert events.
• Cross-index correlation performed via time-bounded searches.

Observed Gaps

Observed gaps in the monitoring environment include:

• No endpoint detection and response (EDR) platform or behavioural analytics layer
• No PowerShell script block logging (Event ID 4104)
• No AMSI instrumentation
• No cloud or SaaS telemetry sources
• Detection workflows rely on manual Splunk searches rather than automated alerting or SOAR orchestration

Noise Characteristics

• Repeated scans produced high-volume flow events.
• Background Windows processes required filtering during analysis.

8. Limitations

• Scale: Small, single-segment environment; does not simulate enterprise traffic volumes or concurrent attack activity.
• Licensing: Enterprise trial (Splunk, Emerging Threats Open) limits access to premium detections.
• Hardware: Local hardware constrains performance testing and large data volumes.
• Single analyst: Reduces behavioural diversity and multi-user realism.
• Sensor scope: Limited to Sysmon endpoint telemetry and Suricata perimeter IDS; no EDR, firewall, or cloud logs.

9. Technical Observations

• Endpoint telemetry provides greater investigative depth than perimeter IDS alone.
• Perimeter IDS visibility limited to observable network-layer behaviours.
• Absence of alerts must be evaluated against sensor coverage and rule scope.
• Native utilities remain available on modern Windows builds; T1559.002 (DDE execution) was blocked by Microsoft Defender prior to execution, not by OS utility removal.

10. Document Control

• Author: Zachary McGill
• Created: 2026-01-18
• Last Updated: 2026-03-09
• Status: Complete
• Review cadence: On major lab architecture changes

1. Suricata’s Role

Suricata operates in detection-only mode. Traffic is captured via AF_PACKET on eth0 prior to NAT and iptables processing.

2. What Suricata Sees

• All traffic ingressing/egressing eth0 (gateway ↔ endpoint, gateway ↔ Internet)
• Packets prior to firewall decisions (INPUT/FORWARD chains)
• Excludes loopback-only traffic and non-eth0 interfaces

Suricata observes network behaviour only; it does not confirm host compromise. Many tested techniques occur entirely on the endpoint and bypass network sensors; Suricata visibility is limited to the network-perimeter subset of the tested technique set.

3. Rule Coverage Categories

Flow-based

• Repeated connections
• Port scanning
• Brute-force patterns

Reputation

• Known malicious IP feeds (ET Open)

Protocol Anomalies

• Invalid handshakes
• Malformed packets
• Abusive SSH negotiation

Production Considerations

• Flow-only visibility insufficient for post-exploitation detection.
• Requires correlation with endpoint telemetry.
• High-volume flow events require thresholding.
• Rule tuning necessary to reduce alert fatigue.
• Fragmentation and asymmetric routing may reduce detection reliability.

Document Control

• Author: Zachary McGill
• Created: 2026-01-18
• Last Updated: 2026-03-09
• Status: Complete

1. Sysmon’s Role

Sysmon (System Monitor) from Microsoft Sysinternals is deployed on the Windows endpoint in SOC Lab v1 to generate detailed host telemetry. The goal is to capture process, network, file, and registry activity that can support detection engineering and threat investigation workflows.

Sysmon events are forwarded to Splunk using the Splunk Universal Forwarder. The telemetry is then used to validate detection logic through Atomic Red Team tests mapped to MITRE ATT&CK techniques.

The configuration used in this lab is based on the SwiftOnSecurity Sysmon configuration (v74) with additional telemetry categories enabled to increase visibility during testing.

2. Architecture Context

Telemetry flow within the lab environment:

Windows Endpoint (Sysmon)

• Generates host activity telemetry
• Logs written to Windows Event Log

Splunk Universal Forwarder

• Collects Sysmon events
• Forwards events to the Splunk indexer

Splunk Enterprise (single node)

• Index: sysmon
• Used for search and detection validation

Event channel used:

Microsoft-Windows-Sysmon/Operational

Source in Splunk:

WinEventLog:Microsoft-Windows-Sysmon/Operational

Sourcetype in Splunk:

XmlWinEventLog:Microsoft-Windows-Sysmon

3. Configuration Base

Base configuration:

SwiftOnSecurity Sysmon Config v74
https://github.com/SwiftOnSecurity/sysmon-config

The SwiftOnSecurity configuration provides:

• Sensible filtering of common system noise
• Detection focused rules for suspicious behaviour
• Coverage for common adversary techniques

For this lab environment the configuration was modified to increase telemetry coverage for detection testing.

4. Additional Telemetry Enabled

Several telemetry categories were modified from the original Swift configuration.

ImageLoad (Event ID 7)

Original behaviour:

onmatch="include"

This logs only images matching specific rules.

Lab modification:

onmatch="exclude"

This change allows all image loads to be logged except explicitly filtered noise.

Purpose:

• Improve visibility into DLL loading behaviour
• Support testing of code injection and module loading techniques

RawAccessRead (Event ID 9)

Original behaviour:

onmatch="include"

Lab modification:

onmatch="exclude"

Purpose:

• Capture direct disk access
• Detect potential credential dumping or forensic evasion behaviour

ProcessAccess (Event ID 10)

Original behaviour:

onmatch="include"

Lab modification:

onmatch="exclude"

Purpose:

• Improve detection of process injection techniques
• Capture suspicious access to sensitive processes

FileDelete (Event ID 23)

A new rule group was added:

<FileDelete onmatch="exclude" />

Purpose:

• Capture file deletion activity
• Support detection of log clearing and artefact removal

ClipboardChange (Event ID 24)

The Swift configuration contains this rule group but it is commented out by default.

Lab modification:

• Section uncommented
• onmatch="exclude" applied

Purpose:

• Monitor clipboard activity
• Useful for detecting credential copying or data staging

ProcessTampering (Event ID 25)

The rule group exists in the base configuration but is disabled.

Lab modification:

• Section enabled

Purpose:

• Capture process tampering behaviour
• Relevant to modern process injection and evasion techniques

5. Event Coverage

Sysmon supports event identifiers from 1 to 29.

The configuration used in this lab generates telemetry for the following primary detection categories.

Event ID	Event Type
1	Process Create
2	File Create Time
3	Network Connection
4	Sysmon Service State Change
5	Process Terminate
6	Driver Load
7	Image Load
8	Create Remote Thread
9	Raw Access Read
10	Process Access
11	File Create
12	Registry Create/Delete
13	Registry Value Set
14	Registry Rename
15	File Stream Hash
16	Sysmon Configuration Change
17	Pipe Created
18	Pipe Connected
19	WMI Event Filter
20	WMI Event Consumer
21	WMI Event Binding
22	DNS Query
23	File Delete
24	Clipboard Change
25	Process Tampering

Some events appear only when relevant activity occurs.

6. Validation

Telemetry was validated through Splunk searches against the sysmon index.

Validation query:

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon"
| rex "<EventID>(?<EventID>\\d+)</EventID>"
| stats count by EventID
| sort EventID

This query extracts the EventID directly from the raw XML event payload.

The extraction approach was used because Splunk Free mode does not permit installation of the Windows TA which normally provides automatic field parsing.

7. Repository Reference

The configuration used in this lab is stored in the repository:

soc-automation-lab/telemetry/sysmon-config.xml

This ensures the telemetry configuration is reproducible and version controlled.

8. Role in Detection Engineering

Sysmon telemetry provides the primary host-level visibility used to investigate adversary behaviour within SOC Lab v1.

During Atomic Red Team testing, Sysmon events are ingested into Splunk and analysed to confirm whether attacker activity produces observable endpoint artefacts that can support detection engineering and investigation workflows.

Technique mappings illustrate representative host telemetry used during analysis of several tested ATT&CK techniques.

ATT&CK Technique	Example Sysmon Telemetry
T1059.001 PowerShell	Event ID 1 (ProcessCreate)
T1055 Process Injection	Event ID 1 (ProcessCreate, demonstrated); Event IDs 8 (CreateRemoteThread) and 10 (ProcessAccess) available but not validated in this test
T1547.001 Registry Run Keys	Event ID 13 (RegistryValueSet, demonstrated); Event ID 12 (RegistryCreate/Delete) not triggered in this test
T1105 Ingress Tool Transfer	Event ID 1 (ProcessCreate, demonstrated); Event ID 22 (DNSQuery) and Event ID 11 (FileCreate) referenced as supporting telemetry

Network discovery techniques such as T1046 are primarily observable through Suricata network telemetry within this lab environment rather than Sysmon endpoint events.

These telemetry examples demonstrate how Sysmon provides host-level evidence supporting investigation of attacker behaviour, while full detection analysis is performed through Splunk searches and correlation with additional log sources.

Document Control

• Author: Zachary McGill
• Created: 2026-01-18
• Last Updated: 2026-03-15
• Status: Complete

1. Splunk’s Role

Splunk Enterprise functions as the central SIEM on Ubuntu-24.04-Splunk-Enterprise. It ingests endpoint telemetry via Universal Forwarder and Suricata EVE output from the gateway.

2. Data Ingestion

Splunk receives logs from:

Endpoint (Windows 11)

• Sysmon - provides host-level telemetry covering multiple activity categories including process execution and termination, file creation and deletion, registry modifications, outbound network connections, DNS queries, image loading, raw disk access, process access behaviour, injection-related indicators, WMI persistence artefacts, named pipe activity, driver loading events, clipboard monitoring, and process tampering detection.
• Security event log (user logon, privilege changes)
• System event log (service/driver events)
• Application event log (general application events)

Network (Suricata Gateway)

• EVE.JSON (alerts, flows, DNS, HTTP, TLS protocol events)
• Engine statistics and metrics

All logs forward via Splunk Universal Forwarder to custom indexes (sysmon, security, wineventlog, suricata_eve, suricata_stats). Ingestion latency averages 1-5 seconds under lab load.

3. Search and Analysis

Splunk queries are structured around index selection and field extraction.

Process execution detection:

index=sysmon EventCode=1 Image="*\\powershell.exe"
| table _time Computer User ParentImage CommandLine

Network scanning detection:

index=suricata_eve event_type=flow src_ip=10.0.0.30
| stats dc(dest_port) as unique_ports

Cross-layer correlation: Cross-layer correlation performed via time-bounded searches across relevant indexes. The join command is avoided due to scalability and memory constraints.

Field extraction is automatic for known sourcetypes (sysmon, suricata_eve). Custom fields defined in props.conf and transforms.conf for non-standard log formats.

Production Considerations

• Avoid join on large datasets.
• Apply time constraints to all searches.
• Baseline normal activity prior to threshold logic.
• Consider data model acceleration for high-volume indexes.
• Prefer stats over transaction for improved scale efficiency.

4. Detection Limitations

Current monitoring limitations include:

• No automated alerting framework configured in Splunk
• Detection workflows rely on manual search-driven analysis
• PowerShell script block logging is not enabled
• AMSI instrumentation is not present on the endpoint
• No EDR or behavioural analytics platform is deployed

5. Platform Context

Refer to SOC Lab v1 documentation for overall lab constraints and technical limitations.

6. Document Control

• Author: Zachary McGill
• Created: 2026-01-18
• Last Updated: 2026-02-16
• Status: Complete

Objective

Establish a repeatable, integrity-bound workflow that verifies:

1. Endpoint telemetry generation
2. Splunk ingestion visibility
3. Structured artifact preservation per test case

This pipeline prioritizes defensibility and consistency over automation complexity.

Workflow Model

Each Atomic Red Team (ART) test follows a fixed sequence:

1. Execute ART test
2. Validate local telemetry (PowerShell)
3. Orchestrate artifact retrieval (Bash)
4. Validate ingestion in Splunk Web
5. Export and hash evidence

No alerting logic, no scheduling, no SOAR integrations.

Case Structure

Each execution generates a timestamped case directory:

cases/<case_id>/
  metadata.txt
  orchestration.log
  evidence.hash
  windows/
    process-validation.json
  splunk/
    splunk-validation.csv
    suricata-validation.csv 

<case_id> is generated automatically by the orchestration script (UTC timestamp).
Splunk does not track the case ID; it is used solely for local evidence control.

Endpoint Validation (PowerShell)

Validate-Process.ps1 performs:

• Sysmon Event ID 1 queries
• Security Event ID 4688 queries
• Field normalisation
• Structured JSON export
• Controlled exit code handling

Output: windows/process-validation.json

Purpose: Confirm telemetry exists at the source before validating ingestion.

Orchestration (Bash)

run-validation.sh enforces procedural consistency:

• Executes remote validation via SSH
• Generates case directory
• Retrieves evidence via SCP
• Logs execution metadata
• Generates SHA256 hashes

This removes manual handling errors and enforces repeatable structure.

Splunk Validation (Manual by Design)

Validation is performed via Splunk Web UI for reliability and transparency.

Representative validation query example:

(index=sysmon Image="*powershell*")
OR
(index=security EventCode=4688 "*powershell*")
| eval Process=coalesce(Image, New_Process_Name)
| eval LogSource=if(index="sysmon","Sysmon","Security")
| table _time host LogSource Process CommandLine ParentImage
| sort - _time

Time range: Last 5-15 minutes.

Results exported to: splunk/splunk-validation.csv

Manual review ensures analytical judgment remains human-driven.

Integrity Model

All artifacts are cryptographically bound:

• windows/process-validation.json
• splunk/splunk-validation.csv

SHA256 hashes are appended to: evidence.hash

This creates tamper-evident, reproducible case records.

Scope Discipline

Automated

• Test validation execution
• Artifact retrieval
• Evidence structuring
• Integrity hashing
• Standardised validation queries

Not Automated

• Detection engineering
• Alert generation
• Scheduled searches
• Splunk APIs
• SOAR integration
• Report writing

Automation reduces operational friction.
Detection reasoning and analytical conclusions remain manual.

Operational Outcome

Per-test workflow reduced from approximately 15 minutes to approximately 1 minute 45 seconds.

Each execution produces:

• Verified endpoint telemetry
• Verified Splunk ingestion
• Structured case artifacts
• Integrity-bound evidence
• Reproducible documentation

This pipeline demonstrates disciplined automation aligned with entry-level SOC analyst responsibilities.