Bring Your Own EDR: How Akamai Turned SentinelOne Into a Trojan Horse at DEF CON 34

At DEF CON 34 in Las Vegas, Akamai researcher Shahak Morag unveiled a novel attack technique called "Bring Your Own EDR" (BYOEDR). The method weaponizes a legitimate SentinelOne endpoint agent — turning the very tool designed to protect endpoints into a privileged Trojan horse that can execute unsigned code and shield malware from removal .

This is not a theoretical exercise. The attack exploits SentinelOne's exposed COM interfaces and signed installer binaries to bypass Windows Protected Process Light (PPL), a security mechanism that normally prevents user-mode processes from accessing protected system processes. SentinelOne has patched the issue in Agent version 26.1.1 .

How the BYOEDR Attack Works

The attack chain is executed in three stages, each abusing a different trusted SentinelOne component :

1. Dumping PPL-Protected Process Memory

A local administrator uses the SentinelHelper.1 COM object's Dump method to dump the memory of any Protected Process Light (PPL) process. The SentinelHelper.1 interface is a legitimate administrative tool, but it was exposed without adequate access control. This allows an attacker with local admin rights to defeat PPL protections entirely, reading the memory contents of processes like Windows Defender .

2. Injecting Unsigned Code into the Elevated Process

After dumping the PPL-protected process, the attacker injects unsigned code into that elevated process. Crucially, this code injection originates from a SentinelOne-signed component — the operating system trusts code signed by SentinelOne. The injected unsigned code, wrapped in a trusted carrier, bypasses Windows code integrity checks .

3. Shielding Malware from Detection and Removal

Finally, the attacker leverages the same trusted SentinelOne processes and interfaces to prevent the EDR from detecting or removing the injected malware. Because the malware runs within or alongside SentinelOne's own trusted processes, the EDR's anti-tampering and self-protection mechanisms effectively shield the malware from itself .

The attacker can also install a rogue SentinelOne agent without a valid license and block management telemetry via local DNS manipulation, isolating the compromised system from the central management console .

What Vulnerability Does It Exploit?

The root issue is that SentinelOne exposed powerful Component Object Model (COM) interfaces — specifically SentinelHelper.1 — to local administrators without adequate access control. Additionally, its signed installer binaries could be repurposed to perform privileged actions that normal unsigned binaries cannot .

As of the disclosure date, no public CVE identifier has been widely reported for this specific issue .

It is important to note that the attack requires local administrator privileges on the target machine. It is not a remote code execution vulnerability. However, once an attacker gains local admin access through a separate initial compromise (such as exploiting a vulnerable application or using stolen credentials), BYOEDR enables them to bypass PPL protections that are meant to contain such compromises .

The Patch: SentinelOne Agent 26.1.1

SentinelOne fixed the reported issue in Agent version 26.1.1. The fix involved hardening the exposed COM interfaces and restricting how the installer binaries and trusted components can be used . Organizations should ensure all SentinelOne agents are upgraded to version 26.1.1 or later immediately .

Broader Implications for Trusted Security Software

The BYOEDR technique highlights a fundamental trust problem: security software is granted high privileges and deep system access by design. When those capabilities are exposed through accessible interfaces or signed binaries, attackers can repurpose them as offensive tools .

• PPL is not an absolute defense. PPL protections can be bypassed if a PPL-signed component (like an EDR) exposes a memory dump or code-injection primitive to local users .
• Signed binaries are a double-edged sword. Code-signing guarantees origin, not safety. Attackers can leverage "living-off-the-land" security products (LOLSPs) similarly to how they abuse trusted OS binaries .
• Vendor responsibility is paramount. Security vendors must audit their own COM interfaces, driver access controls, and installer validation logic with the same rigor they apply to finding flaws in third-party software .

Mitigation Steps for Organizations

To defend against BYOEDR attacks, organizations should take the following actions:

1. Update immediately — Ensure all SentinelOne agents are upgraded to version 26.1.1 or later .
2. Harden local admin access — Since the attack requires local admin privileges, limit and tightly control administrative accounts. Implement just-in-time (JIT) admin access and monitor for unusual privilege elevation .
3. Monitor for COM abuse — Deploy detection rules for suspicious use of SentinelOne's COM interfaces (e.g., SentinelHelper.1 or unexpected calls to Dump methods) by non-SentinelOne processes .
4. Apply least privilege broadly — Treat all security agents as potential attack surfaces. Restrict interactive logins, enforce application control (e.g., WDAC or AppLocker), and segment administrative workflows .
5. Review vendor hardening practices — When evaluating EDR/XDR products, ask vendors how they protect their own privileged interfaces from local abuse, not just from remote exploits .

A Growing Family of Trust Abuse Attacks

BYOEDR is not an isolated incident. A similar technique called "Bring Your Own Installer" (BYOI), discovered by Aon's Stroz Friedberg in 2025, exploits SentinelOne's upgrade/downgrade process to disable anti-tamper protections, leaving endpoints unprotected for malware execution . BYOI was observed in real-world attacks deploying Babuk ransomware .

The combination of BYOEDR and BYOI demonstrates that attackers are increasingly targeting the trust placed in security software itself, not just the vulnerabilities in the applications it protects.