https://feed.craftedsignal.io/vendors/kaspersky/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioMon, 04 May 2026 14:17:05 +0000https://feed.craftedsignal.io/briefs/2026-05-wfp-evasion/Mon, 04 May 2026 14:17:05 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-wfp-evasion/Adversaries may add malicious Windows Filtering Platform (WFP) rules to prevent endpoint security solutions from sending telemetry data, impairing defenses, which this rule detects by identifying multiple WFP block events where the process name is associated with endpoint security software.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

1. Attacker gains initial access to the target system (e.g., via compromised credentials or exploiting a vulnerability).
2. The attacker escalates privileges to gain administrative rights, necessary to interact with the Windows Filtering Platform.
3. The attacker uses a tool or script (e.g., leveraging the netsh command or custom WFP API calls) to create a new WFP filter.
4. 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).
5. The system begins blocking network communication from the targeted security software.
6. The attacker executes malicious commands or malware on the system, knowing that security telemetry will be suppressed.
7. The attacker moves laterally within the network, repeating the WFP filter deployment on other systems to further impair defenses.
8. 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.

]]>mediumadvisorydefense-evasionwindows-filtering-platformendpoint-securityhttps://feed.craftedsignal.io/briefs/2024-01-09-app-compat-shim-persistence/Tue, 09 Jan 2024 10:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-09-app-compat-shim-persistence/Attackers abuse the Application Compatibility Shim functionality in Windows to establish persistence and achieve arbitrary code execution by installing malicious shim databases, which this detection identifies through monitoring registry changes.Attackers can exploit the Windows Application Compatibility Shim functionality to maintain persistence and execute arbitrary code within legitimate Windows processes. This is achieved by installing custom shim databases, which are designed to ensure older applications run smoothly on newer operating systems. By manipulating these databases, attackers can stealthily inject malicious code into trusted processes. The rule detects changes in specific registry paths associated with the installation of these databases, excluding known legitimate processes to minimize false positives. This technique allows for the execution of malicious code without directly modifying the target application’s executable, making it difficult to detect with traditional methods.

Attack Chain

1. The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
2. The attacker modifies the registry to create a new entry for a custom shim database. The registry path targeted is typically under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\.
3. The attacker writes a malicious .sdb file containing the custom shim database to a location on disk.
4. The registry entry created points to the malicious .sdb file.
5. When a targeted application is launched, Windows checks the AppCompatFlags registry keys.
6. The system loads the malicious shim database specified in the registry.
7. The malicious code within the shim database is executed in the context of the targeted application.
8. The attacker achieves persistence, as the malicious shim database is loaded every time the targeted application is run.

Impact

Successful exploitation allows attackers to maintain persistent access to the system, even after reboots or software updates. The injected code runs within the context of a legitimate process, which can evade detection by traditional security tools. This can lead to data theft, system compromise, or further malicious activities, such as lateral movement within the network. The use of application shimming for persistence affects systems running Windows and can impact organizations of any size or sector.

Recommendation

• Deploy the Sigma rule Detect Custom Shim Database Installation to your SIEM to identify suspicious registry modifications related to application shimming.
• Enable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function.
• Investigate any alerts generated by the Sigma rule, focusing on processes that are not in the exclusion list.
• Block or quarantine any identified malicious .sdb files to prevent further execution.
• Review and update the exclusion list in the Sigma rule with any newly identified legitimate applications that use shim databases, reducing false positives.

]]>mediumadvisorypersistenceapp-compatshimwindows