Build a SOC Monitoring Lab with Wazuh

Deploy a Wazuh SIEM, monitor your Windows endpoint with Sysmon, and triage alerts.

Introduction

30 Second Summary

Every company with a network has a team watching for security threats around the clock. These analysts work in a Security Operations Center, scanning dashboards and deciding in real time whether an alert is a genuine attack or harmless noise.

In this project, you will build your own SOC lab right on your laptop. You will deploy a real SIEM on a virtual machine, connect your Windows machine as a monitored endpoint, and investigate a suspicious alert like a Tier 1 analyst.

What You'll Build

You run a reconnaissance command on your Windows machine, watch the alert appear on your Wazuh dashboard in real time, and triage it like a Tier 1 SOC analyst with a documented investigation write-up ready for GitHub.

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

  • A live Wazuh dashboard where you watch security alerts stream in from your Windows machine in real time.
  • Sysmon running on your endpoint, capturing detailed process, network, and file activity mapped to MITRE ATT&CK techniques.
  • A completed SOC investigation write-up documenting your alert details, verdict, impact assessment, and recommendations for your GitHub portfolio.
  • Secret Mission: Write a custom Wazuh detection rule that fires on a specific MITRE ATT&CK technique.

Are there any prerequisites?

This project assumes you have CompTIA Security+ level knowledge or an equivalent understanding of security fundamentals.

You also need VirtualBox already installed on your Windows 10 machine with at least 16 GB of RAM, since the Wazuh server VM needs 8 GB to run.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your career.

Set Up the Wazuh SIEM Server

Every Security Operations Center runs on a SIEM. It collects logs from every device on the network, detects suspicious patterns, and surfaces alerts for analysts to investigate.

In this step, you will deploy Wazuh on an Ubuntu Server virtual machine inside VirtualBox. This gives you the platform that the rest of the project connects to.

In this step, get ready to:
  • Create an Ubuntu Server 24.04 VM in VirtualBox.
  • Install Wazuh 4.14 on the VM using the quickstart installer.
  • Access the Wazuh dashboard from your Windows browser.
Download the Ubuntu Server ISO

Before you can create the VM, you need the operating system installer file. Ubuntu Server 24.04 LTS is a free download (about 3.2 GB).

  • Open your browser and go to ubuntu.com/download/server.
  • Click Download 24.04.4 LTS to download the ISO file.
  • Save the file somewhere easy to find, like your Downloads folder.

What is an ISO file?

An ISO file is a disk image that contains the entire operating system installer. VirtualBox can mount it as a virtual DVD drive, so the VM boots from it as if you inserted a physical disc.

Create the WazuhServer VM in VirtualBox

Now you will create a virtual machine with enough resources to run Wazuh. The quickstart installer requires 4 vCPUs, 8 GB RAM, and 50 GB storage for a deployment with up to 25 agents.

  • Press the Windows key to open your search bar.
  • Type VirtualBox and press Enter to open VirtualBox Manager.
  • Click New in the toolbar to launch the Create Virtual Machine wizard.
  • In the Name field, type WazuhServer.
  • In the ISO Image field, click the dropdown and browse to the Ubuntu Server ISO file you just downloaded.
  • VirtualBox will auto-detect the OS type. Confirm Type is set to Linux and Version is set to Ubuntu (64-bit).
  • Check the Skip Unattended Installation checkbox so you can walk through the installer yourself.
  • Click Next.

Why skip unattended installation?

Unattended installation lets VirtualBox auto-configure the OS, but it can skip networking prompts you need for this project. Doing it manually ensures you set up the username, password, and network correctly.

  • On the Hardware page, set Base Memory to 8192 MB.
  • Set Processors to 4.
  • Click Next.
  • On the Virtual Hard Disk page, make sure Create a Virtual Hard Disk Now is selected.
  • Set the Disk Size to 50 GB.
  • Leave Pre-Allocate Full Size unchecked so the disk grows dynamically.
  • Click Next.
  • On the Summary page, review your settings, then click Finish.

Your new WazuhServer VM now appears in the VirtualBox machine list on the left.

Set the network adapter to Bridged

By default, VirtualBox gives new VMs a NAT network adapter. You need to switch it to Bridged Adapter so the VM gets its own IP address on your home network. This lets your Windows browser reach the Wazuh dashboard directly.

  • Select the WazuhServer VM in the machine list.
  • Click Settings in the toolbar.
  • Click Network in the left panel.
  • In the Attached to dropdown, change NAT to Bridged Adapter.
  • VirtualBox will auto-select a host network interface below the dropdown. Leave the default selection (it picks your active network adapter).
  • Click OK.

What is Bridged Adapter?

Bridged Adapter puts the VM directly on your home or office network, as if it were a separate physical machine plugged into the same router. The VM gets its own IP address from your router's DHCP server, and your Windows host can reach it directly.

NAT mode hides the VM behind the host's IP, which would prevent your browser from reaching the Wazuh dashboard.

Install Ubuntu Server on the VM

With the VM configured, it is time to boot it and install the operating system. The Ubuntu Server installer is text-based (no graphical interface), and you can accept most of the default options.

  • Select the WazuhServer VM and click Start in the toolbar.
  • The VM boots from the Ubuntu ISO. Select your language and press Enter.
  • Select your keyboard layout and press Done.
  • On the install type screen, select the default option and press Done.
  • On the network screen, the installer auto-configures networking via DHCP. Press Done to accept.
  • On the proxy and mirror screens, leave them blank and press Done on each.
  • On the storage screen, leave Use an entire disk checked and press Done.
  • Confirm the storage layout and select Continue when prompted.

Navigate with your keyboard

Ubuntu Server's installer is text-based. Use the arrow keys to move between options, Tab to jump between fields, Space to check/uncheck boxes, and Enter to confirm.

  • On the profile screen, enter a username and password you will remember. Set the server hostname to wazuh-server.
  • On the SSH screen, press Done (you do not need to enable SSH right now).
  • On the featured server snaps screen, press Done without selecting anything.
  • Wait for the installation to complete. This takes a few minutes.
  • When you see Reboot Now, press Enter.
  • If prompted to remove the installation medium, just press Enter again. VirtualBox handles this automatically.

After the reboot, you should see a text-based login prompt. Log in with the username and password you just created.

Stuck on a blank screen after reboot?

If you see a blank or black screen after the reboot, wait 30 seconds and then press Enter. The login prompt may be hidden behind boot log messages.

If the VM tries to boot from the ISO again instead of the installed system, power off the VM, go to Settings > Storage, and remove the ISO from the virtual optical drive.

Still stuck? Help me troubleshoot my Ubuntu Server VM not booting.

Find the VM's IP address and install Wazuh

Now that Ubuntu is running, you need two things: the VM's IP address (so your Windows browser can reach the dashboard) and the Wazuh platform itself.

  • Find the VM's IP address by running this command:
ip addr show

How to read the output

Look for the inet line under your network interface (usually enp0s3 or similar). The IP address looks like 192.168.1.105. Ignore the 127.0.0.1 line. That is the loopback address and not reachable from your Windows host.

  • Write down your VM's IP address. You will use it throughout the rest of this project.
  • Run the Wazuh quickstart installer by running this command:
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

What does this command do?

This command downloads the Wazuh quickstart script and runs it with administrator privileges. The -a flag tells it to install everything in one go: the Wazuh indexer (stores log data), the Wazuh server (processes events and triggers alerts), and the Wazuh dashboard (the web interface you will use).

This is an all-in-one deployment designed for labs with up to 25 agents. It takes several minutes to complete.

This takes 5-10 minutes

The installer downloads and configures multiple components. Let it run without interrupting. You will know it is done when it prints a summary with the admin password.

  • When the installer finishes, it prints the admin username and password. Copy or write down these credentials immediately. You will need them to log into the dashboard.

Save your Wazuh credentials now

The installer displays the admin password only once. If you lose it, you will need to reset it manually. Write it down or take a photo of the terminal output before continuing.

Installation failed or timed out?

Make sure the VM has internet access. Run ping -c 3 google.com to test connectivity. If the ping fails, your Bridged Adapter may not be connected to the correct host network interface. Power off the VM, go to Settings > Network, and try selecting a different host interface from the dropdown under Bridged Adapter.

Still failing? Help me troubleshoot the Wazuh quickstart installer.

Access the Wazuh dashboard from your Windows browser

The Wazuh server is running. Before you run the next command, do you think your Windows browser will be able to reach the dashboard without any warnings?

  • On your Windows machine, open your browser.
  • Navigate to the following URL, replacing the IP with your VM's address:
https://[[VM_IP="your VM's IP address"]]

Your browser will show a security warning about the certificate. This is expected because the Wazuh quickstart uses a self-signed certificate.

  • Click Advanced (or equivalent), then click Proceed or Continue to accept the certificate and load the page.
  • Log in with the username admin and the password the installer printed.

Why the certificate warning?

Wazuh's quickstart installer generates a self-signed SSL certificate to encrypt traffic between your browser and the dashboard. Your browser does not trust it because it was not issued by a recognized certificate authority. For a lab environment, this is perfectly safe to accept.

You should now see the Wazuh dashboard with zero agents connected. This confirms the SIEM is installed and the dashboard is reachable from your Windows host.

Can't reach the dashboard?

Double-check you are using https:// (not http://). The Wazuh dashboard only responds on HTTPS.

Make sure the VM is running and you are using the correct IP address. Go back to the VM terminal and run ip addr show again to confirm the IP.

If the page times out, your Windows firewall may be blocking the connection, or the Bridged Adapter is not on the same subnet as your host. Try temporarily disabling your Windows firewall to test.

Still stuck? Help me connect to the Wazuh dashboard from my Windows browser.

Your SIEM server is live. Next up, you will install Sysmon on your Windows machine and connect it to Wazuh so the dashboard starts filling with real security events.

Install Sysmon and Connect Your Windows Endpoint

Your Wazuh SIEM is up and running, but right now it has no eyes. The dashboard shows zero agents because nothing is sending data to it yet.

In this step, you will install Sysmon on your Windows machine to generate detailed security telemetry. Then you will install the Wazuh agent to pipe that telemetry into your SIEM. By the end, your dashboard will show a live connection with real events streaming in.

In this step, get ready to:
  • Install Sysmon with a MITRE ATT&CK-mapped configuration on your Windows machine.
  • Install the Wazuh agent and connect it to your SIEM server.
  • Verify your Windows endpoint appears as an active agent with events streaming into the dashboard.
Download and install Sysmon on your Windows machine

Sysmon (System Monitor) is a Windows service from Microsoft's Sysinternals suite that logs detailed security events. It records which processes start, which network connections are made, and which files change. Without it, Windows only provides basic event logs that miss most of the detail a SOC analyst needs.

What is Sysmon?

Sysmon is a free monitoring tool that hooks into the Windows kernel to capture granular events like process creation, network connections, and file changes. It writes these events to a dedicated event log that security tools can read.

Sysmon is read-only. It observes what happens on your machine but never blocks or modifies anything. It is safe to run on your daily-use computer.

  • Download Sysmon.zip from the Sysinternals website by opening this link in your browser:
https://download.sysinternals.com/files/Sysmon.zip
  • Once the download completes, open your Downloads folder in File Explorer.
  • Right-click Sysmon.zip and select Extract All....
  • Click Extract to extract the files into a Sysmon folder inside your Downloads folder.

You should see files including Sysmon.exe, Sysmon64.exe, and Eula.txt in the extracted folder.

Sysmon needs a configuration file that tells it which events to capture. You will use the sysmon-modular config by Olaf Hartong, which maps events to MITRE ATT&CK technique IDs. This means every event Sysmon captures is already tagged with the attack technique it relates to.

  • Open an elevated PowerShell window. Press the Windows key, type PowerShell, right-click Windows PowerShell, and select Run as administrator.
  • Click Yes on the User Account Control prompt.
  • Navigate to the extracted Sysmon folder by running this command:
cd ~\Downloads\Sysmon
  • Download the sysmon-modular configuration file by running this command:
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/olafhartong/sysmon-modular/master/sysmonconfig.xml" -OutFile sysmonconfig.xml

What does this command do?

Invoke-WebRequest downloads a file from the internet, similar to how a browser downloads a file when you click a link.

The file sysmonconfig.xml comes from the sysmon-modular GitHub repository. It contains hundreds of rules that tell Sysmon which events to log and tags each rule with the MITRE ATT&CK technique it detects.

  • Confirm the config file downloaded by running:
ls sysmonconfig.xml

You should see sysmonconfig.xml listed with its file size.

  • Install Sysmon with the config file by running this command:
.\sysmon64.exe -accepteula -i sysmonconfig.xml

What does this command do?

  • sysmon64.exe is the 64-bit Sysmon installer and service binary.
  • -accepteula automatically accepts the license agreement so the install runs without prompts.
  • -i sysmonconfig.xml installs Sysmon as a Windows service and loads the MITRE ATT&CK-mapped configuration.

You should see output confirming that Sysmon was installed and the service started successfully. No reboot is required.

Seeing an access denied error?

  • Make sure you opened PowerShell with Run as administrator. Sysmon installs a kernel-level driver and requires elevated privileges.
  • Confirm you ran cd ~\Downloads\Sysmon first so PowerShell can find the sysmon64.exe file.
  • Still stuck? Help me troubleshoot the Sysmon installation error.
Download and install the Wazuh agent

Sysmon is now generating events, but those events are sitting locally on your machine. The Wazuh agent is the software that reads those events and forwards them to your SIEM server over an encrypted connection.

  • Download the Wazuh agent installer by running this command in your elevated PowerShell window:
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.7-1.msi" -OutFile wazuh-agent-4.14.7-1.msi

What is this downloading?

This downloads wazuh-agent-4.14.7-1.msi, the official Wazuh agent installer for Windows. The agent uses about 35 MB of RAM on average and runs quietly in the background.

  • Confirm the download completed by running:
ls wazuh-agent-4.14.7-1.msi

You should see the wazuh-agent-4.14.7-1.msi file listed.

  • Install the Wazuh agent and point it at your SIEM server by running this command:
msiexec.exe /i .\wazuh-agent-4.14.7-1.msi /q WAZUH_MANAGER="[[VM_IP="your Wazuh server VM IP address"]]"

What does this command do?

  • msiexec.exe is the Windows installer program that runs .msi packages.
  • /q runs a silent (quiet) installation with no GUI prompts.
  • WAZUH_MANAGER tells the agent which server to connect to. Replace this with the IP address you noted in Step 1 when you ran ip addr show on your Ubuntu VM.

The command runs silently. After a few seconds, the agent files are installed to C:\Program Files (x86)\ossec-agent.

  • Start the Wazuh agent service by running this command:
Start-Service wazuhsvc
  • Confirm the service is running by running:
Get-Service wazuhsvc

You should see the service listed with a status of Running.

Service not starting?

  • Double-check that you replaced the IP in the install command with your actual VM IP address. If the IP was wrong, re-run the msiexec.exe command with the correct IP.
  • Make sure your WazuhServer VM is still running in VirtualBox. The agent needs to reach the server to complete its registration.
  • Confirm you are running PowerShell as administrator. The agent service requires elevated privileges to start.
  • Still stuck? Help me troubleshoot the Wazuh agent service not starting.
Verify your agent is connected and streaming events

Both Sysmon and the Wazuh agent are running on your machine. Now you need to confirm that the SIEM is actually receiving data.

Before you check, what do you predict the Wazuh dashboard will show now? Do you think your agent will appear immediately, or will it take a few minutes?

  • Switch back to your browser where the Wazuh dashboard is open.
  • Click the hamburger menu (☰) in the upper left corner of the dashboard.
  • Click Agents management.
  • Click Summary.

Your Windows machine should appear in the agents list with a status of Active. This may take up to a minute after starting the service.

  • Click on your agent's name to open its detail view.
  • Browse the Security Events section. You should already see events streaming in from your Windows machine.

What are these events?

The events you see are real security telemetry from your own machine. Sysmon is capturing process creations, network connections, and file changes on your Windows host. The Wazuh agent is collecting those Sysmon events (along with standard Windows security logs) and forwarding them to the SIEM in real time.

Each event includes a rule ID, a severity level, and a description. This is exactly what a SOC analyst sees on a real monitoring dashboard.

Agent not showing as Active?

  • Wait a full minute and refresh the page. The agent sometimes takes a moment to register.
  • Confirm your VM's network adapter is set to Bridged Adapter in VirtualBox. NAT mode blocks direct communication between your Windows host and the VM.
  • Check that your Windows firewall is not blocking outbound traffic to the VM's IP address on port 1514 (the Wazuh agent communication port).
  • Still stuck? Help me figure out why my Wazuh agent is not connecting.

Your SIEM now has eyes. Real security events from your Windows machine are flowing into the Wazuh dashboard in real time. Next up, you will explore what normal activity looks like and then trigger something suspicious to see how the SIEM reacts.

Explore Your Baseline and Trigger a Suspicious Event

Your SIEM is live and your endpoint is reporting in. A dashboard full of events means nothing if you cannot tell the difference between normal activity and something suspicious.

In this step, you will study what normal activity looks like on your machine, then deliberately trigger reconnaissance commands that real attackers use. You will watch the alerts appear in the Wazuh dashboard in real time.

In this step, get ready to:
  • Explore baseline security events in the Wazuh dashboard and Windows Event Viewer.
  • Trigger reconnaissance commands that mimic attacker behavior on your Windows machine.
  • Observe the resulting alerts with rule IDs and severity levels in the dashboard.
Explore your baseline security events

Before you can spot a threat, you need to know what normal activity looks like. Windows constantly generates events from services starting, programs launching, and scheduled tasks running on their timers.

  • Switch back to the Wazuh dashboard in your browser.
  • Click on your Windows agent in the agents list.
  • Navigate to the Security Events section.

You should see a stream of events from your Windows machine. Most of these are routine: Windows services starting up, background programs checking for updates, and system processes running on schedule.

  • Scan through the event list and look at the rule descriptions.
  • Identify at least three different types of normal activity (for example, Windows service events, user logon events, or process creation for system programs like svchost.exe).

Why does baseline matter?

A SOC analyst who only sees alerts for the first time during an incident has no frame of reference. When you know that svchost.exe launches dozens of times during a normal boot, you can instantly dismiss those events and focus on the ones that stand out.

Now compare what Wazuh shows with the raw events on your machine. Event Viewer lets you see the same Sysmon events before they are processed by the SIEM.

  • On your Windows machine, press the Windows key to open your search bar.
  • Type eventvwr and press Enter to open Event Viewer.

Event Viewer organizes every log Windows records by category. You need to drill down to the Sysmon-specific logs.

  • In the left sidebar, expand Applications and Services Logs.
  • Expand Microsoft.
  • Expand Windows.
  • Expand Sysmon.
  • Click Operational.

You should see a list of Sysmon events including process creation, network connection, and file change entries. These are the same events your Wazuh agent is collecting and forwarding to the SIEM.

Two views of the same telemetry

Event Viewer shows you raw Sysmon events stored on the local machine. Wazuh collects these same events, applies its detection rules, and presents them as security alerts with severity levels and descriptions in the dashboard.

This is the difference between raw logs and actionable intelligence. A raw event says "a process started." A Wazuh alert says "a suspicious process started, and here is why it matters."

Not seeing Sysmon events in Event Viewer?

Make sure you expanded Applications and Services Logs, not Windows Logs. These are two separate tree sections in the left sidebar. Sysmon lives under the Applications and Services Logs tree.

If the Sysmon folder does not appear at all, confirm Sysmon is still running. Open an elevated PowerShell and run Get-Service Sysmon64. The status should say Running.

Help me find Sysmon events in Event Viewer.

Trigger suspicious reconnaissance commands

Now that you know what normal looks like, it is time to create something abnormal. Attackers who gain access to a machine typically start by running reconnaissance commands to learn about the system and its users.

  • On your Windows machine, press the Windows key to open your search bar.
  • Type cmd.
  • Select Run as administrator to open an elevated Command Prompt.
  • Run this command to simulate user discovery, a common first step for attackers:
whoami /all

You should see a detailed output listing your username, group memberships, and privileges. An attacker uses this information to understand what account they have compromised and what permissions it has.

  • Now run this command to enumerate all user accounts on the machine:
net user

This lists every user account on the machine. An attacker uses this to find other accounts to target for lateral movement across the network.

What are MITRE ATT&CK techniques?

Both commands you just ran map to specific MITRE ATT&CK techniques. whoami /all maps to T1033 (System Owner/User Discovery). net user maps to T1087 (Account Discovery).

These are standardized IDs that security tools use to classify attacker behavior. When you see a technique ID in an alert, you can look it up in the MITRE ATT&CK framework to understand exactly what kind of attack it represents.

Find your reconnaissance alerts in the dashboard

Those commands have been captured by Sysmon and forwarded to your SIEM through the Wazuh agent. Before you check, predict what you will find. Do you think Wazuh flagged these commands as suspicious, or did they blend in with the normal activity?

  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Security Events for your Windows agent.
  • Sort the events by timestamp to see the newest entries first.
  • Search or filter for whoami to narrow down the results.

You should see process creation events (Sysmon Event ID 1) showing whoami.exe with the full whoami /all command line. Wazuh has matched this event to a rule ID and assigned it a severity level.

  • Clear the filter and search for net user to find the other reconnaissance command.

Both commands appear as Sysmon Event ID 1 (ProcessCreate) entries. Each event includes the full command line, the parent process that launched it, and the user who ran it. Wazuh's rule engine matched each event to a rule ID, gave it a description, and assigned a severity level.

What do these alert fields tell you?

The rule.id is a unique number identifying which Wazuh detection rule fired. The rule.description tells you what the rule detected in plain language. The rule.level is the severity on a scale from 0 to 15, where higher numbers mean greater concern.

In the next step, you will take one of these alerts and investigate it end to end, the way a real SOC analyst handles an incident ticket.

Not seeing alerts for your commands?

Events may take up to a minute to appear in the dashboard. Wait 60 seconds and refresh the page.

Check that your time range filter in the dashboard includes the current time. If the filter is set to a narrow window, it may exclude your recent events. Try setting it to the last 1 hour.

If you still see no results, make sure you ran the commands from an elevated Command Prompt (right-click, Run as administrator). Then try your search again.

Help me find my reconnaissance alerts in the Wazuh dashboard.

You now have a working baseline and have seen your SIEM detect suspicious activity in real time. Next up, you will take one of these alerts and investigate it from start to finish, just like a Tier 1 SOC analyst working through an incident ticket.

Investigate an Alert Like a SOC Analyst

Your SIEM is no longer a silent dashboard. Reconnaissance alerts from your Windows endpoint are streaming in, complete with rule IDs and severity levels.

Seeing alerts is not the same as investigating them. A SOC analyst triages each alert by asking structured questions: what happened, is it malicious, what is the impact, and what should be done. In this step, you will pick one of your reconnaissance alerts, examine it in detail, and document your findings in the same format SOC teams use for real incident tickets.

In this step, get ready to:
  • Select a reconnaissance alert in the Wazuh dashboard and examine every field an analyst would review.
  • Create a structured investigation write-up document with five SOC investigation sections.
  • Fill in the write-up with real alert data, reach a verdict, and recommend next steps.
Select and examine a reconnaissance alert

Every SOC investigation starts the same way: you pick an alert and read every field the SIEM recorded. The goal is to understand exactly what happened before you decide whether it is malicious.

  • Return to the Wazuh dashboard in your browser.
  • Navigate to the Security Events section for your Windows agent.
  • Find one of the alerts triggered by the reconnaissance commands you ran in the previous step (whoami.exe or net.exe).
  • Click on the alert to expand its detail view.

You should see the full event record with all the fields that make an investigation possible.

  • Locate each of the following fields in the alert detail and note them down (on paper or in a temporary note):

Why do these fields matter?

Each field answers a key question in the investigation. The rule ID and description tell you what detection logic fired. The severity level tells you how urgent it is.

The command line shows exactly what was executed. The parent process reveals how the command was launched. Together, these fields tell the full story of what happened on the endpoint.

  • Take a screenshot of this alert detail view with all the fields visible.
  • Save the screenshot to your Desktop. You will include it in your investigation document shortly.

Can't find the reconnaissance alerts?

Use the search bar in the Security Events section to filter for whoami or net.exe. If nothing appears, make sure the time range at the top of the dashboard covers when you ran the commands in the previous step.

Help me find my reconnaissance alerts in the Wazuh dashboard

Create the investigation write-up template

SOC teams document every investigation in a structured format. This makes it easy for other analysts to review findings and for managers to track incident trends. You will create the same format now.

  • Press the Windows key to open your search bar.
  • Type Notepad and press Enter to open it.
  • Paste the following investigation template into the empty Notepad window:
# SOC Investigation Write-Up

## Alert Details
- Rule ID:
- Rule Description:
- Severity Level:
- Timestamp:
- Endpoint (Agent Name):

## Context
- Process Image Path:
- Command Line:
- Parent Process:
- User:
- Is this expected behavior?

## Verdict
(True positive, false positive, or benign true positive? Explain your reasoning.)

## Impact
(What could an attacker learn from this activity? What is the risk?)

## Recommendation
(What would you do next? Escalate, monitor, contain, or close with notes?)

What are the five sections?

  • Alert Details records the basic facts: which rule fired, how severe it is, when it happened, and which endpoint triggered it.
  • Context digs into the process-level data: what ran, how it was launched, and who launched it.
  • Verdict is your analyst judgment. Is this a true positive, a false positive, or a benign true positive?
  • Impact assesses what damage this activity could cause if it were malicious.
  • Recommendation prescribes next steps: escalate, monitor, contain, or close with notes.
  • Click File, then Save As.
  • Navigate to your Desktop in the left sidebar.
  • Change the Save as type dropdown from Text Documents (*.txt) to All Files (*.*).
  • In the File name field, type investigation-writeup.md.
  • Click Save.
  • Check your Desktop. You should see investigation-writeup.md listed as a new file.

File saved as investigation-writeup.md.txt?

This happens when the Save as type dropdown is still set to Text Documents (*.txt). Delete the file, go back to Notepad, and repeat the Save As steps. Make sure you select All Files (*.*) before clicking Save.

Help me save my file as .md instead of .txt in Notepad

Fill in each section with real alert data

Now comes the analyst work. You will use the notes and screenshot from your alert examination to populate every section of the write-up with real data from your lab.

  • In Notepad, start with the Alert Details section. Fill in the rule ID, rule description, severity level, timestamp, and endpoint name using the exact values you noted from the Wazuh alert detail view.
  • Fill in the Context section with the process image path, command line, parent process, and user from the Sysmon event data.
  • For the "Is this expected behavior?" field, describe whether you would expect to see this command on a corporate endpoint.

What is a benign true positive?

A true positive means the rule correctly detected the activity it was designed to catch. A false positive means the rule fired on something harmless that it mistook for a threat.

A benign true positive is a real match (the detection logic worked correctly) but the activity was authorized or harmless. Your reconnaissance commands are a perfect example. The rule correctly flagged discovery behavior, but you ran the commands intentionally in a lab.

  • In the Verdict section, write benign true positive. Explain that the rule correctly identified reconnaissance activity, but you executed the commands intentionally as part of a controlled lab exercise.
  • In the Impact section, describe what an attacker could learn from this activity. Think about what information whoami /all or net user reveals: usernames, group memberships, privilege levels, or other accounts on the system.
  • In the Recommendation section, write what you would do next if this were a production environment. Consider whether you would escalate to a senior analyst, monitor for additional reconnaissance, contain the endpoint, or close the ticket with notes.
  • Add a final section at the bottom of the document titled ## Screenshot. Note that your alert detail screenshot is saved on the Desktop alongside this file.
  • Save the file by pressing Ctrl+S.

Before you check your work, scroll through your completed document. Do all five sections have real data from your alert? Is your verdict supported by a clear explanation?

✔️ Awesome, I've got everything!

Great. Make sure investigation-writeup.md is saved on your Desktop with all five sections filled in and your screenshot file alongside it.

ⓧ I'd like to double check the full template

Your completed document should contain all five sections from the original template, now filled in with your own alert data. Scroll through your file and confirm each section is present in this order:

  • Alert Details with rule ID, rule description, severity level, timestamp, and endpoint name.
  • Context with process image path, command line, parent process, user, and expected behavior assessment.
  • Verdict stating benign true positive with an explanation of why.
  • Impact describing what an attacker could learn from the reconnaissance activity.
  • Recommendation with the next steps you would take in a production environment.
  • Screenshot section referencing your saved alert detail screenshot.

Why this format matters for your portfolio

This five-section structure is the same format SOC teams use for real incident tickets. Hiring managers reviewing your portfolio want to see that you can move beyond "I saw an alert" to structured investigative thinking.

The verdict and recommendation sections are where you stand out. They show you can make a judgment call and prescribe action, which is the core of a Tier 1 SOC analyst's job.

Secret mission

Write a Custom Wazuh Detection Rule

Any analyst can triage existing alerts. But writing your own detection rules is what separates a Tier 1 analyst who follows playbooks from one who can improve the SOC's detection capability. In this secret mission, you will SSH into your Wazuh server, write a custom rule that detects obfuscated PowerShell execution, and watch it fire in real time.

Clean Up Your Resources

Clean Up Your Resources

Everything in this project runs locally on your machine. There are no cloud services or ongoing costs to worry about.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • WazuhServer VM running Wazuh 4.14 in VirtualBox.
  • Sysmon service running on your Windows 10 host.
  • Wazuh agent service running on your Windows 10 host.

Keep everything running

No action needed. Choose this if you are still actively building detection rules and adding to your investigation write-ups.

  • Your SOC lab stays active and continues collecting live telemetry from your Windows machine.
  • The WazuhServer VM uses about 8 GB of RAM while running. Close other applications if your machine feels slow.
  • Sysmon and the Wazuh agent continue running on Windows with negligible resource impact.
  • Your investigation-writeup.md file stays on your Desktop for future reference.

Pause - I'll come back to this later

Shut down the VirtualBox VM to free up RAM. Sysmon and the Wazuh agent continue running on Windows with negligible resource impact.

  • Open VirtualBox Manager.
  • Right-click the WazuhServer VM in the machine list.
  • Select Close, then Power Off.
  • When you are ready to come back, start the VM again. The Wazuh agent on your Windows machine reconnects automatically within a minute.

Delete - I don't want to use this again

Remove all project resources from your machine and start fresh. Save your investigation-writeup.md somewhere safe before deleting if you want to keep your portfolio write-up.

Remove Sysmon from your Windows machine by opening an elevated PowerShell, navigating to the folder where you extracted Sysmon, and running this command:

.\sysmon64.exe -u

Remove the Wazuh agent through Windows Settings.

  • Open Settings on your Windows machine.
  • Select Apps.
  • Find Wazuh Agent in the list of installed apps.
  • Click Uninstall and confirm the removal when prompted.

Delete the WazuhServer VM from VirtualBox. The VM must be powered off before you can remove it.

  • Open VirtualBox Manager.
  • Right-click the WazuhServer VM in the machine list and select Remove.
  • In the confirmation dialog, click Delete all files to permanently remove the VM and its virtual disk.

Finally, delete any leftover downloaded files from your Downloads folder.

  • Delete the Sysmon.zip archive and the extracted Sysmon folder.
  • Delete the sysmonconfig.xml file.
  • Delete the wazuh-agent-4.14.7-1.msi installer.
  • Delete the Ubuntu Server ISO file if you no longer need it.

Nice Work!

Nice Work!

You just built a working Security Operations Center monitoring lab from scratch, using the same open-source tools real SOC teams deploy every day.

You've learned how to:

  • Deploy a production-grade Wazuh SIEM on Ubuntu Server and use it to collect, index, and analyze security alerts from a live endpoint.
  • Install Sysmon with a MITRE ATT&CK-mapped configuration, connect your Windows endpoint to the SIEM, and verify live telemetry streaming into the dashboard.
  • Triage alerts like a Tier 1 SOC analyst by completing a structured investigation write-up with alert details, context, verdict, impact, and recommendations.
  • Secret Mission: Write a custom Wazuh detection rule that fires on obfuscated PowerShell execution, proving you can improve a SOC's detection capability.

Ready to quiz yourself?