SentinelOne “Bring Your Own EDR” Attack Enables PPL Bypass and Unsigned Code Execution

A newly demonstrated “Bring Your Own EDR” technique shows how a legitimate SentinelOne endpoint agent could be abused as a privileged Trojan horse on Windows.

Akamai researchers found that exposed administrative interfaces and trust relationships in the EDR stack could enable Protected Process Light (PPL) abuse and unsigned code execution without a kernel exploit, vulnerable driver, or conventional memory-corruption flaw.

Presented at DEF CON 34 by Akamai researcher Shahak Morag, the research highlights a fundamental endpoint-security concern: EDR products run with exceptionally high privileges, so weaknesses in their local interfaces, installers, or enrollment logic can create high-impact attack paths. SentinelOne fixed the reported issue in Agent version 26.1.1.

SentinelOne “Bring Your Own EDR” Attack Enables PPL Bypass

The proof of concept centers on SentinelOne’s Component Object Model (COM) interface, specifically SentinelHelper.1. Akamai identified a Dump method that accepts a process ID and can generate a memory dump from the targeted process.

Although exploitation requires local administrator privileges, the request is executed through SentinelOne’s protected process context. This allowed the researchers to dump processes protected by Windows PPL, including SentinelOne components and Microsoft Defender’s MsMpEng.exe.

PPL is intended to protect sensitive Windows and security-product processes against ordinary tampering, including reading process memory, modifying code, debugging, or termination.

Antivirus and EDR components commonly use the Antimalware-Light protection level, meaning a local administrator should not automatically be able to access them in the same way as ordinary processes.

In this case, Akamai found that the exposed COM capability checked for administrative privileges while operating inside the protected SentinelOne service context.

That effectively created a bridge across the PPL boundary, allowing an administrator to dump protected processes without deploying a malicious driver or exploiting a Windows kernel vulnerability.

Akamai chained the dump primitive with previously published PPL research to retrieve COM-related secrets from protected targets. The team then refined an injection workflow to ensure code mapped into a PPL process could execute rather than merely remain resident in memory.

The researchers addressed practical barriers including memory-protection behavior, relocation handling, shellcode mapping, and unsigned dependency loading. By statically compiling the payload and removing unsigned runtime DLL dependencies, they reported unsigned code execution in a PPL process, including Microsoft Defender.

The attack chain is significant because it does not depend on traditional high-severity prerequisites such as a vulnerable kernel driver, a zero-day Windows kernel bug, or a memory-corruption exploit. Instead, it abuses a trusted security product’s privileged local functionality after an attacker obtains administrator access.

The research also examined SentinelOne installation and registration behavior. Under tested conditions, Akamai reported that crafted token data could be accepted during installation, producing an agent that appeared secure locally but did not have functional management connectivity.

Later versions reportedly added requirements involving a locally hosted endpoint for a status API request, but the broader risk remains: EDR deployment and enrollment workflows can expand an organization’s attack surface.

Akamai also demonstrated that local hostname-resolution changes could redirect the configured management hostname to localhost. Such manipulation could disrupt cloud telemetry while leaving the agent apparently operational on the endpoint, potentially delaying discovery of compromise.

Mitigation

Organizations using SentinelOne should upgrade affected Windows agents to version 26.1.1 or later and validate vendor guidance across their deployment environment.

Security teams should also:

• Restrict and continuously review local administrator privileges.
• Monitor PowerShell activity that instantiates SentinelHelper.1 or invokes unusual SentinelOne diagnostic functions.
• Alert on unexpected process-dump files, especially those involving security-product processes.
• Audit EDR installer launches, agent enrollment attempts, and changes within security-product installation paths.
• Investigate local DNS or hosts-file modifications affecting EDR management domains.
• Treat self-protection modules, COM interfaces, installers, and management communications as privileged assets requiring continuous validation.

The finding is a reminder that endpoint agents are not merely defensive controls. If their protected interfaces, installers, or telemetry pathways are weakly hardened, attackers with administrative access may be able to convert the tools designed to stop intrusion into some of their most powerful assets.