EDR detection of SystemTraceProvider consumers — current data on Defender ATP / CrowdStrike / SentinelOne?

[franzjeger]

Hi PerfView maintainers,

I'm working on an open-source Windows tool (FrameSage) that consumes ETW kernel events via the same SystemTraceProvider API PerfView uses — StartTraceW with a private session GUID, EVENT_TRACE_FLAG_CSWITCH | DPC | INTERRUPT | DISK_IO | MEMORY_HARD_FAULTS, OpenTraceW in PROCESS_TRACE_MODE_REAL_TIME | PROCESS_TRACE_MODE_EVENT_RECORD, the works. The spike binary and the architecture write-up are linked at the bottom.

We're at the point in the v0.7 release cycle where we need to validate the consumer behaves cleanly under modern EDR products, specifically:

1. Microsoft Defender for Endpoint (the EDR product, not consumer Defender)
2. CrowdStrike Falcon (any tier)
3. SentinelOne Singularity

PerfView has been exercising this API since long before any of these products existed, and you've collectively had every EDR conversation under the sun. So I'd love your current take on:

1. Which of the three (if any) currently flag a plain SystemTraceProvider consumer with default policy? We have anecdata that CrowdStrike's behavioral engine sometimes flags ETW consumers, but no current evidence-level data. PerfView's release history would suggest you've seen reports of this when users in EDR-managed shops try to use PerfView.
2. For products that do flag, has the standard remediation been Authenticode signing + vendor-allow-list submission, or is there a behavioral pattern (e.g., specific provider GUIDs, event flags) that gets flagged regardless of signature?
3. Is there a hunting-query pattern any of these products use to detect "non-PerfView non-xperf SystemTraceProvider consumers" that we should be aware of? (Our validation criteria require evidence-level results — screenshots/logs/exports — not "seemed fine.")

If anyone on the maintainer side runs a multi-EDR home lab and would be willing to run our spike binary (60 s + 5 min --duration runs, plus one run with a real game in the foreground) and capture EDR console output, we'd be deeply grateful. The validation criteria we're held to (and the env-1 gap that motivates this outreach) are documented in spike/etw-edr-report.md §6.1 so you can see exactly what we'd need.

Happy to provide:

• The unsigned spike binary directly, or
• Compile instructions for anyone reasonably uncomfortable running an unsigned binary, or
• The full schema-research doc (spike/etw-schemas.md) so technical reviewers can validate "this is just a normal ETW consumer" before lending a test box.

Hard cutoff on my side: if I don't have evidence-level data by day 5, I escalate to paid in-house testing for the un-validated product. So fast "no, can't help" responses are also genuinely valuable — they let me reallocate budget.

Thanks for reading.

—Frank
FrameSage maintainer
https://github.com/franzjeger/framesage-win

Reference links

• Repo: https://github.com/franzjeger/framesage-win
• Phase 1 ETW spike report: https://github.com/franzjeger/framesage-win/blob/main/spike/etw-report.md
• ETW kernel-event schema research (citations per opcode): https://github.com/franzjeger/framesage-win/blob/main/spike/etw-schemas.md
• EDR validation scope + criteria: https://github.com/franzjeger/framesage-win/blob/main/spike/etw-edr-report.md
• v0.7 architecture: https://github.com/franzjeger/framesage-win/blob/main/audit/v0.7-architecture.md

[brianrob]

@franzjeger, apologies for not getting back to you sooner. This got buried under some other work.

My experience in this space has been specific to Defender. I've not received any reported issues that I'm aware of around CrowdStrike or SentinelOne Singularity. While Defender is somewhat of a moving target regarding how long it takes to scan binaries, what it flags, etc. the biggest issue that I've run into has been around the fact that Defender and ETW can fight over the PMU. Defender uses the PMU for TDT and ETW uses it for CPU sampling. These two can interact poorly in older versions of Windows. Newer versions have an arbitration API that helps them co-exist better. When things fail though, they often fail silently because ETW sessions usually start after Defender, and so you'll get a trace, but the trace won't contain CPU samples even if you asked for them.

Unfortunately, I don't have much experience in the area of binary flagging.

And again, apologies for not getting back to you sooner.