Endpoint detection and response software is supposed to be the thing standing between an attacker and a compromised machine. Research presented at DEF CON 34 in Las Vegas shows how that trust relationship can be turned inside out: by abusing legitimate SentinelOne components, an attacker with local administrator rights could dump memory from Windows’ most heavily protected processes and, ultimately, use the EDR agent’s own defenses to shield a malicious payload from removal. SentinelOne has since fixed the underlying issue in Agent version 26.1.1.

Exploiting Trust, Not a Traditional Bug

The research, from Akamai, centers on Windows Protected Process Light (PPL), a security model designed to stop ordinary processes from reading, modifying, debugging, or killing protected system services such as LSASS, Windows Defender components, and antivirus or EDR engines running at the Antimalware-Light protection level. Notably, the technique required no vulnerable kernel driver and no traditional Windows privilege-escalation bug, it worked by abusing a legitimate, already-trusted EDR process to do things ordinary user-mode software cannot.

Akamai’s researchers found that SentinelOne exposed several Component Object Model interfaces, including one called SentinelHelper. Among its methods was Dump, which a local administrator could invoke to create memory dumps of PPL-protected processes. Unlike SentinelOne’s other exposed functions, this method reportedly did not strictly validate where the calling application was located on disk, giving an admin-level attacker a route to dump processes normally shielded from exactly that kind of access, including SentinelOne’s own agent and Microsoft Defender.

From Memory Dump to Code Execution

The researchers chained the dumping capability with earlier published research on COM-based PPL attacks. By pulling process-specific COM secrets out of the dumped memory, they mapped a path to executing unsigned code inside another PPL-protected process. After working through memory-permission, relocation, and dependency-loading hurdles, the team demonstrated running an unsigned payload inside the protected context of Microsoft Defender itself, a process ordinary malware has no business touching.

Turning the Installer Against Itself

A second angle examined SentinelOne’s installer behavior. The researchers say a legitimate installer could, with a crafted registration value, be made to deploy a non-functional local agent, one that reports a reassuring “secure” status to administrators while quietly disabling any competing endpoint protection already on the machine. That effectively repurposes a trusted vendor installer into a tool for degrading a target’s real defenses.

The team also flagged that an agent’s management-server hostname could be identified through an accessible status interface, and that redirecting that hostname locally could cut off cloud telemetry while leaving the local agent looking active, potentially buying an attacker time before a security operations center notices anything is wrong.

The Endgame: Malware Hiding Behind Its Own Watchdog

The most striking scenario Akamai describes flips SentinelOne’s self-protection features against the organization deploying it. An attacker who places a malicious payload inside the EDR’s own installation directory and then re-enables tamper protection effectively gets SentinelOne to block every other process, including legitimate security tools, from touching or removing that file. The payload ends up evading both Windows’ PPL protections and the EDR’s own defenses simultaneously, hidden in plain sight inside the very software meant to catch it.

What This Means for Defenders

• Update SentinelOne agents to version 26.1.1 or later, where the reported issue has been fixed.
• Tightly restrict local administrator rights, the entire attack chain assumes admin-level access as a starting point.
• Monitor for unexpected EDR installer activity, especially outside of scheduled deployment or update windows.
• Watch for unauthorized changes to local DNS resolution or hosts file entries that could redirect EDR management traffic.
• Review whether any endpoint security platform in use exposes local management interfaces or COM objects that administrators can reach without strong, independent authorization checks.

The research is a reminder that endpoint protection software itself is high-value infrastructure, not just a bystander in the security stack, and that its privileged access, installer logic, and local interfaces deserve the same scrutiny as any other piece of software running with elevated rights on a corporate fleet.