No broken password. No exploit. No firewall alert. Just an employee using access they were supposed to have — to take data they weren’t. Here’s how I caught it with a three-stage correlation in Splunk.

By Ronak Mishra · SC-200 | Security+ | ISC2 CC · Splunk Enterprise SIEM Lab

Most detection content is about outsiders — brute force, phishing, exploits. The attacker is external, the activity is obviously malicious, and the logs light up.

Insider threats are the opposite. The account is valid. The access is authorized. Every individual action, viewed on its own, looks like normal work. There’s no single event you can alert on. And that’s exactly what makes them the hardest thing a SOC has to catch.

I built a Splunk lab to detect one end to end. This is how it worked.

The scenario

A fictional e-commerce company, Meridian Commerce Inc. A Finance account on a Windows 11 workstation (FIN-WKS-04) with legitimate access to customer payment data. The insider does three things:

1. Reads the payment file C:\CustomerExports\payments_export.csv. This account is allowed to. (Event ID 4663)
2. Compresses it with PowerShell’s Compress-Archive. Zipping a file isn't malicious. (Event ID 4104)
3. Exfiltrates it to an external host with curl.exe over port 4444. One outbound connection among thousands. (Event ID 5156)

Read, zip, upload. Three ordinary actions. No perimeter control catches this because nothing is breached. No auth alert fires because the login is valid. The attack lives entirely inside legitimate behavior. The only way to see it is to stop looking at events individually and start looking at the pattern they form together.

Problem 1 — the workstation logs almost nothing by default

Before correlating anything, I found the telemetry wasn’t even there. A default Windows 11 workstation doesn’t log these events. Three audit subcategories must be explicitly enabled: File System (4663) plus a SACL on the folder, PowerShell Script Block Logging (4104), and Filtering Platform Connection (5156). Without them, the read, the compression, and the exfiltration are all invisible. If these aren’t on before the attack, there’s nothing to detect after — the evidence was never written.

Problem 2 — the compression step tried to hide

I expected to catch the compression via Event ID 4688 (Process Creation). It never fired. Compress-Archive is a native PowerShell cmdlet — it runs inside the existing PowerShell engine and doesn't spawn a child process, so there's no 4688. Any detection relying only on process-creation auditing is blind to PowerShell-native staging. That's why Script Block Logging (4104) matters — it captures the cmdlet with full parameter bindings, including exact source and destination paths.

The detection — correlating three stages into one incident

index=windows (EventCode=4663 Object_Name="*CustomerExports*")
    OR (EventCode=4104 _raw="*CompressFilesHelper*")
    OR (EventCode=5156 Destination_Port=4444)
| transaction host maxspan=30m
| where eventcount >= 3
| table _time, host, eventcount, duration

The three OR conditions each match one stage. transaction host maxspan=30m groups events on the same host within a 30-minute window into one logical unit — the line that turns scattered events into a story. where eventcount >= 3 only fires when all three stages hit the same host inside that window. One stage, nothing. Two, nothing. All three in sequence — that's a kill chain, not coincidence.

Result: 27 raw events correlated into 1 incident, spanning 25 minutes on FIN-WKS-04. One alert with the full narrative instead of 27 disconnected log lines nobody would piece together manually.

What happens after the alert fires

Detecting the chain is only step one. Here’s how I’d actually triage this in a live SOC:

Severity: High. Confirmed customer PII touched, compressed, and sent to an external host — this isn’t “suspicious,” it’s a completed exfiltration, not an attempt.

First move: Isolate FIN-WKS-04 from the network immediately to stop any further outbound activity, and disable the account pending investigation — not delete it, since the account and its full history are now evidence.

Scope the blast radius: Pull every file that account touched in the same session window, not just the one flagged file — the transaction proves this exfiltration; it doesn’t rule out others in the same session.

Escalate, don’t conclude: This is exactly the kind of finding that gets handed to IR and HR jointly, not closed solo by a SOC analyst. My job at this stage is to hand over a clean timeline, not decide intent — that’s a human resources and legal call, not a technical one.

Tune after, don’t tune during: The 30-minute window and the 3-event threshold both need validation against real traffic before this becomes a production rule — a busy analyst doing legitimate bulk export-and-archive work could trip the same pattern. That tuning is exactly what separates a lab detection from a production one.

That last part matters more than the query itself. A rule that fires is only useful if someone downstream knows what to do the moment it does.

This is Phase 5 of a full Splunk Enterprise SIEM lab I built from scratch — 6 OWASP Top 10 detections, a live SOC dashboard, incident reports, and two documented detection gaps. Full lab and all SPL: github.com/ronakmishra28/meridian-soc-detection-lab