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

Komari Agent Abused as SYSTEM-Level Backdoor

hello@craftedsignal.io — Thu, 30 Apr 2026 00:00:00 +0000

Huntress discovered threat actors leveraging the Komari monitoring agent as a SYSTEM-level backdoor within a partner environment. Komari, a Go-based project on GitHub with over 4,000 stars, is designed as a remote-control and monitoring tool. This incident marks a publicly documented case of Komari being abused in a real-world intrusion. The attackers compromised VPN credentials to gain initial access before deploying the Komari agent as a persistent backdoor. Komari inherently functions as a command-and-control (C2) channel, with features enabled by default. The threat actor installed Komari as a Windows service named “Windows Update Service” using NSSM, directly from the official GitHub repository, which avoided the need for attacker-controlled staging infrastructure. The initial discovery occurred on April 16, 2026.

Attack Chain

Initial Access: The attacker establishes an SSLVPN session on a FortiGate device from IP address 45.153.34[.]132, authenticating as a legitimate user, [User 1].
Internal Reconnaissance: After establishing the VPN connection, the attacker’s workstation, identified as VM8514, begins enumerating the internal network from the tunnel IP 10.212.134[.]200.
Lateral Movement: Using Impacket’s smbexec.py, the attacker enables Remote Desktop Protocol (RDP) on the target workstation, [REDACTED-WRKSTN].
RDP Access: The attacker establishes an interactive RDP session to [REDACTED-WRKSTN].
Persistence - Service Creation: The attacker uses the Non-Sucking Service Manager (NSSM) to install the Komari agent as a persistent Windows service named “Windows Update Service”.
Agent Download: The Komari agent is downloaded from raw.githubusercontent[.]com/komari-monitor/komari-agent using a PowerShell one-liner executed directly on the system.
Command and Control: The Komari agent establishes a persistent WebSocket connection to its server, allowing the attacker to execute arbitrary commands (PowerShell/sh) and initiate interactive PTY reverse shell sessions.
Maintain Access & Execute: The attacker maintains SYSTEM-level access via the persistent Komari agent, enabling ongoing remote command execution and control over the compromised workstation.

Impact

This attack demonstrates how readily available monitoring tools can be weaponized for malicious purposes. A single compromised account led to the establishment of a SYSTEM-level backdoor on a critical workstation. This could result in data exfiltration, further lateral movement within the network, and potentially ransomware deployment. Microsoft Defender quarantined an earlier registry hive dumping attempt, preventing further data compromise. The number of affected organizations is currently unknown, but any organization using the Komari agent without proper security controls is potentially at risk.

Recommendation

Monitor FortiGate logs for SSLVPN sessions originating from suspicious IP addresses (45.153.34[.]132) and unusual ASN’s (ASN 51396) to detect potentially compromised credentials.
Implement the Sigma rule “Detect Komari Agent Installation via PowerShell” to identify installations of the Komari agent.
Monitor process creation events for the execution of nssm.exe installing a service named “Windows Update Service” to detect suspicious service installations.
Block the domain raw.githubusercontent[.]com at the DNS resolver or web proxy to prevent the downloading of malicious tools and payloads.

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.