An innovative cyber attack, dubbed ‘Bring Your Own EDR’, has exploited the trusted components of SentinelOne’s endpoint detection and response (EDR) system, turning it into a formidable shield for malware. This significant vulnerability was unveiled at DEF CON 34 in Las Vegas, prompting SentinelOne to address the issue in their Agent version 26.1.1.
Understanding the EDR Vulnerability
EDR tools are designed to operate with extensive visibility and high-level privileges, enabling them to inspect processes, files, memory, and system behavior extensively. However, these same capabilities can become a liability if local interfaces, installer logic, and trust boundaries are not adequately secured.
The research centered on the Windows Protected Process Light (PPL) model, which aims to safeguard security services from being tampered with by standard processes. This model is frequently utilized by antivirus and EDR products, including SentinelOne, which employs the Antimalware-Light protection level.
Exploiting SentinelOne’s Components
Akamai researchers identified several exposed Component Object Model (COM) interfaces within SentinelOne, including a SentinelHelper object. A method called Dump was particularly noteworthy, as it allowed a local administrator to create memory dumps of protected processes without rigorous validation of the calling application’s origin.
By leveraging this method, attackers could potentially dump processes protected by PPL, including SentinelOne’s own agent and Microsoft Defender. The approach did not necessitate a vulnerable driver, kernel exploit, or traditional Windows privilege-escalation vulnerability, but rather exploited a legitimate, trusted EDR process to perform actions beyond the capability of standard user-mode software.
Implications and Mitigation Steps
The research demonstrated how attackers could chain these capabilities with previous COM-based PPL research to extract process-specific secrets from dumped memory. This enables the execution of unsigned code within a protected process, bypassing typical security mechanisms.
The study also scrutinized the behavior of the SentinelOne installer. It was found that a legitimate installer could be configured to deploy a nonfunctional local agent, falsely reporting a secure status while disabling competing endpoint protections.
The vulnerability has been addressed in SentinelOne version 26.1.1 or later. Organizations are advised to update their SentinelOne agents promptly, restrict local administrator rights, monitor for unusual installer activity, and scrutinize changes to DNS or hosts file entries affecting EDR management domains.
Security teams should assess whether their EDR platforms expose local management interfaces accessible without robust authorization controls. This case highlights the need for treating endpoint protection as a critical infrastructure component, demanding stringent security measures.
