History of (anti) MDE analysis

Primer

Nowadays MDE (MsMpEng and co.) is understood to have 3 different analysis stages, see below. The understanding of MDE (and the stages) evolved and changed slightly over time, at least what was publicly and widely known (i.e. by me).

As displayed, the store time analysis techniques are well known, together with the data and format of "known bad" (i.e. yara rules), thus bypassing the store time can be trivial. The startup time and runtime checks of MDE can be observed by some tools, however the data plus format of "known bad" is somewhat unknown.

Analysis History

For a better summary and nicer text see Dobin's post. This is a short overview of (in my opinion) relevant MDE analysis tools. Developing your own malware loader and not documenting new findings with regards to EDR internals does not count.

Interpretation

The tools can be split into 3 "phases", each of which describe the (publicly) available anti-EDR knowledge at that point in time.

Internal static Analysis

First are "internal" analysis tools, rows 1-3, extracting some part of Defender and attacking and understanding it in isolation. Understanding these parts helped us understand how the store time analysis (static and emulation). Row 4 is special in the regard that it "just" fuzzes MDE to find vulns, with the only part of "anti-EDR" research being to better understand MsMpEng.exe and mpengine.dll.

Observation of running MDE

From 2021 up until 2025, rows 5-8, a new paradigm of analysis was developed, as in "Observing how the actual MDE behaves in light of malware".Detonator leverages insights from RedEdr to further enhance visibility and thus insights into analysis logic of MDE.

LLM driven internal static Analysis

In 2026 some attempts are made to understand MDE's logic by reversing MsMpEng's code, as in otterpwn's heavener, SpectreOps' LLM powered EDR analysis and Justin's defender_overview. While these techniques further the understanding of the store time stage, not too much insights are given into the startup and tracking stage.

(LLM driven) internal dynamic Analysis

2026 also marks a new era, combining internal analysis and observations for a first time. My EDR-Introspection for example enumerated the protections of EDR, to ultimately hook all MsMpEng syscalls and gain full* insights into its actions at any time, i.e. enumerate scan triggers. Dobin's new DefRev project aims to find the logic behind these scan triggers (why is a scan getting triggered) and the known bad (when will the scan return a malware-classification, for example suspicious, syscall history or handles).

Conclusion

While the scan triggers might be hard-coded (do a scan of loaded images at startup, do a memscan after CreateRemoteThread, see Reversing Defender), the "known bad" might be stored as data. Similar to defender2yara, these dynamic, runtime "known bad" IOCs could be extracted and bypassing dynamic (runtime) scans could be as easy as bypassing yara scans.