Detect Threats Like a SOC Analyst

Deploy a cloud SIEM, simulate attacks, and investigate alerts like a SOC analyst.

Introduction

30 Second Summary

Every time you log into your computer, open a browser, or connect to Wi-Fi, your machine generates hundreds of events. Attackers exploit this noise to hide their activity. Security Operations Center (SOC) analysts are the people who sift through these events to find the threats hiding in plain sight.

In this project, you will build a real threat detection pipeline using a cloud SIEM connected to your own Windows machine. You will simulate attacker techniques, watch alerts fire in real-time, and investigate them the same way professional SOC analysts do every day.

What You'll Build

A fully operational threat detection pipeline where your Windows machine reports security telemetry to a cloud SIEM, and you simulate, detect, and investigate real attacker techniques.

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

  • A Wazuh Cloud SIEM environment connected to your Windows machine as a monitored endpoint.
  • Sysmon installed and generating detailed security telemetry beyond what Windows logs by default.
  • Security alerts triggered by simulated attacker techniques, investigated and mapped to the MITRE ATT&CK framework.
  • Secret Mission: Write a custom detection rule that catches a specific attacker behaviour Wazuh doesn't detect by default.

Are there any prerequisites?

None. You need a Windows 10 or 11 machine with internet access and about 8 GB of RAM. This guide includes full setup for every tool you will use.

Set Up Your Wazuh Cloud SIEM

Every SOC analyst needs a central place to collect and analyze security data from their machines. This central system is called a SIEM (Security Information and Event Management).

In this step, you will set up Wazuh Cloud as your SIEM. Wazuh Cloud is a managed security platform that collects logs from your computer, detects threats, and presents everything in a dashboard you can investigate.

In this step, get ready to:
  • Create a free Wazuh Cloud account.
  • Set up your first SIEM environment.
  • Access the Wazuh dashboard and explore the main interface.
Sign up for Wazuh Cloud free trial

Wazuh Cloud offers a 14-day free trial with no credit card required. You just need an email address to get started.

  • Open your web browser and navigate to the Wazuh Cloud sign-up page:
  • https://console.cloud.wazuh.com/sign-up?landing=trial
  • Fill in your name, email address, and choose a password.
  • Click Start free trial.
  • Check your email inbox for a verification email from Wazuh with the subject line containing "Verify your email address".
  • Click the verification link in the email to confirm your account.

What is a SIEM?

A SIEM collects security logs from across your machines and network, then analyzes them for signs of threats. It is the primary tool SOC analysts use to detect and investigate security incidents.

Instead of manually checking every log file on every machine, a SIEM centralizes everything into one searchable dashboard. Think of it as the security team's command center.

Not receiving the verification email?

Check your spam or junk folder. The email comes from Wazuh and may be filtered by some email providers. If you still cannot find it after a few minutes, try signing up again with the same email address.

help me troubleshoot why I'm not receiving my Wazuh Cloud verification email

Create your SIEM environment

With your account verified, you can now create the environment where all your security data will be stored and analyzed.

  • Log in to the Wazuh Cloud Console using the email and password you just registered.
  • Click Create environment.
  • Enter My SOC Lab as the environment name.
  • Fill in the Use case field with something like "Learning threat detection" or "SOC training".
  • Select the region closest to your physical location to reduce latency.
  • Select the Small profile.
  • Select Monthly for the pricing option.
  • Click Start your free trial.

The environment takes a few minutes to build. Wait for it to finish before proceeding.

Why the Small profile?

The Small profile supports up to 100 active agents, 1 month of indexed data retention, and 25 GB of indexed data capacity. This is more than enough for a single machine sending security telemetry in a learning environment.

Important: enrol an agent within 3 days

Wazuh will terminate your trial environment if you do not enrol an agent within 3 days of starting the trial. Make sure you complete Step 2 (installing the agent on your Windows machine) in the same session or within the next day or two.

Access the Wazuh dashboard

Once the environment finishes building, you can open the main dashboard where you will investigate security alerts later in this project.

  • On the Wazuh Cloud Console Environments page, click Open Wazuh next to your new environment.
  • Click Manage on the Environments page, then select Default credentials to view your login details.
  • Log in to the Wazuh dashboard using the default credentials shown.
  • Take a moment to look around the interface. Notice the left-hand menu with sections for Agents, Threat intelligence, and more.

What should I see?

The Wazuh dashboard opens to a summary view. You will see a mostly empty interface since no agents are connected yet. The left-side menu (accessible via the ☰ icon) is where you will navigate to agent management, threat hunting, and rules management throughout this project.

Dashboard not loading?

If the environment is still showing as "Building" in the Cloud Console, wait a few more minutes and refresh the page. Environment creation typically takes 2-5 minutes.

If you see a certificate warning in your browser, this is expected for new deployments. Click Advanced and then proceed to the site.

help me troubleshoot why my Wazuh Cloud dashboard is not loading

Your cloud SIEM is live and ready to receive security data. Next up, you will connect your Windows machine to this environment by installing the Wazuh agent.

Install the Wazuh Agent on Your Windows Machine

Your Wazuh Cloud SIEM is running, but it has no visibility into your machine yet. A SIEM only becomes useful when endpoints send it security data.

The Wazuh agent is a lightweight service that runs on your Windows machine, collects security logs, and forwards them to your cloud environment. In this step, you will install the agent and confirm it connects successfully.

In this step, get ready to:
  • Deploy a new agent from the Wazuh dashboard.
  • Install the agent on your Windows machine using PowerShell.
  • Verify the agent appears as active in the dashboard.

Complete this step soon after Step 1

Wazuh Cloud terminates trial environments after 3 days if no agent is enrolled. Make sure you finish this step in the same session as Step 1 to keep your environment active.

Deploy a new agent from the dashboard

The Wazuh dashboard includes a deployment wizard that generates the exact installation command for your environment. This saves you from manually looking up your cloud address.

  • In the Wazuh dashboard, click the ☰ menu icon in the upper-left corner.
  • Expand Agents management and select Summary.
  • Click Deploy new agent.
  • Select Windows as the operating system.
  • Follow the on-screen steps to download the agent installer (wazuh-agent-4.14.5-1.msi).
  • Copy the installation command that the wizard generates. It has your cloud environment address pre-filled.

Why copy from the dashboard?

The wizard inserts your unique Wazuh Cloud address into the command automatically. Copying it directly means you avoid typos and do not need to look up the address yourself.

Run the installer in PowerShell

With the installer downloaded and the command copied, you will run everything from an Administrator PowerShell session. Administrator privileges are required because the agent installs a system service.

  • Press the Windows key to open your search bar.
  • Type PowerShell.
  • Right-click Windows PowerShell and select Run as administrator.
  • Click Yes on the User Account Control prompt.
  • Navigate to your Downloads folder by running this command:
cd ~\Downloads
  • Paste the installation command you copied from the Wazuh dashboard and press Enter.

What does the installation command look like?

Your pasted command should follow this format:

.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="your-cloud-address"

The /q flag runs a silent install (no pop-up windows). WAZUH_MANAGER tells the agent where to send data. The dashboard already filled in your specific cloud address.

The installation runs silently with no visible output. When your command prompt returns (you see a new PS C:\ line), the install is complete.

  • Start the Wazuh agent service by running this command:
NET START WazuhSvc

What does this command do?

NET START WazuhSvc starts the Wazuh agent as a Windows service. Once running, it begins collecting security logs and forwarding them to your cloud environment in real-time.

You should see a message that says the service was started successfully.

Seeing an error about access denied or service not found?

If you see an access denied error, make sure you right-clicked PowerShell and selected Run as administrator. A regular PowerShell window does not have permission to start services.

If the service is not found, the .msi installer may not have completed. Check that you ran the install command from the same folder where the wazuh-agent-4.14.5-1.msi file was downloaded.

help me troubleshoot why NET START WazuhSvc is failing

Verify the agent is connected

The agent is installed and running on your machine. Now confirm that the Wazuh Cloud dashboard recognizes it.

  • Switch back to the Wazuh dashboard in your browser.
  • Click the ☰ menu icon in the upper-left corner.
  • Expand Agents management and select Summary.
  • Look for your Windows machine in the agent list. It should show a green Active status.

What if my agent does not appear yet?

It can take 1 to 2 minutes for the agent to check in with the cloud environment for the first time. Refresh the page after a short wait. If the agent still does not appear, verify the service is running by going back to your Administrator PowerShell and running Get-Service wazuhsvc.

Your Windows machine is now reporting to your cloud SIEM. Next, you will install Sysmon to give the agent much richer security telemetry to work with.

Install and Configure Sysmon for Enhanced Telemetry

Your Wazuh agent is connected and reporting to your cloud SIEM. However, standard Windows event logs have significant blind spots. They record basic events like logon success or failure, but miss the detailed activity that reveals attacker behaviour.

Sysmon (System Monitor) fills those gaps by recording detailed telemetry that Windows doesn't capture by default. In this step, you'll install Sysmon with a community-standard security configuration so your SIEM receives the rich data it needs to detect threats.

In this step, get ready to:
  • Download and extract Sysmon to your Windows machine.
  • Download a security-focused Sysmon configuration file.
  • Install Sysmon with the configuration and verify it is generating events.
Download Sysmon

Sysmon is a free tool from Microsoft's Sysinternals suite. It runs as a Windows service and device driver, logging detailed system activity to the Windows Event Log. Your Wazuh agent will automatically forward these events to the dashboard.

Quick extraction with PowerShell

If you prefer using PowerShell (which you already have open as Administrator), you can create the folder and extract in one go:

mkdir C:\Sysmon
Expand-Archive -Path ~\Downloads\Sysmon.zip -DestinationPath C:\Sysmon

Either method works. The important thing is that the Sysmon files end up inside C:\Sysmon.

  • Confirm the extraction worked by running this in your Administrator PowerShell:
ls C:\Sysmon

You should see sysmon64.exe listed among the extracted files.

Don't see sysmon64.exe?

Make sure you extracted the zip file contents into C:\Sysmon directly. Some extraction tools create a nested folder (like C:\Sysmon\Sysmon\). If that happened, move the files up one level so sysmon64.exe sits directly inside C:\Sysmon.

Help me fix the Sysmon extraction on my Windows machine.

Download a security-focused configuration

Sysmon on its own doesn't know what to monitor. It needs a configuration file that tells it which events to log and which to ignore. You'll use a widely trusted community configuration from SwiftOnSecurity that provides high-quality default monitoring out of the box.

  • In your web browser, navigate to the SwiftOnSecurity sysmon-config repository:
  • https://github.com/SwiftOnSecurity/sysmon-config
  • Click on the sysmonconfig-export.xml file in the file list.
  • Click the Raw button near the top right of the file view.
  • Right-click anywhere on the raw XML page and select Save as... to save it.
  • Save the file as sysmonconfig-export.xml in your C:\Sysmon folder.
  • Verify the config file is in place by running:
ls C:\Sysmon\sysmonconfig-export.xml

You should see the file listed with its size and date.

What is this configuration file?

The SwiftOnSecurity sysmon-config is a community-standard template that tells Sysmon which events to capture. It focuses on high-signal security events like suspicious process creation, network connections to unusual destinations, and file modifications in sensitive directories.

Without a configuration, Sysmon would either log nothing useful or flood your SIEM with noise. This config strikes the right balance for threat detection.

Having trouble downloading from GitHub?

If the browser adds a .txt extension, rename the file to remove it so it ends in .xml. The file must be named exactly sysmonconfig-export.xml.

Help me download the SwiftOnSecurity sysmon config file.

Install Sysmon with the configuration

Now that both files are in place, you'll run the Sysmon installer with your config file. This registers Sysmon as a system service that starts automatically and begins logging events immediately.

  • Install Sysmon with the SwiftOnSecurity config by running this command in your Administrator PowerShell:
C:\Sysmon\sysmon64.exe -accepteula -i C:\Sysmon\sysmonconfig-export.xml

What does this command do?

-accepteula automatically accepts the Sysinternals license agreement so the install proceeds without a prompt.

-i tells Sysmon to install itself as a service and load the specified configuration file. From this moment, Sysmon begins recording security events based on the rules in your config.

You should see output confirming that Sysmon was installed successfully. No reboot is required.

  • Verify Sysmon is generating events by opening Event Viewer. Press the Windows key, type Event Viewer, and press Enter.
  • In the left panel, expand Applications and Services Logs.
  • Expand Microsoft, then Windows, then scroll down to Sysmon.
  • Click on Operational.

You should see events already appearing in the log. These are real-time records of process creation, network activity, and other security-relevant actions happening on your machine.

Why Sysmon over standard Windows logs?

Standard Windows logs record basic events like logon success or failure. Sysmon captures exactly which program ran, what command-line arguments were used, which network connections were made, and more.

This telemetry is what allows your SIEM to detect attacker behaviour rather than just seeing generic system noise. SOC analysts rely on Sysmon data for the majority of their endpoint threat detection.

Don't see the Sysmon log in Event Viewer?

Make sure you expanded the full path: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. If Sysmon doesn't appear at all, the installation may have failed.

Return to your PowerShell and run the install command again to check for error messages.

Help me troubleshoot why Sysmon is not appearing in Event Viewer after installation.

Your endpoint is now generating rich security telemetry. Next up, you'll simulate real attacker techniques and watch your SIEM detect them in real time.

Simulate Attacker Techniques and Generate Alerts

Your monitoring infrastructure is fully operational. Sysmon is generating detailed telemetry and your Wazuh agent is forwarding everything to your cloud SIEM.

Now it's time to think like an attacker. In this step, you'll simulate three common attack techniques using only built-in Windows commands to generate real security alerts in your dashboard.

In this step, get ready to:
  • Simulate a brute force login attack that triggers authentication failure alerts.
  • Run suspicious PowerShell reconnaissance commands that mimic post-exploitation behaviour.
  • Trigger a File Integrity Monitoring alert by modifying a critical system file.

Why built-in Windows commands?

Real attackers often use commands already installed on a target system to avoid detection. This is called "living off the land." By using built-in tools like net use and whoami, you'll simulate realistic threats without needing virtual machines or special hacking tools.

Simulate failed login attempts

A brute force attack is when an attacker tries many username and password combinations to break into a system. You'll simulate this by repeatedly attempting to access a network share with wrong credentials.

  • Press the Windows key to open your search bar.
  • Type cmd and press Enter to open a regular Command Prompt.

Do not run as Administrator

Make sure you open a regular Command Prompt, not one with Administrator privileges. Right-clicking and selecting "Run as administrator" would change the security context and affect how Windows logs the failed authentication events.

  • Simulate a brute force attack by running this command five times (press the up arrow and Enter to repeat it after the first run):
net use \\127.0.0.1\C$ /user:fakeadmin wrongpassword

What does this command do?

This command attempts to connect to the administrative share (C$) on your own machine using a fake username and wrong password. Each failed attempt generates a Windows Security Event 4625 (failed logon), which Wazuh detects and logs.

Running it five times simulates the pattern of a brute force attack. Wazuh has built-in rules that trigger alerts when multiple authentication failures occur in a short time window. This maps to MITRE ATT&CK technique T1110 (Brute Force).

You should see an error message about a logon failure after each attempt. This is expected and confirms the failed authentication events are being generated.

Not seeing an error message?

If the command succeeds without an error, your machine's Guest account may be enabled. Open an Administrator PowerShell and run net user guest to check. If the account is active, disable it with net user guest /active:no and try again.

If you see a different error (like a network path error), make sure you typed the command exactly as shown, including the double backslashes.

Help me troubleshoot my brute force simulation. I'm not seeing the expected error message when running the net use command.

Simulate suspicious PowerShell execution

After gaining initial access, attackers run reconnaissance commands to learn about the system they've compromised. These commands gather information about user privileges, accounts, and system configuration.

  • Open a PowerShell window by pressing the Windows key, typing PowerShell, and pressing Enter.
  • Run the following reconnaissance commands one at a time by pasting each and pressing Enter:
whoami /priv
net user
net localgroup administrators
systeminfo

What do these commands reveal?

Each command gives an attacker critical intelligence about the target system:

  • whoami /priv shows the current user's security privileges (what they're allowed to do).
  • net user lists all user accounts on the machine (potential targets for lateral movement).
  • net localgroup administrators reveals which accounts have admin access (high-value targets).
  • systeminfo dumps OS version, patch level, and hardware details (useful for finding exploits).

Sysmon logs each of these as a Process Creation event (Event ID 1). Wazuh picks up these events and can alert on suspicious command patterns. This maps to MITRE ATT&CK technique T1059.001 (Command and Scripting Interpreter: PowerShell).

Each command will display its output directly in the terminal. You should see a list of privileges, user accounts, administrator group members, and system information respectively.

PowerShell command not recognized?

If any command returns an error about not being recognized, make sure you're in PowerShell (not Command Prompt) and that you typed the command exactly as shown.

Help me troubleshoot why my PowerShell reconnaissance commands aren't working as expected.

Trigger a File Integrity Monitoring alert

File Integrity Monitoring (FIM) watches critical system files for unauthorized changes. Attackers often modify the hosts file to redirect traffic to malicious servers. You'll simulate this by editing the hosts file on your machine.

  • First, create a safe backup of your hosts file. In your PowerShell window, run this command:
Copy-Item C:\Windows\System32\drivers\etc\hosts -Destination $HOME\Desktop\hosts.bak

Why back up the hosts file?

The hosts file maps domain names to IP addresses. Modifying it can break internet access to certain sites. Keeping a backup on your Desktop means you can restore it later.

  • Confirm the backup was created by running:
ls $HOME\Desktop\hosts.bak

You should see the file listed with its size and date.

  • Now open Notepad as Administrator. Press the Windows key, type Notepad, then right-click Notepad in the results and select Run as administrator.
  • Click Yes on the User Account Control prompt.
  • In Notepad, click File, then Open.
  • In the File name field at the bottom, paste this path and press Enter:
C:\Windows\System32\drivers\etc\hosts
  • Scroll to the bottom of the file and add this line on a new line at the end:
127.0.0.1 malicious-site.com
  • Press Ctrl+S to save the file.
  • Close Notepad.

What does this simulate?

Adding an entry to the hosts file redirects any request for malicious-site.com to 127.0.0.1 (your own machine). In a real attack, an adversary might redirect legitimate domains to a phishing server.

Wazuh's File Integrity Monitoring module watches the hosts file by default. When it detects the change, it fires an alert. This is a common indicator of compromise that SOC analysts investigate daily.

You have now simulated all three attacker techniques. The Wazuh agent has been collecting these events and forwarding them to your cloud SIEM in real-time.

Access denied when saving the hosts file?

If Notepad shows an access denied error when you try to save, you did not open it as Administrator. Close Notepad and reopen it by right-clicking and selecting Run as administrator. Then open the hosts file again from within the elevated Notepad.

Help me fix the access denied error when modifying my hosts file in Notepad.

Restore your hosts file later

When you're done with this project, remember to remove the fake entry from your hosts file. You can restore the backup you created by copying hosts.bak from your Desktop back to C:\Windows\System32\drivers\etc\hosts.

Your simulated attacks are now generating real security data. Next up, you'll switch to the Wazuh dashboard to investigate the alerts these techniques triggered and see how a SOC analyst would respond.

Investigate Alerts in the Wazuh Dashboard

In the previous step, you simulated three real attacker techniques on your own machine. Your SIEM has been collecting and processing all that telemetry behind the scenes.

Now it is time to switch roles from attacker to defender. You will hunt through the alerts your simulations generated, examine individual events for details like severity and source, and map everything to the MITRE ATT&CK framework. This is exactly what SOC analysts do every day when triaging incidents.

In this step, get ready to:
  • Find security events generated by your simulated attacks.
  • Investigate a brute force alert and review its details.
  • Map detected threats to the MITRE ATT&CK framework.
Find your security events

The Wazuh dashboard aggregates all alerts from your agent into searchable views. You need to navigate to the threat hunting area where your simulated attack alerts are waiting.

  • In the Wazuh dashboard, click the ☰ menu icon in the upper-left corner.
  • Expand Threat intelligence in the left menu.
  • Select Threat Hunting (on some dashboard versions this may appear as Security events).
  • Confirm the time range at the top-right is set to the last 30 minutes.

You should see a list of alerts populated from the brute force, PowerShell reconnaissance, and file integrity events you triggered in the previous step.

What am I looking at?

The Threat Hunting view displays all alerts that Wazuh rules have fired on incoming logs. Each row is a single alert with a timestamp, rule ID, rule description, and severity level.

The higher the severity number, the more critical Wazuh considers that event. You can click any row to expand its full details.

Don't see any alerts?

Make sure the time range covers the period when you ran your simulations. Try expanding it to the last 1 hour.

If you still see nothing, your agent may not have synced yet. Return to Agents management and confirm your agent status is Active. Wait 2-3 minutes and refresh the page.

Help me figure out why my alerts aren't appearing in the dashboard.

Investigate a brute force alert

SOC analysts do not just glance at alert titles. They drill into each event to understand what happened, where it came from, and how serious it is. You will now examine one of the brute force alerts in detail.

  • In the alerts list, look for alerts related to authentication failures. These may have descriptions like "Multiple Windows Logon Failures" or similar wording about failed authentication.
  • Click on one of these alerts to expand its details.
  • Review the rule description field. This tells you what Wazuh detected.
  • Note the severity level (rule level). Higher numbers indicate more critical events.
  • Look at the source information. This shows you where the event originated (your machine, the local IP, and the account that was targeted).

What makes up an alert?

Every Wazuh alert contains three critical pieces of information that SOC analysts use for triage:

  • Rule description tells you WHAT was detected (the type of suspicious activity).
  • Severity level tells you HOW serious it is (scale of 0-15, with 10+ generating active alerts).
  • Source info tells you WHERE and WHO was involved (IP address, user account, process name).
Map alerts to MITRE ATT&CK

The MITRE ATT&CK framework is a universal catalogue of attacker tactics and techniques. SOC analysts use it to classify threats and communicate about them in a standard language. Wazuh automatically maps your alerts to this framework.

  • Click the ☰ menu icon in the upper-left corner.
  • Under Threat intelligence, select MITRE ATT&CK.
  • Select the Framework tab to see a matrix of tactics and techniques detected in your environment.
  • Look for T1110 (Brute Force) highlighted in the matrix. This corresponds to your failed login simulations.
  • Look for T1059 (Command and Scripting Interpreter) which maps to your PowerShell reconnaissance commands.
  • Click on either technique to see the specific alerts from your environment associated with it.

Why does MITRE ATT&CK matter?

When a SOC analyst says "we detected T1110 activity", every security professional worldwide knows exactly what that means. It is a shared vocabulary that removes ambiguity from incident reports.

The framework organises attacks into tactics (the attacker's goal, like "Credential Access") and techniques (how they achieve it, like "Brute Force"). Wazuh performs this mapping automatically based on its rule definitions.

Explore the Events tab

Switch to the Events tab inside the MITRE ATT&CK module to see a detailed timeline of all technique-matched alerts. You can filter by specific MITRE IDs to isolate just the events you care about.

Secret mission

Write a Custom Detection Rule

Wazuh comes with thousands of built-in rules, but real SOC analysts write custom rules for threats specific to their environment. Your mission: create a custom rule that detects when someone runs the whoami command, a common post-exploitation reconnaissance technique.

Clean Up Your Resources

Clean Up Your Resources

This project uses Wazuh Cloud's 14-day free trial (no credit card required) and lightweight local tools. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Wazuh Cloud environment (free trial, auto-deletes after 14 days if no billing added).
  • Wazuh agent installed on your Windows machine.
  • Sysmon installed at C:\Sysmon.
  • Modified hosts file at C:\Windows\System32\drivers\etc\hosts.

Keep everything running

No action needed. Choose this if you are still actively exploring Wazuh and want to continue triggering and investigating alerts.

  • Your Wazuh Cloud trial lasts 14 days with no charge. If you do not add billing information before expiration, the environment is automatically deleted.
  • The Wazuh agent uses approximately 35 MB of RAM and runs quietly in the background.
  • Sysmon runs as a lightweight driver with no noticeable performance impact.
  • The fake entry you added to the hosts file (127.0.0.1 malicious-site.com) is harmless since it points to your own machine. Remove it whenever you prefer a clean system.

Pause - I'll come back to this later

Stop the Wazuh agent service to free up resources while keeping everything installed for later.

  • Stop the Wazuh agent by opening PowerShell as Administrator and running the command below.
Stop-Service wazuhsvc
  • Sysmon can remain installed with no performance impact.
  • Your Wazuh Cloud trial continues counting down even while the agent is stopped. The trial lasts 14 days total from creation.

When you are ready to resume, start the agent again by running this command in Administrator PowerShell:

Start-Service wazuhsvc

Delete - I don't want to use this again

Remove all project resources from your machine and cancel your cloud environment.

  • Revert your hosts file. Open Notepad as Administrator, then open the file at C:\Windows\System32\drivers\etc\hosts. Delete the line 127.0.0.1 malicious-site.com and save the file.
  • Delete the hosts file copy you placed on your Desktop (right-click the file and select Delete).
  • Uninstall Sysmon by opening PowerShell as Administrator and running this command:
C:\Sysmon\sysmon64.exe -u
  • Delete the Sysmon folder by running:
Remove-Item -Recurse -Force C:\Sysmon
  • Uninstall the Wazuh agent. Open Settings on your Windows machine.
  • Select Apps, then select Apps & features.
  • Find Wazuh Agent in the list, click it, and select Uninstall.
  • Cancel your Wazuh Cloud environment. Log in to the Wazuh Cloud Console.
  • Go to the Environments page and select your environment.
  • Click Cancel environment to confirm deletion.

Cancellation is permanent

Cancelling your Wazuh Cloud environment permanently deletes all data including your custom rules, alert history, and agent records. This action cannot be undone.

That's a Wrap!

That's a Wrap!

Nice work! You just built a real threat detection pipeline using Wazuh Cloud and Sysmon on your own Windows machine. This is the same architecture security teams at enterprise organizations use to protect their networks every day.

What you learned:

  • Deployed a cloud SIEM and connected your Windows machine as a monitored endpoint that reports security telemetry in real-time.
  • Simulated real attacker techniques like brute force login attempts and PowerShell reconnaissance, then investigated the resulting security alerts to understand their severity and context.
  • Mapped detected threats to the MITRE ATT&CK framework, the universal language SOC analysts use to classify and communicate about threats.
  • Secret Mission: Wrote a custom detection rule to catch a specific post-exploitation technique that Wazuh doesn't detect by default.

Ready to quiz yourself?