Post cover image

October 19, 2026

Building a SOC Lab with Wazuh, Sysmon, Custom Detection Rules, and File Integrity Monitoring

Introduction

By Oluwatosin Adewumi

9 min read

Introduction

One of the things I have learned while building my cybersecurity skills is that installing a security tool is only the beginning. The real learning happens when you configure it, generate activity, investigate the resulting events, and determine whether your monitoring system can identify what is happening across your environment.

That was the motivation behind building my SOC lab, Project Sentinel.

I wanted to move beyond simply exploring a SIEM dashboard and build an environment where I could collect endpoint telemetry, investigate Windows activity, write custom detection rules, and monitor file changes across Windows and Linux systems.

For this project, I used Wazuh as my security monitoring platform, Sysmon for additional endpoint telemetry, and virtual machines to simulate a small enterprise environment.

My objectives were to:

  • Deploy and configure Wazuh.
  • Enable archive logging and make the archived events searchable.
  • Connect Windows and Ubuntu endpoints to the Wazuh manager.
  • Integrate Sysmon telemetry.
  • Investigate Windows user and account management activity.
  • Develop a custom rule for Windows Guest account enablement.
  • Configure File Integrity Monitoring on Windows and Ubuntu.
  • Build a dashboard to visualize security events.
None

1. Deploying Wazuh

I started by deploying Wazuh on an Ubuntu Server virtual machine. I used VMware Workstation to build the virtual environment and accessed the Ubuntu server remotely through SSH from Windows PowerShell.

After preparing the server, I installed Wazuh using the all-in-one installation method. This provided the core components needed for the lab, including the Wazuh manager, indexer, and dashboard.

The manager processes security events and applies detection rules. The indexer stores and makes indexed events searchable, while the dashboard provides an interface for monitoring and investigation.

Once the installation was complete, I accessed the Wazuh dashboard and began configuring the environment.

None None

2. Enabling Wazuh Archive Logging

One of the next things I wanted to understand was how to retain and investigate events beyond the alerts generated by Wazuh.

Wazuh archive logging can preserve events received and processed by the platform, depending on the configured collection sources. This is useful when investigating activity that may not have triggered a security alert.

To enable this functionality, I modified the Wazuh manager configuration file, ossec.conf, using Nano.

I enabled the archive-related logging settings:

<logall>yes</logall>
<logall_json>yes</logall_json>

I then saved the configuration and restarted the Wazuh manager to apply the changes.

Next, I edited the Filebeat configuration file, filebeat.yml, and enabled the Wazuh archives module:

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: true

After saving the file, I restarted Filebeat.

This step taught me that enabling archive logging on the manager is not the entire process. The forwarding and indexing pipeline must also be configured correctly before the archived events become available for searching.

None None

Creating the archive index pattern

After configuring the manager and Filebeat, I opened the index pattern section of the Wazuh dashboard and created an index pattern for:

wazuh-archives-*

I selected the timestamp field to enable time-based filtering and searching.

This allowed me to explore the archived events available in the index and use the dashboard's time controls when investigating activity.

None

3. Connecting Windows and Ubuntu Endpoints

With the Wazuh server configured, I moved on to endpoint onboarding.

I created separate Windows and Ubuntu virtual machines and connected both to the Wazuh manager.

From the Wazuh dashboard, I selected the option to deploy a new agent, chose the appropriate operating system, and followed the generated installation and enrollment instructions.

On Windows, I ran the required commands with administrator privileges. On Ubuntu, I executed the commands in the terminal. I then started the respective agent services.

This step was important because a centralized monitoring platform is only useful when it receives relevant data from the systems it is expected to monitor.

By connecting both operating systems, I could explore endpoint monitoring across Windows and Linux rather than limiting the lab to a single machine.

None

4. Integrating Sysmon on Windows

The next phase was improving the visibility available from my Windows endpoint.

I downloaded Microsoft Sysmon and obtained a Sysmon configuration from Olaf Hartong's Sysmon configuration repository.

Sysmon provides detailed system activity records, including selected process creation and other system events, depending on the configuration in use.

I installed Sysmon with the configuration file using an elevated terminal:

.\Sysmon.exe -i .\sysmonconfig.xml

The configuration file determines which Sysmon events are collected. This means the quality and scope of the telemetry depend partly on the configuration selected.

However, installing Sysmon alone does not automatically make its events visible in Wazuh. I also needed to configure the Wazuh agent to collect the relevant Windows event channel.

None

Forwarding Sysmon events to Wazuh

I opened the Wazuh Windows agent configuration file, ossec.conf, using a text editor and added the following configuration:

<localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>

This tells the Wazuh agent to collect events from the Windows Sysmon Operational event channel.

I located the channel in Windows Event Viewer, saved the configuration, and restarted the Wazuh agent service.

This was a useful lesson in understanding the relationship between endpoint telemetry and centralized monitoring: Sysmon generates the events, the Wazuh agent collects the configured event source, and Wazuh processes the events it receives.

None None None

5. Setting Up Sysmon for Linux

I also explored Sysmon for Linux on my Ubuntu endpoint.

I followed the installation procedure for the Linux version, obtained a Linux-compatible Sysmon configuration file, and configured the executable to use that file.

The purpose was to extend the lab's endpoint monitoring beyond Windows.

Sysmon for Linux and Microsoft Sysmon for Windows have different installation and configuration requirements, so I treated them as separate integrations rather than assuming the Windows setup would work unchanged on Linux.

This part of the lab helped me explore how endpoint telemetry can support investigations across different operating systems.

None

Note: If you have evidence of Linux Sysmon events arriving in Wazuh, include that screenshot here as well. If you only confirmed the installation, describe this as an installation and configuration step rather than claiming that end-to-end event forwarding was verified.

6. Investigating Windows Account Activity

Once the endpoints were connected, I began generating activity in the Windows environment and investigating the resulting events in Wazuh.

I used commands such as:

whoami
ipconfig /all
net user
net localgroup administrators

These commands helped me examine the current user context, network configuration, local accounts, and membership of the local Administrators group.

I also investigated account-management operations in the isolated lab, including enabling the built-in Guest account, creating a temporary local user, adding that user to the Administrators group, and removing the test account afterward.

For example, the Guest account enablement command was:

net user guest /active:yes

I used these actions to generate activity that I could investigate through the monitoring platform.

The key learning was that performing a command and seeing its output on the endpoint is different from confirming that the activity was collected, indexed, and detected by the SIEM.

I therefore used the Wazuh dashboard to examine the events available from my testing.

None

7. Writing a Custom Wazuh Detection Rule

One of the most valuable parts of this project was writing a custom detection rule for Windows Guest account enablement.

I created a rule with ID 100200, configured to match Windows Security Event ID 4722 and check the target username against the built-in Guest account.

Event ID 4722 indicates that a user account was enabled. By adding a condition for the Guest account, I aimed to identify a specific account change that could warrant further investigation.

The relevant part of my rule was:

<rule id="100200" level="12">
    <if_sid>60100</if_sid>
    <field name="win.system.eventID">^4722$</field>
    <field name="win.eventdata.targetUserName"
           type="pcre2">^Guest$</field>
    <description>
        MYDFIR-Tosin Windows Guest account was enabled
        (Event ID 4722).
    </description>
</rule>

This was an opportunity to move beyond relying exclusively on built-in alerts and understand how detection logic can be adapted to a specific monitoring requirement.

The rule's usefulness depends on the relevant Windows event being audited, collected by the agent, and correctly decoded by Wazuh.

None

What about detecting account disablement?

Enabling and disabling an account are different Windows security events. Event ID 4722 is associated with account enablement, while Event ID 4725 is associated with account disablement.

If you created and tested a separate rule for Event ID 4725, include that rule and its corresponding alert as additional evidence.

[INSERT IMAGE 14 HERE: Your Guest account enablement alert in Wazuh, with the rule ID and event details visible.]

Figure 14: Reviewing a Guest account enablement detection in Wazuh.

None

The rule configuration demonstrates the detection logic I wrote. The alert screenshots demonstrate whether the rules successfully matched events generated during testing. Both are important when documenting a detection engineering project.

8. Implementing File Integrity Monitoring on Windows and Ubuntu

Another major part of the lab was File Integrity Monitoring (FIM).

FIM helps identify changes to monitored files and can support investigations into unexpected modifications, unauthorized changes, and potential tampering.

I configured FIM for both my Windows and Ubuntu endpoints. I then tested file changes and reviewed the resulting events in the Wazuh dashboard.

On my Ubuntu endpoint, Wazuh recorded a modification to:

/opt/company-data/test.txt

The event showed a modified action and the rule description Integrity checksum changed.

This provided concrete evidence that Wazuh detected a change to a monitored file.

The screenshot below captures the result from my actual lab.

[INSERT IMAGE 16 HERE: Your Ubuntu FIM screenshot showing Maya-ubuntu, /opt/company-data/test.txt, the modified event, and rule 550.]

Figure 16: Wazuh detecting a monitored file modification on Ubuntu.

None

This exercise helped me understand why FIM is useful in security monitoring. Instead of relying only on activity logs, an analyst can also examine changes to selected files and use the associated event details to guide further investigation.

9. Building a Security Monitoring Dashboard

After configuring the data collection and detection components, I built a dashboard to bring relevant security information into one view.

The goal was to make the available telemetry easier to explore and to provide a visual overview of events generated by the endpoints.

A useful monitoring dashboard should do more than look attractive. Its visualizations should answer meaningful questions, such as which endpoints are generating events, which detections are firing, and what activity deserves further investigation.

None

If your dashboard contains charts for alert levels, event types, agents, or file integrity events, briefly explain what each visualization tells you. Only describe charts and metrics that are actually present in your screenshot.

10. Lessons Learned

Building this lab gave me several practical lessons.

1. Configuration changes need verification.

Enabling a setting is only one step. I had to restart the relevant services and confirm that the expected data became available in the dashboard.

2. Telemetry collection and detection are different tasks.

Sysmon can generate detailed endpoint events, but the Wazuh agent must collect the appropriate source. A detection rule must then match the resulting event before the expected alert appears.

3. Detection rules need testing.

Writing a custom rule is not enough. Testing it with the relevant event helps establish whether its conditions work as intended and whether the alert contains useful information for an investigation.

4. Different operating systems provide different investigation opportunities.

Working with Windows and Ubuntu helped me explore endpoint monitoring across two environments and understand the importance of configuring each appropriately.

5. Evidence matters.

Screenshots, event records, configuration files, and test results make a technical project easier to review and explain. They also help distinguish a successfully tested capability from a feature that was only configured.

Conclusion

Project Sentinel gave me practical experience building and configuring a small SOC monitoring environment with Wazuh.

I deployed the monitoring platform, enabled archive logging, connected Windows and Ubuntu agents, integrated Sysmon telemetry, investigated Windows account activity, wrote a custom Guest account detection rule, configured File Integrity Monitoring, and built a dashboard.

The most important outcome was not simply getting the tools running. It was learning how the components work together, how to generate test activity, and how to investigate the evidence available through a centralized security monitoring platform.

This lab is a foundation for my continued work in detection engineering, threat hunting, and incident response. My next step is to expand the detection rules, validate them with additional controlled scenarios, and document the findings in a way that other learners can reproduce.

For me, this is what hands-on cybersecurity learning should look like: build, test, investigate, document, and improve.

Tools and technologies: Wazuh, Microsoft Sysmon, Sysmon for Linux, Ubuntu Server, Windows, VMware Workstation, Filebeat, Windows Event Viewer, and custom Wazuh rules.