Build a Wazuh SIEM Detection Lab

Connect a Windows endpoint to Wazuh and investigate file integrity alerts.

Introduction

30 Second Summary

A file can disappear from a busy computer with no obvious clue about who changed it. Without a clear record, even a small deletion can become a slow investigation.

In this project, you will build a Wazuh Cloud SIEM lab that detects unauthorized Windows file changes. You will investigate a controlled File Integrity Monitoring deletion alert for publication on GitHub.

What You'll Build

Your finished demo traces a safe test-file deletion from a Wazuh dashboard alert into a sanitized public report.

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

  • A live SIEM workflow that shows your Windows endpoint sending telemetry to Wazuh Cloud.
  • A clear before-and-after test showing how who-data monitoring brings C:\test\hello.txt into scope.
  • A public GitHub lab report that lets others review your sanitized alert evidence without exposing endpoint identity.
  • Secret Mission: Build a file-change detection matrix that compares creation, modification, and deletion events for C:\test\lifecycle.txt.

Are there any prerequisites?

You need administrator access to an internet-connected Windows computer. A valid email address lets you verify the 14-day free trial with no credit card required.

Before We Start

This checkpoint locks in the purpose of your security lab before the hands-on work begins. It connects the Windows file changes you will detect to the sanitized evidence you will publish.

Set Up Wazuh Cloud and Enroll Windows

The lab has a clear purpose, but the dashboard has no Windows activity to analyze yet. A SIEM needs an endpoint agent to collect activity from the computer you want to monitor.

In this step, you will create a Wazuh Cloud trial in Microsoft Edge. You will install the Wazuh agent version 4.14.7 through Windows PowerShell.

An active agent status proves that your Windows endpoint can send telemetry to the managed environment.

In this step, get ready to:
  • Create a verified 14-day Wazuh Cloud trial environment.
  • Install Wazuh agent 4.14.7 with administrator privileges.
  • Confirm the endpoint is active and save sanitized evidence.
Create your Wazuh Cloud trial

Wazuh Cloud provides a 14-day free trial. No credit card is required.

You can complete this lab without adding billing information. Wazuh deletes the environment when the trial expires if no billing information is added.

  • Press the Windows key to open Windows search.
  • Enter Microsoft Edge in the search field.
  • Press Enter to open the browser.
  • Open the Wazuh Cloud setup guide.
  • Select Start free trial.
  • Complete the account form with an email address you can verify.
  • Submit the completed account form.
  • Open the verification email from Wazuh.
  • Select the verification link in the email.
  • Return to Microsoft Edge.
  • Sign in with your verified Wazuh Cloud account.
  • Select Manage.
  • Follow the setup prompts to create the 14-day trial environment.
  • Select Open Wazuh to enter the dashboard.

That is the cloud side ready. Your Wazuh dashboard can now accept an enrolled endpoint.

Why Wazuh Cloud?

Wazuh Cloud hosts the central SIEM components for you. This keeps your attention on endpoint telemetry and threat detection.

A local Docker deployment adds Windows virtualization and hardware requirements before the detection work begins.

Deploy the Windows agent

The agent deployment page creates commands for your specific cloud environment. Those generated commands connect the endpoint to the correct Wazuh deployment.

  • Open Agents management from the Wazuh dashboard navigation.
  • Select Summary.
  • Select Deploy new agent.
  • Choose the Windows package.
  • Check the installer area for the package name.
  • Choose the tab that matches the installer area on your deployment page.

✔️ I see the required installer

The required package is wazuh-agent-4.14.7-1.msi. The generated commands install the pinned agent and connect it to your trial environment.

  • Copy the generated installation command from Microsoft Edge.
  • Press the Windows key to open Windows search.
  • Enter Windows PowerShell in the search field.
  • Right-click Windows PowerShell in the search results.
  • Choose the option that opens Windows PowerShell with administrator privileges.
  • Approve the Windows permission request.
  • Paste the generated installation command into the administrator PowerShell window.
  • Press Enter to install the agent.
  • Wait for the PowerShell prompt to return without an installation error.
  • Return to the deployment page in Microsoft Edge.
  • Copy the generated start command.
  • Return to the administrator PowerShell window.
  • Paste the generated start command.
  • Press Enter to start the agent.

PowerShell returns to the prompt after running the generated commands. The endpoint is ready for its dashboard status check.

ⓧ I see an older installer

An older package creates version drift against this lab. Refresh the deployment flow before installing anything.

  • Leave the older installation command unrun.
  • Reload the deployment page in Microsoft Edge.
  • Select the Windows package again.
  • Confirm the installer now reads wazuh-agent-4.14.7-1.msi.
  • Copy the refreshed installation command.
  • Open Windows PowerShell with administrator privileges from Windows search.
  • Approve the Windows permission request.
  • Paste the refreshed installation command into PowerShell.
  • Press Enter to install the current agent.
  • Return to the deployment page in Microsoft Edge.
  • Copy the generated start command.
  • Return to the administrator PowerShell window.
  • Paste the generated start command.
  • Press Enter to start the agent.

The refreshed deployment now uses Wazuh agent 4.14.7.

ⓧ I do not see an installer

The deployment wizard has not generated the Windows package yet. Repeating the package selection gives it the information it needs.

  • Return to Agents management in the Wazuh dashboard.
  • Select Summary.
  • Select Deploy new agent.
  • Choose the Windows package.
  • Confirm the installer reads wazuh-agent-4.14.7-1.msi.
  • Copy the generated installation command.
  • Open Windows PowerShell with administrator privileges from Windows search.
  • Approve the Windows permission request.
  • Paste the generated installation command into PowerShell.
  • Press Enter to install the agent.
  • Return to the deployment page in Microsoft Edge.
  • Copy the generated start command.
  • Return to the administrator PowerShell window.
  • Paste the generated start command.
  • Press Enter to start the agent.

The Windows package is now installed and started with the environment-specific deployment commands.

Agent Installation Not Completing?

Confirm that Windows PowerShell has administrator privileges. Check that you copied the complete generated command from the deployment page.

  • Start the installed agent manually by running this official command in the administrator PowerShell window:
Start-Service wazuhsvc

This command asks Windows to start the installed Wazuh agent service.

If the service still does not start, help me troubleshoot the Wazuh agent installation.

Confirm the active agent and save evidence

The dashboard status is the first end-to-end proof that the endpoint can reach your cloud environment. An active row confirms that the agent is running and enrolled.

  • Return to the Wazuh dashboard in Microsoft Edge.
  • Open Agents management from the dashboard navigation.
  • Select Summary.

Before you reload the Summary page, do you expect the endpoint to appear active or disconnected.

  • Reload the Summary page.
  • Locate the row for your Windows endpoint.

You will see the Windows endpoint marked as active. That is the endpoint link working.

Agent Still Disconnected?

Return to the administrator PowerShell window and run the generated start command again. Reload the Summary page after the command finishes.

If the endpoint remains disconnected, help me diagnose the Wazuh agent connection.

The active row is evidence that your telemetry pipeline has started. Sanitize that evidence before it leaves your computer.

Protect Your Endpoint Details

A security screenshot can reveal more than you intend. Keep the dashboard context and active status while removing private endpoint details.

  • Remove any credentials.
  • Remove any IP addresses.
  • Remove any hostnames.
  • Remove any agent identifiers.
  • Remove any personally identifying usernames.
  • Press the Windows key to open Windows search.
  • Enter Snipping Tool in the search field.
  • Press Enter to open Windows Snipping Tool.
  • Capture the Summary heading and the active agent status.
  • Sanitize the capture using cropping or opaque markup.

The preview should retain the active status. It should contain no sensitive values.

  • Save the sanitized capture to your Windows Desktop as agent-active.png.
  • Inspect the saved agent-active.png image from your Desktop.

Your screenshot now proves the endpoint is active without exposing its identity. That is safe evidence for the repository you will publish later.

Your Windows endpoint is now sending telemetry to Wazuh Cloud. Next, you will test whether a new local folder is already inside the monitoring scope.

Expose the Monitoring Blind Spot

Your active Wazuh agent now sends SIEM telemetry into Wazuh Cloud. That connection gives this lab a working collection path.

A new business-critical folder can still sit outside File Integrity Monitoring coverage. This step tests that risk with a safe local file before any monitoring change is made.

In this step, get ready to:
  • Map the FIM views used for investigation.
  • Create the local baseline at C:\test\hello.txt.
  • Test whether the active agent records a matching FIM event.
Inspect the FIM views

File Integrity Monitoring presents current coverage separately from alert history. Its three views help you distinguish tracked files from alert records.

  • Switch back to the Wazuh dashboard in Microsoft Edge from earlier.
  • Select File Integrity Monitoring in the dashboard navigation.
  • Select Dashboard to identify which panels summarize file activity.
  • Select Inventory to identify where monitored paths appear.
  • Select Events to identify where alert records expose their file path and event type.

You now know where Wazuh separates tracked files from alerts.

Create the local test directory

A dedicated local directory gives you a controlled place for the detection test. The C:\test path keeps this activity separate from personal files.

  • Return to the administrator Windows PowerShell window from earlier.
  • Create C:\test by running this command:
mkdir C:\test

What does this command do?

  • The mkdir command asks Windows PowerShell to create a directory.
  • The C:\test path places that directory at the top level of your local Windows drive.
  • Confirm PowerShell lists C:\test as the directory it created.

Directory not created?

  • Return to the administrator PowerShell window from earlier if Windows blocks the directory creation.
  • Confirm that you typed C:\test exactly as shown if PowerShell creates the directory somewhere else.

If the directory still does not appear, help me troubleshoot this PowerShell directory command.

Create the baseline and test visibility

A baseline file gives the coverage check an exact path to look for. Its text also records that it existed before the monitoring scope changes.

  • Press the Windows key to open the search bar.
  • Type Notepad.
  • Press Enter to open Notepad.

You will see a blank Notepad document ready for the baseline.

  • Add the baseline sentence to the blank document by copying this text:
Baseline text file created with Notepad before C:\test was added to the custom File Integrity Monitoring scope.

Why record the baseline timing?

This sentence records when the baseline was created. The timeline lets you compare coverage before and after a monitoring change.

  • Save the document to C:\test\hello.txt using Notepad's save option.
  • Confirm Notepad shows hello.txt as the saved filename.

File saved in the wrong place?

  • Use Notepad's save option again if the document title does not show hello.txt.
  • Confirm the destination path is C:\test before saving.

If the filename or location still looks wrong, help me verify this Notepad file.

✔️ Awesome, I've got everything!

That baseline is ready. It gives your scope test an exact file to find.

ⓧ I'd like to double check the full code

Baseline text file created with Notepad before C:\test was added to the custom File Integrity Monitoring scope.

An active agent creates a tempting assumption that every new file reaches Wazuh. Before you check, do you think this baseline already has a matching FIM event?

  • Switch back to File Integrity Monitoring in Microsoft Edge from earlier.
  • Select Events.
  • Refresh the event list.
  • Search the event list for C:\test\hello.txt.

You will find no matching event for C:\test\hello.txt. That shortfall is the intended result of this test.

Why is the event missing?

The agent is active. The current custom FIM scope does not include C:\test.

Wazuh therefore has no targeted FIM event for the baseline file.

Seeing a matching event?

  • Confirm the matching path is exactly C:\test\hello.txt.
  • Compare the event time with when you saved the baseline file.
  • Check whether a previous lab configuration already monitors C:\test.

If the event still appears unexpected, help me investigate the existing FIM coverage.

The monitoring blind spot is now visible. Next, you will close it with who-data monitoring and prove the baseline appears in Inventory.

Add Who-Data File Integrity Monitoring

Your blind-spot check showed that an active Wazuh agent does not automatically protect every custom directory. File Integrity Monitoring only analyzes paths inside its monitoring scope.

Who-data uses the Windows auditing subsystem to associate file activity with endpoint audit information. This step adds C:\test to that scope so the existing hello.txt can become a verified baseline.

In this step, get ready to:
  • Preserve a safety copy of the local agent configuration.
  • Enable who-data monitoring for C:\test.
  • Verify that the baseline file appears after the service reload.
Back up and open the agent configuration

The ossec.conf file controls local Wazuh agent behavior. A safety copy gives you a rollback path if the edit needs to be reversed.

File Explorer keeps the backup beside the original configuration. Both files stay outside the repository you publish later.

  • Press Windows+E to open File Explorer.
  • Press Ctrl+L to focus the address bar.
  • Enter C:\Program Files (x86)\ossec-agent and press Enter.
  • Select ossec.conf.
  • Press Ctrl+C to copy the selected file.
  • Press Ctrl+V to create the safety copy.

You now see a second configuration file in the agent folder.

  • Select the duplicated configuration file.
  • Press F2 to rename it.
  • Enter ossec.conf.backup and press Enter.
  • Confirm that ossec.conf appears in the agent folder.
  • Confirm that ossec.conf.backup appears beside it.

Why Keep the Full Configuration Local?

The full ossec.conf can contain environment-specific settings. Only the minimal reviewed configuration fragment belongs in the public repository.

Your backup gives you a clean rollback point before the editor receives administrator access. Visual Studio Code needs that access to save a file inside C:\Program Files (x86)\ossec-agent.

  • Press the Windows key to open Windows Search.
  • Type Visual Studio Code.
  • Right-click the Visual Studio Code result.
  • Select Run as administrator.
  • Select Yes on the administrator prompt.
  • Press Ctrl+O to open the file picker.
  • Enter C:\Program Files (x86)\ossec-agent\ossec.conf and press Enter.

The original ossec.conf is now open in an administrator-level editor. The backup remains unchanged beside it.

Configure who-data for the test folder

The existing <syscheck> section defines which paths Wazuh monitors. Your new directory rule places the local test folder inside that scope.

  • Locate the opening <syscheck> tag in ossec.conf.
  • Locate the matching </syscheck> tag.
  • Place your cursor on a blank line directly above </syscheck>.
  • Add the monitored directory rule by pasting this line:
  <directories whodata="yes">C:\test</directories>

What Does This Configuration Do?

  • The directories element places C:\test inside the FIM monitoring scope.
  • The whodata="yes" setting enables endpoint audit information for activity in that directory.
  • Save ossec.conf by pressing Ctrl+S.
  • Confirm that the new line appears once inside the existing <syscheck> section.
  • Leave ossec.conf in C:\Program Files (x86)\ossec-agent.
  • Leave ossec.conf.backup beside the original file.

The saved local configuration now places C:\test inside the who-data monitoring scope.

Configuration Not Saving?

Confirm that the Visual Studio Code window was launched with administrator access. A standard window cannot save changes inside the agent directory.

Check that the directory rule sits between <syscheck> and </syscheck>. Help me check my Wazuh FIM configuration.

✔️ Awesome, I've got everything!

Great. Double-check that you saved ossec.conf without changing the backup.

ⓧ I'd like to double check the full code

<syscheck>
  <directories whodata="yes">C:\test</directories>
</syscheck>
Reload the agent and verify the baseline

Restarting the Windows service forces the agent to reload ossec.conf. Windows PowerShell applies that restart from an administrator session.

  • Press the Windows key to open Windows Search.
  • Type Windows PowerShell.
  • Right-click the Windows PowerShell result.
  • Select Run as administrator.
  • Select Yes on the administrator prompt.

Before you restart the service, do you expect PowerShell to report a problem or return to the prompt?

  • Apply the FIM configuration by running this command:
Restart-Service -Name wazuh

What Does This Command Do?

The command restarts the Wazuh Windows service. The restarted agent reloads the saved File Integrity Monitoring configuration.

PowerShell returns to the prompt without an error. This confirms that the restart command completed.

The endpoint can disconnect briefly while the service reloads. Its return to active status proves that telemetry collection resumed.

  • Switch back to the Wazuh dashboard in Microsoft Edge from earlier.
  • Select Agents management.
  • Select Summary.
  • Refresh the page.

Good. Your Windows endpoint appears as active again with the updated configuration loaded.

Agent Still Disconnected?

The service may have stopped while processing the restart. You can start the installed agent without changing your FIM configuration.

  • Return to the administrator PowerShell window and start the agent by running:
Start-Service wazuhsvc

This command starts the installed agent service. Refresh Agents management after it completes.

If the endpoint remains disconnected, help me troubleshoot the Wazuh Windows service.

Before you check the inventory, do you expect hello.txt to appear now that the updated configuration is active?

  • Select File Integrity Monitoring in the Wazuh dashboard.
  • Select Inventory.
  • Locate the monitored C:\test path.
  • Confirm that hello.txt appears under that path.

That closes the blind spot. hello.txt is now indexed inside the monitored C:\test directory.

  • Redact any hostnames, agent identifiers, IP addresses, or personally identifying usernames from your Inventory screenshot.

Your baseline file is now protected by who-data monitoring. Next, you will generate a controlled deletion event and investigate the resulting alert.

Trigger and Investigate the Detection

Your who-data baseline is in place. C:\test\hello.txt appears in the monitored inventory.

File Integrity Monitoring records changes to files inside its scope. A controlled deletion lets you trace one known action through the SIEM pipeline.

You will trace the event from your Windows endpoint into Wazuh Cloud. You will preserve the result as sanitized evidence.

In this step, get ready to:
  • Trigger the monitored deletion.
  • Investigate the resulting event.
  • Save a sanitized screenshot as fim-deletion-alert.png.
Delete the monitored baseline file

A controlled test action gives the detection pipeline a known cause. Because the file already appears in the inventory, deleting it now creates a clean test signal.

Windows File Explorer removes the file from the monitored directory. Windows may ask you to confirm the deletion depending on your settings.

  • Press the Windows key to open the search bar.
  • Type File Explorer into the search bar.
  • Press Enter to open Windows File Explorer.
  • Enter C:\test in the address bar.
  • Press Enter to load the monitored directory.
  • Select hello.txt.
  • Press the Delete key.
  • Approve the deletion confirmation if Windows displays one.

You no longer see hello.txt in the folder. The monitored C:\test directory remains in place.

Investigate the deletion event

A Wazuh event gives an analyst evidence that an endpoint action reached the monitoring platform. Expanding the event reveals the context needed to validate the detection.

Before you check the dashboard, do you expect the monitored deletion to appear as a new event?

  • Switch back to the Wazuh dashboard in Microsoft Edge from earlier.
  • Select File Integrity Monitoring in the dashboard navigation.
  • Select Events.
  • Locate the newest event associated with C:\test\hello.txt.
  • Select the event to expand its details.

You will see C:\test\hello.txt with the deleted event type. You have closed the detection loop from endpoint action to searchable SIEM evidence.

  • Check that the agent matches your Windows endpoint.
  • Check that the path is C:\test\hello.txt.
  • Check that the event type is deleted.
  • Read the event description.
  • Note the rule level.
  • Review the available user details.
  • Review the available process details.

Together, these fields connect the known deletion to the monitored endpoint. They give you enough context to document why the alert is valid.

Deletion event missing?

  • Refresh Events if the latest record is not visible.
  • Return to Agents management if the event remains absent.
  • Select Summary to confirm that the Windows endpoint remains active.

Help me diagnose the missing deletion event.

Capture sanitized evidence

Security screenshots can feel sensitive because alert records may expose endpoint identity. Careful redaction protects those details before the evidence leaves your computer.

Windows Snipping Tool captures the expanded event for your report. The saved image should retain the detection details while every sensitive value stays unreadable.

What must stay private?

A useful screenshot keeps the monitored path and event type visible. Redaction removes information that could identify your cloud session or Windows endpoint.

  • Cloud credentials or session details.
  • Public or private IP addresses.
  • Hostnames.
  • Agent identifiers.
  • Personally identifying usernames.
  • Keep the expanded deletion event visible in Microsoft Edge.
  • Press the Windows key to open the search bar.
  • Type Snipping Tool into the search bar.
  • Press Enter to open Windows Snipping Tool.
  • Capture the area containing the expanded event.
  • Apply redactions to every sensitive value listed above.
  • Save the image as fim-deletion-alert.png in the same local folder as agent-active.png.

Before you review the saved image, do you expect the alert details to remain readable while every sensitive value stays hidden?

  • Return to Windows File Explorer from earlier.
  • Open the local folder containing fim-deletion-alert.png.
  • Open fim-deletion-alert.png.
  • Confirm that C:\test\hello.txt remains visible.
  • Confirm that deleted remains visible.
  • Confirm that every sensitive value listed above is unreadable.

The screenshot now preserves the alert without exposing the endpoint's identity. You have reviewable evidence for the investigation report.

Evidence still exposes identifiers?

  • Retake the screenshot with a tighter capture area if unrelated data remains visible.
  • Apply opaque redactions over any identifying value that the tighter crop must retain.

Help me review my screenshot for sensitive information.

Your controlled deletion now has a matching alert with sanitized evidence. Next, you will publish the investigation as a reusable GitHub lab.

Publish the Lab to GitHub

The deletion alert you captured proves that your Wazuh SIEM can trace a Windows file change. A screenshot alone is easy to lose.

A sanitized GitHub repository turns your investigation into a durable portfolio artifact. Other people can review the evidence without seeing private endpoint details.

In this step, get ready to:
  • Create the local repository for your lab.
  • Add the configuration fragment plus the incident report.
  • Review the evidence before publishing the repository.
Create the local repository

GitHub Desktop keeps the repository creation workflow visible. Initializing the repository with a README also gives you a tracked file to replace with your lab documentation.

  • Press the Windows key to open Windows search.
  • Type GitHub Desktop into Windows search.
  • Press Enter to open GitHub Desktop.
  • Complete the GitHub sign-in flow if GitHub Desktop asks you to authenticate.
  • Select Create a New Repository on your Hard Drive... from GitHub Desktop.
  • Enter wazuh-siem-threat-detection-lab in the repository name field.
  • Enable the option that initializes the repository with a README.
  • Confirm the repository creation form.

GitHub Desktop now shows wazuh-siem-threat-detection-lab as the current repository. The repository contains an initialized README.md file.

  • Open the current repository in Visual Studio Code from GitHub Desktop.
  • Confirm the Explorer sidebar shows the wazuh-siem-threat-detection-lab folder.
  • Confirm README.md appears inside the repository folder.

Repository creation not completing?

Confirm that GitHub Desktop shows your GitHub account before creating the repository. Complete any browser authentication window that GitHub opens.

Check that the repository name is exactly wazuh-siem-threat-detection-lab. Help me troubleshoot this repository setup.

Build and review the repository

Visual Studio Code gives you one place to assemble the configuration fragment plus the written investigation. The Markdown files explain what happened while .gitignore prevents local Wazuh configuration from entering version control.

  • Create .gitignore inside the wazuh-siem-threat-detection-lab folder using the New File icon in the Explorer toolbar.
  • Protect private Wazuh files by pasting this content into .gitignore:
# Wazuh credentials and private keys
*.key
*.pem
*.p12

# Wazuh local configuration and logs
ossec.conf
ossec.conf.*
*.log

# Private exports and working files
exports/
private/

What does this file protect?

  • The first group excludes common credential files plus private-key formats.
  • The second group excludes the complete Wazuh agent configuration plus local logs.
  • The final group excludes private working directories plus exported data.
  • Save .gitignore.
  • Confirm the Explorer sidebar lists .gitignore beside README.md.

Can't see .gitignore?

Check that the filename begins with a full stop. Confirm that the file has no hidden .txt extension.

Make sure the file sits directly inside wazuh-siem-threat-detection-lab. Help me check my .gitignore file.

✔️ Awesome, I've got everything!

Great. Your repository now has rules that keep local Wazuh configuration plus private working files out of commits.

ⓧ I'd like to double check the full code

# Wazuh credentials and private keys
*.key
*.pem
*.p12

# Wazuh local configuration and logs
ossec.conf
ossec.conf.*
*.log

# Private exports and working files
exports/
private/
  • Create the config folder inside wazuh-siem-threat-detection-lab using the New Folder icon in the Explorer toolbar.

The Explorer sidebar now shows an empty config folder inside the repository.

  • Create fim-config.xml inside the config folder using the New File icon.
  • Add the reusable who-data fragment by pasting this code into config/fim-config.xml:
<syscheck>
  <directories whodata="yes">C:\test</directories>
</syscheck>

What does this configuration do?

  • The syscheck section identifies this fragment as File Integrity Monitoring configuration.
  • The directories entry places C:\test inside the monitoring scope.
  • The whodata setting requests endpoint audit information for activity in that directory.
  • Save config/fim-config.xml.
  • Confirm the file contains only the minimal syscheck fragment.

Configuration file in the wrong place?

Confirm the Explorer sidebar shows fim-config.xml inside config. Keep the full ossec.conf outside this repository.

Check that the path remains C:\test. Help me verify this FIM configuration fragment.

✔️ Awesome, I've got everything!

Good. The repository contains the reusable fragment without exposing the complete local agent configuration.

ⓧ I'd like to double check the full code

<syscheck>
  <directories whodata="yes">C:\test</directories>
</syscheck>
  • Select README.md in the Explorer sidebar.
  • Press Ctrl+A to select the initialized README content.
  • Replace the selected content with the lab overview by pasting this first section:
# Wazuh-Based SIEM and Threat Detection Lab

## Overview

This project demonstrates a Windows threat-detection workflow using Wazuh Cloud and File Integrity Monitoring. A Windows endpoint sends telemetry through the Wazuh agent, and a controlled file deletion produces an alert for investigation.

This repository is Part 1 of a larger Wazuh SIEM, threat detection, and automated incident response lab series.

## Objectives

- Enroll a Windows endpoint in Wazuh Cloud.
- Monitor a local test directory with who-data.
- Detect and investigate deletion of a monitored file.
- Publish sanitized evidence without exposing credentials or endpoint identity.

## Lab Architecture

`Windows endpoint -> Wazuh agent -> Wazuh Cloud -> File Integrity Monitoring dashboard`

## Detection Scenario

The test file `C:\test\hello.txt` was created before the custom directory was added to the FIM scope. After who-data monitoring was configured and the agent was restarted, the file appeared in the FIM inventory. Deleting the file produced the investigated alert.

## Detection Result

| Event | Observed | Evidence |
| --- | --- | --- |
| File deleted | Yes | `evidence/fim-deletion-alert.png` |

What does this section document?

  • The overview frames the project as a Windows threat-detection workflow.
  • The objectives state the observable outcomes of the lab.
  • The architecture traces telemetry from the endpoint into the Wazuh dashboard.
  • The detection result connects the deleted event to its sanitized screenshot.
  • Save README.md.
  • Confirm the file begins with Wazuh-Based SIEM and Threat Detection Lab.
  • Confirm the current final row references evidence/fim-deletion-alert.png.

README table not aligned?

Check that each table row begins plus ends with a vertical bar. Keep the separator row directly below the table headings.

Confirm the screenshot path contains the evidence/ prefix. Help me check this Markdown table.

  • Move the cursor to the end of README.md.
  • Complete the README by pasting the remaining sections below the detection table:


## Evidence

### Active agent

![Sanitized Wazuh agent status](evidence/agent-active.png)

### File deletion alert

![Sanitized Wazuh FIM deletion alert](evidence/fim-deletion-alert.png)

## Investigation Summary

The event identified a deletion in the monitored `C:\test` directory. The alert path and event type matched the controlled test action. Available endpoint identity fields were reviewed during the investigation and redacted from the published evidence.

## Security Considerations

- The full `ossec.conf` file is not included.
- Cloud credentials, private keys, tokens, IP addresses, hostnames, agent identifiers, and personally identifying usernames are excluded or redacted.
- Only a minimal reusable FIM configuration fragment is published.

## Next Project

Part 2 will use a self-hosted Wazuh manager to implement and verify a safe automated Active Response workflow.

What do these sections add?

  • The evidence section embeds both sanitized screenshots from the lab.
  • The investigation summary connects the alert fields to the controlled deletion.
  • The security section records which private details were excluded.
  • The final section places this lab before the planned automated response work.
  • Save README.md.
  • Confirm the file now contains headings for Evidence plus Security Considerations.
  • Confirm both image references begin with evidence/.

Evidence images not referenced correctly?

Check that the filenames are exactly agent-active.png plus fim-deletion-alert.png. Filename differences prevent GitHub from rendering an image.

Keep both paths relative to README.md. Help me diagnose these Markdown image paths.

✔️ Awesome, I've got everything!

Your main README now explains the detection path plus the evidence-handling safeguards.

ⓧ I'd like to double check the full code

# Wazuh-Based SIEM and Threat Detection Lab

## Overview

This project demonstrates a Windows threat-detection workflow using Wazuh Cloud and File Integrity Monitoring. A Windows endpoint sends telemetry through the Wazuh agent, and a controlled file deletion produces an alert for investigation.

This repository is Part 1 of a larger Wazuh SIEM, threat detection, and automated incident response lab series.

## Objectives

- Enroll a Windows endpoint in Wazuh Cloud.
- Monitor a local test directory with who-data.
- Detect and investigate deletion of a monitored file.
- Publish sanitized evidence without exposing credentials or endpoint identity.

## Lab Architecture

`Windows endpoint -> Wazuh agent -> Wazuh Cloud -> File Integrity Monitoring dashboard`

## Detection Scenario

The test file `C:\test\hello.txt` was created before the custom directory was added to the FIM scope. After who-data monitoring was configured and the agent was restarted, the file appeared in the FIM inventory. Deleting the file produced the investigated alert.

## Detection Result

| Event | Observed | Evidence |
| --- | --- | --- |
| File deleted | Yes | `evidence/fim-deletion-alert.png` |

## Evidence

### Active agent

![Sanitized Wazuh agent status](evidence/agent-active.png)

### File deletion alert

![Sanitized Wazuh FIM deletion alert](evidence/fim-deletion-alert.png)

## Investigation Summary

The event identified a deletion in the monitored `C:\test` directory. The alert path and event type matched the controlled test action. Available endpoint identity fields were reviewed during the investigation and redacted from the published evidence.

## Security Considerations

- The full `ossec.conf` file is not included.
- Cloud credentials, private keys, tokens, IP addresses, hostnames, agent identifiers, and personally identifying usernames are excluded or redacted.
- Only a minimal reusable FIM configuration fragment is published.

## Next Project

Part 2 will use a self-hosted Wazuh manager to implement and verify a safe automated Active Response workflow.
  • Create the evidence folder inside wazuh-siem-threat-detection-lab using the New Folder icon.

The Explorer sidebar now shows an empty evidence folder beside config.

  • Create README.md inside the evidence folder using the New File icon.
  • Add the evidence sanitization guide by pasting this content into evidence/README.md:
# Evidence Guide

This directory contains sanitized screenshots from the lab.

Required files:

- `agent-active.png`: The Windows endpoint shown as active in Wazuh.
- `fim-deletion-alert.png`: The expanded File Integrity Monitoring deletion event.

Before committing an image, redact:

- Cloud credentials or session details
- Public or private IP addresses
- Hostnames and agent identifiers
- Personally identifying usernames
- Any unrelated endpoint or organizational data

Why include an evidence guide?

  • The required-files list explains what each screenshot proves.
  • The redaction checklist creates a reusable review standard for future evidence.
  • The guide keeps sensitive endpoint details out of the public investigation record.
  • Save evidence/README.md.
  • Confirm the file names both required screenshots.
  • Confirm the redaction list includes credentials plus endpoint identifiers.

Evidence guide saved at the top level?

Move this file into the evidence folder if it appears beside the main README.md. The repository needs one README at each documented location.

Check the Explorer breadcrumb for evidence/README.md. Help me check the evidence guide location.

✔️ Awesome, I've got everything!

The evidence folder now documents its required screenshots plus the redaction standard.

ⓧ I'd like to double check the full code

# Evidence Guide

This directory contains sanitized screenshots from the lab.

Required files:

- `agent-active.png`: The Windows endpoint shown as active in Wazuh.
- `fim-deletion-alert.png`: The expanded File Integrity Monitoring deletion event.

Before committing an image, redact:

- Cloud credentials or session details
- Public or private IP addresses
- Hostnames and agent identifiers
- Personally identifying usernames
- Any unrelated endpoint or organizational data
  • Return to Windows File Explorer from earlier.
  • Select the sanitized agent-active.png plus fim-deletion-alert.png files.
  • Press Ctrl+C to copy the selected screenshots.
  • Switch back to Visual Studio Code.
  • Select the evidence folder in the Explorer sidebar.
  • Press Ctrl+V to paste the screenshots into the folder.

The Explorer sidebar now lists agent-active.png plus fim-deletion-alert.png inside evidence.

Screenshots missing from evidence?

Confirm that both screenshots were selected before you copied them. Paste them while the evidence folder is selected in the Explorer sidebar.

Keep each filename unchanged so the README links remain valid. Help me place these screenshots correctly.

  • Create incident-report.md inside the wazuh-siem-threat-detection-lab folder using the New File icon.
  • Document the event context plus the investigation timeline by pasting this first section:
# Incident Report: Monitored File Deletion

Environment: Wazuh Cloud with a redacted Windows test endpoint
Analyst: Repository owner
Classification: Controlled File Integrity Monitoring test
Status: Closed

## Summary

Wazuh detected deletion of `C:\test\hello.txt` after the directory was placed under who-data monitoring. The activity was intentionally generated to validate the SIEM detection and investigation workflow.

## Timeline

1. The Windows endpoint enrolled successfully and appeared active.
2. The test directory and baseline file were created outside the custom FIM scope.
3. Who-data monitoring was enabled for `C:\test`.
4. The agent restarted and indexed the baseline file.
5. The file was deleted with Windows File Explorer.
6. Wazuh displayed the deletion event in File Integrity Monitoring.

## Evidence Reviewed

- Active agent status in `evidence/agent-active.png`.
- Expanded deletion alert in `evidence/fim-deletion-alert.png`.
- Sanitized configuration fragment in `config/fim-config.xml`.

What does this report establish?

  • The header classifies the event as a controlled test with a closed status.
  • The timeline records the blind spot plus the monitoring fix in order.
  • The evidence list links each conclusion to a repository artifact.
  • Save incident-report.md.
  • Confirm the timeline contains six numbered events.
  • Confirm the evidence list references both screenshots plus the configuration fragment.

Incident timeline incomplete?

Check that the numbered list begins with endpoint enrollment. Confirm that it ends with the Wazuh deletion event.

Keep the screenshot paths inside backticks. Help me review this incident timeline.

  • Move the cursor to the end of incident-report.md.
  • Complete the report by pasting the analysis plus the lessons learned below the evidence list:


## Analysis

The alert path matched the monitored directory and the event type matched the controlled deletion. This confirmed that endpoint collection, FIM analysis, indexing, and dashboard investigation were operating as intended.

## Containment and Recovery

No production containment was required because the activity occurred in a dedicated local test directory. The alert evidence was preserved, the test action was documented, and sensitive endpoint data was removed from the public artifacts.

## Lessons Learned

- Agent enrollment alone does not place every custom directory inside the intended monitoring scope.
- FIM scope must reflect the files that matter to the organization.
- Security evidence must be sanitized before publication.

What do these conclusions show?

  • The analysis confirms that collection plus investigation worked from endpoint to dashboard.
  • The containment section explains why the controlled test required no production response.
  • The lessons turn the investigation into reusable monitoring guidance.
  • Save incident-report.md.
  • Confirm the final section contains three lessons learned.
  • Confirm the report contains no hostname or agent identifier.

Report contains endpoint details?

Replace any identifying endpoint value with the existing redacted description. Keep credentials plus personally identifying usernames out of the report.

Review every environment field before continuing. Help me sanitize this incident report.

✔️ Awesome, I've got everything!

Your incident report now records the alert timeline plus the conclusions supported by the sanitized evidence.

ⓧ I'd like to double check the full code

# Incident Report: Monitored File Deletion

Environment: Wazuh Cloud with a redacted Windows test endpoint
Analyst: Repository owner
Classification: Controlled File Integrity Monitoring test
Status: Closed

## Summary

Wazuh detected deletion of `C:\test\hello.txt` after the directory was placed under who-data monitoring. The activity was intentionally generated to validate the SIEM detection and investigation workflow.

## Timeline

1. The Windows endpoint enrolled successfully and appeared active.
2. The test directory and baseline file were created outside the custom FIM scope.
3. Who-data monitoring was enabled for `C:\test`.
4. The agent restarted and indexed the baseline file.
5. The file was deleted with Windows File Explorer.
6. Wazuh displayed the deletion event in File Integrity Monitoring.

## Evidence Reviewed

- Active agent status in `evidence/agent-active.png`.
- Expanded deletion alert in `evidence/fim-deletion-alert.png`.
- Sanitized configuration fragment in `config/fim-config.xml`.

## Analysis

The alert path matched the monitored directory and the event type matched the controlled deletion. This confirmed that endpoint collection, FIM analysis, indexing, and dashboard investigation were operating as intended.

## Containment and Recovery

No production containment was required because the activity occurred in a dedicated local test directory. The alert evidence was preserved, the test action was documented, and sensitive endpoint data was removed from the public artifacts.

## Lessons Learned

- Agent enrollment alone does not place every custom directory inside the intended monitoring scope.
- FIM scope must reflect the files that matter to the organization.
- Security evidence must be sanitized before publication.

The Changes view is your final security gate before publication. It shows the exact files GitHub Desktop is preparing to commit.

  • Switch back to GitHub Desktop.
  • Open the Changes view.
  • Confirm the top-level changes include .gitignore, README.md, plus incident-report.md.
  • Confirm the configuration change is config/fim-config.xml.
  • Confirm the evidence changes include evidence/README.md plus both sanitized screenshots.
  • Confirm the complete ossec.conf file does not appear in the changes.
  • Open each screenshot from the Changes view.
  • Confirm every credential plus endpoint identifier remains redacted.

That review closes the riskiest gap in the publishing workflow. Your repository contains useful evidence without exposing the endpoint behind it.

Commit and publish the lab

A Git commit records the reviewed repository as one traceable version. Publishing that commit makes the documentation available from a stable public URL.

  • Keep every reviewed repository file selected in the Changes view.
  • Enter Publish sanitized Wazuh SIEM lab in the commit summary field.
  • Commit the selected files to the current branch using the GitHub Desktop commit control.

GitHub Desktop now shows a clean Changes view. The commit history contains the sanitized lab snapshot.

Commit control unavailable?

Confirm that at least one reviewed file remains selected. Add the commit summary before trying the commit again.

Return to Visual Studio Code if an unsaved file is missing from Changes. Help me troubleshoot this GitHub Desktop commit.

Publishing makes these repository files visible to anyone. Your Changes review has already removed the private configuration plus identifying endpoint data.

  • Select Publish repository in GitHub Desktop.
  • Leave Keep this code private unselected.
  • Confirm the repository publication.

GitHub Desktop finishes publishing the commit to your GitHub account. The repository is now public.

Publication not completing?

Confirm that GitHub Desktop is signed in to the GitHub account where you want the repository to appear. Complete any browser authentication request.

Check your internet connection before retrying the publication. Help me troubleshoot this repository publication.

Before you open the public repository, which documentation files plus evidence images do you expect GitHub to display?

  • Open the Repository menu in GitHub Desktop.
  • Select View on GitHub.

The browser opens the public wazuh-siem-threat-detection-lab repository. You can see the main README plus the configuration folder, incident report, evidence guide, active-agent screenshot, and deletion-alert screenshot.

Published files missing on GitHub?

Return to GitHub Desktop and check for uncommitted changes. Missing files usually remain in the local Changes view.

Confirm that you opened the public repository from the current GitHub Desktop repository. Help me compare my local and published files.

You now have a public investigation package that connects Windows telemetry to a reviewed Wazuh deletion alert. The evidence remains useful while the endpoint identity stays private.

Secret mission

Build a File-Change Detection Matrix

Generate and correlate creation, modification, and deletion events for a second test file. Publish the three-event detection matrix with sanitized evidence in your GitHub repository.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep collecting telemetry, pause the Windows agent, or remove the lab resources. The 14-day Wazuh Cloud trial costs $0 when no payment method is added.

Resources you used:

  • A Wazuh Cloud trial environment containing your endpoint telemetry and File Integrity Monitoring events.
  • A Windows Wazuh agent version 4.14.7 installation.
  • A monitored C:\test directory configured with File Integrity Monitoring and who-data.

Your public GitHub repository wazuh-siem-threat-detection-lab is the finished lab record. These cleanup options keep it online.

Keep everything running

No action is needed while you want to continue collecting lab telemetry. Wazuh deletes the cloud environment when the trial expires if you do not add billing information.

  • Leave the Wazuh service running on your Windows endpoint.
  • Continue reviewing controlled activity in the Wazuh dashboard until the trial expires.
  • Avoid adding billing information unless you intend to continue with a paid environment.
  • Keep the sanitized wazuh-siem-threat-detection-lab repository available as your published lab record.

Pause - I'll come back to this later

Pausing collection stops endpoint telemetry while preserving the cloud environment during the trial. Your endpoint appears disconnected until the Wazuh service starts again.

  • Press the Windows key to open search.
  • Type Services and press Enter.
  • Find Wazuh in the services list.
  • Select the Wazuh service.
  • Select Stop.

The Wazuh service now shows a stopped state. Your cloud environment remains available during the trial.

Delete - I don't want to use this again

Complete removal is irreversible. Your sanitized GitHub repository stays online as the published lab record.

Remove the Windows agent:

  • Press the Windows key to open search.
  • Type Windows PowerShell.
  • Select Run as administrator from the search results.
  • Approve the administrator prompt.
  • Switch PowerShell to the folder containing wazuh-agent-4.14.7-1.msi.
  • Uninstall the Wazuh agent by running this command:
msiexec.exe /x wazuh-agent-4.14.7-1.msi /qn

What does this command do?

  • The msiexec.exe program asks Windows Installer to manage the agent package.
  • The /x option removes the installed package.
  • The /qn option runs the uninstall without opening a wizard.
  • Press the Windows key to open search.
  • Type Services and press Enter.
  • Look for Wazuh in the services list.

You should no longer see the Wazuh service in the list. The endpoint can no longer send telemetry to the cloud environment.

Agent Still Installed?

Confirm that wazuh-agent-4.14.7-1.msi is in PowerShell's current directory. Confirm that the PowerShell title bar shows administrator access.

If the original installer is missing, retrieve the same package from the official Windows agent installation guide. Help me troubleshoot the Wazuh agent uninstall.

Delete the local test directory:

  • Press the Windows key to open search.
  • Type File Explorer and press Enter.
  • Enter C:\ in the address bar.
  • Press Enter.
  • Select the test folder.
  • Right-click the selected folder.
  • Select Delete.

You should no longer see test under C:\.

Cancel the Wazuh Cloud environment:

  • Return to the Wazuh Cloud console in Microsoft Edge.
  • Select Environments.
  • Select your trial environment.
  • Select Manage.
  • Select Cancel environment.
  • Enter CANCEL in the confirmation field.
  • Complete the cancellation confirmation.

Wazuh permanently deletes the environment data when cancellation completes. Your local agent and test directory are already removed.

Nice Work!

Nice Work!

You did it! Your Windows endpoint now feeds a Wazuh Cloud SIEM workflow through an active agent. Your sanitized public GitHub repository documents the investigation from monitored activity to evidence.

You've learned how to:

  • Connect a Windows endpoint to Wazuh Cloud so its active agent delivers SIEM telemetry.
  • Expose a File Integrity Monitoring blind spot in C:\test. Close it with who-data monitoring.
  • Turn a controlled deleted alert into a sanitized incident report. Publish reusable evidence in a public security repository.
  • Secret Mission: Correlate added, modified, and deleted events for C:\test\lifecycle.txt. Publish the full file-change detection matrix.

Ready to quiz yourself?