Sophos — 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.

LSASS Loading Suspicious DLL

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component that manages security policies and user authentication. Attackers often target LSASS to dump credentials, using techniques like injecting malicious DLLs. This detection focuses on identifying instances where LSASS loads a DLL that is either unsigned or not signed by a trusted vendor. The rule excludes known legitimate signatures and file hashes to reduce false positives. This activity is a strong indicator of credential access attempts, potentially leading to further compromise of the system and network. The signatures identified in the rule contain well-known software vendors like Microsoft, McAfee and Citrix.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploiting a vulnerability).
The attacker elevates privileges to gain sufficient access to interact with the LSASS process.
The attacker drops a malicious DLL onto the system, often disguised as a legitimate file.
The attacker injects the malicious DLL into the LSASS process using techniques like Reflective DLL Injection.
LSASS loads the injected DLL, granting the attacker access to sensitive credentials stored in memory.
The malicious DLL dumps credentials, such as plaintext passwords or NTLM hashes.
The attacker uses the stolen credentials for lateral movement to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation leads to credential compromise, allowing attackers to move laterally within the network, access sensitive data, and potentially achieve complete domain dominance. This can result in data breaches, financial losses, and reputational damage. The impact depends on the level of access associated with the compromised credentials.

Recommendation

Deploy the LSASS Loading Untrusted DLL Sigma rule to your SIEM to detect suspicious DLLs loaded by LSASS.
Investigate any alerts generated by the Sigma rule and review the loaded DLL’s code signature and hash.
Block the identified SHA256 hashes listed in the IOC table to prevent the execution of known malicious DLLs.
Implement application whitelisting to restrict which DLLs can be loaded into LSASS.
Enable Sysmon process creation and image load logging to provide the necessary data for detection.