Build a SOC Analyst Home Lab

Set up a Wazuh SIEM, detect brute force attacks, and triage alerts like a SOC analyst.

Introduction

30 Second Summary

Every company with a computer network has someone watching for break-in attempts. When a hacker tries thousands of passwords against a login page or runs commands to map out a system they just compromised, a security analyst is the person who spots it, investigates it, and decides whether it is a real threat.

In this project, you will build a fully functional SOC analyst home lab by deploying a Wazuh SIEM server in VirtualBox, connecting your own Windows machine as a monitored endpoint, generating real attack-like activity, and triaging the alerts exactly the way a SOC analyst does on the job.

What You'll Build

By the end, you can open your Wazuh dashboard, point to a brute force alert your machine caught in real time, walk through the raw Windows Event log, name the MITRE ATT&CK technique it maps to, and deliver a confident true positive or false positive verdict.

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

A live SIEM dashboard showing security alerts from your own Windows endpoint, categorized by severity and MITRE ATT&CK technique.
A completed brute force investigation where you generated the attack, read the raw Windows Event logs (Event ID 4625), identified the ATT&CK technique, and made a documented true positive call with evidence.
A contextual triage workflow for ambiguous reconnaissance alerts, where you assess who ran the commands, when, and from where to distinguish legitimate admin activity from post-exploitation enumeration.
Secret Mission: Write a custom detection rule that catches a specific suspicious command pattern Wazuh misses by default.

Are there any prerequisites?

You need a Windows machine with at least 24 GB of RAM (the Wazuh VM uses 8 GB alongside your normal Windows usage). You also need VirtualBox already installed and basic familiarity with the Linux command line.

Before We Start

Before We Start...

Before you set up any infrastructure, let's lock in what you're about to build and why it matters for your SOC analyst career. This is the moment to commit to the goal before your hands touch the keyboard.

Set Up Your Wazuh SIEM Server

A SIEM is the foundation of any SOC analyst's workflow. It collects logs from endpoints, applies detection rules, and surfaces alerts for investigation.

In this step, you will import the pre-built Wazuh OVA into VirtualBox, access the dashboard from your Windows browser, and install the Wazuh agent so your machine starts sending real security events to the server.

In this step, get ready to:

Import the Wazuh 4.14.6 OVA into VirtualBox and configure the VM settings.
Access the Wazuh dashboard from your Windows browser and sign in.
Install the Wazuh agent on your Windows host and confirm it appears as Active.

Import the Wazuh OVA into VirtualBox

You already downloaded the wazuh-4.14.6.ova file. Now you need to import it into VirtualBox so it becomes a runnable virtual machine.

Open VirtualBox.
Click File in the top menu bar.
Click Import Appliance.
Browse to the location where you saved wazuh-4.14.6.ova and select it.
Review the appliance settings, then click Finish (or Import depending on your VirtualBox version) to complete the import.

After the import completes, you should see the Wazuh VM listed in the VirtualBox Manager on the left side.

What is an OVA file?

An OVA is a pre-packaged virtual machine. It contains the operating system (Amazon Linux 2023), all Wazuh server components, and over 3,000 built-in detection rules. Importing it saves you from manually installing and configuring everything.

Configure the VM settings and start it

Before you boot the VM, you need to adjust two settings. The graphics controller must be set to VMSVGA to prevent the display from freezing. The network adapter must use Bridged Adapter so your Windows host and the VM can communicate on the same network.

Select the Wazuh VM in the VirtualBox Manager list.
Click Settings in the toolbar.
Click Display in the left panel.
Set the Graphics Controller dropdown to VMSVGA.
Click Network in the left panel.
Confirm that Attached to is set to Bridged Adapter. If not, select it from the dropdown.
Click OK to save the settings.
Click the green Start arrow in the toolbar to boot the VM.

The VM takes about 30-60 seconds to boot. You will see a login prompt when it is ready.

You should now see a terminal prompt as wazuh-user. The VM is running.

Why Bridged Adapter?

Bridged Adapter puts the VM on the same network as your Windows host. This means your Windows machine can reach the VM's IP address directly, which is essential for the agent to send logs to the server and for you to access the dashboard from your browser.

VM window freezes or goes black?

This happens when the Graphics Controller is not set to VMSVGA. Power off the VM (right-click the VM in the list, select Close, then Power Off), go back to Settings and fix the Display setting before restarting.

help me fix my Wazuh VM display freezing in VirtualBox

Find the VM's IP address and access the dashboard

Now that the VM is running, you need its IP address so you can reach the Wazuh dashboard from your Windows browser.

In the VM terminal, find the IP address by running this command:

ip addr show

Look for the inet line under your network interface (usually eth0 or enp0s3). Note the IP address before the / (for example, 192.168.1.105).

What does ip addr show do?

This command lists all network interfaces on the Linux VM and their assigned IP addresses. Since you set the network to Bridged Adapter, the VM received an IP from your router's DHCP server, on the same subnet as your Windows machine.

Now open the Wazuh dashboard in your Windows browser.

On your Windows machine, open any web browser (Chrome, Edge, Firefox).
Navigate to https:// followed by the VM IP you just noted (for example, https://192.168.1.105).
Your browser will show a certificate warning. This is expected because Wazuh uses a self-signed certificate. Click Advanced, then Continue (or Accept the Risk and Continue in Firefox) to proceed.
Log in with username admin and password admin.

You should see the Wazuh dashboard. It shows zero agents enrolled because you have not connected any endpoints yet.

Why the certificate warning?

The Wazuh OVA ships with a self-signed SSL certificate. Your browser does not trust it because it was not issued by a recognized certificate authority. For a home lab this is perfectly fine. You can safely accept the warning and proceed.

Cannot reach the dashboard?

Make sure your VM's network adapter is set to Bridged Adapter, not NAT. NAT isolates the VM from your host network.

Also confirm the IP address is on the same subnet as your Windows machine (for example, both starting with 192.168.1.x). If the VM shows 10.0.2.15, it is still using NAT.

It may also take a few minutes for the Wazuh services to fully start after booting. Wait 2-3 minutes and try again.

help me access my Wazuh dashboard from my Windows browser

Install the Wazuh agent on your Windows host

The Wazuh server is running, but it has no data to analyze. You need to install an agent on your Windows machine so it starts forwarding security events (login attempts, process creation, system changes) to the server.

In the Wazuh dashboard, click Agents management in the left menu.
Click Summary.
Click Deploy new agent.
Select Windows as the operating system.
Enter the Wazuh server IP address (the VM IP you noted earlier) in the Server address field.
The dashboard generates an install command for you. Copy it, or follow the manual steps below.

Now open PowerShell as Administrator on your Windows machine to install and start the agent.

Press the Windows key to open search.
Type PowerShell, right-click Windows PowerShell, and select Run as administrator.
Navigate to the folder where you downloaded the MSI file (the dashboard's Deploy page triggers a download of wazuh-agent-4.14.6-1.msi).
Install the agent by running this command:

msiexec.exe /i .\wazuh-agent-4.14.6-1.msi /q WAZUH_MANAGER="[[WAZUH_VM_IP="your Wazuh VM IP address"]]"

What does this command do?

This silently installs the Wazuh agent (/q means quiet, no prompts) and tells it which server to report to via the WAZUH_MANAGER parameter. Replace the IP with your Wazuh VM's actual IP address.

Start the agent service by running:

NET START WazuhSvc

You should see a message confirming the service started successfully.

Before you check the dashboard, what do you think you will see under Agents management? Will it still show zero agents, or will your Windows machine appear?

Switch back to the Wazuh dashboard in your browser.
Navigate to Agents management, then Summary.
Your Windows machine should now appear in the agents list with a status of Active.

You now have a working SIEM server with a live endpoint reporting to it. The agent is forwarding Windows Security, System, and Application event logs to Wazuh in real-time.

Agent not showing as Active?

Wait 1-2 minutes and refresh the page. The agent needs a moment to register with the server.

If it still does not appear, confirm the WAZUH_MANAGER IP in your install command matches the IP shown by ip addr show in the VM. A typo in the IP means the agent cannot reach the server.

Also verify the service is running by entering Get-Service WazuhSvc in PowerShell. The status should say Running.

help me troubleshoot my Wazuh agent not connecting to the server

Your SIEM is live and collecting data from your own machine. Next up, you will see what real alerts look like when Wazuh detects activity on your endpoint.

See Your First Live Alerts

Your Wazuh server is running and your Windows agent is connected. But right now, the dashboard is an empty tool. You have not seen what a real alert looks like yet.

In this step, you will open the Threat Hunting module and see live security data flowing from your own machine. This is your first taste of what a SOC analyst's queue looks like: events streaming in, each one tagged with a rule ID, a severity level, and a description of what happened.

In this step, get ready to:

Explore the Threat Hunting dashboard and identify key alert fields.
Generate deliberate activity on your Windows host and watch new alerts appear.

Explore the Threat Hunting dashboard

Threat Hunting is where all alerts land. Every time your agent forwards an event that matches a detection rule, it appears here with metadata that tells you what happened, how severe it is, and where it came from.

In the Wazuh dashboard, click Threat Hunting in the left navigation menu.
You should already see some alerts listed. Wazuh monitors your Windows Security, System, and Application event channels by default, so events start flowing as soon as the agent connects.

What if I don't see any alerts yet?

Give it 1-2 minutes after your agent first connected. The agent batches events before sending them to the server. If the list is still empty, switch back to Agents management > Summary and confirm your agent still shows as Active.

Click on any alert row to expand it.
Inside the expanded alert, identify these fields:

rule.id tells you which detection rule fired.
rule.description is a human-readable summary of what happened.
rule.level is the severity (0-15 scale). Higher means more urgent.
agent.name shows which monitored endpoint produced the event.
The raw data section (often displayed as JSON) contains the full original log entry from Windows.

What do these fields mean for a SOC analyst?

These five fields are the first things a SOC analyst checks when an alert appears in their queue. The rule.id and rule.description tell you what the SIEM thinks happened. The rule.level tells you how urgently to investigate. The raw data is where you dig for evidence.

In a real SOC, you would be scanning dozens of these per hour, prioritizing by level and deciding which ones need a deeper look.

You should now see an expanded alert with all five fields visible. The alerts you see at this stage are likely informational (low severity). They confirm your agent is reporting in.

Don't see any fields when you expand an alert?

Make sure you clicked directly on the alert row to expand it, not on a column header. Some browsers require you to click a small arrow or chevron icon on the left side of the row.

If the expanded view is blank, try refreshing the page and expanding a different alert.

help me see alert details in the Wazuh Threat Hunting module

Generate deliberate activity to see more alerts

The alerts you see so far are routine system events. Now you will run some commands on your Windows machine that Wazuh actively monitors. These are normal reconnaissance commands that system admins use every day, but they are also the first commands an attacker runs after gaining access to a machine.

Switch to your Windows machine and open PowerShell.
Run these reconnaissance commands by pasting them one at a time:

whoami

ipconfig /all

net user

systeminfo

What do these commands do?

whoami shows which user account is currently logged in.
ipconfig /all reveals the machine's network configuration (IP addresses, DNS servers, adapters).
net user lists all user accounts on the machine.
systeminfo dumps detailed system information (OS version, installed patches, hardware).

Attackers run these exact commands post-compromise to understand where they are, what privileges they have, and what else is on the network. That is why SIEM tools watch for them.

Wait 30-60 seconds for the Wazuh agent to forward the events to the server.

Before you check the dashboard, ask yourself: do you think these commands will trigger high-severity alerts, or just low-level informational events?

Switch back to the Wazuh dashboard in your browser.
In Threat Hunting, click the refresh icon or reload the page.
Look for any new alerts that appeared since you ran the commands.

You should see alerts populating with your Windows hostname, rule IDs, and descriptions. At minimum, you will see informational events about your agent activity. The recon commands may appear as low-severity or informational events rather than urgent high-level alerts.

Why are these not high-severity alerts?

Running whoami or net user is completely normal for an administrator. Wazuh's default rules treat these as low-level observations, not emergencies. The SIEM logs them, but it does not scream about them.

This is a real limitation you will feel. Normal activity blends with suspicious activity until something clearly malicious happens. In the next step, you will generate unmistakable attack traffic that forces Wazuh to fire high-severity alerts.

Not seeing any new alerts after running the commands?

The Wazuh agent batches events before sending. Wait a full 60 seconds, then refresh again.

Confirm the agent is still Active by checking Agents management > Summary. If the agent shows Disconnected, return to your Windows machine and restart the service with NET START WazuhSvc in an Administrator PowerShell.

help me troubleshoot why alerts are not appearing in Wazuh Threat Hunting

You now have live data flowing from your endpoint into your SIEM. You can see alerts, expand them, and read the raw evidence. But you probably noticed something: those recon commands did not trigger anything urgent. Next up, you will generate a brute force attack that makes Wazuh light up with high-severity detections.

Generate a Brute Force Attack and Watch Wazuh Catch It

In the previous step, you ran reconnaissance commands and saw low-level telemetry in the Threat Hunting dashboard. But here is the problem: those events blended in with normal system activity.

Normal activity and suspicious activity look the same until something clearly malicious happens. A brute force attack is a textbook SOC scenario that generates unmistakable high-severity alerts. In this step, you will simulate one against your own machine and watch Wazuh light up with real detections.

In this step, get ready to:

Enable Remote Desktop on your Windows host so it can receive RDP connections.
Generate 8-10 rapid failed login attempts to trigger brute force detection rules.
Observe high-severity alerts in the Threat Hunting dashboard filtered by brute force rule IDs.

Enable RDP on your Windows machine

For a brute force attack to work, you need a service that accepts login attempts. Remote Desktop Protocol (RDP) is the most commonly targeted service in real-world brute force attacks.

On your Windows machine, open Settings.
Navigate to System, then select Remote Desktop.
Toggle Enable Remote Desktop to On.
Click Confirm when prompted.

You should see the toggle turn blue and a message confirming Remote Desktop is now enabled.

Note your Windows machine's IP address by opening PowerShell and running:

ipconfig

Look for the IPv4 Address under your active network adapter. This is the IP address you will target with failed login attempts from the Wazuh VM.

Why enable RDP?

RDP (port 3389) is the number one target for brute force attacks in real-world ransomware incidents. Attackers scan the internet for open RDP ports and hammer credentials until they get in.

By enabling RDP on your lab machine, you are recreating the exact attack surface that SOC analysts monitor every day.

Generate failed login attempts from the Wazuh VM

You will now play the role of an attacker. From your Wazuh VM terminal, you will attempt to connect to your Windows host via RDP using wrong credentials. Each failed attempt generates a Windows Security Event ID 4625 on your Windows host, which the Wazuh agent immediately forwards to the server.

Switch to your Wazuh VM terminal window.
Install the FreeRDP client by running:

sudo dnf install -y freerdp

What is FreeRDP?

FreeRDP is an open-source RDP client for Linux. The xfreerdp command lets you attempt RDP connections from the command line, which is exactly what you need to simulate an attacker hammering a target with login attempts.

Now generate 8 rapid failed login attempts by running this loop (replace the IP with your Windows machine's IPv4 address):

# Attempt 8 failed RDP logins with wrong credentials
for i in $(seq 1 8); do
  xfreerdp /v:[[WINDOWS_IP="your Windows IPv4 address"]] /u:fakeuser /p:wrongpass$i /cert:ignore 2>/dev/null
  echo "Attempt $i sent"
done

What does this command do?

The loop runs xfreerdp 8 times, each time connecting to your Windows host's RDP port with a fake username and a different wrong password.

Each failed connection attempt causes Windows to log Event ID 4625 (failed logon) in its Security event log. The Wazuh agent picks up these events and forwards them to the server. When Wazuh sees multiple failures from the same source in quick succession, it triggers its brute force correlation rules.

You should see output like "Attempt 1 sent", "Attempt 2 sent", and so on up to 8. Each attempt may show a connection error or timeout. That is expected.

If xfreerdp hangs or takes too long

Each connection attempt may take 5-10 seconds to timeout. If it stalls, press Ctrl+C and run the next attempt manually. The key is generating at least 5-6 failed attempts within a short window (a few minutes).

Wait 30-60 seconds after the last attempt for the Wazuh agent to forward all events to the server.

Connection refused or network unreachable?

Make sure both your Wazuh VM and Windows machine are on the same network (Bridged Adapter in VirtualBox settings).

Verify you can reach your Windows machine by running ping <your-windows-ip> from the Wazuh VM terminal. If the ping fails, check that your Windows firewall allows ICMP and that both machines share the same subnet.

Also confirm RDP is enabled and Windows Firewall is not blocking port 3389. Help me troubleshoot network connectivity between my Wazuh VM and Windows host.

Observe the brute force alerts in the dashboard

Your failed login attempts have now been forwarded to Wazuh. Before you check the dashboard, think about what you expect to see.

You just sent 8 failed login attempts from a single IP in rapid succession. Do you think Wazuh will treat this as normal activity or flag it as suspicious? What severity level would you expect?

Return to the Wazuh dashboard in your browser.
Navigate to Threat Hunting from the left menu.
In the search bar at the top, enter this filter and press Enter:

rule.id:(60122 OR 60204)

You should see multiple alerts for brute force activity with severity level 10 or higher.
Click on any one of these alerts to expand it.
Note these key fields in the expanded alert:

The rule.id (60122 or 60204).
The rule.description (something like "Multiple Windows Logon Failures").
The rule.level (10 or higher means high severity).
The source IP address (your Wazuh VM's IP).
The target username (fakeuser).
The timestamp of the alert.

What are rules 60122 and 60204?

These are Wazuh's built-in correlation rules for Windows authentication failures. Rule 60122 fires when Wazuh detects multiple Windows logon failures from a single source. Rule 60204 fires for multiple Windows audit failure events.

Unlike the low-level events you saw earlier, these are correlation rules. They do not fire on a single event. They fire when Wazuh sees a PATTERN of events that matches known attack behaviour. That pattern-matching is what makes a SIEM valuable. It connects individual events into a meaningful alert.

This is what a real SOC alert queue looks like. You generated the attack, and Wazuh caught it automatically.

Not seeing any brute force alerts?

Make sure you ran at least 5-6 failed attempts in quick succession. The correlation rules need multiple failures within a short time window to trigger.

Check that your Windows agent still shows as Active in Agents management > Summary. If the agent went offline, the events are not being forwarded.

Try clearing the filter and searching for rule.id:60122 alone. Also try widening the time range in the dashboard to the last 1 hour.

Help me figure out why my brute force alerts are not appearing in the Wazuh Threat Hunting dashboard.

You now have a real brute force detection in your SIEM. Next, you will dig into the raw event data behind these alerts and walk through the exact triage workflow SOC analysts use on the job.

Triage the Alert Like a SOC Analyst

Your brute force attack worked. Wazuh caught it, and the alerts are sitting in your Threat Hunting dashboard right now.

Seeing alerts fire is not the same as investigating them. The triage workflow turns a raw alert into a decision: what fired, what the raw evidence says, what technique an attacker used, and whether this is a real threat. Without this process, you are just a dashboard watcher, not an analyst.

In this step, get ready to:

Read the raw log data inside a brute force alert.
Map the alert to a MITRE ATT&CK technique.
Document your triage decision with evidence and a verdict.

Read the alert and dig into the raw log

A SOC analyst does not stop at the alert title. The real evidence lives in the raw event log underneath. You need to find the specific Windows Event fields that tell the full story of what happened.

In the Wazuh dashboard, return to the Threat Hunting module where your brute force alerts are visible.
Find an alert with rule ID 60122 or 60204 in the list.
Click on the alert to expand it.
Click the JSON tab to view the full raw event data.

You should now see the complete event payload with nested fields. This is the raw Windows Security log that triggered the alert.

Locate these key fields inside the raw JSON:

win.system.eventID should show 4625 (this is the Windows Event ID for a failed logon attempt).
win.eventdata.logonType should show 3 (LogonType 3 means Network logon, meaning someone tried to log in over the network via RDP).
win.eventdata.ipAddress (or a similar source IP field) shows where the login attempt came from.
win.eventdata.targetUserName shows which account the attacker targeted.

What do these fields tell you?

Event ID 4625 is the Windows Security log entry for every single failed login. It fires regardless of whether the failure is from a typo or a deliberate attack.

LogonType 3 (Network) narrows it down: this was not someone mistyping at the keyboard. It was a remote attempt over the network. Combined with a rapid succession of these events from one IP, you have a textbook brute force signature.

Don't see win.system.eventID in the JSON?

Scroll down within the expanded JSON view. The Windows-specific fields are nested several levels deep. Look for a win object containing system and eventdata child objects.

If you see a flat structure instead, try clicking View surrounding documents or toggling between the table view and the JSON view.

Help me find the raw event fields in my Wazuh alert JSON.

Map the alert to MITRE ATT&CK

Now that you know what happened at the log level, you need to categorize it. The MITRE ATT&CK framework is the industry standard for classifying adversary behavior. Wazuh maps alerts to ATT&CK techniques automatically.

In the left navigation menu of the Wazuh dashboard, look under the Threat Detection and Response section.
Click MITRE ATT&CK.
On the MITRE ATT&CK page, look at the dashboard overview showing detected tactics and techniques.
Find technique T1110 (Brute Force) listed under the Credential Access tactic.
Click the Events tab to see your specific brute force alerts mapped to this technique.

You should see your brute force alerts listed here, confirming that Wazuh automatically classified the attack under Credential Access > Brute Force (T1110).

Why does MITRE ATT&CK mapping matter?

In a SOC interview, you would not just say "I saw a failed login alert." You would say: "I observed multiple failed logon events (Event ID 4625, LogonType 3) from a single source IP in rapid succession. This maps to MITRE ATT&CK T1110, Brute Force, under Credential Access."

That sentence proves you understand the raw evidence AND can place it in the adversary behavior framework that every SOC team uses for reporting and escalation.

Don't see T1110 in the MITRE module?

Make sure you are looking at the correct time range. The MITRE ATT&CK module respects the time filter in the top-right corner of the dashboard. Set it to cover the period when you generated the brute force attempts.

If the module shows no data at all, switch to the Events tab and manually filter for T1110 in the search bar.

Help me find T1110 Brute Force in the Wazuh MITRE ATT&CK module.

Make your triage decision

You have the raw evidence and the ATT&CK classification. Now you make the call. This is the core of SOC analyst work: taking everything you know and producing a clear verdict with reasoning.

Open a text file or notepad on your Windows machine. This is where you will write your first triage report.
Answer each of these SOC analyst questions about the brute force alert:

Is this expected? Did you generate it, or is it from an unknown source?
What is the context? Is the source IP internal or external? Is this a critical asset?
What is the evidence? Multiple Event ID 4625 entries from one IP in seconds, LogonType 3.
What is your verdict? True positive or false positive, and why?

What is a true positive vs false positive?

A true positive means the alert correctly identified real malicious or suspicious activity. A false positive means the alert fired but the activity was benign (like a user mistyping their password once).

In this case, you generated multiple rapid-fire failed logins from an external source. That is a true positive: the alert correctly identified brute force behavior. In a real SOC, you would escalate this for response.

Write your triage decision in the text file. Include all of these elements:

The rule that fired (60122 or 60204).
The raw log evidence (Event ID 4625, LogonType 3, the source IP, and the target username).
The MITRE ATT&CK mapping (T1110, Brute Force, Credential Access).
Your context assessment (who, when, where, expected or not).
Your verdict and recommended action.

Use this escalation template

Here is how a SOC analyst would phrase the escalation: "True positive. Brute force attempt against [username] from [source IP]. Multiple 4625 events (LogonType 3) in rapid succession map to MITRE T1110. Recommend blocking source IP and verifying no successful logon followed."

Save this template. You can reuse this structure for every alert you triage going forward.

Save your text file.

Before you move on, review your triage report. Does it answer all five elements: rule, evidence, ATT&CK technique, context, and verdict?

What should my triage report look like?

Your report should read like a complete investigation note. Someone reading it (a senior analyst, a hiring manager in an interview) should be able to understand what happened, how you know, and what you recommend, without asking follow-up questions.

If any of the five elements is missing, add it now. A weak triage report says "brute force detected." A strong one says exactly what evidence proves it, what framework classifies it, and what action you recommend.

You just completed a full alert triage from start to finish. That is the exact workflow SOC analysts perform dozens of times per shift. Next up, you will investigate more ambiguous alerts where the answer is not as clear-cut.

Investigate Reconnaissance Alerts and the MITRE ATT&CK Dashboard

Your brute force triage gave you a clear-cut investigation. Multiple failed logins, obvious malicious intent, straightforward True Positive call.

Real SOC work is rarely that clean. Reconnaissance commands like whoami, net user, and systeminfo live in a gray area. System administrators run them daily for legitimate purposes. Attackers run the exact same commands immediately after gaining access. Learning to assess context around these ambiguous alerts is what separates junior analysts from strong ones.

In this step, get ready to:

Generate reconnaissance commands that trigger Discovery alerts in Wazuh.
Identify MITRE ATT&CK techniques T1082 and T1087 in the dashboard.
Document a contextual triage decision for ambiguous alerts.

Generate recon activity that Wazuh will flag

In the MITRE ATT&CK framework, Discovery (TA0007) is the tactic attackers use immediately after initial access to understand the compromised environment. Commands like whoami and net localgroup administrators tell an attacker who they are and what privileges they have.

You ran some of these commands earlier in PowerShell. This time you will run a more targeted set in quick succession through Command Prompt to simulate post-exploitation enumeration.

On your Windows machine, press the Windows key to open your search bar.
Type cmd and press Enter to open Command Prompt.
Run these six commands in quick succession by typing each one and pressing Enter:

whoami /all
net user
net localgroup administrators
systeminfo
ipconfig /all
nltest /dclist:

What do these commands reveal?

Each command maps to a specific piece of information an attacker needs after landing on a machine.

whoami /all reveals the current user, their group memberships, and privileges.
net user and net localgroup administrators enumerate all accounts and who has admin access.
systeminfo exposes the OS version, patch level, and domain membership.
ipconfig /all maps the network layout, DNS servers, and domain controllers.
nltest /dclist: identifies domain controllers for lateral movement planning.

Wait 30 to 60 seconds for the Wazuh agent to forward the events to your server.
Switch back to the Wazuh dashboard in your browser.
Navigate to Threat Hunting from the left menu.
Refresh the page and confirm you see new events from your Windows hostname with recent timestamps.

Not seeing new events?

Check that the time range filter in the top-right of the dashboard is set to the last 15 or 30 minutes.
Confirm your Wazuh agent still shows as Active under Agents management > Summary.
Wait another 30 seconds and refresh again. Event forwarding can occasionally take slightly longer.

Still stuck? Why aren't my recon commands showing up in Threat Hunting?

Find the alerts in the MITRE ATT&CK module

You know the commands ran successfully, but which ATT&CK techniques did Wazuh map them to? Before you check, think about it.

Based on what these commands do, which MITRE ATT&CK tactic do you think they fall under? Which specific technique IDs would you expect?

In the Wazuh dashboard, navigate to MITRE ATT&CK under the Threat Detection and Response section in the left menu.
Select the Framework tab.
Find the Discovery tactic column. This is tactic TA0007.
Look for technique T1082 (System Information Discovery) and T1087 (Account Discovery) within the Discovery column.
Click on the Events tab to see your specific alerts mapped to these techniques.

You should see alerts from your Windows host correlated to Discovery techniques. The same commands you ran as a legitimate user are flagged identically to how they would appear if an attacker ran them post-compromise.

Why are legitimate commands flagged as attacks?

Wazuh cannot read intent. It can only see what happened. A whoami /all from an admin troubleshooting permissions looks exactly the same in a log as whoami /all from an attacker mapping their access. This is why context matters more than the alert itself.

The SIEM tells you WHAT happened. The analyst determines WHETHER it matters.

Practice contextual triage

You can see that Wazuh flagged your legitimate commands as Discovery activity. In a real SOC queue, these alerts would sit alongside dozens of others. Your job is to decide whether they represent normal admin work or post-exploitation enumeration.

For each recon alert, a SOC analyst asks four contextual questions:

WHO ran it? Was it the expected admin account, or an unusual user?
WHEN was it run? During business hours, or at 3am?
FROM WHERE? The user's normal workstation, or a server that should not have interactive sessions?
HOW MANY at once? One whoami is normal. Five recon commands in 10 seconds suggests post-exploitation enumeration.

Why context separates junior analysts from strong ones

A junior analyst sees a Discovery alert and either ignores it (because the command is legitimate) or escalates it blindly (because it mapped to ATT&CK). A strong analyst checks context. The combination of who, when, where, and how many turns ambiguous data into a decision.

In an interview, saying "I checked the user, the timing, the source host, and the sequence" demonstrates you understand that detection without investigation is just noise.

Open the text file or Notepad where you wrote your brute force triage report.
Add a new section for your recon alert triage. Document the username from the alert, the hostname, the timestamp, and how many commands ran in sequence.
Write your assessment: note that these commands were executed in rapid succession (consistent with T1082/T1087 post-exploitation enumeration), then state what you would investigate next in a real environment.

Structure your triage note like this

Your note should cover: who ran the commands (username), on which host, at what time, your assessment of benign vs suspicious, and follow-up questions. A strong example:

"Recon commands executed by admin-user on DESKTOP-PC at 14:23 UTC. While individually benign, the rapid sequence of system discovery commands from a single session is consistent with T1082/T1087 post-exploitation enumeration. Follow-up: was a new logon session created just before these commands? Was there a preceding alert (brute force success) that establishes initial access?"

Save your triage report.

Look at your completed triage note. Can you explain why the same commands could be completely benign in one context and highly suspicious in another?

You now have two documented triage decisions: one for a clear True Positive (brute force) and one for an ambiguous alert (reconnaissance). Your triage report shows the full workflow SOC analyst interviewers test for.

Secret mission

Write a Custom Detection Rule

SOC analysts who can only triage existing alerts hit a ceiling fast. Detection engineering is the skill that separates dashboard watchers from analysts who shape what the dashboard sees. In this mission, you will SSH into the Wazuh server, write an XML rule from scratch, and make Wazuh catch something it misses by default.

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 locally, so there are no ongoing costs.

Resources you used:

Wazuh OVA virtual machine running in VirtualBox (~8GB RAM, ~50GB disk while running).
Wazuh agent service installed on your Windows host.
Remote Desktop enabled on your Windows host (security configuration change from Step 3).

Keep everything running

No action needed. Choose this if you are still actively building detection rules and practicing triage.

Your Wazuh VM stays running in VirtualBox and continues collecting events from your Windows agent.
The Wazuh agent on Windows keeps forwarding security events to the manager.
Remote Desktop remains enabled on your Windows host. If you no longer need it, consider disabling it for security (Settings > System > Remote Desktop > toggle Off).

Pause - I'll come back to this later

Shut down running processes to free up RAM and CPU. Your files and configuration stay intact for next time.

In VirtualBox, right-click the Wazuh VM and select Close > Save State. This preserves the VM exactly as it is without using RAM.
The Wazuh agent on Windows will queue events while the VM is off. When you start the VM again, it resumes collecting.
Optionally disable Remote Desktop (Settings > System > Remote Desktop > toggle Off) if you do not plan to generate brute force alerts again soon.

Delete - I don't want to use this again

Remove all project resources completely. Nothing persists beyond your local machine.

Stop the Wazuh agent on your Windows host. Open PowerShell as Administrator and run:
Uninstall the Wazuh agent. Make sure the original MSI installer file is in your working directory, then run:

NET STOP WazuhSvc

msiexec.exe /x wazuh-agent-4.14.6-1.msi /qn

Disable Remote Desktop on your Windows host. Go to Settings > System > Remote Desktop and toggle it Off.
Delete the Wazuh VM from VirtualBox. In the VirtualBox Manager, right-click the Wazuh VM, select Remove, then choose Delete all files. This removes the ~50GB virtual disk.
Delete any local triage report files you created during the project.

Nice Work!

You just built a fully operational SOC analyst workstation from scratch. You have a running SIEM, real alerts from your own machine, and a triage process you can walk through in any interview.

You've learned how to:

Set up a complete Wazuh SIEM server and enroll your Windows endpoint as a monitored agent, giving you a live dashboard with real security telemetry.
Generate a brute force attack and perform a full alert triage: reading the raw event log, identifying Windows Event ID 4625 with LogonType 3, mapping it to MITRE ATT&CK technique T1110, and making a True Positive determination with evidence.
Investigate reconnaissance alerts and assess context (who, when, where, how many) to distinguish legitimate admin activity from post-exploitation enumeration, mapping commands to Discovery techniques in the MITRE ATT&CK module.
Secret Mission: Write a custom detection rule targeting encoded PowerShell commands, learning the fundamentals of detection engineering and rule tuning.

Ready to quiz yourself?