Bring Your Own Installer: Bypassing EDR Through Agent Version Change Interruption

Bring Your Own Installer is a technique which can be used by threat actors to bypass EDR protection on a host through timed termination of the agent update process when inadequately configured.

Summary

Stroz Friedberg Incident Response Services (“Stroz Friedberg”) observed a method used by a threat actor to bypass SentinelOne Endpoint Detection and Response (“EDR”). This method circumvents SentinelOne’s anti-tamper feature by exploiting a flaw within the upgrade/downgrade process of the SentinelOne agent, resulting in an unprotected endpoint. In response to this attack pattern, SentinelOne provided mitigation steps to their clients and assisted Stroz Friedberg with a disclosure of this attack pattern to other EDR vendors. Customers of SentinelOne should review the remediation guidance to ensure they are protected.

Background

SentinelOne EDR is an endpoint protection solution used to detect and block threats. Because it is critical for EDR to constantly monitor endpoint behavior, this technology is built with anti-tamper protection that requires an administrative action in the SentinelOne management console or a unique code to remove an agent from SentinelOne’s protection.  The goal of this anti-tamper safeguard is to restrict unauthorized users from disabling protection measures and prevent malware from trivially terminating EDR processes.

In an incident investigated by Stroz Friedberg, a threat actor gained local administrative access and bypassed these protections without the anti-tamper code. Upon successfully disabling the EDR agent, the threat actor executed a variant of the Babuk ransomware.

Forensic Analysis

The threat actor gained local administrative access on a publicly-accessible server through exploitation of a CVE in an application running on the server. During forensic analysis of the system Stroz Friedberg observed several indicators of EDR bypass:

• File creation of multiple versions of legitimate signed SentinelOne installer files, in this case SentinelOneInstaller_windows_64bit_v23_4_4_223.exe and SentinelInstaller_windows_64bit_v23_4_6_347.msi
• C:\Windows\System32\winevt\Logs\SentinelOne%4Operational.evtx
  • EventID 1: Multiple ProductVersion changes between versions 23.4.4.223 and 23.4.6.347 over approximately a 10-minute period
  • EventID 93 as the last event in the log: CommandType: unload
• C:\Windows\System32\winevt\Logs\Application.evtx
  EventID 1042: MsiInstaller Installer Exited for SentinelInstaller.msi
• Additional event logs and other forensic evidence associated with product version changes, including scheduled task changes, service stop/start events, local firewall configuration changes, etc. were also observed.
• Stroz Friedberg did not observe any usage of malicious driver files, previously written about here or vulnerable drivers as discussed here

Based on the forensic evidence, Stroz Friedberg assessed that the threat actor likely bypassed the protection through a vulnerability in the local upgrade process. Stroz Friedberg later confirmed that the impacted environment did not have local upgrade/downgrade online authorization enabled at the time of the incident.

Testing Methodology

To replicate this behavior, Stroz Friedberg performed testing on a Windows 2022 Server virtual machine with SentinelOne EDR software version 23.4.6.223 installed. To verify the agent was online and active, Stroz Friedberg confirmed that the EDR processes were running and that the agent had an “Online” status within the management console.

Figure 1: SentinelOne Processes Prior to the Version Change.

To initiate an upgrade or downgrade, Stroz Friedberg ran the MSI windows installer file for a SentinelOne version that was different from the installed version. When running MSI files, Microsoft Windows uses its native installer program, msiexec.exe, to perform the installation. This can be verified by running a tasklist in the command prompt terminal.

While observing the process tree shortly after initiating the normal SentinelOne agent version change process through task manager, all SentinelOne processes that were previously running were terminated with approximately 55 seconds before the MSI installer spawned processes for the new agent version.

Figure 2: Abstraction of Expected SentinelOne Agent Version Change Process.

During the time when no SentinelOne processes were active, Stroz Friedberg was able to interrupt the upgrade by terminating the msiexec.exe process associated with the SentinelOne version change by executing a taskkill command from a command prompt running with local administrator permission.

Figure 3: Killing the Windows Installer Executable that Aids in the SentinelOne Version Change.

Because the old version SentinelOne processes were terminated during the upgrade, and the new processes were interrupted before spawning, the final result was a system without SentinelOne protection.

Figure 4: Abstraction of Bring Your Own Installer EDR Bypass.

Stroz Friedberg also observed that the host went offline in the SentinelOne management console shortly after the installer was terminated. Further testing showed that the attack was successful across multiple versions of the SentinelOne agent and was not dependent on the specific versions observed in this incident.

Figure 5: SentinelOne Processes View Showing Before and After Early Termination of the Installer.

Remediation

Stroz Friedberg reported their findings to SentinelOne who responded promptly and issued guidance on mitigating the issue to their customers. SentinelOne has an “Online authorization” feature which removes the ability to perform local upgrades and downgrades and can be found in the Sentinels Policy menu in the management console. At the time of Stroz Friedberg’s investigation and testing, this option was not enabled by default.

Figure 6: SentinelOne Local Upgrade/Downgrade Policy Menu.

Stroz Friedberg performed preliminary testing surrounding this feature and was unable to perform the EDR bypass as previously described above once this option was enabled. Stroz Friedberg coordinated the publication of this blog post with SentinelOne to ensure that mitigation guidance was available to customers prior public disclosure.

Prior to the publication of this blog post, SentinelOne assisted Stroz Friedberg with a private disclosure of this attack pattern to other EDR vendors so that their products could be assessed prior to Stroz Friedberg's public disclosure of this attack. As of the date of publishing, Stroz Friedberg does not have knowledge of any EDR vendor, including SentinelOne, that is currently impacted by this attack when their product is properly configured.

Contact

If you suspect you are compromised or need assistance in assessing compromise, please call our Incident Response hotline. If you are from a Law Enforcement Agency or Endpoint Detection and Response vendor and wish for more details, please contact Stroz Friedberg  Cyber Solutions. For other questions regarding this blog post, please contact EDRVendorContact@strozfriedberg.com.

Update 5/9/25

Updated title. Removed outdated guidelines from "Update 5/6/25". Please refer to SentinelOne's blog post for the latest information and guidance.

Update 5/7/25

SentinelOne provided Stroz Friedberg’s Cyber Solutions delivering Stroz Friedberg Digital Forensics and Incident Response Services, additional details and protections here.

Update 5/6/25

SentinelOne posted additional guidance regarding this attack pattern, which can be found here. In this guidance, SentinelOne highlighted the protections they offer or make available to their customers against this attack.

As a point of clarification of our original blog post, some of the EDR vendors that were contacted did not respond to the disclosure of the attack pattern.

We appreciate SentinelOne’s continued engagement with our team and their commitment to the security of their clients.