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

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.

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

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

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.

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.

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.

First Time Seen Remote Monitoring and Management Tool Execution

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

Attackers commonly abuse legitimate remote monitoring and management (RMM) tools and remote access software for command and control (C2), persistence, and execution of native commands on compromised endpoints. These tools provide attackers with the ability to maintain access, execute commands, and move laterally within a network. This detection identifies when a process associated with commonly abused RMM/remote access tools is observed for the first time on a host. The rule is designed to trigger when a new process name or code signature associated with RMM software, or a child process of such software, is seen within a configured history window. This helps defenders quickly identify potentially malicious use of legitimate tools.

Attack Chain

Initial Access: The attacker gains initial access to a target system through various methods, such as exploiting vulnerabilities or using compromised credentials.
Tool Deployment: The attacker deploys a remote monitoring and management (RMM) tool or remote access software on the compromised endpoint. This may involve downloading and installing the tool, or exploiting existing installations.
Persistence: The RMM tool is configured to run persistently on the system, ensuring that the attacker maintains access even after a reboot or other disruption. This may involve creating a service or adding a registry key to ensure the tool starts automatically.
Command and Control: The attacker uses the RMM tool to establish a command and control (C2) channel with the compromised system. This allows them to remotely execute commands, transfer files, and monitor activity on the system.
Lateral Movement: Using the RMM tool, the attacker moves laterally within the network, compromising additional systems and escalating their access. This may involve using the tool to access shared resources or execute commands on other systems.
Data Exfiltration or Ransomware Deployment: The attacker uses their access to exfiltrate sensitive data from the compromised network or deploy ransomware to encrypt files and demand a ransom payment.
Cleanup: The attacker may attempt to remove traces of their activity, such as logs or files associated with the RMM tool, to avoid detection.

Impact

Compromise via RMM tools can lead to significant data breaches, financial losses, and reputational damage. The use of legitimate tools makes detection more difficult. Successful attacks can result in ransomware deployment, data theft, and prolonged unauthorized access to sensitive systems. Organizations in all sectors are potentially at risk.

Recommendation

Deploy the process creation rule to detect the execution of RMM tools on endpoints based on process.name and process.code_signature.subject_name criteria in the query.
Enable Sysmon process creation logging (Event ID 1) to ensure the collection of necessary event data for the detection rule.
Investigate any alerts generated by the detection rule to determine whether the execution of the RMM tool is authorized and legitimate. Refer to the references for a list of commonly abused RMM tools and associated indicators.

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.

Renamed Automation Script Interpreter

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

Malware operators often rename legitimate system and scripting tools to blend in with normal system processes and bypass security measures. This rule specifically detects instances where automation script interpreters like AutoIt, AutoHotkey, and KIX32 have been renamed. By comparing the process name against the original file name embedded in the executable, this detection identifies potential attempts to masquerade malicious scripts as legitimate software. This technique is employed to bypass application whitelisting and other security controls that rely on file names or process names for identification and authorization. This detection is relevant for any Windows environment where these scripting tools are used, as it can highlight potentially malicious activity masked by a common evasion technique.

Attack Chain

An attacker gains initial access to the system, often through phishing or exploiting a software vulnerability.
The attacker uploads or drops a malicious script (e.g., AutoIt, AutoHotkey, or KIX32 script) onto the target machine.
The attacker renames the legitimate AutoIt, AutoHotkey, or KIX32 interpreter executable to a non-standard name (e.g., “svchost.exe” or “wininit.exe”) to masquerade as a legitimate process.
The attacker executes the renamed interpreter, which in turn executes the malicious script.
The script performs malicious actions, such as downloading additional malware, modifying system settings, or establishing persistence.
The attacker uses the compromised system for lateral movement within the network or for data exfiltration.
The attacker attempts to maintain persistence on the system to ensure continued access.

Impact

Successful renaming of script interpreters allows attackers to execute malicious scripts undetected, potentially leading to data theft, system compromise, or further propagation within the network. The impact can range from minor disruption to significant financial loss and reputational damage, depending on the attacker’s objectives and the sensitivity of the compromised data.

Recommendation

Deploy the Sigma rule “Renamed AutoIt Interpreter” to your SIEM to detect when AutoIt executables are renamed, focusing on process.pe.original_file_name and process.name.
Deploy the Sigma rule “Renamed AutoHotkey Interpreter” to your SIEM to detect when AutoHotkey executables are renamed, focusing on process.pe.original_file_name and process.name.
Enable Sysmon process creation logging to capture the necessary process metadata, as referenced in the rule logsource.
Investigate any alerts generated by these rules to determine the legitimacy of the renamed executable and its associated activity as described in the note section.

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.

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.

Suspicious Script Object Execution via scrobj.dll

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

This detection identifies suspicious usage of scrobj.dll, a legitimate Windows library, when loaded into unusual Microsoft processes. Attackers may exploit scrobj.dll to execute malicious scriptlets within trusted processes, thereby evading detection. This technique allows adversaries to proxy execution through trusted system binaries. The rule focuses on detecting anomalous activity by excluding common executables, and flagging only non-standard processes loading scrobj.dll. The detection logic is based on identifying image load events where scrobj.dll is loaded into unexpected processes, indicating a potential misuse of the library. The rule is designed for data generated by Elastic Defend, Elastic Endgame, and Sysmon.

Attack Chain

An attacker gains initial access to a Windows system through various means.
The attacker crafts or deploys a malicious scriptlet designed to execute malicious commands or payloads.
The attacker leverages a non-standard or less common Microsoft process to load scrobj.dll.
scrobj.dll is loaded into the target process, enabling the execution of scriptlets.
The malicious scriptlet executes within the context of the trusted Microsoft process, bypassing application whitelisting or other security controls.
The scriptlet performs malicious actions, such as downloading additional payloads, modifying system configurations, or establishing command and control communication.
The attacker achieves their objectives, such as data exfiltration, lateral movement, or persistence.

Impact

Successful exploitation allows attackers to execute arbitrary code within the context of a trusted process, bypassing security controls and potentially leading to full system compromise. This could result in data theft, system corruption, or further propagation of the attack within the network. The impact is significant because it allows malware to operate under the guise of legitimate system processes.

Recommendation

Deploy the Sigma rule Suspicious Scrobj.dll Image Load to your SIEM to detect this activity (see rule below).
Enable Sysmon Event ID 7 (Image Loaded) to collect the necessary data for the Sigma rule.
Investigate any alerts generated by the Sigma rule Suspicious Scrobj.dll Image Load to determine the legitimacy of the scrobj.dll loading activity.
Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on processes identified in the detection rule.
Continuously audit scheduled tasks and exclude known safe processes from the detection rule to minimize false positives, as described in the rule’s Triage and Analysis section.

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.

Microsoft Defender Tampering via Registry Modification

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

Attackers commonly disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior within compromised Windows environments. This is often achieved by modifying specific registry keys that control the behavior and functionality of Defender components, such as real-time monitoring, exploit protection, and tamper protection itself. Such actions can significantly reduce the effectiveness of endpoint security, allowing malicious activities to proceed undetected. The references point to techniques that disable PUA protection, tamper protection, memory integrity, and real-time protection. This behavior is observed across various attack scenarios, including ransomware deployment and cryptocurrency mining campaigns.

Attack Chain

Initial access is gained through an unspecified vector (e.g., phishing, exploitation of a vulnerability).
The attacker obtains elevated privileges on the system.
The attacker uses an administrative tool like reg.exe or PowerShell to modify the registry.
The attacker disables real-time monitoring by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableRealtimeMonitoring to 1.
The attacker disables tamper protection by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Features\TamperProtection to 0.
The attacker disables PUA Protection by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\PUAProtection to 0.
With Defender weakened, the attacker executes malicious payloads, such as ransomware or cryptocurrency miners.

Impact

Successful tampering with Microsoft Defender can lead to a significant degradation of endpoint security posture. This can result in undetected malware infections, data breaches, and system compromise. Disabling Defender features can allow attackers to establish persistence, escalate privileges, and deploy malicious payloads without triggering alerts. The impact can range from individual system compromise to widespread network infection, depending on the attacker’s objectives and the extent of the tampering.

Recommendation

Deploy the Sigma rule “Microsoft Windows Defender Tampering - Disable Realtime Monitoring” to your SIEM to detect modifications to the DisableRealtimeMonitoring registry value.
Deploy the Sigma rule “Microsoft Windows Defender Tampering - Disable Tamper Protection” to detect modifications to the TamperProtection registry value.
Monitor registry modification events, specifically targeting keys associated with Microsoft Defender settings as described in the rule query.
Investigate any process modifying Windows Defender registry settings that are not explicitly authorized, referencing the process exclusions in the rule query.

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.

Suspicious Unshare Usage for Namespace Manipulation

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

The unshare command in Linux is a utility used to create new namespaces, providing isolation for processes. While crucial for containerization and security, attackers can misuse unshare to escape container boundaries or escalate privileges by manipulating system namespaces. This occurs by creating namespaces that bypass established security controls. This activity is often observed when threat actors attempt to gain unauthorized access to host resources or elevate their privileges within a compromised system. The focus of this detection is on identifying unusual unshare executions that deviate from legitimate system management activities.

Attack Chain

An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability in a containerized application.
The attacker executes the unshare command.
unshare creates new namespaces, isolating the attacker’s process from the rest of the system.
The attacker attempts to mount sensitive directories from the host system into the new namespace.
Using the newly gained access, the attacker attempts to modify system files, such as /etc/passwd or /etc/shadow, to create new privileged accounts.
The attacker leverages the elevated privileges to install persistent backdoors or malware on the host system.
The attacker attempts to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or system disruption.

Impact

Successful exploitation via unshare can lead to privilege escalation, container escape, and unauthorized access to sensitive resources on the host system. The impact includes potential data breaches, system compromise, and lateral movement within the network. While the number of victims is unknown, the widespread use of containerization technologies makes this a significant threat, particularly for organizations relying on Linux-based container environments and cloud infrastructures.

Recommendation

Deploy the Sigma rule Namespace Manipulation Using Unshare to your SIEM to detect suspicious unshare command executions and tune for your environment.
Enable Auditbeat or Elastic Defend to collect the necessary process execution data to trigger the provided Sigma rule, as outlined in the rule’s setup section.
Review and tune the provided Sigma rule’s exclusion list based on your environment’s legitimate use cases for unshare, as described in the “False positive analysis” section.
Implement additional monitoring and alerting for unusual unshare usage patterns to enhance detection capabilities and prevent future occurrences as recommended in the “Response and remediation” section.

Potential Protocol Tunneling via Yuze

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

This rule detects the execution of Yuze, an open-source tunneling tool written in C, which is commonly used for intranet penetration. Yuze supports both forward and reverse SOCKS5 proxy tunneling and is often executed using rundll32 to load yuze.dll with the RunYuze export. Threat actors can leverage Yuze to proxy command and control (C2) communications or to pivot within a network. The detection focuses on identifying processes with command-line arguments indicative of Yuze execution, specifically those involving “reverse,” “-c,” “proxy,” “fwd,” and “-l” parameters. This activity has been observed in real-world campaigns, increasing the importance of timely detection and response.

Attack Chain

The attacker gains initial access to a target system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker uploads or drops the yuze.dll file onto the compromised host.
The attacker uses rundll32.exe to execute yuze.dll, calling the RunYuze export.
The command line includes parameters to establish a reverse or forward SOCKS5 proxy tunnel (e.g., rundll32 yuze.dll,RunYuze reverse -c :).
Yuze establishes a tunnel to a remote server, allowing the attacker to proxy network traffic.
The attacker uses the established tunnel to pivot within the network and access internal resources.
The attacker may proxy C2 traffic through the tunnel, masking the true origin of the commands.
The attacker performs actions on the internal network, such as data exfiltration or lateral movement, using the tunnel as a covert channel.

Impact

Successful exploitation allows attackers to establish covert communication channels, bypass network security controls, and proxy malicious traffic, potentially leading to unauthorized access to sensitive data, lateral movement within the network, and data exfiltration. The use of Yuze can obscure the origin of attacks, making attribution more difficult and hindering incident response efforts.

Recommendation

Deploy the Sigma rule “Potential Yuze Tunneling via Rundll32” to your SIEM to detect the execution of yuze.dll via rundll32.exe with specific command-line arguments.
Enable process creation logging (Sysmon Event ID 1 or Windows Security Auditing) to capture the necessary command-line information for the Sigma rules.
Investigate any identified instances of rundll32.exe executing yuze.dll, focusing on the parent processes and network connections.
Block the C2/relay IP or domain found in the -c argument at DNS/firewall, as described in the Triage and Analysis section of the rule’s note.