Cybersecurity researchers have identified a novel attack technique termed “Bring Your Own EDR” (BYOEDR), where adversaries exploit trusted components of SentinelOne’s Endpoint Detection and Response (EDR) system to protect malicious software. This method was detailed at DEF CON 34 in Las Vegas, prompting SentinelOne to address the vulnerability in Agent version 26.1.1.
EDR tools are integral to modern cybersecurity, offering deep system visibility and high privileges to monitor processes, files, and system behaviors. However, these privileges can be misused if internal interfaces and trust boundaries are not adequately secured.
The attack leverages Windows’ Protected Process Light (PPL) security model, designed to prevent unauthorized processes from interacting with protected services. EDR products often utilize the Antimalware-Light protection level, similar to other critical services like LSASS and Windows Defender components.
Mechanics of the BYOEDR Attack
Researchers from Akamai discovered that SentinelOne exposed several Component Object Model (COM) interfaces, notably the SentinelHelper object. Within this object, a method named ‘Dump’ allows local administrators to create memory dumps of protected processes. Crucially, this method lacked stringent validation of the calling application’s origin, enabling attackers with administrative privileges to dump processes safeguarded by PPL, including SentinelOne’s agent and Microsoft Defender.
This technique doesn’t rely on traditional vulnerabilities like exploitable drivers or kernel exploits. Instead, it manipulates a legitimate, trusted EDR process to perform actions typically restricted in user-mode software.
By extracting process-specific COM secrets from the dumped memory, attackers can execute unsigned code within another PPL-protected process. In practical terms, this could lead to the execution of malicious payloads within the protected context of Microsoft Defender, bypassing standard security measures.
Additional Exploitation Vectors
The research also highlighted potential weaknesses in SentinelOne’s installer behavior. A manipulated installer could deploy a nonfunctional local agent that reports a “secure” status while disabling competing endpoint protections. This tactic transforms a trusted product installer into a tool that weakens a target’s defensive posture.
Another concern involves management connectivity. Researchers observed that the agent’s management URL could be identified through an accessible status interface. By redirecting this hostname locally, attackers could prevent cloud telemetry collection while the endpoint agent appears active, delaying attack detection from the management console.
The most severe implication arises from reversing an EDR product’s self-protection features. An attacker could place a malicious payload in the EDR installation directory, re-enable tamper protection, and allow SentinelOne to block other processes from modifying or accessing the malware. This approach enables the malicious payload to evade both Windows PPL protections and the EDR’s own defense mechanisms.
SentinelOne has addressed this vulnerability in version 26.1.1 and later. Organizations are advised to update their SentinelOne agents promptly, restrict local administrator rights, monitor for unexpected installer activity, and investigate changes to local DNS or hosts file entries affecting EDR management domains. Additionally, security teams should assess whether their EDR platform exposes local management interfaces accessible without robust authorization controls.
This development underscores the evolving tactics of cyber adversaries who now exploit trusted security tools to facilitate attacks. It highlights the necessity for continuous vigilance and the implementation of stringent security measures to protect endpoint protection systems from being turned against the very assets they are designed to safeguard.
