Bring Your Own EDR Breaking Windows Process Protection to build EDR Protected Malware

The talk argues that endpoint detection and response products, which shield themselves with Protected Process Light and tamper protection, can be turned against the systems they guard. The speaker reviews how EDRs use user-mode hooks and kernel callbacks, and why older bypasses such as unhooking, direct syscalls, living-off-the-land binaries and vulnerable drivers have become less reliable.

The focus then moves to SentinelOne. An exposed COM helper's dump method checked only that the caller was an administrator, not who the caller was or where it ran from, so any local admin could dump protected processes. Pairing that with publicly documented techniques for remote COM calls and for mapping a PE into memory, the speaker got a statically linked payload running inside Microsoft Defender, and a demo showed it encrypting files in a folder. A rogue installation path was also described: the site token check ran inside a temporary DLL that could be extracted, and a crafted Base64 JSON value passed it.

The speaker reported that the same access let the injected code block removal of the EDR and tamper with other protected security products, and that similar behavior was seen on CrowdStrike. The issues were disclosed through HackerOne. The main takeaways are that patching a symptom, such as removing user-mode pages from kernel dumps, does not fix the underlying trust problem, and that unexpected security software on a machine deserves the same scrutiny as malware.