SentinelOne — CraftedSignal Threat Feed

Windows Port Forwarding Rule Addition via Registry Modification

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers may configure port forwarding rules to bypass network segmentation restrictions, effectively using the compromised host as a jump box to access previously unreachable systems. This involves modifying the registry to redirect incoming TCP connections from a local port to another port or a remote computer. The technique is typically employed post-compromise to facilitate lateral movement and maintain unauthorized access within the network. This activity is detected by monitoring changes to the HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\ registry subkeys.

Attack Chain

The attacker gains initial access to the target system through an exploit or compromised credentials.
The attacker executes a command-line interface (e.g., cmd.exe or powershell.exe) with administrative privileges.
The attacker uses reg.exe or PowerShell’s Set-ItemProperty cmdlet to modify the HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\ registry key.
The attacker configures a new port forwarding rule by creating a new subkey under v4tov4\ with specific settings for the local port, remote address, and remote port.
The attacker sets the ListenAddress, ListenPort, ConnectAddress, and ConnectPort values within the new subkey.
The attacker verifies the successful creation and activation of the port forwarding rule using netsh interface portproxy show v4tov4.
The attacker leverages the newly created port forwarding rule to tunnel traffic through the compromised host, bypassing network segmentation.
The attacker uses the proxied connection to access internal resources and conduct further attacks, such as lateral movement or data exfiltration.

Impact

Successful exploitation enables attackers to bypass network segmentation restrictions, leading to unauthorized access to internal systems and data. This can facilitate lateral movement, data exfiltration, and further compromise of the network. The severity of the impact depends on the sensitivity of the accessible resources and the extent of the attacker’s lateral movement.

Recommendation

Enable Sysmon registry event logging to capture modifications to the HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\ registry subkeys, enabling detection of malicious port forwarding rule additions.
Deploy the Sigma rule “Port Forwarding Rule Addition via Registry Modification” to your SIEM to detect suspicious registry modifications related to port forwarding.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process execution chain and the user account that performed the action.
Regularly review and audit existing port forwarding rules to identify and remove any unauthorized or suspicious configurations.

Suspicious Zoom Child Process Execution

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection identifies suspicious child processes spawned by Zoom.exe, potentially indicating an attempt to evade detection or exploit vulnerabilities within the Zoom application. The rule focuses on detecting instances where command interpreters like cmd.exe, PowerShell, or PowerShell ISE are launched as child processes of Zoom. This behavior can be indicative of an attacker attempting to execute malicious commands or scripts within the context of the Zoom application, potentially escalating privileges or gaining unauthorized access to system resources. It’s crucial for defenders to investigate such occurrences, as they may signify ongoing exploitation or malicious activity leveraging Zoom as an initial access vector.

Attack Chain

User launches the Zoom application (Zoom.exe).
A vulnerability in Zoom is exploited, or the user is socially engineered into running a malicious command.
Zoom.exe spawns a child process, such as cmd.exe, powershell.exe, pwsh.exe, or powershell_ise.exe.
The spawned process executes commands or scripts, potentially downloading or executing malware.
The malicious script or command performs reconnaissance activities on the system.
The script establishes persistence by creating a scheduled task or modifying registry keys.
The attacker gains remote access to the compromised system.
The attacker performs lateral movement and data exfiltration.

Impact

Successful exploitation could allow attackers to execute arbitrary commands, escalate privileges, and compromise the affected system. Depending on the user’s privileges, attackers could gain access to sensitive data, install malware, or pivot to other systems on the network. The impact ranges from data breaches to complete system compromise, potentially affecting all users within the organization who utilize the Zoom application.

Recommendation

Deploy the Sigma rule “Suspicious Zoom Child Process” to your SIEM to detect command interpreters spawned by Zoom.exe. Tune the rule for your environment to minimize false positives.
Enable Sysmon process creation logging (Event ID 1) to capture detailed information about process executions, which is essential for the Sigma rule above.
Investigate any alerts generated by the Sigma rule, focusing on the command-line arguments and network connections of the spawned processes.
Monitor Windows Security Event Logs for process creation events related to Zoom.exe and its child processes to identify suspicious behavior.
Consider implementing application control policies to restrict the execution of unauthorized processes within the Zoom application context.

Suspicious Windows PowerShell Arguments Detected

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection rule identifies the execution of PowerShell with suspicious argument values on Windows systems. This behavior is frequently associated with malware installation and other malicious activities. PowerShell is a powerful scripting language, and adversaries often exploit its capabilities to execute malicious scripts, download payloads, and obfuscate commands. The rule focuses on detecting patterns such as encoded commands, suspicious downloads (e.g., using WebClient or Invoke-WebRequest), and various obfuscation techniques used to evade detection. The rule is designed to work with various data sources, including Elastic Defend, Windows Security Event Logs, Sysmon, and third-party EDR solutions like CrowdStrike, Microsoft Defender XDR, and SentinelOne, enhancing its applicability across different environments.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker uses PowerShell to download a malicious payload from a remote server using commands like DownloadFile or DownloadString.
The downloaded payload is often encoded or obfuscated to evade detection. Common techniques include Base64 encoding, character manipulation, and compression.
PowerShell is then used to decode or deobfuscate the payload using methods like [Convert]::FromBase64String or [char[]](...) -join ''.
The deobfuscated payload is executed directly in memory using techniques like iex (Invoke-Expression) or Reflection.Assembly.Load.
The executed payload performs malicious actions, such as installing malware, establishing persistence, or exfiltrating data.
The attacker may use techniques like WebClient to download files from a remote URL.
Commands like nslookup -q=txt are used for command and control.

Impact

Successful exploitation can lead to malware installation, data theft, system compromise, and further propagation of the attack within the network. The detection of suspicious PowerShell arguments helps to identify and prevent these malicious activities before significant damage can occur. Without proper detection, attackers can maintain persistence, escalate privileges, and compromise sensitive data. The rule helps defenders identify and respond to these threats quickly, minimizing the impact of potential attacks.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious PowerShell activity.
Enable Sysmon process creation logging with command line arguments to ensure the necessary data is captured for the Sigma rules to function effectively.
Investigate any alerts generated by the Sigma rules to determine the legitimacy of the PowerShell activity and take appropriate remediation steps.
Continuously tune the Sigma rules based on your environment to reduce false positives and improve detection accuracy.

Suspicious Execution via Windows Command Debugging Utility

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. This can be achieved by running cdb.exe from non-standard installation paths and using specific command-line arguments to execute malicious commands. The LOLBAS project documents this technique, highlighting its potential for defense evasion. This activity has been observed across various environments, necessitating detection strategies that focus on identifying anomalous executions of cdb.exe.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker copies cdb.exe to a non-standard location (outside “Program Files” and “Program Files (x86)”).
The attacker executes cdb.exe with the -cf, -c, or -pd command-line arguments.
These arguments are used to specify a command file or execute a direct command.
The command file or command directly executes malicious code, such as shellcode.
The malicious code performs actions such as creating new processes, modifying files, or establishing network connections.
These actions allow the attacker to maintain persistence or escalate privileges.
The ultimate goal is to evade defenses and execute arbitrary code on the system.

Impact

Successful exploitation allows adversaries to execute arbitrary commands and shellcode on the affected system, potentially leading to complete system compromise. This can result in data theft, installation of malware, or further propagation within the network. The technique is effective at bypassing application whitelisting and other security controls that rely on standard execution paths.

Recommendation

Deploy the Sigma rule “Execution via Windows Command Debugging Utility” to your SIEM to detect suspicious cdb.exe executions (see rules section).
Enable process creation logging via Sysmon or Windows Security Event Logs to provide the necessary data for the Sigma rule.
Implement application whitelisting to prevent execution of cdb.exe from non-standard paths.
Monitor process command lines for the -cf, -c, and -pd flags when cdb.exe is executed.
Investigate any instances of cdb.exe running from unusual directories to determine legitimacy.

SIP Provider Modification for Defense Evasion

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection rule identifies modifications to Subject Interface Package (SIP) providers, a critical component of the Windows cryptographic system responsible for validating file signatures. Attackers may attempt to subvert trust controls by modifying SIP providers, allowing them to bypass signature validation checks and potentially inject malicious code into trusted processes. This activity is a form of defense evasion, allowing unauthorized code execution. The rule focuses on detecting suspicious registry changes associated with SIP providers, while excluding known benign processes to minimize false positives. The rule is designed for data generated by Elastic Defend, but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon. This activity is related to MITRE ATT&CK technique T1553.003 (SIP and Trust Provider Hijacking).

Attack Chain

The attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker escalates privileges to gain necessary permissions to modify the registry.
The attacker modifies the registry keys associated with SIP providers, specifically targeting CryptSIPDllPutSignedDataMsg and Trust\\FinalPolicy locations.
The attacker changes the Dll value within these registry keys to point to a malicious DLL.
The system, upon attempting to validate a file signature, loads the malicious DLL instead of the legitimate SIP provider.
The malicious DLL executes arbitrary code, potentially injecting it into other processes.
The attacker uses the injected code to further compromise the system or network.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or establishing persistence.

Impact

Successful modification of SIP providers allows attackers to bypass signature validation checks, leading to the execution of unsigned or malicious code. This can compromise the integrity of the system, leading to data breaches, system instability, or further propagation of malware within the network. The impact can range from individual workstation compromise to widespread organizational damage, depending on the scope of the attack.

Recommendation

Deploy the Sigma rule Detect SIP Provider Modification via Registry to your SIEM and tune it for your environment to detect suspicious registry modifications related to SIP providers.
Enable Sysmon registry event logging to collect the necessary data for the Sigma rules above.
Investigate any alerts generated by the rules, focusing on the process responsible for the registry change and the DLL being loaded, as described in the rule’s triage section.
Implement application control policies to restrict the execution of unsigned or untrusted code.
Monitor the registry paths listed in the Sigma rules for unexpected changes.

Service DACL Modification via sc.exe

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection identifies the modification of Discretionary Access Control Lists (DACLs) for Windows services using the sc.exe utility. Attackers can leverage this technique to deny access to a service, making it unmanageable or hiding it from system administrators and users. The detection rule focuses on identifying instances where sc.exe is used with the sdset argument, specifically targeting the denial of access for key user groups such as IU, SU, BA, SY, and WD. This activity is indicative of a defense evasion attempt aimed at hindering security tools or preventing remediation. The rule is designed for data generated by Elastic Defend, but also supports integrations with third-party data sources like CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel, offering broad coverage for detecting this malicious behavior across diverse environments.

Attack Chain

An attacker gains initial access to a system through various means (e.g., compromised credentials, phishing).
The attacker elevates privileges to gain necessary permissions to modify service configurations.
The attacker executes sc.exe with the sdset command to modify the DACL of a targeted service.
The sdset command arguments specify the new security descriptor, denying access to specific user groups (e.g., IU, SU, BA, SY, WD).
The service becomes inaccessible to the targeted user groups, potentially disrupting legitimate operations or security tools.
The attacker may repeat this process for multiple services to further impair system functionality or evade detection.
The attacker leverages the disabled or hidden services to maintain persistence or carry out other malicious activities.

Impact

Successful modification of service DACLs can lead to a denial-of-service condition for legitimate users and system administrators. This can impair the functionality of critical security tools, hinder incident response efforts, and provide attackers with a persistent foothold on the compromised system. The hiding of services can also prevent users from identifying and removing malicious services. While the number of victims is not specified in the source, organizations across various sectors are potentially vulnerable to this type of attack.

Recommendation

Deploy the Sigma rule Service DACL Modification via sc.exe to your SIEM to detect this specific behavior.
Enable Sysmon process creation logging to provide the necessary data for the Sigma rule to function effectively.
Investigate any instances where sc.exe is used with the sdset argument and access denial flags, focusing on the targeted user groups (IU, SU, BA, SY, WD).
Implement strict access controls and monitor for unauthorized attempts to modify service configurations.
Regularly audit service permissions to identify and remediate any unauthorized changes.
Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations.

Remote Desktop File Opened from Suspicious Path

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers are increasingly using malicious Remote Desktop Protocol (RDP) files to gain initial access to systems. These RDP files, often delivered via spearphishing attachments, contain connection settings that, when opened, can compromise a system. This technique allows adversaries to bypass traditional security measures by leveraging a legitimate tool (mstsc.exe) with a malicious configuration file. The observed activity involves opening RDP files from suspicious locations like Downloads, temporary folders (AppData\Local\Temp), and Outlook content cache (INetCache\Content.Outlook). This campaign has been observed as recently as October 2024, where Midnight Blizzard conducted large-scale spear-phishing using RDP files. Defenders should monitor for the execution of mstsc.exe with RDP files from untrusted locations.

Attack Chain

The attacker crafts a spearphishing email containing a malicious RDP file as an attachment.
The victim receives the email and, lured by social engineering, downloads the attached RDP file to a local directory, often the Downloads folder.
The victim double-clicks the RDP file, initiating the execution of mstsc.exe.
mstsc.exe reads the connection settings from the RDP file, which may include malicious configurations such as altered gateway settings or credential theft mechanisms.
mstsc.exe attempts to establish a remote desktop connection based on the RDP file’s settings.
If the connection is successful, the attacker gains unauthorized access to the remote system.
The attacker may then perform reconnaissance, move laterally, and escalate privileges within the compromised network.
The final objective could be data exfiltration, ransomware deployment, or establishing persistent access.

Impact

A successful attack using malicious RDP files can lead to unauthorized access to sensitive systems and data. The consequences range from data breaches and financial loss to complete system compromise and disruption of operations. The Microsoft Security blog reported a large-scale spear-phishing campaign utilizing RDP files as recently as October 2024. The targets may be across various sectors, with potentially widespread impact depending on the attacker’s objectives and the scope of the compromised network.

Recommendation

Deploy the Sigma rule Remote Desktop File Opened from Suspicious Path to your SIEM and tune for your environment, focusing on the specified file paths and mstsc.exe execution.
Enable process creation logging with command-line arguments to capture the execution of mstsc.exe and the paths of the RDP files being opened.
Educate users on the risks associated with opening RDP files from untrusted sources, particularly those received as email attachments.
Implement strict email filtering to block or quarantine emails with RDP attachments from external sources.
Monitor network connections for unusual RDP traffic originating from systems where suspicious RDP files were executed.

Potential Secure File Deletion via SDelete Utility

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The Sysinternals SDelete utility is a legitimate tool developed by Microsoft for securely deleting files by overwriting and renaming them multiple times. While intended for secure data disposal, adversaries can abuse SDelete to remove forensic artifacts, destroy evidence of their activities, and impede data recovery efforts after a successful ransomware attack or data theft. This activity can be used as a post-exploitation technique. This detection rule focuses on identifying file name patterns indicative of SDelete’s operation, specifically detecting files with names resembling “*AAA.AAA”. The rule is designed to work with various endpoint detection and response solutions, including Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and CrowdStrike.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker escalates privileges to gain the necessary permissions to delete files.
The attacker deploys or utilizes an existing copy of the SDelete utility.
The attacker executes SDelete against targeted files or directories.
SDelete overwrites the targeted file(s) multiple times with random data.
SDelete renames the file(s) multiple times, often with patterns such as “*AAA.AAA”.
SDelete deletes the file(s) making recovery difficult.
The attacker removes SDelete or any associated tools to further cover their tracks.

Impact

Successful exploitation of this technique can result in the permanent deletion of crucial forensic artifacts, log files, or even critical data. This can severely hinder incident response efforts, making it challenging to identify the scope of the attack, the attacker’s methods, and the compromised assets. The number of victims and affected sectors depends on the scale of the initial breach and the attacker’s objectives.

Recommendation

Deploy the “Potential Secure File Deletion via SDelete Utility” detection rule to your SIEM and tune for your environment.
Investigate any alerts generated by the detection rule, focusing on the process execution chain and identifying the user account involved.
Review the privileges assigned to the user account to ensure the least privilege principle is followed.
Enable Sysmon Event ID 11 (File Create) logging to enhance visibility into file creation events.

Potential NetNTLMv1 Downgrade Attack via Registry Modification

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This rule detects a specific defense evasion technique where an attacker modifies the Windows registry to force a system to use the less secure NTLMv1 authentication protocol. This is known as a NetNTLMv1 downgrade attack. The registry modification involves changing the LmCompatibilityLevel value, which controls the authentication level. Attackers with local administrator privileges can perform this modification to weaken the authentication mechanism, making it easier to intercept and crack credentials. The rule is designed to detect this activity by monitoring registry events from various sources, including Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Crowdstrike. It is important to monitor for this activity as it can lead to credential theft and further compromise of the system.

Attack Chain

The attacker gains local administrator privileges on a Windows system.
The attacker uses a registry editor or command-line tool (e.g., reg.exe, PowerShell) to modify the LmCompatibilityLevel value in the registry.
The attacker navigates to one of the following registry paths: HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel or HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
The attacker sets the LmCompatibilityLevel value to “0”, “1”, or “2” (or their hexadecimal equivalents “0x00000000”, “0x00000001”, “0x00000002”). These values force the system to use NTLMv1.
The system now uses NTLMv1 for authentication attempts.
The attacker initiates a man-in-the-middle attack to capture NTLMv1 authentication traffic using tools like Responder or Inveigh.
The captured NTLMv1 hashes are cracked using brute-force or dictionary attacks, revealing the user’s credentials.
The attacker uses the compromised credentials to gain unauthorized access to network resources or other systems.

Impact

A successful NetNTLMv1 downgrade attack can lead to the compromise of user credentials, enabling attackers to move laterally within the network, access sensitive data, and potentially escalate privileges. The impact can range from data breaches to complete system compromise, depending on the attacker’s objectives and the compromised user’s privileges.

Recommendation

Deploy the Sigma rule “Potential NetNTLMv1 Downgrade Attack” to detect registry modifications setting LmCompatibilityLevel to insecure values (0, 1, 2) within the specified registry paths.
Enable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function correctly.
Review registry event logs for unauthorized modifications of LmCompatibilityLevel to confirm legitimate administrative actions.
Implement strict access control policies to limit local administrator privileges and reduce the attack surface.
Monitor the references URL for updates on recommended security configurations related to NTLM authentication.

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.

Local Account TokenFilter Policy Modification for Defense Evasion and Lateral Movement

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled (set to 1), allows remote connections from local members of the Administrators group to be granted full high-integrity tokens during negotiation. This bypasses User Account Control (UAC) restrictions, allowing for elevated privileges remotely. Attackers may modify this registry setting to facilitate lateral movement within a network. This rule detects modifications to this specific registry setting, alerting on potential unauthorized changes that could lead to defense evasion and privilege escalation. The modification of this policy has been observed being leveraged in conjunction with pass-the-hash attacks.

Attack Chain

The attacker gains initial access to a system through an exploit, such as phishing or exploiting a vulnerability.
The attacker obtains local administrator credentials on the compromised system.
The attacker modifies the LocalAccountTokenFilterPolicy registry key to a value of 1. This is done to allow remote connections from local administrator accounts to receive high-integrity tokens. The registry key is typically located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
The attacker leverages a “pass the hash” attack (T1550.002) using the compromised local administrator credentials.
The attacker attempts to move laterally to other systems within the network using the “pass the hash” technique and the modified LocalAccountTokenFilterPolicy.
Due to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.
The attacker bypasses UAC on the remote system, gaining elevated privileges.
The attacker performs malicious activities on the remote system, such as data exfiltration or deploying ransomware.

Impact

Successful modification of the LocalAccountTokenFilterPolicy allows attackers to bypass User Account Control (UAC) and gain elevated privileges on remote systems, potentially leading to unauthorized access to sensitive data, lateral movement across the network, and the deployment of ransomware. The overall impact can include data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule Local Account TokenFilter Policy Enabled to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.
Enable Sysmon registry event logging to capture modifications to the registry, which is required for the Local Account TokenFilter Policy Enabled Sigma rule.
Review the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.
Monitor registry events for changes to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy path, specifically looking for changes to the value data.

Enumerating Domain Trusts via DSQUERY.EXE

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The dsquery.exe utility is a command-line tool in Windows used to query Active Directory. Attackers may leverage dsquery.exe to discover domain trust relationships within a Windows environment, mapping out potential lateral movement paths. This discovery is often an early stage in reconnaissance, before an attacker attempts to move laterally to other systems. This activity can be detected across various endpoint detection platforms including Elastic Defend, CrowdStrike, Microsoft Defender XDR, and SentinelOne. This activity is not inherently malicious, as administrators also use it for legitimate purposes.

Attack Chain

An attacker gains initial access to a compromised host within the target environment.
The attacker executes dsquery.exe with the argument objectClass=trustedDomain to enumerate domain trusts.
The command execution is logged by endpoint detection and response (EDR) solutions or Windows Security Event Logs.
The attacker parses the output of the dsquery.exe command to identify trusted domains and their attributes.
The attacker uses the discovered trust information to plan lateral movement strategies.
The attacker attempts to authenticate to other systems within the trusted domains using stolen credentials or other exploits.

Impact

Successful enumeration of domain trusts enables attackers to map out the Active Directory environment and identify potential pathways for lateral movement. While the enumeration itself is low impact, it facilitates subsequent actions like credential theft, privilege escalation, and data exfiltration. This can lead to widespread compromise across the organization, impacting numerous systems and sensitive data.

Recommendation

Deploy the Sigma rule “Detect Enumerating Domain Trusts via DSQUERY.EXE” to your SIEM and tune for your environment.
Investigate any execution of dsquery.exe with the argument objectClass=trustedDomain to identify potentially malicious activity.
Monitor process execution events for dsquery.exe to detect suspicious command-line arguments and execution patterns.

Command Shell Activity Started via RunDLL32

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers commonly abuse RunDLL32, a legitimate Windows utility, to execute malicious code by hosting it within DLLs. This technique allows adversaries to launch command shells like cmd.exe or PowerShell, effectively bypassing traditional security controls. Defenders should be aware of this technique because it provides a stealthy way for attackers to execute arbitrary commands, potentially leading to further compromise of the system. This activity is detected by monitoring for command shells initiated by RunDLL32, while excluding known benign patterns to reduce false positives. The detection rule was last updated on 2026/05/04 and supports multiple data sources, including Elastic Defend, Microsoft Defender XDR, and Sysmon.

Attack Chain

The attacker gains initial access to the system through an exploit or social engineering.
The attacker uses RunDLL32.exe to execute a malicious DLL.
RunDLL32.exe loads the specified DLL into memory.
The malicious DLL contains code to execute a command shell (cmd.exe or powershell.exe).
RunDLL32.exe spawns a command shell process.
The attacker uses the command shell to execute commands for reconnaissance.
The attacker may use the command shell to download additional payloads.
The attacker leverages the command shell to perform lateral movement.

Impact

Successful exploitation allows attackers to execute arbitrary commands on the compromised system. While the rule is rated “low” severity, this initial access can lead to credential access (T1552) and further lateral movement within the network. Attackers can potentially gain full control of the system, leading to data theft, system disruption, or other malicious activities.

Recommendation

Deploy the Sigma rule “Command Shell Activity Started via RunDLL32” to your SIEM and tune for your environment.
Enable Sysmon process creation logging (Event ID 1) to provide the necessary data for this detection.
Review the process details of RunDLL32.exe to confirm the parent-child relationship with the command shell, helping to reduce false positives.
Implement enhanced monitoring for rundll32.exe and related processes to detect similar activities in the future and improve response times.

Code Signing Policy Modification Through Built-in Tools

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers may attempt to subvert trust controls by disabling or modifying the code signing policy. This allows them to execute unsigned or self-signed malicious code. This can be achieved by modifying boot configuration data (BCD) settings using the built-in bcdedit.exe utility on Windows. Disabling Driver Signature Enforcement (DSE) allows the loading of untrusted drivers, which can compromise system integrity. The rule identifies commands that can disable the Driver Signature Enforcement feature. The scope of the targeting is broad, as it can affect any Windows system where an attacker gains sufficient privileges to modify the BCD settings. This activity is detected by analyzing process execution events for specific command-line arguments used with bcdedit.exe. The detection rule was last updated on 2026-05-04.

Attack Chain

The attacker gains administrative privileges on a Windows system.
The attacker executes bcdedit.exe with arguments to disable driver signature enforcement. Example: bcdedit.exe /set testsigning on or bcdedit.exe /set nointegritychecks on.
The bcdedit.exe modifies the Boot Configuration Data (BCD) store.
The system is restarted to apply the changes made to the BCD.
The attacker loads an unsigned or self-signed malicious driver.
The malicious driver executes with kernel-level privileges.
The attacker performs malicious activities such as installing rootkits, bypassing security controls, or stealing sensitive data.
The attacker maintains persistence by ensuring the malicious driver is loaded on subsequent system reboots.

Impact

Successful modification of the code signing policy can lead to the execution of unsigned or self-signed malicious code, which can compromise the integrity and security of the system. Attackers can install rootkits, bypass security controls, or steal sensitive data. The impact can range from individual system compromise to broader network-wide attacks, depending on the attacker’s objectives.

Recommendation

Deploy the Sigma rule “Code Signing Policy Modification Through Built-in Tools” to your SIEM to detect the execution of bcdedit.exe with arguments used to disable code signing (process.args).
Enable process creation logging with command line arguments on Windows systems to ensure the Sigma rule can capture the relevant events (logsource).
Investigate any detected instances of code signing policy modification, as this activity is typically not legitimate and can indicate malicious activity. The rule First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 can be used to detect suspicious drivers loaded into the system after the command was executed.
Ensure that Driver Signature Enforcement is enabled on all systems.

Potential Chroot Container Escape via Mount

hello@craftedsignal.io — Sat, 02 May 2026 12:45:21 +0000

This detection rule monitors for a specific sequence of commands on Linux systems that could indicate an attempt to escape a containerized environment. The attack involves first mounting a file system, typically targeting the host’s root file system, and then using the chroot command to change the root directory. This combination, if successful, allows an attacker inside a container to gain unauthorized access to the host system. The rule is designed to identify this uncommon behavior pattern, which is a strong indicator of malicious activity. The rule is applicable to environments utilizing Elastic Defend, SentinelOne Cloud Funnel, and Crowdstrike FDR. The detection looks for this sequence occurring within a 5-minute timeframe.

Attack Chain

An attacker gains initial access to a container, possibly through exploiting a vulnerability or misconfiguration in the application running within the container.
The attacker attempts to mount the host’s root filesystem within the container using the mount command, often targeting /dev/sd* devices. This requires sufficient privileges within the container, or the exploitation of a container escape vulnerability to gain such privileges.
The mount command is executed with arguments specifying the device to mount and the mount point within the container’s file system.
The attacker then executes the chroot command, changing the root directory of the current process to the mounted host’s root filesystem.
After successfully executing chroot, the attacker’s perspective shifts to the host’s file system, allowing them to access and modify sensitive files and configurations.
The attacker uses their newly acquired access to install backdoors, create new user accounts with elevated privileges, or modify system configurations to establish persistence.
The attacker may attempt to move laterally to other containers or systems within the network, leveraging their compromised position on the host.
The final objective is to gain complete control over the host system and potentially the entire infrastructure, leading to data exfiltration, system disruption, or other malicious activities.

Impact

A successful container escape can have severe consequences, potentially leading to complete compromise of the host system and the data it contains. Depending on the environment, this could affect a single server or spread to many hosts. The compromise of containerized environments can lead to data breaches, service disruption, and reputational damage. Given the sensitive nature of data often processed within containers, the impact can range from financial losses to regulatory penalties.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential container escapes.
Enable Elastic Defend integration to collect process data, and ensure Session View data is enabled to enhance visibility as mentioned in the setup guide.
Review and harden container configurations to minimize privileges granted to containerized processes, reducing the attack surface for escape attempts.
Implement network segmentation to limit the potential for lateral movement following a successful container escape.
Monitor process execution logs for unusual mount and chroot command sequences within container environments using Elastic Defend, SentinelOne, and Crowdstrike logs.

Potential Kerberos SPN Spoofing via Suspicious DNS Query

hello@craftedsignal.io — Fri, 01 May 2026 17:31:25 +0000

This detection identifies a specific pattern in DNS queries indicative of Kerberos SPN spoofing, a technique used to coerce systems into authenticating to attacker-controlled hosts. The pattern “UWhRCA…BAAAA” represents a marshaled CREDENTIAL_TARGET_INFORMATION structure. Attackers exploit this by crafting malicious DNS names to trick victim systems into requesting Kerberos tickets for legitimate services, often their own identity, but directed towards an attacker-controlled endpoint. This can lead to Kerberos relay or NTLM reflection/relay attacks, bypassing normal NTLM fallback mechanisms. The technique is associated with tools like RemoteKrbRelay and wspcoerce. This activity has been observed in various attacks targeting Windows environments where Kerberos authentication is prevalent. Defenders need to detect and mitigate this early stage of credential access.

Attack Chain

The attacker identifies a target Windows system within the network.
The attacker sets up a malicious server to receive coerced authentication requests.
The attacker crafts a malicious DNS query containing a base64-encoded blob “UWhRCA…BAAAA” representing a marshaled CREDENTIAL_TARGET_INFORMATION structure.
The victim system, triggered by an external factor (e.g., RPC call, scheduled task, or web request), attempts to resolve the crafted DNS name.
The malicious DNS query is sent to the DNS server, which resolves to the attacker’s server.
The victim system initiates a Kerberos authentication request to the attacker’s server, believing it to be a legitimate service.
The attacker’s server relays the Kerberos ticket or uses NTLM reflection/relay techniques to gain unauthorized access.
The attacker compromises the victim system or pivots to other systems within the network using the stolen credentials.

Impact

Successful exploitation can lead to credential compromise, lateral movement, and domain takeover. Victims in Active Directory environments are particularly vulnerable. The impact includes unauthorized access to sensitive data, disruption of services, and potential ransomware deployment. If the coerced service has high privileges, the attacker can gain complete control over the compromised system or even the entire domain. Organizations using Kerberos authentication are at risk.

Recommendation

Deploy the “Potential Kerberos SPN Spoofing via Suspicious DNS Query” rule to your SIEM and tune for your environment to detect malicious DNS queries.
Enable Sysmon Event ID 22 - DNS Query logging to provide the necessary data for detection.
Investigate and block any DNS queries resolving to external IPs that contain the “UWhRCA…BAAAA” pattern.
Monitor process creation events for processes initiating DNS queries containing the suspicious pattern, specifically looking for known coercion tools.
Implement network segmentation to limit the impact of lateral movement if a system is compromised.
Review and harden Kerberos configurations to prevent SPN spoofing and relay attacks.

WDAC Policy File Creation by Unusual Process

hello@craftedsignal.io — Sat, 02 Nov 2024 12:00:00 +0000

Attackers are increasingly targeting Windows Defender Application Control (WDAC) to disable or weaken endpoint defenses. By crafting malicious WDAC policies, adversaries can block legitimate security software and evade detection. This technique involves creating WDAC policy files (.p7b or .cip) in protected system directories using unauthorized processes. The activity often occurs when attackers have already gained a foothold in the system and are attempting to solidify their position. Successful deployment of a malicious WDAC policy can significantly hinder incident response and allow malware to operate undetected. This tactic has gained traction since late 2024, with offensive tools like Krueger demonstrating the potential for weaponizing WDAC against EDR solutions.

Attack Chain

Initial Access: The attacker gains initial access to the system through methods such as phishing or exploiting a software vulnerability.
Privilege Escalation: The attacker escalates privileges to gain administrative access, which is required to modify WDAC policies.
Policy Creation: The attacker crafts a malicious WDAC policy using tools or scripts. This policy is designed to block specific security products or processes.
Staging: The malicious policy is staged in a temporary location on the system, often within user-writable directories.
Policy Placement: The attacker moves the malicious WDAC policy file (.p7b or .cip) to a protected system directory, such as C:\Windows\System32\CodeIntegrity\ or C:\Windows\System32\CodeIntegrity\CiPolicies\Active\. The tool used may be a Living-off-the-Land Binary (LOLBin) or a custom .NET assembly.
Activation: The attacker triggers the activation of the new WDAC policy, which often requires a system reboot or the use of a service control utility.
Defense Evasion: Once the policy is active, the targeted security products are blocked, allowing the attacker to operate with reduced risk of detection.
Lateral Movement/Objectives: With defenses weakened, the attacker can move laterally within the network, exfiltrate data, or achieve other objectives.

Impact

A successful attack targeting WDAC can severely impair an organization’s ability to detect and respond to threats. By blocking security software, attackers can operate with impunity, leading to data breaches, financial losses, and reputational damage. Observed damage includes disabled endpoint detection and response (EDR) solutions, allowing ransomware and other malware to execute without interference. The scope of impact can range from individual workstations to entire domains, depending on the breadth of the WDAC policy deployment.

Recommendation

Deploy the “WDAC Policy File by an Unusual Process” Sigma rule to your SIEM to detect unauthorized WDAC policy modifications.
Monitor file creation events with extensions .p7b and .cip in C:\Windows\System32\CodeIntegrity\ and C:\Windows\System32\CodeIntegrity\CiPolicies\Active\ directories, specifically filtering for processes other than poqexec.exe, TiWorker.exe, and omadmclient.exe.
Enable Sysmon Event ID 11 (File Create) logging to capture file creation events and provide the necessary data for the Sigma rule to function effectively.
Implement strict access control policies on WDAC policy directories to prevent unauthorized modification.

MsiExec Child Process Spawning Network Connections for Defense Evasion

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

Adversaries may abuse the Windows Installer service (msiexec.exe) to proxy the execution of malicious payloads, effectively bypassing application control and other security mechanisms. This technique, known as “Msiexec” proxy execution (T1218.007), involves using msiexec.exe to execute malicious DLLs or scripts. The detection focuses on identifying child processes spawned by MsiExec, particularly those exhibiting network activity. This behavior is atypical for legitimate software installations and updates, making it a strong indicator of potential malicious use. Defenders should be aware of this technique as it allows attackers to blend in with legitimate system processes. The Elastic detection rule, updated on 2026-05-04, aims to identify this suspicious activity across multiple data sources including Elastic Defend, Sysmon, and SentinelOne.

Attack Chain

Attacker gains initial access to the system through an exploit or social engineering.
Attacker leverages msiexec.exe to execute a malicious MSI package with a /v parameter, commonly used to pass verbose logging options, potentially hiding malicious commands.
The malicious MSI package contains custom actions that execute arbitrary code.
Msiexec.exe spawns a child process (e.g., powershell.exe, cmd.exe, or another executable) to carry out malicious actions.
The child process establishes a network connection to an external server or performs DNS lookups, possibly for command and control (C2) communication or to download additional payloads.
The attacker uses the network connection to download and execute further tools or scripts.
The attacker performs lateral movement within the network.
The final objective could be data exfiltration, ransomware deployment, or persistent access.

Impact

Successful exploitation allows attackers to bypass application control and execute arbitrary code on the system. This can lead to malware installation, data theft, or complete system compromise. While the exact number of victims is not specified in the provided source, the technique can be applied across various sectors. The impact can range from individual workstation compromises to large-scale breaches affecting entire organizations.

Recommendation

Deploy the Sigma rule MsiExec Child Process with Unusual Executable and Network Connection to detect suspicious msiexec.exe child processes initiating network connections based on unusual executable paths.
Enable Sysmon process creation logging (Event ID 1) and network connection logging (Event ID 3) to provide the necessary data for the Sigma rule.
Investigate any alerts triggered by the Sigma rules, focusing on the process tree, command-line arguments, and network destinations.
Review and whitelist legitimate software installations and automated deployment tools that use MsiExec and require network access to minimize false positives, as detailed in the “False positive analysis” section of the source material.

Alternate Data Stream Creation/Execution at Volume Root Directory

hello@craftedsignal.io — Mon, 08 Jul 2024 12:00:00 +0000

This detection rule identifies the creation or execution of Alternate Data Streams (ADS) within the root directory of a volume on Windows systems. Attackers leverage this technique to conceal malicious tools or data, as ADSs created in this manner are not easily discoverable by standard system utilities. This method allows for the persistence and execution of malware while evading typical detection mechanisms. This rule is designed for data generated by Elastic Defend, Microsoft Defender XDR, and SentinelOne Cloud Funnel, providing broad coverage across different endpoint security solutions. Monitoring for ADS activity at the volume root is crucial to identify potential defense evasion attempts and hidden malicious payloads.

Attack Chain

Attacker gains initial access to the target system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a script or program (e.g., PowerShell) to create a hidden ADS at the root of a volume (e.g., C:\:evil.exe).
The ADS is populated with malicious code, such as a reverse shell or malware payload.
The attacker uses a command-line tool or script to execute the hidden ADS file. For example: wmic process call create "cmd.exe /c start C:\:evil.exe".
The malicious code within the ADS executes, allowing the attacker to perform unauthorized actions, such as data exfiltration or establishing persistence.
The attacker uses the hidden ADS to maintain persistence on the system, ensuring continued access even after reboots.
The attacker further leverages the compromised system to move laterally within the network, compromising additional systems and escalating privileges.

Impact

Successful exploitation allows attackers to hide malicious tools and maintain persistence on compromised systems. The creation of ADSs at the volume root directory makes it difficult for administrators and security tools to detect the presence of malware. This can lead to prolonged compromise, data breaches, and significant disruption of business operations. The rule has a risk score of 47, and a medium severity is applied.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect ADS creation and execution at the volume root directory.
Enable logging for file creation events (Sysmon Event ID 11) and process creation events (Sysmon Event ID 1) for enhanced visibility into ADS activity.
Investigate alerts generated by the Sigma rules to determine the legitimacy of ADS creation or execution, focusing on processes and file paths that match the [A-Z]:\\:.+ regex pattern in the rule query.
Regularly scan systems for hidden ADS files using specialized tools to uncover any potential malicious files.
Implement application control policies to restrict the execution of unauthorized applications and prevent the creation of malicious ADSs.

NTDS Dump via Wbadmin

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

This detection identifies the execution of wbadmin.exe with arguments indicative of an attempt to access and dump the NTDS.dit file from a Windows domain controller. Attackers with sufficient privileges, specifically those belonging to groups like Backup Operators, can abuse the legitimate wbadmin.exe utility to create a backup of the Active Directory database (NTDS.dit). This file contains sensitive credential information, and once obtained, attackers can extract password hashes and compromise the entire domain. This activity is often part of a larger attack aimed at gaining persistent access and control over the network. The Elastic detection rule was published on 2024-06-05 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system within the target network. This may be achieved through phishing, exploiting vulnerabilities, or compromised credentials.
The attacker escalates privileges to obtain membership in the Backup Operators group or a similar privileged group capable of running backups.
The attacker executes wbadmin.exe with the recovery argument, targeting the NTDS.dit file. The command line includes parameters to create a system state backup.
Wbadmin creates a backup of the system state, including the NTDS.dit file, in a specified location.
The attacker copies the NTDS.dit file from the backup location to a separate location for offline analysis.
The attacker uses tools such as ntdsutil.exe or secretsdump.py to extract password hashes from the NTDS.dit file.
The attacker cracks the password hashes or uses them in pass-the-hash attacks to gain access to other systems and resources within the domain.
The attacker achieves domain dominance and persistence, allowing them to control critical systems and data.

Impact

Successful exploitation allows attackers to dump credentials from the NTDS.dit file, leading to complete compromise of the Active Directory domain. This enables them to move laterally, access sensitive data, and establish persistent control over the environment. The impact can include data breaches, ransomware deployment, and long-term disruption of business operations. The medium risk score indicates that while the attack requires specific privileges, the consequences are significant if successful.

Recommendation

Enable process creation logging with command line arguments to detect wbadmin.exe execution as described in the Attack Chain (Data Source: Windows Security Event Logs, Sysmon).
Implement the provided Sigma rule to detect suspicious wbadmin.exe execution with NTDS.dit related arguments in your SIEM (Rule: NTDS Dump via Wbadmin).
Monitor and restrict membership in privileged groups like Backup Operators to minimize the risk of abuse (Reference: https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960).
Review and whitelist legitimate backup schedules or disaster recovery processes to reduce false positives (False positive analysis).

Microsoft Management Console File Execution from Unusual Path

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

Attackers may exploit Microsoft Management Console (MMC) by executing .msc files from non-standard directories to bypass security controls. This technique can be used for initial access and execution. This detection focuses on identifying the execution of mmc.exe with .msc files from paths outside the typical system directories, which are generally considered trusted. By monitoring process executions and filtering out known legitimate paths, analysts can identify potentially malicious activity related to the misuse of MMC. The rule aims to detect deviations from standard administrative practices that could indicate unauthorized access or command execution via malicious or compromised .msc files. The detection logic specifically excludes executions from common directories like System32, SysWOW64, and Program Files.

Attack Chain

An attacker gains initial access to the system through an unspecified method.
The attacker places a malicious .msc file in an unusual or untrusted directory (e.g., C:\Users\Public).
The attacker executes mmc.exe with the malicious .msc file as an argument from the untrusted path.
mmc.exe processes the .msc file, potentially executing embedded commands or scripts.
The malicious .msc file performs unauthorized actions on the system, such as modifying system settings or executing arbitrary code.
The attacker leverages the execution context of mmc.exe to bypass security controls and escalate privileges.
The attacker may establish persistence by creating a scheduled task or modifying registry keys to execute the malicious .msc file automatically.

Impact

Successful exploitation can lead to unauthorized access, command execution, and privilege escalation, potentially compromising the entire system. While specific victim counts or sector targeting are not available, the technique is applicable across various Windows environments. The use of a trusted system binary like mmc.exe for malicious purposes can evade traditional security measures, making detection more challenging.

Recommendation

Implement the Sigma rule Microsoft Management Console File from Unusual Path to detect the execution of mmc.exe with .msc files from untrusted paths.
Enable process creation logging with command-line arguments to provide the necessary data for the Sigma rule to function effectively.
Investigate any alerts generated by the Sigma rule, focusing on the origin and content of the .msc file.
Consider implementing application control policies to restrict the execution of .msc files to authorized directories only.
Review and audit the use of MMC in the environment to identify any legitimate use cases that might trigger false positives.

DNS Global Query Block List Modified or Disabled

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

The DNS Global Query Block List (GQBL) is a Windows security feature designed to prevent the resolution of specific DNS names, commonly exploited in attacks like WPAD spoofing. Attackers who have obtained elevated privileges, such as DNSAdmin, can modify or disable this list to bypass security controls. This allows exploitation of hosts running WPAD with default settings. The modification of the GQBL can be used for privilege escalation and lateral movement within a network. This rule detects changes to the registry values associated with the GQBL, specifically “EnableGlobalQueryBlockList” and “GlobalQueryBlockList.” This activity could indicate an attacker attempting to weaken defenses to facilitate further malicious activities.

Attack Chain

An attacker gains initial access to a system, possibly through compromised credentials or exploiting a vulnerability.
The attacker escalates privileges to obtain DNSAdmin rights.
The attacker modifies the “EnableGlobalQueryBlockList” registry value to “0” or “0x00000000,” effectively disabling the GQBL.
Alternatively, the attacker modifies the “GlobalQueryBlockList” registry value to remove “wpad” from the list.
The attacker leverages the disabled GQBL to conduct WPAD spoofing attacks, redirecting network traffic to attacker-controlled servers.
The attacker captures user credentials transmitted during WPAD authentication.
The attacker uses the captured credentials to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful modification or disabling of the DNS Global Query Block List can lead to WPAD spoofing attacks, credential theft, lateral movement, and ultimately, complete compromise of the network. Attackers can leverage this technique to gain unauthorized access to sensitive data or systems. The impact includes potential data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule Registry Modification of DNS Global Query Block List to your SIEM to detect unauthorized changes to the GQBL configuration.
Enable Sysmon registry event logging to capture the necessary events for the Sigma rule to function (reference the logsource in the rule).
Review and restrict DNSAdmin privileges to only necessary accounts to minimize the attack surface (reference: Overview section).
Monitor network traffic for unusual DNS queries or WPAD-related activity, correlating with registry modification events (reference: Attack Chain step 5).
Regularly audit registry settings related to DNS configuration, including the GQBL, to identify unauthorized modifications (reference: Attack Chain steps 3 & 4).
Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List (reference: Impact section).

Suspicious Child Processes from Communication Applications

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

This detection rule focuses on identifying suspicious child processes of communication applications such as Slack, Cisco Webex, Microsoft Teams, Discord, WhatsApp, Zoom, and Thunderbird on Windows operating systems. Attackers may attempt to masquerade as legitimate processes or exploit vulnerabilities in these applications to execute malicious code. The rule monitors for the creation of child processes by these communication apps and checks if those child processes are unexpected, untrusted, or lack a valid code signature. This detection is crucial because successful exploitation can lead to unauthorized access, data exfiltration, or further compromise of the system. The rule has been actively maintained since August 2023, with updates as recent as May 2026, indicating its relevance and ongoing refinement to address emerging threats.

Attack Chain

User launches a communication application (e.g., Slack, Teams, Webex).
The communication application executes a vulnerable or compromised component.
The compromised component spawns a child process (e.g., powershell.exe, cmd.exe).
The child process executes a malicious command or script.
The script attempts to download additional payloads from an external source.
The payload executes, establishing persistence through registry modification or scheduled tasks.
The attacker gains remote access to the system.
Data exfiltration or lateral movement within the network occurs.

Impact

A successful attack can lead to the compromise of sensitive data, installation of malware, and potential lateral movement within the organization’s network. By exploiting communication applications, attackers can gain access to internal communications, confidential documents, and user credentials. The number of affected users and the extent of the damage depend on the compromised application and the attacker’s objectives. If successful, this attack may lead to significant financial loss, reputational damage, and disruption of business operations.

Recommendation

Deploy the Sigma rule Suspicious Communication App Child Process to your SIEM to detect anomalous child processes spawned by communication applications and tune for your environment.
Enable process creation logging with command line arguments in Windows to ensure that the Sigma rule has the necessary data to function correctly (logsource: process_creation, product: windows).
Investigate any alerts generated by the rule and review the command line arguments of the spawned processes to identify potential malicious activity.
Implement application whitelisting to restrict the execution of unauthorized applications and reduce the attack surface.
Ensure that all communication applications are updated to the latest versions to patch known vulnerabilities and reduce the risk of exploitation.
Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server, referencing the setup guide.

Network-Level Authentication (NLA) Disabled via Registry Modification

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

Network Level Authentication (NLA) is a security feature in Windows that requires users to authenticate before establishing a full RDP session, adding an extra layer of protection against unauthorized access. Attackers might attempt to disable NLA to gain access to the Windows sign-in screen without proper authentication. This tactic can facilitate the deployment of persistence mechanisms, such as leveraging Accessibility Features like Sticky Keys, or enable unauthorized remote access. This brief addresses the registry modifications associated with disabling NLA and provides detection strategies to identify such attempts. The references indicate that this technique is used in conjunction with other attacks for lateral movement within a compromised network.

Attack Chain

Initial access to the system is gained (potentially via compromised credentials or vulnerability exploitation).
The attacker elevates privileges to modify system-level settings.
The attacker modifies the registry key HKLM\SYSTEM\ControlSet*\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication to disable NLA.
The UserAuthentication value is set to “0” or “0x00000000”.
The attacker attempts to establish an RDP connection to the compromised system.
Due to the disabled NLA, the attacker bypasses the initial authentication screen.
The attacker leverages accessibility features (e.g., Sticky Keys) for persistence or further exploitation.
The attacker gains unauthorized access to the system.

Impact

Successful disabling of NLA allows attackers to bypass authentication and gain unauthorized access to systems via RDP. This can lead to data theft, malware installation, or further lateral movement within the network. While the exact number of victims and sectors targeted are unspecified, the potential impact includes significant data breaches and system compromise.

Recommendation

Enable Sysmon process-creation and registry event logging to detect the registry modifications (Elastic Defend, Elastic Endgame, Microsoft Defender XDR, SentinelOne, Sysmon).
Deploy the Sigma rule provided to detect attempts to modify the UserAuthentication registry key (Sysmon Registry Events).
Review and harden RDP configurations across the environment to prevent unauthorized access (Microsoft documentation).
Monitor endpoint security policies to detect unauthorized registry modifications (Endpoint Security Policies).

Wireless Credential Dumping via Netsh

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

Attackers often target wireless credentials to gain unauthorized network access. This involves using the legitimate Windows command-line tool netsh.exe to extract Wi-Fi passwords stored on a compromised system. By leveraging netsh, attackers can bypass traditional security measures and retrieve sensitive information without deploying custom malware. The technique involves specific command-line arguments that instruct netsh to display wireless keys in cleartext, exposing the network passwords. Defenders must monitor netsh command-line activity to identify potential credential access attempts. This activity can lead to lateral movement within the network.

Attack Chain

The attacker gains initial access to a Windows system (e.g., via phishing or exploiting a software vulnerability).
The attacker executes netsh.exe with specific arguments to list available wireless profiles.
The attacker identifies a target wireless profile from the list.
The attacker executes netsh.exe again, this time specifying the target profile and requesting the key to be displayed in cleartext using the key=clear argument.
Netsh.exe retrieves the Wi-Fi password from the Windows Wireless LAN service.
The password is displayed in the command output, which the attacker captures.
The attacker uses the obtained Wi-Fi password to connect to the wireless network.
The attacker can now perform lateral movement and access internal resources.

Impact

Successful credential dumping allows attackers to gain unauthorized access to wireless networks. This can lead to lateral movement within the organization’s network, access to sensitive data, and further compromise of systems and resources. The impact includes potential data breaches, financial losses, and reputational damage. This technique allows attackers to bypass traditional network access controls.

Recommendation

Deploy the Sigma rule Detect Wireless Credential Dumping via Netsh to identify suspicious netsh.exe commands in your environment.
Enable Sysmon process creation logging to capture the netsh.exe command-line arguments.
Investigate any alerts triggered by the Sigma rule, focusing on the process lineage and user context as outlined in the “Triage and analysis” section of the source.
Implement strong password policies for Wi-Fi networks, including the use of WPA2 or WPA3 encryption.
Review and restrict the use of netsh.exe on systems where it is not required, using application control solutions.
Monitor for related alerts indicating lateral movement, staging, remote access, or persistence, as mentioned in the “Triage and analysis” section of the source.

Windows Console History Clearing

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

Attackers can try to cover their tracks by clearing the PowerShell console history on Windows systems. PowerShell offers multiple ways to log commands, including the built-in history and the command history managed by the PSReadLine module. This activity is often part of post-compromise behavior aimed at evading detection and forensic analysis. This rule detects the execution of specific commands that clear the built-in PowerShell logs or delete the ConsoleHost_history.txt file. The rule focuses on PowerShell activity and covers scenarios where commands like Clear-History, Remove-Item, rm, and Set-PSReadlineOption are used to manipulate command history.

Attack Chain

Initial access is gained through an unspecified method, potentially exploiting a vulnerability or using stolen credentials.
The attacker executes PowerShell (powershell.exe, pwsh.exe, or powershell_ise.exe) to perform reconnaissance and other malicious activities.
The attacker attempts to clear the PowerShell command history using the Clear-History cmdlet.
Alternatively, the attacker attempts to remove the ConsoleHost_history.txt file using Remove-Item or rm, which stores the PSReadLine command history.
Another method involves using the Set-PSReadlineOption cmdlet with the SaveNothing parameter to prevent the saving of future command history.
The attacker may leverage other tools and techniques to further obscure their activities and maintain persistence on the compromised system.
The attacker attempts to move laterally to other systems within the network to increase their impact.
The final objective is data exfiltration, deployment of ransomware, or other malicious activities, all while attempting to evade detection by clearing logs and command history.

Impact

Successful clearing of console history hinders forensic investigations and incident response efforts. If command history is cleared, administrators will have difficulty reconstructing the attacker’s actions and identifying the extent of the compromise. This can lead to prolonged incident response times, increased damage, and potential for further exploitation of the compromised systems.

Recommendation

Deploy the Sigma rule Detect Clearing PowerShell History to your SIEM to detect the use of Clear-History cmdlet, potentially indicating an attempt to remove command history.
Deploy the Sigma rule Detect Removal of PowerShell History File to detect the use of Remove-Item or rm command against the PowerShell history file.
Enable PowerShell logging and auditing policies to ensure adequate visibility into PowerShell activity as described in the setup instructions to improve detection capabilities.

System File Ownership Change for Defense Evasion

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

Attackers often attempt to modify file or directory ownership to bypass access controls and gain unauthorized access to sensitive data or system resources. This involves altering permissions associated with critical files or directories, granting broader access to accounts under attacker control or resetting permissions to default values which might be more permissive. This defense evasion technique can be used to establish persistence, escalate privileges, or exfiltrate data without triggering standard security alerts. The common tools used include icacls.exe and takeown.exe, typically targeting files within the C:\Windows\ directory.

Attack Chain

Initial access is achieved through an existing compromised account or vulnerability.
The attacker uses takeown.exe /f to take ownership of a target file or directory.
The attacker uses icacls.exe /reset to reset the ACL of the file or directory.
Alternatively, the attacker uses icacls.exe /grant Everyone:F to grant full control to everyone, weakening security.
The attacker modifies the contents of the file, such as injecting malicious code or configuration changes.
The attacker leverages the modified file for persistence, such as a modified system DLL loaded at boot.
The system executes the malicious code when the compromised file is accessed or executed.
The attacker achieves their objective, such as maintaining persistence, escalating privileges, or executing arbitrary commands.

Impact

Compromising file and directory permissions can lead to significant security breaches. Successful attacks can allow unauthorized access to sensitive data, system instability, or the execution of malicious code with elevated privileges. This can affect any Windows environment where file permissions are improperly managed, with potential for widespread system compromise and data exfiltration. The impact is most severe on systems containing sensitive data or critical infrastructure components.

Recommendation

Monitor process execution for icacls.exe and takeown.exe with suspicious arguments targeting system files (e.g., C:\Windows\*) to detect potential permission modification attempts using the provided Sigma rules.
Enable Windows Security Auditing for file system changes to capture events related to permission modifications and ownership changes.
Deploy the provided Sigma rules to your SIEM and tune for your environment, specifically focusing on processes modifying permissions on files within the C:\Windows\ directory.
Investigate any alerts triggered by the Sigma rules, focusing on the process execution chain and the target files being modified.

Netsh Helper DLL Persistence

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

The netsh.exe utility in Windows supports the addition of Helper DLLs to extend its functionality. An attacker can abuse this mechanism to establish persistence by adding a malicious DLL. When netsh.exe is executed, the malicious DLL is loaded and executed, allowing the attacker to run arbitrary code with the privileges of the user or process that initiated netsh.exe. This can be done by administrators or scheduled tasks, making it a stealthy and effective persistence technique. The registry key targeted by this technique is HKLM\Software\Microsoft\netsh\.

Attack Chain

Attacker gains initial access to the target system through unspecified means.
Attacker creates a malicious DLL to be used as a Netsh Helper DLL.
Attacker modifies the Windows Registry to add the malicious DLL as a Netsh Helper DLL under HKLM\Software\Microsoft\netsh\.
The system administrator or a scheduled task executes netsh.exe.
netsh.exe loads and executes the malicious DLL, granting the attacker code execution.
The malicious DLL performs its intended actions, such as establishing a reverse shell or deploying additional malware.
The attacker maintains persistence on the system through the malicious Netsh Helper DLL.

Impact

Successful exploitation allows attackers to establish persistent access to a compromised system. This can lead to data theft, system compromise, and further malicious activities. While the risk score is low, the persistence mechanism can allow attackers to maintain a foothold for extended periods, increasing the potential for significant damage.

Recommendation

Monitor registry modifications under the HKLM\Software\Microsoft\netsh\ path for suspicious DLL additions using the “Netsh Helper DLL Registry Modification” Sigma rule.
Enable Sysmon registry event logging to collect the necessary data for the Sigma rule.
Investigate any alerts generated by the Sigma rule by reviewing the DLL file properties, timestamps, and related processes.

MsXsl.exe Network Connection for Defense Evasion

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

MsXsl.exe is a Windows utility designed to transform XML data using XSLT stylesheets. Adversaries are known to abuse this utility to execute malicious scripts, bypassing application control and other security measures. This behavior is often used as a defense evasion technique to download or execute malicious payloads. This activity has been observed since at least March 2020. The abuse of msxsl.exe allows attackers to establish command and control or exfiltrate sensitive data without being easily detected, as the tool is a signed Microsoft binary. This matters for defenders because it highlights the need to monitor legitimate system utilities for anomalous behavior, specifically network connections to external IP addresses.

Attack Chain

An attacker gains initial access to a Windows system through unspecified means.
The attacker leverages msxsl.exe to execute a malicious script.
Msxsl.exe initiates a network connection to an external IP address.
The script downloads a malicious payload from the external server.
The downloaded payload is executed on the compromised system.
The attacker establishes a command and control channel through the network connection.
The attacker performs data exfiltration via the established C2 channel.

Impact

Compromised systems can be used for further malicious activities, including data theft, lateral movement, and deployment of additional malware. Successful exploitation can lead to sensitive data exfiltration, disruption of services, or complete system compromise. The low risk score does not represent impact, but instead reflects that the behavior is not always malicious, and may be a feature of normal software operation.

Recommendation

Enable Sysmon network connection logging to monitor msxsl.exe network activity.
Deploy the Sigma rule “Network Connection via MsXsl” to your SIEM and tune for your environment to detect suspicious network connections originating from msxsl.exe.
Investigate any alerts generated by the Sigma rule, focusing on the destination IP address and the parent process of msxsl.exe.
Whitelist legitimate uses of msxsl.exe in your environment based on known good processes or applications to reduce false positives.

VaultCmd Usage for Listing Windows Credentials

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

Attackers may abuse the Windows Credential Manager to list or dump credentials stored within. This allows for the exfiltration of saved usernames and passwords. The tool vaultcmd.exe can be used to interact with the Credential Manager and list the stored credentials. This activity is often performed in preparation for lateral movement within a compromised network. This detection focuses on identifying instances where vaultcmd.exe is executed with the /list* argument, indicating an attempt to enumerate stored credentials. The detection rule is designed to identify abuse of vaultcmd for credential access, enabling defenders to detect unauthorized credential access activities.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).
The attacker executes vaultcmd.exe with the /list argument to enumerate the credentials stored in the Windows Credential Manager.
The vaultcmd.exe process accesses the Credential Manager to retrieve the list of saved credentials.
The output of vaultcmd.exe (the list of credentials) is captured or redirected to a file for later exfiltration.
The attacker parses the output to identify valuable credentials, such as domain administrator accounts or service accounts.
The attacker uses the acquired credentials to authenticate to other systems on the network (lateral movement).
The attacker elevates privileges on the target systems.
The final objective is achieved, such as data theft or ransomware deployment.

Impact

Successful execution of this attack chain can lead to unauthorized access to sensitive resources, lateral movement within the network, and ultimately, data theft, system compromise, or ransomware deployment. A compromised user account can grant the attacker access to internal systems, confidential data, and critical infrastructure. If the attacker gains domain administrator credentials, they can compromise the entire Windows domain.

Recommendation

Monitor process execution events for instances of vaultcmd.exe being executed with the /list* argument (Data Source: Windows Security Event Logs, Sysmon, Microsoft Defender XDR, SentinelOne, Crowdstrike).
Deploy the Sigma rule “Detect VaultCmd Credential Listing” to your SIEM to identify potential credential access attempts.
Investigate any identified instances of vaultcmd.exe being executed with the /list* argument to determine the legitimacy of the activity.
Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future.

Suspicious Managed Code Hosting Process

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

This detection identifies suspicious managed code hosting processes on Windows systems. Attackers may leverage processes like wscript.exe, cscript.exe, mshta.exe, wmic.exe, svchost.exe, dllhost.exe, cmstp.exe, and regsvr32.exe to execute malicious code, often bypassing traditional security controls. These processes can be abused to load and execute .NET assemblies or other managed code components. The detection focuses on identifying unusual file creation events associated with these processes which could indicate an attacker is attempting to leverage these processes for malicious purposes. This activity might be indicative of code injection, defense evasion, or other suspicious code execution techniques. The rule uses EQL to search for file events associated with specific processes.

Attack Chain

An attacker gains initial access to the system through a phishing email or compromised software.
The attacker uses a LOLBin such as mshta.exe or regsvr32.exe to bypass application control.
The LOLBin executes a malicious script or loads a malicious DLL from a user-writable location.
The malicious script or DLL performs reconnaissance activities, such as gathering system information or enumerating network resources.
The attacker then attempts to escalate privileges by exploiting a vulnerability or using stolen credentials.
The attacker uses the compromised process to download and execute additional malware.
The malware establishes persistence on the system through scheduled tasks or registry modifications.
The attacker performs lateral movement within the network, compromising additional systems and exfiltrating sensitive data.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise systems, steal sensitive data, and establish persistence. The use of LOLBins can bypass application control, making detection more challenging. Depending on the scope of the attack, this could result in significant financial losses, reputational damage, and disruption of business operations. This is a high-severity finding due to the potential for attackers to gain full control over affected systems.

Recommendation

Enable Sysmon file creation logging (Event ID 11) to collect the necessary data for this detection.
Deploy the Sigma rule “Suspicious Managed Code Hosting Process” to your SIEM and tune for your environment.
Investigate any alerts generated by this rule, focusing on the file paths, process command lines, and parent processes involved.
Monitor for unexpected file creation events associated with processes like wscript.exe, cscript.exe, and mshta.exe in user-writable directories.
Implement application control policies to restrict the execution of LOLBins and other potentially malicious processes.
Correlate the detection with other security events to identify related malicious activity.

Program Files Directory Masquerading

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

This detection identifies processes executing from directories that masquerade as the legitimate Windows Program Files directories. Attackers may create directories with similar names (e.g., “C:\Program Files Bad” or “C:\Program Files(x86) Malicious”) to host and execute malicious executables, bypassing security measures that trust the standard Program Files locations. This technique is particularly effective when combined with low-privilege accounts, as it allows attackers to evade detections that whitelist only the standard, trusted Program Files paths. The timeframe for this rule is the last 9 months. This matters to defenders because it highlights a common tactic used to bypass established trust relationships within the Windows operating system, requiring more granular inspection of process execution paths.

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker creates a new directory that mimics the “Program Files” or “Program Files (x86)” directory (e.g., “C:\Program Files Bad”).
The attacker copies or downloads malicious executable files into the newly created masquerading directory.
The attacker executes the malicious executable from the masquerading directory.
The operating system loads the executable and begins its execution, potentially bypassing any allowlisting rules that only check the standard “Program Files” locations.
The malicious executable performs its intended actions, such as installing malware, establishing persistence, or exfiltrating data.
The attacker leverages the compromised system to move laterally within the network, repeating the masquerading technique on other systems.

Impact

A successful attack can lead to malware infection, data theft, or complete system compromise. The impact is significant, as it undermines the trust placed in the “Program Files” directory and allows attackers to operate undetected for extended periods. While no specific victim counts are given, the technique is broadly applicable to any Windows environment, especially those relying on simple path-based allowlisting for security.

Recommendation

Deploy the Sigma rule Program Files Directory Masquerading Detection to your SIEM to detect suspicious process executions from masquerading directories.
Enable Sysmon process creation logging (Event ID 1) to collect the necessary process execution data for the Sigma rule.
Regularly review and update allowlisting rules to include more specific criteria beyond just the “Program Files” directory, such as file hashes or digital signatures.
Investigate any alerts generated by the Sigma rule, focusing on the parent processes and user accounts associated with the suspicious executions.
Monitor file creation events in the root directory to detect suspicious folders being created (file_event category)

Potential Remote Install via MsiExec

hello@craftedsignal.io — Mon, 29 Jan 2024 10:00:00 +0000

Adversaries may abuse Windows Installer (msiexec.exe) to perform remote installations of malicious payloads. This technique is used for initial access, defense evasion, and execution of arbitrary code. The detection rule identifies attempts to install a file from a remote server using MsiExec. The rule looks for msiexec.exe processes running with arguments such as -i, /i, -p, or /p, indicative of remote installations, and executed from suspicious parent processes like sihost.exe, explorer.exe, cmd.exe, wscript.exe, mshta.exe, powershell.exe, wmiprvse.exe, pcalua.exe, forfiles.exe, and conhost.exe. The rule includes exceptions to reduce false positives from legitimate software installations, specifically excluding command lines containing --set-server, UPGRADEADD, --url, USESERVERCONFIG, RCTENTERPRISESERVER, app.ninjarmm.com, zoom.us/client, SUPPORTSERVERSTSURI, START_URL, AUTOCONFIG, awscli.amazonaws.com, */i \"C:*, and */i C:\\*. This technique can lead to complete system compromise and data exfiltration.

Attack Chain

An attacker gains initial access via an unspecified method (e.g., phishing, exploit).
The attacker uses a script or command-line interpreter (e.g., cmd.exe, powershell.exe) to initiate the msiexec.exe process.
The msiexec.exe process is launched with arguments that specify a remote MSI package (-i, /i, -p, /p) and enable silent installation (/qn, -qn, -q, /q, /quiet).
The msiexec.exe process downloads the MSI package from a remote server over HTTP or HTTPS.
msiexec.exe executes the downloaded MSI package, which may contain malicious payloads.
The malicious payload executes, potentially performing actions such as installing malware, establishing persistence, or escalating privileges.
The attacker gains control over the compromised system.
The attacker performs further actions, such as data exfiltration or lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to install malware, steal sensitive data, or disrupt system operations. A compromised system can be used as a pivot point to access other systems on the network. The impact can range from data breaches and financial losses to reputational damage and disruption of critical services. The number of potential victims depends on the scope of the initial access and the attacker’s objectives.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious MsiExec invocations with remote payloads.
Enable Sysmon process creation logging (Event ID 1) to ensure the required data is available for the Sigma rule.
Investigate any alerts generated by the Sigma rule, focusing on the parent process, command-line arguments, and network connections associated with the msiexec.exe process.
Monitor process execution events for child processes spawned by msiexec.exe for anomalous activity.
Implement application control policies to restrict the execution of msiexec.exe to authorized users and processes only.

Potential Exploitation of an Unquoted Service Path Vulnerability

hello@craftedsignal.io — Mon, 29 Jan 2024 10:00:00 +0000

Unquoted service paths in Windows can be exploited to escalate privileges. When a service path lacks quotes, Windows may execute a malicious executable placed in a higher-level directory. This detection rule identifies suspicious processes starting from common unquoted paths, like “C:\Program.exe” or executables within “C:\Program Files (x86)\” or “C:\Program Files\”, signaling potential exploitation attempts. The rule aims to detect early stages of privilege escalation threats. This rule is designed for data generated by Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, Windows Security Event Logs, and Crowdstrike.

Attack Chain

An attacker identifies a service running with an unquoted path, such as “C:\Program Files\Unquoted Path Service\Common\Service.exe”.
The attacker places a malicious executable named “Program.exe” in “C:"
The operating system attempts to start the service “C:\Program Files\Unquoted Path Service\Common\Service.exe”.
Due to the unquoted path, the OS incorrectly parses the path and first attempts to execute “C:\Program.exe”.
The malicious “Program.exe” executes with the privileges of the service account.
The malicious executable performs actions to escalate privileges, such as adding a user to the local administrators group.
The attacker gains elevated access to the system.

Impact

Successful exploitation of an unquoted service path vulnerability can lead to complete system compromise, as the attacker gains the privileges of the service account. This can allow the attacker to install programs, view, change, or delete data, or create new accounts with full user rights. The impact is high, potentially leading to a loss of confidentiality, integrity, and availability of the affected system.

Recommendation

Review process executable paths to confirm if they match the patterns specified in the rule query, such as “?:\Program.exe” or executables within “C:\Program Files (x86)\” or “C:\Program Files\”.
Deploy the Sigma rule “Potential Exploitation of an Unquoted Service Path Vulnerability” to your SIEM and tune for your environment.
Enable Sysmon process-creation logging with Event ID 1 to activate the Sigma rules above.
Conduct a thorough review of service configurations to identify and correct any unquoted service paths as part of remediation steps.

Potential Abuse of Certreq for File Transfer via HTTP POST

hello@craftedsignal.io — Sun, 28 Jan 2024 20:47:00 +0000

The Windows Certreq utility is a command-line tool used for managing certificates. Adversaries may abuse Certreq to download files from or upload data to a remote server by initiating an HTTP POST request. This behavior can be used for command and control (C2) or exfiltration. This technique leverages a legitimate system binary (LOLBin) to evade detection. Elastic has observed this behavior being detected through multiple data sources including Elastic Defend, Microsoft Defender XDR, Sysmon, SentinelOne, and Crowdstrike. This is a cross-industry threat that can affect any organization using Windows.

Attack Chain

An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
The attacker executes Certreq.exe with the -Post argument to initiate an HTTP POST request.
The Certreq process attempts to connect to a remote server to send or receive data.
The remote server responds to the Certreq request, potentially delivering a file or receiving exfiltrated data.
The downloaded file is saved to disk (if applicable).
The attacker may execute the downloaded file or further process the exfiltrated data.
The attacker may attempt to clean up the Certreq command from command history or logs to evade detection.

Impact

Successful exploitation could lead to the download and execution of malicious payloads, potentially compromising the affected system and network. Alternatively, sensitive data could be exfiltrated from the target environment. The impact can range from data theft and system compromise to full network intrusion, depending on the attacker’s objectives and the data accessed. The severity is medium because Certreq is a legitimate tool, and its abuse requires specific command-line arguments and network activity.

Recommendation

Deploy the Sigma rule “Detect Certreq HTTP Post Request” to your SIEM to identify potential abuse of Certreq for file transfer.
Enable Sysmon process creation logging (Event ID 1) to capture the execution of Certreq.exe and its command-line arguments, enabling detections.
Monitor network connections originating from Certreq.exe for unusual destinations or data transfer patterns using network connection logs.
Investigate any instances of Certreq.exe executing with the -Post argument, as this is not typical usage of the utility.

AMSI Enable Registry Key Modification for Defense Evasion

hello@craftedsignal.io — Sat, 27 Jan 2024 18:23:00 +0000

Attackers can disable the Antimalware Scan Interface (AMSI) to evade detection by modifying the AmsiEnable registry key. This technique is commonly employed to execute malicious scripts without triggering security warnings or blocks. The AMSI, a Windows feature, allows applications and services to request the scanning of potentially malicious content (e.g., PowerShell scripts, JScript) before execution. By setting the AmsiEnable value to 0, an attacker can disable AMSI for the current user, effectively bypassing real-time script scanning. This action is often a precursor to deploying further malicious payloads or establishing persistence on a compromised system. This behavior has been observed since at least 2019 and continues to be a relevant defense evasion technique.

Attack Chain

An attacker gains initial access to the target system, possibly through phishing or exploiting a vulnerability.
The attacker executes a script or binary that attempts to modify the AmsiEnable registry key.
The script or binary uses reg.exe, PowerShell, or another tool to set the AmsiEnable registry value to 0. The registry key location is typically HKEY_USERS\\Software\Microsoft\Windows Script\Settings\AmsiEnable.
After successfully disabling AMSI, the attacker proceeds to execute malicious scripts or code. These scripts may use powershell.exe, wscript.exe, or cscript.exe.
The malicious scripts download and execute additional payloads, such as malware or remote access tools (RATs).
The attacker performs lateral movement within the network using the compromised system as a pivot.
The attacker attempts to establish persistence, ensuring continued access to the system even after reboots.
The attacker exfiltrates sensitive data or deploys ransomware to achieve their objectives.

Impact

Successful modification of the AmsiEnable registry key allows attackers to execute malicious scripts without triggering AMSI alerts, leading to potential malware infections, data breaches, and system compromise. Disabling AMSI significantly reduces the effectiveness of endpoint security solutions, making the system more vulnerable to attack. The impact can range from individual workstation compromise to widespread network infections, depending on the attacker’s objectives and the organization’s security posture.

Recommendation

Deploy the Sigma rule Detect AmsiEnable Registry Modification via Registry Events to your SIEM to detect modifications to the AmsiEnable registry key.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
Monitor process creation events for processes modifying registry keys, especially reg.exe and PowerShell, using the rule Detect AmsiEnable Registry Modification via Process Creation.
Investigate any alerts generated by these rules promptly to determine if the activity is malicious or legitimate.
Implement application control policies to restrict the execution of unsigned or untrusted scripts and binaries.
Harden systems by restricting user permissions to modify critical registry keys.

Microsoft Office 'Office Test' Registry Persistence Abuse

hello@craftedsignal.io — Sat, 27 Jan 2024 17:30:00 +0000

The “Office Test” registry key, located under HKCU\Software\Microsoft\Office Test\Special\Perf, is a legitimate feature that allows specifying a DLL to be executed every time an MS Office application is started. Attackers can abuse this functionality by modifying the registry to point to a malicious DLL, achieving persistence on a compromised host. This allows for continued malicious activity even after a system restart or user logout. Elastic has published a rule to detect this behavior. The modification of this registry key, excluding deletions, is a strong indicator of potential abuse, and can be detected via endpoint detection and response (EDR) solutions as well as traditional Sysmon logging.

Attack Chain

An attacker gains initial access to a system, often through phishing or exploiting a vulnerability.
The attacker establishes a foothold and escalates privileges to make necessary registry modifications.
The attacker modifies the HKCU\Software\Microsoft\Office Test\Special\Perf registry key, adding a new entry or modifying an existing one to point to a malicious DLL.
The attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.
A user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).
The Office application loads the DLL specified in the “Office Test” registry key during startup.
The malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.
The attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.

Impact

Successful exploitation allows attackers to maintain persistent access to a compromised system. The injected DLL can be used to execute arbitrary code, potentially leading to data theft, malware installation, or further compromise of the network. The relatively low risk score suggests a common technique, but the potential for persistent access makes it a significant threat.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the “Office Test” registry key (HKCU\Software\Microsoft\Office Test\Special\Perf\*).
Enable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.
Monitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.
Implement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.

Suspicious Alternate Data Stream (ADS) File Creation

hello@craftedsignal.io — Fri, 26 Jan 2024 18:00:00 +0000

This detection focuses on identifying the creation of Alternate Data Streams (ADS) on Windows systems, a technique often employed by adversaries to conceal malicious code or data within seemingly benign files. Attackers leverage scripting engines and command interpreters to write ADS to various file types, including executables, documents, and media files. This activity is uncommon in legitimate workflows, making it a valuable indicator of potential compromise. The rule is designed to trigger on file creation events where the process creating the file is a known script or command interpreter (cmd.exe, powershell.exe, etc.) and the target file has a suspicious extension. The detection excludes common legitimate ADS usage patterns. This technique is used for defense evasion, allowing malware to persist without being easily detected by traditional security measures.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker uses a command interpreter (cmd.exe, powershell.exe, etc.) or scripting engine (wscript.exe, cscript.exe) to execute malicious code.
The malicious code creates an Alternate Data Stream (ADS) on a targeted file (e.g., an executable, document, or image). The targeted file’s extension could be pdf, dll, exe, dat, etc.
The attacker hides malicious code or data within the ADS, making it less visible to standard file system scans and security tools. The ADS is written to a file path using the C:\\*:\* syntax.
The attacker may rename or clean up any staging files to further conceal their activity.
The attacker can then execute the hidden code within the ADS, or use the ADS to store configuration data for later use.
The attacker maintains persistence by using the ADS to store and execute malicious code, bypassing typical file-based security measures.
The ultimate goal is to maintain unauthorized access to the system, potentially leading to data exfiltration, lateral movement, or other malicious activities.

Impact

Successful exploitation allows attackers to hide malicious code within legitimate files, evading detection by traditional security measures. This can lead to prolonged persistence on compromised systems, enabling data theft, ransomware deployment, or other malicious activities. While the specific number of victims is unknown, this technique is broadly applicable across Windows environments, potentially affecting a wide range of organizations.

Recommendation

Deploy the Sigma rule Suspicious ADS File Creation via Cmd to detect ADS creation events initiated by cmd.exe.
Deploy the Sigma rule Suspicious ADS File Creation via PowerShell to detect ADS creation events initiated by powershell.exe.
Enable Sysmon Event ID 15 (FileCreateStreamHash) to provide detailed information about ADS creation events, as referenced in the rule’s setup instructions.
Investigate any alerts generated by these rules, focusing on the file paths, creating processes, and command-line arguments involved, as detailed in the rule’s triage and analysis notes.

Group Policy Discovery via Microsoft GPResult Utility

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

Attackers may leverage the gpresult.exe utility, a built-in Windows tool, to gather information about Group Policy Objects (GPOs) within an Active Directory environment. This reconnaissance activity allows adversaries to understand the existing security policies, identify potential misconfigurations, and discover pathways for privilege escalation or lateral movement. The rule focuses on detecting the execution of gpresult.exe with specific command-line arguments (/z, /v, /r, /x) commonly associated with malicious reconnaissance. This behavior is typically observed after an initial compromise, where the attacker is attempting to map out the network and identify valuable targets. This activity matters for defenders as it provides an early indicator of post-compromise activity and can help prevent further damage.

Attack Chain

The attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
The attacker executes gpresult.exe from the command line or through a script.
The attacker uses command-line arguments such as /z, /v, /r, or /x to request detailed information about Group Policy settings.
gpresult.exe queries the Active Directory domain to retrieve GPO information applicable to the user or computer.
The attacker parses the output of gpresult.exe to identify security policies, user rights assignments, and other relevant configurations.
The attacker identifies potential weaknesses in the GPO configuration, such as overly permissive user rights or insecure password policies.
The attacker uses the gathered information to exploit identified weaknesses and escalate privileges or move laterally to other systems within the network.
The attacker achieves their objective, such as data exfiltration, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a comprehensive understanding of the target environment’s security posture, enabling attackers to identify and exploit weaknesses for privilege escalation and lateral movement. While the source does not specify a number of victims or sectors targeted, the impact of a successful attack can range from data breaches and financial losses to reputational damage and disruption of operations. The discovery of misconfigured group policies can open doors for attackers to compromise critical systems and data within the network.

Recommendation

Deploy the Sigma rule “Group Policy Discovery via GPResult” to your SIEM to detect the execution of gpresult.exe with suspicious parameters.
Enable Windows process creation logging to capture command-line arguments used with gpresult.exe and other executables.
Review and harden Group Policy configurations to minimize the risk of exploitation by attackers.
Investigate any alerts generated by the Sigma rule “Group Policy Discovery via GPResult” to determine the context and intent of the activity.

Detection of Malicious Browser Extension Installation

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

This detection rule identifies the installation of browser extensions on Windows systems, which can be a sign of malicious activity. Threat actors may install malicious browser extensions through app store downloads disguised as legitimate extensions, social engineering tactics, or by directly compromising a system. These extensions can then be used for persistence, data theft, or other malicious purposes. The rule focuses on monitoring file creation events related to browser extension installations, specifically targeting the file paths and types associated with Firefox (.xpi) and Chromium-based browsers (.crx). It excludes known safe processes and extensions to reduce false positives. This detection is relevant for defenders because malicious browser extensions can provide a persistent foothold for attackers, allowing them to maintain access to compromised systems and user data. The rule is based on EQL and can be used with Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon data.

Attack Chain

The user’s system is compromised, potentially through social engineering or existing malware.
The attacker gains access to the system and attempts to install a malicious browser extension.
The attacker drops the extension file (.xpi for Firefox, .crx for Chromium) into the appropriate browser extension directory (e.g., C:\\Users\\*\\AppData\\Roaming\\*\\Profiles\\*\\Extensions\\ for Firefox or C:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\Webstore Downloads\\ for Chromium).
A file creation event is triggered as the extension file is created in the target directory.
The detection rule identifies this file creation event based on the file name and path, filtering out known safe processes like firefox.exe.
The malicious extension installs itself into the browser.
The extension gains persistence by loading every time the browser starts.
The attacker can now perform malicious actions such as monitoring browsing activity, stealing credentials, or injecting malicious content into web pages.

Impact

A successful attack using malicious browser extensions can lead to persistent access to the compromised system, allowing attackers to steal sensitive information such as credentials, financial data, or personal information. This can result in financial loss, identity theft, and reputational damage. The installation of malicious extensions can also lead to the injection of malicious content into web pages, redirecting users to phishing sites or distributing malware. The scope of the impact can range from individual users to entire organizations, depending on the extent of the compromise.

Recommendation

Enable Sysmon Event ID 11 (File Create) logging to capture the necessary file creation events for this detection.
Deploy the provided Sigma rule Browser Extension Install via File Creation to your SIEM and tune the exclusions for your specific environment.
Review and update the list of known safe processes and extensions in the Sigma rule Browser Extension Install via File Creation to minimize false positives.
Implement application whitelisting policies to restrict the installation of unauthorized browser extensions.
Educate users on the risks associated with installing browser extensions from untrusted sources and encourage them to only install extensions from official browser stores.
Implement policies to regularly review installed browser extensions across the organization.

Unusual Network Connection via RunDLL32

hello@craftedsignal.io — Fri, 26 Jan 2024 10:00:00 +0000

Attackers often abuse the rundll32.exe utility to execute malicious Dynamic Link Libraries (DLLs), blending their activity with legitimate system operations. This detection identifies instances where rundll32.exe establishes outbound network connections, particularly when executed without command-line arguments. Such behavior deviates from typical usage and may indicate command and control (C2) activity or other malicious actions. The rule is designed to detect command and control activity where adversaries are using rundll32.exe without arguments to make external network connections. The rule uses data from Elastic Defend, Sysmon, and SentinelOne to detect this behavior. The rule specifically excludes connections to well-known private and reserved IP ranges to reduce false positives.

Attack Chain

An attacker gains initial access to a Windows system, possibly through phishing or exploiting a software vulnerability.
The attacker attempts to execute a malicious DLL using rundll32.exe without specifying arguments, which is an anomaly.
rundll32.exe is invoked with a command line resembling: rundll32.exe .
The malicious DLL initiates an outbound network connection to an external IP address.
The network connection attempts to bypass firewall rules by masquerading as a legitimate system process.
The attacker uses this connection to establish a command and control channel.
Data exfiltration or further exploitation activities occur over the established C2 channel.
The attacker achieves their final objective, such as data theft, ransomware deployment, or system compromise.

Impact

Successful exploitation allows attackers to establish command and control channels on compromised systems, leading to potential data exfiltration, lateral movement within the network, and deployment of ransomware. This can result in significant financial losses, reputational damage, and disruption of business operations. The impact is broad, affecting any Windows environment where rundll32.exe is used.

Recommendation

Deploy the Sigma rule Detect Unusual Network Connection via RunDLL32 to your SIEM and tune for your environment to detect unusual network connections made by rundll32.exe.
Enable Sysmon process creation and network connection logging to capture necessary events for the Sigma rule.
Investigate any alerts generated by the Sigma rule, focusing on the parent processes of rundll32.exe and the destination IP addresses of the network connections.
Review and harden firewall rules to prevent unauthorized outbound connections from system processes like rundll32.exe.
Implement application control policies to restrict the execution of unsigned or untrusted DLLs via rundll32.exe.

Unusual Executable File Creation by a System Critical Process

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

This detection rule identifies anomalous creation or modification of executable files by critical Windows system processes, like smss.exe, csrss.exe, and lsass.exe. Attackers may attempt to leverage these processes to evade detection, and the rule is designed to detect such activities. The rule leverages data from Elastic Defend, Microsoft Defender XDR, SentinelOne, CrowdStrike, and Sysmon. It provides investigation steps to help analysts triage and analyze potential incidents, focusing on the identity of the writing process, its lineage, and the characteristics of the written file. This rule is designed to detect potential remote code execution or other forms of exploitation targeting Windows systems. The rule logic excludes specific legitimate file paths to minimize false positives.

Attack Chain

An attacker gains initial access to the system through methods such as phishing or exploiting a vulnerability.
The attacker executes code on the system.
The attacker attempts to escalate privileges.
The attacker leverages a system critical process to create or modify an executable file.
The created/modified file may be a backdoor, malware component, or a tool for further exploitation.
The attacker uses the created executable to establish persistence.
The attacker uses the newly created executable to perform lateral movement.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution with elevated privileges. The number of victims is dependent on the scope of the initial compromise. The targeted sectors include any organization running vulnerable Windows systems. If the attack succeeds, the adversary can gain full control over the system, leading to data theft, system disruption, or further propagation of malware.

Recommendation

Deploy the “Unusual Executable File Creation by a System Critical Process” detection rule to your SIEM and tune for your environment.
Enable Sysmon file creation logging (Event ID 11) to enhance detection capabilities (see setup instructions in the rule source).
Investigate any alerts generated by this rule, paying close attention to the writing process’s identity, lineage, and the characteristics of the written file as detailed in the rule’s triage and analysis section.
Correlate alerts from this rule with other endpoint and network activity to identify the scope of the potential compromise.

Detecting Rare SMB Connections for Potential NTLM Credential Theft

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

This detection strategy focuses on identifying unusual Server Message Block (SMB) traffic that originates from internal IP addresses and connects to external networks. The SMB protocol, commonly used for file and printer sharing within a network, can be exploited to exfiltrate data by injecting rogue UNC paths to capture NTLM credentials. This activity is often associated with threat actors attempting to steal credentials for lateral movement or data exfiltration. Defenders should be aware of this technique as it allows adversaries to bypass traditional security controls by leveraging a legitimate protocol for malicious purposes. This detection is relevant for environments utilizing Windows operating systems and SMB for internal network communications. The goal is to identify and alert on SMB connections to external IPs, excluding known safe ranges and legitimate business applications.

Attack Chain

An attacker compromises an internal system via phishing or other means (not detailed in source).
The attacker injects a rogue UNC path into a document, email, or other medium.
A user opens the malicious document or clicks the injected link, triggering an SMB connection to a malicious external server.
The SMB connection attempts to authenticate with the user’s NTLM credentials.
The attacker captures the NTLM hash from the authentication attempt.
The attacker attempts to crack the NTLM hash to obtain the user’s password.
Using the cracked password, the attacker gains unauthorized access to other systems and resources on the network.

Impact

Successful exploitation can lead to credential theft, allowing attackers to gain unauthorized access to sensitive data and systems within the organization. This can result in data breaches, financial losses, and reputational damage. The impact is significant because SMB is a common protocol within many Windows environments, making this technique highly effective if not properly monitored.

Recommendation

Deploy the Sigma rule “Detect SMB Connection to External IP” to your SIEM to identify potentially malicious SMB connections to the internet. Tune the rule by excluding known good external IPs used by legitimate services.
Enable Sysmon Event ID 3 (Network Connection) with proper filtering to capture SMB traffic details as recommended in the linked setup guide, to enhance the fidelity of the detection.
Implement network segmentation to restrict SMB traffic to only necessary internal communications, reducing the attack surface and mitigating the risk of external exposure.

Windows Script Execution from Archive File

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

Attackers commonly use archive files (ZIP, RAR, 7z) to deliver malicious scripts, such as JScript and VBScript, to Windows systems. This technique allows them to bypass some initial security checks and deliver payloads that can execute arbitrary code. The “Windows Script Execution from Archive” detection identifies instances where Windows Script Host (wscript.exe) is launched from temporary directories containing extracted archive contents. This activity can indicate a user has opened a malicious archive, leading to potential malware execution. This detection focuses on the parent-child process relationship, where explorer.exe, winrar.exe, or 7zFM.exe spawns wscript.exe to execute scripts from the temp directory.

Attack Chain

A user receives a malicious archive file (e.g., ZIP, RAR, 7z) via email or downloads it from a website.
The user opens the archive file using a file archiver tool like Explorer, WinRAR, or 7-Zip.
The archiver extracts the contents, including a malicious JScript (.js) or VBScript (.vbs) file, to a temporary directory, such as \Users\*\AppData\Local\Temp\7z*\.
The user (or the archiver tool) inadvertently executes the extracted script using Windows Script Host (wscript.exe).
Wscript.exe executes the malicious script, which may perform a variety of actions, such as downloading and executing additional payloads.
The script establishes persistence via registry modification, adding a run key to execute upon system startup.
The script connects to a command-and-control server to receive further instructions.
The attacker gains control of the compromised system and begins lateral movement.

Impact

A successful attack of this nature can lead to arbitrary code execution on the victim’s machine, potentially resulting in data theft, malware installation, or complete system compromise. While the number of affected organizations is not specified, the technique is broadly applicable to any Windows environment where users handle archive files, potentially affecting numerous individuals and organizations across various sectors.

Recommendation

Enable process creation logging with command line arguments to capture the execution of wscript.exe and its arguments.
Deploy the Sigma rule “Detect Script Execution from Archive” to your SIEM to identify suspicious script execution patterns.
Monitor process activity for wscript.exe and other scripting engines executing from temporary directories.
Configure endpoint security solutions to block execution of scripts from common temporary directories.

Credential Acquisition via Registry Hive Dumping

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

This detection identifies attempts to export registry hives containing sensitive credential information using the Windows reg.exe utility. Attackers may target the HKLM\SAM and HKLM\SECURITY hives to extract stored credentials, including password hashes and LSA secrets. The activity is often part of a broader credential access campaign. The rule focuses on detecting the execution of reg.exe with specific arguments indicating an attempt to save or export these critical registry hives. The use of reg.exe makes this technique accessible to various threat actors, including ransomware groups and nation-state actors. Defenders need to monitor for this activity to prevent unauthorized credential access and potential lateral movement within the network. This rule specifically looks for “save” and “export” arguments targeting SAM and SECURITY hives.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker executes reg.exe from the command line or through a script.
The reg.exe command includes arguments to save or export registry hives.
The target registry hives are HKLM\SAM and HKLM\SECURITY, containing sensitive credential information.
The exported registry hive is saved to a file on disk or a network share.
The attacker may compress or encrypt the exported registry hive to evade detection.
The attacker retrieves the exported registry hive for offline analysis.
The attacker extracts credential information from the registry hive, such as password hashes and LSA secrets, to use in lateral movement or privilege escalation.

Impact

Successful exploitation allows attackers to acquire sensitive credentials stored within the registry. This can lead to lateral movement within the network, privilege escalation, and ultimately, data exfiltration or system compromise. Compromised credentials can be used to access critical systems and data, causing significant damage to the organization. The impact is considered high due to the potential for widespread access and control over the compromised environment.

Recommendation

Enable process creation auditing with command line arguments to capture the execution of reg.exe with relevant arguments. (Data Source: Windows Security Event Logs, Sysmon)
Deploy the Sigma rule Detect Registry Hive Export via Reg.exe to your SIEM to detect the execution of reg.exe with arguments indicative of registry hive dumping.
Implement access controls and monitor file system activity to detect unauthorized access or modification of registry hive files.
Review and restrict the use of reg.exe to authorized personnel and processes.
Monitor for parent processes of reg.exe that are unusual or unexpected, which might indicate malicious activity.
Investigate any alerts generated by the Sigma rule by reviewing the process command line, parent process, and destination of the exported registry hive.

Windows Sandbox Abuse with Sensitive Configuration

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

Attackers may abuse the Windows Sandbox feature to evade detection by running malicious code within the isolated environment. This involves configuring the sandbox with sensitive options such as granting write access to the host file system, enabling network connections, and setting up automatic command execution via logon. By running within the sandbox with these configurations, malware can potentially interact with the host system, while making detection more difficult. This technique is used for defense evasion, hiding artifacts, and executing malicious activities within a virtualized environment to avoid direct exposure on the host. The rule identifies the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command.

Attack Chain

An attacker gains initial access to the system through an exploit or social engineering.
The attacker leverages Windows Sandbox by executing wsb.exe or WindowsSandboxClient.exe.
The attacker configures the sandbox to enable networking using Enable or true.
The attacker grants the sandbox write access to the host file system using C:\\false.
The attacker sets up a logon command to automatically execute malicious code when the sandbox starts using .
The sandbox initializes and executes the configured logon command.
The malicious code interacts with the host file system and network, performing actions such as data exfiltration or lateral movement.
The attacker achieves their objective, such as deploying ransomware or stealing sensitive information, while operating from within the isolated sandbox environment.

Impact

A successful attack using Windows Sandbox abuse can lead to a range of negative impacts. Attackers may gain unauthorized access to sensitive data, compromise system integrity, or disrupt business operations. The use of the sandbox environment helps to conceal malicious activity, making detection and remediation more challenging. The damage can include data breaches, financial losses, reputational damage, and regulatory penalties. Successful exploitation allows malware to interact with the host system, potentially affecting multiple systems on the network.

Recommendation

Deploy the “Windows Sandbox with Sensitive Configuration” detection rule to your SIEM to identify potential sandbox abuse attempts.
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that enable networking (Enable, true).
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that enable write access to the host file system (C:\\false).
Monitor process creation events for wsb.exe and WindowsSandboxClient.exe with command-line arguments that define logon commands ().
Enable Sysmon process creation logging (Event ID 1) to capture the necessary command-line arguments.

Microsoft Build Engine Started by an Office Application

hello@craftedsignal.io — Tue, 09 Jan 2024 18:22:00 +0000

The Microsoft Build Engine (MSBuild) is a software build platform commonly used by Windows developers. When MSBuild is started by an Office application like Word or Excel, it deviates from typical usage patterns. This behavior can be indicative of a malicious document executing a script payload as part of a defense evasion tactic. Attackers may leverage MSBuild to execute code or perform actions that would otherwise be blocked or detected. This activity is particularly concerning because it can bypass traditional security measures that focus on blocking suspicious executables or scripts directly launched by Office applications. The rule was created in March 2020, and last updated in April 2026.

Attack Chain

A user opens a malicious Office document (e.g., Word, Excel, PowerPoint).
The Office document contains an embedded macro or exploit that triggers the execution of MSBuild.exe.
MSBuild.exe is launched as a child process of the Office application (e.g., winword.exe, excel.exe, powerpnt.exe).
MSBuild executes a project file or inline task specified in the command line. This can involve compiling code, executing scripts, or performing other actions.
The executed code or script performs malicious activities, such as downloading additional payloads, modifying system settings, or establishing persistence.
MSBuild may spawn child processes, such as cmd.exe, powershell.exe, or other utilities, to further execute malicious commands.
The attacker achieves their objective, which could include data exfiltration, installing malware, or gaining unauthorized access to the system.

Impact

Successful exploitation can lead to the execution of arbitrary code on the victim’s machine, potentially resulting in data theft, malware installation, or complete system compromise. Since MSBuild is a legitimate Microsoft tool, its use by malicious actors can make detection more challenging. The impact is high because it leverages a trusted process to carry out malicious activities, evading standard security measures.

Recommendation

Deploy the Sigma rule “Microsoft Build Engine Started by an Office Application” to your SIEM to detect this specific behavior based on process creation events.
Enable Sysmon process creation logging with the appropriate configuration to capture the necessary process start events for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on the command-line arguments of MSBuild.exe and the parent process information, including the executable name and command line.
Monitor process execution events for MSBuild.exe with parent processes being Office applications as a high priority indicator of potential compromise.
Review and harden Office macro settings to prevent execution of malicious macros.

Potential Local NTLM Relay via HTTP

hello@craftedsignal.io — Tue, 09 Jan 2024 14:00:00 +0000

This detection identifies attempts to coerce local NTLM authentication over HTTP through WebDAV named-pipe paths, focusing on Print Spooler and SRVSVC. Attackers can exploit this vulnerability, often combined with tools like NTLMRelay2Self, PetitPotam, or modified versions of krbrelayx’s printerbug.py, to relay the obtained credentials and escalate their privileges within the network. This technique allows attackers to bypass traditional security measures by leveraging legitimate Windows protocols for malicious purposes. Successful exploitation can lead to domain dominance and unauthorized access to sensitive resources. This activity is often associated with post-exploitation activity following initial access via other means.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes rundll32.exe to load davclnt.dll using the DavSetCookie function.
The rundll32.exe process is invoked with arguments specifying a named pipe path over HTTP, such as http*/print/pipe/*, http*/pipe/spoolss, or http*/pipe/srvsvc.
The system attempts to authenticate to the specified HTTP endpoint using NTLM.
The attacker intercepts the NTLM authentication request.
Using a relay tool like NTLMRelay2Self or ntlmrelayx, the attacker relays the captured NTLM credentials to another service or machine.
The attacker leverages the relayed credentials to escalate privileges or gain unauthorized access to network resources.
The attacker may then perform lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation allows attackers to escalate privileges within the compromised system and potentially the entire domain. This can lead to unauthorized access to sensitive data, deployment of ransomware, or other destructive activities. The impact ranges from data breaches and financial losses to complete system compromise. Depending on the targeted accounts, the attacker may be able to achieve domain administrator privileges.

Recommendation

Deploy the Sigma rule “Potential Local NTLM Relay via HTTP” to your SIEM to detect the execution of rundll32.exe with specific arguments indicative of NTLM relay attempts.
Enable Sysmon process creation logging to ensure the necessary data is available for the Sigma rule to function correctly.
Monitor network connections originating from processes that load davclnt.dll to identify potential NTLM relay traffic.
Investigate and block the usage of tools like NTLMRelay2Self, PetitPotam, and ntlmrelayx within the environment.
Implement mitigations for NTLM relay attacks, such as enabling Extended Protection for Authentication (EPA) and disabling NTLM where possible.
Review and restrict the usage of WebClient service and Print Spooler service where not required.

Persistence via Scheduled Job Creation

hello@craftedsignal.io — Tue, 09 Jan 2024 12:00:00 +0000

Adversaries may abuse scheduled tasks to maintain persistence on a compromised system. This involves creating or modifying scheduled tasks to execute malicious code at specific times or intervals. This activity can be used to ensure that the attacker’s code remains active even after a system restart or user logout. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes to flag potential abuse. The rule is designed for data generated by Elastic Defend, but also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
The attacker attempts to establish persistence.
The attacker uses a script or program to create a new scheduled job within the C:\Windows\Tasks\ directory.
The scheduled job is configured to execute a malicious payload at a specified time or interval.
The malicious payload could be a script (e.g., PowerShell) or an executable.
The scheduled job executes, triggering the malicious payload.
The attacker maintains persistent access to the system.
The attacker performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to maintain a persistent presence on the compromised system. This allows them to execute malicious code, steal sensitive information, or perform other malicious activities over an extended period. The number of affected systems can vary depending on the scope of the initial compromise and the attacker’s objectives.

Recommendation

Enable Sysmon Event ID 11 (File Create) logging to monitor file creation events on Windows systems.
Deploy the Sigma rule “Detect Suspicious Scheduled Job Creation” to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on scheduled jobs created in the C:\Windows\Tasks\ directory with a “.job” extension.
Review and update exclusion lists for known legitimate scheduled job creation processes (e.g., CCleaner, ManageEngine) to minimize false positives.

Suspicious WerFault Child Process Abuse

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

This detection identifies suspicious child processes spawned by WerFault.exe, the Windows Error Reporting tool. Attackers can abuse WerFault by manipulating the SilentProcessExit registry key to execute malicious processes. This technique allows for defense evasion, persistence, and privilege escalation. The detection focuses on WerFault processes with specific command-line arguments (-s, -t, and -c) known to be used in SilentProcessExit exploitation, while excluding legitimate executables like Initcrypt.exe and Heimdal.Guard.exe. The rule helps defenders identify potential attempts to hijack the error reporting mechanism for malicious purposes. The monitored data sources include Windows Event Logs, Sysmon, Elastic Defend, Microsoft Defender XDR, and SentinelOne.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker modifies the SilentProcessExit registry key to specify a malicious process to be executed when a target application crashes. This involves setting the ReportingMode and Debugger values under the SilentProcessExit key for the target application.
The attacker triggers a crash in the target application or waits for a legitimate crash to occur.
WerFault.exe is invoked to handle the application crash.
Due to the registry modification, WerFault.exe spawns the attacker-controlled process, passing command-line arguments such as -s, -t, and -c.
The attacker-controlled process executes with the privileges of WerFault.exe, potentially achieving privilege escalation.
The malicious process performs actions such as injecting code into other processes, establishing persistence, or exfiltrating data.
The attacker achieves their objectives, such as maintaining persistence, escalating privileges, or evading detection.

Impact

A successful attack can lead to persistence, privilege escalation, and defense evasion. Attackers can use this technique to execute malicious code with elevated privileges, potentially bypassing security controls and gaining unauthorized access to sensitive data and system resources. The number of victims and affected sectors can vary depending on the attacker’s objectives and the scope of the initial compromise.

Recommendation

Enable Sysmon process creation logging to capture WerFault.exe child processes (Data Source: Sysmon).
Deploy the Sigma rule “WerFault Child Process Masquerading” to your SIEM and tune for your environment.
Review the SilentProcessExit registry key for unauthorized modifications (registry_set event).
Investigate any WerFault.exe processes with command-line arguments -s, -t, and -c (process_creation event).

Detection of Custom Shim Database Installation for Persistence

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

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

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
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\.
The attacker writes a malicious .sdb file containing the custom shim database to a location on disk.
The registry entry created points to the malicious .sdb file.
When a targeted application is launched, Windows checks the AppCompatFlags registry keys.
The system loads the malicious shim database specified in the registry.
The malicious code within the shim database is executed in the context of the targeted application.
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.

Unusual Service Host Child Process - Childless Service

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

The Windows Service Host process (svchost.exe) is a critical system component that hosts multiple Windows services to optimize resource utilization. Certain services running under svchost.exe are not expected to spawn child processes. Attackers may inject malicious code into these “childless” svchost processes to execute unauthorized commands and evade traditional detection methods. This detection rule identifies anomalies by monitoring child processes of svchost.exe instances associated with services known to be childless, such as WdiSystemHost, LicenseManager, and StorSvc, flagging potential process injection or exploitation attempts. The rule aims to identify deviations from the expected behavior of these services, providing an early warning of potential malicious activity.

Attack Chain

Attacker gains initial access to the system through an exploit or by leveraging existing credentials.
The attacker injects malicious code into a running svchost.exe process associated with a childless service like WdiSystemHost or StorSvc.
The injected code spawns a child process from the targeted svchost.exe instance. This could involve executing a system utility or a custom payload.
The child process executes commands or performs actions dictated by the injected code, such as establishing a reverse shell or downloading additional payloads.
The attacker uses the spawned process to perform reconnaissance activities, gathering information about the system and network.
The attacker escalates privileges, potentially leveraging vulnerabilities or misconfigurations accessible from the compromised svchost process.
The attacker moves laterally to other systems on the network, using the compromised system as a pivot point.
The attacker achieves their final objective, which may include data exfiltration, ransomware deployment, or establishing persistent access.

Impact

Successful exploitation can lead to privilege escalation, allowing attackers to gain control of the compromised system and potentially the entire network. Attackers can use the compromised system as a staging ground for further attacks, exfiltrate sensitive data, deploy ransomware, or disrupt critical services. The medium severity score reflects the potential for significant impact if the activity is not detected and contained promptly.

Recommendation

Deploy the Sigma rule Unusual Svchost Child Process - Childless Service to your SIEM to detect potential process injection attacks targeting svchost.exe.
Tune the rule by adding known false positives to the exclusion list, such as WerFault.exe, WerFaultSecure.exe, and wermgr.exe to reduce alert fatigue.
Enable process creation logging via Sysmon (Event ID 1) with command line details for better visibility into spawned processes, as described in the setup guide.
Investigate any alerts generated by the rule, focusing on the process details and parent-child relationships to determine the legitimacy of the spawned process.
Consider using endpoint detection and response (EDR) solutions like Elastic Defend for enhanced visibility and automated response capabilities, as the rule is designed for data generated by Elastic Defend.

UAC Bypass via DiskCleanup Scheduled Task Hijack

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

This rule identifies User Account Control (UAC) bypass attempts via hijacking the DiskCleanup Scheduled Task. Attackers exploit this method to execute code with elevated privileges, bypassing standard security controls. The technique involves leveraging the cleanmgr.exe or taskhostw.exe executables with specific arguments (/autoclean and /d) outside of their expected paths. This allows attackers to run malicious code under the guise of a legitimate system process, making detection more challenging. This technique is used to gain elevated privileges on a compromised system, allowing for further malicious activities.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a software vulnerability).
The attacker modifies or creates a scheduled task to execute cleanmgr.exe or taskhostw.exe with the /autoclean and /d arguments.
The modified scheduled task is triggered, executing the specified executable with the supplied arguments.
The executable, such as cleanmgr.exe, attempts to run Disk Cleanup.
If the executable path is outside the standard locations (e.g., C:\\Windows\\System32 or C:\\Windows\\SysWOW64), it indicates a potential hijack.
Malicious code is executed with elevated privileges due to the UAC bypass.
The attacker uses these elevated privileges to install malware, modify system settings, or perform other malicious activities.

Impact

Successful exploitation allows attackers to bypass User Account Control (UAC) and execute code with elevated privileges. This can lead to the installation of malware, modification of system settings, data theft, and other malicious activities. While the exact number of victims is unknown, this technique is effective on systems where UAC is enabled but misconfigured or vulnerable.

Recommendation

Deploy the Sigma rule “UAC Bypass via DiskCleanup with Suspicious Path” to your SIEM and tune for your environment to detect UAC bypass attempts.
Deploy the Sigma rule “UAC Bypass via DiskCleanup and Taskhostw” to your SIEM to detect UAC bypass attempts.
Monitor process creation events for cleanmgr.exe and taskhostw.exe with the /autoclean and /d arguments, focusing on executions outside the standard system directories.
Review and harden scheduled tasks to prevent unauthorized modifications.
Ensure that UAC settings are properly configured and enforced across the organization.

Disable Windows Event and Security Logs Using Built-in Tools

hello@craftedsignal.io — Thu, 04 Jan 2024 10:00:00 +0000

Attackers often disable Windows Event and Security Logs to evade detection on compromised systems. This activity involves tampering with, clearing, and deleting event log data to break SIEM detections, cover their tracks, and slow down incident response. The methods employed include using the logman utility, PowerShell commands to disable the EventLog service, or auditpol to disable auditing. These actions are typically performed after initial access and privilege escalation to hinder forensic investigations and maintain persistence within the environment. Defenders should monitor for these specific tools and command-line arguments to identify potential attempts to disable logging.

Attack Chain

The attacker gains initial access to the system, possibly through phishing or exploiting a vulnerability.
The attacker escalates privileges to administrator level to gain the necessary permissions to modify event logging settings.
The attacker uses logman.exe with arguments to stop or delete EventLog traces (e.g., logman.exe stop EventLog-*, logman.exe delete EventLog-*).
Alternatively, the attacker uses PowerShell with Set-Service cmdlet to disable the EventLog service (e.g., powershell.exe Set-Service EventLog -StartupType Disabled).
The attacker can also use auditpol.exe to disable auditing policies, preventing future events from being logged (e.g., auditpol.exe /success:disable).
After disabling logging, the attacker performs malicious activities such as lateral movement, data exfiltration, or malware deployment, with a reduced risk of detection.
The attacker removes traces of their activity from other logs if possible.
The attacker maintains persistence and continues to exploit the compromised environment.

Impact

Successful disabling of Windows Event and Security Logs can severely hinder incident response and forensic investigations. The absence of log data makes it difficult to detect ongoing malicious activity, understand the scope of the compromise, and attribute the attack. This can lead to prolonged dwell time for attackers, increased data exfiltration, and greater overall damage to the organization.

Recommendation

Deploy the Sigma rule “Disable Windows Event and Security Logs Using Built-in Tools” to your SIEM to detect the execution of logman.exe, PowerShell, and auditpol.exe with specific arguments related to disabling event logs.
Monitor process creation events for logman.exe, powershell.exe, pwsh.exe, powershell_ise.exe, and auditpol.exe with command-line arguments that indicate an attempt to disable event logging.
Enable Sysmon process creation logging to capture detailed command-line arguments for process monitoring.
Regularly review and audit Group Policy settings related to event logging to prevent unauthorized modifications.
Monitor for changes to the EventLog service configuration, including startup type and status, using system monitoring tools.

Incoming Execution via PowerShell Remoting

hello@craftedsignal.io — Wed, 03 Jan 2024 18:53:23 +0000

This detection identifies potential lateral movement through the exploitation of Windows PowerShell remoting. PowerShell remoting is a feature that enables administrators and attackers to execute commands on remote Windows systems. The detection focuses on identifying incoming network connections on ports 5985 (HTTP) and 5986 (HTTPS), the default ports used for PowerShell Remoting, followed by the execution of processes spawned by wsmprovhost.exe, the Windows Remote Management process host. This activity, when originating from unexpected sources, may indicate unauthorized access and lateral movement within a network. The rule is designed to detect suspicious activity by monitoring network traffic and process execution, flagging potential unauthorized remote executions, and enabling security teams to respond swiftly.

Attack Chain

An attacker gains initial access to a network, possibly through phishing or exploiting a vulnerability on an internet-facing system.
The attacker leverages PowerShell remoting to initiate a connection to a target system on ports 5985 or 5986.
The target system accepts the incoming PowerShell Remoting connection.
The wsmprovhost.exe process is launched on the target system to facilitate the remote PowerShell session.
The attacker executes commands remotely, spawning child processes from wsmprovhost.exe.
The attacker attempts to escalate privileges or move laterally to other systems within the network using the remote PowerShell session.
The attacker uses tools such as net.exe or PsExec over the remote PowerShell session to further propagate.
The attacker achieves their objective, such as data exfiltration or deploying ransomware, by leveraging the established remote session.

Impact

Successful exploitation of PowerShell Remoting for lateral movement can lead to widespread compromise within an organization. An attacker could gain control over multiple systems, potentially leading to data breaches, system outages, or ransomware deployment. The number of affected systems could range from a few critical servers to a significant portion of the network, depending on the attacker’s objectives and the organization’s security posture. The impact could include financial losses, reputational damage, and disruption of business operations.

Recommendation

Deploy the Sigma rule Incoming Execution via PowerShell Remoting to your SIEM to detect suspicious PowerShell remoting activity and tune for your environment.
Monitor network connections to ports 5985 and 5986, and investigate any unauthorized or unexpected traffic using the network_connection log source.
Investigate processes spawned by wsmprovhost.exe for unusual or malicious activity using the process_creation log source.
Whitelist authorized administrative IP addresses or user accounts that frequently perform remote management tasks, as mentioned in the false positives analysis.
Review and document automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance, then create exceptions for their specific process names or execution paths.

Symbolic Link Creation to Shadow Copies for Credential Access

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

This rule identifies the creation of symbolic links to shadow copies on Windows systems. Attackers use this technique to gain access to sensitive files stored within shadow copies, including the ntds.dit file (containing password hashes), system boot keys, and browser offline credentials. This approach allows them to bypass normal file access controls and extract credentials for lateral movement or privilege escalation. The detection rule is designed to ingest data from various sources, including Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs, providing broad coverage across different endpoint security solutions. The activity is typically initiated by command-line tools like cmd.exe or powershell.exe, making detection through process monitoring feasible. This technique is particularly relevant as it targets credential dumping, a critical stage in many attack campaigns.

Attack Chain

An attacker gains initial access to a Windows system, possibly through phishing or exploitation of a vulnerability.
The attacker elevates privileges to gain administrative rights, which are required to create shadow copies and symbolic links.
The attacker creates a volume shadow copy using vssadmin.exe or similar tools.
The attacker uses mklink command or PowerShell New-Item -ItemType SymbolicLink to create a symbolic link to the shadow copy path.
The symbolic link points to a directory within the shadow copy containing sensitive files like ntds.dit or browser credential stores.
The attacker copies the targeted sensitive files (e.g., ntds.dit) from the shadow copy using the symbolic link.
The attacker removes the shadow copy to cover their tracks, although the symbolic link creation remains as evidence.
The attacker extracts credentials from the copied ntds.dit file offline for use in lateral movement or further attacks.

Impact

Successful exploitation allows attackers to gain unauthorized access to sensitive credentials stored on the compromised system. This can lead to lateral movement within the network, privilege escalation, and ultimately, the compromise of critical assets. If the ntds.dit file is accessed, the entire Active Directory domain could be at risk, potentially affecting thousands of users and systems. This type of attack is particularly damaging as it allows attackers to operate undetected for extended periods while they harvest credentials.

Recommendation

Deploy the provided Sigma rule “Symbolic Link to Shadow Copy Created via Cmd” to detect the creation of symbolic links to shadow copies via cmd.exe (rules).
Deploy the provided Sigma rule “Symbolic Link to Shadow Copy Created via PowerShell” to detect the creation of symbolic links to shadow copies via powershell.exe (rules).
Enable Sysmon Event ID 1 (Process Creation) logging to provide necessary data for the Sigma rules to function correctly (setup).
Review the “Investigating Symbolic Link to Shadow Copy Created” section in the rule’s notes for triage and analysis steps when the rule triggers.
Monitor for the usage of mklink command with the HarddiskVolumeShadowCopy argument in process command lines.

InstallUtil Process Making Network Connections for Defense Evasion

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

InstallUtil.exe is a legitimate Windows utility used for installing and uninstalling server resources. Adversaries abuse InstallUtil.exe to execute malicious code under the guise of legitimate processes, often to evade detection. This technique allows attackers to proxy execution through a trusted system binary, potentially bypassing application control and security monitoring. The detection rule identifies suspicious network activity by monitoring InstallUtil.exe’s outbound connections, flagging potential misuse by alerting on the initial network connection attempt. This activity is detected via the Elastic EQL rule “InstallUtil Process Making Network Connections.”

Attack Chain

An attacker gains initial access through an undisclosed method.
The attacker uses InstallUtil.exe to execute a malicious .NET assembly.
InstallUtil.exe loads the malicious assembly into its process.
The malicious assembly executes code that establishes an outbound network connection.
The connection is used for command and control (C2) or data exfiltration.
The attacker may use the C2 channel to download and execute further payloads.
The attacker performs lateral movement within the network.
The attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution within the context of a trusted Windows process (InstallUtil.exe), bypassing application control and potentially evading detection. This could result in a compromised system, data exfiltration, or further malicious activities within the network. The scope of impact depends on the attacker’s objectives and the level of access gained, potentially affecting entire organizations.

Recommendation

Enable process creation logging and network connection logging via Sysmon or Elastic Defend to provide the data needed for the rules below.
Deploy the Sigma rule “InstallUtil Network Connection” to your SIEM and tune for your environment to detect suspicious outbound network connections from InstallUtil.exe.
Investigate any alerts triggered by the Sigma rule by examining the parent process of InstallUtil.exe, destination IP addresses, and associated activities.
Implement network monitoring and alerting for unusual outbound connections from critical systems to enhance detection of similar threats in the future.

Browser Process Spawned from an Unusual Parent

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

This detection identifies instances where a browser process, specifically Google Chrome or Microsoft Edge, is initiated from an unexpected parent process on a Windows system. The rule focuses on scenarios where browsers are launched with arguments indicative of remote debugging, headless automation, or minimal user interaction. Such activity can signal an attempt to manipulate a browser session for malicious purposes, potentially leading to credential theft or unauthorized access to sensitive information. The rule is designed to leverage data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Process Creation Logs.

Attack Chain

An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
The attacker executes a script or command to launch a browser process (chrome.exe or msedge.exe).
The browser is launched with specific command-line arguments, such as --remote-debugging-port, --headless, or --window-position=-x,-y, to enable remote control or hide the browser window.
The parent process of the browser is an unusual executable, not typically associated with launching browsers (e.g., not explorer.exe).
The attacker leverages the remote debugging port to interact with the browser session programmatically.
The attacker attempts to steal credentials or session cookies from the browser.
The attacker uses stolen credentials to access sensitive data.

Impact

Successful exploitation can lead to the theft of user credentials, enabling unauthorized access to sensitive data and systems. This could result in financial loss, data breaches, and reputational damage for affected organizations. The targeted use of browser manipulation techniques increases the likelihood of bypassing traditional security controls.

Recommendation

Deploy the Sigma rule Browser Process Spawned from Unusual Parent to your SIEM and tune for your environment.
Enable Sysmon process-creation logging (Event ID 1) to collect the necessary data for the Sigma rule.
Investigate any alerts generated by the Browser Process Spawned from Unusual Parent Sigma rule.
Review process command lines for arguments like --remote-debugging-port or --headless to identify potential browser manipulation attempts.
Monitor network connections originating from browser processes for unexpected destinations, as described in the investigation guide from the source.

Mimikatz MemSSP Log File Detection

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

This detection identifies the creation of the mimilsa.log file, a default log generated by the Mimikatz misc::memssp module. The misc::memssp module injects a malicious Security Support Provider (SSP) into the Local Security Authority Subsystem Service (LSASS) process. This injected SSP logs credentials from subsequent logons to the compromised host, allowing attackers to capture sensitive information. The creation of this log file is a strong indicator of credential access attempts and the potential compromise of user accounts and system security. This rule is designed for data generated by Elastic Defend and also supports data from CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel.

Attack Chain

An attacker gains initial access to a Windows system (e.g., via phishing or exploiting a vulnerability).
The attacker executes Mimikatz or a similar tool with the misc::memssp module.
Mimikatz injects a malicious SSP library (e.g., mimilib.dll) into the LSASS process (lsass.exe).
The injected SSP hooks into the authentication process.
When users log on to the system, the SSP captures their credentials.
The captured credentials are written to the mimilsa.log file, typically located in C:\Windows\System32\.
The attacker retrieves the mimilsa.log file to obtain the captured credentials.
The attacker uses the stolen credentials to escalate privileges, move laterally within the network, and access sensitive resources.

Impact

A successful Mimikatz MemSSP attack can lead to the compromise of user accounts, including those with administrative privileges. This allows attackers to gain unauthorized access to sensitive data, systems, and resources within the organization. Lateral movement becomes easier, potentially impacting a large number of systems. The compromised credentials can also be used for external attacks, such as gaining access to cloud services or other external resources.

Recommendation

Deploy the Sigma rule Mimikatz Memssp Log File Detected to your SIEM and tune for your environment.
Enable Sysmon file creation logging to detect the creation of mimilsa.log files.
Investigate any alerts generated by the Sigma rule, focusing on the process that created the log file and any subsequent file access.
Monitor for the presence of mimilib.dll and any LSA Security Packages registry modifications, as these may indicate persistent SSP installation.
Review and restrict interactive logons to high-value hosts to minimize the potential for credential theft.
Investigate related alerts for the same host.id in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access.

Windows Subsystem for Linux Distribution Installed via Registry Modification

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

Attackers may leverage the Windows Subsystem for Linux (WSL) to evade detection by operating within a Linux environment on a Windows host. The installation of a new WSL distribution involves specific registry modifications. This rule identifies such modifications, providing an alert when a new WSL distribution is installed. This is important for defenders as it could signal an attacker setting up a persistent and potentially hidden environment for malicious activities. WSL allows attackers to utilize Linux tools and techniques on a Windows system, potentially bypassing traditional Windows-based security measures.

Attack Chain

Initial Access: The attacker gains initial access to the Windows system through existing vulnerabilities or compromised credentials.
Privilege Escalation: The attacker elevates their privileges to perform system-level changes, including registry modifications.
WSL Installation: The attacker initiates the installation of a WSL distribution. This may involve downloading and executing a WSL installer package.
Registry Modification: During installation, the system modifies the registry to configure and register the new WSL distribution. Specifically, keys under HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Lxss\\ are created/modified.
WSL Environment Setup: The attacker configures the installed WSL distribution, potentially installing additional tools and software needed for their objectives.
Execution of Malicious Activities: The attacker executes malicious commands and scripts within the WSL environment, leveraging Linux tools to perform actions such as lateral movement, data exfiltration, or persistence.
Defense Evasion: The attacker utilizes WSL to evade detection, as traditional Windows-based security tools may not effectively monitor or analyze activity within the Linux subsystem.
Persistence: The attacker establishes persistence within the WSL environment, ensuring continued access to the compromised system even after reboots or security updates.

Impact

Successful exploitation allows attackers to establish a hidden and persistent environment within the compromised Windows system. This can lead to data theft, system compromise, and further propagation of the attack within the network. The number of victims and affected sectors depends on the scope and objectives of the attacker. The use of WSL for malicious purposes can significantly complicate incident response and remediation efforts.

Recommendation

Deploy the Sigma rule “Detect WSL Installation via Registry Modification” to your SIEM to detect new WSL installations by monitoring registry changes.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function correctly (see setup instructions in the rule description).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the WSL installation and identify potential malicious activities.
Monitor for execution of suspicious processes within WSL environments, as described in “Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd”.

Detection of Bcdedit Boot Configuration Modification

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

This detection rule identifies the execution of bcdedit.exe with specific arguments that modify the boot configuration data (BCD) store in Windows systems. Attackers or malware may use this technique to disable Windows Error Recovery (recoveryenabled) or to ignore errors during the boot process (bootstatuspolicy ignoreallfailures). These modifications are often performed to prevent systems from recovering properly after an attack, particularly in ransomware scenarios. The rule is designed to work with data from Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon. The detection logic focuses on process execution events that include the relevant bcdedit.exe command-line arguments. Defenders should be aware of legitimate uses of bcdedit.exe by administrators for troubleshooting or data recovery purposes, so context is crucial.

Attack Chain

Initial Access: The attacker gains initial access to the system through various means, such as phishing or exploiting a vulnerability.
Privilege Escalation: The attacker escalates privileges to gain administrative access, required to modify boot configuration settings.
Reconnaissance: The attacker performs reconnaissance to identify the system’s configuration and identify appropriate targets for modification.
Disable Recovery: The attacker uses bcdedit.exe to disable Windows Error Recovery using the /set {default} recoveryenabled No command.
Ignore Boot Failures: The attacker uses bcdedit.exe to set the boot status policy to ignore all failures using the /set {default} bootstatuspolicy ignoreallfailures command.
System Impact: By modifying the boot configuration, the attacker inhibits system recovery, making it harder for the system to recover from errors or malicious activity.
Payload Execution: The attacker deploys and executes the primary malicious payload, such as ransomware, leveraging the modified boot configuration to maximize impact.
Final Objective: The attacker achieves their final objective, which could include data encryption, data theft, or system disruption.

Impact

Successful modification of boot configuration data can lead to significant system instability and data loss. In ransomware attacks, this technique prevents the system from recovering, increasing the likelihood of the victim paying the ransom. While the exact number of affected organizations is unknown, this technique is widely used in ransomware campaigns and can affect any Windows system if successfully executed.

Recommendation

Deploy the “Modification of Boot Configuration” Sigma rule to your SIEM and tune for your environment to detect the malicious use of bcdedit.exe described in this brief.
Enable Sysmon process creation logging to capture bcdedit.exe executions and their command-line arguments (Sysmon Event ID 1).
Investigate any detected instances of bcdedit.exe modifying boot configuration settings to determine legitimacy, as described in the rule’s “Triage and analysis” section.
Monitor process execution logs for unexpected processes running bcdedit.exe with arguments related to disabling recovery or ignoring boot failures.

Windows Backup Deletion via Wbadmin

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

Attackers, including ransomware groups, often attempt to remove or impair an organization’s ability to recover from an attack. One method to achieve this is by deleting Windows backup catalogs and system state backups using the wbadmin.exe utility. Windows Server Backup stores details about backups (what volumes are backed up and where the backups are located) in a backup catalog. Removing these catalogs renders backups unusable for recovery, increasing the impact of the attack. This technique is frequently observed in ransomware playbooks and other destructive attacks targeting Windows environments. This activity can be detected using endpoint detection and response (EDR) solutions, Windows Security Event Logs, and Sysmon.

Attack Chain

The attacker gains initial access to the system via phishing, exploiting a vulnerability, or using compromised credentials.
The attacker escalates privileges to administrator level to execute wbadmin.exe.
The attacker executes wbadmin.exe with the delete catalog command to remove backup catalogs.
The attacker executes wbadmin.exe with the delete systemstatebackup command to remove system state backups.
The attacker may also delete shadow copies using vssadmin.exe or wmic.exe to further hinder recovery.
The attacker deploys ransomware or initiates other destructive actions.
The attacker encrypts or destroys data on the system and connected network shares.
The attacker demands a ransom payment for data recovery, which is complicated by the deleted backups.

Impact

Successful deletion of backup catalogs and system state backups significantly impairs an organization’s ability to recover from a ransomware attack or other destructive event. This can lead to prolonged downtime, data loss, and financial losses associated with incident response and recovery efforts. While the number of direct victims of this specific technique is difficult to quantify, the impact is typically observed in conjunction with broader ransomware campaigns affecting organizations across various sectors.

Recommendation

Enable Sysmon process creation logging with Event ID 1 to capture wbadmin.exe executions and activate the first Sigma rule.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Monitor Windows Security Event Logs for process creation events related to wbadmin.exe.
Investigate any instances of wbadmin.exe executing with delete arguments.
Review and harden account access controls to prevent unauthorized use of wbadmin.exe.

Suspicious Enumeration Commands Spawned via WMIPrvSE

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

Attackers can leverage the Windows Management Instrumentation (WMI) to execute commands for reconnaissance and enumeration within a compromised system. This involves spawning native Windows tools via the WMI Provider Service (WMIPrvSE). This activity is often used to gather system and network information in a stealthy manner, which could be part of a larger attack, such as lateral movement or privilege escalation. This behavior matters because it allows adversaries to gather information about the target environment without using easily detectable methods, potentially leading to further compromise.

Attack Chain

The attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker uses WMI to execute a reconnaissance command.
WMIPrvSE.exe is invoked to execute the attacker’s specified command.
The attacker executes commands such as ipconfig.exe, net.exe, or systeminfo.exe via WMIPrvSE.exe to gather network configuration details, user information, and system information.
The enumerated information is collected and potentially exfiltrated to a command and control server.
The attacker uses the gathered information to identify further targets within the network.
The attacker moves laterally to other systems using stolen credentials or exploited vulnerabilities.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or persistent access.

Impact

Successful execution of enumeration commands via WMIPrvSE allows attackers to gather sensitive information about the system and network environment. This information can be used to facilitate lateral movement, privilege escalation, and data theft, potentially leading to significant financial loss, reputational damage, and disruption of business operations.

Recommendation

Enable Sysmon process creation logging to capture the execution of enumeration commands (Data Source: Sysmon).
Deploy the Sigma rule “Enumeration Command Spawned via WMIPrvSE” to your SIEM to detect suspicious WMIPrvSE activity (Sigma rule).
Investigate any instances of WMIPrvSE spawning common enumeration tools such as net.exe, ipconfig.exe, or systeminfo.exe (Sigma rule).
Implement network segmentation to limit the scope of potential lateral movement following successful enumeration (Attack Chain).

Suspicious Antimalware Scan Interface DLL Creation

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

The Antimalware Scan Interface (AMSI) is a Windows interface that allows applications and services to integrate with antimalware products. Attackers may attempt to bypass AMSI to execute malicious code without detection. This detection identifies the creation of the AMSI DLL (amsi.dll) in unusual locations, which is a common technique used to load a rogue AMSI module instead of the legitimate one. This technique can be used to evade detection by security products that rely on AMSI for scanning potentially malicious scripts and code. The rule is designed to work with data from Winlogbeat, Elastic Endpoint, Sysmon, Endgame, SentinelOne Cloud Funnel, Microsoft Defender XDR, and Crowdstrike.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploit).
The attacker determines the location of the legitimate amsi.dll file.
The attacker identifies a writable directory where a malicious amsi.dll can be placed. This location must be in the search order of applications that use AMSI, such as PowerShell or other scripting hosts.
The attacker copies or creates a malicious amsi.dll in the identified location. This rogue DLL is designed to bypass or disable AMSI functionality.
A process like PowerShell or another scripting host is launched. Because the malicious amsi.dll is in a higher-priority directory, it is loaded instead of the legitimate AMSI library.
The launched process executes malicious code (e.g., PowerShell script).
Because the rogue amsi.dll is loaded, AMSI scans are bypassed, allowing the malicious code to execute without detection.

Impact

A successful AMSI bypass can allow attackers to execute malicious code, such as malware, scripts, or exploits, without detection by antimalware products. This can lead to system compromise, data theft, or other malicious activities. The impact can range from a single compromised endpoint to a wider breach of an organization’s network.

Recommendation

Enable file creation monitoring with Sysmon or Elastic Defend to detect the creation of files, specifically DLLs, in unusual locations.
Deploy the Sigma rule “Suspicious Antimalware Scan Interface DLL Creation” to your SIEM to detect the creation of amsi.dll in non-standard paths. Tune the rule for your environment.
Investigate any alerts generated by the Sigma rule by examining the parent process, file path, and user context to determine if the activity is malicious.

Script Execution via Microsoft HTML Application

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

This detection identifies the execution of scripts via HTML applications, leveraging Windows utilities like rundll32.exe or mshta.exe. Attackers often use this method to bypass process and signature-based defenses by proxying the execution of malicious content through legitimate, signed binaries. The detection focuses on specific command-line arguments and patterns associated with this technique, while also excluding known legitimate uses by applications such as Citrix System32 (wfshell.exe), Microsoft Access (MSACCESS.EXE), and Quokka.Works (GTInstaller.exe). This technique is used by attackers to execute malicious scripts without directly running them, thus evading traditional security measures. The detection rule analyzes process names, command-line arguments, parent processes, and file paths to identify potentially malicious activity indicative of defense evasion.

Attack Chain

An attacker gains initial access through various means (e.g., phishing, drive-by download).
The attacker leverages a malicious HTML application (HTA) file or a scriptlet (SCT) file.
The attacker uses mshta.exe or rundll32.exe to execute the malicious HTA or SCT file. The command line includes obfuscated or encoded script content.
mshta.exe or rundll32.exe process spawns a child process, such as cmd.exe or powershell.exe, to execute further commands.
The spawned process executes malicious code, such as downloading and executing a payload.
The attacker achieves persistence by modifying registry keys or creating scheduled tasks.
The attacker performs lateral movement by exploiting vulnerabilities or using stolen credentials.
The final objective is achieved, such as data exfiltration, ransomware deployment, or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise the system, steal sensitive data, deploy ransomware, or establish a persistent foothold. Due to the nature of the technique, it can bypass many traditional security measures. The wide adoption of Windows and the inherent trust placed in signed binaries makes this a potent evasion technique. Failure to detect and prevent this attack can lead to significant financial and reputational damage for the targeted organization.

Recommendation

Deploy the Sigma rule “Script Execution via Microsoft HTML Application” to your SIEM to detect suspicious mshta.exe and rundll32.exe executions. Tune the rule by adding exceptions for known legitimate uses in your environment.
Enable Sysmon process creation logging (Event ID 1) to ensure the visibility required for the Sigma rules to function correctly.
Monitor process command lines for suspicious arguments like “script:eval”, “WScript.Shell”, and “mshta http” which are indicative of this technique.
Implement application control policies to restrict the execution of mshta.exe and rundll32.exe where they are not required for legitimate business purposes.
Investigate and block any identified malicious HTA files or scriptlet URLs found in the command lines of detected processes.

Conhost Proxy Execution for Defense Evasion

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

Attackers are leveraging the Console Window Host (conhost.exe) to proxy execution of commands, using the --headless argument to hide malicious activity. This technique allows adversaries to blend in with legitimate Windows processes, making detection more challenging. This behavior, often associated with defense evasion, involves using conhost.exe to execute commands such as PowerShell, cmd.exe, mshta, curl, and scripts. The activity can be seen across multiple environments including endpoints, Windows systems, and cloud platforms like Microsoft Defender XDR and SentinelOne. Defenders must differentiate between legitimate uses of conhost.exe, such as those by Winget-AutoUpdate or OpenSSH, and malicious proxy executions, which could indicate broader compromise.

Attack Chain

An attacker gains initial access to the system, possibly through phishing or exploiting a vulnerability.
The attacker executes a command that calls conhost.exe with the --headless argument.
Conhost.exe is used to proxy the execution of a malicious command, such as PowerShell, cmd.exe, or mshta.
The proxied command downloads a malicious payload from a remote server using tools like curl or bitsadmin.
The downloaded payload is executed, establishing persistence on the compromised system.
The attacker uses the compromised system to move laterally within the network, compromising additional systems.
Sensitive data is exfiltrated from the network to a remote server controlled by the attacker.
The attacker achieves their final objective, such as deploying ransomware or stealing intellectual property.

Impact

Successful exploitation can lead to a complete compromise of the targeted system and potentially the entire network. This can result in data theft, financial loss, and reputational damage. The use of conhost.exe for proxy execution makes it difficult to detect malicious activity, potentially allowing attackers to remain undetected for extended periods. The impact could range from individual workstation compromises to large-scale network breaches, affecting potentially hundreds or thousands of systems within an organization.

Recommendation

Deploy the “Proxy Execution via Console Window Host” Sigma rule to your SIEM and tune for your environment to detect suspicious conhost.exe activity.
Monitor process creation events for conhost.exe with the --headless argument, focusing on the command-line arguments to identify potentially malicious commands.
Investigate any instances of conhost.exe executing suspicious scripts, downloaders, or task scheduler modifications to identify potential threats.
Enable Sysmon process creation logging (Event ID 1) to capture detailed process execution information, as recommended in the setup instructions linked in the overview.
Review the investigation fields in the brief to understand the key data points for analyzing potential proxy execution attempts.

Windows Firewall Disabled via Netsh

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

Attackers commonly use the netsh.exe utility, a command-line scripting tool, to manage network configurations. Abusers leverage netsh.exe to disable or modify Windows Firewall rules, a built-in host-based firewall. This manipulation weakens the system’s defenses, allowing unauthorized network traffic and enabling lateral movement within the compromised environment. The activity allows for command and control communications and unhindered exploitation of internal resources. Defenders must monitor netsh.exe executions for unexpected firewall modifications.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
Privilege Escalation: The attacker escalates privileges to a level sufficient to modify firewall settings.
Discovery: The attacker uses reconnaissance techniques to identify existing firewall rules.
Defense Evasion: The attacker uses netsh.exe to disable specific firewall rules, using commands like netsh advfirewall firewall set rule name="rule_name" new enable=no.
Defense Evasion: Alternatively, the attacker disables the entire firewall using netsh advfirewall set allprofiles state off.
Lateral Movement: With the firewall weakened, the attacker moves laterally to other systems on the network.
Command and Control: The attacker establishes command and control channels, which may now be unimpeded by firewall rules.
Impact: The attacker achieves their objectives, such as data exfiltration, ransomware deployment, or further compromise of the network.

Impact

Successful disabling of Windows Firewall rules can lead to significant security breaches. Attackers can move laterally within the network, compromise additional systems, and exfiltrate sensitive data. The impact can range from data loss and financial damage to reputational harm and legal consequences. The defense evasion enables attackers to establish persistent command and control channels, maintain a long-term presence within the compromised environment and conduct further malicious activities.

Recommendation

Enable Sysmon process creation logging to monitor netsh.exe executions and related command-line arguments to support detections.
Deploy the Sigma rules in this brief to your SIEM to detect attempts to disable Windows Firewall rules via netsh.exe. Tune the rules for your specific environment.
Investigate any alerts generated by the Sigma rules, focusing on identifying the user account, process execution chain, and the specific firewall rules being modified.
Implement strict access controls to limit the number of users with the privileges necessary to modify firewall settings.
Regularly review and audit firewall configurations to ensure they are properly configured and have not been tampered with.

Suspicious PowerShell Execution via Windows Script Host

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

This detection identifies PowerShell execution initiated by Windows Script Host processes (cscript.exe or wscript.exe). Attackers often use Windows Script Host (WSH) to execute malicious scripts as an initial access method. These scripts can act as droppers for second-stage payloads or download tools and utilities necessary for further compromise. The rule focuses on the parent-child process relationship between WSH and PowerShell, highlighting a common technique used to bypass security controls and execute arbitrary commands on a compromised system. This activity is relevant to defenders as it represents a potential entry point for various attacks, including malware deployment and data exfiltration. The detection logic is based on process execution events observed in Windows environments and is designed to work with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

The user receives a phishing email with a malicious attachment (e.g., a .vbs or .js file).
The user opens the attachment, which is processed by either wscript.exe or cscript.exe.
The scripting engine executes the embedded malicious code.
The script downloads a PowerShell script from a remote server or contains an embedded, obfuscated PowerShell command.
The script uses wscript.exe or cscript.exe to launch powershell.exe to execute the downloaded or embedded PowerShell script.
PowerShell executes, performing malicious actions such as downloading additional payloads, modifying system settings, or establishing persistence.
PowerShell attempts to connect to external command-and-control servers to receive further instructions.
The attacker gains initial access to the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation can lead to initial access, allowing attackers to deploy malware, steal sensitive information, or perform other malicious activities. The impact can range from data breaches and financial losses to reputational damage. The severity depends on the attacker’s objectives and the level of access they gain. The number of affected systems depends on the scope of the phishing campaign or other initial access methods used to deliver the malicious script.

Recommendation

Enable Sysmon process creation logging to capture the necessary event data for the rules below.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Investigate process execution chains where cscript.exe or wscript.exe spawn powershell.exe using the provided Sigma rules.
Implement email security measures to block phishing emails with script attachments.
Monitor network connections originating from PowerShell processes for suspicious outbound traffic.

Proxy Execution via Windows OpenSSH Client

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

This detection identifies attempts to execute commands through a proxy using the Windows OpenSSH client (ssh.exe or sftp.exe). Attackers may abuse this behavior to evade application control policies by leveraging the trusted Windows OpenSSH binaries. The technique involves using the ProxyCommand or LocalCommand options with the OpenSSH client to execute arbitrary commands on the target system. The rule focuses on detecting command lines containing potentially malicious commands such as PowerShell, schtasks, mshta, msiexec, cmd, or script execution, indicating a possible attempt to bypass security measures. The detection logic is applicable to Windows systems.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes the Windows OpenSSH client (ssh.exe or sftp.exe) with either the ProxyCommand or LocalCommand option.
The ProxyCommand or LocalCommand parameter specifies a command to be executed locally on the system.
The command includes potentially malicious payloads such as PowerShell commands, scheduled tasks manipulation (schtasks), or execution of other LOLBINs (Living Off the Land Binaries) like mshta or msiexec.
The OpenSSH client executes the specified command.
The malicious command performs actions such as downloading and executing additional payloads, creating scheduled tasks for persistence, or executing arbitrary code.
The attacker achieves their objectives, such as gaining further access to the system, escalating privileges, or deploying malware.

Impact

Successful exploitation can lead to a complete compromise of the affected system. Attackers can bypass application control mechanisms, execute arbitrary code, and establish persistence. This can result in data theft, system disruption, or further propagation of the attack within the network. The severity of the impact depends on the privileges of the account running the OpenSSH client and the specific actions performed by the malicious commands.

Recommendation

Enable process creation logging with command line details to capture the execution of ssh.exe and sftp.exe with malicious parameters.
Deploy the Sigma rule Proxy Execution via Windows OpenSSH to your SIEM to detect suspicious OpenSSH client executions with malicious commands in the command line.
Monitor for the creation of child processes from ssh.exe or sftp.exe, as this can indicate the execution of malicious commands specified in the ProxyCommand or LocalCommand options.
Review and restrict the usage of PermitLocalCommand in OpenSSH server configurations to prevent attackers from executing commands locally on the system after a connection is established.

Windows User Account Creation via Net.exe

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

Attackers may create new accounts (both local and domain) to maintain access to victim systems. This rule identifies the usage of net.exe to create new accounts on Windows systems. The detection logic focuses on process execution events where net.exe or net1.exe are executed with arguments indicative of user creation, specifically the ‘user’ argument in conjunction with either the ‘/ad’ or ‘/add’ flags. While account creation is a common administrative task, suspicious executions, especially those initiated by unusual parent processes or accounts, warrant further investigation. This rule is designed for data generated by Elastic Defend but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, and SentinelOne Cloud Funnel, enhancing its applicability across various security environments.

Attack Chain

An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.
The attacker opens a command prompt or PowerShell session.
The attacker uses net.exe or net1.exe to create a new user account. The command includes the user argument along with /add or /ad flags. For example: net user /add.
The attacker may add the newly created user to privileged groups, such as Administrators or Domain Admins, to elevate privileges.
The attacker uses the new account to move laterally within the network, accessing sensitive data or systems.
The attacker establishes persistence by configuring the new account to be a service account or adding it to local administrator groups.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and long-term persistence on compromised systems. The impact is often determined by the privileges assigned to the newly created account. If the attacker adds the account to the Administrators group, they can effectively take full control of the affected system. In a domain environment, creating a domain account can lead to wider compromise across the entire network.

Recommendation

Enable Sysmon process-creation logging to capture the necessary events for the rules below.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Investigate any instances of net.exe or net1.exe creating user accounts, especially when initiated by unusual parent processes.
Monitor for newly created accounts being added to privileged groups.
Review the triage and analysis steps in the rule’s original documentation for guidance on investigating and responding to potential incidents.

Unusual Network Connection via DllHost

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

The detection rule identifies unusual instances of dllhost.exe making outbound network connections, which may indicate adversarial command and control activity. Dllhost.exe is a legitimate Windows process used to host DLL services. Adversaries may exploit it for stealthy command and control by initiating unauthorized network connections to non-local IPs. This approach helps in identifying potential threats by focusing on unusual network behaviors associated with this process. The rule aims to detect activity related to defense evasion, where adversaries use system binaries to proxy execution. The detection logic relies on identifying dllhost.exe processes initiating network connections to destinations outside of commonly used private IP ranges.

Attack Chain

An attacker gains initial access to a Windows system (e.g., via phishing or exploitation).
The attacker executes a malicious DLL file on the compromised system.
The attacker uses dllhost.exe to host and execute the malicious DLL.
The malicious DLL initiates a network connection to an external IP address, bypassing traditional process-based network monitoring.
The attacker establishes a command and control (C2) channel via the dllhost.exe process.
The attacker uses the C2 channel to send commands and receive data from the compromised system.
The attacker performs lateral movement within the network.
The attacker exfiltrates sensitive data from the compromised network.

Impact

A successful attack can lead to the establishment of a covert command and control channel, allowing attackers to remotely control the compromised system. This can result in data theft, further compromise of the network, and potential financial loss. The references point to APT29 activity, suggesting sophisticated actors may leverage this technique.

Recommendation

Enable Sysmon process creation (Event ID 1) and network connection (Event ID 3) logging to enhance visibility of process execution and network activity (https://ela.st/sysmon-event-1-setup, https://ela.st/sysmon-event-3-setup).
Deploy the Sigma rule Unusual Network Connection via DllHost to your SIEM to detect suspicious outbound connections from dllhost.exe.
Investigate and whitelist legitimate software updates or enterprise applications that use dllhost.exe for network communications to reduce false positives, as described in the rule’s analysis notes.

Suspicious Execution via Microsoft Office Add-Ins

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

Attackers are increasingly leveraging malicious Microsoft Office Add-Ins to gain initial access and persistence on victim systems. These add-ins, often delivered through phishing campaigns, contain embedded malicious code. This detection identifies unusual execution patterns, such as Office applications (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE, VSTOInstaller.exe) launching add-ins (wll, xll, ppa, ppam, xla, xlam, vsto) from suspicious paths like Temp or Downloads directories, or with atypical parent processes (explorer.exe, OpenWith.exe, cmd.exe, powershell.exe). The detection logic filters out known benign activities to minimize false positives, focusing on anomalies indicative of malicious intent, such as installations of Logitech software. This activity matters because successful exploitation can lead to arbitrary code execution, data theft, and further compromise of the victim’s network.

Attack Chain

A user receives a phishing email containing a malicious Microsoft Office document.
The user opens the document, which prompts them to enable macros or install an add-in.
The malicious add-in (wll, xll, ppa, ppam, xla, xlam, vsto) is downloaded from a remote server or dropped into a suspicious directory, such as %TEMP% or %APPDATA%.
The user executes an Office application (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE), which loads the malicious add-in.
The malicious add-in executes arbitrary code, potentially downloading and executing a second-stage payload.
The add-in may establish persistence by modifying registry keys or creating scheduled tasks.
The attacker gains initial access to the system and can perform reconnaissance, lateral movement, and data exfiltration.
The attacker achieves their objective, which could include data theft, ransomware deployment, or intellectual property theft.

Impact

A successful attack can lead to complete system compromise, data theft, and potential ransomware deployment. Organizations across all sectors are at risk, particularly those with a high volume of email traffic. The use of malicious Office Add-Ins provides attackers with a persistent foothold within the victim’s environment, allowing for long-term data collection and disruption of business operations. This can lead to significant financial losses, reputational damage, and legal liabilities.

Recommendation

Deploy the Sigma rule Office Add-In Loaded From Suspicious Path to detect add-ins loaded from temporary or download directories based on process.args and process.name.
Deploy the Sigma rule Office Add-In Loaded By Suspicious Parent to detect add-ins loaded by cmd.exe or powershell.exe based on process.parent.name.
Investigate any instances of VSTOInstaller.exe executing with the /Uninstall argument, as this may indicate suspicious activity, correlating with the exclusion rule in the provided query.
Monitor for Office applications launching add-ins with parent processes of explorer.exe or OpenWith.exe using process creation logs and the provided query logic.
Implement stricter email filtering to prevent phishing emails containing malicious Office documents from reaching end-users.

Potential RemoteMonologue Attack via Registry Modification

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

The RemoteMonologue attack technique abuses Component Object Model (COM) objects to coerce authentication from a remote system. This is achieved by modifying the RunAs registry value associated with a COM object. Setting this value to “Interactive User” forces the COM object to run under the context of the interactive user, enabling attackers to hijack sessions and potentially escalate privileges. This technique is often used as a defense evasion or persistence mechanism by adversaries after gaining initial access to a system. The attack involves modifying registry keys associated with COM objects to trigger NTLM authentication coercion. This can be used for lateral movement and gaining access to sensitive resources. This rule is designed to detect registry modifications indicative of the RemoteMonologue attack.

Attack Chain

Initial Access: An attacker gains initial access to the target system through unspecified means.
Identify COM Objects: The attacker identifies suitable COM objects for abuse.
Modify Registry: The attacker modifies the registry to set the RunAs value for the selected COM object to Interactive User. This involves modifying the registry path HKCR\AppID\{Clsid}\RunAs.
Trigger COM Object Execution: The attacker triggers the execution of the modified COM object, potentially through a remote procedure call or other inter-process communication mechanisms.
Authentication Coercion: The execution of the COM object triggers NTLM authentication to a system controlled by the attacker.
Relay Attack: The attacker relays the coerced NTLM authentication to gain access to other resources on the network.
Session Hijacking: Successful relay leads to session hijacking, allowing the attacker to impersonate the user.
Lateral Movement/Privilege Escalation: The attacker uses the hijacked session for lateral movement or privilege escalation within the network.

Impact

A successful RemoteMonologue attack can lead to unauthorized access to sensitive systems and data. By coercing authentication and hijacking sessions, attackers can bypass security controls and escalate their privileges within the network. The scope of the impact depends on the privileges of the hijacked user account and the resources accessible to that account. This attack can enable lateral movement, data exfiltration, and other malicious activities.

Recommendation

Deploy the Sigma rule Detect RemoteMonologue Registry Modification to your SIEM to identify suspicious registry modifications related to COM object hijacking.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively.
Investigate any alerts generated by the Sigma rule by reviewing the registry event logs and identifying the user account and process responsible for the registry modification.
Implement enhanced monitoring on critical systems to detect any attempts to modify COM object registry settings.
Block the attack by ensuring “RunAs” value is not set to “Interactive User”.

Potential Defense Evasion via Filter Manager (fltMC.exe)

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

The Filter Manager Control Program (fltMC.exe) is a Windows utility used to manage filter drivers, also known as minifilters. These minifilters are leveraged by various security products, including EDR, antivirus solutions, and data loss prevention tools, to intercept and modify I/O requests. Attackers can abuse fltMC.exe to unload these minifilters, effectively disabling or circumventing the security measures they provide. This allows malicious actors to operate without detection, potentially leading to data breaches, malware infections, or other harmful activities. This technique has been observed being used to disable security products such as Bitdefender, SentinelOne and ManageEngine Endpoint Central.

Attack Chain

Attacker gains initial access to the target system (e.g., via compromised credentials or exploit).
Attacker executes fltMC.exe with administrative privileges.
fltMC.exe attempts to unload a specific filter driver (minifilter).
The operating system processes the request to unload the specified filter driver.
If successful, the targeted minifilter is removed from the active filter stack.
Security software relying on the unloaded minifilter ceases to function correctly, leaving a security gap.
Attacker performs malicious actions, such as deploying malware or exfiltrating sensitive data, without the protection of the disabled filter driver.
Attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation allows attackers to disable or circumvent security controls, increasing the likelihood of successful malware infections, data breaches, and other malicious activities. The scope of impact depends on the specific filter driver unloaded and the security products it supports. Disabling a critical EDR minifilter could leave the entire system vulnerable, while disabling a less critical filter might only impact a subset of security features.

Recommendation

Monitor process creation events for the execution of fltMC.exe with the unload argument to identify potential evasion attempts (see Sigma rule “Potential Evasion via Filter Manager”).
Investigate any instances of fltMC.exe execution where the parent process is not a known and trusted system management tool.
Implement strict access controls to limit the ability of users to execute fltMC.exe or modify filter driver configurations.
Review the list of exclusions in the provided EQL query to identify any legitimate software that may be generating false positives.
Ensure that endpoint security solutions are properly configured and monitored to detect and prevent unauthorized filter driver modifications.
Enable Sysmon process creation logging to activate the rules above.

Kerberos Traffic from Unusual Process

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

This detection identifies unusual processes initiating network connections to the standard Kerberos port (88) on Windows systems. Typically, the lsass.exe process handles Kerberos traffic on domain-joined hosts. The rule aims to detect processes other than lsass.exe communicating with the Kerberos port, which could indicate malicious activity such as Kerberoasting (T1558.003) or Pass-the-Ticket (T1550.003). The detection is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. This can help security teams identify potential credential access attempts and lateral movement within the network.

Attack Chain

An attacker compromises a user account or system within the domain.
The attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.
The malicious process attempts to request Kerberos service tickets (TGS) for various services within the domain. This is done by connecting to the Kerberos port (88) on a domain controller.
The attacker uses tools like Rubeus or Kerberoast.ps1 to enumerate and request TGS tickets.
The unusual process (not lsass.exe) sends Kerberos traffic to the domain controller.
The attacker extracts the Kerberos tickets from memory or network traffic.
The attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).
The attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.

Impact

A successful Kerberoasting or Pass-the-Ticket attack can lead to unauthorized access to sensitive resources and lateral movement within the network. Attackers can compromise service accounts with elevated privileges, potentially leading to domain-wide compromise. Detection of this behavior can prevent attackers from gaining access to critical assets. While the exact number of victims and sectors targeted are unknown, this technique is widely used by various threat actors in targeted attacks.

Recommendation

Deploy the “Kerberos Traffic from Unusual Process” Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.
Review event ID 4769 for suspicious ticket requests as mentioned in the rule’s documentation.
Examine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.
Monitor for processes connecting to port 88, filtering out legitimate Kerberos clients like lsass.exe, using the “Detect Kerberos Traffic from Non-Standard Process” Sigma rule.
Investigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.

Windows Subsystem for Linux Enabled via Dism Utility

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

Attackers may enable the Windows Subsystem for Linux (WSL) to run Linux applications and tools directly on Windows, potentially bypassing security controls and hindering detection. This involves using the Dism.exe utility to enable the “Microsoft-Windows-Subsystem-Linux” feature. By leveraging WSL, adversaries can execute malicious code, access Windows resources, and perform various malicious activities while blending in with legitimate system processes. The use of WSL provides an environment where traditional Windows-based security solutions may have limited visibility, thus offering a way to evade detection. This activity has been observed as a post-exploitation technique, used after initial access to a compromised system.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using compromised credentials.
The attacker executes Dism.exe (Deployment Image Servicing and Management tool).
Dism.exe is invoked with the command-line argument to enable the “Microsoft-Windows-Subsystem-Linux” feature.
The system processes the Dism.exe command and enables WSL.
The attacker installs a Linux distribution (e.g., Ubuntu, Kali) within the WSL environment.
The attacker uses the WSL environment to execute Linux-based tools and scripts for reconnaissance, lateral movement, or data exfiltration.
The attacker leverages the WSL environment to interact with Windows resources or execute Windows commands.
The attacker achieves their objective, such as stealing sensitive data or establishing persistence on the compromised system.

Impact

Successful enablement of WSL can lead to a compromised Windows system being used as a platform for Linux-based attacks. This can result in data theft, system compromise, and further propagation of malicious activity within the network. The use of WSL can make it difficult to detect malicious activity since it allows attackers to blend Linux-based attacks with normal Windows operations. The lack of visibility into the WSL environment by traditional Windows security tools can lead to prolonged periods of undetected malicious activity.

Recommendation

Monitor process creation events for the execution of Dism.exe with command-line arguments that include Microsoft-Windows-Subsystem-Linux to detect WSL enablement attempts (see Sigma rule Detect WSL Enablement via Dism).
Enable Sysmon process creation logging to capture detailed command-line information for processes, which is crucial for detecting this activity (Sysmon Event ID 1).
Implement the provided Sigma rule to detect suspicious usage of the DISM utility to enable WSL. Tune the rule based on your environment to minimize false positives.
Investigate any alerts generated by the Sigma rule Detect WSL Enablement via Dism to determine the legitimacy of the activity.
Monitor network connections originating from WSL processes for suspicious outbound traffic.
Consider blocking the execution of Dism.exe if WSL is not a sanctioned tool in your environment.

Windows Scheduled Tasks AT Command Enabled via Registry Modification

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

The legacy Windows AT command allows scheduling tasks for execution. While deprecated since Windows 8 and Windows Server 2012, it remains present for backwards compatibility. Attackers may enable the AT command through registry modifications to achieve persistence or lateral movement within a network. This technique bypasses modern security controls and can be difficult to detect without specific monitoring. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. The use of this command allows an attacker to execute commands with elevated privileges, potentially compromising the entire system.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker attempts to enable the AT command by modifying the registry.
The registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt is modified to a value of “1” or “0x00000001”.
The attacker uses the AT command to schedule a malicious task.
The scheduled task executes a command or script, such as downloading and executing malware.
The malware establishes persistence on the system.
The attacker uses the compromised system as a pivot point for lateral movement.

Impact

Enabling the AT command can lead to unauthorized task scheduling, malware execution, persistence, and lateral movement within a network. Successful exploitation can compromise sensitive data, disrupt operations, and grant attackers persistent access to critical systems. The use of a deprecated command makes it harder to detect, increasing the impact.

Recommendation

Monitor registry events for modifications to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt as described in the rule overview.
Deploy the Sigma rule “Scheduled Tasks AT Command Enabled” to your SIEM and tune for your environment.
Enable Sysmon process creation and registry event logging to activate the rule.
Investigate any alerts triggered by the Sigma rule “Scheduled Tasks AT Command Enabled” for suspicious activity.

Windows Host Network Discovery Enabled via Netsh

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

Attackers can leverage the netsh.exe utility to modify Windows Firewall settings, specifically enabling Network Discovery. This setting allows a host to broadcast its presence and services, making it easier for attackers to identify potential targets within the network for lateral movement. The behavior is often a post-exploitation technique to weaken host-based defenses after gaining initial access. The modification uses netsh.exe, a command-line scripting utility for managing network configurations. This activity can be easily scripted and automated, making it a common step in reconnaissance and lateral movement playbooks. Defenders should monitor for unauthorized use of netsh.exe to modify firewall settings.

Attack Chain

Attacker gains initial access to a Windows host.
Attacker executes netsh.exe with elevated privileges.
netsh.exe is used to modify the Windows Firewall configuration.
The specific command executed enables Network Discovery using the netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes syntax.
The firewall rule group “Network Discovery” is modified to allow inbound and outbound traffic.
The compromised host begins sending out broadcast messages, advertising its presence and services on the network.
The attacker uses the information gathered to identify other vulnerable systems on the network.
The attacker moves laterally to other systems based on the discovery information.

Impact

Successful exploitation allows attackers to easily enumerate and identify other vulnerable systems within the network. This can lead to rapid lateral movement, further compromising the environment. The risk is heightened when the compromised host has access to sensitive data or critical systems. There is no specific victim count or sector targeted mentioned in the provided source.

Recommendation

Deploy the Sigma rule “Enable Host Network Discovery via Netsh” to your SIEM to detect the use of netsh.exe to enable network discovery (see rule below).
Enable Windows Firewall logging and monitor for changes to firewall rules, specifically those related to Network Discovery.
Review and restrict the use of netsh.exe to authorized personnel and systems only.

Windows Firewall Disabled via PowerShell

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

Attackers often attempt to disable or modify system firewalls to evade network restrictions and facilitate lateral movement within a compromised environment. The Windows Firewall, a built-in component, provides host-based traffic filtering. Disabling it allows unrestricted communication, aiding command and control activities and hindering detection efforts. This activity is commonly achieved through PowerShell, leveraging cmdlets like Set-NetFirewallProfile. The rule focuses on detecting the use of this specific cmdlet to disable the Windows Firewall, alerting defenders to potential defense evasion attempts. This technique is valuable to attackers across various attack vectors, especially after initial access has been established.

Attack Chain

Initial Access: An attacker gains initial access through methods such as phishing or exploiting a vulnerability in a network-facing application.
Privilege Escalation (if necessary): The attacker escalates privileges to gain the necessary permissions to modify firewall settings.
PowerShell Execution: The attacker executes PowerShell, either through an interactive session or a script.
Disable Firewall Profile: The attacker uses the Set-NetFirewallProfile cmdlet with parameters such as -Enabled False to disable the firewall for all, public, domain, or private profiles.
Network Reconnaissance: With the firewall disabled, the attacker performs network reconnaissance to identify valuable assets and potential lateral movement paths.
Lateral Movement: The attacker moves laterally to other systems on the network, exploiting trust relationships or vulnerabilities.
Command and Control: The attacker establishes command and control channels to communicate with compromised systems and exfiltrate sensitive data.
Data Exfiltration or Further Exploitation: The attacker exfiltrates sensitive data or continues to exploit the environment based on their objectives.

Impact

Successful disabling of the Windows Firewall can lead to unrestricted lateral movement within a network, allowing attackers to compromise additional systems and exfiltrate sensitive data. This can result in data breaches, financial losses, and reputational damage. While the source does not specify the number of affected organizations, any environment relying on Windows Firewall for network segmentation is at risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the use of Set-NetFirewallProfile with the -Enabled False parameter (see Sigma rule below).
Enable process creation logging on Windows endpoints to capture PowerShell executions (reference the logsource in the Sigma rule).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the firewall modification activity.
Review and enforce the principle of least privilege to limit the number of users with permissions to modify firewall settings.
Consider implementing additional network segmentation and monitoring controls to detect and prevent lateral movement even if the Windows Firewall is disabled.

Windows Defender Exclusions Added via PowerShell

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

Attackers may attempt to evade detection by modifying Windows Defender’s configuration to exclude specific files, folders, or processes from scanning. This is often achieved by using PowerShell commands to add exclusions. The tactic allows malware to operate without being detected by the built-in antivirus solution. Observed as early as 2018 with Trickbot disabling Windows Defender, this technique remains relevant today. This activity can be performed using Add-MpPreference or Set-MpPreference commands in PowerShell, specifying exclusions by path or process name. Detecting these modifications is critical for maintaining the integrity of endpoint security. The scope of targeting ranges from individual workstations to entire networks.

Attack Chain

The attacker gains initial access to the system via an undisclosed method.
The attacker executes PowerShell with administrative privileges.
The attacker uses the Add-MpPreference or Set-MpPreference cmdlet to add an exclusion.
The exclusion specifies a file path, folder, or process that should be ignored by Windows Defender.
Windows Defender is reconfigured to ignore the specified item.
The attacker deploys or executes malware in the excluded location.
The malware operates without interference from Windows Defender.
The attacker achieves their final objective, such as data theft or lateral movement.

Impact

Successful exploitation allows attackers to operate undetected on compromised systems, leading to potential data breaches, lateral movement within the network, and deployment of ransomware. While the exact number of victims is unknown, this technique is widely used by various threat actors, impacting organizations across various sectors. The lack of detection can lead to prolonged periods of compromise, increasing the potential damage.

Recommendation

Deploy the Sigma rule “Windows Defender Exclusions Added via PowerShell” to your SIEM to detect suspicious PowerShell commands used to add exclusions.
Enable Sysmon process creation logging with command line auditing to capture the necessary event data for the Sigma rule.
Regularly review Windows Defender exclusion lists to identify any unauthorized or suspicious entries.
Investigate any PowerShell process that uses Add-MpPreference or Set-MpPreference with exclusion parameters, as identified by the provided Sigma rule.
Monitor for processes and file modifications within excluded directories.
Configure alerts to notify security teams when new Windows Defender exclusions are added.

Werfault ReflectDebugger Persistence via Registry Modification

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

Attackers can abuse the Windows Error Reporting (Werfault) service to establish persistence on a compromised system. This is achieved by modifying the ReflectDebugger registry key. When Werfault is executed with the -pr parameter, it will execute the debugger specified in the ReflectDebugger registry key. This allows attackers to execute arbitrary code every time the Windows Error Reporting utility is triggered. The technique involves modifying specific registry paths associated with the ReflectDebugger. This behavior has been documented as a persistence mechanism in malware analysis reports.

Attack Chain

The attacker gains initial access to the system through unspecified means.
The attacker attempts to modify the Windows Error Reporting ReflectDebugger registry key.
The attacker modifies the ReflectDebugger value within one of the following registry paths: HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, \REGISTRY\MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger, or MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger.
The attacker sets the ReflectDebugger value to a malicious executable or script.
The attacker triggers Werfault.exe with the -pr parameter, either manually or through a system event.
Werfault.exe executes the attacker-controlled code specified in the ReflectDebugger registry value.
The attacker achieves persistence, as the malicious code is executed each time Werfault is triggered with the -pr parameter.

Impact

Successful exploitation allows attackers to achieve persistence on the targeted system. This can lead to the execution of arbitrary code, potentially resulting in data theft, further malware installation, or complete system compromise. The impact is limited by the permissions of the Werfault process. While no specific victim counts are available, this technique can affect any Windows system where the attacker can modify the registry.

Recommendation

Deploy the Sigma rule Werfault ReflectDebugger Registry Modification to detect unauthorized modifications to the ReflectDebugger registry key (logsource: registry_set, rule title).
Enable Sysmon process creation logging to detect the execution of Werfault with the -pr parameter.
Monitor registry events for changes to the specific ReflectDebugger paths mentioned in the overview section (HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger).

Unusual System Utilities Initiating Network Connections

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

Attackers frequently exploit built-in system utilities to bypass security measures and execute malicious code. This technique, known as “Living off the Land,” allows them to blend in with legitimate system activity, making detection more challenging. This threat brief focuses on identifying unusual network connections originating from Windows system utilities that are not typically associated with network communication. This behavior is often indicative of an attacker leveraging these tools for purposes such as downloading payloads, establishing command and control, or exfiltrating data. The utilities of concern include: Microsoft.Workflow.Compiler.exe, bginfo.exe, cdb.exe, cmstp.exe, csi.exe, dnx.exe, fsi.exe, ieexec.exe, iexpress.exe, odbcconf.exe, rcsi.exe and xwizard.exe. Defenders should monitor for network activity from these processes to identify potential malicious activity.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing or exploiting a vulnerability.
The attacker leverages a system utility such as cmstp.exe to execute malicious code.
cmstp.exe is invoked with a malicious INF file, leading to the execution of arbitrary commands.
The executed code initiates a network connection to an external server.
The connection is used to download a secondary payload, such as a reverse shell or malware.
The attacker uses the downloaded payload to establish a persistent presence on the system.
The attacker performs lateral movement to other systems on the network.
The attacker exfiltrates sensitive data from compromised systems to a remote server.

Impact

A successful attack can lead to a compromised system with unauthorized code execution, data exfiltration, and potential lateral movement within the network. Due to the low severity and the high probability of false positives, this rule should be tuned for specific environments and paired with other detection mechanisms. This may lead to data breaches, financial loss, or reputational damage.

Recommendation

Implement the Sigma rules provided in this brief to detect unusual network connections from system utilities within your environment.
Monitor process execution events for the utilities listed in the rule query to identify potential abuse of these tools.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into process execution and network activity.
Correlate detections from this rule with other security alerts and logs to gain a more complete understanding of the attack.

Unusual Persistence via Services Registry Modification

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

This detection identifies processes that modify the Windows services registry key directly, bypassing the standard Windows APIs. This behavior can signify an adversary’s attempt to establish persistence stealthily by creating new services or altering existing ones in an unexpected manner. The detection logic focuses on changes to the ServiceDLL and ImagePath values within specific registry paths associated with service configurations. This rule is designed for data generated by Elastic Defend and also supports Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon Registry Events. The rule helps security analysts identify potentially malicious activity related to service manipulation, which can lead to persistent access and control over compromised systems. The rule excludes known legitimate processes and paths to minimize false positives, focusing on anomalous registry modifications.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploitation of a vulnerability).
The attacker escalates privileges to gain administrative access, allowing them to modify the registry.
The attacker directly modifies the HKLM\SYSTEM\ControlSet*\Services\*\ServiceDLL or HKLM\SYSTEM\ControlSet*\Services\*\ImagePath registry keys to point to a malicious DLL or executable.
The attacker’s malicious DLL or executable is configured to run as a service, ensuring persistence across system reboots.
The compromised service starts automatically during system startup or manually when triggered by the attacker.
The malicious service executes arbitrary code, providing the attacker with persistent control over the system.
The attacker may use the compromised service to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence on the compromised system, maintaining access even after reboots or user logoffs. This can lead to long-term control over the system, enabling attackers to perform various malicious activities, including data theft, deployment of ransomware, or use of the system as a foothold for further attacks within the network. The severity is further amplified if critical services are targeted, potentially leading to system instability or denial of service.

Recommendation

Enable Sysmon registry event logging to capture the necessary data for this detection (Data Source: Sysmon).
Deploy the provided Sigma rules to your SIEM to detect unusual service registry modifications (Sigma rules).
Tune the Sigma rules by adding exceptions for legitimate software installations or updates that modify service registry keys directly (Sigma rules).
Investigate any alerts generated by the Sigma rules, focusing on processes modifying the ServiceDLL or ImagePath registry values (Sigma rules).
Review endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future (Response and remediation).

Unusual Parent Process for cmd.exe

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

This detection rule identifies unusual parent processes spawning cmd.exe on Windows systems. While cmd.exe is a legitimate command-line interpreter, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The rule focuses on identifying cmd.exe instances spawned by uncommon parent processes like lsass.exe, csrss.exe, and regsvr32.exe, which may indicate unauthorized or suspicious activity. The rule is based on the EQL query language and is designed for data generated by Elastic Defend, Microsoft Defender XDR, and SentinelOne Cloud Funnel, as well as Sysmon event logs. This detection helps in early threat detection by flagging anomalies in process relationships.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a malicious payload on the system.
The malicious payload spawns cmd.exe to execute commands.
The cmd.exe process is launched by an unusual parent process, such as lsass.exe or csrss.exe, instead of typical processes like explorer.exe or cmd.exe.
The cmd.exe process executes malicious commands, such as downloading additional payloads, modifying system configurations, or exfiltrating data.
The attacker uses the cmd.exe process to establish persistence on the system by creating scheduled tasks or modifying registry keys.
The attacker performs lateral movement by using cmd.exe to access other systems on the network.
The attacker achieves their final objective, such as data theft, system compromise, or ransomware deployment.

Impact

A successful attack leveraging an unusual parent process for cmd.exe can lead to a range of adverse outcomes, including system compromise, data theft, and ransomware deployment. The impact can vary depending on the attacker’s objectives and the level of access they gain. Without proper detection and response, organizations can suffer financial losses, reputational damage, and operational disruption. The severity is dependent on the specific commands executed via the spawned command prompt.

Recommendation

Deploy the provided EQL query to your Elastic Security environment to detect unusual parent processes for cmd.exe.
Enable Sysmon process creation logging (Event ID 1) to capture the necessary data for this detection and ensure proper configuration.
Tune the EQL query for your environment by excluding legitimate parent processes, identified in the “False positive analysis” section, that may trigger false positives (e.g., SearchIndexer.exe, WUDFHost.exe).
Investigate any alerts generated by this rule to determine the nature of the malicious activity and the extent of the compromise.
Implement enhanced monitoring and logging for cmd.exe and its parent processes to detect similar anomalies in the future.
Consider deploying endpoint detection and response (EDR) solutions like Elastic Defend, Microsoft Defender XDR, or SentinelOne Cloud Funnel for enhanced visibility and protection.

UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer

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

This detection rule identifies a User Account Control (UAC) bypass technique that abuses the Internet Explorer Add-On Installer (ieinstal.exe) to launch malicious programs with elevated privileges. Attackers exploit elevated COM interfaces to circumvent UAC, allowing for stealthy code execution. The specific behavior involves executing a program from a temporary directory using ieinstal.exe with the -Embedding argument. This bypass can be utilized to perform various malicious activities, including installing malware, modifying system settings, or establishing persistence. The targeted systems are Windows endpoints where UAC is enabled. This technique matters because it allows attackers to gain unauthorized access with elevated permissions, undermining standard Windows security controls.

Attack Chain

The attacker gains initial access to the system, possibly through phishing or other means.
The attacker drops a malicious executable into a temporary directory, such as C:\Users\\AppData\Local\Temp\IDC*.tmp\.
The attacker invokes ieinstal.exe with the -Embedding argument, specifying the path to the malicious executable.
ieinstal.exe, running with elevated privileges, launches the malicious executable due to COM object handling.
The malicious executable executes with elevated privileges, bypassing UAC prompts.
The attacker leverages elevated privileges to perform malicious activities, such as installing malware or modifying system settings.
The attacker establishes persistence to maintain elevated access across system reboots.

Impact

Successful exploitation of this UAC bypass technique allows attackers to execute arbitrary code with elevated privileges, bypassing security controls designed to prevent unauthorized system modifications. This can lead to the installation of malware, data theft, or complete system compromise. The severity of the impact is high, as it grants attackers significant control over the affected system.

Recommendation

Deploy the Sigma rule “UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer” to your SIEM to detect potential UAC bypass attempts.
Enable Sysmon process creation logging to capture the necessary events for the Sigma rule to function correctly.
Monitor process execution from temporary directories, specifically those matching the pattern C:\\*\\AppData\\*\\Temp\\IDC*.tmp\\*.exe.
Investigate any instances of ieinstal.exe being executed with the -Embedding argument, as this is a key indicator of the UAC bypass attempt.
Implement application whitelisting to prevent unauthorized executables from running, particularly those in temporary directories.

Suspicious SolarWinds Child Process Execution

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

This detection rule identifies suspicious child processes initiated by SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, excluding known legitimate operations. Adversaries may exploit the trusted SolarWinds processes to execute unauthorized programs with elevated privileges, bypassing security controls. The rule focuses on Windows systems and is designed to detect activity indicative of post-compromise actions following a supply chain attack. This detection is crucial for organizations that utilize SolarWinds software, as malicious actors could leverage compromised SolarWinds installations to gain unauthorized access and execute arbitrary code within the network.

Attack Chain

Initial compromise of the SolarWinds software supply chain (T1195.002).
Malicious code is injected into SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe.
The compromised SolarWinds process spawns a suspicious child process.
The child process executes a malicious command or binary, attempting to evade detection.
The child process leverages Native APIs (T1106) to perform privileged actions.
Lateral movement or data exfiltration may occur from the compromised host.

Impact

A successful attack can lead to the execution of arbitrary code on systems running SolarWinds software. This can result in data theft, system compromise, and further propagation of the attack throughout the network. Organizations in various sectors utilizing SolarWinds products are potentially at risk. The impact may include loss of sensitive data, disruption of critical services, and reputational damage.

Recommendation

Deploy the Sigma rule Suspicious SolarWinds Child Process - CommandLine to detect potentially malicious child processes of SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe.
Deploy the Sigma rule Suspicious SolarWinds Child Process - Executable to detect execution of unusual executables as child processes of SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe.
Enable process creation logging with command line details on Windows systems to ensure the Sigma rules have sufficient data.
Review and tune the rules for false positives based on legitimate SolarWinds child processes in your environment, updating the exclusion lists in the rules accordingly, referencing the “false_positives” section in the rule description.

Suspicious Modifications to Windows Security Support Provider (SSP) Registry

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

Attackers can abuse the Windows Security Support Provider (SSP) mechanism to establish persistence on a compromised system. SSPs are DLLs loaded into the Local Security Authority Subsystem Service (LSASS) process, which handles authentication in Windows. By modifying specific registry keys related to SSP configuration, attackers can force LSASS to load malicious DLLs at startup, effectively creating a persistent backdoor. This technique is often used to maintain unauthorized access to a system even after a reboot. The registry keys of interest are HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages and HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages. Successful exploitation allows the attacker to intercept and manipulate authentication credentials.

Attack Chain

An attacker gains initial access to a Windows system through an exploit or compromised credentials (not detailed in source).
The attacker escalates privileges to gain administrative rights on the system.
The attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages to include a path to a malicious DLL.
Alternatively, the attacker modifies the registry key HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages to include a path to a malicious DLL.
The attacker triggers a system reboot, or restarts the LSASS process, causing the malicious SSP DLL to be loaded.
The malicious DLL intercepts authentication credentials and exfiltrates them or performs other malicious actions.
The attacker maintains persistent access to the system, even after reboots.

Impact

Successful exploitation allows attackers to achieve persistence and potentially compromise sensitive credentials handled by LSASS. This can lead to lateral movement within the network, data exfiltration, and further system compromise. The impact is significant as it bypasses standard security measures and provides a persistent foothold for malicious activities.

Recommendation

Deploy the Sigma rule “Suspicious SSP Registry Modification” to your SIEM to detect unauthorized modifications to SSP registry keys.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function.
Continuously monitor for unexpected processes writing to the HKLM\SYSTEM\*\ControlSet*\Control\Lsa\Security Packages and HKLM\SYSTEM\*\ControlSet*\Control\Lsa\OSConfig\Security Packages registry keys.
Review and whitelist legitimate software installers that frequently modify these registry entries to reduce false positives as mentioned in the brief.
Ensure access controls and permissions are strictly enforced to limit unauthorized modification of critical registry paths related to Security Support Providers.

Suspicious Execution via Windows Subsystem for Linux

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

The Windows Subsystem for Linux (WSL) enables users to run Linux binaries natively on Windows, creating an opportunity for adversaries to evade detection by executing malicious Linux commands without triggering traditional Windows security alerts. This technique involves leveraging WSL’s bash shell to perform actions that might otherwise be flagged if executed directly within the Windows environment. This alert focuses on detecting suspicious behaviors indicative of malicious use of WSL, such as unauthorized access to sensitive files, use of network tools, or unusual command-line arguments. This can be used to facilitate lateral movement, data exfiltration, or other malicious activities. The Qualys blog post “Implications of Windows Subsystem for Linux for Adversaries & Defenders” (2022-03-22) describes this attack vector in detail.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker enables WSL if it is not already enabled.
The attacker executes wsl.exe to start a Linux environment.
Inside the WSL environment, the attacker uses bash to execute malicious commands.
The attacker attempts to access sensitive files such as /etc/shadow or /etc/passwd to gather credentials.
The attacker uses network tools like curl to download or upload malicious payloads.
The attacker executes scripts to establish persistence within the WSL environment.
The attacker uses the compromised WSL environment to move laterally to other systems or exfiltrate data.

Impact

Successful exploitation via WSL can lead to a variety of negative outcomes, including unauthorized access to sensitive information, credential compromise, and lateral movement within the network. While specific victim counts are unavailable, this technique can significantly increase the attack surface and reduce the effectiveness of traditional Windows-based security measures, affecting organizations across various sectors.

Recommendation

Enable Sysmon process creation logging to capture wsl.exe and bash.exe executions (reference: Sysmon Event ID 1 setup in rule setup section).
Deploy the Sigma rule “Detect Suspicious WSL Activity” to your SIEM and tune for your environment.
Monitor process command lines for suspicious arguments used with wsl.exe, such as access to /etc/shadow or /etc/passwd (reference: Sigma rule selection criteria).
Investigate and whitelist legitimate uses of WSL within your environment to reduce false positives (reference: False positive analysis in the rule description).

Suspicious Endpoint Security Parent Process Detected

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

This detection identifies potentially malicious attempts to evade endpoint security solutions by monitoring the parent processes of security executables. Adversaries may employ process hollowing or other code injection techniques to inject malicious code into legitimate processes, such as esensor.exe or elastic-endpoint.exe, to avoid detection. The rule flags unexpected parent processes based on deviations from expected behavior, excluding known benign paths and arguments to minimize false positives. This activity is important for defenders as successful evasion can lead to significant compromise of systems and data. The rule supports various data sources, including Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon, providing broad coverage across different security ecosystems.

Attack Chain

An attacker gains initial access to the system through an unknown vector.
The attacker attempts to inject malicious code into a legitimate endpoint security process (esensor.exe or elastic-endpoint.exe).
The malicious code is injected using process hollowing or similar techniques.
The endpoint security process is launched by a suspicious parent process outside of known legitimate paths (e.g., not in C:\Program Files\Elastic\* or C:\Windows\System32\*).
The injected code executes within the context of the endpoint security process, potentially disabling or bypassing security controls.
The attacker leverages the compromised endpoint security process to perform further malicious activities, such as lateral movement or data exfiltration.
The endpoint security solution’s ability to detect and respond to threats is impaired, allowing the attacker to operate undetected.

Impact

Successful exploitation via process injection can lead to a significant degradation of endpoint security posture. Attackers can disable or bypass security controls, allowing them to perform malicious activities such as data theft, ransomware deployment, or lateral movement undetected. The impact can range from individual system compromise to widespread network breaches, depending on the scope of the attack.

Recommendation

Deploy the Sigma rule Suspicious Endpoint Security Parent Process to your SIEM to detect anomalous parent-child process relationships involving endpoint security executables.
Enable Sysmon process creation logging (Event ID 1) to provide detailed process execution data for the Sigma rule.
Investigate any alerts generated by the Sigma rule by reviewing the parent process executable path, command-line arguments, and historical activity.
Add legitimate but unusual parent process paths to the Sigma rule’s exclusion list to reduce false positives, as described in the rule’s False positive analysis section.
Correlate alerts from this rule with other security events from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon, as recommended in the rule’s Possible investigation steps section.

SolarWinds Process Disabling Services via Registry Modification

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

This threat brief focuses on the detection of SolarWinds processes attempting to disable services by modifying their registry start type. This activity is associated with defense evasion tactics, potentially linked to initial access via supply chain compromise, similar to the SUNBURST campaign. The behavior involves SolarWinds binaries, such as SolarWinds.BusinessLayerHost*.exe and NetFlowService*.exe, manipulating registry entries related to service start configurations. This technique can be used to impair or disable security tools and services, allowing attackers to operate more freely within a compromised environment.

Attack Chain

Initial compromise of the SolarWinds Orion platform, potentially through a supply chain attack.
Deployment of a malicious module or payload within the SolarWinds environment.
Execution of a SolarWinds process, such as SolarWinds.BusinessLayerHost*.exe.
The SolarWinds process modifies the registry to change the start type of a service.
The registry modification targets the HKLM\SYSTEM\ControlSet*\Services\*\Start path.
The Start value is set to “4” or “0x00000004”, which disables the targeted service.
Disabling critical security services allows the attacker to evade detection and further compromise the system.
Attacker achieves persistence and performs lateral movement, exfiltrating data or deploying ransomware.

Impact

Successful exploitation can lead to the disabling of critical security services, such as antivirus, endpoint detection and response (EDR) agents, or other monitoring tools. This can significantly reduce the visibility of malicious activity within the network, potentially leading to data breaches, ransomware deployment, or other severe security incidents. The SolarWinds supply chain compromise affected numerous organizations globally, underscoring the potential impact of this type of attack.

Recommendation

Deploy the Sigma rule SolarWinds Process Disabling Services via Registry to your SIEM to detect registry modifications by SolarWinds processes aimed at disabling services.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule to function effectively.
Review and harden access controls for SolarWinds processes to restrict their ability to modify critical system settings.
Investigate any alerts generated by the Sigma rule, focusing on the affected service and the timeline of events surrounding the registry modification.
Utilize threat intelligence platforms to stay informed about known SolarWinds-related attack patterns and indicators of compromise (IOCs).
Monitor endpoints for unusual behavior by SolarWinds processes, including network connections, file modifications, and process creations.

Signed Proxy Execution via MS Work Folders

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

Windows Work Folders is a Microsoft file server role that allows users to sync work files between their PCs and a central server. The WorkFolders.exe process, when called, will automatically execute any Portable Executable (PE) named control.exe as an argument before accessing the synced share. Attackers can abuse this functionality by placing a malicious executable renamed to control.exe in a location synced by Work Folders, and then triggering WorkFolders.exe. This can lead to the execution of arbitrary code in a manner that bypasses application control policies, as WorkFolders.exe is a signed Microsoft binary. This technique has been observed in the wild and documented by security researchers. This allows attackers to execute code from locations outside the standard Windows directories, evading traditional detection mechanisms.

Attack Chain

An attacker gains initial access to the target system through an unspecified means (e.g., phishing, exploiting a vulnerability).
The attacker places a malicious executable and renames it to control.exe in a directory accessible to Work Folders.
The attacker configures Windows Work Folders to synchronize the directory containing the malicious control.exe.
The victim system synchronizes with the Work Folders server, copying the malicious control.exe to the local machine.
The attacker triggers the WorkFolders.exe process.
WorkFolders.exe executes the control.exe binary from the synced folder.
The malicious control.exe executes, performing attacker-defined actions such as establishing persistence, escalating privileges, or deploying additional malware.
The attacker achieves code execution in a potentially elevated context, leveraging a signed Microsoft binary (WorkFolders.exe) to bypass security controls.

Impact

Successful exploitation allows attackers to execute arbitrary code on a victim’s machine, potentially bypassing application control and other security measures. This can lead to a range of malicious activities, including data theft, system compromise, and lateral movement within the network. Given the legitimate use of Work Folders, identifying malicious executions can be challenging, potentially allowing attackers to maintain a persistent foothold. The lack of specific victim counts or industry targeting details in the source material limits a complete assessment of impact scope.

Recommendation

Monitor process creations where WorkFolders.exe is the parent process and control.exe is the child process, but control.exe is not located in a standard Windows system directory (Sigma rule: “Detect Suspicious WorkFolders Control Execution”).
Investigate any instances where control.exe is executed from unusual or user-writable locations, especially if WorkFolders.exe is involved (see Attack Chain step 6).
Enable Sysmon process creation logging (Event ID 1) on Windows systems to capture the necessary data for the provided Sigma rules.
Review the Microsoft documentation on Windows Information Protection (WIP) and consider implementing it to encrypt data on PCs using Work Folders.
Implement application control policies that restrict the execution of control.exe to authorized locations (e.g., C:\Windows\System32).

Remote File Download via Desktopimgdownldr Utility

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

The desktopimgdownldr.exe utility, a legitimate Windows tool for configuring lock screen and desktop images, can be misused by adversaries to download arbitrary files from remote locations. This is achieved by leveraging the /lockscreenurl argument followed by an HTTP or HTTPS URL. This technique allows attackers to bypass traditional download restrictions and can be used to retrieve malicious payloads, tools, or scripts directly onto a compromised system. This method is particularly effective because desktopimgdownldr.exe is a signed Microsoft binary, potentially evading initial detection based on process name or file reputation. The detection rule was initially created in September 2020 and updated in May 2026. This technique is valuable for attackers seeking to transfer files without using common tools like certutil, powershell, or bitsadmin.

Attack Chain

The attacker gains initial access to the target system through an existing vulnerability, credential compromise, or social engineering.
The attacker executes desktopimgdownldr.exe with the /lockscreenurl argument, specifying a URL from which to download a malicious file.
desktopimgdownldr.exe initiates an HTTP or HTTPS request to the specified URL.
The remote server responds with the file content, which desktopimgdownldr.exe saves to disk.
The attacker then executes the downloaded file (e.g., a malicious script or executable).
The malicious code performs actions such as establishing persistence, escalating privileges, or deploying further malware.
The attacker uses the compromised system to move laterally within the network, accessing sensitive data and systems.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful exploitation allows attackers to download and execute arbitrary files on a Windows system, leading to potential compromise of the host and the network. This can result in data theft, system damage, or ransomware infection. Due to the legitimate nature of the desktopimgdownldr.exe utility, this technique can bypass security controls and detection mechanisms, increasing the likelihood of successful exploitation. While the exact number of victims is unknown, any Windows system where an attacker can execute commands is potentially vulnerable.

Recommendation

Deploy the Sigma rule “Remote File Download via Desktopimgdownldr Utility” to your SIEM to detect the execution of desktopimgdownldr.exe with the /lockscreenurl argument.
Monitor process creation events for desktopimgdownldr.exe to identify suspicious command-line arguments.
Enable Sysmon process creation logging to ensure sufficient data is available for the provided Sigma rules.
Investigate any instances of desktopimgdownldr.exe downloading files from external URLs to determine if they are malicious.
Implement application control policies to restrict the execution of unauthorized or unknown executables in sensitive environments.

Remote File Copy to a Hidden Share

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

This detection rule identifies attempts to copy files to hidden network shares in Windows environments, which can be indicative of lateral movement or data staging by malicious actors. Attackers may leverage hidden shares, typically used for legitimate administrative purposes, to move laterally within a network or to stage data for exfiltration without being easily detected. The rule focuses on detecting the use of command-line tools such as cmd.exe and powershell.exe with arguments that specify the copying of files to network paths that match a hidden share pattern (e.g., \\\\*\\\\*$). This activity helps identify suspicious file transfer operations that deviate from normal administrative or user behavior. The rule was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to a compromised host within the network.
The attacker uses cmd.exe or powershell.exe to execute a file copy command.
The command line includes arguments to copy files to a hidden network share (e.g., \\\\\\$).
The copy, move, cp, or mv commands are used to transfer the file.
The target hidden share is accessed using the compromised account’s credentials.
The file is successfully copied to the hidden share.
The attacker may then access the copied file from another compromised host.
The attacker proceeds to exfiltrate the staged data or uses the copied files for lateral movement.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement to other systems within the network, and potential data exfiltration. While the number of victims and specific sectors targeted are not specified, a successful compromise can significantly impact an organization’s data security and overall network integrity. The impact includes potential data loss, reputational damage, and disruption of normal business operations.

Recommendation

Deploy the “Detect Remote File Copy to Hidden Share” Sigma rule to your SIEM and tune for your environment to detect suspicious file copy activities.
Enable Sysmon process-creation logging to capture the command-line arguments used in file copy operations, activating the rule above.
Review and restrict permissions on network shares, especially hidden shares, to ensure only authorized users have access, as described in the investigation guide.
Investigate any alerts generated by the Sigma rule by examining the process details (cmd.exe, powershell.exe) and the network share path, as outlined in the investigation guide.
Correlate events with other logs or alerts from the same host or user to identify any additional suspicious activities, enhancing the detection capabilities.

Registry Persistence via AppInit DLL Modification

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

The AppInit DLLs mechanism allows dynamic-link libraries (DLLs) to be loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. This mechanism is intended for customization of the user interface and behavior of Windows-based applications. However, attackers can abuse this by adding malicious DLLs to the registry locations associated with AppInit DLLs. This enables them to execute code with elevated privileges, similar to process injection, and maintain a persistent presence on the compromised machine. This technique is often used to maintain access after initial compromise. Detection focuses on registry modifications to the relevant keys, excluding known legitimate processes to minimize false positives. The referenced Elastic rule was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to the system through a vulnerability, phishing, or other means.
The attacker identifies the AppInit DLLs registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows.
The attacker modifies the AppInit_DLLs registry value to include the path to their malicious DLL.
The attacker’s DLL is placed on the filesystem, typically in a location where it will persist across reboots.
Any new process that loads user32.dll will automatically load the attacker’s malicious DLL.
The malicious DLL executes arbitrary code within the context of the newly created process.
The attacker can use this code execution to perform further actions, such as installing backdoors or escalating privileges.
The attacker maintains persistent access to the system through the malicious DLL loaded into every user interface process.

Impact

Successful exploitation allows attackers to execute arbitrary code within the context of any process that loads user32.dll. This provides a persistent mechanism for maintaining access to the compromised system. The attacker gains code execution with elevated privileges, similar to process injection. This can lead to data theft, system compromise, or further lateral movement within the network. While no specific victim counts are mentioned, the widespread use of Windows makes this a potentially high-impact vulnerability.

Recommendation

Monitor registry modifications to the AppInit_DLLs value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows using the “Registry Persistence via AppInit DLL Modification” Sigma rule.
Enable Sysmon registry event logging to provide the data required for the Sigma rule to function correctly.
Deploy the “Registry Persistence via AppInit DLL Modification” Sigma rule to your SIEM and tune the filter to exclude known-good DLL paths in your environment.
Investigate any alerts triggered by the Sigma rule, focusing on the parent process and the DLL being loaded.

Registry Persistence via AppCert DLL Modification

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

The rule detects attempts to maintain persistence by creating or modifying registry keys associated with AppCert DLLs on Windows systems. AppCert DLLs are loaded by every process that uses common API functions to create processes, making them a viable target for persistence. Adversaries can exploit this by inserting malicious DLL paths into the registry, ensuring their code executes persistently across system reboots. This technique is often used for privilege escalation and persistence. The rule specifically looks for changes in the registry path HKLM\SYSTEM\ControlSet*\Control\Session Manager\AppCertDLLs\*, as well as the equivalent \\REGISTRY\\MACHINE\\SYSTEM\... path. This activity matters because it can lead to stealthy and persistent malware infections. The rule is designed for use with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, Crowdstrike, and Sysmon. The detection logic was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker obtains necessary privileges to modify the Windows Registry, potentially requiring administrator rights.
The attacker creates or modifies a registry key under HKLM\SYSTEM\ControlSet*\Control\Session Manager\AppCertDLLs\* to point to a malicious DLL.
The malicious DLL is placed on the file system, often in a location that appears legitimate or is easily accessible.
Any process that uses the standard Windows API to create new processes will load the specified DLL.
The malicious DLL executes its payload, which could include establishing persistence, injecting into other processes, or performing other malicious activities.
The attacker maintains persistence by ensuring the malicious DLL is loaded every time a new process is created.
The final objective is to maintain long-term access to the compromised system, potentially escalating privileges and moving laterally within the network.

Impact

Successful exploitation allows attackers to achieve persistent code execution on the system. This can lead to complete system compromise, data theft, or further propagation of malware within the network. The use of AppCert DLLs allows the malicious code to run in the context of nearly every process, making detection and removal more challenging. Without proper detection and response mechanisms, an attacker can maintain control of the system indefinitely.

Recommendation

Enable Sysmon registry event logging and configure it to monitor the relevant AppCertDLLs registry paths to capture the necessary events for the rules (Data Source: Sysmon).
Deploy the provided Sigma rule Detect AppCert DLL Registry Modification to your SIEM to detect unauthorized modifications to the AppCertDLLs registry keys (Rule: Detect AppCert DLL Registry Modification).
Investigate any alerts generated by the rule Detect AppCert DLL Registry Modification to determine the legitimacy of the registry modifications, using the provided triage steps as a guide.
Regularly scan systems for malicious DLLs located in the file system using updated antivirus and anti-malware tools, focusing on DLLs referenced in the AppCertDLLs registry keys.

RDP Enabled via Registry Modification

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

Attackers may enable Remote Desktop Protocol (RDP) to facilitate lateral movement within a compromised network. By modifying the fDenyTSConnections registry key to a value of 0, attackers can enable remote desktop connections, allowing them to access systems remotely. This technique can be employed using remote registry manipulation or tools like PsExec. The modification of the registry key is a common tactic used by ransomware operators and other threat actors to gain unauthorized access to victim servers. This activity can be performed to enable remote access for initial access or to regain access after persistence mechanisms have failed.

Attack Chain

An attacker gains initial access to a system via an exploit or compromised credentials.
The attacker uses a tool like PsExec or leverages remote registry modification capabilities.
The attacker modifies the fDenyTSConnections registry key, setting its value to 0. This key is typically located in HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server.
The system’s RDP service is enabled or re-enabled as a result of the registry change.
The attacker attempts to connect to the now-enabled RDP service using valid or brute-forced credentials.
Upon successful authentication, the attacker gains interactive access to the system via RDP.
The attacker performs reconnaissance, elevates privileges, and moves laterally to other systems.
The attacker deploys ransomware, exfiltrates data, or achieves other objectives.

Impact

Successful modification of the fDenyTSConnections registry key allows unauthorized remote access to systems, potentially leading to lateral movement, data theft, or ransomware deployment. Organizations could suffer significant financial losses, reputational damage, and operational disruption. The scope of the impact depends on the attacker’s objectives and the level of access they gain within the environment.

Recommendation

Deploy the Sigma rule “RDP Enabled via Registry” to detect modifications to the fDenyTSConnections registry key (rules).
Monitor process creation events for suspicious use of reg.exe or PowerShell to modify registry keys related to RDP (rules).
Implement network segmentation and firewall rules to restrict RDP traffic to authorized hosts (overview).
Review the privileges assigned to users and ensure the principle of least privilege is enforced (overview).
Enable Sysmon registry event logging to capture registry modifications (setup).
Investigate any alerts related to registry modifications on critical systems (overview).

PsExec Lateral Movement via Network Connection

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

This detection identifies the execution of PsExec, a dual-use tool commonly employed for both legitimate administration and malicious lateral movement. PsExec, part of the Sysinternals Suite, allows for remote command execution with elevated privileges, often abused by attackers to disable security controls and move laterally within a network. This rule specifically detects the creation of PsExec.exe followed by a network connection initiated by the process, which is a strong indicator of potential malicious activity. While PsExec has legitimate uses, its prevalence in attack scenarios necessitates careful monitoring. The rule is designed to work with data from Elastic Defend, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

An attacker gains initial access to a system within the network (e.g., via phishing or exploiting a vulnerability).
The attacker uploads or transfers the PsExec tool (PsExec.exe) to the compromised host, potentially using SMB shares or other file transfer methods.
The attacker executes PsExec with the -accepteula flag, which suppresses the license dialog, potentially indicating a first-time execution on the machine.
PsExec establishes a network connection to a remote target system, leveraging SMB/Windows Admin Shares (T1021.002) to facilitate remote command execution.
The attacker uses PsExec to execute commands on the remote system, potentially with SYSTEM privileges, to install malware, gather credentials, or perform reconnaissance.
The attacker leverages the newly compromised system as a pivot point to move laterally to other systems within the network, repeating the process.
The attacker escalates privileges on multiple systems.
The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to widespread compromise across the network. Attackers can leverage PsExec to gain control over critical systems, disable security controls, and exfiltrate sensitive data. Lateral movement facilitated by PsExec can enable attackers to rapidly expand their footprint within an organization, impacting numerous systems and services. While the rule’s severity is low due to the dual-use nature of PsExec, the potential impact of unchecked lateral movement is significant.

Recommendation

Deploy the Sigma rule PsExec Network Connection to your SIEM and tune the process.executable and process.parent.executable filters for your environment to reduce false positives.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into PsExec activity.
Review and enforce the principle of least privilege to limit the accounts that can run PsExec and access sensitive systems.
Investigate any alerts generated by the PsExec Network Connection rule promptly to determine if the activity is legitimate or malicious.
Monitor network connections originating from systems where PsExec is executed using the PsExec Outbound Network Connection Sigma rule.

Potential DNS Tunneling via NsLookup

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

Attackers can abuse DNS protocol for command and control and/or data exfiltration by exploiting network rules that allow DNS communication with external resources. This technique, known as DNS tunneling, involves encoding data within DNS queries to transmit commands, malicious files, or exfiltrate sensitive information to attacker-controlled DNS servers. Detection focuses on identifying anomalous patterns of nslookup.exe usage, specifically a high volume of executions with explicit query types originating from a single host within a short timeframe. This activity may bypass traditional security controls that monitor standard network traffic, enabling covert communication channels.

Attack Chain

The attacker compromises a host within the network.
The attacker executes nslookup.exe to perform DNS queries with specific query types (e.g., -querytype=TXT, -qt=A).
The attacker encodes data (commands, files, or exfiltrated data) into the DNS query.
The compromised host sends multiple DNS requests to a rogue DNS server controlled by the attacker.
The attacker receives the DNS queries and decodes the data.
The attacker uses the tunneled command to further compromise the internal network.
The attacker exfiltrates data to the attacker-controlled server.

Impact

Successful DNS tunneling allows attackers to establish covert communication channels, bypassing traditional security measures. This can lead to command and control of compromised systems, exfiltration of sensitive data, and further propagation within the network. The impact includes potential data breaches, system compromise, and prolonged attacker presence due to the difficulty in detecting covert DNS traffic.

Recommendation

Deploy the Sigma rule “Suspicious Nslookup DNS Tunneling Activity” to your SIEM to detect potential DNS tunneling attempts.
Enable Sysmon process creation logging (Event ID 1) to capture nslookup.exe executions and their command-line arguments.
Inspect network traffic logs for unusually high volumes of DNS queries originating from individual hosts.
Monitor DNS query logs for encoded or unusual data patterns within DNS query names.

Potential Credential Access via Windows Utilities

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

This rule identifies the execution of Windows utilities commonly abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. Attackers often leverage these tools to extract sensitive information, such as user credentials and domain secrets. The utilities of interest include procdump, ProcessDump.exe, WriteMiniDump.exe, RUNDLL32.EXE, RdrLeakDiag.exe, SqlDumper.exe, TTTracer.exe, ntdsutil.exe, and diskshadow.exe. The rule focuses on detecting specific command-line arguments and process names indicative of credential dumping activities. This activity is typically associated with post-exploitation phases, where attackers aim to escalate privileges and move laterally within a network. This detection is crucial for defenders as it can reveal ongoing credential theft attempts, allowing for prompt intervention and mitigation.

Attack Chain

The attacker gains initial access to a Windows system through various means, such as phishing, exploiting vulnerabilities, or using compromised credentials.
The attacker executes a privileged process, such as cmd.exe or powershell.exe, to perform reconnaissance and identify potential targets for credential dumping.
The attacker uses a utility like procdump.exe with the -ma flag to dump the LSASS process memory (procdump.exe -ma lsass.exe).
Alternatively, the attacker uses ntdsutil.exe to create an IFM (Install From Media) snapshot of the Active Directory database (ntdsutil.exe "ac i ntds" "ifm" "cr fu c:\\temp" q q).
The attacker may use diskshadow.exe with a script (/s) to create shadow copies of the system volume, potentially including the NTDS.dit file.
The attacker stages the dumped credentials or database files in a temporary directory.
The attacker compresses the staged data using archiving tools for easier transfer.
Finally, the attacker exfiltrates the compressed data to an external server for further analysis and credential harvesting.

Impact

Successful exploitation can lead to widespread credential compromise, allowing attackers to gain unauthorized access to sensitive systems and data. Credential theft can enable lateral movement within the network, privilege escalation, and ultimately, data exfiltration or ransomware deployment. The targeted dumping of LSASS memory exposes user credentials, while the extraction of the Active Directory database can compromise the entire domain. The severity of the impact depends on the scope of the compromise and the sensitivity of the affected data.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious process execution patterns indicative of credential dumping (Sigma rule: “Potential Credential Access via Procdump”).
Monitor process creation events for the execution of known credential dumping utilities with suspicious command-line arguments using the provided Sigma rules, enabling process creation logging via Sysmon (Sigma rule: “Potential Credential Access via NTDSUtil”).
Implement application control policies to restrict the execution of unauthorized or untrusted binaries, especially those associated with credential dumping, referencing the list of tools described in the Overview.
Review and harden Active Directory security configurations to prevent unauthorized access to the NTDS.dit file, using Microsoft’s security guidance.
Regularly audit and monitor systems for suspicious file creation and modification events, particularly those involving potential credential dumps, and ensure proper file integrity monitoring is enabled.

Persistence via WMI Event Subscription

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

Windows Management Instrumentation (WMI) provides a powerful framework for managing Windows systems, but adversaries can abuse its capabilities to establish persistence. By creating WMI event subscriptions, attackers can execute arbitrary code in response to defined system events. This technique involves creating event filters, providers, consumers, and bindings that automatically run malicious code. This can be achieved through tools like wmic.exe, which allows the creation of event consumers such as ActiveScriptEventConsumer or CommandLineEventConsumer. Successful exploitation of WMI for persistence allows attackers to maintain unauthorized access to a compromised system, even after reboots or other system changes. This activity has been observed across various environments, highlighting the need for robust detection mechanisms to identify and prevent WMI-based persistence.

Attack Chain

An attacker gains initial access to a Windows system through unspecified means.
The attacker uses wmic.exe to create a WMI event filter that defines a specific event to monitor.
A WMI event consumer, such as ActiveScriptEventConsumer or CommandLineEventConsumer, is created using wmic.exe specifying the malicious code or script to execute when the event occurs.
A WMI binding is established between the event filter and the event consumer using wmic.exe, linking the event to the action.
The malicious WMI event subscription is activated, monitoring for the defined event.
When the specified event occurs, the WMI service triggers the execution of the associated malicious code or script through the event consumer.
The attacker gains persistent access to the system, as the WMI event subscription will re-activate after reboots.
The attacker can then perform additional malicious activities, such as lateral movement or data exfiltration.

Impact

Successful exploitation of WMI for persistence can allow an attacker to maintain long-term, unauthorized access to a compromised system. This can result in data theft, system compromise, and further malicious activities. While the exact number of victims is not specified in the source, the broad applicability of this technique means that many Windows systems are potentially at risk. If the attack succeeds, the attacker gains a foothold on the system that is difficult to detect and remove, which can lead to significant operational disruption and financial loss.

Recommendation

Enable process creation logging and monitor for wmic.exe with command-line arguments related to creating event consumers, specifically ActiveScriptEventConsumer or CommandLineEventConsumer, to trigger the Sigma rule “Detect Suspicious WMIC Process”.
Deploy the provided Sigma rule to your SIEM to detect suspicious WMI event subscription creation.
Review the investigation steps outlined in the provided documentation to triage and analyze potential WMI persistence attempts.
Monitor Windows Security Event Logs and Sysmon for events related to WMI activity for broader coverage.