At DEF CON 34 (Las Vegas, August 7, 2026), Akamai security researcher Shahak Morag presented "Bring-Your-Own-EDR – Breaking Windows Process Protection to build EDR-Protected Malware," published the same day as an Akamai blog post, 'Bring Your Own EDR: How to Turn a Commercial EDR into a Trojan Horse.' The research shows that SentinelOne exposes three local COM objects -- SentinelHelper.1, SentinelUI.1, and SentinelAgent.1. SentinelHelper.1 alone exposes a wide method surface: `Dump(uint processId, string userDumpPath, string kernelDumpPath)`, `GetAgentStatusJSON`, `ApplyConfig`, `GetConfig`, `SetConfig`, `SetProtectionState`, `UnprotectPPL`, `Stop`, `GetDumper`, `GetServiceToken`, and `LiveKernelDump`. Of these, `Dump` -- designed for use by the legitimate DiagnosticsCollector.ps1 script -- is the outlier: unlike SentinelHelper's other methods, it checks only that the caller holds administrator privileges, not the caller's file-system location. That gap lets any local-admin process invoke Dump against Windows Protected Process Light (PPL) targets signed at the `PsProtectedSignerAntimalware-Light` signer level, including SentinelOne's own SentinelAgent.exe and Microsoft Defender's MsMpEng.exe.

The full exploit chain has four phases. First, the attacker dumps a PPL process's memory via SentinelHelper.Dump, using `CoSetProxyBlanket` to configure the COM security/impersonation level needed to make the call succeed. Second, the dump is analyzed in WinDbg to recover process-specific COM secrets -- `combase!CProcessSecret::s_guidOle32Secret` (observed by Akamai as `{6c8844c0-0cd1-7a62-6f72-57d03fe54d6a}` in their proof-of-concept run) and the `g_pMTAEmptyCtx` pointer -- which, combined with the `CStdStubBuffer_AddRef` primitive, grant an arbitrary memory-read/injection primitive inside the PPL address space. This step builds directly on Slowerzs' prior PPLSystem research (github.com/Slowerzs/PPLSystem, blog.slowerzs.net/posts/pplsystem/, May 2024), which had already shown how to extract a PPL process's COM secret and context to remotely invoke `IRundown::DoCallback` inside the process, but stopped short of achieving arbitrary code execution; Akamai's contribution is extending that primitive into full shellcode execution. Third, the attacker reflectively maps an unsigned payload into the protected process using `NtMapViewOfSection`, working around several practical obstacles: the mapped entry page defaults to PAGE_READONLY (fixed via `NtProtectVirtualMemory`, flipping it to PAGE_EXECUTE_READWRITE), the PE-to-shellcode conversion tool (PE_TO_SHELLCODE) places its relocation-fixing code outside the mapped PE sections (worked around with a custom Python script that adds a `.overlay` section as an 8th PE section carrying the relocation shellcode), and relocation requires all sections to be marked RWX (characteristics `0xE0000020`, verified copy-on-write via WinDbg's `!vprot`) so the fixup code can rewrite them before the loader flips permissions back. The payload is statically compiled so it does not pull in unsigned runtime DLLs (e.g., vcruntime140.dll), which PPL rejects. Fourth, `NtCreateThreadEx` starts a thread at the mapped shellcode, achieving unsigned code execution inside the PPL boundary -- effectively subverting the code-signing enforcement PPL exists to guarantee.

Akamai also documented two complementary, non-memory-corruption abuses of SentinelOne's own installer and self-protection logic. The Windows MSI installer's registration flow can be tricked into completing a non-functional install: the installer extracts a temporary validation DLL, calls it, and deletes it, and Akamai used WinDbg plus Process Monitor to intercept that DLL and reverse-engineer the Base64-encoded JSON site-token format it expects (`{"url": "http://127.0.0.1:8888/", "site_key": "abc123xyz"}`), without any real management server; newer versions add a check against a `/api/v1.6/gw-overall-status` HTTP endpoint that a mock loopback server can also satisfy. The resulting agent reports a 'SECURE' status while providing no real protection. Separately, an attacker can run `sentinelctl.exe unprotect` to disable tamper protection, stage malware inside SentinelOne's own install directory, and re-run `sentinelctl.exe protect` (SetProtectionState/UnprotectPPL are the corresponding COM-exposed equivalents), causing the malware to inherit both PPL and SentinelOne's anti-tamper protection -- including a `PROCESS_QUERY_LIMITED_INFORMATION`-only access restriction against later tampering attempts -- turning the trusted EDR into a shield for the very payload it should detect. Akamai also queried the SentinelAgent COM object's `GetAgentStatusJSON` method to learn the configured management hostname, then redirected it to 127.0.0.1 via the local hosts file, silently cutting off cloud telemetry while the console still shows a protected status. Akamai explicitly linked the installer-abuse pattern to SafeBreach researcher Shmuel Cohen's 2023/2024 Black Hat Asia research weaponizing Palo Alto Networks Cortex XDR (safebreach.com/blog/dark-side-of-edr-offensive-tool/ and the Cortex-specific bypass writeup), which showed the same class of trusted-installer/self-protection abuse against a different EDR vendor.

Exploitation requires existing local administrator access -- no kernel exploit, signed vulnerable driver, or memory-corruption vulnerability against SentinelOne itself is needed. No CVE has been assigned. SentinelOne shipped Agent 26.1.1, which addresses the reported caller-validation gap in SentinelHelper.Dump, following Akamai's responsible disclosure; vulnerable versions run through 26.1.0, and the fix was already generally available at the time of public disclosure.