Security researchers Ezra Woods and Mike Manrod, building on an observation from researcher BushidoToken about threat actors abusing legitimate EDR products, documented a technique now being called “EDR-on-EDR violence” or BYOEDR (Bring Your Own EDR). The idea is uncomfortably simple: once an attacker has local administrator rights on a host, they sign up for a free trial of a different EDR product, install it, and use its own management console to blind or kill the EDR that’s already there.

In their testing, the researchers installed Cisco Secure Endpoint (AMP) on a host already running CrowdStrike Falcon and Elastic Defend. From the Cisco console, they went to Management > Policies, opened the Windows Protect policy, cleared every entry from the Exclusions tab, then used Outbreak Control > Blocked Application to add the SHA256 hash of the competing EDR’s process. Both CrowdStrike and Elastic went dark. No tamper-protection alert fired, no malicious binary touched disk, and the only externally visible symptom was that the endpoint stopped checking in.

Why This Slips Past Tamper Protection

Every major EDR vendor ships tamper protection, but it’s scoped to protect that vendor’s own agent from being modified, uninstalled, or have its processes killed by an untrusted caller. It was never designed to stop a second, fully legitimate, digitally-signed security product from blocking it through the second product’s own console. The attacking software is not malware — it’s a real EDR agent doing exactly what it’s licensed to do, with a valid certificate, following its documented workflow for adding entries to a blocklist. That’s what makes it hard: there is no exploit, no unsigned driver, and no LOLBin abuse to hang a signature on.

Detection Strategy: Three Layers

Because the “attack” is a legitimate installer, detection has to shift from signature-matching to behavioral and inventory-based logic:

  1. Unauthorized second-agent installation — flag execution of a competing EDR vendor’s installer on a host that already has an EDR agent registered.
  2. Security product inventory drift — the Windows Security Center (root\SecurityCenter2\AntiVirusProduct WMI class) is the canonical list of registered AV/EDR products on a host. A second product suddenly appearing there, especially outside a change window, is a strong signal.
  3. Absence-based monitoring — the actual payoff of BYOEDR is silence. Correlate any installer/inventory signal above with the target EDR’s heartbeat disappearing.

Sigma Rule: Competing EDR Installer Execution

title: Endpoint Security Agent Installer Execution from Unmanaged Source
id: f3d8a1c2-7b4e-4a9d-9e21-6c8f2b1a4d70
status: experimental
description: Detects execution of a known EDR/AV vendor installer that is not the
    organization's standard deployment tool. Intended to surface unauthorized
    "second agent" installs consistent with BYOEDR / EDR-on-EDR abuse, not to
    replace software inventory controls.
logsource:
    category: process_creation
    product: windows
detection:
    selection_installer:
        Image|endswith:
            - '\SentinelInstaller.exe'
            - '\WindowsSensor.exe'
            - '\CSFalconContainer.exe'
            - '\immpackage.exe'
            - '\AMPInstaller.exe'
            - '\elastic-agent.exe'
            - '\CarbonBlackInstaller.exe'
            - '\CyveraInstaller.exe'
            - '\SEDservice.exe'
    filter_known_deployment_tools:
        ParentImage|endswith:
            - '\ccmexec.exe'
            - '\IntuneManagementExtension.exe'
            - '\msiexec.exe'
    condition: selection_installer and not filter_known_deployment_tools
falsepositives:
    - Legitimate EDR migrations or bake-offs run outside change management
    - Some enterprise deployment tools invoke installers through unusual parents
level: high
tags:
    - attack.defense_evasion
    - attack.t1562.001

Tune the filter_known_deployment_tools list to your actual RMM/EPM/GPO software so this rule alerts only when an installer runs outside the sanctioned deployment path — that’s the real signal. Executing this same logic via WDAC/application control as a hard block is stronger than detection alone.

KQL: Correlate New Security Product Registration with EDR Silence

For Microsoft Sentinel / Defender for Endpoint, hunt for hosts where a new antivirus/EDR product registered in Security Center around the same time an existing agent’s telemetry stopped:

let LookbackHours = 48h;
let InstallEvents = DeviceProcessEvents
| where Timestamp > ago(LookbackHours)
| where FileName has_any ("SentinelInstaller.exe", "WindowsSensor.exe", "immpackage.exe",
                            "AMPInstaller.exe", "elastic-agent.exe", "CarbonBlackInstaller.exe",
                            "CyveraInstaller.exe", "SEDservice.exe")
| project InstallTime = Timestamp, DeviceName, InstallerName = FileName, AccountName;
let SilentHosts = DeviceInfo
| where Timestamp > ago(LookbackHours)
| summarize LastSeen = max(Timestamp) by DeviceName
| where LastSeen < ago(2h);
InstallEvents
| join kind=inner SilentHosts on DeviceName
| where LastSeen > InstallTime
| project DeviceName, InstallTime, InstallerName, AccountName, LastSeen
| order by InstallTime desc

This flags devices where a competing security agent was installed and the host subsequently stopped reporting — the exact fingerprint of a successful BYOEDR blocking action. Pair it with a query against your EDR vendor’s own console/API for a straight heartbeat-gap alert, since DeviceInfo gaps in Defender only tell you about Defender’s own visibility, not a third-party agent’s.

Hardening Recommendations

  • Restrict local admin. BYOEDR is entirely gated on local administrator rights — this is a privilege-escalation problem wearing a defense-evasion costume.
  • Application control (WDAC/AppLocker). Block execution of non-approved security vendor installers by publisher, not just by hash.
  • Web/DNS filtering. Block access to competing EDR vendor trial-signup and download portals from endpoints; there’s rarely a legitimate business reason for a workstation to reach a rival vendor’s console.
  • Alert on Security Center product count changes. A jump from one to two registered AV/EDR products on a single host, outside a documented migration, should page someone.
  • Absence-based alerting. If your EDR doesn’t already alert on agents going silent for longer than your normal check-in interval, build that query today — it’s the single most reliable signal this technique leaves behind.