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, process access events, and indicators of injection-related behaviour.
• 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, process access behaviour, and persistence-related indicators.

Active Sysmon event coverage in this environment:

Process activity

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

File system activity

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

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

Process access / injection indicators

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

WMI persistence telemetry

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

System telemetry

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

Named pipe monitoring

• Event ID 18 - PipeEvent

Other host activity

• Event ID 24 - ClipboardChange

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 and 20, 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. 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, process access behaviour, injection-related indicators, WMI persistence artefacts, named pipe activity, and driver loading events.
• 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.