ETW and eBPF can provide useful host telemetry for detecting behavior associated with ransomware, but neither is a complete detection or response system. Build detections by correlating bursts of file activity with process context, recovery-inhibition behavior, persistence changes, and network activity; investigate the resulting signals rather than treating any one event as proof of infection.
What ETW and eBPF contribute
Windows Event Tracing (ETW) is a framework for collecting event data. Providers emit events into sessions, controllers manage sessions and enable providers, and consumers read trace files or process events in real time. ETW transports telemetry; an analytic layer must decide whether the activity is suspicious.
As an Amazon Associate I earn from qualifying purchases.
On Linux, eBPF programs can observe kernel-related activity. What a sensor can see, how it reports that activity, and which systems it supports depend on the specific implementation, distribution, kernel, and agent version. An eBPF sensor is not automatically compatible with every Linux host.
| Mechanism | What it can contribute | What it does not do by itself |
|---|---|---|
| ETW | Events from enabled Windows providers, delivered through trace sessions to a consumer. | Interpret events as ransomware or generate a detection without separate analytics. |
| Sysmon | Configurable Windows Event Log context, including process, file, network, DNS, and configuration activity. | Determine intent, analyze its own events, or alert on ransomware automatically. |
| eBPF sensor | Kernel-related activity selected and exposed by that sensor’s implementation. | Guarantee uniform coverage or compatibility across Linux systems and vendors. |
Do not assume equivalent event names or meanings across ETW providers, Sysmon, and eBPF. Confirm what each selected source actually reports before writing rules that depend on it.
#1 Best Overall
Which file activity is suspicious?
File encryption can create a rapid sequence of reads and writes across many files, broad access to particular file types, directory traversal, and repeated file creation, renaming, or deletion as originals are rewritten. A single write or rename is weak evidence; the combination, pace, breadth, and process responsible are more useful investigative signals.
- Count files touched and distinguish repeated activity across one directory from traversal across many locations.
- Correlate reads and writes with create, rename, and delete events around the same files.
- Preserve process identity and lineage, command line, executable identity, user, host role, and timestamps.
- Look for related persistence activity and unusual use of tools that can inhibit recovery.
- Correlate host events with relevant network activity, including suspicious command-and-control behavior where network monitoring can observe it.
Legitimate backup, software deployment, indexing, compression, and other bulk file operations can resemble portions of this behavior. Microsoft Learn’s Sysmon event guidance states, “No single event indicates malicious activity by itself.” Treat an unusual sequence as a reason to investigate, not as a verdict.
Rank #2
How to build a cross-platform detection
- Choose the signals. Select Windows providers and Linux sensor events that expose the process, file, persistence, and network context your rules require. Document gaps rather than assuming either platform provides the same fields.
- Correlate over a short time window. Build a sequence or score from read/write bursts, number and diversity of files, directory traversal, and create/rename/delete patterns. Include process identity and relevant recovery-tool behavior. There is no universal threshold established for this combination; tune against representative workloads.
- Establish benign baselines. Exercise known bulk-I/O workloads such as backup, deployment, indexing, and compression. Use those observations to reduce noise without suppressing suspicious activity broadly.
- Validate collection health. Track ETW buffer loss, consumer throughput, delayed or dropped events, timestamps, and forwarding health. Monitor comparable health indicators in the Linux sensor and downstream pipeline.
- Connect alerts to an operational response. Define who receives an alert, what evidence is retained, and how containment and recovery decisions are made. Host telemetry complements, rather than replaces, prevention, network visibility, response, and recovery controls.
Windows: use ETW and Sysmon for complementary context
Enable ETW providers appropriate to the system or application events needed by the detection, then route session data to a consumer and analytics pipeline. Inspect loss statistics: Microsoft documents that event size, buffer capacity, and a consumer that cannot keep up can result in lost events. A quiet alert stream is not reassuring if collection is dropping data.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Sysmon can add structured process, file, network, DNS, and configuration context to Windows Event Log. Configure high-volume event classes selectively and send the resulting events to a system that can correlate and alert. Sysmon is an event source, not a detection engine; its official overview says it does not analyze generated events or produce alerts on its own.
Linux: validate the specific eBPF sensor
Before deployment, check the sensor vendor’s current support table and known-issues information for the exact Linux distribution, kernel, and agent version. Microsoft Defender for Endpoint’s eBPF provider is one vendor-specific implementation; its prerequisites, fallback behavior when eBPF is unavailable or disabled, and kernel configuration warnings should not be generalized to custom eBPF programs or other products.
Confirm which events remain available if the provider falls back or cannot load, and make that state visible to monitoring. Do not assume that a supported kernel version alone guarantees a working sensor on a particular host.
Rank #4
Capacity, noise, and response readiness
Collecting or intercepting every I/O operation can create substantial event volume and impose performance overhead. ETW can lose events if session buffers or consumers cannot keep pace, while any high-volume telemetry pipeline can strain CPU, memory, storage, or forwarding capacity. Measure event loss, resource use, and application latency against representative workloads before tuning production collection.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use targeted event selection and filtering to manage volume, but preserve enough context to reconstruct the sequence that prompted an alert. CISA’s StopRansomware guidance recommends layered monitoring that can include Sysmon, EDR, IDS, and centrally managed alerting. It also identifies anomalous use of recovery-inhibition tools such as vssadmin, wbadmin, bcdedit, fsutil, and wmic as activity to monitor. These tools can have legitimate uses, so assess their use in context.
What a successful deployment can—and cannot—claim
A well-designed pipeline can collect and correlate behavior that warrants investigation across Windows and Linux. The available evidence does not establish a universal detection threshold, an expected accuracy or false-positive rate for a combined ETW/eBPF detector, or that telemetry alone prevents encryption. Evaluate a concrete implementation with representative workloads and documented ground truth, and treat an alert as the start of investigation and response—not proof of compromise.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
