A Commercial Alternative to Sysmon You Can Build Into Your Application

Introduction

Sysmon isn't something you embed in a product. It's a free Microsoft Sysinternals tool that installs as a standalone system service on a machine and writes what it sees to the Windows Event Log, for an administrator or a SIEM to read later. If your application needs that same visibility, file activity, process activity, registry activity, built into its own logic rather than dumped into someone else's event log, Sysmon isn't an option at all, commercial or otherwise. You need an SDK.

CBFS Filter is that category: a kernel-mode driver, shipped prebuilt and signed, plus a user-mode library your application calls directly. This article covers what it actually covers, what it doesn't, and where the real difference from Sysmon lies, since it isn't just "paid versus free."

What Sysmon Actually Does

Sysmon monitors around 29 event types, including process creation, network connections, DNS queries, file creation, registry key and value changes, image and driver loads, and process access, and writes each one to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Configuration is an XML rule file applied at install or update time. With two narrow exceptions (blocking new executable file creation and blocking file shredding), Sysmon only logs; it does not intervene in the operations it observes, and its own documentation says so directly.

Sysmon also isn't licensed or built to be embedded in a third-party application. It's a resident system service you install once per machine, independent of any single application, aimed at the person operating that machine rather than a product built on top of it.

What CBFS Filter Actually Covers

CBFS Filter is three components, each backed by its own prebuilt kernel-mode driver: CBFilter for filesystem activity, CBProcess for process and thread activity, and CBRegistry for registry activity. Unlike Sysmon, every one of them can run synchronously: your application sees the request before it completes and can allow it, deny it, or modify it, not just log it afterward.

On the file side, CBFilter's coverage is considerably broader than Sysmon's handful of file events (creation, deletion, and the two narrow block cases). It reports file creation, open, read, write, rename, deletion, directory creation and enumeration, attribute and security-attribute changes, extended attributes, hard link creation, reparse point operations, and range locking, each with the initiating process, user, and timestamp attached.

CBProcess covers process and thread creation and termination, and process and thread handle opens and duplicates, with the parent process, command line, and image path available on process creation, comparable in substance to Sysmon's process creation event.

CBRegistry covers thirteen distinct registry operations, including key creation, opening, closing, deletion, renaming, security attribute changes, enumeration of subkeys and values, and reading and writing values, a finer breakdown than Sysmon's three registry event IDs, which group creation/deletion, value changes, and renames into three broader categories.

All three let you scope activity with rules, by path, process, or attribute, rather than capturing everything and filtering downstream, which matters because CBFS Filter's driver sees every matching request in real time rather than batching to a log.

What CBFS Filter Doesn't Cover

Sysmon logs several event categories that CBFS Filter's current components don't address at all: network connections, DNS queries, image and DLL loads, driver loads, and clipboard changes. If your application needs those specifically, CBFS Filter isn't a complete substitute on its own, and nothing in this article should be read as claiming otherwise. This is a genuine gap, not a minor omission, and it's worth checking against your actual requirements before assuming full parity with Sysmon's event coverage.

The Real Difference: Logging vs. Building

Sysmon's value is that it's free, requires no code, and produces a standard log an existing SIEM or analyst workflow already knows how to read. CBFS Filter's value is the opposite of that: everything it sees is a function call or an event in your own application, in your own data model, with the option to block or alter the operation in real time rather than only recording that it happened. That's a different product decision, not just a pricing one, and it's why "alternative" undersells what CBFS Filter actually is: it's the SDK for building the product Sysmon can't be, not a drop-in replacement for the log file Sysmon produces.

When This Matters

If you're an administrator who wants visibility into what's happening on a machine, Sysmon remains free, well-documented, and sufficient for that job, and CBFS Filter would be the wrong tool for it. If you're building a security, compliance, backup, or DLP product that needs file, process, and registry visibility as a first-class part of its own logic, with the ability to intervene in real time rather than just log, CBFS Filter is built for exactly that, with the understanding that network and image-load visibility would need to come from somewhere else.