Michael Guhl, Threat Advisor 
Happy New Year and welcome back to another year of cybersecurity! We’re back for another round of cat-and-mouse. As the expression on Harold’s face suggests, the ‘new year’ often just means ‘new ways for things to break.
As we kick off the year, let’s focus on Defense in Depth, specifically how to protect your endpoints when your Endpoint Detection and Response (EDR) tool is knocked offline. Before we dive in, a word of caution: implementing these strategies may require policy updates and system changes that could impact your SIEM budget and tool performance. Ensure you collaborate with key stakeholders before adjusting Windows logging.
This guide provides a roadmap for detecting events when your primary security tools fail. (Rest assured, no kittens were harmed in the testing of these methods; this is for informational purposes only.)
The Future of Native Telemetry: Windows 11 & Server 2025
After 12 years, Microsoft has announced a significant update for Windows 11 and Windows Server 2025: native Sysmon-like functionality (Native Sysmon functionality coming to Windows). As detailed in Microsoft’s Secure Future Initiative (SFI), this native integration aligns with two key pillars:
- Secure by Design: Reducing complexity and eliminating gaps caused by manual deployments.
- Secure Operations: Making advanced security diagnostic data available out of the box.
For the Linux community, Microsoft also maintains a version for these events in their public GitHub repository.
The Threat: EDR Tampering and Silencing
Adversaries are increasingly moving away from simple evasion and toward infrastructure sabotage. Instead of hiding from an EDR, they seek to degrade its visibility entirely.
Techniques like Bind Link EDR tampering and EDRSilencer (which abuses the Windows Filtering Platform) demonstrate how legitimate Windows features can be weaponized to blind security tools. To counter this, organizations must adopt a telemetry-first, vendor-independent strategy using Sysmon, Windows Security logs, WMI auditing, and WFP logs.
While vendors might wink and promise 100% coverage, techniques like Bind Link tampering prove that ‘Full Visibility’ is often an aspiration, not a guarantee. If we rely solely on the agent, and that agent is targeted, we are effectively flying blind.
Defense in Depth: Why Logging Alone Is Not Enough
While robust telemetry collection is foundational, logging alone does not stop EDR bypasses, it only helps detect them. Attackers leveraging Bind Link manipulation or WFP abuse are often operating post privilege escalation, meaning prevention controls must be layered well before the detection fires. A defense in depth strategy ensures that even if one layer fails (for example, an EDR agent is silenced), other controls can still limit impact, generate alerts, or slow attacker progress.
One critical layer is endpoint hardening and privilege management. Bind Link tampering and WFP filter creation both require elevated privileges. Enforcing least privilege, using Just In Time (JIT) admin access, and monitoring abnormal administrative token usage can significantly reduce exposure. Security Event ID 4672 should not be a routine event on workstations; excessive or unexpected admin privilege grants should be investigated immediately, especially when followed by filesystem or network configuration changes.
Once an attacker gains elevated privileges, your endpoint becomes a standoff between malware, exploits, and your security tools. This is why we need layers—so that when the EDR gets silenced, it’s not the only thing standing between you and a ransomware event.
Application Control and Driver Abuse Prevention
Application control technologies such as Windows Defender Application Control (WDAC) add a powerful preventative layer. These controls can block execution of unauthorized binaries such as red team tools (EDRSilencer.exe, EDR Redir.exe) even when attackers obtain administrative privileges. WDAC policies can also restrict which binaries are allowed to interact with sensitive Windows APIs or load certain DLLs, reducing the attack surface for Bind Filter abuse.
In addition, organizations should monitor and restrict filesystem filter driver interactions. While BindFlt is a legitimate Windows driver, its use outside of known system processes is rare. Monitoring driver load behavior, unexpected DLL loads (such as bindfltapi.dll), and registry keys associated with filter drivers provides early warning signs of abuse. Combined with Sysmon Event ID 7 and kernel level logging, this approach helps surface activity that EDR products themselves may miss.
Network Level Resilience Against EDR Silencing
EDRSilencer highlights a blind spot in many environments over reliance on endpoint agents for network visibility. Defense in depth requires network telemetry that does not depend on the endpoint being cooperative. Network firewalls, secure web gateways, and NDR solutions should independently monitor outbound traffic from endpoints and alert when expected EDR telemetry abruptly stops.
Organizations should baseline expected EDR communication patterns (destination domains, IP ranges, ports, and frequency). Sudden drops in outbound connections from EDR agents especially when correlated with WFP filter creation events should trigger automated alerts. This ensures that even if an endpoint is successfully silenced, the SOC becomes aware through external observation rather than relying solely on the endpoint to report its own failure.
Operational Discipline: Continuous Validation
Finally, defense in depth requires continuous validation. Purple team exercises, adversary emulation, and red team testing should explicitly include EDR bypass scenarios, not just malware execution. Testing whether Bind Link abuse or WFP filtering would be detected and how quickly is critical to understanding your real world readiness.
As emphasized earlier, work closely with local system administrators before enabling advanced auditing. Sysmon, WMI, and WFP logs can significantly increase event volume, impacting SIEM ingestion costs and endpoint performance. Always validate changes in a test environment, define retention policies, and ensure your SOC is prepared to handle the additional telemetry without alert fatigue.
It doesn’t always take a sophisticated APT to burn down a security posture. A simple script using WFP abuse can leave your high-end EDR in ashes while the attacker watches from the sidelines.
EDR Bypass and other EDR evasion techniques:
- Typically require administrative privileges
- Abuse legitimate OS functionality
- Often occur after initial compromise
- Are invisible if defenders rely solely on the EDR agent being targeted
Detection Architecture:
A resilient detection strategy must assume the endpoint agent can be degraded and instead rely on host native telemetry that attackers cannot easily suppress without breaking the OS.
Core telemetry pillars:
| Category | Event IDs | Purpose |
| Windows Security | 4688, 4672, 4697 | Privilege use, process creation, and service installs. |
| WFP Auditing | 5156, 5157, 5447 | Network filter creation and connection blocking. |
| WMI Logs | 5857, 5858, 5861 | Discovery and orchestration activity. |
| Sysmon | 1, 3, 7, 11, 12, 13 | Deep visibility into processes, DLLs, and registry. |
| PowerShell | 4104, 4103 | Script block logging and de-obfuscated code execution. |
These logs must be forwarded for correlation to occur independently of endpoint health. Each one of these technologies and event IDs typically requires additional insight and might need alert design for use cases. Detection depends on understanding normal EDR communication and administrative behavior.
EDR bypass techniques highlight a shift from evasion to infrastructure sabotage. Organizations that instrument Windows deeply and correlate across process, file, registry, and network telemetry can detect these techniques even when EDR agents are impaired. Defense in depth is not optional; it is the only sustainable strategy.
For those thinking, ‘This is a nice story, but we don’t even have an EDR yet’—the advice remains the same: focus on the telemetry. Native Windows logging and Sysmon are your best friends whether you have a fancy vendor tool or not.
Conclusion: Moving Toward a Telemetry-First Posture
The shift from EDR evasion to EDR sabotage marks a new chapter in the cat-and-mouse game of cyber defense. As we have seen, the very features that make Windows flexible—like the Filtering Platform and Bind Links—can be turned into blindfolds for security teams.
To maintain visibility in this environment, your strategy must evolve from “tool-centric” to “telemetry-centric.” By implementing the layers discussed, you ensure that:
- Redundancy is your Safety Net: If the EDR is silenced, Sysmon still speaks. If Sysmon is tampered with, native Windows Security Logs remain.
- The Network Doesn’t Lie: By monitoring EDR health from the network level, you remove the attacker’s ability to hide their tracks simply by compromising the host.
- Hardening Prevents Evasion: Prevention (via WDAC and Least Privilege) remains the most effective way to ensure that the administrative privileges required for these bypasses are never granted in the first place.
The Road Ahead
As you implement these changes, remember that cybersecurity is a marathon, not a sprint. Start by baselining your normal administrative behavior and gradually increase your logging verbosity.
By taking these steps, you are doing more than just adding logs; you are building a resilient ecosystem where a “quiet” endpoint is, in itself, a loud and clear alarm for the SOC. No kittens were harmed, and with this defense-in-depth approach, your organization won’t be either.
Technical Reference: Critical Event IDs
Windows Security & WMI
| Event ID | Event Name | Short Description | MITRE TTP |
| 4688 | New Process Created | Logs every new process launched, including the command line (if enabled). | T1059 (Command and Scripting Interpreter) |
| 4672 | Special Privileges Assigned | Generated when an account logs on with administrative or sensitive privileges. | T1078 (Valid Accounts), T1134 (Access Token Manipulation) |
| 4697 | Service Installed | Records the creation of a new Windows service, a common persistence method. | T1543.003 (Create or Modify System Process: Windows Service) |
| 5156 | WFP Connection Allowed | The Windows Filtering Platform allowed a network connection. | T1041 (Exfiltration Over C2 Channel), T1011 (Exfiltration Over Other Network Medium) |
| 5157 | WFP Connection Blocked | The Windows Filtering Platform blocked a network connection. | T1041 (Exfiltration), T1571 (Non-Standard Port) |
| 5447 | WFP Filter Changed | A filter in the Windows Filtering Platform was added, deleted, or modified. | T1562.001 (Impair Defenses: Disable or Modify Tools) |
| Event ID | Event Name | Short Description | MITRE TTP |
| 5857 | WMI Operation Started | Logs the start of a WMI provider or activity (WMI Event Consumer Activity). | T1047 (Windows Management Instrumentation) |
| 5858 | WMI Client Failure | Captures WMI operation failures, which may indicate recon or misconfigured attacks. | T1047 (Windows Management Instrumentation) |
| 5861 | Permanent Event Subscription | Records the creation of a permanent WMI event subscription (binding). | T1546.003 (Event Triggered Execution: WMI Event Subscription) |
| 1 | Process Creation | Provides detailed process info, including hashes, parent process, and user context. | T1059 (Command and Scripting Interpreter), T1106 (Native API) |
| 3 | Network Connection | Records TCP/UDP connections with source/destination IPs and process details. | T1011, T1041, T1043 (Commonly Abused Protocols) |
| 7 | Image Loaded | Logs when a DLL or executable is loaded into a process. | T1574.002 (Hijack Execution Flow: DLL Side-Loading) |
| 11 | File Create | Records when a file is created or overwritten, useful for tracking dropped payloads. | T1105 (Ingress Tool Transfer), T1059 (Execution) |
| 12 | Registry Event (Create/Delete) | Logs the creation or deletion of registry keys and objects. | T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys) |
| 13 | Registry Event (Value Set) | Logs when a registry value is set or changed (e.g., modifying persistence keys). | T1547.001 (Registry Run Keys / Startup Folder) |
| 4104 | Script Block Logging | Records the actual code in PowerShell script blocks, including de-obfuscated content. | T1059.001 (Command and Scripting Interpreter: PowerShell) |
| 4103 | Module Logging | Logs the execution details of PowerShell modules and pipeline activities. | T1059.001 (Command and Scripting Interpreter: PowerShell) |
| Vendor / Product | Process Executables | Directory Path | Registry Keys to Monitor |
| Microsoft Defender | MsMpEng.exe, MsSense.exe, SenseIR.exe, SenseNdr.exe | C:\Program Files\Windows Defender\ C:\ProgramData\Microsoft\Windows Defender\ | HKLM\SOFTWARE\Microsoft\Windows Defender\ |
| SentinelOne | SentinelAgent.exe, SentinelServiceHost.exe | C:\Program Files\SentinelOne\ | HKLM\SOFTWARE\SentinelOne\ |
| Carbon Black Cloud | RepMgr.exe, RepUtils.exe, RepUx.exe, RepWAV.exe, RepWSC.exe | C:\Program Files\CarbonBlack\ | HKLM\SOFTWARE\CarbonBlack\ |
| Carbon Black EDR | cb.exe | C:\Program Files\CarbonBlack\ | HKLM\SOFTWARE\CarbonBlack\ |
| Cisco Secure Endpoint | sfc.exe | C:\Program Files\Cisco\ | HKLM\SOFTWARE\Cisco\ |
| Cybereason | AmSvc.exe, CrsSvc.exe | C:\Program Files\Cybereason\ | HKLM\SOFTWARE\Cybereason\ |
| Trellix (McAfee) | xagt.exe | C:\Program Files\McAfee\ | HKLM\SOFTWARE\McAfee\ |
| Trend Micro Apex One | CETASvc.exe, TmWSCSvc.exe, Ntrtscan.exe, PccNTMon.exe | C:\Program Files\Trend Micro\ | HKLM\SOFTWARE\TrendMicro\ |
| Generic/System | — | — | HKLM\SYSTEM\CurrentControlSet\Services\ HKLM\SYSTEM\CurrentControlSet\Services\BindFlt\ HKLM\SYSTEM\CurrentControlSet\Services\Wfp* |
Share