Detect an Attack Chain in Splunk

Build 3 SPL detection rules mapped to MITRE ATT&CK by simulating a real attack chain.

Introduction

30 Second Summary

Real-world attackers don't just break in and grab what they want. They move through systems in stages, from gaining an initial foothold to stealing credentials that unlock even more access. Security teams need to detect each stage before the damage compounds.

In this project, you will simulate a realistic 3-stage attack chain in your home lab, hunt through the resulting endpoint telemetry in Splunk, and write detection rules that catch each stage of the intrusion.

What You'll Build

A detection engineering portfolio piece that traces attacker behaviour from initial PowerShell execution through persistence via scheduled tasks to credential dumping from LSASS memory.

By the end of this project, you'll have:

3 tested SPL detection rules mapped to MITRE ATT&CK techniques (T1059.001, T1053.005, T1003.001) running in your Splunk instance.
A documented investigation report showing how you traced a simulated attack chain from execution through persistence to credential access.
A telemetry mapping table connecting ATT&CK techniques to Sysmon Event IDs and detection-relevant fields.
Secret Mission: Write a Sigma rule for one of your detections, demonstrating vendor-agnostic detection engineering skills.

Do I need anything set up before starting?

Yes. This project assumes you already have a home lab with Splunk running on an Ubuntu VM, a Windows VM with Sysmon configured and forwarding logs to Splunk, and Atomic Red Team installed on the Windows VM. You should also have snapshot capability for your Windows VM so you can restore to a clean state.

Before We Start

Detection engineering is the skill that separates alert-clickers from investigators. In this project, you will simulate a realistic 3-stage attack chain on your Windows VM, hunt through the telemetry it generates, and write tested detection rules in Splunk.

Before you run any attacks, you need a clean baseline. In this step, you will restore your Windows VM to a known-good state, confirm your tools are working, and create the investigation report document you will use throughout the project.

In this step, get ready to:

Confirm your Windows tools (Sysmon, Atomic Red Team) are running and accessible.
Verify Splunk is receiving Sysmon logs from your Windows endpoint.
Create your investigation report template with MITRE ATT&CK technique mappings.

Restore your snapshot and confirm Windows tools

A clean VM state ensures your attack telemetry is the only noise in the logs. Restoring your snapshot removes any leftover artifacts from previous testing.

Restore your Windows VM to its most recent clean snapshot using your hypervisor's snapshot manager.
Once the VM boots, open PowerShell as Administrator.
Confirm Atomic Red Team is accessible by running this command:

Invoke-AtomicTest T1059.001 -ShowDetailsBrief

What does this command do?

This command asks Atomic Red Team to list all available tests for technique T1059.001 (PowerShell execution). If the module is loaded correctly, you will see a list of numbered test names.

If you only see a folder path instead of a test list, the Atomic Red Team module may not be imported. Run Import-Module Invoke-AtomicRedTeam first, then retry.

Confirm Sysmon is running by checking the service status:

Get-Service sysmon64

What should I see?

You should see the service listed with a Status of Running. If your install used the 32-bit version, try Get-Service sysmon instead.

Sysmon service not found?

If you get an error saying the service cannot be found, Sysmon may not be installed on this VM. Revisit your home lab setup and confirm Sysmon was installed and configured before continuing.

help me troubleshoot why Sysmon is not showing as a running service on my Windows VM

Confirm Splunk is ingesting Sysmon logs

Your detection rules rely on Sysmon telemetry arriving in Splunk. A quick search confirms the log pipeline is healthy before you generate new attack data.

On your Ubuntu VM, open Splunk Web in your browser.
Navigate to Search & Reporting from the left sidebar.
Run this search to check for recent Sysmon events:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" | head 10

What should I see?

You should see up to 10 recent events in the results table. Each event represents a Sysmon log entry (process creation, network connection, file creation, etc.) forwarded from your Windows VM.

If you see results, your log pipeline is working. Note the current time as your baseline timestamp. You will use this timestamp later to filter searches to only show events generated after this point.

Note the current time (check the clock on your Ubuntu VM or the latest event timestamp in Splunk). Write this down as your baseline timestamp.

No events returned?

Check that the Windows VM is powered on and has network connectivity to your Ubuntu VM. Verify your Splunk Universal Forwarder service is running on the Windows endpoint.

Also confirm the sourcetype matches your Splunk configuration. Try broadening the search to index=* with no sourcetype filter to see if any data is arriving at all.

help me troubleshoot why my Splunk instance is not showing Sysmon events from my Windows VM

Create your investigation report template

Investigation reports are a standard SOC deliverable. You will build this document throughout the project, documenting your methodology, findings, and detection logic for each technique.

Create a new file called Investigation Report - Attack Chain Detection.md in a location you can easily find (your Desktop or a project folder).
Paste the following template into the file:

# Investigation Report - Attack Chain Detection

## Date
[[DATE="today's date"]]

## Lab Environment Description
[[LAB_DESCRIPTION="describe your lab setup (e.g. Windows 11 VM with Sysmon, Ubuntu VM with Splunk Free)"]]

## Objective
[[OBJECTIVE="your project objective (e.g. Simulate a 3-stage attack chain and build detection rules)"]]

## MITRE ATT&CK Techniques Covered
- T1059.001
- T1053.005
- T1003.001

What does each section cover?

Date: when you performed the investigation.
Lab Environment Description: your VM setup so anyone reading the report can reproduce your work.
Objective: the goal of this detection engineering exercise.
MITRE ATT&CK Techniques Covered: the three technique IDs you will simulate, hunt for, and build detections against.

Fill in the Date, Lab Environment Description, and Objective fields with your own details.
Save the file.

Keep this file open

You will add to this report in every remaining step. Keep it open in a text editor throughout the project so you can quickly document findings as you go.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file with all three sections filled in.

ⓧ I'd like to double check the full code

Here is what your completed report template should look like (with your own values filled in):

# Investigation Report - Attack Chain Detection

## Date
[[DATE="today's date"]]

## Lab Environment Description
[[LAB_DESCRIPTION="describe your lab setup (e.g. Windows 11 VM with Sysmon, Ubuntu VM with Splunk Free)"]]

## Objective
[[OBJECTIVE="your project objective (e.g. Simulate a 3-stage attack chain and build detection rules)"]]

## MITRE ATT&CK Techniques Covered
- T1059.001
- T1053.005
- T1003.001

Your lab is verified and your report is ready. Next up, you will execute the 3-stage attack chain and generate the telemetry you will hunt through in Splunk.

Execute the Attack Chain

Your lab is clean, your tools are confirmed, and you have a baseline timestamp to filter against. Now it's time to become the attacker.

In this step, you will simulate a realistic 3-stage intrusion using Atomic Red Team. Each stage maps to a different phase of the MITRE ATT&CK framework: Execution, Persistence, and Credential Access. The telemetry these attacks generate is what you will hunt through in the next step.

In this step, get ready to:

Execute a PowerShell command (T1059.001) to simulate initial code execution.
Create a scheduled task (T1053.005) to simulate persistence.
Dump LSASS memory (T1003.001) to simulate credential theft.

Simulate PowerShell execution (T1059.001)

The first stage of your attack chain is Execution. An attacker who has gained initial access to a machine almost always reaches for PowerShell as their first tool. It is built into every Windows machine, powerful, and scriptable.

You will run Atomic Test #19 "PowerShell Command Execution", which executes a basic PowerShell command. This generates Sysmon Event ID 1 (Process Create) telemetry showing powershell.exe launching with command-line arguments.

In your PowerShell Administrator window on the Windows VM, run this command to execute the PowerShell technique:

Invoke-AtomicTest T1059.001 -TestNumbers 19

Confirm the output includes Done executing test: followed by the test identifier.
Wait 15 seconds for the logs to forward to Splunk before continuing.

What does this test do?

Test #19 runs a basic PowerShell command that mirrors what an attacker does after initial access. It does not download anything or connect to the internet.

The value is not in the command itself. The value is in the Sysmon telemetry it generates. Sysmon Event ID 1 records the full command line, the parent process, and the user who ran it. That is exactly what a SOC analyst searches for.

Seeing an error about the module not being loaded?

Make sure you are running PowerShell as Administrator. Right-click the PowerShell icon and select **Run as administrator**.
If the Invoke-AtomicTest command is not recognized, re-import the module by running Import-Module Invoke-AtomicRedTeam and try again.

Help me troubleshoot my Atomic Red Team test execution

Simulate scheduled task persistence (T1053.005)

The second stage is Persistence. After executing code, a real attacker needs a way to survive a reboot. Creating a scheduled task is one of the most common persistence mechanisms because it uses a legitimate Windows feature.

Test #2 "Scheduled task Local" creates a task named spawn using schtasks.exe. This generates Sysmon Event ID 1 telemetry showing schtasks.exe with /Create arguments.

Execute the scheduled task technique by running:

Invoke-AtomicTest T1053.005 -TestNumbers 2

Confirm the output includes Done executing test: in the terminal.
Wait 15 seconds for the logs to forward to Splunk.

Clean up the scheduled task (remove it from the system) by running:

Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup

Why run cleanup after the test?

Cleanup removes the artifacts the test created (the scheduled task "spawn") from your VM. You have already generated the telemetry you need. Leaving stale persistence mechanisms on your lab machine creates noise for future investigations.

Seeing a "cannot create" or access denied error?

This test does not require elevation, but some Windows policies restrict scheduled task creation. Make sure you are still in an Administrator PowerShell session.
If you see a message that the task already exists, run the cleanup command first, then re-run the test.

Help me troubleshoot my scheduled task test

Simulate LSASS credential dumping (T1003.001)

The third and final stage is Credential Access. After establishing persistence, the attacker wants passwords and hashes. The Local Security Authority Subsystem Service (LSASS) process holds credentials for every user who has logged into the machine.

Test #2 "Dump LSASS.exe Memory using comsvcs.dll" uses a built-in Windows DLL to dump LSASS memory. This is a "living-off-the-land" technique that avoids dropping third-party tools like Mimikatz. It generates Sysmon Event ID 10 (Process Access) telemetry showing access to lsass.exe.

Why comsvcs.dll instead of Mimikatz?

Mimikatz fails on Windows builds 24H2 and later due to kernel memory structure changes and the Microsoft Vulnerable Driver Blocklist. The comsvcs.dll method works reliably across all Windows versions.

It also teaches a more realistic attack pattern. Real adversaries prefer tools already on the system because they are harder to detect with signature-based AV.

Execute the credential dumping technique by running:

Invoke-AtomicTest T1003.001 -TestNumbers 2

Confirm the output includes Done executing test: in the terminal.
Wait 15 seconds for the logs to forward to Splunk.

Clean up the dump file by running:

Invoke-AtomicTest T1003.001 -TestNumbers 2 -Cleanup

Seeing an access denied or privilege error?

This test requires elevation. Confirm your PowerShell window title bar says "Administrator".
If Windows Defender blocks the dump, you may need to add an exclusion for the Atomic Red Team atomics folder. This is a known lab-environment issue and does not affect the telemetry already generated.

Help me troubleshoot my LSASS credential dump test

All three attack stages are complete. Now document what you did so your investigation report has a clear timeline.

Open your Investigation Report - Attack Chain Detection.md file.
Add a new "Simulation" section below the header. Record each attack with the exact command, your timestamp, and the ATT&CK technique ID. Use this structure:

## Simulation

### T1059.001 - PowerShell Command Execution
- Command: Invoke-AtomicTest T1059.001 -TestNumbers 19
- Timestamp: [timestamp]
- ATT&CK Technique: T1059.001

### T1053.005 - Scheduled Task Local
- Command: Invoke-AtomicTest T1053.005 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1053.005
- Cleanup: Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup

### T1003.001 - Dump LSASS.exe Memory using comsvcs.dll
- Command: Invoke-AtomicTest T1003.001 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1003.001
- Cleanup: Invoke-AtomicTest T1003.001 -TestNumbers 2 -Cleanup

What does this section do?

This Simulation section creates the timeline you will reference when hunting through Splunk. Recording exact timestamps lets you filter out all noise before your tests and focus only on attacker-generated events.

In real incident response, a timeline of known-bad activity is the anchor for the entire investigation.

Replace each [timestamp] with the actual time you ran that command.
Save the file.

✔️ Awesome, I've got everything!

Great. Double check you have saved your report file with the Simulation section filled in.

ⓧ I'd like to double check the full code

Here is what your full report should look like at this point:

# Investigation Report - Attack Chain Detection

## Date
[Date]

## Lab Environment Description
[Description]

## Objective
[Objective]

## MITRE ATT&CK Techniques Covered
- T1059.001
- T1053.005
- T1003.001

## Simulation

### T1059.001 - PowerShell Command Execution
- Command: Invoke-AtomicTest T1059.001 -TestNumbers 19
- Timestamp: [timestamp]
- ATT&CK Technique: T1059.001

### T1053.005 - Scheduled Task Local
- Command: Invoke-AtomicTest T1053.005 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1053.005
- Cleanup: Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup

### T1003.001 - Dump LSASS.exe Memory using comsvcs.dll
- Command: Invoke-AtomicTest T1003.001 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1003.001
- Cleanup: Invoke-AtomicTest T1003.001 -TestNumbers 2 -Cleanup

Your attack chain is complete and documented. The telemetry is sitting in Splunk, waiting for you to find it. Next up, you will hunt through that telemetry and identify the exact evidence each attack left behind.

Hunt Through Splunk Telemetry

Your attack simulation is complete. Now you switch roles from attacker to defender.

In this step, you will query Splunk to find the Sysmon telemetry each attack left behind. The goal is to identify the exact fields and values that reveal attacker behaviour so you can turn them into detection rules in the next step.

In this step, get ready to:

Hunt for PowerShell execution evidence (T1059.001).
Hunt for Scheduled Task creation evidence (T1053.005).
Hunt for LSASS credential dumping evidence (T1003.001).

Set your time range to filter out old events

Your baseline timestamp from Step 1 marks the boundary between old noise and the fresh attack telemetry you generated. Setting your search time range to start at that timestamp ensures you only see events from your simulation.

In Splunk Web, click the time range picker to the right of the search bar.
Select Date & Time Range.
Choose Since and enter your baseline timestamp (the time you noted at the end of Step 1).
Click Apply.

Why set a custom time range?

Your Splunk instance ingests Sysmon logs continuously. Without a time boundary, your hunt queries would return every PowerShell execution and scheduled task ever logged. Filtering to events after your baseline timestamp isolates just the attack telemetry you generated minutes ago.

Hunt for PowerShell execution evidence

The first technique you simulated was T1059.001. Sysmon captures process creation as Event ID 1, which records the image path, command-line arguments, and the parent process that spawned it.

Search for the PowerShell execution event by pasting this SPL query into the Splunk search bar and clicking the search button:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\powershell.exe" | table _time Image CommandLine ParentImage User | sort -_time

What does this query do?

`EventCode=1` filters to Sysmon Process Create events only. `Image="*\\powershell.exe"` matches any event where the new process is PowerShell, regardless of the full path.

The table command selects the five most useful fields for investigation. CommandLine shows exactly what the attacker typed. ParentImage reveals what process launched PowerShell.

Locate the event generated by your Atomic Red Team test. You should see at least one row where Image ends in powershell.exe and CommandLine contains the test command.
Note the CommandLine value, the ParentImage (what launched PowerShell), and the _time timestamp.

No results returned?

Confirm your time range covers the period when you ran the attacks. If you set a custom time range that is too narrow, expand it to the last hour.

Double check the sourcetype is exactly XmlWinEventLog:Microsoft-Windows-Sysmon/Operational. A typo here returns zero results silently.

Help me troubleshoot why my Splunk search for PowerShell events returns no results. I have Sysmon logging on a Windows VM forwarding to Splunk on Ubuntu.

Hunt for Scheduled Task creation evidence

The second technique (T1053.005) used schtasks.exe to create a persistence mechanism. Sysmon Event ID 1 also captures this because creating a scheduled task launches the schtasks.exe process.

Search for the Scheduled Task creation event by pasting this query into the Splunk search bar:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\schtasks.exe" CommandLine="*Create*" | table _time Image CommandLine ParentImage User | sort -_time

What does this query do?

`Image="*\\schtasks.exe"` filters to events where the Scheduled Tasks utility ran. CommandLine="*Create*" narrows further to only task-creation actions, filtering out task queries or deletions.

The CommandLine field is especially valuable here because it contains the task name, the scheduled time, and the command the task would execute.

Locate the event showing schtasks.exe with the /Create flag and the task name spawn in the CommandLine.
Note the full CommandLine (including the scheduled time and the command it would execute) and the ParentImage.

Still seeing zero events for schtasks?

Remember you ran cleanup (Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup) which deleted the task. The cleanup removes the task itself but does not erase the Sysmon log of its creation. If you see no events, check that CommandLine is capitalized as Create with a capital C in your search.

Help me find my Scheduled Task creation event in Splunk

Hunt for LSASS credential dumping evidence

The final technique (T1003.001) accessed LSASS process memory to dump credentials. Unlike the first two hunts, this one uses Sysmon Event ID 10 (Process Access) instead of Event ID 1. Event ID 10 captures when one process opens a handle to another process.

Search for the LSASS memory access event by pasting this query into the Splunk search bar:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe" | table _time SourceImage TargetImage GrantedAccess CallTrace | sort -_time

What does this query do?

`EventCode=10` filters to Sysmon Process Access events. TargetImage="*\\lsass.exe" matches any process that opened a handle to LSASS (the Local Security Authority Subsystem Service that stores credentials in memory).

The key detection fields here are GrantedAccess (a hex value indicating the level of access requested) and CallTrace (the chain of DLLs involved in the access call). Together these reveal whether the access was a legitimate system operation or a credential dump.

Locate the event showing access to lsass.exe. You may see multiple rows. Look for the one where SourceImage is not a system process like svchost.exe or csrss.exe.
Note the SourceImage (what accessed LSASS), the GrantedAccess value (look for 0x1fffff or 0x1438), and the CallTrace (look for dbgcore.dll or dbghelp.dll).

Why are GrantedAccess and CallTrace so important?

Many legitimate system processes access LSASS. The GrantedAccess value tells you how much access was requested. Values like 0x1fffff (full access) or 0x1438 are far more permissive than normal system operations require.

The CallTrace showing dbgcore.dll or dbghelp.dll indicates a memory-dumping operation was used. Legitimate services rarely involve debug DLLs when touching LSASS.

Too many LSASS access events?

System processes like svchost.exe and csrss.exe access LSASS regularly. Focus on rows where SourceImage is rundll32.exe or another unexpected process, and where CallTrace includes debug DLLs.

Help me identify the malicious LSASS access event among legitimate system events

Document your findings in the investigation report

You now have concrete evidence for all three techniques. Recording your findings while they are fresh creates the analysis trail that makes your report interview-ready.

Open your Investigation Report - Attack Chain Detection document.
Add a ## Findings section below the Simulation section.
For each technique (T1059.001, T1053.005, T1003.001), record: the search query you used, the key field values you found, which fields are most useful for detection, and what would distinguish this activity from normal operations.

What makes good detection rationale?

For each finding, ask yourself: would a legitimate user or process produce the same telemetry? For T1059.001, normal admin scripts also run PowerShell. The difference is suspicious flags like -enc or Invoke- patterns.

For T1053.005, IT teams create scheduled tasks too. The difference is unfamiliar task names or tasks created by unexpected parent processes. For T1003.001, the GrantedAccess and CallTrace values separate credential dumps from routine system access.

Your Findings section should look similar to this structure:

## Findings

### T1059.001 - PowerShell Execution
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\powershell.exe" | table _time Image CommandLine ParentImage User | sort -_time
- CommandLine: [value]
- ParentImage: [value]
- Timestamp: [value]
- Key fields: Image, CommandLine, ParentImage
- Detection rationale: [notes]

### T1053.005 - Scheduled Task Creation
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\schtasks.exe" CommandLine="*Create*" | table _time Image CommandLine ParentImage User | sort -_time
- CommandLine: [value including /Create and task name spawn]
- ParentImage: [value]
- Timestamp: [value]
- Key fields: Image, CommandLine
- Detection rationale: [notes]

### T1003.001 - LSASS Credential Dumping
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe" | table _time SourceImage TargetImage GrantedAccess CallTrace | sort -_time
- SourceImage: [value]
- GrantedAccess: [value e.g. 0x1fffff]
- CallTrace: [value including dbgcore.dll or dbghelp.dll]
- Key fields: SourceImage, GrantedAccess, CallTrace
- Detection rationale: [notes]

Fill in the bracketed placeholders with the actual values from your Splunk search results.
For each detection rationale, write 1-2 sentences explaining what distinguishes the malicious activity from normal operations on a Windows machine.
Save your report.

✔️ Awesome, I've got everything!

Great. Double check you have saved your report with all three Findings subsections filled in.

ⓧ I'd like to double check the full report

Your full report should look like this at the end of this step (with your actual values replacing the bracketed placeholders):

# Investigation Report - Attack Chain Detection

## Date
[Date]

## Lab Environment Description
[Description]

## Objective
[Objective]

## MITRE ATT&CK Techniques Covered
- T1059.001
- T1053.005
- T1003.001

## Simulation

### T1059.001 - PowerShell Command Execution
- Command: Invoke-AtomicTest T1059.001 -TestNumbers 19
- Timestamp: [timestamp]
- ATT&CK Technique: T1059.001

### T1053.005 - Scheduled Task Local
- Command: Invoke-AtomicTest T1053.005 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1053.005
- Cleanup: Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup

### T1003.001 - Dump LSASS.exe Memory using comsvcs.dll
- Command: Invoke-AtomicTest T1003.001 -TestNumbers 2
- Timestamp: [timestamp]
- ATT&CK Technique: T1003.001
- Cleanup: Invoke-AtomicTest T1003.001 -TestNumbers 2 -Cleanup

## Findings

### T1059.001 - PowerShell Execution
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\powershell.exe" | table _time Image CommandLine ParentImage User | sort -_time
- CommandLine: [value]
- ParentImage: [value]
- Timestamp: [value]
- Key fields: Image, CommandLine, ParentImage
- Detection rationale: [notes]

### T1053.005 - Scheduled Task Creation
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\schtasks.exe" CommandLine="*Create*" | table _time Image CommandLine ParentImage User | sort -_time
- CommandLine: [value including /Create and task name spawn]
- ParentImage: [value]
- Timestamp: [value]
- Key fields: Image, CommandLine
- Detection rationale: [notes]

### T1003.001 - LSASS Credential Dumping
- Search used: index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe" | table _time SourceImage TargetImage GrantedAccess CallTrace | sort -_time
- SourceImage: [value]
- GrantedAccess: [value e.g. 0x1fffff]
- CallTrace: [value including dbgcore.dll or dbghelp.dll]
- Key fields: SourceImage, GrantedAccess, CallTrace
- Detection rationale: [notes]

You have now traced all three stages of the attack chain through raw telemetry. You know exactly which Sysmon Event IDs captured each technique and which fields contain the evidence. Next up, you will turn these hunt queries into proper detection rules that could fire automatically in a production SOC.

Write SPL Detection Rules

Your hunt queries confirmed that each attack technique leaves distinct traces in Sysmon telemetry. You know exactly which fields and values reveal malicious behaviour.

Now you will transform those ad-hoc queries into formal SPL detection rules. These rules can run on a schedule, alert your SOC team when suspicious activity occurs, and serve as the backbone of your detection coverage. Each rule targets one MITRE ATT&CK technique and includes logic to reduce false positives.

In this step, get ready to:

Write and save an SPL detection rule for suspicious PowerShell execution (T1059.001).
Write and save an SPL detection rule for Scheduled Task creation (T1053.005).
Write and save an SPL detection rule for LSASS credential dumping (T1003.001).

Write the PowerShell execution detection rule

The first rule targets T1059.001. Your hunt query found PowerShell executions, but a production detection rule needs to filter for patterns commonly associated with malicious use rather than firing on every single PowerShell invocation.

In Splunk Web, click Search & Reporting in the Apps bar to open a new search.
Paste the following SPL into the search bar and click the green search button to run it:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\powershell.exe" (CommandLine="*-enc*" OR CommandLine="*-nop*" OR CommandLine="*IEX*" OR CommandLine="*DownloadString*" OR CommandLine="*Invoke-*")
| stats count min(_time) as firstTime max(_time) as lastTime by Image CommandLine ParentImage User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

What does this rule detect?

This rule fires only when PowerShell is launched with flags commonly associated with malicious activity. It looks for encoded commands (-enc), no-profile execution (-nop), in-memory execution (IEX), download cradles (DownloadString), and invoke patterns (Invoke-).

The stats command groups results by key fields so you see each unique combination of command line, parent process, and user. The eval strftime lines convert timestamps into human-readable format for your analysts.

Confirm the search returns results from your earlier attack simulation. You should see at least one row showing powershell.exe with command-line arguments matching the Atomic Red Team test.
Click Save As in the toolbar above the search bar.
Select Report.
In the Title field, enter ATT&CK T1059.001 - Suspicious PowerShell Execution.
Click Save.

Search returns no results?

Check your time range picker. Set it to All time or a range that covers when you ran the Atomic Red Team tests in the previous step.
Verify the sourcetype matches your Sysmon configuration. Some setups use a slightly different sourcetype string.
Confirm Sysmon is still forwarding logs by running a broad search for index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" | head 5.

Help me troubleshoot why my Splunk SPL detection rule for PowerShell T1059.001 returns no results even though I ran the Atomic Red Team test.

Write the Scheduled Task detection rule

The second rule targets T1053.005. Attackers frequently use schtasks.exe to establish persistence by creating scheduled tasks that survive reboots.

Click Search in the Apps bar to start a new search.
Paste the following SPL into the search bar and run it:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\schtasks.exe" CommandLine="*/Create*"
| stats count min(_time) as firstTime max(_time) as lastTime by Image CommandLine ParentImage User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

What does this rule detect?

This rule fires whenever schtasks.exe runs with the /Create flag. Any new scheduled task created via the command line generates an alert. This gives your SOC team visibility into persistence attempts.

The grouping by ParentImage is important because it reveals what process spawned the task creation. A scheduled task created by powershell.exe is far more suspicious than one created by a legitimate installer.

Confirm the search returns results showing schtasks.exe with /Create and the task name spawn from your earlier simulation.
Click Save As, then select Report.
In the Title field, enter ATT&CK T1053.005 - Scheduled Task Creation.
Click Save.

Don't see the scheduled task event?

Remember you ran cleanup after the T1053.005 test. The cleanup removes the task, but the Sysmon log of its creation remains. The event should still appear.
Double-check the CommandLine filter uses */Create* with a leading wildcard. The full path includes a forward slash before Create.

Help me figure out why my Splunk search for schtasks.exe scheduled task creation is not returning results from my Atomic Red Team T1053.005 test.

Write the LSASS credential dumping detection rule

The third rule is the most complex. It targets T1003.001 by detecting processes that access LSASS memory with suspicious access masks and call traces. This rule also excludes legitimate system processes to reduce noise.

Click Search in the Apps bar to start a new search.
Paste the following SPL into the search bar and run it:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe" GrantedAccess IN ("0x1038","0x1438","0x143a","0x1fffff") CallTrace IN ("*dbgcore.dll*","*dbghelp.dll*","*ntdll.dll*","*kernelbase.dll*")
NOT SourceImage IN ("*\\svchost.exe","*\\csrss.exe","*\\wininit.exe","*\\lsass.exe")
| stats count min(_time) as firstTime max(_time) as lastTime by SourceImage TargetImage GrantedAccess CallTrace User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

What makes this rule effective?

This rule layers multiple detection signals together. The GrantedAccess values (0x1038, 0x1438, 0x143a, 0x1fffff) represent memory access permissions that credential dumping tools request.

The CallTrace filter checks for DLLs involved in memory dumping operations (dbgcore.dll, dbghelp.dll). The NOT SourceImage clause excludes known legitimate system processes like svchost.exe and csrss.exe that routinely access LSASS for normal operations.

Confirm the search returns results showing a process accessing lsass.exe with a suspicious GrantedAccess value from your earlier comsvcs.dll test.
Click Save As, then select Report.
In the Title field, enter ATT&CK T1003.001 - Potential Credential Dumping via LSASS Access.
Click Save.

Now validate that all three rules fire against fresh attack telemetry.

Switch to your Windows VM and open PowerShell as Administrator.
Re-run all three Atomic Red Team tests by running these commands:

Invoke-AtomicTest T1059.001 -TestNumbers 19
Invoke-AtomicTest T1053.005 -TestNumbers 2
Invoke-AtomicTest T1003.001 -TestNumbers 2

Wait 30 seconds for logs to forward to Splunk.
Return to Splunk Web on your Ubuntu VM.
Click Reports in the Apps bar.
Click on each of your three saved reports to run them. Confirm each one returns new results matching your fresh attacks.
Clean up the T1053.005 and T1003.001 tests on the Windows VM by running:

Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup
Invoke-AtomicTest T1003.001 -TestNumbers 2 -Cleanup

One or more rules did not return new results?

Make sure you set the time range to cover the last 15 minutes when running the saved report. The default time range may not include your fresh tests.
For the LSASS rule (T1003.001), confirm you ran PowerShell as Administrator. The comsvcs.dll dump requires elevation and will fail silently without it.
Check that the Splunk forwarder on Windows is still active. Run Get-Service SplunkForwarder on the Windows VM to confirm it shows a Running status.

Help me troubleshoot why my saved SPL detection rules are not returning results after I re-ran the Atomic Red Team tests for validation.

Finally, save each rule as a local file and update your investigation report.

Save each SPL query to a local text file with the filenames attack_t1059_001_suspicious_powershell.spl, attack_t1053_005_scheduled_task_creation.spl, and attack_t1003_001_lsass_credential_dumping.spl. These serve as portable backups of your detection logic.
Open your investigation report and add a ## Detection Development section. For each rule, document: the rule name, the full SPL query, the ATT&CK technique it maps to, the detection logic rationale (why these specific fields and values), known false positives, and recommended response actions.

What to include for false positives and response actions

For the PowerShell rule, legitimate admin scripts and configuration management tools (like SCCM) may trigger detections. The recommended response is to investigate the ParentImage and correlate with change management records.

For the Scheduled Task rule, software installers and Windows Update routinely create tasks. Investigate whether the parent process and task command are expected. For the LSASS rule, antivirus and security scanning tools may access LSASS. Correlate SourceImage with your approved security tooling list.

✔️ Awesome, I've got everything!

Great. Make sure you have saved all three reports in Splunk and all three local .spl files.

ⓧ I'd like to double check the full code

Here are the three complete SPL detection rules for comparison.

attack_t1059_001_suspicious_powershell.spl:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\powershell.exe" (CommandLine="*-enc*" OR CommandLine="*-nop*" OR CommandLine="*IEX*" OR CommandLine="*DownloadString*" OR CommandLine="*Invoke-*")
| stats count min(_time) as firstTime max(_time) as lastTime by Image CommandLine ParentImage User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

attack_t1053_005_scheduled_task_creation.spl:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\schtasks.exe" CommandLine="*/Create*"
| stats count min(_time) as firstTime max(_time) as lastTime by Image CommandLine ParentImage User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

attack_t1003_001_lsass_credential_dumping.spl:

index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe" GrantedAccess IN ("0x1038","0x1438","0x143a","0x1fffff") CallTrace IN ("*dbgcore.dll*","*dbghelp.dll*","*ntdll.dll*","*kernelbase.dll*")
NOT SourceImage IN ("*\\svchost.exe","*\\csrss.exe","*\\wininit.exe","*\\lsass.exe")
| stats count min(_time) as firstTime max(_time) as lastTime by SourceImage TargetImage GrantedAccess CallTrace User Computer
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S")
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S")
| sort -lastTime

You now have three tested detection rules covering the full attack chain. Next, you will assemble your complete investigation report and prepare it as a portfolio-ready artifact.

Assemble the Investigation Report

You now have three tested detection rules and raw findings scattered across your report. The missing piece is structure. A well-organized investigation report transforms your technical work into a deliverable that hiring managers and SOC leads can evaluate in minutes.

In this step, you will restructure your report into a professional format, add a telemetry mapping table that demonstrates threat-modelling awareness, and practice articulating your detection logic out loud. This is the exact format real SOC teams use for incident reports and detection development documentation.

In this step, get ready to:

Restructure your report with Executive Summary, Environment, and Recommendations sections.
Add a Telemetry Mapping Table linking ATT&CK techniques to Sysmon evidence.
Practice articulating your detection logic for interview readiness.

Write the Executive Summary and Recommendations

Your report currently has findings and detection rules documented, but it is missing the bookend sections that frame your work for a reader. An Executive Summary gives someone the full picture in seconds. Recommendations show you can think beyond detection into operational response.

Open your Investigation Report - Attack Chain Detection.md file.
Restructure the top of your report to match this layout, replacing the Date/Lab Environment/Objective/MITRE ATT&CK Techniques headers with a cleaner structure:

# Investigation Report - Attack Chain Detection

## Executive Summary
[1-2 sentences summarizing what you simulated, what telemetry you found, and that you authored 3 detection rules]

## Environment
[Your lab setup: Ubuntu VM running Splunk, Windows VM with Sysmon and Atomic Red Team installed, network configuration between them]

## Attack Simulation
[Move your existing Simulation content here - timeline of commands with ATT&CK mappings]

## Detection Development
[Keep your existing Detection Development content - each rule with rationale, false positives, response actions]

## Findings and Analysis
[Move your existing Findings content here - add which Sysmon Event IDs were relevant per technique and why]

What changed in the structure?

The original header section (Date, Lab Environment, Objective, MITRE ATT&CK Techniques) was a working template. The final report uses a professional structure: Executive Summary up front for quick reading, Environment for reproducibility, then the technical sections.

Your Simulation section becomes Attack Simulation, and your Findings section becomes Findings and Analysis. The content stays the same. You are reorganizing, not rewriting.

Write your Executive Summary. Keep it to 1-2 sentences covering: what you simulated (a 3-stage attack chain), what you found (telemetry evidence in Sysmon logs), and what you built (3 SPL detection rules mapped to MITRE ATT&CK).
Now add a Recommendations section at the bottom of your report:

## Recommendations
- Deploy all three detection rules as real-time alerts in Splunk with appropriate throttling (e.g. once per host per hour)
- Integrate alerts with a SOAR platform or ticketing system for automated triage
- Schedule weekly tuning reviews to adjust false positive filters based on environment baselines
- Layer these detections with additional data sources (Windows Security Event Log, EDR telemetry) for higher-fidelity alerting
- Create a response playbook for each detection: what an analyst should investigate, which systems to isolate, and escalation criteria

What makes good Recommendations?

Recommendations show you understand the operational side of detection engineering. You are not just writing queries. You are thinking about alert fatigue, analyst workflow, and how to turn a detection into an actionable response.

Customize these recommendations based on your own observations. If you noticed a lot of noise in your PowerShell rule, mention specific tuning strategies.

Save your file after adding both sections.

Add the Telemetry Mapping Table

A telemetry mapping table connects the dots between attacker behaviour and your detection capability. It shows an interviewer that you understand not just what you detected, but which log sources captured it, what specific values matter, and how an attacker could evade your rules.

Add a new section called Telemetry Mapping Table below your Findings and Analysis section. Copy this table structure into your report:

## Telemetry Mapping Table
| ATT&CK Technique | Sysmon Event ID | Key Fields | Malicious Indicator Values | Potential Evasion |
|---|---|---|---|---|
| T1059.001 | 1 | Image, CommandLine, ParentImage | -enc, -nop, IEX, DownloadString, Invoke- | Obfuscation, renamed binary |
| T1053.005 | 1 | Image, CommandLine | schtasks.exe /Create | COM-based task creation, WMI |
| T1003.001 | 10 | TargetImage, GrantedAccess, CallTrace | 0x1038/0x1438/0x1fffff, dbgcore.dll/dbghelp.dll | Different access masks, direct syscalls |

Why include evasion techniques?

The Potential Evasion column is what separates a junior detection from a mature one. For example, your T1059.001 rule looks for powershell.exe by image name. An attacker could rename the binary to bypass that check. Naming this gap shows you are already thinking about the next iteration of your rule.

For T1003.001, "direct syscalls" means an attacker could bypass the standard Windows API and call kernel functions directly, which would not generate the same CallTrace values your rule looks for.

Save your file.
Review the table and confirm each row matches what you observed during your hunts in Step 3. If you noticed additional key fields or indicator values, add them.

Expand the evasion column

If you want to go deeper, research one evasion technique per row and add a sentence explaining how you would detect the evasion. For example, for renamed PowerShell binaries, you could detect by OriginalFileName field instead of Image path.

Review your report for interview readiness

A portfolio artifact only works if you can explain it under pressure. Interviewers will ask you to walk through your detection logic, justify your field choices, and describe how you would handle false positives. Practicing out loud before the interview is the difference between a confident answer and a stumbling one.

Read through your complete report from top to bottom. Confirm every section is filled in with real content from your simulation and analysis.
For each detection rule, practice answering these questions out loud:

What does this rule detect, in one sentence?
Why did you choose these specific field values (for example, why 0x1438 and 0x1fffff for the LSASS rule's GrantedAccess)?
What would a false positive look like, and how would you tune the rule to reduce it?
If this rule fires at 3 AM, what are your first three investigation steps?

Why practice out loud?

Reading silently and speaking are different skills. When you explain detection logic out loud, you quickly find the spots where your understanding is thin. If you stumble on why dbgcore.dll matters in the CallTrace, that is exactly the gap to fill before an interview.

Save your final report.

Record yourself

Use your phone to record a 2-minute walkthrough of one detection rule. Play it back and listen for filler words, vague explanations, or spots where you lose confidence. This is free interview prep.

✔️ Awesome, I've got everything!

Great. Make sure your report is saved with all sections complete.

ⓧ I'd like to double check the full code

Here is the complete report structure you should have at the end of this step:

# Investigation Report - Attack Chain Detection

## Executive Summary
[1-2 sentences on what was done and found]

## Environment
[Lab setup description]

## Attack Simulation
[Timeline of commands with ATT&CK mappings]

## Detection Development
[Each rule with rationale, false positives, response actions]

## Findings and Analysis
[Sysmon Event IDs and telemetry per technique]

## Telemetry Mapping Table
| ATT&CK Technique | Sysmon Event ID | Key Fields | Malicious Indicator Values | Potential Evasion |
|---|---|---|---|---|
| T1059.001 | 1 | Image, CommandLine, ParentImage | -enc, -nop, IEX, DownloadString, Invoke- | Obfuscation, renamed binary |
| T1053.005 | 1 | Image, CommandLine | schtasks.exe /Create | COM-based task creation, WMI |
| T1003.001 | 10 | TargetImage, GrantedAccess, CallTrace | 0x1038/0x1438/0x1fffff, dbgcore.dll/dbghelp.dll | Different access masks, direct syscalls |

## Recommendations
[How a SOC would operationalize these rules]

Secret mission

Write a Sigma Rule

Your SPL detection rules work great in Splunk. But what happens when your team also runs Microsoft Sentinel or Elastic? Translate your most complex detection into Sigma, the vendor-agnostic format that lets SOC teams share detection logic across any SIEM.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on your existing home lab with Splunk Free, so there are no ongoing costs.

Resources you used:

3 saved SPL detection rules in Splunk (ATT&CK T1059.001, ATT&CK T1053.005, ATT&CK T1003.001).
Investigation report file (Investigation Report - Attack Chain Detection.md).
Sigma rule file (sigma_lsass_credential_dumping.yml).

Keep everything running

No action needed. Choose this if you plan to continue building on these detection rules or want to use them as a reference for future projects.

Your 3 saved searches remain in Splunk and can be re-run or refined at any time.
Your investigation report and Sigma rule stay wherever you saved them on disk.
Your Windows VM snapshot is still available if you want to re-simulate attacks later.

Pause - I'll come back to this later

Shut down your VMs to free up host machine resources while keeping everything intact for later.

Shut down your Windows VM (do not delete the snapshot).
Shut down your Ubuntu VM running Splunk.
Your saved searches, report, and Sigma rule will all be there when you start the VMs back up.

Delete - I don't want to use this again

Remove all project resources to start fresh. This does not delete your VMs or pre-existing tools.

Delete the saved searches from Splunk. In Splunk Web, go to Settings > Searches, reports, and alerts. Find each of the three saved searches (ATT&CK T1059.001 - Suspicious PowerShell Execution, ATT&CK T1053.005 - Scheduled Task Creation, ATT&CK T1003.001 - Potential Credential Dumping via LSASS Access), click Edit > Delete for each one.
Delete your investigation report and Sigma rule files. If they are on your Ubuntu VM, run:

rm "Investigation Report - Attack Chain Detection.md"
rm sigma_lsass_credential_dumping.yml

If you saved any .spl files locally, delete those as well:

rm attack_t1059_001_suspicious_powershell.spl
rm attack_t1053_005_scheduled_task_creation.spl
rm attack_t1003_001_lsass_credential_dumping.spl

Restore your Windows VM to the clean snapshot you started from. This removes any residual artifacts from the Atomic Red Team simulations.

Nice Work!

You just built a detection engineering portfolio piece from the ground up. You simulated a realistic attack chain, hunted through the telemetry it produced, and wrote production-quality detection rules with a documented investigation report to back them up.

You've learned how to:

Simulate a 3-stage attack chain (Execution, Persistence, Credential Access) using Atomic Red Team and trace attacker behaviour through Sysmon telemetry in Splunk.
Author tested SPL detection rules mapped to MITRE ATT&CK techniques (T1059.001, T1053.005, T1003.001) with documented detection logic rationale and false positive considerations.
Produce a portfolio-ready investigation report documenting your methodology, findings, telemetry mappings, and recommendations for operationalizing your rules in a SOC.
Secret Mission: Write a Sigma rule demonstrating vendor-agnostic detection engineering skills.

Ready to quiz yourself?