EDR Evasion and Defence Guide: BYOVD, Unhooking and Tamper Protection

Endpoint detection and response (EDR) is now one of the first things an intruder tries to blind, and a blinded agent can still look healthy in the console while ransomware or data theft runs underneath it. Attackers load signed but vulnerable drivers to reach the kernel, remove user-mode hooks, call system services directly, patch Event Tracing for Windows (ETW) and the Antimalware Scan Interface (AMSI), and abuse scanning exclusions. This guide describes those techniques at the level of MITRE ATT&CK, then concentrates on what defenders control: driver blocking, kernel isolation, tamper protection, exclusions, detecting sensor failure and the identities that can switch protection off. It is for endpoint engineers, detection engineers and security architects, and uses Windows examples because most of this tradecraft is documented there; the principles apply to Linux and macOS agents too.

Key takeaways

• Treat sensor silence as an alert. Successful evasion often triggers no detection; it removes the telemetry that would have produced one, so missing heartbeats, crashed agents and logging gaps need their own detections.
• Close the kernel door first. Bring Your Own Vulnerable Driver (BYOVD) gives an attacker with administrator rights a route into the kernel, where they can blind any user-mode protection. The Microsoft vulnerable driver blocklist, memory integrity (HVCI) and App Control for Business driver policies are the main counters.
• Tamper protection only works if it is managed centrally. Locally togglable protection, broad exclusions and Safe Mode reboots are the low-effort ways around it.
• Exclusions are attack surface. ATT&CK tracks both adding exclusions and hiding payloads in existing ones (T1564.012); every exclusion needs an owner, a reason and a review date.
• Most evasion needs administrator rights. Local administrator sprawl, shared local passwords and weakly protected EDR console accounts are the real enablers, so identity controls are part of EDR defence.

How EDR sees an endpoint, and where it goes blind

An EDR agent combines several sensors, each with a different failure mode, so know which sensor each detection depends on.

Controls in the kernel or under virtualisation-based security are harder to evade than user-mode hooks, and anything an administrator can change, an attacker with administrator rights can usually change too unless tamper protection or a higher trust boundary prevents it.

In the current ATT&CK matrix (v20, October 2026) TA0005 is named Stealth, and techniques that break security tooling sit under a separate Defense Impairment tactic (TA0112). Content mapped to the older Impair Defenses technique (T1562) should be re-mapped.

EDR evasion techniques mapped to controls

The table describes what each evasion family achieves, not how to perform it.

Hardening against BYOVD and kernel-level attacks

ATT&CK describes BYOVD under Exploitation for Privilege Escalation (T1068): adversaries "may bring a signed vulnerable driver onto a compromised machine" to run code in the kernel. Once in the kernel they can terminate protected processes and remove the callbacks EDR relies on. Loading a driver needs administrator rights, so this is a post-compromise step. ATT&CK lists Agrius using a public driver, GMER64.sys, to stop and remove security software.

• Vulnerable driver blocklist: Microsoft states that since the Windows 11 2022 update the blocklist "is enabled by default for all devices", is enforced whenever memory integrity, Smart App Control or S mode is active (except on Windows Server 2016), and is updated quarterly as well as through monthly Windows updates. Check that it has not been switched off in the Windows Security app on older or upgraded estates.
• Memory integrity (HVCI): runs kernel-mode code integrity inside virtualisation-based security, so unsigned code cannot be made executable in the kernel. It does not stop data-only writes through a vulnerable driver, which is why the blocklist matters. Verify with the Win32_DeviceGuard WMI class: SecurityServicesRunning containing 2 means memory integrity is running.
• ASR rule "Block abuse of exploited vulnerable signed drivers (Device)": GUID 56a863a9-875e-4185-98a7-b882c64b5ce5. It stops applications writing known vulnerable signed drivers to disk but, as Microsoft notes, "doesn't prevent loading existing drivers already on the computer". It is not supported through Configuration Manager; deploy it with Intune, an MDM CSP or Group Policy.
• App Control for Business driver policy: where HVCI cannot be enabled, Microsoft recommends adding the driver block rules to your App Control policy, removing the downloadable policy's Allow All rules before merging into an allowlist. Event 3099 confirms the policy loaded; already-running drivers are blocked only after a reboot.
• Driver allowlisting for high-value servers: Microsoft is explicit that the blocklist "isn't guaranteed to block every driver found to have vulnerabilities". For domain controllers, hypervisor management and backup servers, allow only the drivers each system needs.

Tamper protection and agent self-defence

In Microsoft Defender for Endpoint, tamper protection keeps real-time protection, behaviour monitoring, cloud-delivered protection and security intelligence updates switched on and, under certain management conditions, prevents exclusions being added or modified. Other EDR products offer equivalents (uninstall tokens, protected agent processes); ask your vendor which attack paths above each one covers.

• Manage it centrally: set tamper protection from the Defender portal, Intune or Configuration Manager, not the Windows Security app. Microsoft notes that in managed organisations "individual users can't change the tamper protection setting". Check state with Get-MpComputerStatus and the IsTamperProtected property.
• Control troubleshooting mode: it temporarily lifts tamper protection on a device; restrict who can start it and alert on use outside a ticket.
• Watch for silent failure: Microsoft warns that changes to protected settings "might appear to succeed but are actually blocked". Event 5013 records that tamper protection blocked a change, a strong signal that someone tried.
• Block the Safe Mode route: enable the ASR rule "Block rebooting machine in Safe Mode" (33ddedf1-c6e0-47cb-833e-de6133960387). Microsoft notes that in Safe Mode "many security products are disabled or run with limited functionality".
• Protect LSASS as well as the agent: LSA protection (RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, value 1 for UEFI lock) stops non-protected processes reading LSASS memory. It is on by default only for new, enterprise-joined, HVCI-capable Windows 11 22H2 installs, so set it explicitly elsewhere.
• Passive mode leaves gaps: with Defender in passive mode behind another antivirus, real-time protection, ASR rules, network protection and indicators are unavailable. EDR in block mode adds remediation of behavioural detections; the primary product must cover the rest.

Exclusion governance

BlackByte ransomware added Microsoft Defender exclusions, and APT38 excluded C:\Windows\System32, according to ATT&CK procedure examples. Microsoft's own position is that "Creating an exclusion or an allow indicator creates a protection gap."

• Know what an exclusion turns off: on Windows and macOS, Defender custom exclusions apply to antivirus scanning only, so EDR still sees the file. On Linux, global exclusions mute both antivirus and EDR. A process exclusion on any platform also stops network protection inspecting that process.
• Know the evaluation order: antivirus exclusions are evaluated before block indicators, so a broad exclusion can override one.
• Prefer narrow forms: contextual exclusions (a path only when opened by a named process) rather than folder or extension exclusions, and never user-writable locations such as temp folders.
• Review on a schedule: every exclusion needs an owner, a ticket and an expiry date. ATT&CK mitigation M1049 recommends auditing exclusions and limiting their scope.

Reducing script, injection and memory evasion

ATT&CK says reflective code loading and parent PID spoofing "cannot be easily mitigated with preventive controls". The effective approach is to limit how untrusted code gets to run and to keep visibility that does not depend on user-mode hooks.

• Application control: App Control for Business or AppLocker in allowlist mode removes most opportunities to run an evasion tool at all. App Control also puts PowerShell into Constrained Language Mode for scripts that are not allowed (events 8028 audit, 8029 enforce).
• AMSI coverage: AMSI integrates with PowerShell, Windows Script Host, JavaScript, VBScript, Office VBA macros and UAC elevation. Remove PowerShell 2.0, which predates AMSI, and keep script block logging (event 4104) on and forwarded.
• ASR rules for common delivery chains: "Block Office applications from injecting code into other processes" (75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84), "Block execution of potentially obfuscated scripts" (5beb7efe-fd9a-4556-801d-275e5ffc04cc), "Block use of copied or impersonated system tools" (c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb) and "Block credential stealing from the Windows local security authority subsystem" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2).
• DLL side-loading: App Control DLL rules and Safe DLL Search Mode (ATT&CK M1044) limit side-loading; hunt for signed executables running from user-writable folders next to unsigned DLLs.
• Detect outcomes, not methods: attackers who evade hooks still need to read credentials, move laterally and encrypt or exfiltrate data, and detections built on those outcomes survive the loss of any single sensor.

Choosing the right control mix

Small organisations: confirm the driver blocklist and memory integrity are on, enable tamper protection centrally, deploy the three ASR rules Microsoft groups as standard protection (vulnerable signed drivers, LSASS credential stealing, WMI persistence) and remove local administrator rights. Large organisations: add App Control allowlisting by tier, a second telemetry path, exclusion expiry and lab testing of EDR resilience against the techniques above.

Implementation: a phased rollout

1. Baseline. Inventory agents, versions and devices where EDR is missing, passive or unhealthy; export every exclusion with its owner; query HVCI and LSA protection state.
2. Audit mode. Deploy the ASR rules in audit mode (event 1122) and the vulnerable driver App Control policy in audit form (event 3076). Microsoft warns that blocking kernel drivers without testing "can cause devices or software to malfunction, and in rare cases, blue screen".
3. Pilot ring. Enforce on IT staff devices, then a representative business ring, for at least one patch cycle, tracking blocks (1121, 3077) and tickets per rule.
4. Enable tamper protection and remove local changes. Turn on tamper protection tenant-wide, remove locally defined exclusions and move every exception into central policy.
5. Enforce broadly. Move rules to block mode by ring. Enable memory integrity on capable hardware, starting with new builds.
6. Harden tier 0. Apply driver allowlisting and full application control to domain controllers, identity servers, backup and hypervisor management systems.
7. Rollback plan. Per-rule ASR exclusions or a switch back to audit mode for a misbehaving rule; App Control policy removal plus reboot; for memory integrity boot failures, Microsoft's recovery is to disable the policy, boot to Windows RE and set the HypervisorEnforcedCodeIntegrity Enabled value to 0. With UEFI lock, Secure Boot must be disabled to recover, so test before locking.

Detection and measurement

Metrics that show the programme is working:

• Sensor health coverage: percentage of endpoints with an active, current, tamper-protected agent reporting in the last 24 hours (target 99 per cent).
• Kernel protection coverage: percentage of capable devices with memory integrity running and the vulnerable driver blocklist enforced.
• Exclusion hygiene: percentage of exclusions with an owner and expiry, and exclusions on user-writable paths (target zero).
• Silence-to-triage time: median time from an endpoint going silent to an analyst investigating it.
• Tamper attempts: count of 5013 and tamper alerts per month, each one triaged as a potential intrusion.
• Local administrator exposure: number of users with standing local administrator rights.

Where identity fits

Almost every technique here requires administrator or SYSTEM rights, or control of the management console, so the identities around EDR are part of its attack surface.

• Local administrator accounts: a shared local administrator password lets one compromised device become many. Windows LAPS rotates each device's local administrator password and backs it up to Microsoft Entra ID or Active Directory. See the Privileged Access Management Guide.
• EDR and device management consoles: whoever controls the console can disable policy everywhere without any evasion technique. In the Stryker attack, one hijacked administrator account was used to wipe devices through Microsoft Intune. Protect these roles with phishing-resistant MFA and just-in-time elevation. See the JIT Access Guide.
• Service accounts and API credentials: SIEM connectors and automation often hold EDR API keys that can change policy. Scope, vault and rotate them. See the Service Account Security Guide and the API Key Management Guide.

Common failure patterns

• Healthy dashboards hiding dead agents: devices show as onboarded but nobody alerts when they stop reporting.
• Blocklist assumed, not verified: upgraded devices, older servers and machines where memory integrity was switched off for driver compatibility never enforce the blocklist.
• Inherited exclusions: application folders, temp paths or script extensions excluded years ago, now a hiding place (T1564.012).
• Local administrators everywhere: standing administrator rights give malware the privileges BYOVD needs.
• Trusting signatures: allowing any signed driver or binary, despite stolen certificates such as those in the NVIDIA certificate theft, and ignoring revocation events (CodeIntegrity 3033, 3036).
• Single telemetry path: when the agent is killed there is no independent record; forward Sysmon and native logs to the SIEM.

Framework mapping

Practitioner checklist

• Alert on endpoints whose EDR agent stops reporting, crashes or loses tamper protection, and triage each one as a possible intrusion.
• Verify the vulnerable driver blocklist and memory integrity are enforced on every capable device, including upgraded ones.
• Deploy the ASR rule for vulnerable signed drivers, the Safe Mode reboot rule and the LSASS rule through audit, pilot and block rings.
• Manage tamper protection centrally and restrict troubleshooting mode.
• Export, justify, narrow and set expiry dates on every scanning exclusion; remove exclusions on user-writable paths.
• Apply App Control allowlisting, including drivers, to tier 0, backup and hypervisor management servers.
• Remove standing local administrator rights and deploy Windows LAPS.
• Protect EDR and device management console roles with phishing-resistant MFA and just-in-time access, and vault EDR API keys.

Standards and references

• MITRE ATT&CK: Defense Impairment (TA0112)
• MITRE ATT&CK: Disable or Modify Tools (T1685)
• MITRE ATT&CK: Exploitation for Privilege Escalation (T1068)
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: Enable memory integrity
• Microsoft Learn: Protect security settings with tamper protection
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Exclusions for Microsoft Defender for Endpoint and Microsoft Defender Antivirus

Related NHI Mgmt Group resources: Privileged Access Management Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide · ITDR Guide