Crowdstrike — CraftedSignal Threat Feed

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.

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.

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).

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.

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.

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.

Executable File Creation with Multiple Extensions

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

Adversaries may use masquerading techniques to evade defenses and blend into the environment by manipulating the name or location of a file, tricking users into executing malicious code disguised as a benign file type. This rule detects the creation of executable files with multiple extensions, a common method of masquerading. The rule focuses on identifying suspicious file creations that use misleading extensions, specifically targeting files with an “.exe” extension preceded by common benign extensions. It excludes known legitimate processes to minimize false positives. This activity is relevant for defenders to identify potential threats where adversaries attempt to bypass security measures by disguising malicious files.

Attack Chain

An attacker crafts a malicious executable file with a double extension (e.g., “document.pdf.exe”).
The attacker delivers the malicious file to the target system via phishing or other means.
The user downloads or receives the file and attempts to open it.
Windows displays the file with the first extension (“document.pdf”) by default, misleading the user.
Upon execution, Windows recognizes the “.exe” extension and executes the file.
The malicious executable runs, potentially deploying malware or performing other unauthorized actions.
The malware establishes persistence or attempts lateral movement within the network.
The attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to malware infection, data breaches, and system compromise. This technique bypasses common file type restrictions and user awareness, potentially affecting a wide range of users and systems. While the number of victims is not specified, the impact can be significant, particularly in organizations where users handle sensitive data. The affected sectors are broad, encompassing any organization where users are susceptible to social engineering attacks.

Recommendation

Deploy the Sigma rule “Executable File Creation with Multiple Extensions” to your SIEM and tune for your environment to detect the creation of suspicious files with multiple extensions.
Enable Sysmon Event ID 11 (File Create) for comprehensive file creation monitoring to improve the effectiveness of the detection rule.
Implement enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities.
Educate users on the risks associated with double file extensions and encourage caution when opening attachments from unknown sources.
Review and whitelist legitimate software installations that may create executables with multiple extensions to reduce false positives, as described in the rule’s triage notes.

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.

Process Activity via Compiled HTML File Execution

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

Attackers are known to deliver malicious payloads within compiled HTML files (.chm) to bypass security measures and gain initial access to systems. This technique leverages the Microsoft HTML Help system and its associated executable, hh.exe, to proxy the execution of malicious code. Compiled HTML files can contain various types of content, including HTML documents, images, and scripting languages like VBA, JScript, Java, and ActiveX. By embedding malicious scripts or executables within a .chm file, attackers can trick users into executing them when they open the file. This is particularly effective because hh.exe is a signed binary, which may allow it to bypass certain security controls. The scope of this technique affects Windows systems where the HTML Help system is installed.

Attack Chain

The attacker crafts a malicious .chm file containing embedded malicious code, such as a PowerShell script or executable.
The attacker delivers the .chm file to the victim via social engineering, such as phishing or malicious websites.
The victim opens the .chm file, causing hh.exe to launch.
hh.exe processes the .chm file, rendering its content, which includes the embedded malicious script or executable.
The malicious code executes, often spawning a scripting interpreter like powershell.exe or cmd.exe.
The scripting interpreter executes commands to download additional payloads or perform malicious actions on the system.
The attacker gains initial access to the victim’s system.
The attacker escalates privileges and moves laterally within the network.

Impact

Successful exploitation can lead to initial access, code execution, and potentially full system compromise. This can result in data theft, malware installation, and further lateral movement within the network. The severity and impact depend on the permissions of the user running hh.exe and the nature of the malicious payload.

Recommendation

Deploy the Sigma rule “Compiled HTML File Spawning Suspicious Processes” to your SIEM to detect instances where hh.exe is the parent process of scripting interpreters.
Enable Sysmon process creation logging to provide the necessary data for the Sigma rule to function correctly.
Monitor process execution chains for unknown processes originating from hh.exe, as mentioned in the investigation guide.
Implement email filtering and security awareness training to prevent users from opening malicious .chm files delivered via phishing.
Block the execution of unsigned or untrusted executables in the environment to reduce the risk of malicious code execution.
Use endpoint detection and response (EDR) solutions like Elastic Defend, CrowdStrike, Microsoft Defender XDR, and SentinelOne to detect and respond to malicious activity.

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.

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

Suspicious Mofcomp Activity

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

The rule detects suspicious usage of mofcomp.exe, a command-line tool used to compile Managed Object Format (MOF) files. Attackers can abuse MOF files to manipulate the Windows Management Instrumentation (WMI) repository by building malicious WMI scripts for persistence or execution. This can be achieved by creating their own namespaces and classes within WMI or establishing persistence through WMI Event Subscriptions. The rule identifies unusual mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes like ScenarioEngine.exe and system accounts (S-1-5-18). This detection is designed to work with data from Elastic Defend, Microsoft Defender XDR, Crowdstrike, and Windows Security Event Logs. The rule aims to detect potential misuse of WMI for malicious purposes, enhancing the visibility of attacker techniques for execution and persistence.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).
The attacker uploads a malicious MOF file to the compromised system.
The attacker executes mofcomp.exe to compile the malicious MOF file.
mofcomp.exe processes the MOF file, creating new namespaces and classes or modifying existing ones in the WMI repository.
If the MOF file creates a WMI Event Subscription, it triggers the execution of a malicious script or binary when a specific event occurs.
The malicious script or binary executes, performing actions such as installing malware, creating backdoors, or exfiltrating data.
The attacker maintains persistence through the WMI Event Subscription, ensuring continued access even after system reboots.

Impact

Successful exploitation via malicious MOF files can lead to persistent access, code execution, and system compromise. Attackers can use this technique to install malware, create backdoors, or steal sensitive data. The rule aims to detect early stages of such attacks, preventing significant damage. By establishing persistence, attackers can maintain long-term control over the compromised system, evading traditional detection methods.

Recommendation

Deploy the provided Sigma rules to your SIEM to detect suspicious mofcomp.exe activity and tune for your environment.
Enable process creation logging and command-line auditing on Windows systems to capture necessary events for the provided Sigma rules.
Investigate any alerts generated by the Sigma rules, focusing on unusual MOF file paths, parent processes, and user accounts.
Review and monitor WMI namespaces and classes for unauthorized modifications or additions following any detected suspicious mofcomp.exe activity.

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).

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.

Rare Connection to WebDAV Target via Rundll32

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

Attackers can exploit WebDAV by injecting WebDAV paths into files or features opened by a victim user, leading to NTLM credential leakage through forced authentication. This technique relies on the victim’s system attempting to authenticate against a malicious WebDAV server when accessing a file or link containing a WebDAV path. This threat is particularly relevant for defenders because it can lead to unauthorized access to sensitive information and potential lateral movement within the network. The attack leverages rundll32.exe to initiate the WebDAV connection, making it difficult to distinguish from legitimate system processes. The Elastic detection rule identifies rare WebDAV connection attempts to uncover potential credential access attempts.

Attack Chain

An attacker crafts a malicious document or link containing a WebDAV path.
The victim user opens the malicious document or clicks the link.
The operating system attempts to resolve the WebDAV path using rundll32.exe and the DavSetCookie function.
The system initiates an authentication attempt with the malicious WebDAV server.
The attacker captures the NTLM credentials during the authentication handshake.
The attacker relays the captured NTLM credentials to access internal resources.

Impact

Successful exploitation leads to credential compromise and potential lateral movement within the victim’s network. An attacker could gain unauthorized access to sensitive data and systems, potentially leading to data exfiltration, system compromise, or further attacks. This can impact organizations of any size and industry that rely on NTLM authentication. The severity depends on the user’s permissions and the resources they can access with their compromised credentials.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect suspicious WebDAV connections initiated via rundll32.exe.
Investigate any alerts generated by the Sigma rule, focusing on rare or unusual WebDAV destinations.
Monitor process creation events for rundll32.exe with command-line arguments containing “DavSetCookie”, focusing on connections to external domains.
Conduct regular security awareness training to educate users about the risks of opening unsolicited documents or clicking suspicious links.

New ActiveSync Allowed Device Added via PowerShell

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

This detection identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a new ActiveSync allowed device. Attackers may target user email to collect sensitive information by adding unauthorized devices to a user’s allowed ActiveSync devices. The rule focuses on detecting suspicious PowerShell activity by monitoring for specific command patterns indicative of unauthorized device additions. This activity can lead to persistent access to sensitive email data, bypassing normal authentication controls. The original Elastic detection rule was created on 2020/12/15 and updated on 2026/05/04. This matters for defenders because it highlights a persistence mechanism that can be difficult to detect through traditional means.

Attack Chain

An attacker gains initial access to a privileged account with Exchange management permissions.
The attacker uses PowerShell to execute the Set-CASMailbox cmdlet.
The attacker modifies the ActiveSyncAllowedDeviceIDs attribute for a target user’s mailbox.
The attacker adds a rogue device ID to the list of allowed devices.
The attacker configures a mobile device with the rogue device ID to synchronize with the target mailbox.
The attacker gains persistent access to the target user’s email, calendar, and contacts.
The attacker exfiltrates sensitive data from the mailbox.
The attacker maintains persistence even after password changes by continuing to synchronize via the added device.

Impact

Successful exploitation could lead to unauthorized access to sensitive email data, including confidential communications, financial information, and personal data. This can result in data breaches, compliance violations, and reputational damage. The scope of the impact depends on the privileges of the compromised account and the sensitivity of the data contained in the targeted mailboxes.

Recommendation

Deploy the Sigma rule ActiveSyncAllowedDeviceID Added via PowerShell to your SIEM and tune for your environment to detect suspicious activity.
Enable Sysmon process-creation logging to capture PowerShell commands for the rule above.
Review Exchange audit logs for instances of Set-CASMailbox being used to modify ActiveSyncAllowedDeviceIDs.
Implement multi-factor authentication (MFA) for all accounts, especially those with Exchange management privileges.
Regularly audit ActiveSync device configurations to identify unauthorized devices.

MSBuild Started by System Process for Defense Evasion and Execution

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

The Microsoft Build Engine (MSBuild) is a legitimate tool used by developers to build applications. However, adversaries are known to abuse MSBuild to execute malicious code, leveraging its trusted status to bypass security measures. This technique allows attackers to perform various actions on compromised systems while blending in with legitimate system activity. The observed behavior involves MSBuild being started by system processes like Explorer (explorer.exe) or Windows Management Instrumentation (WMI, wmiprvse.exe). Defenders should be aware of this unusual activity as it signifies a potential defense evasion tactic and unauthorized code execution within the targeted environment. This activity has been observed across environments leveraging Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, CrowdStrike, and standard Windows event logging.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker leverages a script or payload that invokes MSBuild.exe.
The script or payload is executed by a system process like explorer.exe or wmiprvse.exe, which is highly unusual for typical MSBuild usage.
MSBuild.exe starts with specific command-line arguments that dictate the build process, often involving malicious code.
The malicious code is embedded within an MSBuild project file (.csproj or similar).
MSBuild.exe executes the malicious code as part of the build process.
The executed code performs actions such as downloading additional payloads, modifying system configurations, or establishing persistence.
The attacker achieves their objective, such as gaining remote access, exfiltrating data, or deploying ransomware.

Impact

Successful exploitation can lead to a variety of negative outcomes, including unauthorized code execution, system compromise, data theft, and potentially complete system takeover. The use of MSBuild as a proxy execution method allows attackers to evade traditional security controls and blend in with legitimate system activities. This can result in delayed detection and increased dwell time, amplifying the potential damage. Since MSBuild is a trusted Microsoft utility, its abuse can make malicious activity harder to identify and respond to.

Recommendation

Deploy the Sigma rule “Microsoft Build Engine Started by a System Process” to your SIEM to detect instances of MSBuild.exe being launched by explorer.exe or wmiprvse.exe (see rules section).
Enable process creation logging with command line arguments to capture the full context of MSBuild.exe executions (reference setup instructions in the source URL).
Investigate any instances of MSBuild.exe started by explorer.exe or wmiprvse.exe to determine if they are legitimate or malicious.
Implement enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response.
Review and whitelist any legitimate scripts or administrative tools that leverage MSBuild for authorized tasks to reduce false positives.

Encoded Executable Stored in the Registry

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

This detection identifies Windows Registry modifications used to conceal encoded portable executables, a tactic employed by adversaries to evade traditional disk-based detection mechanisms. The rule focuses on detecting registry entries with data strings that match known encoded executable patterns. This technique allows attackers to store malicious code within the registry, making it more difficult to detect using standard file-based scanning methods. The rule is designed to work with Elastic Defend, but also supports data from third-party EDR solutions, including CrowdStrike, Microsoft Defender XDR, and SentinelOne. The detection logic focuses on identifying registry entries with data resembling encoded executables.

Attack Chain

An attacker gains initial access to the system (e.g., through compromised credentials or exploiting a vulnerability).
The attacker uses a command-line tool, such as PowerShell or cmd.exe, to interact with the registry.
The attacker encodes a malicious executable using tools like certutil or custom encoding scripts.
The attacker creates or modifies a registry key using reg.exe or PowerShell’s Set-ItemProperty cmdlet.
The encoded executable is written to the registry key’s data value. The data string often starts with “TVqQAAMAAAAEAAAA*”.
The attacker uses another script or command to decode the executable from the registry.
The decoded executable is then executed in memory or written to disk for execution.
The attacker achieves their final objective, such as establishing persistence, escalating privileges, or deploying ransomware.

Impact

Successful exploitation allows attackers to evade traditional disk-based security measures, enabling them to execute malicious code undetected. Attackers can use this technique to establish persistence, escalate privileges, or deploy malware, including ransomware. The rule helps defenders identify systems where this defense evasion technique is being employed.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect encoded executables stored in the registry.
Enable Sysmon registry event logging to provide the necessary data for the provided Sigma rules.
Investigate any alerts triggered by the Sigma rules to determine if the registry modification is malicious.
Use endpoint detection and response (EDR) tools to further analyze suspicious processes associated with the registry modifications.
Implement application control policies to prevent the execution of unauthorized executables, even if they are decoded from the registry.

Disabling LSA Protection via Registry Modification

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

Local Security Authority (LSA) protection is a security feature in Windows that prevents unauthorized processes from accessing sensitive information stored in LSASS memory. This protection is enabled through the RunAsPPL registry key. Adversaries may attempt to disable LSA protection by modifying this registry key, allowing them to more easily access credentials stored in LSASS. This technique can be used as part of a broader attack to escalate privileges and move laterally within a network. The rule detects modifications to the RunAsPPL registry key that weaken LSA protection. This involves monitoring changes to the registry path *\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL and alerting when the registry data does not contain values that enable protected LSASS modes (“1”, “0x00000001”, “2”, “0x00000002”).

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker escalates privileges to an administrator account, if necessary, to gain the required permissions to modify the registry.
The attacker modifies the RunAsPPL registry key located at HKLM\System\CurrentControlSet\Control\Lsa (or similar path under ControlSet00x) to a value that disables LSA protection (e.g., setting it to 0). This is often achieved using tools like reg.exe or PowerShell.
The attacker may stage the system for a reboot to apply the registry change.
After the system reboots, LSASS starts without Protected Process Light (PPL) protection, allowing the attacker to access its memory.
The attacker uses credential dumping tools like Mimikatz to extract credentials from the unprotected LSASS process.
The attacker uses the stolen credentials to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful disabling of LSA protection allows attackers to easily extract credentials from LSASS memory. This can lead to widespread compromise of user and service accounts, enabling lateral movement and privilege escalation within the network. The impact could range from data breaches and financial loss to complete system compromise and disruption of critical services.

Recommendation

Enable Sysmon registry event logging to detect changes to the RunAsPPL registry key (Data Source: Sysmon).
Deploy the Sigma rule “Disabling Lsa Protection via Registry Modification” to your SIEM to detect malicious modifications to the RunAsPPL registry key.
Investigate any alerts generated by the Sigma rule, focusing on the process making the change, the user account, and any associated processes (see the “investigation_fields” in the source).
Monitor for unusual process activity after registry modifications, such as the execution of credential dumping tools (e.g., Mimikatz).
Regularly review and enforce the principle of least privilege to minimize the number of accounts with permissions to modify sensitive registry keys.
Use host isolation when unauthorized LSA-protection weakening is detected and confirmed.

Command Obfuscation via Unicode Modifier Letters

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

Attackers are increasingly employing Unicode modifier letters to obfuscate command-line arguments, thereby bypassing traditional string-based detection mechanisms. This technique involves replacing standard ASCII characters with visually similar Unicode characters, making it difficult for simple pattern-matching rules to identify malicious commands. The obfuscation targets common Windows utilities such as reg.exe, net.exe, certutil.exe, PowerShell.exe, cmd.exe, and others frequently abused in post-exploitation scenarios. Defenders need to implement more sophisticated detection methods that account for Unicode normalization or character range analysis to identify and mitigate this threat. This technique has become more prevalent in the last year as attackers seek to evade common detection strategies.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
Execution: The attacker executes a command-line utility like cmd.exe or powershell.exe to perform malicious actions.
Obfuscation: The command-line arguments are obfuscated by replacing ASCII characters with Unicode modifier letters.
Defense Evasion: The obfuscation allows the attacker to evade simple string-based detections that would normally flag the command as malicious.
Privilege Escalation: The attacker may use the obfuscated command to escalate privileges or gain access to sensitive resources.
Persistence: The attacker may establish persistence by creating a scheduled task or modifying the registry using obfuscated commands.
Lateral Movement: The attacker may use the obfuscated command to move laterally to other systems on the network.

Impact

Successful command obfuscation can lead to a significant compromise of Windows systems. Attackers can bypass security controls and execute malicious code undetected, potentially leading to data theft, system disruption, or ransomware deployment. The obfuscation makes it harder for security teams to identify and respond to attacks, increasing the dwell time and potential damage.

Recommendation

Deploy the Sigma rule provided below to detect the presence of Unicode modifier letters in command lines (references: Sigma rules).
Enable Sysmon process creation logging to capture command-line arguments for analysis (references: Sysmon setup instructions).
Investigate any alerts triggered by the Sigma rule and analyze the raw command lines to identify the true intent of the command (references: Triage and Analysis section of the source).
Consider implementing Unicode normalization techniques to remove the obfuscation before analyzing command lines.
Monitor the listed processes (reg.exe, net.exe, certutil.exe, etc.) more closely for suspicious activity.

Control Panel Process with Unusual Arguments

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

This detection rule identifies unusual instances of Control Panel being executed with suspicious keywords or paths in the process command line. Control Panel (control.exe) is a legitimate Windows utility, but adversaries may abuse it to proxy execution of malicious code, effectively bypassing defense mechanisms. This technique involves launching control.exe with command-line arguments that point to malicious payloads or unusual file types, such as image files or INF files, or paths containing traversal sequences. The rule is designed to trigger when control.exe is launched with suspicious arguments like image files, INF files, paths containing traversal sequences, or paths in user-writable locations.

Attack Chain

An adversary gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The adversary stages a malicious payload on the system in a location such as AppData\Local or Users\Public.
The adversary crafts a command line that uses control.exe to execute the malicious payload. The command line includes a suspicious path, such as control.exe evil.jpg or control.exe ..\..\..\evil.dll.
The control.exe process is executed with the malicious command line.
Control.exe attempts to load the specified file.
If the file is an executable or script, it is executed within the context of the control.exe process.
The malicious code performs its intended actions (e.g., downloading additional payloads, establishing persistence, or exfiltrating data).
The adversary achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution, allowing adversaries to install malware, steal sensitive data, or compromise the entire system. This can result in significant financial loss, reputational damage, and disruption of business operations. Because Control Panel is a signed Microsoft binary, abusing it can bypass application control policies.

Recommendation

Deploy the Sigma rule “Control Panel Process with Unusual Arguments” to your SIEM to detect suspicious control.exe command lines (rule).
Enable Sysmon process creation logging to capture the command-line arguments of control.exe (logsource).
Monitor process execution events for instances of control.exe launching child processes (rule).
Investigate any alerts generated by the Sigma rule, focusing on the parent process, command-line arguments, and any subsequent network connections (rule).
Implement application control policies to restrict the execution of control.exe from unusual locations (overview).

Suspicious .NET Code Compilation via Unusual Parent Processes

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

Attackers sometimes deliver malicious code in a non-executable format to bypass initial security checks. They then use legitimate .NET compilers like csc.exe (C#) and vbc.exe (VB.NET) to compile the code into an executable on the victim machine. This technique, known as “Compile After Delivery”, helps them evade traditional signature-based detections. This activity is often launched from scripting engines or system utilities, such as wscript.exe, mshta.exe, cmstp.exe, regsvr32.exe and others. The rule detects these unusual parent-child process relationships, providing an alert for potential post-delivery code compilation activity, and applies to Windows environments.

Attack Chain

An attacker gains initial access via an unspecified method.
The attacker delivers obfuscated or encoded .NET source code to the target system.
The attacker uses a scripting engine (e.g., wscript.exe, mshta.exe, cscript.exe) or system utility (e.g., wmic.exe, regsvr32.exe, cmstp.exe) to execute a .NET compiler (csc.exe or vbc.exe).
The scripting engine or system utility passes the delivered .NET source code as an argument to the compiler.
The .NET compiler compiles the source code into a binary executable.
The attacker executes the compiled binary.
The compiled binary performs malicious actions, such as establishing persistence, lateral movement, or data exfiltration.

Impact

Successful exploitation allows attackers to execute arbitrary code on the target system, bypassing security measures that rely on pre-execution scanning. This can lead to a range of malicious activities, including data theft, system compromise, and deployment of ransomware. Detecting and preventing this technique is crucial for maintaining the integrity and confidentiality of systems.

Recommendation

Enable process creation logging via Windows Security Event Logs or Sysmon (Event ID 1) to capture process execution data needed for the detection rule.
Deploy the Sigma rule “Suspicious .NET Code Compilation” to your SIEM to detect instances of .NET compilers being executed by unusual parent processes.
Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes, as described in the rule’s documentation.
Monitor process execution for the parent processes listed in the Sigma rule’s detection criteria (e.g., wscript.exe, mshta.exe, cmstp.exe, regsvr32.exe) for unusual command-line arguments.

Netsh Used to Enable Remote Desktop Protocol (RDP) in Windows Firewall

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

Attackers can leverage the native Windows command-line tool netsh.exe to modify Windows Firewall rules and enable inbound Remote Desktop Protocol (RDP) connections. This can be used as a defense evasion technique to bypass existing firewall restrictions, allowing them to establish remote access to a compromised host. Ransomware operators and other malicious actors frequently utilize RDP to access victim servers, often using privileged accounts, to further their objectives. This activity can be conducted post-compromise to facilitate lateral movement and the deployment of malicious payloads. The behavior was observed being detected by Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Crowdstrike.

Attack Chain

An attacker compromises a Windows host through initial access methods (e.g., phishing, exploitation of a vulnerability).
The attacker gains a foothold on the system and escalates privileges as needed.
The attacker executes netsh.exe with specific arguments to modify the Windows Firewall configuration.
The netsh command creates or modifies an inbound rule to allow RDP traffic (TCP port 3389).
The attacker establishes an RDP connection to the compromised host.
The attacker uses the RDP session to perform reconnaissance, move laterally, or deploy malware.
The attacker may attempt to disable or modify security tools to further evade detection.
The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation of this technique can lead to unauthorized remote access to systems, enabling lateral movement, data theft, and ransomware deployment. If RDP is enabled on a large number of systems, the attacker can move laterally through the environment. The impact can range from data breaches to complete operational disruption.

Recommendation

Monitor process creation events for netsh.exe executing with arguments related to enabling inbound RDP traffic using the “Remote Desktop Enabled in Windows Firewall by Netsh” rule.
Implement the Sigma rule provided below to detect instances of netsh.exe being used to modify firewall rules related to RDP.
Enforce the principle of least privilege and restrict the use of netsh.exe to authorized personnel only.
Review existing firewall rules and remove any unnecessary or overly permissive rules.
Enable Sysmon process creation logging for enhanced visibility into process execution events.