OpenEDR: a source-available Windows EDR agent that ships its telemetry to your own Elasticsearch

What OpenEDR actually is, and who it is built for

OpenEDR is a Windows endpoint detection and response agent published as source code by Comodo. The README describes it as "a full-blown EDR capability" and says the agent records telemetry locally before sending it to locally hosted or cloud-hosted Elasticsearch deployments. The intended reader is an engineer who wants base-security-event granularity: process creation and deletion, registry access, file system I/O, network activity, plus file and device trajectory data. The README frames process hierarchy tracking as the mechanism for root-cause analysis, and the repository ships screenshots of a process timeline and a process treeview to illustrate what that looks like once the data lands in a UI.

The audience is narrow. This is not an endpoint agent you install on a laptop and forget. It is a set of runtime components, drivers and services that you compile, deploy, and wire into an ELK stack yourself. Teams already running Elasticsearch and Kibana, with Windows fleets and someone who can read C++ build output, are the realistic adopters. Anyone who wants a console, a cloud tenant and a support contract is pointed by the README itself toward the Comodo Dragon Enterprise platform instead.

The runtime architecture: drivers, injected DLLs and a self-protection provider

The README lists the components in enough detail to see where the design sits. At the bottom is the Core Library, described as the basic framework. Above it, a Service application coordinates the rest. Process monitoring is split three ways: an injected DLL that hooks API calls inside target processes, a driver that loads that DLL into each new process, and a service component that controls it. System Monitor is described as a generic container for kernel-mode components, and inside that container sit a file-system mini-filter hooking I/O requests, a low-level process monitoring component using system callbacks, and a low-level registry monitoring component doing the same for registry access. A network filter handles network activity, and a self-protection provider prevents EDR components and configuration from unauthorized changes.

That layout has consequences. Hooking APIs inside other processes and loading a kernel mini-filter means the agent lives at a privilege level where a bug is not a crashed app but a bugcheck. The self-protection provider exists precisely because anything running at that level is a target: if an attacker can stop the service or edit its configuration, the telemetry stops. The README does not document how self-protection behaves during an upgrade or an uninstall, and that gap matters more than it looks, because a component that resists unauthorized changes is also a component that can resist authorized ones.

Installing OpenEDR and getting a first event into Kibana

The repository does not put install steps in the README. It points to a set of documents under getting-started/, and those are the real entry point: InstallationInstructions.md, BuildInstructions.md, DockerInstallation.md, SettingELK.md, SettingFileBeat.md, EditingAlertingPolicies.md and SettingKibana.md. Read them in that order. The README also offers a shortcut for people who do not want to build anything: email [email protected] and use the Comodo Dragon Enterprise platform, which the README calls a short-term solution until easy-to-use packages are finalized.

If you build it yourself, the shape of the work is: compile the agent from edrav2/, stand up Elasticsearch, Kibana and Logstash, configure Filebeat to ship the agent's telemetry, then apply alerting policies and Kibana dashboards. The repository provides a Docker path, so the stack side can start from the documented Docker installation rather than a manual ELK build.

git clone https://github.com/ComodoSecurity/openedr.git
cd openedr
ls getting-started/

That listing is the map. The files you need are InstallationInstructions.md and BuildInstructions.md for the agent, DockerInstallation.md for the stack, then SettingELK.md, SettingFileBeat.md and SettingKibana.md in sequence. The README gives no single command that installs the whole thing, and it does not document a package repository, so treat the build documents as authoritative rather than looking for a one-liner.

Expect the first real milestone to be a document in Kibana, not a detection. The README's screenshots show event search, event details and a process tree, which are Kibana views over indexed telemetry. Until Filebeat is shipping and the index pattern is right, none of those views have anything to render.

Where OpenEDR stops: Windows-only, ELK-dependent, and unversioned in the README

The component list is entirely Windows-shaped. A file-system mini-filter, a driver that injects a DLL into new processes, and registry callbacks are Windows kernel concepts. The README never mentions Linux or macOS support, and the related searches asking about OpenEDR on Linux have no answer in the repository. If your fleet is mixed, OpenEDR covers one part of it.

The second constraint is the dependency on Elasticsearch. The README says telemetry goes to "locally hosted or cloud-hosted ElasticSearch deployments", and the getting-started set includes dedicated documents for ELK, Filebeat and Kibana. There is no bundled storage engine and no standalone console. If you do not already operate Elasticsearch, adopting OpenEDR means adopting an ELK deployment as well, with the index lifecycle, disk and query tuning that comes with it. At base-event granularity, that volume is not small.

The third issue is versioning. The README's Releases section links to release-2.5.1, and the repository's releases list shows release-2.5.1 from 2022-09-20 and 2.0.0.0 from 2020-11-12. The README does not state which release the build instructions target, and it does not document an upgrade path between releases. The last push to the repository was on 2026-05-23, which is recent, but recent commits are not the same as a documented upgrade procedure. Verify which tag the getting-started documents were written against before you build.

OpenEDR compared with Wazuh and OSSEC

The searches that bring people here are mostly comparisons, and the difference is architectural rather than cosmetic. OSSEC is a host-based intrusion detection system built around log analysis and file integrity monitoring: it reads logs, checks file hashes, and raises alerts from rules. OpenEDR does not analyze logs as its primary input. It hooks API calls inside processes, filters file system I/O in the kernel, and monitors registry access through system callbacks, then ships that raw telemetry to Elasticsearch. The unit of data is the event, not the log line.

Wazuh, which grew out of OSSEC, is closer in deployment shape: an agent plus a manager plus a dashboard, with broad platform coverage and a large rule set. OpenEDR's bet is narrower and deeper on Windows. It gives you process hierarchy and file and device trajectory at base-event level, which is what the README argues enables root-cause analysis. It does not give you the cross-platform coverage or the ready-made detection content that a Wazuh deployment brings out of the box.

A practical way to frame it: if your question is "what changed on this host", a log-and-integrity tool answers it cheaply. If your question is "what did this process do, what did it spawn, and what files did it touch", you need the event-level telemetry OpenEDR collects, and you need the storage and query layer to go with it.

Licence, maintenance and the cost of running it

GitHub reports the licence as NOASSERTION, and the repository carries a LICENSE.md at the top level. That means the licence text is in the repository but is not one of the licences GitHub recognizes automatically. Read LICENSE.md directly, and check it against what you plan to do: internal deployment, redistribution inside a product, or modification of the kernel components are different questions, and the README does not answer any of them. This is not legal advice; it is a pointer to the file that matters.

Maintenance cost is dominated by two things. The first is the build: the runtime components include kernel-mode drivers, and building and signing those is a different skill from building a user-space service. The BuildInstructions.md document is where that work is described. The second is the ELK stack. Base-event telemetry from a Windows fleet is high volume, and someone has to own index rotation, storage, and the Kibana side. The README frames the hosted Dragon platform as the way to avoid "log forwarding configuration" and "storing telemetry data", which is an accurate description of the operational load you take on when you self-host.

Upgrades are the open question. With releases listed as 2.5.1 and 2.0.0.0 and no upgrade documentation in the README, plan to validate each new tag in a lab rather than rolling it across a fleet.

Editorial conclusion

OpenEDR suits Windows-centric teams that already run Elasticsearch and Kibana and want base-event telemetry they can query themselves; it does not suit anyone expecting a finished console, a Linux agent, or a signed installer from a download page. Before committing, read getting-started/InstallationInstructions.md and getting-started/BuildInstructions.md, confirm which Windows builds the mini-filter driver supports, and check LICENSE.md, which GitHub reports as NOASSERTION, against the components you intend to redistribute.

Frequently asked questions

Official sources

1. ComodoSecurity/openedr on GitHub
2. Issues
3. README
4. Releases