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

Persistence via Windows Installer (Msiexec)

hello@craftedsignal.io — Thu, 05 Sep 2024 14:17:05 +0000

The Windows Installer (msiexec.exe) is a legitimate system tool used for installing, updating, and removing software on Windows systems. Adversaries can abuse msiexec.exe to establish persistence mechanisms by creating malicious scheduled tasks or modifying registry run keys. This allows them to execute arbitrary code during system startup or user logon. This technique is attractive to attackers due to msiexec.exe being a trusted Windows binary, potentially evading detection by security solutions that focus on flagging unknown or suspicious processes. The use of msiexec.exe for persistence can be difficult to detect without specific monitoring rules, as it is a common and legitimate system process. This activity can be observed across various Windows versions and is frequently integrated into automated attack frameworks and scripts.

Attack Chain

An attacker gains initial access to a compromised system, potentially through phishing, exploitation of a vulnerability, or stolen credentials.
The attacker leverages msiexec.exe to create a new scheduled task using the schtasks.exe command, setting it to execute a malicious script or binary.
Alternatively, the attacker uses msiexec.exe in conjunction with reg.exe or PowerShell to modify registry keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run or HKCU\Software\Microsoft\Windows\CurrentVersion\Run, adding a pointer to their malicious executable.
The created scheduled task or registry entry points to a malicious payload, such as a reverse shell or a downloader.
The system is restarted, or the user logs on, triggering the execution of the newly created scheduled task or the malicious binary through the modified registry run key.
The malicious payload executes, establishing a persistent foothold for the attacker on the compromised system.
The attacker can now perform further actions, such as data exfiltration, lateral movement, or deployment of ransomware.

Impact

Successful exploitation allows the adversary to maintain persistent access to the compromised system. This can lead to data theft, system compromise, deployment of ransomware, or use of the system as a staging point for further attacks within the network. A single compromised system can be used to pivot and compromise additional systems, leading to a widespread security breach. The impact can include financial losses, reputational damage, and disruption of business operations.

Recommendation

Monitor process creation events for msiexec.exe spawning schtasks.exe or reg.exe to create scheduled tasks or modify registry run keys (reference: rules in this brief).
Implement and tune the Sigma rules provided in this brief to detect suspicious msiexec.exe activity related to persistence mechanisms.
Review and audit existing scheduled tasks and registry run keys for any suspicious entries or anomalies.
Enable file integrity monitoring (FIM) on critical system directories, including the Windows Task Scheduler directory and registry run key locations (reference: event.category == “file” and file.path … and event.category == “registry” and registry.path … in the rule query).
Implement application control policies to restrict the execution of unauthorized or unknown executables (reference: rule query).

Detecting Remote Windows Service Installation for Lateral Movement

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

This detection rule identifies a potential lateral movement technique where an attacker establishes a network logon to a Windows system and subsequently installs a service using the same LogonId. This behavior is flagged as suspicious because it deviates from typical administrative practices and can indicate unauthorized access and persistence within the network. The rule is designed to filter out common legitimate services and administrative activities, focusing on anomalies that could signify malicious intent. This detection is crucial for defenders as it can uncover attackers attempting to move laterally and establish persistent access.

Attack Chain

An attacker gains initial access to a network via compromised credentials or exploiting a vulnerability.
The attacker performs network reconnaissance to identify target systems for lateral movement.
Using valid credentials or pass-the-hash techniques, the attacker authenticates to a remote Windows host over the network (e.g., SMB).
The attacker attempts to install a new service on the remote host, potentially using tools like sc.exe or PowerShell.
The service installation event is logged with a specific LogonId that matches the earlier network logon event, indicating a relationship between the two activities.
The newly installed service is configured to execute a malicious payload or establish a reverse shell.
The attacker uses the service to execute commands or deploy further malicious tools on the compromised host.
The attacker achieves persistence and lateral movement within the network, enabling further compromise and data exfiltration.

Impact

A successful attack using this technique can lead to widespread compromise of systems within a network. Attackers can use the newly installed service to execute arbitrary code, install malware, or move laterally to other systems. This can result in data theft, system disruption, or ransomware deployment. The impact can be significant, potentially affecting numerous systems and causing substantial financial and reputational damage.

Recommendation

Enable Windows Security Event Logs with necessary auditing policies, specifically Audit Logon and Audit Security System Extension, to capture relevant logon and service installation events.
Deploy the provided Sigma rules to your SIEM to detect suspicious remote service installations based on matching LogonIds from network logons.
Investigate any alerts generated by the Sigma rules, focusing on unusual service file paths and user accounts.
Review the list of excluded service file paths in the Sigma rules and customize them based on your environment’s known legitimate services.
Monitor network connections for suspicious SMB activity, particularly connections originating from unusual or untrusted sources.
Implement multi-factor authentication (MFA) to reduce the risk of credential theft and unauthorized network access.

Remote Execution of Windows Services via RPC

hello@craftedsignal.io — Tue, 02 Jan 2024 10:00:00 +0000

This detection rule identifies the remote execution of Windows services over Remote Procedure Call (RPC), a technique often employed for lateral movement within a network. The rule focuses on correlating network connections initiated by services.exe with subsequent child process creation events. While this activity can be a legitimate function of administrators using remote management tools, it also represents a potential attack vector. The rule aims to strike a balance between detecting malicious activity and minimizing false positives arising from routine administrative tasks. The detection logic is based on identifying network connections to services.exe followed by the creation of child processes that are not commonly associated with legitimate service management. The rule requires the use of Elastic Defend or Sysmon for adequate logging coverage.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker attempts to move laterally to other systems.
The attacker establishes a connection to the target system’s services.exe process over RPC using a high port (>= 49152).
The attacker uses the established RPC connection to create or start a new service on the remote system.
The services.exe process on the remote system spawns a child process related to the newly created or started service.
This new process executes the attacker’s payload, potentially granting further access or executing malicious commands.
The attacker leverages the newly executed service for persistent access or further lateral movement.

Impact

A successful attack could result in unauthorized access to sensitive data, disruption of critical services, or the deployment of ransomware. Lateral movement allows attackers to compromise multiple systems within the network, escalating the impact of the initial breach. Due to the nature of the technique, it can be challenging to distinguish between legitimate administrative activity and malicious actions, leading to delayed detection and increased dwell time for attackers.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune the filters for known-good executables in your environment to reduce false positives.
Enable Sysmon process-creation (Event ID 1) and network connection (Event ID 3) logging to ensure the required data for the Sigma rules is available.
Investigate any alerts triggered by these rules, focusing on the parent process and network connection details associated with the spawned child process.
Consider excluding known remote management tools from triggering the detection by adding exceptions based on process.executable or process.args in the Sigma rules.
Monitor the network for unusual RPC activity, especially connections to services.exe from unexpected source IPs.