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

Remote Desktop File Opened from Suspicious Path

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

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

Attack Chain

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

Impact

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

Recommendation

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

Detection of VScode Remote Tunneling for Command and Control

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

This detection focuses on identifying the misuse of Visual Studio Code’s (VScode) remote tunnel feature to establish unauthorized access or control over systems. While the VScode remote tunnel feature is designed to allow developers to connect to remote environments seamlessly, attackers can abuse this functionality for malicious purposes. The rule specifically looks for the execution of the VScode portable binary with the “tunnel” command-line option, which is indicative of an attempt to establish a remote tunnel session to either GitHub or a remote VScode instance. Successful exploitation can lead to command and control capabilities, allowing attackers to remotely manage and compromise the affected system. The rule aims to detect this suspicious behavior by monitoring process execution and command-line arguments.

Attack Chain

The attacker gains initial access to the target system through unspecified means.
The attacker downloads a portable version of Visual Studio Code (VScode) onto the compromised system.
The attacker executes the VScode binary with the tunnel command-line argument to initiate a remote tunnel session.
The attacker specifies additional arguments such as --accept-server-license-terms to bypass license agreement prompts.
The VScode tunnel attempts to establish a connection to a remote server, potentially a GitHub repository or a remote VScode instance controlled by the attacker.
If successful, the tunnel creates a persistent connection, allowing the attacker to execute commands and transfer files.
The attacker uses the established tunnel to remotely access the compromised system, enabling them to perform malicious activities such as data exfiltration or lateral movement.
The attacker maintains persistent access through the established tunnel, allowing for long-term command and control of the compromised system.

Impact

Successful exploitation allows attackers to establish a persistent command and control channel, enabling them to remotely manage the compromised system. This can lead to data theft, deployment of ransomware, or further lateral movement within the network. While the number of potential victims and specific sectors targeted are not explicitly stated, the widespread use of VScode makes a wide range of organizations vulnerable.

Recommendation

Deploy the “Attempt to Establish VScode Remote Tunnel” rule to detect suspicious VScode tunnel activity in your environment.
Enable Sysmon process-creation logging to capture the necessary process execution data.
Investigate any alerts triggered by the rule, focusing on the command-line arguments and process behaviors to confirm malicious intent.
Monitor network connections originating from VScode processes for unusual or unauthorized connections to external servers.
Review and whitelist legitimate uses of VScode’s tunnel feature by authorized developers to reduce false positives.

WDAC Policy File Creation by Unusual Process

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

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

Attack Chain

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

Impact

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

Recommendation

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

MsiExec Child Process Spawning Network Connections for Defense Evasion

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

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

Attack Chain

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

Impact

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

Recommendation

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

NTDS Dump via Wbadmin

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

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

Attack Chain

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

Impact

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

Recommendation

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

Network-Level Authentication (NLA) Disabled via Registry Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Wireless Credential Dumping via Netsh

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

AMSI Enable Registry Key Modification for Defense Evasion

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

Windows Sandbox Abuse with Sensitive Configuration

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

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

Attack Chain

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

Impact

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

Recommendation

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

Unusual Service Host Child Process - Childless Service

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

MSBuild запускает необычные процессы

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

The Microsoft Build Engine (MSBuild) is a legitimate tool used for building applications. However, adversaries may abuse MSBuild to execute malicious scripts or compile code, effectively bypassing security controls. This technique is often employed to deploy malicious payloads. This detection focuses on identifying instances where MSBuild initiates unusual processes such as PowerShell, Internet Explorer, or the Visual C# Command Line Compiler (csc.exe). This activity is considered suspicious because legitimate software development workflows do not typically involve MSBuild directly spawning these processes. The original Elastic detection rule was created on 2020-03-25 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
The attacker modifies or creates an MSBuild project file (.csproj or .sln) containing malicious commands.
The malicious MSBuild project file is crafted to execute a script or compile code.
The attacker uses the MSBuild.exe or msbuild.exe utility to execute the malicious project file.
MSBuild spawns an unusual process such as powershell.exe, csc.exe, or iexplore.exe based on the malicious project file configuration.
PowerShell executes arbitrary commands, downloads further payloads, or performs other malicious actions.
The C# compiler (csc.exe) compiles malicious code into an executable or library.
The compiled malware or downloaded payloads execute, leading to further compromise, such as data exfiltration or lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to deploy malware, compromise sensitive data, and establish persistence on the targeted system. The use of MSBuild for malicious purposes allows attackers to bypass application whitelisting and other security controls that trust signed Microsoft binaries. While the precise number of victims is unknown, this technique can be employed against a wide range of organizations, particularly those with vulnerable systems or inadequate endpoint protection.

Recommendation

Enable process creation logging, specifically including parent-child relationships, to detect unusual process spawning by MSBuild (logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*, winlogbeat-*).
Deploy the Sigma rule “Microsoft Build Engine Started an Unusual Process” to your SIEM to identify instances of MSBuild spawning suspicious processes, and tune for your environment.
Investigate any instances of MSBuild spawning PowerShell, csc.exe, or iexplore.exe to determine if the activity is legitimate or malicious (process.name:(“csc.exe” or “iexplore.exe” or “powershell.exe”)).
Monitor for modifications to MSBuild project files (.proj or .sln) for signs of tampering.

Suspicious Enumeration Commands Spawned via WMIPrvSE

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Process Writing to Startup Folder for Persistence

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

Attackers often leverage the Windows Startup folder to maintain persistence, as any executable placed in this folder will automatically run when a user logs into the system. This technique is particularly effective because it requires no user interaction and can easily be automated. This rule detects when processes commonly abused by attackers, such as cmd.exe, powershell.exe, or mshta.exe, write or modify files within the Startup folders. The rule focuses on identifying unauthorized persistence mechanisms and helps defenders uncover potentially compromised systems. By monitoring file creation events in the Startup folders by suspicious processes, this detection aims to catch malicious activity early in the attack chain.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker executes a command shell (e.g., cmd.exe, powershell.exe) on the compromised system.
The attacker uses the command shell to write a malicious executable or script file to one of the Windows Startup folders (C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\* or C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*).
The attacker modifies the file attributes (e.g., using attrib.exe) to hide the file or make it more difficult to detect.
The attacker schedules a reboot or waits for the user to log off and back on.
Upon user logon, the malicious executable or script in the Startup folder is automatically executed.
The malicious code establishes persistence, potentially downloading additional payloads or establishing a command and control (C2) channel.
The attacker maintains persistent access to the compromised system, enabling further malicious activities such as data theft or lateral movement.

Impact

Successful exploitation leads to persistent access on the compromised system, allowing attackers to maintain their foothold even after system reboots. This can lead to data exfiltration, installation of ransomware, or further propagation within the network. The number of affected systems depends on the scope of the initial compromise and the attacker’s ability to move laterally. Sectors commonly targeted by persistence techniques include finance, healthcare, and government.

Recommendation

Enable Sysmon Event ID 11 (File Create) to capture file creation events, as referenced in the setup instructions.
Deploy the Sigma rule Suspicious Process Writing to Startup Folder to your SIEM to detect suspicious processes creating files in the startup folder, and tune for your environment.
Investigate any alerts generated by the Sigma rule to determine if the activity is malicious, referencing the investigation guide.
Block the processes listed in the rule (cmd.exe, powershell.exe, etc.) from writing to the startup folders if legitimate use is not required.

Windows Script Interpreter Executing Process via WMI

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

This detection identifies the use of Windows script interpreters (cscript.exe or wscript.exe) to execute processes via Windows Management Instrumentation (WMI). Adversaries exploit WMI to execute scripts or processes stealthily, often using script interpreters. The rule monitors for these interpreters executing processes via WMI, specifically when initiated by non-system accounts, indicating potential malicious intent. The detection focuses on identifying scenarios where wmiutils.dll is loaded by wscript.exe or cscript.exe, followed by wmiprvse.exe spawning a new process. This is often associated with malicious initial access or execution techniques.

Attack Chain

An attacker gains initial access via phishing (T1566) or other means.
The attacker leverages a script, such as VBScript or JavaScript (T1059.005, T1059.007), to execute commands using WMI.
The script interpreter (cscript.exe or wscript.exe) loads wmiutils.dll to interact with WMI.
The WMI Provider Host process (wmiprvse.exe) is invoked as a parent process, triggered by the script execution.
wmiprvse.exe executes a secondary process, such as powershell.exe, cmd.exe, or other executables, often from unusual locations like C:\\Users\\ or C:\\ProgramData\\.
The executed process performs malicious actions, such as downloading additional payloads or establishing persistence.
The attacker attempts to maintain persistence by creating scheduled tasks or modifying registry keys.
The ultimate objective is often lateral movement, data exfiltration, or deploying ransomware.

Impact

Successful exploitation allows attackers to execute arbitrary code, bypass security controls, and establish persistence on the compromised system. The use of WMI enables stealthy execution, making detection challenging. The impact can range from data theft and system compromise to full network takeover. In some cases, threat actors may deploy ransomware, leading to significant financial losses and operational disruption.

Recommendation

Enable Sysmon Event ID 1 (Process Creation) and Event ID 7 (Image Loaded) logging to provide the necessary data for the provided Sigma rules.
Deploy the provided Sigma rule “WMI Scripting Process Creation” to detect suspicious process creation events originating from wmiprvse.exe.
Investigate any alerts generated by the provided Sigma rule “WMI Scripting Process Creation” with a focus on processes spawned by wmiprvse.exe from unusual locations or with suspicious command-line arguments.
Implement endpoint protection policies to block or alert on the execution of high-risk processes when initiated by non-system accounts as mentioned in the overview.
Regularly review and update endpoint protection policies to block or alert on the execution of high-risk processes like those listed in the detection query, especially when initiated by non-system accounts.

Windows Scheduled Tasks AT Command Enabled via Registry Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Windows Root Certificate Modification Detection

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

Attackers can install malicious root certificates to subvert trust controls and bypass security measures. Once a malicious root certificate is installed, attackers can sign malicious files, making them appear as legitimate software from trusted vendors like Microsoft. This allows the attacker to execute code undetected and maintain persistence on the system. Furthermore, a rogue root certificate can be used in adversary-in-the-middle attacks to decrypt SSL traffic, enabling the collection of sensitive data. This activity is typically achieved through registry modifications. Monitoring for these modifications can help security teams identify potential compromise attempts.

Attack Chain

An attacker gains initial access to a Windows system, possibly through phishing or exploiting a software vulnerability.
The attacker elevates privileges to administrator or SYSTEM level, required to modify the trusted root certificate store.
The attacker uses tools like certutil.exe or PowerShell to import a malicious root certificate into the Windows registry.
The registry keys HKLM\Software\Microsoft\SystemCertificates\Root\Certificates or HKLM\Software\Policies\Microsoft\SystemCertificates\Root\Certificates are modified to add the new certificate.
The attacker uses the newly installed root certificate to sign malicious executables or scripts.
The signed malicious files are executed, bypassing signature-based detection mechanisms.
The attacker intercepts and decrypts SSL traffic, collecting sensitive data like credentials or financial information.
The attacker maintains persistence by using the trusted certificate to repeatedly sign and execute malicious code.

Impact

Successful installation of a malicious root certificate allows attackers to bypass security controls, leading to the execution of arbitrary code and potential data theft. This can result in significant data breaches, financial losses, and reputational damage. Attackers can use this technique to maintain a long-term presence on compromised systems, making detection and remediation more challenging. While no specific victim counts are available, the technique is broadly applicable across many sectors and can affect any organization running Windows systems.

Recommendation

Deploy the Sigma rule “Detect Root Certificate Modification” to your SIEM to detect registry modifications related to root certificate installation.
Enable Sysmon registry event logging to provide the necessary data for the Sigma rule.
Investigate any alerts triggered by the Sigma rule, focusing on processes modifying the registry keys related to root certificates.
Review the “False Positives” section in the rule documentation to tune the Sigma rule for your environment.
Monitor network traffic for suspicious SSL decryption activity following the detection of a root certificate modification.

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 Modifications to Windows Security Support Provider (SSP) Registry

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Microsoft Antimalware Service Executable Execution

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

This detection identifies suspicious execution of the Microsoft Antimalware Service Executable (MsMpEng.exe) from non-standard paths or renamed instances. Attackers may attempt to evade defenses through DLL side-loading or by masquerading as the antimalware process. This technique is used to blend in with legitimate system activity and avoid detection by security tools. This rule is designed to detect instances where MsMpEng.exe is executed from unexpected locations or has been renamed, potentially indicating malicious activity. The rule leverages process monitoring data to identify deviations from the expected execution patterns of the antimalware service. This behavior has been seen associated with ransomware attacks, such as REvil.

Attack Chain

An attacker gains initial access to the system, potentially through phishing or exploiting a vulnerability.
The attacker drops a malicious payload onto the system, placing it in a non-standard directory, such as a temporary folder or a user’s profile directory.
The attacker renames or copies the legitimate MsMpEng.exe to the malicious payload’s location.
The attacker executes the renamed or copied MsMpEng.exe from the non-standard location. This is intended to mimic legitimate activity and evade detection.
The malicious MsMpEng.exe then loads a malicious DLL through DLL side-loading, which executes arbitrary code within the context of the antimalware process.
The malicious code performs actions such as disabling security controls, escalating privileges, or establishing persistence.
The attacker leverages the compromised system to move laterally within the network, compromising additional systems.
The attacker achieves their final objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to complete system compromise, including the disabling of security controls, data theft, and ransomware deployment. This can result in significant financial losses, reputational damage, and disruption of business operations. Identifying and responding to this type of attack is critical to prevent further damage. The Sophos article references the REvil ransomware attack which impacted hundreds of businesses.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture process execution events, including image path and command-line arguments, which are essential for detecting this behavior.
Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious MsMpEng.exe execution from unusual paths or renamed instances.
Investigate any alerts generated by these rules to determine the legitimacy of the MsMpEng.exe execution and identify any potential malicious activity.
Monitor process execution events for instances where the process name is “MsMpEng.exe” but the executable path is outside the standard Windows Defender or Microsoft Security Client directories.
Review the references provided for additional context and guidance on investigating this type of activity.

Suspicious DNS Queries to RMM Domains from Non-Browser Processes

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

This detection identifies DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains originating from processes that are not web browsers. This activity can indicate the use of legitimate RMM tools for malicious purposes, such as command and control, persistence, or lateral movement within a network. The detection aims to surface RMM clients, scripts, or other non-browser activities contacting these services without legitimate user interaction. Defenders should investigate processes making these queries to confirm expected behavior and validate the security posture of their managed assets. The rule is based on a list of known RMM domains and excludes common browser processes to reduce false positives.

Attack Chain

An attacker gains initial access to a Windows host through unspecified means.
The attacker deploys or leverages an existing RMM tool on the compromised host.
The RMM tool, running as a non-browser process, initiates a DNS query to resolve a command and control server associated with the RMM service (e.g., teamviewer.com).
The DNS query is made by a process other than a known web browser (chrome.exe, firefox.exe, etc.).
The compromised host establishes a connection to the resolved IP address associated with the RMM domain.
The attacker uses the RMM tool to execute commands, transfer files, or perform other malicious activities on the compromised host.
The attacker may use the RMM tool for lateral movement, pivoting to other systems within the network.
The attacker achieves their objective, which could include data exfiltration, ransomware deployment, or maintaining persistent access.

Impact

Compromise via abused RMM software can lead to full system compromise, data theft, or deployment of ransomware. While the number of affected victims is unknown, the sectors most likely to be impacted include any organization that relies on RMM tools for IT management. Successful exploitation allows attackers to bypass traditional security controls by using legitimate software, making detection more challenging.

Recommendation

Deploy the Sigma rule “DNS Queries to Known RMM Domains from Non-Browser Processes” to your SIEM and tune the RMM domain list for your environment.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the DNS query and its parent process.
Implement application control policies to restrict the execution of unauthorized RMM tools.
Enable Sysmon DNS event logging to ensure the necessary data is available for the detection rule.
Correlate with other alerts to identify potential compromises.
Review process.code_signature for trusted RMM publishers and investigate any unsigned or unexpected signers.

Scheduled Task Creation via Scripting

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

This rule detects the creation of scheduled tasks by Windows scripting engines, a tactic commonly employed by adversaries to establish persistence on compromised systems. The activity involves monitoring registry changes related to scheduled task actions and correlating them with script execution. Specifically, it looks for instances where cscript.exe, wscript.exe, powershell.exe, pwsh.exe or powershell_ise.exe are used to create or modify scheduled tasks. This behavior can be indicative of malicious activity, as legitimate software installations should not typically involve scripting engines directly creating scheduled tasks. Defenders should investigate any instances of this behavior to determine if it is malicious. The rule focuses on Windows environments.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploit).
The attacker executes a script (e.g., PowerShell, VBScript) on the target system.
The script interacts with the taskschd.dll library to create or modify a scheduled task.
The script modifies the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\*\Actions or \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\*\Actions to define the actions performed by the scheduled task.
The scheduled task is configured to execute a malicious payload at a specific time or event.
The scheduled task executes, providing the attacker with persistent access to the system.
The attacker leverages the persistent access to perform further malicious activities, such as lateral movement or data exfiltration.

Impact

Successful exploitation leads to persistence on the compromised system, allowing attackers to maintain access even after reboots or user logoffs. This can facilitate long-term data theft, deployment of ransomware, or further compromise of the network. The impact depends on the privileges of the account under which the scheduled task runs, potentially granting SYSTEM level access.

Recommendation

Enable Sysmon ImageLoad events (Event ID 7) to detect when taskschd.dll is loaded by scripting engines (powershell.exe, cscript.exe, wscript.exe) as described in the Sysmon Event ID 7 setup guide.
Enable Sysmon Registry Events to monitor changes to the registry paths associated with scheduled task actions as described in the Sysmon Registry Events setup guide.
Deploy the provided Sigma rules to your SIEM to detect scheduled task creation by scripting engines and tune for your environment.
Investigate any alerts generated by these rules, focusing on the specific scripts and scheduled tasks involved.

RMM Domain DNS Queries from Non-Browser Processes

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

This detection identifies potentially malicious use of Remote Monitoring and Management (RMM) tools by detecting DNS queries to known RMM domains originating from processes that are not web browsers. Attackers frequently abuse legitimate RMM software for command and control, persistence, and lateral movement within compromised networks. This rule focuses on surfacing RMM clients, scripts, or other non-browser activity contacting these services, thereby increasing the likelihood of detecting unauthorized remote access or malicious activity. The rule aims to reduce false positives by excluding common browser processes and focusing on unusual network activity. The identified domains are associated with various RMM tools like TeamViewer, AnyDesk, and ScreenConnect. This detection is relevant for organizations concerned about insider threats, supply chain attacks, or general compromise leading to unauthorized remote access.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker installs an unauthorized RMM tool (e.g., using a script or installer).
The RMM tool initiates a DNS query to resolve its command and control domain (e.g., teamviewer.com).
The system, now running the RMM agent, establishes a connection to the attacker-controlled RMM server.
The attacker uses the RMM tool to execute commands on the compromised system.
The attacker uses the RMM tool for lateral movement within the network.
The attacker uses the RMM tool to maintain persistence on the compromised system.

Impact

Compromise via unauthorized RMM tools can provide attackers with persistent remote access, enabling them to perform a range of malicious activities, including data theft, ransomware deployment, and further lateral movement within the network. Successful exploitation can lead to significant financial loss, reputational damage, and disruption of business operations. The number of affected systems can vary depending on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

Deploy the Sigma rule RMM Domain DNS Queries from Non-Browser Processes to your SIEM and tune it to your environment, excluding legitimate non-browser processes that use RMM tools.
Investigate any alerts generated by the rule, focusing on identifying the process making the DNS query and its parent process, as outlined in the rule’s description.
Monitor DNS query logs for queries to the RMM domains listed in the IOC table, and block them at the DNS resolver if unauthorized RMM use is confirmed.
Enable Sysmon Event ID 22 (DNS Query) logging to provide the necessary data for this detection, as recommended in the “Setup” section of the content.

Persistence via WMI Event Subscription

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

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

Attack Chain

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

Impact

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

Recommendation

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

NullSessionPipe Registry Modification for Lateral Movement

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

This detection rule identifies modifications to the NullSessionPipe registry setting in Windows. This setting defines named pipes that can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. By adding specific pipes to the NullSessionPipes registry key, an attacker can make services accessible without requiring authentication. This rule focuses on flagging modifications that introduce new accessible pipes, which could indicate malicious intent. The targeted configuration is located under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. The registry key NullSessionPipes is of particular interest when its values change.

Attack Chain

Initial compromise of a system within the network.
The attacker gains elevated privileges on the compromised system.
The attacker modifies the Windows Registry, specifically the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes key. They add a new pipe name to this key, which will allow unauthenticated access to that named pipe.
The attacker uses reg.exe or PowerShell to modify the registry, potentially using commands like reg add or Set-ItemProperty.
A remote system attempts to connect to the newly accessible named pipe on the compromised system without authenticating.
The attacker exploits the now-accessible service or application associated with the named pipe to execute commands or transfer data.
The attacker leverages this access to move laterally within the network, compromising additional systems.

Impact

Successful modification of the NullSessionPipes registry setting can lead to unauthorized access to sensitive resources and lateral movement within the network. By enabling anonymous access to named pipes, attackers can potentially bypass authentication mechanisms and gain control over critical systems. While the direct number of victims is not specified, the impact can be significant, particularly in organizations where shared resources and services rely on secure authentication protocols.

Recommendation

Enable Windows Registry auditing to capture changes to the NullSessionPipes registry key. This will allow you to detect unauthorized modifications as described in the overview.
Deploy the Sigma rule “NullSessionPipe Registry Modification” to your SIEM and tune for your environment to identify malicious activity related to named pipe modifications.
Investigate any alerts generated by the Sigma rule, focusing on the specific named pipes being added or modified in the registry event details, as detailed in the rule’s description.
Regularly review and validate the legitimacy of existing entries in the NullSessionPipes registry key to identify and remove any unauthorized pipes.

LOLBIN Network Connection for Defense Evasion

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

Attackers may leverage LOLBINs, signed binaries that are part of the operating system, to perform malicious actions while blending in with legitimate system activity. This technique allows them to evade detection by application allowlists and signature validation. This brief focuses on the abuse of expand.exe, extrac32.exe, ieexec.exe, and makecab.exe to initiate outbound network connections. The LOLBINs are used to execute malicious code, download additional payloads, or establish command and control channels. This activity can be indicative of malware installation, data exfiltration, or other malicious post-exploitation activities. Detection is crucial to identify potentially compromised systems and prevent further damage.

Attack Chain

An attacker gains initial access to the target system (e.g., through phishing or exploitation of a vulnerability).
The attacker executes a signed LOLBIN, such as expand.exe, extrac32.exe, ieexec.exe, or makecab.exe.
The LOLBIN is used to download or execute a malicious payload from a remote server.
The executed binary establishes a network connection to an external IP address.
Data exfiltration may occur over the established network connection.
The attacker maintains persistence on the system by scheduling tasks or modifying registry keys.
The attacker moves laterally within the network, compromising additional systems.

Impact

A successful attack leveraging LOLBINs can result in the installation of malware, data theft, or full system compromise. The use of signed binaries makes it more difficult to detect malicious activity, potentially allowing attackers to operate undetected for extended periods. The financial and reputational damage caused by such attacks can be significant. While the risk score is low, the potential for defense evasion justifies monitoring.

Recommendation

Implement the provided Sigma rule Network Connection via Signed Binary to detect suspicious network connections initiated by LOLBINs.
Monitor process execution logs for instances of expand.exe, extrac32.exe, ieexec.exe, and makecab.exe using process creation logging.
Review network connection logs for outbound connections initiated by these processes, excluding connections to internal networks based on the provided list of private IP ranges.
Investigate any detected instances of LOLBINs making external network connections, correlating with other suspicious activities on the affected host, as detailed in the “Triage and analysis” section.

Execution via Local SxS Shared Module

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

This detection identifies potential abuse of the Windows Side-by-Side (SxS) feature to execute malicious code. Attackers can place a malicious DLL file within an application’s local SxS folder (application.exe.local) and trick the Windows module loader into prioritizing it over legitimate system DLLs. This technique, known as DLL hijacking or DLL redirection, allows adversaries to gain arbitrary code execution within the context of the targeted application. This technique may be used to bypass security controls, escalate privileges, or establish persistence. The detection focuses on file events related to DLLs within these specific SxS folders.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker identifies a legitimate application with an associated SxS folder (application.exe.local).
The attacker creates or modifies a malicious DLL file.
The attacker places the malicious DLL file in the application’s SxS folder (application.exe.local).
A legitimate application attempts to load a DLL.
Due to the presence of the malicious DLL in the SxS folder, the Windows module loader prioritizes the attacker’s DLL.
The malicious DLL is loaded and executed by the application.
The attacker achieves code execution within the context of the application.

Impact

Successful exploitation can lead to arbitrary code execution within the targeted application’s context. This can result in privilege escalation, data theft, system compromise, or the establishment of persistence mechanisms. While the number of directly affected organizations is unknown, this technique can be used against a wide range of applications on Windows systems.

Recommendation

Monitor file creation events for DLL files in C:\*\*.exe.local\*.dll and \\Device\\HarddiskVolume*\\*\\*.exe.local\\*.dll using the provided Sigma rule to detect potential malicious DLL planting.
Enable Sysmon Event ID 11 (File Create) to improve visibility into file creation events, as noted in the setup instructions.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the DLL creation event and the involved application.

Detection of Encrypted Archive Creation with WinRAR or 7-Zip

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

Attackers frequently compress and encrypt data before exfiltration to reduce the amount of data being sent over the network and to obfuscate the contents. This behavior often indicates a later stage of intrusion where the attacker has already collected sensitive data and is preparing to move it out of the environment. The use of archiving tools like WinRAR and 7-Zip with encryption flags can help attackers to hide their activities, making it more difficult for defenders to identify and respond to data theft. This technique has been observed in multiple threat actors including Turla as documented by WeLiveSecurity. This brief focuses on detecting command-line activity indicative of archive creation with encryption using WinRAR or 7-Zip on Windows systems.

Attack Chain

Initial Access: The attacker gains initial access to the system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
Credential Access: The attacker attempts to obtain credentials using techniques such as Mimikatz or credential dumping.
Discovery: The attacker performs reconnaissance to identify sensitive data and systems of interest.
Data Collection: The attacker gathers sensitive data from various locations on the compromised system or network.
Archive Creation: The attacker uses WinRAR or 7-Zip to create an encrypted archive of the collected data using command-line arguments like -hp, -p, /hp, or /p with rar.exe or WinRAR.exe or -p* with 7z.exe or 7za.exe.
Data Staging: The encrypted archive is moved to a staging location, such as a temporary directory or removable media.
Exfiltration: The attacker exfiltrates the encrypted archive from the network using various methods, such as FTP, SCP, or cloud storage services.
Covering Tracks: The attacker deletes the archive from the staging location to remove evidence of the activity.

Impact

A successful attack can lead to the exfiltration of sensitive data, including personally identifiable information (PII), financial records, intellectual property, and other confidential information. This can result in significant financial losses, reputational damage, legal liabilities, and regulatory fines for the victim organization. The number of victims and specific sectors targeted will vary depending on the attacker’s objectives and the nature of the compromised data.

Recommendation

Deploy the Sigma rule “Detect Encrypting Files with WinRar or 7z - CommandLine” to your SIEM to detect the execution of WinRAR or 7-Zip with encryption parameters (rule:Detect Encrypting Files with WinRar or 7z - CommandLine).
Enable process creation logging with command line arguments in Sysmon to ensure the necessary data is available for detection (Data Source: Sysmon).
Investigate any alerts generated by the Sigma rules to determine the scope and impact of the potential data exfiltration attempt (rule:Detect Encrypting Files with WinRar or 7z - CommandLine).
Monitor network traffic for unusual outbound connections, particularly to cloud storage services or other external destinations, that may indicate data exfiltration.

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 Process Execution via Renamed PsExec Executable

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

PsExec is a legitimate remote administration tool developed by Microsoft as part of the Sysinternals Suite, enabling the execution of commands with both regular and SYSTEM privileges on Windows systems. It functions by executing a service component, Psexecsvc.exe, on a remote system, which then runs a specified process and returns the results to the local system. While commonly used by administrators, adversaries frequently abuse PsExec for lateral movement and to execute commands as SYSTEM, effectively disabling defenses and bypassing security protections. This detection identifies instances where the PsExec service component is executed using a custom name, a tactic employed to evade security controls or detections targeting the default PsExec service component name. The rule was last updated on 2026-05-04 and covers Elastic Defend, Windows, M365 Defender, and Crowdstrike data sources.

Attack Chain

An attacker gains initial access to a system within the network (e.g., via phishing or exploiting a public-facing application).
The attacker uploads a renamed version of psexesvc.exe to a compromised host.
The attacker uses a tool like the standard PsExec.exe to initiate a remote connection to a target system.
PsExec attempts to copy the renamed psexesvc.exe to the ADMIN$ share on the target system.
The renamed psexesvc.exe is executed as a service on the remote host.
The renamed service executes commands specified by the attacker with SYSTEM privileges.
The results of the commands are returned to the originating system.
The attacker leverages the command execution for lateral movement, data exfiltration, or further compromise of the environment.

Impact

A successful attack can lead to complete compromise of the target system and potentially the entire network. By executing commands with SYSTEM privileges, attackers can disable security controls, install malware, steal sensitive data, or move laterally to other critical systems. The use of a renamed PsExec executable demonstrates an attempt to evade detection, increasing the likelihood of a successful breach.

Recommendation

Deploy the Sigma rule “Suspicious Process Execution via Renamed PsExec Executable” to your SIEM and tune for your environment to detect the execution of renamed psexesvc.exe executables.
Enable Sysmon process creation logging (Event ID 1) to capture the necessary process execution details for the Sigma rule.
Investigate any alerts generated by this rule promptly, focusing on the commands executed and the target systems involved.
Review and enforce the principle of least privilege to minimize the potential impact of compromised accounts.
Monitor network traffic for SMB connections originating from unusual or untrusted systems, which could indicate PsExec usage.

IIS HTTP Logging Disabled via AppCmd

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

Attackers with access to an Internet Information Services (IIS) server, potentially through a webshell or other compromised entry point, may disable HTTP logging as a defense evasion technique. This is typically achieved by using the appcmd.exe utility with specific arguments to modify the IIS configuration, preventing the server from recording HTTP requests and responses. Disabling logging makes it significantly harder for defenders to detect malicious activity, trace attacker actions, and perform effective incident response. This activity is a common tactic employed by threat actors to obscure their presence and maintain persistence within a compromised environment, particularly when deploying webshells or conducting lateral movement. This behavior is typically observed post-exploitation.

Attack Chain

Attacker gains initial access to the IIS server, possibly via a webshell or exploiting a vulnerability.
Attacker executes appcmd.exe to modify the IIS configuration.
The appcmd.exe command includes arguments to disable HTTP logging, such as /dontLog*:*True.
The command targets specific sites, applications, or the entire server depending on the attacker’s objectives.
IIS configuration files, such as applicationHost.config or web.config, are modified to reflect the changes.
HTTP logging is disabled, preventing the server from recording HTTP requests and responses.
Attacker performs malicious activities, such as deploying webshells, without generating HTTP logs.
Attacker maintains persistence and evades detection by preventing forensic analysis.

Impact

Successful disabling of IIS HTTP logging can severely impair incident response capabilities. Organizations may be unable to detect malicious activity within their web infrastructure, leading to prolonged compromises and increased damage. This technique can be particularly damaging when attackers deploy webshells or conduct lateral movement within the network. Without HTTP logs, tracing attacker actions and identifying compromised systems becomes significantly more challenging. The impact can range from data breaches to system downtime and reputational damage.

Recommendation

Deploy the Sigma rule “IIS HTTP Logging Disabled via AppCmd” to your SIEM to detect when appcmd.exe is used to disable HTTP logging.
Enable Sysmon process creation logging with Event ID 1 to capture the execution of appcmd.exe with the relevant arguments, enabling detection via the Sigma rules.
Investigate any alerts generated by the Sigma rule, focusing on the parent process of appcmd.exe and the user account under which it was executed.
Monitor for modifications to IIS configuration files (applicationHost.config, web.config) to detect unauthorized changes to logging settings.
Regularly review and validate the configuration of IIS HTTP logging to ensure it remains enabled and properly configured.

Adding Hidden File Attribute via Attrib.exe

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

Attackers can add the ‘hidden’ attribute to files to hide them from the user in an attempt to evade detection. This technique involves using the attrib.exe utility to modify file attributes. By setting the hidden attribute, adversaries can conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it. This tactic is often employed post-compromise to maintain a stealthy presence within the target environment. Detection focuses on monitoring process executions that involve attrib.exe with command-line arguments indicating the modification of the hidden attribute. The rule is designed for data generated by Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system through various means such as exploiting a vulnerability or using stolen credentials.
Privilege Escalation: The attacker escalates privileges to gain the necessary permissions to execute system utilities.
Defense Evasion: The attacker uses attrib.exe to modify the hidden attribute of a malicious file or directory. For example, attrib.exe +h C:\path\to\malicious\file.exe.
Concealment: The malicious file or directory is now hidden from normal directory listings, making it harder for users and administrators to detect.
Persistence: The attacker establishes persistence by hiding malicious scripts or executables in startup directories or scheduled tasks.
Lateral Movement: The attacker uses the hidden files to move laterally within the network, potentially using them as part of a larger attack campaign.

Impact

The impact of this attack includes prolonged attacker presence, increased difficulty in detecting malicious activity, and potential data exfiltration or system compromise. While the risk score is relatively low, the technique contributes to a broader attack chain and can significantly hinder incident response efforts. A successful hiding of artifacts might lead to further compromise, data breaches, or ransomware deployment.

Recommendation

Deploy the Sigma rule “Adding Hidden File Attribute via Attrib” to your SIEM to detect suspicious usage of attrib.exe.
Enable process creation logging with command line monitoring in Windows environments to ensure the Sigma rule can capture relevant events.
Investigate any alerts generated by the Sigma rule, focusing on the parent processes and target files to determine if the activity is legitimate.
Correlate detections of attrib.exe with other suspicious activities or alerts on the same host.
Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden attribute.