Silent But Deadly
This blog post explores how Windows Filtering Platform's dynamic session capabilities can be leveraged to temporarily isolate EDR solutions from their cloud infrastructure, building upon @netero_1010's EDRSilencer research to create a self-cleaning, bidirectional network blocking technique.
Abstract
This research presents an evolution of Windows Filtering Platform (WFP) based Endpoint Detection and Response (EDR) evasion techniques, building upon the foundational work of EDRSilencer (Netero, 2023). By leveraging WFP's dynamic session capabilities with the FWPM_SESSION_FLAG_DYNAMIC flag, we demonstrate a method for creating temporary, self-cleaning network isolation of security software. This approach addresses operational security concerns present in persistent filtering methods while providing bidirectional network blocking. We analyze the technical implementation, compare methodologies, and provide comprehensive detection strategies for security teams.
1. Introduction
Modern Endpoint Detection and Response (EDR) solutions have evolved from signature-based detection to cloud-powered behavioral analysis engines. This architectural shift has created a critical dependency on network connectivity for core functionality including telemetry transmission, threat intelligence updates, and real-time analysis.
In 2023, security researcher @netero_1010 introduced EDRSilencer¹, demonstrating the viability of using Windows Filtering Platform to disrupt EDR network communications. This research exposed a fundamental architectural vulnerability: the reliance on network connectivity for security effectiveness.
This blog presents an advancement of this concept, utilizing WFP's dynamic session capabilities to create ephemeral network filters that provide operational advantages over persistent filtering approaches.
2. Background
2.1 Windows Filtering Platform Architecture
Windows Filtering Platform (WFP) is a set of APIs and system services that provide a platform for creating network filtering applications². WFP operates at multiple layers of the network stack, enabling deep packet inspection and filtering capabilities. Key components include:
- Filter Engine: Core component managing all filtering operations
- Base Filtering Engine (BFE): Windows service hosting the filter engine
- Layers: Network stack locations where filtering occurs
- Filters: Rules determining allow/block decisions
- Providers: Entities that own filters
2.2 EDR Communication Architecture
Contemporary EDR solutions typically employ a hybrid architecture:
- Local Components: Process monitoring, file system hooks, kernel callbacks
- Cloud Components: Behavioral analysis, threat intelligence, machine learning models
- Communication Layer: TLS-encrypted channels for telemetry and updates
This architecture creates a critical dependency on network connectivity for:
- Real-time telemetry transmission
- Threat intelligence updates
- Alert generation and escalation
- Policy updates and enforcement
2.3 Prior Work: EDRSilencer
The EDRSilencer tool demonstrated that WFP could effectively block EDR communications using persistent filters:
c1filter.flags = FWPM_FILTER_FLAG_PERSISTENT; 2filter.layerKey = FWPM_LAYER_ALE_AUTH_CONNECT_V4; 3filter.action.type = FWP_ACTION_BLOCK;
While effective, this approach presented several limitations:
- Persistent filters requiring manual removal
- Forensic artifacts in WFP database
- Outbound-only blocking
- No automatic cleanup mechanism
3. Methodology
3.1 Dynamic Session Implementation
Our approach leverages the FWPM_SESSION_FLAG_DYNAMIC flag to create ephemeral filtering sessions:
c1BOOL InitializeWFP() { 2 DWORD status = ERROR_SUCCESS; 3 4 // Initialize COM for GUID generation 5 if (FAILED(CoInitializeEx(NULL, COINIT_MULTITHREADED))) { 6 LogMessage("[-] Failed to initialize COM\n"); 7 return FALSE; 8 } 9 10 // Generate unique identifiers for WFP objects 11 if (FAILED(CoCreateGuid(&g_ProviderGuid))) { 12 LogMessage("[-] Failed to create provider GUID\n"); 13 CoUninitialize(); 14 return FALSE; 15 } 16 17 if (FAILED(CoCreateGuid(&g_SublayerGuid))) { 18 LogMessage("[-] Failed to create sublayer GUID\n"); 19 CoUninitialize(); 20 return FALSE; 21 } 22 23 // Configure dynamic session 24 FWPM_SESSION session = {0}; 25 session.flags = FWPM_SESSION_FLAG_DYNAMIC; 26 27 // Open WFP engine with dynamic session 28 status = FwpmEngineOpen( 29 NULL, // Local machine 30 RPC_C_AUTHN_WINNT, // Authentication service 31 NULL, // Auth info 32 &session, // Dynamic session configuration 33 &g_EngineHandle // Output handle 34 ); 35 36 if (status != ERROR_SUCCESS) { 37 LogMessage("[-] Failed to open WFP engine: 0x%x\n", status); 38 CoUninitialize(); 39 return FALSE; 40 } 41 42 return TRUE; 43}
3.2 Bidirectional Network Isolation
Complete network isolation requires filtering at multiple layers:
c1// Outbound connection blocking 2filter.layerKey = FWPM_LAYER_ALE_AUTH_CONNECT_V4; 3 4// Inbound connection blocking 5filter.layerKey = FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4;
This approach prevents both outbound telemetry and inbound command-and-control communications.
3.3 Process Identification and Filtering
Accurate process identification is critical for targeted filtering:
c1BOOL GetProcessImagePathW(DWORD pid, LPWSTR pBuffer, DWORD cchBuffer) { 2 HANDLE hProc = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, FALSE, pid); 3 if (!hProc) { 4 return FALSE; 5 } 6 7 BOOL ok = QueryFullProcessImageNameW(hProc, 0, pBuffer, &cchBuffer); 8 CloseHandle(hProc); 9 return ok; 10}
The complete filtering implementation converts process paths to WFP application identifiers and creates appropriate filter conditions.
4. Results and Analysis
4.1 Comparative Analysis
| Characteristic | EDRSilencer (Persistent) | Dynamic Session Approach |
|---|---|---|
| Filter Persistence | Survives reboot | Process lifetime only |
| Cleanup Required | Manual via commands | Automatic on exit |
| Forensic Artifacts | WFP database entries | Minimal event logs |
| Network Coverage | Outbound only | Bidirectional |
| Crash Safety | Filters remain | Automatic removal |
| Integration Complexity | Standalone tool | Library-ready |
4.2 Operational Advantages
The dynamic session approach provides several operational benefits:
- Reduced Forensic Footprint: No persistent WFP database modifications
- Operational Safety: Automatic cleanup prevents accidental persistent blocks
- Integration Flexibility: Suitable for inclusion in broader toolsets
- Complete Isolation: Bidirectional blocking ensures comprehensive communication prevention
4.3 Limitations
Several limitations should be noted:
- Privilege Requirements: Administrator privileges required for WFP operations
- Detection Surface: WFP operations generate Security event log entries
- Version Dependencies: Behavior may vary across Windows versions
- Local Protection: Does not affect local detection capabilities
5. Detection and Mitigation
5.1 Detection Strategies
Security teams should implement multi-layered detection:
5.1.1 Event Log Monitoring
Monitor for Windows Filtering Platform events:
- Event ID 5441: Filter change events
- Event ID 5157: Connection blocked by WFP
- Event ID 5152: Packet dropped by WFP
powershell1# Detection query for dynamic WFP sessions 2Get-WinEvent -FilterHashtable @{LogName='Security';ID=5441} | 3 Where-Object {$_.Message -match "Dynamic"} | 4 Where-Object {$_.Message -match "Block"}
5.1.2 WFP State Monitoring
Regular enumeration of active filters:
cmd1netsh wfp show filters 2netsh wfp show providers
5.1.3 Behavioral Correlation
Correlate multiple indicators:
- WFP filter creation by unexpected processes
- Temporal correlation with security software failures
- Network timeout patterns from EDR processes
5.2 Mitigation Recommendations
5.2.1 For Security Teams
- Implement WFP Monitoring: Real-time alerting on filter modifications
- Redundant Communication: Multiple telemetry paths and protocols
- Local Caching: Store critical events locally with delayed transmission
- Process Protection: Utilize Windows protected process mechanisms
5.2.2 For EDR Vendors
- Architectural Resilience: Reduce dependency on real-time cloud connectivity
- Local Intelligence: Implement autonomous detection capabilities
- Communication Monitoring: Detect and alert on network isolation
- Alternative Channels: Implement fallback communication methods
6. Ethical Considerations
This research is provided to improve defensive security capabilities. Key ethical considerations include:
- Authorized Use Only: Techniques should only be employed in authorized security assessments
- Responsible Disclosure: Vendors should be notified of architectural vulnerabilities
- Defensive Focus: Research aims to improve security tool resilience
- Knowledge Sharing: Open discussion enables better defenses
7. Conclusion
The evolution from persistent WFP filtering to dynamic session-based isolation represents a refinement in technique that addresses operational security concerns while maintaining effectiveness. This research demonstrates that architectural dependencies on network connectivity remain a significant consideration for EDR effectiveness.
Key contributions of this research include:
- Technical Advancement: Demonstration of dynamic WFP sessions for security tool isolation
- Operational Improvements: Self-cleaning, crash-safe implementation
- Detection Guidance: Comprehensive strategies for identifying WFP abuse
- Architectural Insights: Highlighting critical dependencies in modern security tools
8. Future Work
Several areas warrant further investigation:
- Cross-Platform Analysis: Examining similar techniques on non-Windows platforms
- Kernel-Level Countermeasures: Developing driver-based detection mechanisms
- Alternative Communication Channels: Researching resilient telemetry methods
- Automated Detection: Machine learning approaches for WFP anomaly detection
Acknowledgments
We acknowledge @netero_1010 for the foundational EDRSilencer research that pioneered WFP-based EDR evasion techniques. This work builds upon that foundation to explore operational improvements and detection strategies.
References
- Windows Filtering Platform Documentation
- EDRSilencer Original Research
- WFP API Reference
- MITRE ATT&CK | Impair Defenses: Disable or Modify Tools
Disclaimer: This research is provided for educational purposes to advance defensive security capabilities. Readers are responsible for ensuring they have proper authorization before implementing these techniques in any environment. The authors assume no liability for misuse of this information.