Elastic-Endpoint — 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.

Long Base64 Encoded Command via Scripting Interpreter

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

This rule identifies the execution of scripting interpreters (Python, PowerShell, Node.js, and Deno) with unusually long command lines containing base64 encoded payloads. The rule focuses on scenarios where the initial process.command_line field is ignored due to its excessive length, but the complete command line is still available in process.command_line.text. Attackers leverage this technique to evade traditional command-line inspection and execute malicious content across Windows, macOS, and Linux systems. This approach allows attackers to embed and execute code without writing it to disk, making it harder to detect. The rule is designed to detect this behavior, allowing for closer inspection of the executed commands and their intent.

Attack Chain

An attacker gains initial access to a system (e.g., via phishing or exploiting a vulnerability).
The attacker uses PowerShell, Python, Node.js, or Deno to execute commands.
A long, base64-encoded string is crafted, designed to evade detection.
The interpreter is invoked with the encoded string passed as an argument, exceeding typical command-line limits.
The process.command_line field is truncated due to its length, but the full command line is available in process.command_line.text.
The interpreter decodes and executes the payload from the process.command_line.text.
The decoded payload performs malicious actions such as downloading malware, establishing persistence, or exfiltrating data.
The attacker achieves their objective, such as gaining control of the system or stealing sensitive information.

Impact

Successful exploitation can lead to a wide range of malicious activities, including malware installation, data theft, privilege escalation, and system compromise. Due to the defense evasion capabilities, it is difficult to identify and prevent. The impact includes potential data breaches, financial losses, and reputational damage. The rule’s detection helps defenders identify this attack vector and prevent further exploitation of affected systems.

Recommendation

Deploy the Sigma rule Detect Long Base64 Encoded Command via Scripting Interpreter to your SIEM to detect this behavior.
Investigate any alerts generated by this rule, focusing on the process.command_line.text field to understand the full command being executed.
Review parent processes and execution chains of the interpreter to understand the initial attack vector.
Implement controls to restrict the execution of scripting interpreters from untrusted sources.
Monitor process execution logs for command lines exceeding a certain length threshold.
Improve logging coverage to capture the full command line even when it exceeds standard limits.

Suspicious DNS Queries to RMM Domains from Non-Browser Processes

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

This detection identifies DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains originating from processes that are not web browsers. This activity can indicate the use of legitimate RMM tools for malicious purposes, such as command and control, persistence, or lateral movement within a network. The detection aims to surface RMM clients, scripts, or other non-browser activities contacting these services without legitimate user interaction. Defenders should investigate processes making these queries to confirm expected behavior and validate the security posture of their managed assets. The rule is based on a list of known RMM domains and excludes common browser processes to reduce false positives.

Attack Chain

An attacker gains initial access to a Windows host through unspecified means.
The attacker deploys or leverages an existing RMM tool on the compromised host.
The RMM tool, running as a non-browser process, initiates a DNS query to resolve a command and control server associated with the RMM service (e.g., teamviewer.com).
The DNS query is made by a process other than a known web browser (chrome.exe, firefox.exe, etc.).
The compromised host establishes a connection to the resolved IP address associated with the RMM domain.
The attacker uses the RMM tool to execute commands, transfer files, or perform other malicious activities on the compromised host.
The attacker may use the RMM tool for lateral movement, pivoting to other systems within the network.
The attacker achieves their objective, which could include data exfiltration, ransomware deployment, or maintaining persistent access.

Impact

Compromise via abused RMM software can lead to full system compromise, data theft, or deployment of ransomware. While the number of affected victims is unknown, the sectors most likely to be impacted include any organization that relies on RMM tools for IT management. Successful exploitation allows attackers to bypass traditional security controls by using legitimate software, making detection more challenging.

Recommendation

Deploy the Sigma rule “DNS Queries to Known RMM Domains from Non-Browser Processes” to your SIEM and tune the RMM domain list for your environment.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the DNS query and its parent process.
Implement application control policies to restrict the execution of unauthorized RMM tools.
Enable Sysmon DNS event logging to ensure the necessary data is available for the detection rule.
Correlate with other alerts to identify potential compromises.
Review process.code_signature for trusted RMM publishers and investigate any unsigned or unexpected signers.