Symantec — CraftedSignal Threat Feed

Potential Evasion via Windows Filtering Platform Blocking Security Software

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The Windows Filtering Platform (WFP) provides APIs and system services for network filtering and packet processing. Attackers can abuse WFP by creating malicious rules to block endpoint security processes, hindering their ability to send telemetry. This can be achieved by tools like Shutter, EDRSilencer, and Nighthawk. This detection rule identifies patterns of blocked network events linked to security software processes, signaling potential evasion tactics. The rule specifically looks for blocked network events linked to processes associated with known security software, aiming to detect and alert on attempts to disable or modify security tools. This behavior is especially concerning as it allows attackers to operate with reduced visibility.

Attack Chain

Attacker gains initial access to the target system (e.g., via compromised credentials or exploiting a vulnerability).
The attacker escalates privileges to gain administrative rights, necessary to interact with the Windows Filtering Platform.
The attacker uses a tool or script (e.g., leveraging the netsh command or custom WFP API calls) to create a new WFP filter.
The WFP filter is configured to block network traffic originating from specific processes associated with endpoint security software (e.g., elastic-agent.exe, sysmon.exe).
The system begins blocking network communication from the targeted security software.
The attacker executes malicious commands or malware on the system, knowing that security telemetry will be suppressed.
The attacker moves laterally within the network, repeating the WFP filter deployment on other systems to further impair defenses.
The attacker achieves their final objective, such as data exfiltration or ransomware deployment, with reduced risk of detection.

Impact

A successful attack using WFP to impair defenses can lead to a significant reduction in the effectiveness of endpoint security solutions. This can result in delayed detection of malicious activities, increased dwell time for attackers, and ultimately, a higher likelihood of successful data breaches or ransomware attacks. With endpoint telemetry blocked, organizations may remain unaware of the ongoing compromise until significant damage has occurred. The number of affected systems can vary depending on the attacker’s scope and objectives.

Recommendation

Enable and review Windows Audit Filtering Platform Connection and Packet Drop events to populate the logs required for the provided EQL rule (logs-system.security*, logs-windows.forwarded*, winlogbeat-*).
Deploy the provided EQL rule to your SIEM to detect suspicious WFP modifications and tune for your environment.
Investigate any alerts generated by the EQL rule, focusing on identifying the specific processes being blocked and the source of the WFP rule modifications.
Regularly review and audit WFP rules to identify any unauthorized or suspicious entries.
Implement strict access controls and monitoring for systems authorized to modify WFP rules.

Suspicious Registry Hive Access via RegBack

hello@craftedsignal.io — Tue, 02 Jul 2024 12:00:00 +0000

This detection identifies suspicious attempts to access registry backup hives (SAM, SECURITY, and SYSTEM) located in the RegBack folder on Windows systems. These hives contain sensitive credential material, making them attractive targets for attackers seeking to compromise system security. The detection logic focuses on file access events, specifically successful file opens, while excluding known benign processes such as taskhostw.exe and various AV/EDR solutions (SophosScanCoordinator.exe, MsSense.exe, ccSvcHst.exe, etc.) to minimize false positives. The rule is designed to provide defenders with high-fidelity alerts when unauthorized access to these critical registry hives is detected. The scope includes any Windows system where endpoint file access logging is enabled.

Attack Chain

An attacker gains initial access to the system through various means.
The attacker attempts to access the SAM, SECURITY, or SYSTEM registry hives located in the C:\\Windows\\System32\\config\\RegBack\\ directory.
The attacker leverages a tool or script to open one or more of these registry hives. This could involve using built-in Windows utilities, scripting languages, or custom-developed tools.
If the attacker successfully opens the SAM and SYSTEM hives, they can extract user account credentials, including usernames, password hashes, and other sensitive information. The SECURITY hive is also useful.
The attacker may stage the registry hive files by copying them to a different location on the system for further analysis or exfiltration.
The attacker uses credential dumping tools (e.g., Mimikatz, secretsdump.py) or custom scripts to extract credentials from the staged registry hives.
The attacker leverages the extracted credentials to escalate privileges, move laterally within the network, or access sensitive data.
The final objective is typically to gain unauthorized access to critical systems, steal sensitive data, or establish long-term persistence within the compromised environment.

Impact

Successful exploitation of this technique can lead to the compromise of user account credentials, enabling attackers to escalate privileges, move laterally within the network, and gain unauthorized access to sensitive data. The impact can range from data breaches and financial losses to reputational damage and disruption of critical business operations. The number of victims can vary depending on the scope of the attacker’s activities and the security posture of the targeted organization. Sectors commonly targeted include finance, healthcare, government, and critical infrastructure.

Recommendation

Enable file access monitoring for the C:\\Windows\\System32\\config\\RegBack\\ directory to capture file open events.
Deploy the Sigma rule Registry Hive Access via RegBack to your SIEM and tune the exclusions based on your environment.
Monitor process_creation events for unusual processes accessing files in C:\\Windows\\System32\\config\\RegBack\\, using the rule Suspicious Process Accessing RegBack Hives.
Enable Sysmon process creation logging and file creation to activate the rules above.

Suspicious Process Access via Direct System Call

hello@craftedsignal.io — Wed, 03 Jan 2024 15:00:00 +0000

This detection identifies suspicious process access events on Windows systems where a process attempts to access another process’s memory via direct system calls, bypassing standard Windows API calls. Endpoint security solutions often hook userland Windows APIs to detect malicious code execution. Attackers can evade these hooks by directly invoking syscalls, which are lower-level instructions that interact directly with the operating system kernel. The rule specifically looks for process access events (Sysmon Event ID 10) where the call trace does not originate from known Windows system DLLs like ntdll.dll, indicating a potential attempt to bypass security measures. The rule excludes certain legitimate applications, such as Malwarebytes Anti-Exploit, Cisco AMP, Microsoft EdgeWebView, and Adobe Acrobat DC, to reduce false positives. This technique is often employed by advanced malware and red teams to evade detection.

Attack Chain

A malicious process is executed on the system, either through user interaction or exploitation of a vulnerability.
The process attempts to gain access to another process’s memory space (Target Process).
Instead of using standard Windows API calls, the malicious process directly invokes system calls (syscalls) to access the target process’s memory.
The CallTrace in the Sysmon event does not originate from expected system DLLs like ntdll.dll, sysfer.dll, wow64cpu.dll, wow64win.dll, or win32u.dll, indicating a direct syscall.
The process might attempt to read sensitive information such as credentials, inject malicious code, or manipulate the target process’s behavior.
The malicious process performs actions within the context of the target process, such as executing injected code or accessing sensitive data.
The attacker leverages the compromised process to achieve their objectives, such as data exfiltration, lateral movement, or privilege escalation.
The attacker cleans up any traces of their activity and attempts to maintain persistence on the compromised system.

Impact

Successful exploitation can lead to the compromise of sensitive data, the injection of malicious code into legitimate processes, and the complete takeover of the affected system. This can result in data breaches, financial loss, and reputational damage. The impact is especially significant if the target process holds sensitive credentials, browser secrets, or has security-product context.

Recommendation

Enable Sysmon process access logging (Event ID 10) with call tracing and ingest the logs into your SIEM to activate the rules above (https://ela.st/sysmon-event-10-setup).
Deploy the Sigma rules provided in this brief to your SIEM and tune them for your environment to detect direct syscall process access.
Investigate any alerts generated by these rules, focusing on the SourceImage, TargetImage, GrantedAccess, and CallTrace fields in the Sysmon event to determine the legitimacy of the process access attempt.
Prioritize investigation of alerts where the target process is lsass.exe or other security-sensitive processes.
Implement robust endpoint detection and response (EDR) solutions to detect and prevent malicious activity on endpoints.
Monitor for suspicious process creation events originating from the flagged processes.