Back to posts

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.

7 min read

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:

  1. Local Components: Process monitoring, file system hooks, kernel callbacks
  2. Cloud Components: Behavioral analysis, threat intelligence, machine learning models
  3. 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:

c
1filter.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:

c
1BOOL 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:

c
1// 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:

c
1BOOL 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

CharacteristicEDRSilencer (Persistent)Dynamic Session Approach
Filter PersistenceSurvives rebootProcess lifetime only
Cleanup RequiredManual via commandsAutomatic on exit
Forensic ArtifactsWFP database entriesMinimal event logs
Network CoverageOutbound onlyBidirectional
Crash SafetyFilters remainAutomatic removal
Integration ComplexityStandalone toolLibrary-ready

4.2 Operational Advantages

The dynamic session approach provides several operational benefits:

  1. Reduced Forensic Footprint: No persistent WFP database modifications
  2. Operational Safety: Automatic cleanup prevents accidental persistent blocks
  3. Integration Flexibility: Suitable for inclusion in broader toolsets
  4. Complete Isolation: Bidirectional blocking ensures comprehensive communication prevention

4.3 Limitations

Several limitations should be noted:

  1. Privilege Requirements: Administrator privileges required for WFP operations
  2. Detection Surface: WFP operations generate Security event log entries
  3. Version Dependencies: Behavior may vary across Windows versions
  4. 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
powershell
1# 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:

cmd
1netsh 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

  1. Implement WFP Monitoring: Real-time alerting on filter modifications
  2. Redundant Communication: Multiple telemetry paths and protocols
  3. Local Caching: Store critical events locally with delayed transmission
  4. Process Protection: Utilize Windows protected process mechanisms

5.2.2 For EDR Vendors

  1. Architectural Resilience: Reduce dependency on real-time cloud connectivity
  2. Local Intelligence: Implement autonomous detection capabilities
  3. Communication Monitoring: Detect and alert on network isolation
  4. Alternative Channels: Implement fallback communication methods

6. Ethical Considerations

This research is provided to improve defensive security capabilities. Key ethical considerations include:

  1. Authorized Use Only: Techniques should only be employed in authorized security assessments
  2. Responsible Disclosure: Vendors should be notified of architectural vulnerabilities
  3. Defensive Focus: Research aims to improve security tool resilience
  4. 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:

  1. Technical Advancement: Demonstration of dynamic WFP sessions for security tool isolation
  2. Operational Improvements: Self-cleaning, crash-safe implementation
  3. Detection Guidance: Comprehensive strategies for identifying WFP abuse
  4. Architectural Insights: Highlighting critical dependencies in modern security tools

8. Future Work

Several areas warrant further investigation:

  1. Cross-Platform Analysis: Examining similar techniques on non-Windows platforms
  2. Kernel-Level Countermeasures: Developing driver-based detection mechanisms
  3. Alternative Communication Channels: Researching resilient telemetry methods
  4. 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


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.