Introduction

Generating telemetry without the underlying attacks can be very useful for detection engineering. Some attacks are destructive, noisy, unreliable, or just annoying to reproduce repeatedly. If I am building detections for certain LDAP behavior, AV events, ransomware-like telemetry, or other endpoint signals, I do not always want to run the real tool or real malware just to check if a rule still works.

As usual, that useful defensive question quickly turned into a less comfortable one: what if I can make the system believe something happened, when it did not?

And then the next question: what if I can create enough telemetry, or enough broken telemetry behavior, that the product relying on those logs does not see the real activity anymore?

This post is the written version of my conference talk about Event Tracing for Windows (ETW), telemetry trust, capping, fake events, buffer behavior, and the somewhat uncomfortable implications for EDR products. 

I will use Microsoft Defender for Endpoint (MDE) for many examples, because that is where I spend a lot of my time, but the underlying ETW concepts are not unique to MDE. Any product relying heavily on ETW, especially cloud-connected EDR products, are impacted by the same class of problems.

What is ETW?

Event Tracing for Windows is a telemetry mechanism deeply integrated into Windows. It can expose events from user-mode applications, kernel- mode drivers, and operating system components.

The interesting bit is that, according to Microsoft’s own documentation, ETW was designed for performance monitoring and debugging. Use cases for security never were part of that plan. This led to some undesirable design decisions that do have a security implication.

That does not make ETW bad. It is actually one of the most useful telemetry mechanisms available in Windows. But it does mean we should be careful when we start treating it as if it was designed to be used for security from the beginning.

At a high level, ETW consists of a few important components:

• Providers, which generate telemetry.
• Consumers, which request or receive telemetry.
• Trace sessions, which connect providers to consumers.
• The ETW kernel components, which handle the logistics.

Please note this blog is not a comprehensive deep dive into ETW. I will cover the most important components that were relevant to my research.

There are many user-mode providers and many kernel-mode providers. These can be operating system components, drivers, applications, or product-specific components. A consumer can request a trace session for one or more providers, after which events from those providers can be delivered to the consumer.

 

Simplified ETW message flow.

There are several types of sessions:

• Autologger sessions, which start at boot.
• Real-time sessions, which are the most interesting for EDR-style use cases.
• File logging sessions, where events are written to a file and consumed later.
• Private sessions, often used for internal application monitoring.

 

Simplified overview of interaction between ETW components.

Real-time sessions are especially relevant, because they allow a product to consume events as they are produced. They may still involve files or buffers under the hood, but the important part is that the consumer does not have to wait for an offline log file to be written and processed later.

Private sessions are worth mentioning, because EDRs use those, too. Defender for Endpoint previously exposed one of its private sessions in a way that made it possible to observe telemetry before it was sent to the cloud. That has since been fixed, which is good, even if it removed a very useful research view into the product.

Every real-time session also gets a buffer pool assigned. That sounds like a basic implementation detail, but it becomes one of the more important parts of this story later.

Existing ETW attack research

I am obviously not the first person to look at ETW from an offensive angle. There is a lot of existing work in this area. Many ETW attacks focus on preventing telemetry from being generated or consumed. Examples include:

• Patching functions in memory.
• Blocking or tampering with event write paths.
• Hooking application functions so specific events are never emitted.
• Tampering with trace files on disk.
• Disabling trace sessions.

These techniques can be very effective, but many of them require high privileges, kernel access, code injection, a vulnerable driver, or other conditions that raise the bar. That was not the starting point I wanted for this research. I was mostly interested in what could be done from an un-elevated user-mode context, which is a much more relevant initial access scenario. If a phisher or attacker lands on a workstation without local admin, can they still influence what the EDR sees?

That question is what made digging into the provider side of ETW most interesting to me.

Why EDRs use ETW

Before going into the weirdness, let’s first answer the question: why do EDR products rely on ETW so much? The simple answer is that ETW has a lot of advantages.

First, it is stable and accessible. If a product can get useful telemetry through ETW, it does not need to inject code everywhere or implement everything as a kernel callback. Stability matters a lot for endpoint products. We have all seen what happens when security software gets kernel behavior wrong and causes a major outage.

Second, it is fast. ETW was built for high-volume performance tracing. It has buffering, filtering, and efficient delivery mechanisms. For telemetry-heavy products, that is very attractive.

Third, it is flexible. A vendor can enable or disable providers through a configuration change in real-time. They can collect more telemetry or less telemetry without necessarily shipping a new agent. That is a very big operational advantage.

Fourth, it has broad coverage. Kernel callbacks are useful and harder to tamper with, but they only cover a subset of interesting behaviors. ETW has providers for a huge range of Windows components. For an EDR, that means more context and more opportunities for detection with limited development effort.

Fifth, ETW can be less intrusive. A product can ask Windows for telemetry instead of hooking every function or injecting into every process. In practice, EDRs still use a mix of techniques, but ETW reduces the need to do everything the invasive way to get the telemetry they require.

This is why you see a lot of ETW usage in products, such as Defender for Endpoint, CrowdStrike, Elastic and other EDRs. They still use kernel callbacks, minifilters, function hooking, and other mechanisms, but a large part of the behavioral telemetry can come from ETW.

This is also why ETW reliability matters. If a product builds detections on top of ETW, then ETW collection gaps become detection gaps.

 

In Defender for Endpoint specifically, you can see this split when looking at configuration and behavior. There are kernel callback-based signals, but there is also a much larger set of ETW providers that the product listens to. That is not a criticism by itself. It is exactly what I would expect from a product that needs broad Windows visibility without putting every possible collection path in the kernel.

Cloud EDRs and capping

Cloud EDR products have another problem: they cannot collect, process and send everything. Full telemetry streaming sounds great, until you have to run it at scale. Every event has to be collected, processed, transferred, stored, queried, and analyzed. That costs CPU, memory, bandwidth, storage, and money.

This event handling also has to work in low-bandwidth environments and in organizations with thousands or hundreds of thousands of endpoints. You cannot just flood every pipeline with every possible event and hope the invoice remains reasonable. So, most vendors cap and filter telemetry.

In one Defender for Endpoint configuration I looked at, the LDAP client ETW provider was configured with a maximum number of LDAP events per machine. There was also local capping behavior that effectively meant only unique combinations of certain fields, such as the process and query details, would be collected once per period.

From a product perspective, this makes sense. If the same process runs the same LDAP query a thousand times, you may not need all thousand events in the cloud. You may only need to know that it happened.

From a detection engineering perspective, it can be annoying. You run an attack simulation multiple times, expect multiple events, and only see one. Then you wonder if the detection is broken, the telemetry is delayed, the query is wrong, or the product decided you already had enough data for today. The answer can simply be: the event was capped.

In the LDAP example above, the local capping behavior was effectively “first seen” style logic over a 24-hour period. If the same process generated the same relevant query again, you would not necessarily see it again in the cloud data. That is defensible as a cost and volume control, but it is painful when you are iterating on developing a detection and are not aware of this mechanism. This capping or filtering is not formally documented by the vendor in most cases.

This is one of the reasons I have written about MDE telemetry capping before [1][2][3]. You need to know the limits of the dataset you are relying and building detections on. Otherwise, you end up losing a lot of time debugging your detections, when the real problem is that the data never arrived.

There is also a more unsettling implication. If a collection pipeline has a cap, then hitting the cap can create a blind spot. That is not a bug in the detection rule. That is a missing input problem. No telemetry means no detection, at least for detections relying on that telemetry.

Writing events to existing providers

ETW providers have globally unique identifiers. A process can register a provider and receive a handle for that registration. For user-mode providers, a process can generally register a provider even when that provider already exists. Each registration is process-specific, and the process gets its own handle. That behavior is by design, it’s part of how ETW has been architected.There are roughly three provider models:

• MOF-based providers, which are older and mostly from the WMI era. They are also less used by now.
• Manifest-based providers, which are common and were introduced with Windows Vista, and are the most common ones in current Windows installations.
• TraceLogging providers, which are often used for application-internal telemetry. They don’t have a predefined manifest; this is determined by the initiating application.

Manifest-based providers are the most relevant here. The manifests are XML-based and stored on disk. They describe providers, event IDs, templates, fields, data types, and so on.

For example, an LDAP event template may describe fields, such as the scope, search filter, and distinguished name. If you want to emit an event that downstream consumers understand, you need to match the expected structure. This turned out to be a significant part of my research time, getting the format right in order for the events to be accepted by the session kernel, and later Defender.

In theory the flow is simple:

• A real ETW provider exists.
• A real-time session is consuming events from that provider.
• Another process registers the same provider.
• That process emits events with the expected structure.
• Those events arrive in the same session.

From the perspective of the trace session, the event is associated with the provider. There is not always a strong, obvious distinction for downstream analytics between “this event was emitted by the expected component” and “this event was emitted by another process that registered the same provider.”

That is the uncomfortable part. So, I wanted to experiment if I could manipulate the registration and the event emission process.

However, there are some limits. Some fields in an ETW event are controlled by the session controller, which resides in the kernel. For example, I could not simply spoof the emitting process ID from user mode. That killed the fun experiment where I wanted to see if I could convince MDE that its own process had done something malicious. The kernel did not let me just pick whatever PID I wanted and just overwrote it with the PID of the process I emitted from.

But even with those limits, the broader issue remains: event payloads and provider identity can be trusted more than they deserve. 

Kernel providers

The same concept exists from kernel mode as well. If you have a kernel driver, local admin permissions, and the necessary signing requirements, the barrier changes. I did not focus on that path because I wanted to stay in unelevated user mode, but others have since shown similar ideas to be possible from kernel mode.

The user-mode path is already interesting enough, because it lowers the required privileges for some classes of telemetry manipulation and there is a long list of providers to work with.

ETW security descriptors

ETW is not completely unprotected. Providers can register security descriptors in the registry. These descriptors define who can do certain interactions with a provider.

At a high level, when a consumer wants to start a trace, the ETW kernel checks the provider’s configured access control. If there is no provider-specific security, fallback behavior applies. If the caller has the required access, the session can be created. Otherwise, it fails.

For most providers, starting trace sessions requires local administrator privileges. However, there are some exceptions. One notable group is Performance Log Users. Installing Visual Studio can add a user to this group, which makes sense from a developer and diagnostics perspective, but it also expands access to tracing capabilities.

There are also providers where broader access is intentionally allowed for troubleshooting. One example I looked at, was related to anti-malware service telemetry. Microsoft indicated that some of this access existed to support user-mode diagnostics and tooling, such as the MDE Client Analyzer.

The important nuance is that much of this security model is focused on consumers, which can be nice from a privacy perspective. Starting sessions and reading telemetry is not the same as registering a provider and emitting events. Provider registration has its own logic, and for many providers there was no obvious protection preventing another user-mode process from registering the provider and emitting compatible events.

In many cases, the broad permission was not “you can read everything.” It was closer to “you can register the GUID.” That sounds harmless, until you start looking at event emission and downstream trust. The security model was not designed around hostile telemetry generation as the primary threat, only information disclosure.

Later, after disclosure to MSRC and their subsequent patch, I learned more about additional internal checks and allow/deny logic that Microsoft can apply for specific providers. This was not documented, and I had to reverse some of the ETW implementation details to understand what had changed. 

I did not reverse the full inner workings of this flow. The short version is that there is an NtTraceControl function in the kernel. This function can reference a disallow list. If a provider is on the list and the process requesting a handle is not on the list as a permitted process, the handle is not issued. This is the protection that has been applied to a small set of providers based on my report.

Targeted protection does exist, it’s just rarely applied, while I believe it should be applied much broader. Honestly, the ETW architecture should in fact be redesigned to be a more secure and robust implementation.

Building the proof of concept

With this acquired knowledge I wrote a first proof of concept in Go to see if I could register a provider and emit an event. Mostly because I like Go and can be productive in it. There are easier ways to do some of this if you are a good C developer, but that’s not within my area of capabilities. I found several open-source ETW packages that looked promising, so I started building.

The first implementation looked promising locally. I could emit events and see events in a local trace session. Then I waited for them to appear in Defender for Endpoint, and nothing happened.

After too much waiting and failing, I started to compare what I emitted with what was emitted by a real operation. Most open-source ETW libraries for Go were built for consuming events, not for emitting events that had to match the full manifest, with all the correct headers, in line with what MDE expected. Some incorrect headers emitted by my POC code were accepted locally, but were not useful downstream. There were also data layout issues, including Windows little-endian details, that I had managed to get wrong.

Eventually I moved my implementation closer to the native Windows APIs via direct Syscalls, almost like using C anyway :). I managed to emit events in a form that both the local ETW path and the cloud pipeline accepted.

At that point, the fake LDAP telemetry arrived in the cloud. That was the useful defensive moment: I could create controlled telemetry and validate detections, without running the real behavior.

From there, I tested simulations of tooling that defenders commonly detect through LDAP-heavy behavior, such as SharpHound-like enumeration, AD Explorer-like activity, and certificate services-related enumeration. 

Examples like the one above are useful for detection validation, but they also demonstrate why blindly trusting event presence is dangerous. This was also the point in my research where the abuse scenarios became obvious.

Validating capping

Once event generation worked, I wanted to validate the event capping behavior, which I discussed earlier.

For the LDAP example, the configuration suggested local uniqueness checks based on fields, such as process and query details. I tested this by generating the same logical event from different process names and with different field combinations. As expected, changing the process identity or event content affected whether the data appeared again.

Next, I tested the global cap. When I generated more events than the configured maximum, only the capped number of events from the configuration arrived in the cloud. Later events generated by another process on the same machine, with different values, did not arrive either. That confirmed the important part: once the cap for that event type was reached, additional relevant telemetry for that period would not appear in the cloud dataset.

This is not only an MDE issue. Any cloud EDR applying event capping has some version of this trade-off. The exact limits vary by product, provider, event type, and configuration. Some providers may cap at 1.000, others at 2.400, 10.000, or other values. Some network-related telemetry also had aggregation behavior, meaning the effective threshold could be higher than the obvious event cap.

The practical point is that the first events win. It is not necessarily a rolling window where the newest events replace older ones. Once the product decides it has received enough events for that period, later telemetry will most likely not be sent.

That is fine, if the early telemetry was representative. It is not so fine if the early telemetry was (generated) noise.

The reset behavior matters, too. In the examples I discussed, the cap resets after the relevant period, such as 24 hours after the first event in that window, or in many cases, a reboot. If you are testing or investigating, that timing can make the dataset look inconsistent, unless you know the cap exists.

Fake detections and analyst distraction

LDAP telemetry was useful for proving the concept, but the same idea applied to other providers too.

The Microsoft-Windows-Antimalware provider was especially interesting, because fake detections could affect what analysts saw. At one point, fake malware detections and fake ransomware-like events could produce visible portal artifacts and alerts. That creates obvious opportunities for distraction and chaos.

I do not recommend doing this to customers, colleagues, or anyone else. Besides the ethics, you can genuinely disrupt an incident response process. If a security team sees a machine apparently detonating a large number of malware samples, someone should notice and will respond. That is the problem: you can make analysts spend time on things that did not happen.

There were other uncomfortable possibilities too. Some environments use conditional access policies based on user risk, device risk, compliance state, or EDR alert state. If security telemetry can influence risk or compliance decisions, then fake telemetry can potentially create operational impact beyond just a noisy alert queue.

Again, this is not an argument against those controls. Risk-based conditional access is useful. It is an argument for understanding which signals feed those decisions and how trustworthy those signals are.

Another example is real-time protection state. An actor may disable real-time protection to bypass the AV components, this will trigger an event. However the actor could emit an AV enablement event right after, without actually re-enabling the AV. This event does not have to originate from the Defender process, and this is not possible to check.

If telemetry says the real-time protection was re-enabled, but the actual state is different for some period of time, the portal view and the endpoint reality may not align in the way an analyst or even compliance controls expect. That is exactly the sort of gap defenders need to be aware of.

Reporting to MSRC

I reported these ETW issues to MSRC in January 2025 with a long report that included many (over 100) providers I could influence and a limited proof-of-concept focused on the Microsoft-Windows-Antimalware part. The initial response was familiar: thank you for the report, but this did not meet the bar for immediate servicing. That was not very motivating, but it was not surprising either. Many researchers have received some version of that response. 

Later, while preparing demos for the talk, I noticed that one of my ransomware-related demos no longer behaved the same way. The telemetry still arrived, but the alerting result changed. That suggested someone on the Defender side had read the report and decided that at least part of it was worth fixing.

At first, I was happy. A fix is good.

Then I tested other cases. Fake LDAP activity still worked. Other fake tool simulations still produced the expected downstream behavior. So the specific demo path had been addressed, but the broader class of issue had not.

Microsoft also wrote a signature for my proof-of-concept tool. That was funny and somewhat annoying, because that forced me to bypass AV detection for my detection validation tool, which is a ridiculous sentence to have to write, but also exactly what happened.

The bypass was not sophisticated, I removed some strings and XOR’ed the rest. The point was not to demonstrate a world-class evasion technique, but to show the awkwardness of the situation: a validation tool was detected, a small amount of string obfuscation was enough to change the result, and the underlying issue still existed elsewhere.

This research was first presented at BlackHat USA 2025 on August 6th, under the same title as this blog. Before the talk, Microsoft asked for my deck multiple times. I sent it near the end of June, which by my own standards was early. A few days later I received the following message: 

“The revised fix began rolling out in July. It’s being deployed gradually through a ring-based approach and is expected to reach full deployment by August 7th”

My Black Hat talk was on August 6th. The timing was probably not really a coincidence, but it was an amusing one.

I was interested in the patch and tried to get clarity on what exactly was being fixed. That took several back and forth emails, with almost no success. The answer, vague as it was, mentioned that they were hardening Defender-specific pieces because the behavior looked bad to customers. Other ETW provider owners would need to address their own areas.

After retesting before and after the talk, the picture was mixed:

• Some ransomware-related event generation no longer worked.
• Some anti-malware or real-time protection-related paths were later hardened.
• Some trace provider behavior was locked down.
• Most providers were still unaffected.

The good part is that the better fixes happened in the ETW session manager itself. If the kernel refuses registration or emission for a protected provider, there is no clean user-mode workaround. The not so good part is that they focused on fixing only the most “embarassing” providers and leave the broader trust issue intact.

This is also why I joked in the Black Hat talk that they still had 99 problems and fixed one. That is obviously a simplification, but it captures my frustration. The fix addressed the narrow proof-of-concept path more than the class of behavior I described in the report to MSRC.

Around the same time, I noticed Defender configuration changes indicating more attention to dropped events, out-of-sequence events, capped events, and similar telemetry health indicators. That is, again, a positive development. Vendors should care much more about what they are missing.

I noticed this because I pull and diff MDE configurations regularly. The product changes often, and those changes can be very revealing if you care about how telemetry and detections actually work.

 

Buffers: the part that worried me

The provider spoofing and fake event side is interesting, but the buffer behavior is generally more worrisome and impactful.

As briefly addressed earlier, real-time ETW sessions have buffer pools. ETW uses a pool of shared buffers for each tracing session, not per provider. Multiple providers can write to the same buffers within a session.

Consumers can influence buffer size and buffer count within certain limits. These buffers are in non-paged pool memory in the kernel. This is normal ETW behavior and exists for performance reasons.

You can inspect some session properties with native tooling, such as logman, including information about buffer size and lost events. Seeing the lost event counters made me curious.

The expected behavior is as depicted below: one or more ETW providers emit their events into a trace session, instructed by the session kernel. 

The consumer process, which is attached to the trace session, consumes the events in the buffer pool and the pool is flushed, making space for new events. This commonly happens very frequently, so the chance of the pool being full is not high in normal scenarios.

What happens if the pool is full and the buffer is not drained?

As mentioned before, at a high level, events from providers enter the session buffer. The consumer drains the buffer regularly. Now, if the consumer does not drain the buffer pool and the buffer fills, the session controller kicks in. New events will be dropped, and even more important: providers are instructed they cannot emit more events.

The impact is not neatly isolated in the way I expected. A full pool or badly handled session can prevent providers from emitting events in a way that affects other consumers. The provider is instructed it can not emit events anymore. If a provider is connected to multiple sessions, which is not uncommon to be the case, none of the trace sessions will receive events from any of the providers connected to the trace session with the full buffers.

That means a separate session can interfere with telemetry that an EDR expects to receive. The impact is simple and bad: telemetry stops being produced and thus, is not delivered.

From a defender perspective, that is very bad. If your EDR relies on those ETW providers, and those providers cannot emit the events, then the EDR is blind to that part of the activity. It may still have kernel callback data, minifilter data, or other sources, but the ETW-derived coverage can be completely gone.

This is where the design history matters. ETW was conceived for performance tracing and debugging, not as a security telemetry provider where one consumer’s behavior must never affect another consumer’s visibility.

Another related issue is trace session exhaustion. Windows has a finite number of 64 trace sessions. If those are exhausted, other consumers may not be able to create the sessions they need. This is a different mechanism than capping or buffer loss, but it leads to the same uncomfortable theme: the monitoring pipeline can fail in ways that look like missing activity, unless someone is watching the health of the pipeline itself.

Tooling created during the research

During the research, I built several small tools.

One tool helped inspecting provider security descriptors and make SDDL output more readable. SDDL is powerful, but I do not enjoy reading it raw. Some people can do that fluently, which is impressive, but I prefer tooling.

Another tool emitted controlled events for validation. The idea was to simulate certain behaviors, such as LDAP-heavy tools, without running the real tools. This is useful for detection engineering and pipeline validation.

I also built monitoring around ETW session loss behavior, because there was no convenient tool that showed exactly what I wanted during testing. This helped me observe dropped events and buffer-related effects.

The toolset eventually included functionality to start trace sessions for providers I knew Defender relied on and observe how flooding or unconsumed sessions affected event loss. I am intentionally keeping this section conceptual in the blog version. The important defensive lesson is that telemetry health is observable and should be monitored, not that everyone should reproduce the most disruptive version of the experiment in production.

One of the tools’ intended use cases was still benign: emulate selected attack telemetry, extend those templates with behavior relevant to your own detections, and use it to check if the pipeline and detections still behave as expected. The fact that the same primitives can be misused is exactly why this topic needs vendor attention.

• PockETWatcher — Lightweight ETW consumer
• ETWhat — Provider mode enumeration tool
• ETWLocksmith — Provider security analyzer
• autologgerAnalyzer — Autologger details
• ETWtop — Session performance monitoring
• Provmon — ETW provider registration monitor tool
• BamboozlEDR — ETW event emitting and BOFs

Defensive uses

The original — and still valid — use case is detection validation. If you can generate controlled telemetry that resembles a behavior you care about, you can test whether:

• The telemetry pipeline still receives the expected event.
• Field parsing still works.
• Detections still fire.
• Alert enrichment still behaves correctly.
• Product changes or configuration changes broke assumptions.

This can fit nicely into CI-style detection engineering workflows. You do need to extend the event generation to the behaviors and providers you care about, but the concept is useful.

Another defensive aspect to focus on, is writing some detections on telemetry health monitoring. If event loss spikes and then a source goes quiet, that can be suspicious. It is not automatically malicious, because endpoints also go quiet for boring reasons. Laptops sleep. Users close them. Networks disappear. Products update. But as an input to visibility monitoring, dropped events and sudden telemetry gaps are important.

You can also start looking for unusual provider registrations. This is not universally useful. Some providers are expected to be used by many processes. TCP-related telemetry, for example, can be very broad. But for other providers, there may be only a small set of legitimate emitters. If a random process registers a provider that should only be used by the security product or a Windows component, that is worth investigating.

Finally, defenders should understand capping behavior. If a provider caps at 1.000 events per period, the 1.001st event may not exist in your cloud dataset. If the cap resets 24 hours after the first observed event, that timing matters during both testing and investigations.

What attackers can do with this knowledge

The attacker implications are not subtle. If a cloud EDR caps a certain event type, an attacker can try to create enough noise to hit that cap before performing the activity they care about. The later activity may not appear in the cloud telemetry. The exact usefulness depends on the provider, event type, cap, local detections, and other telemetry sources.

If a trace session or buffer behavior can be abused, telemetry loss can affect more than cloud-side capping. That can impact local consumers, too. The capping examples mostly apply to cloud EDR pipelines, while the buffer/session issue can affect anything relying on ETW.

An attacker could also create fake events to distract analysts. If defenders are looking at a flood of fake malware, fake ransomware, or fake suspicious activity in one place, the real action may be elsewhere and possibly overlooked.

There are also denial-of-visibility angles. Windows has limits on the number of trace sessions. Exhausting session availability or leaving problematic sessions behind can prevent other consumers from creating sessions. Some of these paths require administrative permissions, but some provider emission issues do not.

The cap-based blind spot can last until the cap period resets. The buffer or session-based blind spot can last until the problematic session is removed or the system reboots, depending on the path. Those are very different operational realities, and defenders should not group them together as one generic “ETW issue.”

The point is not that ETW makes EDR useless. It does not. The point is that telemetry assumptions matter.

Sysmon and other telemetry

One question I got after my Blackhat talk was whether this affects Sysmon too. Sysmon is different. The majority of Sysmon’s telemetry comes from kernel callbacks and a minifilter driver, rather than ETW. DNS telemetry is one area where ETW is involved. Sysmon also writes its own events through an ETW-based path, including private logger behavior.

So the answer is nuanced. Sysmon does not rely on ETW in the same way as many EDR cloud telemetry pipelines for collection, but ETW still appears in parts of the picture. Breaking or interfering with Sysmon’s private logging path is a different problem and significantly more work, but not impossible. It is also worth noting that Sysmon has way less telemetry visibility than most EDRs, due to this design.

What it means for logs
I spend a lot of time in logs, and I still like them. But we need to be honest about what they are. Logs are observations. They are not reality.

They are produced by systems with design constraints, performance trade-offs, access control decisions, filters, caps, buffers, implementation bugs, and product-specific logic. Treating logs as perfect truth is convenient, but it is not how these systems work.

That does not mean ETW is bad. Quite the opposite. ETW is incredibly valuable, and there is no equally broad replacement for much of the visibility defenders need. Even people who are skeptical of ETW as a security source have to acknowledge that defenders need the data it exposes.

The right conclusion is not “do not use ETW.” The right conclusion is “understand the failure modes of the telemetry you depend on.” For detection engineers, that means validating both logic and data availability. For incident responders, that means being careful with negative evidence. For product vendors, that means hardening sensitive providers, isolating session impact, exposing telemetry health, and making event loss visible to customers.

For Microsoft, specifically, it means ETW needs to evolve if it is going to be a core security telemetry substrate. I understand that kernel changes are hard and why Microsoft is careful with them. I also understand the push to reduce third-party kernel components in endpoint products. But if security products are pushed out of the kernel and toward platform-provided telemetry, then the platform telemetry needs stronger security properties.

Something has to give.

Practical recommendations

For defenders, I would summarize the practical recommendations as follows:

• Know which detections rely on ETW-heavy telemetry.
• Understand capping behavior for high-value providers.
• Treat missing data as a possible visibility issue, not automatically as absence of activity.
• Monitor dropped, capped, delayed, or out-of-sequence events where your product exposes them.
• Watch for unusual provider registrations where that signal is meaningful.
• Use controlled telemetry generation for validation, but do it carefully and in a lab.
• Ask vendors how they isolate trace sessions and how they surface telemetry loss.

Push Microsoft and other vendors to protect high-value providers and make telemetry health first-class. There is no perfect customer-side fix for the architectural parts. Some of this has to be fixed in Windows and in EDR products. But defenders can still make better decisions when they understand the assumptions under their detections.

References and prior work

I definitely did not figure all of this out on my own. ETW has been researched by many people over many years. Geoff Chappell’s ETW documentation remains one of the most valuable resources for undocumented behavior, even though Geoff sadly passed away. His website is still incredibly useful.

ETW Explorer by Pavel Yosifovich is also one of my favorite tools for looking at providers and manifests. My main complaint is that some text is not as easy to copy as I would like, which is a very detection-engineer complaint. Other than that, it is excellent.

Finally, I want to highlight the work by Matt Graeber, which helped a lot in the initial phase of implementing the event emitting behavior.

The tools I created during this research are on my GitHub. They are intended for validation and research, not for production use or annoying your SOC.

Closing thoughts

The original goal was simple: make detection validation easier. That part still matters. Being able to generate controlled telemetry is useful, especially when the real behavior is destructive, expensive, or impractical to run repeatedly.

But the more important lesson is that telemetry pipelines can lie, lose data, or be influenced in ways defenders may not immediately see.

That is not just a Microsoft Defender for Endpoint problem. It is not just a cloud EDR problem either. Capping mostly affects cloud analytics. Buffer and session behavior can affect anything relying on ETW. Fake events can affect analysts and automation if the pipeline trusts them too much.

So the practical takeaway is simple: know where your detections get their data from. Know what can make that data disappear. Know what can make that data misleading. And keep asking vendors for better telemetry health signals.

Because if your logs can be deceived, your analysts can be, too.

Knowledge center

Other articles

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

KVK 76682307
BTW NL860745314B01