Cyber Insights: Bring Your Own EDR Attack Could Turn SentinelOne’s Own Defences Against It
9 Min Read
25th August 2026
Overview
Security researchers at Akamai have demonstrated a novel attack technique that turns the trusted capabilities of an endpoint security platform into a potential tool for attackers.
Dubbed “Bring Your Own EDR” (BYO-EDR), the research shows how an attacker with local administrator privileges could abuse legitimate SentinelOne components to interfere with security controls, access protected processes and, in the most significant scenario, potentially use the EDR’s own self-protection mechanisms to shield malicious code.
Unlike traditional attacks against endpoint security products, the technique does not rely on a vulnerable kernel driver or conventional privilege-escalation exploit. Instead, it takes advantage of the elevated permissions and trust relationships that endpoint security software requires to protect a Windows system.
The research was presented at DEF CON 34 and covers several attack paths involving SentinelOne’s local COM interfaces, Windows Protected Process Light (PPL), installer behaviour and management connectivity. SentinelOne has addressed the reported issue in Agent version 26.1.1.
What is a “Bring Your Own EDR” Attack?
Endpoint Detection and Response platforms are deliberately given extensive privileges. They need to inspect processes, monitor files, prevent tampering and interact with parts of Windows that ordinary applications cannot access.
BYO-EDR explores what happens when an attacker turns that trust model on its head.
Rather than attempting to disable the EDR outright, the researchers investigated whether SentinelOne’s privileged functionality could be manipulated to perform actions on the attacker’s behalf.
One of the central technologies involved is Windows Protected Process Light (PPL). PPL is intended to prevent ordinary processes from reading, modifying, debugging or terminating highly trusted security processes. Products such as SentinelOne and Microsoft Defender use these protections precisely because they make interference by malware more difficult.
The Akamai research demonstrates that abusing a trusted security component can potentially provide a route across that boundary without directly breaking PPL itself.
How SentinelOne’s Trusted Interfaces Could Be Abused
Researchers identified several locally accessible SentinelOne Component Object Model (COM) interfaces, including an object known as SentinelHelper.
One method exposed through this interface, called Dump, could reportedly be invoked by a local administrator to create memory dumps of PPL-protected processes. The weakness lay in insufficient validation of where the calling application was located.
Rather than directly attempting to defeat Windows protections, an attacker could therefore ask the trusted SentinelOne process to perform the privileged operation for them.
Researchers demonstrated potential access to memory belonging to SentinelOne itself, Microsoft Defender and other PPL-protected processes.
Taking the research further, Akamai combined this behaviour with previously identified COM-based PPL techniques. By extracting process-specific COM secrets from dumped memory, the researchers demonstrated a path towards executing unsigned code within a protected process.
Their proof of concept ultimately achieved execution of an unsigned payload inside the protected context of Microsoft Defender.
Turning EDR Protection Into Malware Protection
Perhaps the most striking element of the research is the possibility of turning SentinelOne’s own tamper protection into a defensive layer for malicious code.
The researchers demonstrated a scenario in which an attacker could place a malicious payload inside the SentinelOne installation directory and then re-enable the product’s self-protection functionality.
Once protected, other processes could potentially be prevented from accessing or modifying the malicious file.
In effect, a security product designed to stop attackers interfering with trusted files could become the mechanism protecting the attacker’s payload from interference. The malicious code could potentially benefit from both Windows PPL protections and SentinelOne’s own file and process protection mechanisms.
This challenges a longstanding assumption within endpoint security: that files and processes associated with a trusted EDR product can themselves be treated as inherently safe.
Creating a False Sense of Security
A separate aspect of the research examined how SentinelOne’s installer and management functionality could potentially be manipulated.
Researchers found that a legitimate installer could reportedly be supplied with a crafted registration value, resulting in the deployment of a non-functional local agent.
The concerning element is that the endpoint could still appear to be in a “secure” state even though its effective security posture had been deliberately weakened. Competing endpoint protections could potentially be disabled at the same time.
Management connectivity presented another potential avenue for defence evasion. Researchers found that an attacker could manipulate local name resolution — through the Windows hosts file or local DNS configuration — to redirect SentinelOne’s management hostname and prevent the endpoint communicating with its cloud management infrastructure.
A device might therefore continue to appear operational locally while telemetry is no longer reaching the SOC. For defenders, that distinction is critical. A healthy-looking security agent does not necessarily mean that monitoring is functioning correctly.
Why This Matters
This research is particularly significant because it changes the role of the EDR within the attack.
Attackers have historically attempted to evade, disable or uninstall endpoint protection. BYO-EDR presents another possibility: use the security product itself as part of the attack chain.
There is an important limitation. The demonstrated technique requires the attacker to already possess local administrator privileges, meaning it should primarily be considered a post-compromise technique rather than a route for initial access.
However, administrator-level access is commonly achieved during sophisticated intrusions through stolen credentials, malware, compromised administrative accounts or exploitation of other vulnerabilities.
Once that access exists, manipulating the EDR could help an attacker reduce visibility, establish a more resilient foothold and potentially make malicious activity appear to originate from trusted security software.
Detection & Monitoring Recommendations
Traditional detections based solely on whether an executable is signed or belongs to a trusted security vendor may provide limited protection against this type of attack.
Instead, security teams need to consider the context in which trusted EDR processes are behaving.
Unexpected memory dumps involving SentinelOne, Microsoft Defender, LSASS or other PPL-protected processes should be investigated. The same applies to unusual interaction with SentinelOne COM objects, unexplained installer execution and modifications within EDR-controlled directories.
Particular attention should be given to:
Unsigned executables or DLLs appearing inside SentinelOne directories
Unexpected changes to SentinelOne registration or configuration
Windows hosts-file or DNS changes affecting EDR management infrastructure
Local administrator activity immediately before EDR configuration changes
SOC teams should also correlate telemetry loss with local endpoint events. An endpoint that suddenly stops reporting should not automatically be dismissed as a connectivity problem, particularly if configuration or DNS changes occurred immediately beforehand.
Recommended Actions
Organisations using SentinelOne should prioritise upgrading Windows agents to version 26.1.1 or later and confirm that the update has reached servers, workstations, VDI environments and other managed Windows endpoints.
Verification should extend beyond the version number. Security teams should independently confirm that endpoint telemetry is continuing to reach the central management platform rather than relying solely on the health status displayed by the local agent.
Monitoring should also be strengthened around SentinelOne installation directories and configuration data. Unexpected file creation, unsigned DLLs and unauthorised installer activity should trigger investigation.
Where possible, organisations should monitor local DNS and hosts-file modifications that could interfere with security tooling. A sudden loss of SentinelOne cloud connectivity following such a change should be treated as a potential security event rather than simply an operational fault.
Finally, administrative access remains an important control. Because exploitation requires local administrator privileges, reducing the number of privileged accounts and tightly monitoring their use can make the attack considerably harder to execute.
Analyst Assessment
The BYO-EDR research represents an important development in defence-evasion tradecraft because it demonstrates how attackers could potentially repurpose security controls rather than simply bypass them.
The ability to use a trusted EDR component to interact with PPL-protected processes is significant on its own. More concerning is the demonstrated possibility of placing malicious code within an EDR-controlled location and then allowing the product’s own protection mechanisms to make that payload harder to access or remove.
There is currently no indication in the supplied research that the technique is being widely exploited in real-world attacks, and the requirement for local administrator privileges limits its usefulness as an initial compromise vector. Nevertheless, its potential value during an advanced intrusion is clear.
For organisations using SentinelOne, upgrading to version 26.1.1 or later should be accompanied by integrity monitoring around the EDR itself. Security teams should validate telemetry reception, monitor protected directories and investigate unexpected interaction with PPL processes rather than assuming the endpoint security platform can always be treated as a trusted observer.
How NormCyber MDR Helps Detect Attacks Against Security Controls
When attackers begin manipulating the tools designed to detect them, relying on a single security signal is no longer enough. NormCyber’s Managed Detection and Response (MDR) service combines continuous monitoring with expert-led analysis across endpoint, identity and network telemetry, helping organisations identify suspicious behaviour even when legitimate security software is involved in the attack chain.
Our SOC analysts look beyond whether an application is simply trusted or digitally signed, investigating the wider context around unusual privileged activity, unexpected configuration changes, suspicious process behaviour and sudden gaps in security telemetry. This can help identify situations where an attacker is attempting to tamper with an EDR platform, interfere with its management connectivity or use trusted administrative capabilities to hide malicious activity.
By correlating signals across the wider environment rather than depending on one endpoint control in isolation, NormCyber MDR provides an additional layer of visibility when the security tooling itself becomes part of the attack surface. Discover how NormCyber MDR can strengthen your organisation’s detection and response capabilities and provide 24/7 expert oversight against emerging techniques designed to undermine traditional security controls.
