# olafhartong/sysmon-modular: a Sysmon config built from small XML modules

> Sysmon Modular splits a Sysmon configuration into per-event modules that a Go CLI merges into deployable XML. It suits teams who need to review and tune endpoint telemetry rather than accept a single monolithic config.

**olafhartong/sysmon-modular** — A repository of sysmon configuration modules

- Repository: https://github.com/olafhartong/sysmon-modular
- Stars: 3,145 · Forks: 664
- Language: Go
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/olafhartong-sysmon-modular

## What problem the module layout solves

A Sysmon configuration is one XML document covering every event type the driver can emit. Once it grows past a few hundred lines, reviewing it means scrolling through process creation rules to find a registry exclusion, and a change made for a server role can quietly alter what a workstation collects. Sysmon Modular addresses that by keeping the source material in numbered top-level directories that map to Sysmon event IDs: 1_process_creation, 3_network_connection_initiated, 7_image_load, 11_file_create, 22_dns_query, 23_file_delete and so on. The repository description is simply "a repository of sysmon configuration modules", and that is the design: small XML fragments you can select, review and maintain individually.

The intended audience is the person who owns endpoint telemetry. That means detection engineers, DFIR staff and threat hunters who need to justify why an event ID is collected, and who have to answer when someone asks why a particular process is excluded. The README frames each generated configuration as "a starting point" and asks for review against applications, endpoint roles, detection needs and logging budget. The project traces its lineage to SwiftOnSecurity's original configuration, which the README credits as the inspiration and part of the foundation. If your organisation has never tuned a Sysmon config and simply needs one running, the module layout adds a review step you may not want.

## How modules become a deployable XML file

The source of truth is the numbered directories at the repository root. Each holds XML fragments for its event ID. The Go tool reads those fragments and emits a single consolidated configuration. The tooling lives under tooling/ and the CLI is described as the supported generator; the repository also carries a config-build.yml workflow under .github/, which matches the README's statement that consolidated files are generated and distributed as release assets rather than committed to the repository.

That last point matters for how you consume the project. Cloning the repository does not hand you a ready sysmonconfig.xml at the root. You either download a release asset or run the generator yourself. The release pipeline produces three named profiles: sysmonconfig.xml for the regular starting configuration without FileDelete archiving, sysmonconfig-with-filedelete.xml which adds FileDelete collection and file archiving, and sysmonconfig-excludes-only.xml, described as a very verbose profile built from exclusion modules. Each is generated for Sysmon 15.21, 14.16, 13.34 and 12.03, with versioned filenames such as sysmonconfig-14.16.xml and the unversioned names acting as aliases for 15.21. Releases also carry prebuilt binaries, an ATT&CK Navigator layer derived from the balanced 15.21 configuration, and a SHA256SUMS manifest.

Two further profiles stay in the repository as separate examples rather than release assets. The research configuration is described as extremely verbose collection for short, controlled sessions, with a warning about CPU, memory and logging capacity. The MDE-augment configuration is a narrower selection meant to complement Microsoft Defender for Endpoint with less overlap; the README is explicit that it does not enable every Sysmon event.

## Installing the tooling and generating a first config

You do not need Go to use the generator. Download the binary matching your platform from the latest GitHub Release: sysmon-modular-windows-amd64.exe, sysmon-modular-windows-arm64.exe, sysmon-modular-linux-amd64, sysmon-modular-linux-arm64, sysmon-modular-darwin-amd64 or sysmon-modular-darwin-arm64. The README says to save it as tooling/sysmon-modular, or tooling/sysmon-modular.exe on Windows, and to make it executable once on Linux and macOS.

```bash
chmod +x tooling/sysmon-modular
```

If you prefer to build from source, the requirement is Go 1.22 or newer and only the Go standard library. The README gives this command from the repository root on Linux or macOS:

```bash
git clone https://github.com/olafhartong/sysmon-modular.git
cd sysmon-modular
go -C tooling build -o "$PWD/tooling/sysmon-modular" ./cmd/sysmon-modular
```

On Windows the equivalent output path is $PWD\tooling\sysmon-modular.exe. The go -C tooling form runs the build from the tooling directory, so if you adapt repository-root examples to go -C tooling run, use absolute paths or follow the tooling-relative examples in the command reference at tooling/docs/README.md.

Before generating anything, confirm the binary works and read the command surface. The README states that version and --version print sysmon-modular 1.0, and that the build version also appears in top-level and command-specific help.

```bash
./tooling/sysmon-modular --version
./tooling/sysmon-modular help
./tooling/sysmon-modular merge --help
```

Note the distinction the README draws: --version identifies the tooling build, while --sysmon-version selects the target Sysmon executable for the configuration you are producing. Getting those two confused is an easy mistake when you are pinning a file for endpoints that still run an older driver. The README also points at merge --help for the merge command, and separately documents validate, analyse and compare commands for working with existing configurations.

## Where the profiles will hurt you

The most useful thing in the README is the warning attached to its own output. The excludes-only profile is built from exclusion modules, which means it collects broadly and filters out known noise. The README tells you to expect substantial event volume and to tune before production use. The research configuration carries a stronger warning: it can consume substantial CPU, memory and logging capacity, and the README says to load a lighter configuration when the investigation is complete. Those are not hypothetical caveats added for safety. They follow from the architecture. A configuration assembled from inclusion modules emits only what the modules name; a configuration assembled from exclusions emits everything the driver supports except the named noise.

The FileDelete profile adds a second constraint that has nothing to do with detection quality. It enables file archiving, and the README tells you to account for the archive's disk requirements. On a busy file server or a build machine, that is a capacity decision before it is a detection decision.

This project is also the wrong tool if you are not running Sysmon at all, or if you want a configuration you can deploy without looking at it. The README's own framing, that every configuration is a starting point and should be measured on representative machines, rules out set-and-forget use. It is equally wrong if you need a single artifact for a mixed fleet running several Sysmon versions and cannot pin per version, since the release ships separate files for 15.21, 14.16, 13.34 and 12.03. The README advises pinning a specific release for controlled rollouts rather than automatically deploying latest.

## sysmon-modular against SwiftOnSecurity's sysmon-config

The obvious comparison is the configuration this project grew out of. SwiftOnSecurity's sysmon-config is a single XML file you download and deploy. Its strength is that it is one artifact with one review surface, and the README here credits it as the original inspiration and part of sysmon-modular's foundation. The difference in approach is granularity of maintenance, not detection content. With a single file you diff two revisions of one document and read the changes in context. With sysmon-modular you diff a module directory, which is easier to reason about in isolation but requires you to understand how the generator assembles the fragments before you can predict the deployed result.

The second difference is the toolchain. sysmon-modular ships a Go CLI that the README describes as handling generation, validation, analysis and comparison, plus a build workflow that produces versioned files for four Sysmon releases. A single-file configuration has no equivalent pipeline. That is a real advantage if you maintain configurations for several endpoint roles and want the output reproducible from source. It is overhead if you maintain one config for one fleet and change it twice a year.

A third point of comparison sits inside the project itself: the MDE-augment profile. If you already run Microsoft Defender for Endpoint, the README positions that profile as a way to reduce overlap rather than duplicate collection. Choosing between the balanced profile and MDE-augment is a question about what your EDR already records, and the README points to 0_custom_configuration/README.md for rebuilding and reviewing its exclusion list.

## Maintenance, releases and the MIT licence

The last push to the repository was on 2026-09-18, and the most recent release, configs-082cba578667, carries the same timestamp. That release is a generated configuration artifact rather than a tagged version of the tooling, which tells you how the project ships: the CLI is built and attached to releases alongside freshly generated XML. The README states the tooling starts at build version 1.0, defined in tooling/cmd/sysmon-modular/version.go, and that local and release builds include it automatically.

Upgrade cost depends on which half you use. If you consume release assets, upgrading means downloading a new sysmonconfig.xml and redeploying it, and the README's advice to pin a specific release for controlled rollouts applies. If you generate from source, upgrading means pulling the module directories and rebuilding, then diffing the merged output against what is deployed. Neither path is expensive on its own, but the second one puts the diff review on you.

The licence is MIT, per the repository metadata and license.md. MIT is permissive and places few conditions on redistribution or modification, which matters here because you will almost certainly modify the modules. The README does not document rollback, so how you revert endpoints to a previous configuration is your operational problem, not something the project answers. This is not legal advice; read license.md and your own obligations before redistributing a modified configuration.

## Conclusion

Adopt sysmon-modular if you already run Sysmon and want to see, per event ID, exactly what a configuration collects before it reaches production. Do not adopt it if you want a finished configuration to deploy unchanged, or if you cannot measure event volume on representative hosts: the excludes-only and research profiles are documented as very verbose. Verify first which Sysmon version your endpoints run, because the release ships separate files for 15.21, 14.16, 13.34 and 12.03, and confirm whether FileDelete archiving is acceptable given the disk requirements the README flags.

## FAQ

### What is Sysmon and what is it used for?

Sysmon is the Microsoft Sysinternals system monitoring driver that sysmon-modular writes configurations for. The README links to the Sysinternals download page and treats Sysmon as the component whose telemetry the modules select and exclude.

### Is Sysmon included in Windows 11?

The README does not say. It points to the Microsoft Sysinternals download page for Sysmon and to the Sysmon 15.21, 14.16, 13.34 and 12.03 targets the released configurations are generated for.

### How can I tell if Sysmon is installed?

The README does not cover checking an installation. It only documents the sysmon-modular tooling, where ./tooling/sysmon-modular --version prints sysmon-modular 1.0, and --sysmon-version selects the target Sysmon executable for the configuration being produced.

### What is sysmon modular?

It is a repository of Sysmon configuration modules plus a Go CLI that merges them into deployable XML. The README describes each configuration as a starting point that should be reviewed and tuned for your applications, endpoint roles, detection needs and logging budget.

## Sources

- [Issues](https://github.com/olafhartong/sysmon-modular/issues)
- [License: MIT](https://github.com/olafhartong/sysmon-modular/blob/master/LICENSE)
- [olafhartong/sysmon-modular on GitHub](https://github.com/olafhartong/sysmon-modular)
- [README](https://github.com/olafhartong/sysmon-modular/blob/master/README.md)
- [Releases](https://github.com/olafhartong/sysmon-modular/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/olafhartong-sysmon-modular