SOC Alert Triage with Wazuh

Triage real security alerts using Sysmon, Wazuh, and MITRE ATT&CK.

Introduction

30 Second Summary

Every day, security teams receive thousands of alerts from their monitoring tools. Most are noise. The skill that separates a real analyst from a dashboard watcher is the ability to quickly decide which alerts demand action and which can be safely ignored.

In this project, you will simulate attacker activity on your own Windows machine, then practice the exact triage workflow that SOC (Security Operations Center) analysts use to separate real threats from false alarms.

What You'll Build

A hands-on SOC triage exercise where you enhance your Wazuh SIEM with Sysmon for deep endpoint visibility, deliberately trigger realistic security events, and then practice the full analyst decision-making workflow on the resulting alerts.

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

  • A fully configured Sysmon + Wazuh integration producing detailed Windows security events from your machine.
  • A queue of 5+ categorized alerts you personally triaged using the Escalate/Investigate/Dismiss/Tune framework.
  • A structured triage report mapping each alert to MITRE ATT&CK techniques with your reasoning documented.
  • Secret Mission: Simulate a coordinated multi-stage attack chain and write an incident narrative connecting individual alerts into one story.

Are there any prerequisites?

This project assumes you already have Wazuh running in Docker with a Windows agent enrolled and active. You also need a Windows machine with at least 16GB of RAM.

Install Sysmon and Configure Wazuh Ingestion

Your Wazuh SIEM is running, but right now it only sees basic Windows event logs (Security, System, Application). That leaves a massive blind spot.

To catch the detailed activity a SOC analyst needs (process creation, network connections, registry changes), you need Sysmon feeding telemetry into Wazuh. In this step, you will install Sysmon and wire it into your Wazuh agent so every event flows into your dashboard.

In this step, get ready to:
  • Install Sysmon v15.2 with a community detection configuration.
  • Configure the Wazuh agent to ingest Sysmon logs.
  • Verify Sysmon events appear in the Wazuh dashboard.
Download and install Sysmon

Sysmon (System Monitor) is a free Microsoft Sysinternals tool that logs deep operating system activity. On its own, Windows only records high-level events. Sysmon adds granular details like the full command line of every new process, which is exactly what a SOC analyst investigates.

  • Open PowerShell as Administrator by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
  • Download the Sysmon ZIP from Microsoft Sysinternals by running this command:
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "$env:USERPROFILE\Desktop\Sysmon.zip"
  • Extract the ZIP to a folder on your Desktop by running:
Expand-Archive -Path "$env:USERPROFILE\Desktop\Sysmon.zip" -DestinationPath "$env:USERPROFILE\Desktop\Sysmon" -Force
  • Download the SwiftOnSecurity Sysmon configuration file by running:
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "$env:USERPROFILE\Desktop\Sysmon\sysmonconfig.xml"

Why use the SwiftOnSecurity configuration?

Sysmon can run with default settings, but the SwiftOnSecurity community configuration is the industry-standard starting point. It filters out noisy benign events and focuses on the activity SOC analysts actually investigate (suspicious process creation, network connections, registry modifications).

  • Navigate into the Sysmon folder and install Sysmon with the configuration by running these commands:
cd "$env:USERPROFILE\Desktop\Sysmon"
.\sysmon64.exe -accepteula -i .\sysmonconfig.xml

What does this command do?

The -accepteula flag skips the license prompt. The -i flag installs Sysmon as a Windows service and kernel driver. The .\sysmonconfig.xml tells Sysmon which events to log based on the SwiftOnSecurity rules.

You should see output confirming that the Sysmon64 service and SysmonDrv driver are installed and started.

  • Verify Sysmon is running by running:
Get-Service Sysmon64

You should see a status of Running next to Sysmon64.

Service not showing as Running?

Make sure you launched PowerShell as Administrator. Sysmon requires elevated privileges to install its kernel driver.

If you see an error about the term not being recognized, ensure you ran cd into the Sysmon folder first. PowerShell needs the .\ prefix to run executables from the current directory.

help me troubleshoot my Sysmon installation

Configure the Wazuh agent to ingest Sysmon logs

Sysmon is now generating events, but your Wazuh agent does not know to collect them yet. You need to tell the agent to monitor the Sysmon event channel.

  • Open the Wazuh agent configuration file in Notepad with administrator privileges by running:
notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"
  • Scroll down to find the <ossec_config> section. You will see existing <localfile> blocks for the default Windows event channels (Security, System, Application).
  • Add the following block below the existing <localfile> entries, but still inside the <ossec_config> tags:
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

What does this configuration do?

The <location> tells the Wazuh agent which Windows Event Channel to monitor. Microsoft-Windows-Sysmon/Operational is where Sysmon writes all of its events.

The <log_format>eventchannel</log_format> tells the agent to use the Windows Event Log API to read these events, which preserves all the structured data fields that make Sysmon so useful for analysis.

  • Save the file in Notepad by pressing Ctrl+S, then close Notepad.
  • Restart the Wazuh agent to apply the new configuration by running:
Restart-Service -Name wazuh

The agent will reconnect to your Wazuh manager and begin forwarding Sysmon events.

Restart command failing?

Make sure your PowerShell session is still running as Administrator. The Wazuh agent service requires elevated privileges to restart.

If you see a permissions error, close your current PowerShell window and open a new one as Administrator.

help me restart the Wazuh agent service on Windows

✔️ Awesome, I've got everything!

Great. Double check you have saved ossec.conf and that the Wazuh agent restarted without errors.

ⓧ I'd like to double check the full code

Your ossec.conf file should now contain this new block somewhere inside <ossec_config>, alongside the existing <localfile> entries for Security, System, and Application:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
Verify the integration in the Wazuh dashboard

The final piece is confirming that Sysmon events actually appear in your Wazuh SIEM. This proves the entire pipeline works: Sysmon captures events, the agent forwards them, and the manager indexes them for analysis.

  • Open your web browser and navigate to https://localhost.
  • Sign in with the default credentials: username admin and password SecretPassword.
  • Your browser may show a certificate warning because Wazuh uses a self-signed certificate. Click Advanced and then proceed to the site.
  • In the left sidebar, click Threat Hunting.
  • In the search bar at the top, type the following filter and press Enter:
data.win.system.providerName: Microsoft-Windows-Sysmon
  • Wait 1-2 minutes if you do not see results immediately. Sysmon events take a moment to propagate through the pipeline.

You should see events appearing with Sysmon as the provider. Look for Event ID 1 entries, which represent process creation events.

What is Event ID 1?

Sysmon Event ID 1 is a Process Create event. Every time any program launches on your machine, Sysmon records the full command line, the parent process, the user account, and a hash of the executable.

This is the single most important event type for a SOC analyst. Most attacker tools (reverse shells, credential dumpers, lateral movement utilities) show up as suspicious process creations.

No Sysmon events in the dashboard?

Confirm the Wazuh agent is connected. In the dashboard, go to Agents and check your Windows agent shows a green Active status.

Double check that ossec.conf has the correct Sysmon channel name: Microsoft-Windows-Sysmon/Operational. A typo here means the agent silently ignores the channel.

If the agent shows Active but no events appear, try restarting the agent one more time with Restart-Service -Name wazuh and wait another minute.

help me troubleshoot why Sysmon events are not showing in my Wazuh dashboard

Your SIEM now has deep endpoint visibility. Next up, you will generate realistic security alerts by simulating attacker techniques on your machine.

Generate Your Alert Queue

Your Wazuh SIEM now has Sysmon integrated, giving it deep visibility into every process, network connection, and registry change on your Windows machine. Now it needs something interesting to look at.

In this step, you'll play the attacker. You'll simulate several techniques from real-world intrusions to fill your alert queue with realistic security alerts that you can triage in the next step.

In this step, get ready to:
  • Simulate brute-force login attempts and registry persistence.
  • Generate suspicious process creation events using encoded commands and scheduled tasks.
  • Verify your alert queue contains at least 5 distinct alerts in the Wazuh dashboard.
Simulate a brute-force indicator

A brute-force attack is when someone tries many passwords against an account in rapid succession. Each failed attempt generates a Windows Security Event 4625 (failed logon). When a SIEM sees multiple 4625 events in a short window, it raises an alert.

  • In your PowerShell window (running as Administrator), generate 6 failed login attempts by running this command:
for ($i=1; $i -le 6; $i++) { net user fakeuser WrongPass /domain 2>$null }

What does this command do?

The for loop runs net user six times with a fake username and wrong password. The /domain flag forces a domain lookup (which fails on a standalone machine). Each iteration generates a Windows Security Event 4625 that Wazuh captures.

The 2>$null at the end suppresses error output in your terminal. The underlying events still get logged to the Windows Security channel regardless.

No output appears in your terminal because errors are suppressed. The events are logged silently in the background.

  • Now simulate a registry modification to mimic persistence. Run this command:
New-ItemProperty -Path "HKLM:\Software\Microsoft\ADs" -Name "NoofAlerts" -Value 2

Why does this trigger an alert?

This command creates a registry key, which Wazuh rule 91843 specifically detects. The rule fires when PowerShell executes New-ItemProperty -Path and maps it to MITRE ATT&CK techniques T1059.001 (PowerShell execution) and T1112 (Modify Registry).

Real attackers modify registry keys to maintain persistence on a system. Even though this particular key is harmless, the pattern is identical to what malware uses.

You should see output confirming the property was created, showing the property name, value, and registry path.

Seeing an access denied error?

The registry modification targets HKLM:\ which requires Administrator privileges. Make sure your PowerShell session is elevated (running as Administrator).

Right-click PowerShell in your taskbar and select Run as Administrator, then try the command again.

Help me fix this access denied error when modifying the registry.

Simulate suspicious process creation

Attackers frequently encode their commands in Base64 to evade simple detection rules. They also create scheduled tasks to ensure their code runs again after a reboot.

  • Run an encoded PowerShell command by executing:
powershell -EncodedCommand UABpAG4AZwAgAGwAbwBjAGEAbABoAG8AcwB0AA==

What is this encoded command?

The Base64 string decodes to Ping localhost in UTF-16LE. It is completely harmless. However, the pattern of using -EncodedCommand triggers Sysmon Event ID 1 (Process Create) with a suspicious encoded command signature.

This maps to MITRE ATT&CK technique T1027 (Obfuscated Files or Information). Real attackers use encoding to hide malicious payloads from static analysis tools.

You should see ping output (replies from 127.0.0.1). This confirms the encoded command executed successfully.

  • Create a scheduled task that mimics attacker persistence by running:
schtasks /create /tn "SuspiciousTask" /tr "cmd.exe /c echo test" /sc once /st 23:59 /f

Why is a scheduled task suspicious?

This creates a one-time scheduled task named SuspiciousTask that runs cmd.exe /c echo test at 23:59. The task itself is harmless, but the act of creating scheduled tasks from a command line maps to MITRE ATT&CK technique T1053.005 (Scheduled Task/Job).

Attackers use scheduled tasks to survive reboots and maintain access to compromised systems. A SOC analyst seeing this pattern would flag it for investigation.

You should see a SUCCESS message confirming the task was created.

Command not recognized?

If schtasks is not recognized, make sure you are running in a standard PowerShell or Command Prompt window (not PowerShell ISE). The schtasks utility is built into Windows and should be available in any elevated terminal.

Help me troubleshoot why schtasks is not recognized in my terminal.

Verify your alert queue in the dashboard

Your simulated events need 1-2 minutes to propagate from the Windows event log through the Wazuh agent to the dashboard.

  • Wait 1-2 minutes for events to propagate.
  • Return to the Wazuh dashboard in your browser.
  • Click Threat Hunting in the left sidebar.
  • In the search bar at the top, type the following filter and press Enter:
rule.level >= 3

What does this filter do?

Wazuh assigns a severity level (0-15) to each alert. Level 0-2 are informational noise. Filtering for rule.level >= 3 removes the low-priority background events and shows only alerts that warrant analyst attention.

You should see a mix of alerts at different severity levels. Look for alerts related to authentication failures, registry modifications, encoded commands, and scheduled task creation.

Not seeing your alerts?

If the Threat Hunting view shows no results after 2 minutes, check the following:

  • Make sure the time picker in the top right corner covers the last 15 minutes.
  • Verify the Wazuh agent is running by opening a new PowerShell window and running Get-Service wazuh. The status should show Running.
  • Remove the filter temporarily to see if any events are flowing at all.

Help me figure out why my Wazuh dashboard isn't showing alerts after running the simulation commands.

Your alert queue is loaded with realistic security events. Next up, you'll put on your analyst hat and triage each alert using the Escalate/Investigate/Dismiss/Tune decision framework.

Triage the Alerts

Your alert queue is populated with real security events from your own machine. Now comes the skill that separates a SOC analyst from someone who just reads logs.

In this step, you will apply a structured decision framework to each alert in your queue. Every alert gets a verdict, and every verdict gets a documented reason.

In this step, get ready to:
  • Learn the Escalate/Investigate/Dismiss/Tune decision framework.
  • Triage at least 5 alerts in your Wazuh dashboard.
  • Document your verdicts with reasoning in a triage notes file.
Learn the four triage verdicts

Every alert that lands in a SOC analyst's queue demands a decision. You cannot leave alerts sitting in limbo.

The industry-standard framework uses four verdicts:

  • ESCALATE means a real threat requiring immediate incident response.
  • INVESTIGATE means the alert is ambiguous and needs more context before you can decide.
  • DISMISS means you have confirmed the alert is a false positive in this context.
  • TUNE means the alert fires on a known-benign pattern that should be suppressed in future rules.

Why these four and not just "good" or "bad"?

Binary decisions (malicious vs benign) break down in production. Most alerts sit in a gray zone where you need more information.

The four-verdict model gives you a clear next action for each category. Escalate triggers the incident playbook. Investigate queues the alert for deeper analysis. Dismiss closes the ticket. Tune feeds back into detection engineering to reduce noise.

Now open your first alert to see what information you have to work with.

  • Return to the Wazuh dashboard at https://localhost.
  • Navigate to Threat Hunting in the left sidebar.
  • Click on any alert row to expand it.

When you expand an alert, examine these key fields:

  • rule.description tells you what the rule detected in plain language.
  • rule.level shows the severity (higher number means more critical).
  • rule.mitre maps the alert to a MITRE ATT&CK technique, if one applies.
  • The source data shows the process name, user, command line, and timestamp.

What does the JSON tab show?

Click the JSON tab on an expanded alert to see the full raw event. This includes every field Sysmon captured: the parent process, file hashes, network connections, and registry targets.

The JSON view is where experienced analysts find the details that tip a verdict from Investigate to Escalate.

Triage each alert in your queue

Work through your alert queue one alert at a time. For each alert, read the fields, think about what caused it, and assign a verdict.

Here is how to think through the three main alert types you generated:

Encoded PowerShell command
  • Find the alert related to the encoded PowerShell execution (look for -EncodedCommand in the command line field).
  • Check what the encoded command actually does. You know it decodes to Ping localhost because you ran it yourself.
  • Assign verdict: DISMISS in your lab context (you caused it, and the payload is harmless).

How would a real SOC handle this?

In production, an encoded PowerShell command would be INVESTIGATE because base64-encoded commands are a common evasion technique. This maps to MITRE technique T1027 (Obfuscated Files or Information).

Attackers encode commands specifically to bypass signature-based detection and make log review harder. Seeing one in the wild should always prompt deeper analysis.

Registry modification (rule 91843)
  • Find the alert with rule ID 91843 (PowerShell registry modification).
  • Note the MITRE mapping: T1059.001 (Command and Scripting Interpreter: PowerShell) and T1112 (Modify Registry).
  • Assign verdict: INVESTIGATE. Registry persistence is a key indicator of compromise. An analyst would need to determine whether the modification is authorized before clearing it.

Why is registry modification a red flag?

Attackers modify registry keys to survive reboots. Common persistence locations include HKCU\Software\Microsoft\Windows\CurrentVersion\Run and service-related keys.

Even though your test wrote to HKLM:\Software\Microsoft\ADs (a benign path), the detection pattern is the same one that catches real persistence techniques.

Authentication failures
  • Find alerts related to Windows Security Event 4625 (failed logon attempts).
  • Note the pattern: multiple failures from the same source in quick succession. This maps to MITRE technique T1110 (Brute Force).
  • Assign verdict: ESCALATE if the source IP is external or unknown. Assign TUNE if you can confirm the source is a known misconfigured service account on your own machine.

Check additional alerts too

Your queue likely contains more than just these three types. Look for the scheduled task creation alert (mapped to T1053.005) and any Sysmon process creation events from normal Windows activity.

Normal Windows activity alerts are great candidates for DISMISS or TUNE verdicts. Triaging benign alerts builds the same muscle memory as triaging real threats.

Record your triage findings

For each alert you triaged, you need a written record. In a real SOC, this goes into the ticketing system. For this exercise, you will use a simple markdown file.

  • Open any text editor (Notepad, VS Code, or your preferred editor).
  • Create a new file and save it as triage-notes.md anywhere convenient on your Desktop.
  • Use the following template to record each alert:
# Triage Notes

## Alert 1
- **Rule ID:** [number from rule.id field]
- **Description:** [text from rule.description]
- **MITRE Technique:** [technique ID, e.g. T1112]
- **Verdict:** [ESCALATE / INVESTIGATE / DISMISS / TUNE]
- **Reasoning:** [one sentence explaining why you chose this verdict]

## Alert 2
- **Rule ID:**
- **Description:**
- **MITRE Technique:**
- **Verdict:**
- **Reasoning:**

## Alert 3
- **Rule ID:**
- **Description:**
- **MITRE Technique:**
- **Verdict:**
- **Reasoning:**

## Alert 4
- **Rule ID:**
- **Description:**
- **MITRE Technique:**
- **Verdict:**
- **Reasoning:**

## Alert 5
- **Rule ID:**
- **Description:**
- **MITRE Technique:**
- **Verdict:**
- **Reasoning:**

What goes in each field?

  • Rule ID is the numeric identifier from the rule.id field in the expanded alert (e.g. 91843).
  • Description is the human-readable text from rule.description.
  • MITRE Technique is the technique ID shown in rule.mitre (e.g. T1112). Some alerts may not have a MITRE mapping. Write "None" for those.
  • Verdict is your decision using the four-verdict framework.
  • Reasoning is one sentence explaining WHY. This is the most important field because it proves you can think, not just click.
  • Fill in the template for at least 5 alerts from your queue.
  • Save triage-notes.md.

Not sure which verdict to pick?

Ask yourself: "If I did NOT generate this alert myself, what would I do?" If the answer is "call someone senior immediately," that is ESCALATE. If the answer is "I need to check something else first," that is INVESTIGATE.

There is no single correct answer for every alert. What matters is that your reasoning is sound and defensible.

Help me decide on a triage verdict for my alerts.

✔️ I've triaged at least 5 alerts

Excellent work. Make sure your triage-notes.md file is saved with all five entries filled in.

ⓧ I'd like to double check the full template

Here is a completed example for reference. Your actual verdicts may differ based on what you see in your specific alerts.

# Triage Notes

## Alert 1 - Encoded PowerShell
- **Rule ID:** 91007
- **Description:** PowerShell executed with encoded command
- **MITRE Technique:** T1027
- **Verdict:** DISMISS
- **Reasoning:** I generated this alert myself; the decoded payload is "Ping localhost" which is harmless.

## Alert 2 - Registry Modification
- **Rule ID:** 91843
- **Description:** PowerShell executed New-ItemProperty -Path
- **MITRE Technique:** T1059.001, T1112
- **Verdict:** INVESTIGATE
- **Reasoning:** Registry modification is a persistence indicator; requires confirmation of whether the change is authorized.

## Alert 3 - Authentication Failures
- **Rule ID:** 60122
- **Description:** Multiple Windows logon failures
- **MITRE Technique:** T1110
- **Verdict:** TUNE
- **Reasoning:** Source is localhost (my own test); in production from external IP this would be ESCALATE.

## Alert 4 - Scheduled Task Creation
- **Rule ID:** 91820
- **Description:** Sysmon - Scheduled task created
- **MITRE Technique:** T1053.005
- **Verdict:** INVESTIGATE
- **Reasoning:** Scheduled tasks are a common persistence mechanism; need to verify legitimacy.

## Alert 5 - Normal Process Creation
- **Rule ID:** 61603
- **Description:** Sysmon Event 1 - Process creation
- **MITRE Technique:** None
- **Verdict:** DISMISS
- **Reasoning:** Standard Windows system process with expected parent; no suspicious indicators.

Your rule IDs may differ

The exact rule IDs depend on your Wazuh version and which events fired. The important thing is that you identified the alert type, applied a verdict, and wrote defensible reasoning.

You have just done what a Tier 1 SOC analyst does hundreds of times per shift: read an alert, make a decision, document the reasoning. Next up, you will map your findings to the full MITRE ATT&CK matrix and write a structured triage report.

Map to MITRE ATT&CK and Write Your Triage Report

You have a queue of triaged alerts with verdicts and reasoning. Now it's time to speak the shared language that every SOC team uses to communicate about threats.

MITRE ATT&CK is the industry-standard framework that maps adversary behavior into named tactics and techniques. In this step, you'll use Wazuh's built-in MITRE module to visualize which attack phases your alerts cover, then write a structured triage report that any security team could read and act on.

In this step, get ready to:
  • Explore the MITRE ATT&CK module in the Wazuh dashboard.
  • Write a structured triage report for your most interesting alert.
  • Review your verdict ratios against real-world SOC benchmarks.
Explore the MITRE ATT&CK module

The MITRE ATT&CK module inside Wazuh automatically maps your alerts to the ATT&CK matrix. This gives you a visual overview of which tactics and techniques your simulated activity triggered.

  • Switch back to the Wazuh dashboard in your browser.
  • Click MITRE ATT&CK in the left sidebar menu to open the MITRE ATT&CK module.
  • Select the Events tab. This shows all alerts that Wazuh has mapped to specific MITRE technique IDs.
  • Select the Framework tab. Here you can see the available MITRE tactics and their associated techniques detected in your environment.

What does the Framework tab show?

The Framework tab provides a high-level overview of the tactics and techniques occurring on endpoints monitored by your Wazuh server. It lets you filter and search for specific tactics and techniques, and view which endpoints the events occurred on.

Look for tactics like Execution, Persistence, and Discovery. These map directly to the attack stages you simulated in the previous step. Clicking any technique shows the related events in your environment.

  • Click on one or two techniques you recognize from your triage notes (for example, T1059.001 for PowerShell or T1112 for Modify Registry).
  • Note which tactics your alerts cover. You should see activity across Execution, Persistence, and possibly Discovery.

Use the Framework tab for pattern recognition

In a real SOC, gaps in the ATT&CK matrix tell you where your detection coverage is weak. Clusters of activity across multiple tactics in a short timeframe suggest a coordinated attack rather than isolated noise.

Write a structured triage report

SOC teams document their triage findings in a standard format that any analyst can pick up and continue investigating. You'll now write a report for your most interesting alert using the exact structure used in production ticketing systems.

  • Choose the most interesting alert from your triage notes. The registry modification (rule 91843) or the encoded PowerShell command are good candidates because they have rich MITRE mappings.
  • Open that alert in the Wazuh dashboard and expand its full JSON details by clicking on it in the Threat Hunting view.
  • Open your triage-notes.md file and add a new section for your structured report using the following template:
## Triage Report - [Alert Rule ID]

### Alert Summary
# One sentence describing what happened

### Evidence
# Key fields from the alert JSON
- Process: 
- User: 
- Timestamp: 
- Command: 

### MITRE Mapping
# Technique ID + Tactic
- Technique: 
- Tactic: 

### Verdict
# Your decision: Escalate / Investigate / Dismiss / Tune

### Reasoning
# Why you decided this (2-3 sentences)

### Recommended Next Steps
# What you would do in a production environment (2-3 actions)

What goes in each section?

  • Alert Summary: A single sentence a manager could read and understand. Example: "PowerShell executed a registry modification on the local machine."
  • Evidence: Copy the exact values from the alert JSON. These are your forensic breadcrumbs.
  • MITRE Mapping: The technique ID (like T1112) and the tactic it falls under (like Persistence). This lets other analysts immediately understand the attack phase.
  • Recommended Next Steps: Actions a production team would take. For example: "Check if the registry key persists after reboot," "Review other activity from this user in the last 24 hours," or "Isolate the endpoint pending investigation."
  • Fill in each section of the template using the alert details from the Wazuh dashboard.
  • Save your triage-notes.md file.

Not sure what to write for Recommended Next Steps?

Think about what a real analyst would do if this alert appeared on a production server they did not control. Would they isolate the machine? Check for lateral movement? Review authentication logs? The key is naming concrete actions, not vague instructions like "investigate further."

Help me write Recommended Next Steps for my triage report based on the alert I chose.

Review your verdict ratios

The final piece of your triage exercise is stepping back and looking at the big picture. In a production SOC, the distribution of verdicts tells you something important about your detection tuning.

  • Count how many of your triaged alerts fall into each category: Escalate, Investigate, Dismiss, and Tune.
  • Add a summary section to the bottom of your triage-notes.md with your counts and percentages.
## Verdict Summary

- Escalate: X alerts (X%)
- Investigate: X alerts (X%)
- Dismiss: X alerts (X%)
- Tune: X alerts (X%)

## Comparison to Real-SOC Benchmarks
# In a production SOC, typical ratios are:
# - Dismiss/Tune: 60-80%
# - Investigate: 15-30%
# - Escalate: 5-10%

## My Observations
# How do your ratios compare? What does this tell you?

Why do these ratios matter?

In a real SOC, roughly 60-80% of alerts end up as Dismiss or Tune, 15-30% need further Investigation, and only 5-10% get Escalated as real threats. This ratio reflects a fundamental truth: most alerts are noise.

Your job as an analyst is finding the signal in that noise. If your exercise shows 100% Dismiss, your detection rules are too noisy. If everything is Escalate, you may be over-reacting. The ratios build calibration over time.

  • Write 2-3 sentences comparing your ratios to the benchmarks. Note whether your results skew higher on Dismiss (expected, since you generated these alerts yourself) and what that tells you about alert fatigue in real SOCs.
  • Save your triage-notes.md file.

Extra for Experts: Why does alert fatigue matter?

SOC analysts process hundreds of alerts per shift. When 80% of those alerts are false positives, analysts start skimming instead of reading. This is how real attacks slip through. The Tune verdict exists specifically to reduce future noise by suppressing known-benign patterns at the rule level.

Secret mission

Simulate and Narrate a Multi-Stage Attack Chain

In a real SOC, alerts rarely arrive in isolation. Attackers move through stages: they execute code, establish persistence, then explore the network. Your challenge is to simulate a coordinated multi-stage attack on your own machine, then write the incident narrative that connects the dots.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally using Docker and Windows services, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Sysmon64 service installed on your Windows machine (free, no ongoing cost).
  • Scheduled task named SuspiciousTask (created during alert simulation).
  • Registry key at HKCU:\Software\Microsoft\Windows\CurrentVersion\Run named Updater (persistence simulation artifact).
  • Registry key at HKLM:\Software\Microsoft\ADs named NoofAlerts (PowerShell rule trigger artifact).
  • Wazuh Docker stack (pre-existing, uses approximately 2-4GB RAM while running).

Keep everything running

No action needed. Choose this if you are still actively building on this project or plan to continue practicing triage with Sysmon and Wazuh.

  • Sysmon continues generating rich endpoint telemetry in the background.
  • The Wazuh Docker stack keeps collecting and indexing events (uses approximately 2-4GB RAM).
  • The scheduled task SuspiciousTask and registry keys remain as harmless artifacts from your simulation.

Pause - I'll come back to this later

Shut down running processes to free up memory while keeping your files and configuration intact for later.

  • Stop the Wazuh Docker stack by running the following command in the wazuh-docker directory:
docker compose down
  • Sysmon stays installed but stops being collected by Wazuh once the stack is down.
  • Your triage notes and configuration remain untouched.

When you are ready to resume, run docker compose up -d in the same directory to bring Wazuh back online.

Delete - I don't want to use this again

Remove all project resources and start fresh. Run all commands below in PowerShell as Administrator.

  • Delete the scheduled task by running:
schtasks /delete /tn "SuspiciousTask" /f
  • Remove the Updater registry key (persistence artifact) by running:
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Updater"
  • Remove the NoofAlerts registry key by running:
Remove-ItemProperty -Path "HKLM:\Software\Microsoft\ADs" -Name "NoofAlerts"
  • Uninstall Sysmon by running:
sysmon64 -u
  • Stop and remove the Wazuh Docker stack by running the following command in the wazuh-docker directory:
docker compose down -v

What does the -v flag do?

The -v flag removes Docker volumes along with the containers. This deletes all indexed alert data stored by Wazuh.

Skip -v if you want to keep your alert history for reference.

Nice Work!

Nice Work!

You just completed a full SOC analyst triage exercise from scratch. You installed endpoint telemetry, generated realistic attack signals, and made the same judgment calls that Tier 1 analysts make every single day.

Here's what you learned:

  • Installed and configured Sysmon to produce rich endpoint telemetry integrated with your Wazuh SIEM.
  • Generated realistic security alerts by simulating attacker techniques on your own machine.
  • Triaged 5+ alerts using the Escalate/Investigate/Dismiss/Tune framework.
  • Mapped alerts to MITRE ATT&CK techniques and wrote a structured triage report.
  • Secret Mission: Correlated a multi-stage attack chain into a single incident narrative, demonstrating Tier 2 analyst thinking.

Ready to quiz yourself?