Splunk Part 03: Building ATT&CK-Aligned Searches
Welcome Back!
In the previous parts of this series, we focused on getting Splunk running and understanding how data is searched using SPL. We also introduced the MITRE ATT&CK framework and explained how it models adversary behavior rather than tools or malware. This part connects those two ideas.
At this stage, Splunk is no longer just a log viewer. It becomes a platform where adversary behavior can be modeled, searched, and validated against real telemetry. That is the core idea behind detection engineering.
MITRE ATT&CK does not give you alerts. It does not give you queries. What it gives you is a structured way to describe how attackers behave once they interact with a system. The work happens when those behaviors are translated into something observable inside your data.
From ATT&CK Techniques to Splunk Searches
Each ATT&CK technique describes an action an adversary takes to move, execute, persist, or evade. For that action to be detected, there must be a data source capable of recording it. In Splunk, that usually means authentication logs, process creation events, command-line telemetry, or network logs.
One of the most common techniques encountered in real environments is Command and Scripting Interpreter, tracked by MITRE as T1059
https://attack.mitre.org/techniques/T1059/
This technique covers adversary execution of commands through interpreters such as PowerShell, cmd.exe, bash, or similar shells. On Windows systems, this behavior is commonly visible through process creation events.
Observing Command Execution in Splunk
If Windows Security logs are indexed, process creation events can be queried using Event ID 4688. A basic search to surface PowerShell execution looks like this:
index=windows EventCode=4688
| search New_Process_Name="*powershell.exe*"
| table _time Account_Name New_Process_Name Command_LineThis search does not assume malicious intent. It simply exposes where and how PowerShell is being executed.
[SCREENSHOT — PowerShell process execution results showing multiple PowerShell events with command-line visibility]
In most environments, this will return a mix of administrative activity and automation. That is expected. Detection work starts by understanding what “normal” looks like.
Narrowing Toward Suspicious Execution
Adversaries frequently use encoded commands to obscure PowerShell activity. This behavior is explicitly documented under T1059. Filtering for encoded arguments begins to separate routine use from potentially suspicious execution.
index=windows EventCode=4688
| search New_Process_Name="*powershell.exe*" Command_Line="*-enc*"
| table _time Account_Name Command_Line[SCREENSHOT — Encoded PowerShell command results highlighting “-enc” usage in the command line]
At this point, the search is no longer generic visibility. It is directly aligned with an ATT&CK technique. This is what it means to build a behavior-based detection rather than a signature.
Detecting Authentication Abuse (T1110)
Another commonly observed ATT&CK technique is Brute Force, tracked as T1110 https://attack.mitre.org/techniques/T1110/
On Windows systems, failed authentication attempts are logged with Event ID 4625. Repeated failures against the same account or from the same source can indicate password guessing or credential stuffing activity.
A simple SPL search to surface this behavior looks like:
index=windows EventCode=4625
| stats count by Account_Name, src_ip
| where count > 5[SCREENSHOT — Aggregated failed login attempts grouped by account and source IP]
This does not prove compromise. It identifies abnormal patterns that deserve attention. Thresholds should always be tuned to the environment, but the behavioral signal remains consistent.
Correlating Techniques in Practice
ATT&CK techniques rarely occur in isolation. An attacker may attempt brute force authentication, successfully log in, and then execute commands. Individually, each action may look benign. Together, they tell a different story.
Splunk allows analysts to pivot between authentication events and process execution within the same time window. This is where ATT&CK becomes operational rather than theoretical.
[SCREENSHOT — Timeline or table view showing authentication activity followed by PowerShell execution]
This investigative workflow mirrors how real SOC investigations unfold. The framework provides the map, but the analyst still validates intent using context.
Labeling Detections with ATT&CK Metadata
In mature detection programs, SPL searches and alerts are labeled with ATT&CK technique identifiers. This is not cosmetic. It allows teams to understand which adversary behaviors are covered and which are not.
A saved search might reference T1059 directly in its name or description. Dashboards can group detections by tactic. Over time, this enables coverage analysis instead of relying on alert counts alone.
At this point, ATT&CK techniques are no longer abstract labels. They are behaviors that can be searched for, filtered, and reasoned about using real data. Splunk is being used to test assumptions about attacker activity rather than simply collecting logs.
This part intentionally stops short of alerts and automation. Before anything is operationalized, the behavior has to make sense in the data. The next step is taking these searches and turning them into repeatable detections that can be tracked, tuned, and maintained over time.
Stay Curious!