Skip to content
Security Notes

Sysmon and Wazuh: building a detection homelab end to end

By Elias Lankinen11 min read

The alert that isn't there

Most home networks are compromised in silence. A machine gets a malicious Office macro, a process spawns powershell.exe with an encoded command, that PowerShell reaches out to an IP in another country, downloads a second-stage payload, and reads the memory of a system process to steal cached passwords. On a default Windows install, almost none of that leaves a usable trace. The Security event log will note a logon here and a service install there, but the actual sequence, the story of the intrusion, evaporates. You cannot investigate what you never recorded. This is the gap a detection homelab exists to close. The premise is simple and, for a lot of people, surprisingly cheap: take two free tools, one that generates rich records of what Windows is really doing and one that collects and reasons over those records, wire them together, and you have a working approximation of what a corporate security operations center runs. You can then attack your own lab and watch the alerts fire, or fail to. The two tools are Sysmon and Wazuh. Neither is a toy. Both are used in production by real organizations. And putting them together teaches you something no vendor demo will: detection is not a product you install, it is a thing you build and tune, and most of the difficulty lives in the tuning.

Source: UMD-Eskin, Wikimedia Commons
Source: UMD-Eskin, Wikimedia Commons

Sysmon: turning Windows into a witness

System Monitor, or Sysmon, is a free Windows system service and device driver from Microsoft's Sysinternals group, written by Mark Russinovich and Thomas Garnier. ("Sysinternals" is the utility suite Russinovich co-founded in the 1990s, later acquired by Microsoft.) Once installed, according to Microsoft's documentation, Sysmon "remains resident across system reboots to monitor and log system activity to the Windows event log." It installs a boot-start driver so it can capture activity from early in the boot process, before most kernel-mode malware gets a chance to load, and the service runs as a Windows protected process to make it harder to tamper with. Two things Sysmon deliberately does not do are worth stating up front, because they are the source of most confusion. It does not analyze the events it generates, and it does not try to hide from an attacker who goes looking for it. Sysmon is a witness, not a detective and not a spy. Analysis is somebody else's job, which is exactly why you pair it with Wazuh. What makes Sysmon valuable is the specificity of what it records. Native Windows logging will tell you a process started; Sysmon's Event ID 1 (process creation) records the full command line, the parent process and its command line, the account, and a cryptographic hash of the executable, plus a ProcessGUID, a unique identifier that survives even when Windows recycles a numeric process ID. That last detail matters more than it sounds: it lets you reconstruct a chain of ancestry, winword.exe spawned cmd.exe spawned powershell.exe, without the ambiguity that reused process IDs introduce. The full catalogue runs to roughly thirty event types. A few carry outsized weight for detection:

  • Event ID 3 (network connection) links each TCP/UDP connection to the process that made it, with source and destination IPs, ports, and hostnames.
  • Event ID 7 (image load) records DLLs being loaded into a process, useful for catching malicious library injection.
  • Event ID 8 (CreateRemoteThread) fires when one process creates a thread inside another, a classic code-injection move.
  • Event ID 10 (process access) records when one process opens a handle into another's memory. This is the single most important line of defense against credential theft, and we will come back to it.
  • Event ID 11 (file create), 12–14 (registry), and 22 (DNS query) round out the picture of what a program touches. DNS logging, incidentally, was only possible from Windows 8.1 onward, because the underlying telemetry did not exist on Windows 7.
  • Event ID 15 (FileCreateStreamHash) is a quiet gem: it captures the "mark of the web," the Zone.Identifier stream browsers attach to downloaded files, so you can see which executables arrived from the internet.
Source: Wikimedia Commons
Source: Wikimedia Commons

The configuration is the product

Here is the misconception that trips up nearly everyone starting out: they install Sysmon, run sysmon -i -accepteula, and assume they now have visibility. They do not. A default install logs process creation and a few other basics but leaves network connections, image loads, and process-access monitoring switched off, because those are the noisiest and most performance-sensitive events. An untuned Sysmon is close to useless, and a naively "log everything" Sysmon will bury you and slow the machine down. Event ID 3 and Event ID 7 alone can generate the bulk of a system's log volume. The real artifact is the configuration file, an XML document that decides which events to capture and, crucially, which to throw away. Sysmon's filtering language is expressive: each event type gets include and exclude rule sets, exclude wins ties, and individual field conditions support operators like contains, begin with, end with, is, and image (which matches an executable by name regardless of path). You can, for instance, log every network connection except those made by your browser to ports 80 and 443, cutting the noise floor dramatically while keeping the anomalies. Almost nobody writes these from scratch. Two community configurations are the standard starting points. SwiftOnSecurity's sysmon-config is a heavily commented, opinionated template with sane defaults that capture high-value events and filter known-benign noise. Olaf Hartong's sysmon-modular takes a different approach: it splits the rules into modules, each mapped to MITRE ATT&CK techniques, and updates frequently as new techniques emerge. Both are excellent, and both come with the same warning, echoed by practitioners like TrustedSec: every network is different, and you must review the config and exclude what is noisy-but-normal in your environment. Tuning is not a one-time step; it is the job.

Wazuh: the analyst that never sleeps

If Sysmon is the witness, Wazuh is the detective, the case file, and the filing cabinet combined. It bills itself as a unified open-source XDR and SIEM platform. Those acronyms are worth unpacking. SIEM (Security Information and Event Management) means collecting logs from across an estate and correlating them to spot threats and satisfy compliance. XDR (Extended Detection and Response) is the newer, marketing-inflected term for doing that across endpoints, cloud, and network with automated response bolted on. In practice, for a homelab, Wazuh is the thing that ingests your Sysmon events and decides which ones are alarming. Wazuh has a longer lineage than its 2015 birth date suggests. It is a fork of OSSEC, a host-based intrusion detection system that Daniel Cid founded in 2004. OSSEC was acquired by Third Brigade in 2008, which Trend Micro in turn acquired in 2009, and development slowed over the following years. In 2015 Santiago Bassett started the Wazuh fork to modernize it, and, as historical write-ups of the project note, Wazuh retains compatibility with OSSEC's decoders and rules while adding a search backend, a dashboard, MITRE ATT&CK mapping, and vulnerability detection. It remains free and open source, developed by Wazuh Inc., with the source on GitHub. The platform has four components, and understanding the split helps you reason about where things break:

  1. The agent runs on each monitored endpoint (Windows, Linux, macOS, and several Unix variants). It reads logs, including the Sysmon event log, and forwards them securely to the server.
  2. The server, or manager, is the brain. It runs incoming events through decoders (which parse raw log text into structured fields) and then rules (which decide whether a structured event is worth an alert and at what severity). Wazuh ships thousands of rules and, per its own documentation, a single server can analyze data from hundreds or thousands of agents.
  3. The indexer is a full-text search and analytics engine (built on the OpenSearch lineage of Elasticsearch) that stores and indexes the resulting alerts.
  4. The dashboard is the web interface where you hunt through alerts, view MITRE ATT&CK coverage, and generate compliance reports mapped to standards like PCI DSS, HIPAA, and NIST 800-53. There is a fifth capability that turns detection into defense: active response. Wazuh can be configured to run a script when a rule fires, killing a process, blocking an IP at the firewall, or disabling an account, which means your homelab can not only see the LSASS dump but sever it mid-attack.

Wiring it together

The minimum viable lab is three machines, and they can all be virtual on a single host with a modest amount of RAM. You need one Linux box for the Wazuh server, indexer, and dashboard (they can share a machine in a lab, though production splits them), one Windows victim machine running Sysmon with the Wazuh agent installed, and, ideally, one attacker machine, typically a Kali Linux install, from which you launch simulated attacks. An isolated virtual network keeps the whole thing off your real LAN. The integration point is a single instruction to the Windows agent: tell it to read the Sysmon channel. That means editing the agent's config to add a localfile block pointing at Microsoft-Windows-Sysmon/Operational, the event-log location where Sysmon writes. From that moment, every Sysmon event flows to the manager. Wazuh already ships decoders and rules for Sysmon fields, so you get baseline coverage immediately, and you can layer custom rules on top for the techniques you specifically want to catch. The workflow, once running, is a loop. You simulate an attack, watch the dashboard, and if nothing fires, you dig into why. Was the event even generated (a Sysmon config problem)? Did it reach the manager (an agent or network problem)? Did a decoder parse it (a decoder problem)? Did a rule match (a rule problem)? Wazuh's dashboard includes a ruleset-testing tool where you can paste a raw event and watch exactly which decoder and rule it hits, which turns that four-way guessing game into a diagnosis. This debugging loop, unglamorous as it is, is where the actual learning happens.

A worked example: catching credential theft

The canonical first detection is credential dumping from LSASS, and it is worth walking through because it shows every layer cooperating. LSASS, the Local Security Authority Subsystem Service, holds credential material in memory after a user logs in, hashes, Kerberos tickets, sometimes plaintext. Tools like Mimikatz read that memory to harvest it, and the technique is catalogued by MITRE as T1003.001, LSASS Memory, a sub-technique of T1003, OS Credential Dumping. It is one of the most common moves in real intrusions because stolen credentials are the key to spreading across a network. To read LSASS's memory, an attacker's process must first open a handle into it, and that is precisely what Sysmon's Event ID 10 (process access) records. Microsoft's own documentation calls this out directly: process access monitoring enables detection of tools that "read the memory contents of processes like Local Security Authority (Lsass.exe) in order to steal credentials." A well-tuned config includes a rule for any process opening lsass.exe with high-privilege access rights, while excluding the handful of legitimate Windows processes that do so routinely, otherwise the alert drowns in noise. The detection chain runs like this: the attacker runs Mimikatz or procdump against LSASS; Sysmon emits an Event ID 10 naming the source process and lsass.exe as the target; the Wazuh agent ships it; a Wazuh rule matches on the target image and access mask; an alert appears on the dashboard tagged with T1003.001; and, if you have wired up active response, Wazuh kills the offending process and can disable the account behind it. Multiple published homelab walkthroughs, such as this Wazuh-and-Sysmon LSASS detection lab, reproduce exactly this flow end to end. The MITRE tag is not decoration. The ATT&CK framework, which MITRE developed internally starting in 2013 and released publicly in May 2015, is a shared vocabulary of adversary behavior: every technique has a stable ID, and mapping your alerts to those IDs lets you reason about coverage, which attacker behaviors you can see and which you are blind to, rather than just counting raw alerts. It reframes the question from "how many alerts did I get" to "what can an attacker do in my environment without me noticing," which is the question that actually matters.

Source: Gregory Maxwell, Wikimedia Commons
Source: Gregory Maxwell, Wikimedia Commons

Where the lab lies to you

A homelab is a model, and models mislead in instructive ways. Three deserve naming. First, volume. Your lab has a handful of machines producing a trickle of events, so noisy rules look fine and expensive Sysmon settings feel free. Scale that to a few hundred endpoints and the same configuration floods the indexer, blows past your storage, and buries analysts in false positives. The tuning that feels optional in a lab is survival at scale, which is why the community configs exist and why they warn you to customize. Second, evasion. Sysmon does not hide, by design, and a competent attacker can enumerate it, unload its driver, or simply avoid the specific behaviors your rules watch for. There is an entire cat-and-mouse literature on tampering with Sysmon and on techniques that never touch LSASS the obvious way. A green dashboard means your rules caught what you tested, not that you are safe. Third, the alert-to-response gap. Detecting the LSASS dump after it completes means the credentials are already stolen; active response mitigates but does not un-ring the bell. Real defense is layered, and detection is the layer that assumes the earlier ones failed. None of this is an argument against building the lab. It is the argument for it. The value is not the running system at the end; it is the reps, watching a detection fail, tracing why through decoder and rule, and internalizing that the security you get from these tools is proportional to the attention you pour into them, not the price you paid, which is zero. The uncomfortable question the lab leaves you with is the one every real defender lives with: not "is my dashboard green," but "what is happening on my machines right now that I simply never told anything to look for?"

Sources

  1. Microsoft Learn, Sysmon - Sysinternals (2026)
  2. SwiftOnSecurity, sysmon-config: Sysmon configuration file template (2024)
  3. Olaf Hartong, sysmon-modular: A repository of Sysmon configuration modules (2026)
  4. TrustedSec, Building a Detection Foundation: Part 4 - Sysmon (2024)
  5. Wazuh, Components Overview, Wazuh documentation (2026)
  6. Wazuh, wazuh/wazuh source repository (2026)
  7. Noze, OSSEC: Open Source HIDS, Wazuh's ancestor (2024)
  8. MITRE ATT&CK, OS Credential Dumping: LSASS Memory, T1003.001 (2026)
  9. Wikipedia, ATT&CK (2026)
  10. Stevanus Banu, SIEM Lab: Detecting LSASS Credential Dumping (T1003.001) with Wazuh and Sysmon (2024)