Windows — CraftedSignal Threat Feed

Potential Pass-the-Hash (PtH) Attempt Detection

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

Pass-the-Hash (PtH) is a technique where attackers leverage stolen password hashes to authenticate and move laterally within a Windows environment, bypassing standard system access controls. Instead of needing the plaintext password, adversaries use a hash of the password to authenticate to a remote service or server. This detection rule focuses on identifying potential PtH attempts by monitoring for successful logins using specific user IDs (S-1-5-21-* or S-1-12-1-*) and the seclogo logon process, which is commonly associated with credential theft and misuse. The rule aims to detect anomalous authentication patterns indicating that an attacker is using PtH to gain unauthorized access to systems. This is important because successful PtH attacks can lead to widespread compromise of sensitive data and critical infrastructure.

Attack Chain

The attacker gains initial access to a system through phishing or exploiting a vulnerability.
The attacker dumps password hashes from the compromised system using tools like Mimikatz.
The attacker identifies a target system within the network.
The attacker uses the stolen password hash to authenticate to the target system using the seclogo logon process.
Windows validates the hash, granting the attacker access without requiring the plaintext password.
The attacker successfully authenticates with the stolen credentials and a user ID matching the pattern S-1-5-21-* or S-1-12-1-*.
The attacker leverages their unauthorized access to move laterally to other systems or access sensitive data.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful Pass-the-Hash attacks can lead to significant damage, including unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Organizations can experience financial losses, reputational damage, and operational disruptions. While the specific number of victims is not stated, PtH is a common technique used in many breaches, potentially affecting any organization that relies on Windows authentication.

Recommendation

Enable Audit Logon to generate the necessary Windows Security Event Logs as referenced in the setup instructions https://ela.st/audit-logon.
Deploy the Sigma rule to your SIEM to detect potential Pass-the-Hash attempts. Tune the rule to account for legitimate uses of the seclogo logon process.
Investigate any alerts generated by the Sigma rule, focusing on correlating the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems.
Review and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege after an incident, as detailed in the Response and Remediation section.

PhantomRPC: Windows RPC Privilege Escalation Vulnerability

hello@craftedsignal.io — Fri, 24 Apr 2026 08:00:12 +0000

Kaspersky researchers discovered a critical vulnerability in the Windows Remote Procedure Call (RPC) architecture, dubbed PhantomRPC, that enables local privilege escalation. The flaw allows an attacker to create a rogue RPC server and, by exploiting existing processes with impersonation privileges (such as those running as Local Service or Network Service), elevate their own permissions to SYSTEM. The vulnerability resides in the architectural design of RPC itself, making it potentially exploitable across all Windows versions. The researcher has demonstrated five different exploitation paths escalating privileges from various local or network service contexts. This issue has been disclosed to Microsoft, but a patch has not yet been released. Due to the fundamental nature of the vulnerability, the number of potential attack vectors is effectively unlimited.

Attack Chain

The attacker gains initial access to the system with low privileges.
The attacker identifies a service running with SeImpersonatePrivilege, such as Local Service or Network Service.
The attacker crafts a malicious RPC server application designed to exploit the PhantomRPC vulnerability.
The attacker triggers a connection from the target service (e.g., Group Policy Client service) to the attacker’s malicious RPC server via ALPC.
The malicious RPC server uses RpcImpersonateClient API to impersonate the SYSTEM account.
The attacker’s malicious RPC server executes code within the security context of the SYSTEM account.
The attacker leverages the elevated privileges to perform arbitrary actions, such as installing malware, creating new accounts, or accessing sensitive data.

Impact

Successful exploitation of PhantomRPC allows a low-privileged attacker to gain complete control over the affected system by escalating privileges to SYSTEM. This can lead to complete system compromise, including data theft, malware installation, and denial of service. The vulnerability affects all Windows versions and given the number of potential attack vectors, it poses a significant risk to a large number of systems. While the exact number of potential victims remains unknown, the widespread use of RPC in Windows makes this a highly critical issue.

Recommendation

Monitor for the creation of suspicious ALPC ports, especially those targeting services with SeImpersonatePrivilege. Use the Sigma rule Detect Suspicious ALPC Port Creation to identify potential exploitation attempts.
Monitor for processes calling the RpcImpersonateClient API, especially those originating from unusual or untrusted processes. Use the Sigma rule Detect RpcImpersonateClient API Call from Unusual Process to identify potential exploitation attempts.
Restrict access to services with SeImpersonatePrivilege where possible, limiting the potential attack surface.

Trigona Ransomware Employing Custom Data Exfiltration Tool

hello@craftedsignal.io — Thu, 23 Apr 2026 19:02:17 +0000

Trigona ransomware, initially launched in October 2022, has been observed using a custom command-line tool named “uploader_client.exe” to exfiltrate data from compromised environments. This shift, observed in March 2026, suggests an effort to avoid detection by security solutions that commonly flag publicly available tools like Rclone and MegaSync. Symantec researchers believe this indicates a strategic investment in proprietary malware to maintain a lower profile during critical phases of attacks. The custom tool supports five simultaneous connections per file for faster data exfiltration via parallel uploads, rotates TCP connections after 2GB of traffic to evade monitoring, offers options for selective file type exfiltration, and utilizes an authentication key to restrict access to stolen data. Despite disruptions in October 2023, Trigona has resumed operations, incorporating additional techniques like installing the Huorong Network Security Suite tool HRSword and disabling security products.

Attack Chain

Initial compromise of the target system through unspecified means.
Installation of the Huorong Network Security Suite tool HRSword as a kernel driver service.
Deployment of tools such as PCHunter, Gmer, YDark, WKTools, DumpGuard, and StpProcessMonitorByovd to disable security-related products by leveraging vulnerable kernel drivers to terminate endpoint protection processes.
Execution of utilities with PowerRun to launch apps, executables, and scripts with elevated privileges, bypassing user-mode protections.
Deployment of AnyDesk for direct remote access to the breached systems.
Execution of Mimikatz and Nirsoft utilities for credential theft and password recovery operations.
Use of the custom “uploader_client.exe” to exfiltrate valuable documents such as invoices and PDFs from network drives via parallel uploads, rotating TCP connections to evade monitoring, and using an authentication key to restrict data access.
Final stage involving the deployment of Trigona ransomware, demanding ransom payment in Monero cryptocurrency.

Impact

Successful Trigona ransomware attacks result in significant data theft and encryption, disrupting business operations and causing financial losses. The group has demonstrated the capability to resume operations even after suffering disruptions, indicating a persistent threat. Observed data exfiltration has included high-value documents such as invoices and PDFs, demonstrating a targeted approach to data theft. Victims face potential regulatory penalties, reputational damage, and recovery costs associated with restoring systems and data. The number of victims and specific financial impact varies per campaign, but the potential for severe disruption and financial strain is consistent.

Recommendation

Monitor process creation events for the execution of “uploader_client.exe” with command-line arguments indicative of data exfiltration (see Sigma rule below).
Implement network monitoring to detect connections to unusual or hardcoded server addresses used by the “uploader_client.exe” exfiltration tool (see IOC table).
Deploy endpoint detection rules to identify the installation of Huorong Network Security Suite (HRSword) as a kernel driver service and tools like PCHunter, Gmer, YDark, WKTools, DumpGuard, and StpProcessMonitorByovd.
Monitor for processes launched via PowerRun, especially if followed by credential dumping or remote access tool execution.
Review AnyDesk usage for unusual connections or after-hours access, as this tool is used for remote access.
Enable robust logging for credential access attempts and password recovery activity associated with Mimikatz and Nirsoft tools.

Powercat PowerShell Implementation Detection

hello@craftedsignal.io — Mon, 04 Nov 2024 14:27:00 +0000

Powercat is a PowerShell script that functions similarly to the traditional Netcat utility, allowing for network communication using TCP and UDP. Attackers can use Powercat to establish reverse shells, transfer files, and perform port scanning within a compromised environment. This activity is often employed during post-exploitation phases to maintain access and propagate further into the network. Defenders should be aware of PowerShell scripts invoking Powercat, especially in environments…

Persistence via Windows Installer (Msiexec)

hello@craftedsignal.io — Thu, 05 Sep 2024 14:17:05 +0000

The Windows Installer (msiexec.exe) is a legitimate system tool used for installing, updating, and removing software on Windows systems. Adversaries can abuse msiexec.exe to establish persistence mechanisms by creating malicious scheduled tasks or modifying registry run keys. This allows them to execute arbitrary code during system startup or user logon. This technique is attractive to attackers due to msiexec.exe being a trusted Windows binary, potentially evading detection by security solutions that focus on flagging unknown or suspicious processes. The use of msiexec.exe for persistence can be difficult to detect without specific monitoring rules, as it is a common and legitimate system process. This activity can be observed across various Windows versions and is frequently integrated into automated attack frameworks and scripts.

Attack Chain

An attacker gains initial access to a compromised system, potentially through phishing, exploitation of a vulnerability, or stolen credentials.
The attacker leverages msiexec.exe to create a new scheduled task using the schtasks.exe command, setting it to execute a malicious script or binary.
Alternatively, the attacker uses msiexec.exe in conjunction with reg.exe or PowerShell to modify registry keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run or HKCU\Software\Microsoft\Windows\CurrentVersion\Run, adding a pointer to their malicious executable.
The created scheduled task or registry entry points to a malicious payload, such as a reverse shell or a downloader.
The system is restarted, or the user logs on, triggering the execution of the newly created scheduled task or the malicious binary through the modified registry run key.
The malicious payload executes, establishing a persistent foothold for the attacker on the compromised system.
The attacker can now perform further actions, such as data exfiltration, lateral movement, or deployment of ransomware.

Impact

Successful exploitation allows the adversary to maintain persistent access to the compromised system. This can lead to data theft, system compromise, deployment of ransomware, or use of the system as a staging point for further attacks within the network. A single compromised system can be used to pivot and compromise additional systems, leading to a widespread security breach. The impact can include financial losses, reputational damage, and disruption of business operations.

Recommendation

Monitor process creation events for msiexec.exe spawning schtasks.exe or reg.exe to create scheduled tasks or modify registry run keys (reference: rules in this brief).
Implement and tune the Sigma rules provided in this brief to detect suspicious msiexec.exe activity related to persistence mechanisms.
Review and audit existing scheduled tasks and registry run keys for any suspicious entries or anomalies.
Enable file integrity monitoring (FIM) on critical system directories, including the Windows Task Scheduler directory and registry run key locations (reference: event.category == “file” and file.path … and event.category == “registry” and registry.path … in the rule query).
Implement application control policies to restrict the execution of unauthorized or unknown executables (reference: rule query).

Detecting Potential PowerShell Pass-the-Hash/Relay Scripts

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

This detection identifies PowerShell scripts containing artifacts indicative of NTLM relay or pass-the-hash (PtH) attacks. These techniques allow attackers to authenticate to systems without needing plaintext passwords, enabling lateral movement and privilege escalation. The rule focuses on identifying specific byte sequences and strings within PowerShell script blocks that suggest NTLM/SMB negotiation and credential access attempts. This detection helps defenders identify and respond to potential credential theft and abuse within their Windows environments. The rule is based on observed techniques used in various publicly available tools such as Invoke-TheHash, Check-LocalAdminHash, and PoshC2.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker executes a PowerShell script on the compromised system. This script could be directly executed or obfuscated to evade initial detection.
The PowerShell script attempts to perform NTLM relay or pass-the-hash attacks by utilizing specific byte sequences related to NTLM/SMB negotiation, such as NTLMSSPNegotiate or 0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50.
The script may utilize tools like Invoke-WMIExec or Invoke-SMBExec to execute commands on remote systems using the stolen credentials.
The attacker attempts to authenticate to other systems on the network using the relayed credentials or password hashes.
Successful authentication allows the attacker to move laterally, accessing sensitive data or escalating privileges on other systems.
The attacker may deploy additional payloads or establish persistence mechanisms for continued access.

Impact

A successful pass-the-hash or NTLM relay attack can grant an attacker unauthorized access to sensitive systems and data within the network. This can lead to data breaches, financial loss, or disruption of critical services. The impact could range from compromising a few systems to gaining domain administrator privileges, depending on the attacker’s goals and the network’s security posture. Organizations can experience significant financial and reputational damage due to data breaches and service disruptions.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary data for this detection. Refer to the setup instructions in the rule documentation for configuration details.
Deploy the Sigma rule Detecting Potential PowerShell Pass-the-Hash/Relay Scripts to your SIEM and tune it based on your environment.
Investigate any alerts generated by this rule to determine the scope and impact of the potential attack. Refer to the triage and analysis section in the rule documentation for guidance on investigation steps.
Implement network segmentation and access controls to limit the impact of lateral movement.
Monitor authentication events (event codes 4624, 4625, 4648) for suspicious activity, such as NTLM authentication from unexpected source IPs or to unusual target systems, as described in the rule’s investigation notes.

Service Reconnaissance via WMIC.exe

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

Attackers may leverage the Windows Management Instrumentation Command-line (WMIC) tool for reconnaissance activities within a network. Specifically, WMIC can be used to query and retrieve information about services running on remote systems. By executing WMIC commands with the ‘service’ parameter, adversaries can identify the presence and status of specific services, potentially revealing vulnerable or misconfigured systems. This information can then be used to guide further exploitation attempts. WMIC is a built-in Windows utility, making its activity blend with legitimate system administration tasks, increasing the difficulty of detection. This activity is a component of the broader T1047 technique (Windows Management Instrumentation).

Attack Chain

The attacker gains initial access to a compromised system within the target network.
The attacker executes WMIC.exe from the command line.
WMIC.exe is invoked with the service parameter to query service information.
The command includes a target IP address or hostname to query a remote system.
The command attempts to retrieve service names and status information (e.g., wmic /node:"192.168.1.100" service get name, state).
WMIC attempts to connect to the remote host via RPC. An error message is generated if the remote host is unreachable: “Node - (provided IP or default) ERROR Description =The RPC server is unavailable”.
If the target service is not running, a “No instance(s) Available” message may be displayed.
The attacker parses the output from WMIC to identify running services of interest for further exploitation or lateral movement.

Impact

Successful service reconnaissance allows attackers to map potential attack vectors within a network. By identifying specific services running on remote systems, attackers can prioritize targets for exploitation based on known vulnerabilities or misconfigurations. This can lead to unauthorized access, data breaches, and system compromise. While the reconnaissance itself does not directly cause harm, it provides crucial information that enables subsequent malicious activities.

Recommendation

Deploy the Sigma rule Detect Suspicious WMIC Service Enumeration to your SIEM to identify potential service reconnaissance attempts via WMIC (logsource: process_creation, product: windows).
Monitor process creation events for WMIC.exe executions containing the service parameter using endpoint detection and response (EDR) solutions (logsource: process_creation, product: windows).
Implement network segmentation to limit the scope of potential reconnaissance activities.
Review and restrict the use of WMIC in your environment, as it is a common tool for both legitimate administration and malicious activity.

Suspicious Registry Modifications by Scripting Engines

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

Attackers may leverage scripting engines, such as wscript.exe and cscript.exe, to directly modify the Windows Registry. These scripting engines are often abused for malicious purposes, including establishing persistence, escalating privileges, or disabling security controls. These scripting engines can modify the registry without using standard tools like regedit.exe or reg.exe, making it harder to detect malicious registry changes. Defenders should be aware of processes using these engines to modify the registry, as this behavior is uncommon in legitimate software installations or administrative tasks.

Attack Chain

An attacker gains initial access to the system, potentially through social engineering or exploiting a software vulnerability.
The attacker executes a script (VBScript, JScript) via wscript.exe or cscript.exe.
The script contains commands to modify specific registry keys, such as the Run key for persistence (T1547.001).
The scripting engine process (e.g., wscript.exe) directly interacts with the Windows Registry to set the new values.
Upon system restart or user logon, the modified registry key triggers the execution of a malicious payload.
The attacker achieves persistence on the compromised system, allowing for continued access and control.
The attacker leverages the persistent access to perform lateral movement or data exfiltration.

Impact

Successful exploitation can lead to persistent access on compromised systems, enabling attackers to execute malicious code, steal sensitive information, or disrupt critical services. The registry modifications performed by scripting engines can bypass traditional security measures and make it difficult to detect and remediate the attack. This can result in significant data loss, financial damage, and reputational harm to affected organizations.

Recommendation

Deploy the Sigma rule “Registry Tampering by Potentially Suspicious Processes” to your SIEM to detect suspicious registry modifications made by scripting engines.
Investigate any alerts generated by the Sigma rule “Registry Tampering by Potentially Suspicious Processes” for unusual or unauthorized registry changes.
Monitor registry events for modifications made by processes such as wscript.exe and cscript.exe (logsource: registry_event).

Multiple Logon Failure from the Same Source Address

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

This detection rule identifies potential password guessing or brute force activity against Windows systems. It focuses on detecting a high number of failed network logon attempts originating from a single source IP address within a short time frame. The rule analyzes Windows Security Event Logs, specifically looking for event category “authentication” and event action “logon-failed”. By aggregating failed authentication counts within a 60-second window and filtering out common authentication misconfiguration errors, the rule aims to pinpoint suspicious activity indicative of credential access attempts. This is important for defenders as it highlights potential breaches or malicious actors attempting to compromise user accounts via brute-force or password spraying attacks.

Attack Chain

The attacker initiates a network connection to a Windows system, likely targeting a service such as SMB or RDP.
The attacker attempts to authenticate using a list of usernames and passwords or commonly used passwords, generating failed logon attempts (Event ID 4625).
The Windows system logs the failed authentication attempts in the Security Event Log.
The detection rule monitors the Security Event Log for failed logon events (event.category == “authentication” and event.action == “logon-failed”).
The rule aggregates the number of failed logon attempts from the same source IP address within a 60-second time window.
If the number of failed attempts exceeds a threshold (e.g., 100) and involves multiple target usernames (Esql.count_distinct_target_user_name >= 2), the rule triggers a detection.
The attacker may continue attempts after initial failures or pivot to successful credentials for lateral movement.
Successful credential access can lead to privilege escalation, data exfiltration, or other malicious activities.

Impact

Successful brute-force or password spraying attacks can lead to unauthorized access to user accounts and sensitive data. The impact can range from minor inconvenience to significant data breaches and financial losses, depending on the compromised accounts and the data they have access to. The rule aims to reduce the window of opportunity for attackers to gain a foothold in the environment.

Recommendation

Enable Audit Logon to generate the necessary Windows Security Event Logs. Follow the setup instructions outlined in the rule documentation.
Deploy the Sigma rule “Multiple Logon Failure from the Same Source Address” to your SIEM and tune the threshold values (Esql.failed_auth_count and Esql.count_distinct_target_user_name) to minimize false positives in your environment.
Investigate any triggered alerts by examining the logon failure reason codes and the targeted user names as described in the rule’s investigation guide.
Monitor network connections from the source IP address for any suspicious outbound traffic or lateral movement activity.
Review and enforce strong password policies to mitigate the risk of successful brute-force attacks.

Windows Registry Classes Autorun Keys Modification for Persistence

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

Attackers can manipulate Windows Registry Classes keys, an autostart extensibility point (ASEP), to achieve persistence. This involves modifying registry entries that control how the operating system handles specific file types or shell actions. By modifying these keys, adversaries can ensure their malicious code executes whenever a user interacts with a specific file type (e.g., opening an .exe) or performs a specific action within the shell. This technique, which has been observed since at least 2019, allows malicious actors to maintain a persistent foothold on compromised systems. While legitimate software also utilizes these registry keys, careful filtering and monitoring are crucial for distinguishing malicious modifications from benign software installations. Detection can be noisy due to the legitimate use of these keys, so tuning and review is critical.

Attack Chain

Initial Access: The attacker gains initial access through a separate vector (e.g., phishing, exploit). This stage is not covered by this detection, which focuses on post-exploitation activity.
Privilege Escalation (if needed): The attacker may need elevated privileges to modify certain registry keys. This can involve exploiting vulnerabilities or leveraging existing administrative rights.
Registry Key Modification: The attacker modifies specific keys under \Software\Classes in the Windows Registry. Common targets include \Folder\ShellEx\ExtShellFolderViews, \.exe, and \Directory\Shellex\DragDropHandlers.
Payload植入：攻击者修改注册表项指向一个恶意可执行文件或脚本。这可能涉及替换默认命令或添加新的处理程序。
Execution Trigger: The malicious code is configured to execute when a user interacts with the associated file type or shell action (e.g., opening a .exe file, right-clicking a folder).
Malicious Payload Execution: When the configured trigger occurs, the malicious payload executes, giving the attacker control over the system.
Persistence Maintained: The modified registry keys ensure that the malicious payload will continue to execute whenever the trigger occurs, maintaining persistence across reboots or user logons.
Objective Achieved: The attacker leverages persistent access to achieve their objectives, such as data exfiltration, lateral movement, or deploying ransomware.

Impact

Successful exploitation allows attackers to maintain persistent access to compromised systems, bypassing traditional security measures. This can lead to significant data breaches, financial losses, and reputational damage. The number of potential victims is broad, as any Windows system is potentially vulnerable. The types of damage possible range from credential theft to ransomware deployment, depending on the attacker’s objectives.

Recommendation

Enable Windows Registry auditing and monitor registry_set events for modifications to keys under \Software\Classes to identify suspicious activity.
Deploy the Sigma rule “Classes Autorun Keys Modification” to your SIEM and tune the filters (filter_main_, filter_optional_) for your specific environment to reduce false positives.
Investigate any registry modifications detected by the Sigma rule, focusing on unusual executables or scripts being launched from these locations.
Regularly review and update the filters in the Sigma rule to account for legitimate software changes in your environment.

Detection of Obfuscated IP Address Usage in Download Commands

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

Attackers are increasingly using obfuscated IP addresses (e.g., hexadecimal, octal, or other encoded representations) within download commands to bypass security measures that rely on simple IP address blacklisting or pattern matching. This technique makes it more difficult to identify malicious network connections based on simple string matching. The observed commands include Invoke-WebRequest, Invoke-RestMethod, wget, curl, DownloadFile, and DownloadString. Defenders need to detect these obfuscated IPs to identify and block malicious download attempts. This technique has been observed across various attack campaigns and is a common tactic used to deliver malware while attempting to evade detection.

Attack Chain

An attacker gains initial access, potentially through phishing or exploiting a vulnerability.
The attacker crafts a command containing an obfuscated IP address. This may involve converting a standard IP address into its hexadecimal, octal, or decimal representation.
The attacker utilizes a command-line tool such as curl, wget, or PowerShell’s Invoke-WebRequest to initiate a download. The command includes the obfuscated IP within a URL.
The command interpreter resolves the obfuscated IP address back to its standard format before initiating the network connection.
The target host establishes a connection to the attacker’s server at the resolved IP address.
The attacker’s server delivers a malicious payload, such as a script, executable, or document containing macros.
The downloaded payload is executed on the target system, potentially leading to further compromise, such as privilege escalation or lateral movement.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or establishing persistent access.

Impact

Successful exploitation can lead to the download and execution of malware, potentially compromising the targeted system. This can result in data breaches, system disruption, or financial loss. The use of obfuscation techniques makes it more difficult to detect and prevent these attacks, increasing the risk of successful compromise.

Recommendation

Deploy the Sigma rule “Obfuscated IP Download Activity” to your SIEM to detect the use of obfuscated IP addresses in download commands. Tune the rule for your environment to minimize false positives.
Investigate any process creation events that match the Sigma rule, paying close attention to the command-line arguments.
Consider implementing additional network-based detection mechanisms to identify connections to suspicious IP addresses, even if they are obfuscated.
Monitor process creation logs (Sysmon) for processes executing download commands like Invoke-WebRequest, Invoke-RestMethod, wget, curl, DownloadFile, and DownloadString with suspicious arguments.

System Shells Launched via Windows Services

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

Attackers may configure existing Windows services or create new ones to execute system shells, in order to elevate their privileges from administrator to SYSTEM. This tactic is used to gain SYSTEM permissions and establish persistence. The detection rule focuses on identifying instances where services.exe is the parent process of a command shell (cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe), indicating that a service is being abused to run a shell. The rule is designed to work with data from Elastic Defend, CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.

Attack Chain

Attacker gains initial access to the system with administrator privileges.
Attacker identifies a legitimate service or creates a new service to abuse for privilege escalation.
Attacker modifies the service configuration to execute a command shell (cmd.exe, powershell.exe, pwsh.exe, or powershell_ise.exe). This may involve modifying the service’s executable path or adding command-line arguments.
The system’s Service Control Manager (SCM) starts the service.
services.exe spawns the configured command shell process.
The command shell executes with SYSTEM privileges.
Attacker uses the SYSTEM shell to perform malicious activities, such as installing malware, accessing sensitive data, or creating new user accounts.
The service continues to run, providing persistent access to the system.

Impact

Successful exploitation leads to privilege escalation to SYSTEM, granting the attacker complete control over the compromised system. This can result in data theft, malware installation, or further lateral movement within the network. The rule has a risk score of 47 and is categorized as medium severity.

Recommendation

Deploy the Sigma rule System Shells via Services to detect the execution of command shells spawned by services.exe within your SIEM environment, and tune for your environment.
Investigate any process creation events where services.exe is the parent process of cmd.exe, powershell.exe, pwsh.exe, or powershell_ise.exe using the investigation guide provided in the content section.
Review service creation and modification events in Windows Event Logs (Event IDs 4697 and 7045) for suspicious entries.
Enable Sysmon process creation logging (Event ID 1) to capture detailed process information.
Utilize osquery to retrieve detailed service information to identify potentially malicious services. Reference queries $osquery_0, $osquery_1, and $osquery_2 in the investigation guide.

UAC Bypass via Windows Firewall MMC Snap-In Hijack

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

This threat involves the exploitation of a User Account Control (UAC) bypass technique on Windows systems. Attackers leverage the Microsoft Management Console (MMC) and its Windows Firewall snap-in (WF.msc) to execute arbitrary code with elevated privileges. By hijacking this trusted process, malicious actors can circumvent security measures designed to restrict unauthorized access and modifications to the system. This UAC bypass method allows attackers to stealthily execute code, potentially leading to privilege escalation, malware installation, or data exfiltration. The technique is relevant to defenders because it enables attackers to bypass standard security controls, increasing the risk of successful compromise. This activity has been observed in various forms and can be adapted to deliver a range of malicious payloads.

Attack Chain

User executes a seemingly benign application or script.
The application triggers the execution of mmc.exe with the WF.msc argument, launching the Windows Firewall snap-in.
A malicious process is spawned as a child process of mmc.exe. This is the key indicator of compromise.
The malicious process exploits a vulnerability or misconfiguration within the MMC snap-in or related components.
The exploited process gains elevated privileges, bypassing UAC restrictions.
The attacker uses these elevated privileges to perform malicious actions, such as installing malware or modifying system settings.
The attacker achieves persistence through registry modifications or scheduled tasks.
The final objective is achieved, such as data exfiltration, system compromise, or lateral movement within the network.

Impact

A successful UAC bypass can lead to a significant compromise of the targeted system. Attackers can install persistent backdoors, escalate privileges, and gain control over critical system functions. This can result in data theft, system instability, or complete system takeover. The impact is amplified in environments where UAC is relied upon as a primary security control, potentially affecting a large number of systems across an organization.

Recommendation

Deploy the Sigma rule “UAC Bypass via Windows Firewall MMC Snap-In Hijack” to your SIEM to detect suspicious processes spawned by mmc.exe with the “WF.msc” argument.
Monitor process creation events for unexpected child processes of mmc.exe using process monitoring tools and tune the Sigma rule accordingly.
Enable process auditing and Sysmon event logging (Event ID 1) to capture detailed information about process creations, as specified in the setup instructions of the original rule.
Investigate any alerts generated by the Sigma rule, focusing on the parent process chain and the actions performed by the spawned process.
Refer to the references provided for more information on UAC bypass techniques and mitigation strategies.

Uncommon Svchost Command Line Parameters Indicate Potential Masquerading or Injection

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

Svchost.exe (Service Host) is a critical Windows process responsible for hosting various Windows services. Attackers frequently target svchost.exe to disguise malicious activity, using techniques like process injection or file masquerading. By injecting malicious code into a legitimate svchost.exe process or creating a fake svchost.exe executable, attackers can evade detection and escalate privileges. This can be done by spawning the process with unusual arguments to trick the OS or a user. Detecting these anomalies is crucial for identifying potentially compromised systems. The attacks documented leveraging this technique started to gain prominence around 2018 and are still relevant in 2026.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker uploads a malicious executable or script to the compromised system.
The attacker injects malicious code into a legitimate svchost.exe process. Alternatively, the attacker may copy the svchost.exe executable and rename it, placing it in a different directory.
The injected code or masqueraded executable executes with unusual command-line arguments, deviating from the standard “-k ” parameter.
The malicious svchost process performs unauthorized actions, such as establishing network connections, modifying files, or creating new processes.
The attacker leverages the elevated privileges of the svchost process to further compromise the system.
The attacker attempts to maintain persistence by modifying registry keys or scheduling tasks.
The ultimate goal is data exfiltration, lateral movement, or ransomware deployment.

Impact

Compromised svchost.exe processes can lead to significant system instability and data breaches. Attackers may leverage these processes to gain complete control over affected systems, potentially impacting hundreds or thousands of machines in a network. The consequences can include data theft, financial losses, and reputational damage. Ransomware groups, such as BlackByte/Exbyte, and APT groups, like APT41, have been observed using similar techniques to evade detection and achieve their objectives.

Recommendation

Deploy the Sigma rule “Uncommon Svchost Command Line Parameter” to your SIEM to detect anomalous svchost.exe processes based on command-line arguments.
Investigate any alerts triggered by the Sigma rule to determine if they are indicative of malicious activity.
Enable process creation logging, specifically capturing command-line arguments, to provide the necessary data for detection.
Implement application control policies to restrict the execution of unauthorized executables, including masqueraded svchost.exe instances.

PowerShell Invoke-NinjaCopy Script Detection

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

Invoke-NinjaCopy is a PowerShell script used to perform direct volume file access, enabling attackers to bypass traditional file access controls. This technique allows reading locked system files, such as the NTDS.dit or registry hives, which are essential for credential dumping. The script, often incorporated into post-exploitation frameworks like Empire, leverages stealth functions to minimize detection. Defenders need to monitor PowerShell script block content for the presence of Invoke-NinjaCopy or related “Stealth*” functions to identify potential credential access attempts. This activity is typically observed in Windows environments where attackers attempt to escalate privileges or move laterally within a network. The use of NinjaCopy allows attackers to grab sensitive data without being blocked by standard security measures.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker executes a PowerShell script, either directly or through a command-line interface.
The PowerShell script contains the Invoke-NinjaCopy function or related StealthReadFile, StealthOpenFile functions.
The script utilizes the StealthOpenFile function to directly access the volume where the target file resides (e.g., NTDS.dit).
StealthReadFile is used to read the contents of the target file, bypassing standard file access controls.
The script copies the contents of the NTDS.dit or registry hives to a temporary location.
The attacker dumps credentials from the copied NTDS.dit file using tools like secretsdump.py or other credential harvesting tools.
The attacker uses the harvested credentials to escalate privileges or move laterally within the network.

Impact

Successful exploitation can lead to the compromise of domain credentials, granting the attacker access to sensitive information and systems. Credential dumping from NTDS.dit or registry hives can expose user accounts, service accounts, and other privileged credentials. The impact ranges from data breaches and financial losses to complete network compromise and disruption of services. If successful, attackers may gain persistent access and control over critical infrastructure, potentially affecting thousands of users and systems.

Recommendation

Enable PowerShell Script Block Logging and monitor event ID 4104 for script content containing Invoke-NinjaCopy, StealthReadFile, StealthOpenFile, StealthCloseFileDelegate as described in the Overview.
Deploy the Sigma rule “PowerShell Invoke-NinjaCopy script” to your SIEM and tune the rule for false positives in your environment.
Investigate any PowerShell processes with command-line arguments that contain the identified keywords to identify potential attacker activity as outlined in the Attack Chain.
Implement strict access controls on sensitive files like NTDS.dit and registry hives to limit the impact of successful credential access attempts.
Review PowerShell execution policies to prevent the execution of unsigned or untrusted scripts.

Windows EventLog Autologger Session Disabled via Registry Modification

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

Attackers may disable Windows EventLog autologger sessions by modifying specific registry keys, thus evading detection and preventing security monitoring of early boot activities and system events. The AutoLogger event tracing session records events early in the operating system boot process, allowing applications and device drivers to capture traces before user login. Disabling these sessions can blind security monitoring tools, especially those focused on early boot activity, making it harder to detect malicious activity. This technique allows attackers to operate with less scrutiny during critical phases of system startup, potentially enabling persistence or other malicious objectives.

Attack Chain

The attacker gains initial access to the system, possibly through exploitation of a vulnerability or through stolen credentials.
The attacker uses reg.exe or PowerShell to modify the registry.
The attacker targets registry keys under \Control\WMI\Autologger\.
The attacker modifies the Start value to disable specific autologger sessions like EventLog-Application or EventLog-System.
Alternatively, the attacker modifies the Enabled value to disable specific providers of an autologger session.
The attacker executes the command, changing the registry value to disable the targeted autologger session or provider.
The system no longer records events for the disabled autologger session or provider.

Impact

Disabling the Windows EventLog autologger can severely impact an organization’s ability to detect and respond to threats. Security monitoring tools that rely on these logs will be unable to record early boot activities and system events, leading to a gap in visibility. This can allow attackers to establish persistence mechanisms, escalate privileges, or perform other malicious activities without being detected. The impact could range from undetected malware infections to significant data breaches, depending on the attacker’s objectives.

Recommendation

Deploy the Sigma rule Windows EventLog Autologger Session Registry Modification Via CommandLine to your SIEM and tune for your environment to detect this behavior in your environment.
Monitor process creation events for reg.exe, powershell.exe, or pwsh.exe with command-line arguments that contain \Control\WMI\Autologger\ and either Start or Enabled based on the Sigma rule’s detections.
Implement Atomic Red Team simulations to validate detections and train security staff.
Investigate any instances of registry modifications related to Autologger sessions to determine if they are legitimate or malicious.

Suspicious LSASS Access via Malicious Secondary Logon Service

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

This threat leverages the Windows Secondary Logon service (seclogon.dll) to gain unauthorized access to the Local Security Authority Subsystem Service (LSASS) process. The attack involves manipulating the seclogon service to leak an LSASS handle, which can then be used to extract credentials. This technique is often employed as a precursor to credential dumping and lateral movement within a compromised network. The detection focuses on identifying specific call traces to seclogon.dll coupled with suspicious access rights (0x14c0) when accessing LSASS, originating from svchost.exe. Defenders should monitor for this activity as it indicates a potential attempt to compromise sensitive credentials stored within LSASS memory.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploitation of a vulnerability).
The attacker executes code within the context of a user account.
The attacker leverages the Secondary Logon service (seclogon.dll) to request access to LSASS.
The malicious code interacts with the seclogon service to obtain a handle to the LSASS process with specific access rights (0x14c0), typically from a svchost.exe process.
The seclogon service, acting on behalf of the attacker, grants access to LSASS.
The attacker uses the leaked LSASS handle to read memory contents.
The attacker extracts sensitive information, such as user credentials (passwords, NTLM hashes, Kerberos tickets), from the LSASS memory.
The attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows attackers to steal user credentials, leading to unauthorized access to sensitive systems and data. This can result in data breaches, financial losses, and reputational damage. The compromise of domain administrator credentials can grant the attacker complete control over the entire Windows domain.

Recommendation

Enable Sysmon process creation logging (event ID 1) and process access logging (event ID 10) to detect suspicious LSASS handle access.
Deploy the Sigma rule “Suspicious Lsass Handle Access via MalSecLogon” to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the call trace, access rights, and source process.
Monitor authentication events for signs of credential misuse following suspicious LSASS access.
Review local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers
Block the GrantedAccess value “0x14c0” in conjunction with CallTrace “seclogon.dll” when the TargetImage is “lsass.exe” (Sysmon Event ID 10).

Potential Timestomping of Executable Files on Windows

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

This detection identifies attempts to modify the timestamps of executable files within sensitive directories on Windows systems, a technique known as timestomping. Timestomping is employed by adversaries to disguise malicious files as legitimate system components, making them harder to detect. The rule focuses on changes to file creation timestamps in directories like System32, SysWOW64, ProgramData, and common startup locations. It excludes known legitimate processes to reduce false positives. The goal of this technique is to evade detection and maintain persistence within the compromised system. This behavior is typically associated with post-exploitation activity after initial access.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., exploiting a vulnerability).
The attacker uploads a malicious executable (e.g., a backdoor or malware dropper) to a location on the filesystem.
The attacker uses a tool or script (e.g., PowerShell, built-in Windows utilities) to modify the creation timestamp of the malicious executable.
The timestamp is set to match that of a legitimate system file in the same directory, such as a DLL in C:\Windows\System32.
The attacker may then configure persistence for the timestomped executable, such as creating a registry entry in HKLM\Software\Microsoft\Windows\CurrentVersion\Run.
The malicious executable remains dormant, blending in with other legitimate files and evading initial detection.
The attacker triggers the execution of the timestomped executable, either manually or through scheduled tasks, registry entries or other persistence mechanisms.
The malicious executable performs its intended function, such as establishing a reverse shell or deploying ransomware.

Impact

Successful timestomping can allow attackers to maintain a persistent presence on a compromised system while evading detection by security tools and administrators. This can lead to prolonged data theft, system compromise, and other malicious activities. The technique is often used in conjunction with other evasion methods to further obscure malicious activity. A successful attack could lead to data exfiltration, ransomware deployment, or long-term espionage.

Recommendation

Enable Sysmon Event ID 2 (File creation time changed) logging to capture timestomping activity as described in the setup instructions.
Deploy the Sigma rule “Potential Timestomp in Executable Files” to your SIEM to detect suspicious file timestamp modifications.
Investigate any alerts generated by the Sigma rule, focusing on processes modifying file creation times in sensitive system directories.
Review the process ancestry of processes modifying file timestamps to identify potentially malicious parent processes.
Monitor for execution of files with recently modified timestamps using process creation logs.

Detection of Custom Shim Database Installation for Persistence

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

Attackers can exploit the Windows Application Compatibility Shim functionality to maintain persistence and execute arbitrary code within legitimate Windows processes. This is achieved by installing custom shim databases, which are designed to ensure older applications run smoothly on newer operating systems. By manipulating these databases, attackers can stealthily inject malicious code into trusted processes. The rule detects changes in specific registry paths associated with the installation of these databases, excluding known legitimate processes to minimize false positives. This technique allows for the execution of malicious code without directly modifying the target application’s executable, making it difficult to detect with traditional methods.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker modifies the registry to create a new entry for a custom shim database. The registry path targeted is typically under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\.
The attacker writes a malicious .sdb file containing the custom shim database to a location on disk.
The registry entry created points to the malicious .sdb file.
When a targeted application is launched, Windows checks the AppCompatFlags registry keys.
The system loads the malicious shim database specified in the registry.
The malicious code within the shim database is executed in the context of the targeted application.
The attacker achieves persistence, as the malicious shim database is loaded every time the targeted application is run.

Impact

Successful exploitation allows attackers to maintain persistent access to the system, even after reboots or software updates. The injected code runs within the context of a legitimate process, which can evade detection by traditional security tools. This can lead to data theft, system compromise, or further malicious activities, such as lateral movement within the network. The use of application shimming for persistence affects systems running Windows and can impact organizations of any size or sector.

Recommendation

Deploy the Sigma rule Detect Custom Shim Database Installation to your SIEM to identify suspicious registry modifications related to application shimming.
Enable Sysmon registry event logging to ensure the necessary data is available for the Sigma rule to function.
Investigate any alerts generated by the Sigma rule, focusing on processes that are not in the exclusion list.
Block or quarantine any identified malicious .sdb files to prevent further execution.
Review and update the exclusion list in the Sigma rule with any newly identified legitimate applications that use shim databases, reducing false positives.

Process Execution from Suspicious Windows Directories

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

This detection identifies process execution from suspicious default Windows directories. Attackers may hide malware in trusted paths to evade defenses, making it difficult for analysts to distinguish between legitimate and malicious activity. The detection focuses on identifying processes running from directories like C:\PerfLogs, C:\Users\Public, and various Windows subdirectories (e.g., C:\Windows\Tasks, C:\Windows\AppReadiness), where executable files are not typically expected to reside. The detection excludes known legitimate processes like SpeechUXWiz.exe, SystemSettings.exe, TrustedInstaller.exe and other Intel and IBM executables to reduce false positives. This technique is often used to bypass security controls or take advantage of existing exceptions applied to these directories. This activity was observed being used by threat actors in the Siestagraph campaign.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker drops a malicious executable into a suspicious directory like C:\Users\Public or C:\Windows\Tasks.
The attacker executes the malware from the unusual directory. This might be achieved using cmd.exe or powershell.exe.
The executed malware establishes persistence by creating a scheduled task or modifying registry keys.
The malware connects to a command-and-control (C2) server to receive further instructions.
The C2 server instructs the malware to perform reconnaissance on the network.
The malware attempts to move laterally to other systems on the network using techniques like pass-the-hash or exploiting vulnerabilities.
The attacker achieves their objective, such as data exfiltration, ransomware deployment, or establishing long-term access to the network.

Impact

Successful exploitation can lead to the execution of arbitrary code, persistence on the system, and further compromise of the network. Attackers can use this technique to bypass security controls and evade detection, potentially leading to data breaches, financial loss, or disruption of services. While the rule itself has a medium severity, the impact of a successful attack using this technique can be severe, depending on the attacker’s objectives and the compromised data.

Recommendation

Deploy the Sigma rule “Process Execution from Unusual Directory” to your SIEM and tune for your environment to detect suspicious process execution.
Investigate any alerts generated by the Sigma rule to determine if the process execution is legitimate or malicious.
Enable process creation logging, specifically Event ID 4688 with command line process auditing, to ensure the Sigma rule has the necessary data to function effectively.
Review and harden permissions on the listed suspicious directories to prevent unauthorized file creation and execution.
Block execution of unsigned or untrusted executables from these directories using application control solutions.

DCOM Lateral Movement via ShellWindows/ShellBrowserWindow

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

This detection identifies the abuse of Distributed Component Object Model (DCOM) for lateral movement within a Windows environment. DCOM allows software components to communicate across a network, and attackers may leverage it to execute commands remotely. This rule specifically focuses on the use of ShellBrowserWindow or ShellWindows Application COM objects as the launching point for these remote commands. The technique enables stealthy lateral movement, as it leverages legitimate Windows functionality. This activity is detected by identifying incoming TCP connections on high ports associated with explorer.exe spawning child processes, which are indicative of DCOM abuse. The rule is designed to detect this behavior and alert security teams to potential unauthorized lateral movement attempts.

Attack Chain

An attacker gains initial access to a compromised host within the network.
The attacker uses DCOM to initiate a connection to a target host.
The DCOM connection is established to the target host via high TCP ports (above 49151).
The explorer.exe process on the target host receives the DCOM connection.
The attacker uses ShellBrowserWindow or ShellWindows COM objects to execute commands.
explorer.exe spawns a child process to execute the attacker-supplied command.
The spawned process performs malicious actions, such as reconnaissance or further lateral movement.

Impact

Successful exploitation allows attackers to execute arbitrary commands on the target system, leading to potential data exfiltration, system compromise, and further lateral movement within the network. This can result in significant damage, including data breaches, financial losses, and reputational harm. The DCOM protocol is commonly used in many Windows environments, so this technique could be broadly applicable across many victim organizations.

Recommendation

Deploy the Sigma rule “DCOM Lateral Movement with Explorer.exe” to your SIEM and tune for your environment to detect suspicious process creations spawned by explorer.exe.
Enable Sysmon Event ID 3 (Network Connection) and Event ID 1 (Process Creation) logging to ensure the required data is available for the Sigma rule to function correctly.
Review network activity for incoming TCP connections to high ports (49151+) associated with explorer.exe, as highlighted in the “Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows” detection.
Investigate any unusual or unexpected child processes spawned by explorer.exe, as detected by the Sigma rule.

Suspicious Execution via Scheduled Task

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

This detection rule identifies suspicious program executions initiated by scheduled tasks on Windows systems. Adversaries often exploit scheduled tasks for persistence and to execute malicious programs. This rule focuses on detecting known malicious executables, such as PowerShell, Cmd, and MSHTA, when launched from unusual file paths like user directories or temporary folders. It leverages process lineage analysis, specifically looking for processes spawned by svchost.exe with the “Schedule” argument, to determine if the execution originated from a scheduled task. The rule aims to pinpoint potential threats effectively by excluding benign processes and focusing on suspicious combinations of executables and paths. The rule was last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker creates or modifies a scheduled task to execute a malicious payload. This task is designed to run at a specific time or event.
The Windows Task Scheduler service (svchost.exe with “Schedule” argument) initiates the scheduled task.
The scheduled task executes a suspicious executable, such as powershell.exe, cmd.exe, or mshta.exe.
The suspicious executable is launched from an unusual or suspicious path, such as C:\\Users\\, C:\\ProgramData\\, or C:\\Windows\\Temp\\.
The executed payload performs malicious activities, such as downloading additional malware, establishing persistence, or exfiltrating data.
The attacker maintains persistence on the system through the scheduled task, allowing for repeated execution of the malicious payload.

Impact

Successful exploitation allows attackers to maintain persistent access to the compromised system, execute malicious code, and potentially escalate privileges. This can lead to data theft, system compromise, and further lateral movement within the network. The damage includes potential data exfiltration, malware installation, and disruption of normal system operations.

Recommendation

Enable process creation logging with command line arguments to detect suspicious executions (logs-endpoint.events.process-* and logs-windows.sysmon_operational-*).
Deploy the Sigma rule “Suspicious Execution via Scheduled Task” to your SIEM to identify potentially malicious processes executed via scheduled tasks. Tune the rule to exclude legitimate software installations or updates (see rule section below).
Investigate any alerts generated by the Sigma rule, focusing on processes with suspicious original file names and command line arguments (process.pe.original_file_name, process.args).
Monitor scheduled tasks for unauthorized modifications or additions, as this is a common technique for persistence (registry_set).

Potential Credential Access via LSASS Handle Duplication

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

This detection identifies suspicious attempts to access the Local Security Authority Subsystem Service (LSASS) memory via the DuplicateHandle function on Windows systems. LSASS is a critical process that manages user credentials, making it a prime target for credential dumping attacks. Attackers may use DuplicateHandle to bypass the NtOpenProcess API, which is commonly monitored, to evade detection. The rule focuses on EventCode 10, looking for lsass.exe requesting DuplicateHandle access rights (0x40) where the call trace originates from an unknown executable region (UNKNOWN). This technique is often associated with tools like MirrorDump.

Attack Chain

An attacker gains initial access to the target system (e.g., via phishing or exploitation of a vulnerability).
The attacker executes a malicious program or script on the compromised system.
The malicious code attempts to open a handle to the LSASS process.
Instead of using NtOpenProcess, the attacker leverages the DuplicateHandle function to obtain a handle to LSASS.
The DuplicateHandle call originates from an unknown or suspicious module, as indicated by “UNKNOWN” in the call trace.
With a valid handle to LSASS, the attacker dumps the LSASS memory to a file or other location.
The attacker parses the dumped memory to extract sensitive credentials.
The attacker uses the stolen credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation could lead to the compromise of user credentials, including domain administrator accounts. This can give attackers unrestricted access to the entire domain, allowing them to steal sensitive data, install malware, or disrupt critical services. The impact can range from data breaches and financial loss to complete infrastructure compromise.

Recommendation

Enable Sysmon process creation and event 10 logging to capture the necessary telemetry for this detection. (Setup instructions: https://ela.st/sysmon-event-10-setup)
Deploy the Sigma rule “Potential Credential Access via DuplicateHandle in LSASS” to your SIEM and tune for your environment to reduce false positives.
Investigate any alerts generated by this rule by reviewing the event logs and call trace details to identify suspicious modules or processes.
Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function.

Windows Account Discovery of Administrator Accounts

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

Attackers often perform reconnaissance activities within a compromised environment to understand the available resources and potential targets. This reconnaissance helps them plan subsequent actions, such as privilege escalation and lateral movement. This activity involves using built-in Windows utilities like net.exe and wmic.exe to enumerate administrator-related user accounts and groups. This information can reveal potential targets for credential compromise or other post-exploitation activities. Lower privileged accounts commonly perform this enumeration.

Attack Chain

The attacker gains initial access to a Windows system.
The attacker executes net.exe with arguments to list users and groups.
The attacker filters the output for administrator-related keywords like “admin”, “Domain Admins”, “Enterprise Admins”, “Remote Desktop Users”, or “Organization Management”.
Alternatively, the attacker executes wmic.exe to query user accounts.
The attacker parses the output from wmic.exe to identify administrator accounts.
The attacker identifies privileged accounts to target for credential theft or privilege escalation.
The attacker uses the identified accounts to perform lateral movement or access sensitive data.

Impact

Successful enumeration of administrator accounts allows an attacker to identify high-value targets within the environment. This can lead to credential theft, privilege escalation, lateral movement, and ultimately, unauthorized access to sensitive data or systems. While the risk score is low, this activity serves as a precursor to more serious compromises.

Recommendation

Monitor process creation events for net.exe and wmic.exe commands with arguments related to user and group enumeration using the Sigma rules provided.
Investigate any instances of lower-privileged accounts executing these commands and filter out authorized administrative accounts performing the same actions.
Enable Windows process creation logging to capture the necessary events.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

Detection of Invoke-Obfuscation via Standard Input

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

Invoke-Obfuscation is a PowerShell obfuscation framework used to evade detection by security products. Attackers employ this technique to disguise malicious PowerShell code, making it harder to identify through static analysis or signature-based detection. This particular technique involves passing obfuscated PowerShell code via standard input (stdin) to the PowerShell interpreter. This method is often employed during the execution of scripts, where malicious code is dynamically constructed and executed, leaving a reduced footprint on the file system. Defenders should be aware of this technique because it is frequently used by threat actors in conjunction with other tactics to compromise systems and execute malicious payloads. This brief provides actionable detection strategies focused on identifying this specific obfuscation pattern.

Attack Chain

An attacker gains initial access through a vulnerability or other means (not covered in this brief).
The attacker uploads a small, initial-stage script or binary to the target system.
This script prepares the environment for PowerShell execution, potentially setting environment variables or disabling security features.
The script then calls powershell.exe with parameters designed to accept input from stdin.
Obfuscated PowerShell code generated by Invoke-Obfuscation is piped into the powershell.exe process via stdin. This code often contains commands to download, execute, or further obfuscate malicious payloads.
The powershell.exe process executes the obfuscated code from stdin, bypassing some common detection rules.
The deobfuscated code performs malicious actions such as lateral movement, data exfiltration, or persistence.
The attacker achieves their final objective, which may include data theft, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a full compromise of the targeted system, potentially impacting other systems within the network. Obfuscation makes incident response more difficult, as identifying and analyzing the malicious code requires additional effort. Affected systems could suffer data loss, service disruption, or financial damage. The use of Invoke-Obfuscation also indicates a deliberate attempt to evade security controls, suggesting a sophisticated attacker.

Recommendation

Deploy the Sigma rule Detect Invoke-Obfuscation Via Stdin to your SIEM to detect obfuscated PowerShell execution via standard input based on command-line patterns.
Enable process creation logging on Windows endpoints, ensuring that command-line arguments are captured to facilitate detection of obfuscated commands.
Investigate any process creation events where powershell.exe is executed with parameters that suggest input from stdin along with obfuscated code patterns.
Implement application control policies to restrict the execution of unauthorized PowerShell scripts, reducing the attack surface for Invoke-Obfuscation techniques.
Continuously update and refine detection rules to adapt to new obfuscation methods and variations of the Invoke-Obfuscation framework.

Adversaries Disabling Important Scheduled Tasks

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

Attackers are increasingly targeting scheduled tasks to disable critical system functions. This tactic involves using schtasks.exe to disable essential tasks related to security, backup, and update mechanisms. By disabling tasks like Windows Defender scans, System Restore points, BitLocker encryption, and Windows Update, adversaries can significantly weaken a system’s defenses, making it more vulnerable to data destruction or ransomware attacks. The observed behavior involves the execution of…

Windows Time-Based Evasion via Choice Exec

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

This brief focuses on the detection of choice.exe being used within batch files as a time-delay tactic, a technique notably employed by the SnakeKeylogger malware. The analysis leverages data from Endpoint Detection and Response (EDR) agents, scrutinizing process names and command-line executions. This behavior is significant because it suggests the implementation of time-based evasion techniques designed to circumvent detection mechanisms. Successful evasion could enable attackers to execute malicious code covertly, remove incriminating files, and establish persistent access on compromised systems. The use of choice.exe for such purposes warrants immediate investigation by security operations center (SOC) analysts due to the potential for significant system compromise and data exfiltration.

Attack Chain

The attacker gains initial access via an unknown vector.
A batch script is executed on the target system.
The batch script uses choice.exe with the /T and /N parameters to introduce a time delay. The /T parameter specifies a timeout period, and the /N parameter suppresses the display of choices.
This delay allows the malware to evade time-sensitive detection mechanisms.
After the delay, the script executes further commands, potentially downloading and executing a payload.
The payload executes, installing a keylogger such as SnakeKeylogger or 0bj3ctivity Stealer.
The keylogger captures sensitive information such as keystrokes and clipboard data.
The stolen data is exfiltrated to a remote server.

Impact

Compromised systems can lead to data theft, intellectual property loss, and financial fraud. SnakeKeylogger and similar malware have been used to steal credentials and sensitive information from various targets. Successful exploitation could result in significant financial losses, reputational damage, and legal liabilities. The number of victims and the extent of the damage depend on the attacker’s objectives and the compromised systems’ value.

Recommendation

Deploy the Sigma rule Detect Choice.exe Time Delay to your SIEM to detect the use of choice.exe with time-delay parameters (log source: process_creation).
Enable Sysmon process creation logging (Event ID 1) to capture the necessary process execution data for the Sigma rule.
Investigate any instances of choice.exe being used with the /T and /N parameters to determine if it is part of a malicious script.
Block the execution of unsigned or untrusted batch scripts to prevent the initial execution of the malicious code.
Monitor endpoint activity for suspicious processes and network connections originating from systems where choice.exe has been detected.

Windows AutoLogger Session Tampering Detection

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

Attackers are increasingly targeting Windows Event Tracing (ETW) and AutoLogger sessions to evade detection. The AutoLogger session is crucial as it records events early in the operating system boot process, providing security solutions with essential telemetry. This technique involves tampering with registry keys associated with AutoLogger sessions, specifically disabling or stopping them by setting DWORD values to 0. This is done to blind security solutions, preventing them from monitoring early boot activities and critical system events. Disabling these sessions allows adversaries to operate with less scrutiny, making it harder to detect malicious activities during the initial phases of a system compromise. This technique has been observed in attacks involving IcedID and XingLocker ransomware.

Attack Chain

Initial access is achieved through an as-yet-unspecified method (e.g., exploitation, phishing).
The attacker gains administrative privileges on the target system.
The attacker identifies AutoLogger sessions to disable, focusing on those relevant to security monitoring, such as ‘\EventLog-’ or ‘\Defender’.
The attacker modifies the registry to disable the targeted AutoLogger sessions. This involves setting the ‘Enabled’ or ‘Start’ DWORD values under the HKLM\System\CurrentControlSet\Control\WMI\Autologger registry key to 0.
The attacker may use tools like wevtutil.exe or directly interact with the registry via PowerShell or cmd.exe to make these changes.
The security monitoring capabilities reliant on the tampered AutoLogger sessions are effectively impaired or disabled.
With logging impaired, the attacker proceeds with the main objectives, such as lateral movement, data exfiltration, or ransomware deployment, with a reduced risk of detection.
The ultimate goal is to compromise the system, steal data, or deploy ransomware, bypassing security measures that rely on early boot and system event logging.

Impact

Successful tampering with AutoLogger sessions can significantly reduce the visibility of security solutions, allowing attackers to operate undetected for extended periods. This can lead to delayed incident response, increased dwell time, and greater potential for damage, including data breaches, financial losses, and reputational damage. The sectors most at risk are those heavily reliant on Windows-based systems and proactive security monitoring. The DFIR Report documented a case where adversaries moved from IcedID infection to XingLocker ransomware deployment within 24 hours, highlighting the speed and potential impact of these attacks.

Recommendation

Deploy the Sigma rule Potential AutoLogger Sessions Tampering to your SIEM to detect malicious registry modifications related to AutoLogger sessions.
Investigate any registry modifications under the \Control\WMI\Autologger\ path, focusing on changes to Enabled or Start values, as identified in the Sigma rule.
Monitor process creation events for wevtutil.exe modifying registry keys related to AutoLogger, as specified in the filter_main_wevtutil section of the Sigma rule.
Correlate registry modification events with process execution events to identify the source of the tampering, paying close attention to processes originating from the Windows Defender platform, as outlined in the filter_main_defender section of the Sigma rule.
Implement endpoint detection and response (EDR) solutions with robust registry monitoring capabilities to identify and block unauthorized modifications to AutoLogger settings.

Unusual Network Activity from Windows System Binaries

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

Attackers frequently abuse trusted Windows system binaries and developer utilities to proxy the execution of malicious payloads, effectively bypassing security controls that would otherwise prevent direct execution. This technique, known as “System Binary Proxy Execution,” allows adversaries to masquerade their activities and blend in with legitimate system processes. This detection identifies network activity from system applications such as mshta.exe, regsvr32.exe, and installutil.exe that are not expected to initiate network connections under normal circumstances. The original rule was created in September 2020, and updated in May 2026. The scope of targeting includes any Windows environment where adversaries might attempt to evade detection by proxying malicious activity through trusted system binaries.

Attack Chain

An attacker gains initial access to the system, often through phishing or exploiting a vulnerability.
The attacker drops a malicious payload onto the system, potentially obfuscated to avoid detection.
The attacker uses a trusted system binary, such as mshta.exe, regsvr32.exe, or installutil.exe to execute the payload.
The system binary initiates a network connection, potentially to a command-and-control (C2) server.
The attacker uses the C2 channel to download additional tools or exfiltrate data.
The attacker moves laterally within the network, compromising additional systems.
The attacker achieves their final objective, such as data theft, ransomware deployment, or system disruption.

Impact

Successful exploitation can lead to a variety of negative impacts, including data breaches, system compromise, and potential financial losses. The technique is often employed in targeted attacks and can be difficult to detect due to the use of legitimate system binaries. If successful, attackers can maintain persistence, escalate privileges, and move laterally within the network, leading to widespread damage.

Recommendation

Enable Sysmon process creation (Event ID 1) and network connection (Event ID 3) logging to provide the necessary data for detection.
Deploy the Sigma rules in this brief to your SIEM to detect unusual network activity from Windows system binaries.
Regularly review and update the list of known benign network connections from these binaries to reduce false positives.
Implement application control policies to restrict the execution of untrusted applications.
Monitor DNS queries (Sysmon Event ID 22) for suspicious domain resolutions originating from system binaries.

Script Execution via Microsoft HTML Application

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Script Interpreter Execution from Environment Variable Folders

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

Attackers may attempt to execute malicious scripts from suspicious directories or folders accessible by environment variables. This technique leverages script interpreters such as cscript.exe, wscript.exe, mshta.exe, and powershell.exe to run scripts from locations like the Temp directory, the Public user folder, or other user profile directories. The use of these locations can help attackers evade detection, as security tools may not thoroughly inspect files executed from these typically benign locations. This activity has been associated with threat actors such as Shuckworm, known to target Ukraine military.

Attack Chain

The attacker gains initial access, potentially through phishing or exploiting a software vulnerability.
A malicious script is dropped into a suspicious folder such as C:\Users\Public\, %TEMP%, or C:\Users\\AppData\Local\Temp.
The attacker uses cscript.exe, wscript.exe, or mshta.exe to execute the dropped script. The command line may contain flags to bypass execution policies (e.g., -ExecutionPolicy bypass) or hide the window (e.g., -w hidden).
Alternatively, PowerShell may be invoked with the -ep bypass or -ExecutionPolicy Bypass flags, along with a command to execute the script located in the temporary folder.
The script executes, performing malicious actions such as downloading additional payloads, establishing persistence, or exfiltrating data.
The script may leverage built-in Windows utilities for further malicious activities.
The attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to a range of damaging outcomes, including system compromise, data theft, and further propagation of malware within the network. Organizations may experience data breaches, financial losses, and reputational damage. The compromise of systems can also disrupt business operations and require extensive recovery efforts.

Recommendation

Deploy the Sigma rule Script Interpreter Execution From Suspicious Folder to your SIEM to detect suspicious script executions.
Monitor process creation events with a focus on script interpreters (cscript.exe, wscript.exe, mshta.exe, powershell.exe) executing from suspicious directories, using the logsource and detection sections of the Sigma rule as a guide.
Tune the filters in the Sigma rule based on your environment to reduce false positives, as described in the falsepositives section.
Review and block any observed malicious command lines containing flags like -ep bypass, -ExecutionPolicy bypass, or -w hidden, as detailed in the selection_proc_flags section of the Sigma rule.

Invoke-Obfuscation via Clip.exe

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

Attackers are increasingly using obfuscation techniques to evade detection, specifically leveraging clip.exe in conjunction with PowerShell and command-line interpreters. This combination allows for the execution of malicious code while bypassing traditional signature-based detections. This activity often includes encoding and splitting commands to avoid string-based detection. Invoke-Obfuscation is a known framework used to generate these types of payloads. Defenders should focus on detecting the specific patterns of command execution and data manipulation that are characteristic of this technique. The detection of such obfuscated PowerShell commands is crucial for identifying and mitigating potential security breaches.

Attack Chain

Attacker gains initial access to the target system (e.g., via phishing or exploiting a vulnerability).
A command interpreter (cmd.exe) is invoked to execute a complex, obfuscated command.
The command includes echo to write data to standard output, piping the output to clip.exe.
clip.exe places the output (part of the malicious PowerShell code) into the clipboard.
Another cmd.exe process invokes PowerShell to execute the content retrieved from the clipboard.
PowerShell uses reflection to load and execute .NET assemblies from the clipboard.
The executed code performs malicious actions, such as downloading additional payloads or establishing persistence.
The clipboard content is cleared to remove traces of the injected code.

Impact

Successful execution of obfuscated PowerShell commands can lead to a range of malicious activities, including malware installation, data theft, and remote system control. The use of clip.exe and other obfuscation techniques significantly hinders detection efforts, potentially allowing attackers to operate undetected for extended periods. This can result in significant financial losses, data breaches, and reputational damage for affected organizations.

Recommendation

Deploy the Sigma rule “Detect Invoke-Obfuscation Via Use Clip” to your SIEM to detect command lines using clip.exe and obfuscated PowerShell (see rule details).
Monitor process creation events for instances of cmd.exe invoking clip.exe with command lines containing echo piped to clip.exe (logsource: process_creation, product: windows).
Inspect PowerShell execution logs for commands that access the clipboard, especially when followed by assembly loading or remote code execution (logsource: process_creation, product: windows).

Unusual Network Connection via DllHost

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Execution from a Mounted Device

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

This detection rule identifies suspicious execution of script interpreters or signed binaries from mounted devices in Windows environments. Attackers attempt to evade defenses by launching processes from non-standard directories, such as mounted devices. This technique can be employed following initial access via phishing or other means. The focus is on processes spawned by explorer.exe with a working directory on removable drives (D, E, F) and named rundll32.exe, mshta.exe, powershell.exe, pwsh.exe, cmd.exe, regsvr32.exe, cscript.exe, wscript.exe, certutil.exe, bitsadmin.exe, msiexec.exe, wmic.exe, schtasks.exe, or msbuild.exe. This behavior is anomalous and indicative of potential malicious activity. The rule originates from Elastic’s detection rule set.

Attack Chain

User unknowingly executes a malicious file (T1204.002) or opens a phishing email leading to drive-by compromise.
The malicious file is downloaded onto the system, potentially onto a mounted device such as a USB drive (D:, E:, or F:).
The user interacts with the mounted device via explorer.exe, inadvertently triggering the execution of a malicious script or binary (TA0002).
The script interpreter (e.g., powershell.exe, cmd.exe) or a signed binary (e.g., mshta.exe, regsvr32.exe) is executed from the mounted device (T1059).
The process inherits the working directory from the mounted device, further masking its origin.
The script or binary performs malicious actions, such as downloading additional malware, establishing persistence, or exfiltrating data (TA0005).
The attacker leverages the trusted binary or interpreter to proxy execution of their malicious code (T1127, T1218).
The system is compromised, potentially leading to data theft, ransomware deployment, or lateral movement within the network.

Impact

A successful attack of this nature can lead to the compromise of Windows systems. Attackers can evade traditional defenses, making detection more challenging. The impact can range from data theft and system compromise to lateral movement and ransomware deployment. Organizations may experience financial loss, reputational damage, and operational disruption if systems are successfully compromised using this technique.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture process execution events, including the working directory and parent process, which is essential for activating the rules below.
Deploy the “Suspicious Execution from Mounted Device” Sigma rule to your SIEM to detect potentially malicious processes being launched from unusual locations and tune for your environment.
Implement application control policies to restrict the execution of script interpreters and signed binaries from removable drives to mitigate the risk of this attack.
Educate users about the risks of executing files from untrusted sources, particularly from removable media, to prevent initial infection (T1204).

Suspicious CertUtil Commands Used for Defense Evasion

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

CertUtil is a command-line utility included with Windows, designed for managing digital certificates and certificate services. Attackers frequently abuse it to “live off the land” by downloading malware, deobfuscating files, and establishing command and control channels within compromised environments. This activity leverages certutil.exe to perform actions typically associated with malicious payloads, blending in with legitimate system activity and evading traditional security measures. The tool’s capability to encode, decode, and retrieve files from URLs makes it a versatile asset for attackers aiming to maintain a low profile while executing malicious operations. This detection focuses on identifying specific command-line arguments indicative of this abuse, such as those used for encoding, decoding, and URL retrieval.

Attack Chain

The attacker gains initial access through an undisclosed means (e.g., phishing, exploit).
The attacker executes certutil.exe via cmd.exe or PowerShell.
Certutil is used with the urlcache parameter to download a malicious payload from a remote server.
Certutil uses the decode parameter to decode a base64-encoded payload, saving it to disk.
The attacker uses certutil with encodehex to encode a binary into a hexadecimal representation to evade signature-based detection.
The attacker then uses certutil with decodehex to decode the hexadecimal encoded data.
The attacker executes the decoded payload, gaining further control of the system.
The attacker establishes a command and control channel, using certutil to encode/decode communications.

Impact

Successful exploitation allows attackers to download and execute arbitrary code, bypass security measures, and maintain persistence within the compromised system. This can lead to data exfiltration, system compromise, and further propagation of the attack within the network. The lack of directly observed IOCs in the originating advisory limits quantification of victim count and impact scope, but the technique is widely applicable.

Recommendation

Deploy the Sigma rule “Suspicious CertUtil Usage for Encoding/Decoding” to detect abuse of encoding/decoding functions within certutil.exe, focusing on unusual file types or destinations.
Deploy the Sigma rule “Suspicious CertUtil URL Download” to identify certutil.exe being used to download files from URLs, and tune the rule based on known good software deployment practices.
Enable Sysmon process creation logging to ensure the rules above function correctly by capturing command-line arguments (as referenced in the logsource for each rule).
Review historical process execution logs for instances of certutil.exe using suspicious parameters like decode, encode, urlcache, verifyctl, encodehex, decodehex, or exportPFX to identify potentially compromised systems.

Detecting Remote Windows Service Installation for Lateral Movement

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

This detection rule identifies a potential lateral movement technique where an attacker establishes a network logon to a Windows system and subsequently installs a service using the same LogonId. This behavior is flagged as suspicious because it deviates from typical administrative practices and can indicate unauthorized access and persistence within the network. The rule is designed to filter out common legitimate services and administrative activities, focusing on anomalies that could signify malicious intent. This detection is crucial for defenders as it can uncover attackers attempting to move laterally and establish persistent access.

Attack Chain

An attacker gains initial access to a network via compromised credentials or exploiting a vulnerability.
The attacker performs network reconnaissance to identify target systems for lateral movement.
Using valid credentials or pass-the-hash techniques, the attacker authenticates to a remote Windows host over the network (e.g., SMB).
The attacker attempts to install a new service on the remote host, potentially using tools like sc.exe or PowerShell.
The service installation event is logged with a specific LogonId that matches the earlier network logon event, indicating a relationship between the two activities.
The newly installed service is configured to execute a malicious payload or establish a reverse shell.
The attacker uses the service to execute commands or deploy further malicious tools on the compromised host.
The attacker achieves persistence and lateral movement within the network, enabling further compromise and data exfiltration.

Impact

A successful attack using this technique can lead to widespread compromise of systems within a network. Attackers can use the newly installed service to execute arbitrary code, install malware, or move laterally to other systems. This can result in data theft, system disruption, or ransomware deployment. The impact can be significant, potentially affecting numerous systems and causing substantial financial and reputational damage.

Recommendation

Enable Windows Security Event Logs with necessary auditing policies, specifically Audit Logon and Audit Security System Extension, to capture relevant logon and service installation events.
Deploy the provided Sigma rules to your SIEM to detect suspicious remote service installations based on matching LogonIds from network logons.
Investigate any alerts generated by the Sigma rules, focusing on unusual service file paths and user accounts.
Review the list of excluded service file paths in the Sigma rules and customize them based on your environment’s known legitimate services.
Monitor network connections for suspicious SMB activity, particularly connections originating from unusual or untrusted sources.
Implement multi-factor authentication (MFA) to reduce the risk of credential theft and unauthorized network access.

Windows USN Journal Deletion via Fsutil

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

Attackers can use the fsutil.exe utility to delete the volume USN Journal in Windows. The USN Journal tracks changes made to files and directories on a disk volume, including metadata for file creation, deletion, modification, and permission changes. Deleting this journal can hinder forensic analysis by removing evidence of file operations. This technique is used to cover tracks and evade detection after an initial compromise. This activity is often observed during the post-exploitation phase of an attack, where adversaries attempt to remove traces of their presence and actions on the compromised system.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes fsutil.exe via command line.
The command fsutil usn deletejournal /D [volume] is used to delete the USN Journal on the specified volume.
The operating system processes the command, removing the USN Journal.
Subsequent file system activity is no longer recorded in the USN Journal.
The attacker performs further actions on the system, such as lateral movement or data exfiltration.
Forensic analysis is hampered due to the missing USN Journal entries.

Impact

Successful deletion of the USN Journal impairs forensic investigations and incident response efforts. Without the USN Journal, analysts may struggle to determine the full scope of an intrusion, including files created, modified, or deleted by the attacker. This can lead to incomplete remediation and a higher risk of reinfection.

Recommendation

Deploy the Sigma rule “Detect USN Journal Deletion via Fsutil” to your SIEM to identify this specific behavior.
Monitor process execution events for fsutil.exe with arguments related to “deletejournal” and “usn” to detect potential attempts to delete the USN Journal.
Enable Sysmon process creation logging to capture the execution of fsutil.exe with the relevant arguments.

Windows System Restore Disabled via Registry Modification

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

Attackers may disable the Windows System Restore feature to prevent victims from easily reverting their systems to a clean state after an infection or other malicious activity. This action complicates incident response and remediation efforts, forcing more complex and time-consuming recovery procedures. Disabling system restore is often performed post-compromise to ensure persistence and hinder forensic analysis. This technique can be implemented manually through the registry editor or via automated scripts, making it accessible to a wide range of threat actors.

Attack Chain

Initial access is gained through various methods (e.g., phishing, exploitation).
The attacker escalates privileges to Administrator or SYSTEM.
The attacker uses reg.exe or PowerShell to modify registry keys.
The attacker targets the HKLM\Software\Policies\Microsoft\Windows NT\SystemRestore\DisableConfig registry key.
Alternatively, the attacker targets the HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore\DisableSR registry key.
The attacker sets the value of the targeted registry key to DWORD:00000001.
The attacker confirms the System Restore feature is disabled.
The attacker proceeds with further malicious activities, knowing that recovery is hindered.

Impact

Disabling System Restore can significantly impede recovery efforts following a cyber incident. Organizations may face longer downtimes and increased costs associated with manual system reimaging or advanced forensic analysis. The absence of readily available restore points can also lead to data loss if systems are severely damaged or encrypted.

Recommendation

Deploy the Sigma rule Registry Disable System Restore to your SIEM to detect malicious attempts to disable System Restore via registry modification.
Monitor registry modifications related to System Restore configurations, focusing on the keys \Policies\Microsoft\Windows NT\SystemRestore and \Microsoft\Windows NT\CurrentVersion\SystemRestore, and values set to DWORD (0x00000001).
Implement strict access controls to prevent unauthorized modification of registry settings.

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.

Unusual Scheduled Task Update

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

This detection identifies first-time modifications to scheduled tasks by non-system users on Windows systems. Adversaries frequently abuse scheduled tasks to achieve persistence by modifying existing tasks or creating new ones that execute malicious code at recurring intervals. This rule focuses on detecting unauthorized changes to existing tasks by filtering out known system accounts (SYSTEM, Local Service, Network Service) and machine accounts, thereby highlighting potentially suspicious user activity. The rule leverages Windows Security Event Logs (event code 4702) to monitor task modifications. The goal is to aid in the early detection of threats where attackers are attempting to establish persistence on a compromised system.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker enumerates existing scheduled tasks on the system using tools like schtasks.exe or PowerShell cmdlets.
The attacker identifies a suitable scheduled task to modify for persistence.
The attacker modifies the task’s settings, such as the trigger time, the executable to run, or the arguments passed to the executable. This modification is logged as event ID 4702.
The scheduled task is updated using schtasks.exe /change or PowerShell’s Set-ScheduledTask cmdlet.
The modified scheduled task executes at the specified time, launching the attacker’s malicious payload.
The malicious payload establishes a reverse shell to the attacker’s command and control (C2) server.
The attacker uses the reverse shell to perform further actions on the compromised system, such as data exfiltration or lateral movement.

Impact

A successful attack involving the modification of scheduled tasks can lead to persistent access to a compromised system. The attacker can use this access to steal sensitive data, install malware, or perform other malicious activities. While this rule is low severity, it can uncover attackers attempting to persist in a network.

Recommendation

Enable “Audit Other Object Access Events” to generate the required Windows Security Event Logs (event ID 4702) as described in the setup instructions.
Deploy the Sigma rule provided below to your SIEM to detect unusual scheduled task updates.
Investigate any alerts generated by this rule to determine if the scheduled task modification is legitimate or malicious.
Review the references provided to understand the underlying event IDs and attacker techniques related to scheduled tasks.

Uncommon Registry Persistence Change Detection

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

This detection identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts on Windows systems. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The rule filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations. The rule focuses on changes to registry keys such as HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell and HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run. This rule is designed for data generated by Elastic Defend and also supports third-party data sources such as Sysmon. The rule was last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker executes code on the system, potentially using a dropper or exploit.
The attacker identifies uncommon registry keys suitable for persistence.
The attacker modifies the registry key to point to a malicious executable or script. This may involve adding a new entry or modifying an existing one.
The system restarts, or the user logs in, triggering the execution of the malicious code through the modified registry key.
The malicious code executes with the privileges of the user or system, depending on the registry key modified.
The attacker achieves persistence, allowing them to maintain access to the system even after restarts.
The attacker performs malicious activities such as data exfiltration, lateral movement, or deploying ransomware.

Impact

A successful attack can lead to persistent access to the compromised system, allowing the attacker to maintain control and execute malicious activities. This can lead to data theft, system disruption, or further compromise of the network. The impact can range from a single workstation being compromised to a widespread enterprise-level breach, depending on the attacker’s objectives and the scope of the initial compromise.

Recommendation

Deploy the “Uncommon Registry Persistence Change” Sigma rule to your SIEM to detect modifications to uncommon registry persistence keys and tune for your environment.
Enable Sysmon registry event logging to ensure the visibility required for the Sigma rule to function effectively (see references).
Review and tune the filter conditions in the Sigma rule to reduce false positives, specifically excluding legitimate software installations, system maintenance processes, and administrative scripts.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process responsible for the registry modification and correlating it with other suspicious activities.
Block execution of known malicious executables and scripts identified during the investigation to prevent further compromise.

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 Script Interpreter Execution from Environment Variable Folders

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

Attackers often leverage script interpreters like cscript.exe, wscript.exe, mshta.exe, and powershell.exe to execute malicious code. This activity becomes more suspicious when these interpreters are launched from directories referenced by environment variables commonly associated with temporary storage, such as %TEMP%, %PUBLIC%, or within user profile directories like Favorites or Contacts. This behavior is often indicative of malware attempting to evade detection by residing in locations less scrutinized by security tools. Such techniques are employed to execute malicious scripts downloaded from the internet or dropped by other malware components. This behavior has been linked to threat actors such as Shuckworm, known for targeting Ukraine with military-themed lures.

Attack Chain

A user downloads a malicious file (e.g., a document or executable) from the internet or receives it via email.
The malicious file, upon execution, drops a script file (e.g., VBScript, JavaScript, PowerShell script) into a temporary directory like C:\Users\Public\ or C:\Users\AppData\Local\Temp.
The dropped script uses obfuscation and/or encoding techniques to avoid static analysis.
The attacker executes a script interpreter (cscript.exe, wscript.exe, mshta.exe, powershell.exe) to run the malicious script from the temporary directory. The command line often includes bypass flags such as -ExecutionPolicy Bypass or -w hidden to evade security controls.
The script interpreter executes the malicious code, which may involve downloading additional payloads, establishing persistence, or performing lateral movement.
The malicious script may modify registry keys to establish persistence by adding a run key or scheduled task.
The script may attempt to connect to command-and-control (C2) servers to receive further instructions and exfiltrate sensitive data.
The final objective may include data theft, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to the execution of arbitrary code, system compromise, and data exfiltration. Depending on the attacker’s objectives, the impact can range from data theft to full system control and ransomware deployment. The exploitation of scripting engines can bypass application control policies and other security measures, leading to widespread infection and significant disruption of business operations.

Recommendation

Deploy the Sigma rule “Script Interpreter Execution From Suspicious Folder” to your SIEM to detect suspicious script execution from temporary directories.
Review and tune the filters in the Sigma rule for your environment to reduce false positives, especially related to software installation processes.
Enable process creation logging with command-line arguments to provide the necessary data for the Sigma rule to function effectively.
Monitor PowerShell execution policies and restrict script execution to signed scripts only to prevent the execution of unsigned malicious scripts.
Implement application control policies to restrict the execution of script interpreters from untrusted locations.

Suspicious Network Connection via Registration Utility

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

Attackers may abuse native Windows registration utilities such as regsvr32.exe, RegAsm.exe, and RegSvcs.exe to execute malicious code and bypass security controls. These utilities are often used to register and unregister COM objects and .NET assemblies, but can also be leveraged to download and execute arbitrary scripts from remote locations. The behavior is commonly seen in post-exploitation scenarios. This activity can be used to bypass application allow lists and evade defenses. This behavior has been observed across multiple threat actors and attack campaigns, making it a reliable indicator of suspicious or malicious activity. This detection focuses on the network connection initiated by these utilities, highlighting potential misuse.

Attack Chain

An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.
The attacker uses a registration utility (e.g., regsvr32.exe) to execute a malicious script or download a payload from a remote server.
The registration utility makes an outbound network connection to a malicious server to download the payload.
The downloaded payload is executed, potentially leading to further compromise of the system.
The attacker performs reconnaissance on the compromised system to gather information about the environment.
The attacker moves laterally to other systems on the network, leveraging the compromised system as a pivot point.
The attacker installs persistence mechanisms to maintain access to the compromised environment.
The attacker exfiltrates sensitive data or deploys ransomware, depending on their objectives.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to install malware, steal sensitive data, or disrupt business operations. The affected systems can be used as a beachhead for further attacks on the internal network, potentially leading to widespread compromise. The use of signed Microsoft binaries makes detection more challenging, as these tools are often trusted by default. While the risk_score is low at 21 and severity low, this is often related to initial access and could lead to high impact down the line.

Recommendation

Enable Sysmon process creation (Event ID 1) and network connection (Event ID 3) logging to ensure visibility into the execution of registration utilities and their network activity.
Deploy the Sigma rules in this brief to your SIEM to detect suspicious network connections initiated by regsvr32.exe, RegAsm.exe, and RegSvcs.exe.
Investigate any alerts generated by the Sigma rules, focusing on the command-line arguments used and the destination IP addresses.
Implement network segmentation to limit the potential impact of a compromised system, restricting lateral movement.
Monitor for unexpected registry modifications associated with the execution of registration utilities, as these can indicate persistence mechanisms.
Review and update application allow lists to ensure that only authorized uses of registration utilities are permitted.

Suspicious Copy from or to System Directory

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

Attackers often copy legitimate operating system binaries (LOLBINs) from standard system directories to evade detection. This technique involves using command-line tools like cmd.exe, powershell.exe, robocopy.exe, or xcopy.exe to move these binaries to different locations on the disk, frequently with modified names. By relocating and renaming LOLBINs, threat actors attempt to bypass security measures that rely on file path or filename-based detection. This technique has been observed in various attack campaigns, including those involving malware delivery and ransomware deployment. This behavior aims to execute malicious operations under the guise of legitimate system processes, complicating forensic analysis and incident response efforts.

Attack Chain

Initial access is achieved through an undisclosed method (e.g., exploitation, phishing).
The attacker gains command execution on the target system.
The attacker uses cmd.exe or powershell.exe to initiate a copy operation.
The command line includes the copy command, copy-item, cp, or cpi to copy a file.
The source file is located within a Windows system directory such as C:\\Windows\\System32, C:\\Windows\\SysWOW64, or C:\\Windows\\WinSxS.
The destination directory is outside the standard system directories.
The copied binary is then executed from the new location.
The attacker uses the LOLBIN to perform further malicious actions, such as downloading payloads or executing arbitrary code.

Impact

Successful execution of this attack allows threat actors to evade traditional security detections by using renamed and relocated LOLBINs. This can lead to the successful execution of malicious payloads, potentially resulting in data theft, system compromise, or ransomware deployment. The impact can range from localized infections to domain-wide ransomware attacks, depending on the attacker’s objectives and the scope of the compromise.

Recommendation

Deploy the Sigma rule “Suspicious Copy From or To System Directory” to your SIEM to detect this behavior and tune for your environment.
Investigate any process_creation events where cmd.exe or powershell.exe is used to copy files from system directories as indicated by the rule and the details in the Attack Chain section.
Monitor for the execution of LOLBINs such as certutil.exe, robocopy.exe, and xcopy.exe from non-standard locations.
Implement application control policies to restrict the execution of unauthorized or relocated binaries.

Service Startup Type Modification via WMIC

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

Attackers may leverage WMIC, a legitimate Windows command-line utility, to modify the startup type of services. This tactic is often used to disable security products or critical system services, hindering incident response or creating system instability. By setting services to “Manual” or “Disabled”, adversaries ensure that these services do not automatically start upon system boot, achieving persistence or impeding detection. While WMIC is a built-in tool, its use for modifying service startup types is often indicative of malicious activity, especially when performed on security-related services. This activity may be part of a larger attack chain aimed at deploying ransomware, exfiltrating data, or establishing a persistent presence on the compromised system.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing, exploiting a vulnerability, or compromised credentials.
The attacker executes wmic.exe with specific command-line arguments to interact with Windows services.
The service alias is invoked within WMIC to target specific services.
The ChangeStartMode method is used to modify the startup type of the targeted service.
The attacker sets the startup type to either Manual or Disabled, preventing the service from automatically starting on subsequent reboots.
If the targeted service is a security product, this action effectively disables the defense mechanism.
The attacker proceeds with further malicious activities, such as deploying malware or exfiltrating sensitive data, with reduced resistance.
The compromised system experiences degraded security posture and potential operational disruptions.

Impact

Successful modification of service startup types can severely impact system security and availability. Disabling security software can lead to undetected malware infections and data breaches. Disabling critical system services can cause system instability, data loss, or complete system failure. While the exact number of victims is unknown, this technique is broadly applicable across Windows environments, potentially affecting organizations of any size and in any sector. The impact ranges from minor operational disruptions to significant financial losses due to data breaches and ransomware attacks.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious wmic.exe process creations that attempt to change service startup types.
Investigate any instances where wmic.exe is used to modify service startup types, especially when the targeted services are related to security or critical system functions.
Implement endpoint detection and response (EDR) solutions to provide enhanced visibility into process execution and system modifications.
Regularly review and audit service configurations to identify unauthorized changes.

SeDebugPrivilege Enabled by a Suspicious Process

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

This detection rule identifies processes running under non-SYSTEM accounts that enable the SeDebugPrivilege. This privilege, typically reserved for system-level tasks, allows a process to debug and modify other processes. Adversaries may enable SeDebugPrivilege to escalate their privileges and bypass access controls, potentially gaining unauthorized access to sensitive data or system resources. The rule aims to detect suspicious processes enabling this privilege, excluding known legitimate processes, to flag potential privilege escalation attempts. This rule was last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., phishing, exploiting a vulnerability).
The attacker executes a malicious process on the compromised system.
The malicious process attempts to enable the SeDebugPrivilege.
Windows Security Auditing logs a “Token Right Adjusted Events” event, indicating that a process has enabled SeDebugPrivilege.
The detection rule identifies the event, filtering out known legitimate processes that may legitimately enable this privilege (e.g., msiexec.exe, taskhostw.exe).
The rule triggers an alert, indicating a potential privilege escalation attempt.
Security analysts investigate the alert to determine the legitimacy of the process enabling SeDebugPrivilege and the context of its execution.

Impact

Successful exploitation and enabling of SeDebugPrivilege can allow an attacker to debug and modify other processes, potentially gaining access to sensitive information, escalating privileges to SYSTEM level, and bypassing security controls. This can lead to a complete compromise of the affected system and potentially lateral movement to other systems on the network. The impact is high, especially in environments where sensitive data is processed or stored.

Recommendation

Enable Audit Token Right Adjusted Events to ensure proper logging of SeDebugPrivilege usage as per the setup instructions.
Deploy the “SeDebugPrivilege Enabled by a Suspicious Process” Sigma rule to your SIEM to detect potential privilege escalation attempts.
Review and tune the exclusion list in the Sigma rule to minimize false positives, considering legitimate processes in your environment, as described in the False positive analysis.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the process enabling SeDebugPrivilege.
Monitor systems for unauthorized access or lateral movement following the detection of SeDebugPrivilege enabling.

Remote Scheduled Task Creation via RPC

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

This detection identifies the creation of scheduled tasks on Windows systems originating from a remote source using Remote Procedure Call (RPC). The creation of scheduled tasks is a common technique used for persistence and execution. While administrators may legitimately use this functionality for remote management, adversaries also leverage it for lateral movement and executing malicious code on compromised systems. The rule specifically looks for RPC calls where the client locality and process ID are 0, suggesting the task was created remotely. Identifying this activity allows defenders to investigate potentially malicious lateral movement and unauthorized task execution. This activity has been observed across various Windows environments.

Attack Chain

An attacker gains initial access to a network, potentially through phishing or exploiting a vulnerability.
The attacker identifies a target system within the network accessible via RPC.
The attacker establishes an RPC connection to the target system.
Using the RPC connection, the attacker creates a new scheduled task on the target system. The RpcCallClientLocality and ClientProcessId are set to 0 in the task creation event, indicating remote origin.
The scheduled task is configured to execute a malicious payload or command. This could involve running a script, executable, or PowerShell command.
The scheduled task is triggered based on a defined schedule or event.
The malicious payload executes on the target system, achieving the attacker’s objective.
The attacker uses the compromised system to further pivot within the network, repeating the process on other targets.

Impact

Successful exploitation can lead to the establishment of persistence on the target system, allowing the attacker to maintain access even after reboots or credential changes. This can also facilitate lateral movement, enabling the attacker to compromise additional systems within the network. The impact could range from data theft and system disruption to full network compromise. Organizations may experience downtime, data loss, and reputational damage.

Recommendation

Enable “Audit Other Object Access Events” to generate the Windows Security Event Logs required for detection (reference: Setup section in content).
Deploy the provided Sigma rules to your SIEM to detect remote scheduled task creation events (reference: rules section).
Investigate any alerts generated by the Sigma rules to determine the legitimacy of the scheduled task creation.
Review and restrict permissions for creating scheduled tasks, especially from remote sources, to prevent unauthorized task creation.
Monitor the TaskContent value to investigate the configured action of scheduled tasks created remotely (reference: Triage and analysis section in content).

Process Created with a Duplicated Token

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

This detection rule identifies the creation of a process impersonating the token of another user logon session on Windows. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. This technique is used for privilege escalation. The rule flags suspicious process creation by examining token usage patterns, process origins, and recent file modifications, while excluding known legitimate behaviors, to flag potential privilege escalation attempts. The rule is designed for data generated by Elastic Endpoint 8.4+.

Attack Chain

An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using compromised credentials.
The attacker identifies a user logon session with higher privileges than their current session.
The attacker duplicates the token of the identified user logon session using API calls like DuplicateTokenEx.
The attacker uses the duplicated token to create a new process using CreateProcessWithTokenW.
The new process inherits the privileges of the duplicated token.
The attacker executes malicious commands or tools within the context of the newly created process.
The attacker gains elevated privileges on the system, allowing them to perform actions they were previously unauthorized to do.

Impact

Successful exploitation allows an attacker to escalate privileges on the compromised system, potentially gaining administrative or system-level access. This can lead to unauthorized access to sensitive data, installation of malware, lateral movement to other systems on the network, and ultimately, complete control over the affected environment.

Recommendation

Enable Elastic Defend to collect the necessary process creation and event data to activate this rule.
Deploy the Sigma rule Detect Process Created with a Duplicated Token to your SIEM and tune for your environment.
Investigate any alerts generated by the rule, focusing on processes with unusual parent-child relationships or unsigned code.

Print.exe Used to Dump Sensitive Files for Credential Access

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

Attackers are leveraging the Print.exe utility, a legitimate Windows command-line tool, to dump sensitive operating system files for credential harvesting. This technique involves using Print.exe to copy files like ntds.dit, SAM, SECURITY, and SYSTEM from their protected Windows directories. These files contain sensitive credential data that can be extracted offline. This activity was observed in relation to the SolarWinds Web Help Desk exploitation in early 2026. Abuse of Print.exe allows attackers to bypass traditional security measures that focus on blocking known malicious executables. This poses a significant risk because the extracted credentials can be used for lateral movement, privilege escalation, and data exfiltration.

Attack Chain

The attacker gains initial access to a Windows system, potentially through exploitation of a vulnerability in a web application or via compromised credentials.
The attacker executes print.exe with command-line arguments specifying the source file to copy (e.g., \config\SAM, \windows\ntds\ntds.dit) and the destination path. The /D flag is used to designate the destination printer or file.
Print.exe copies the targeted sensitive file (e.g., NTDS.DIT, SAM, SECURITY, SYSTEM) from its protected location.
The copied file is typically saved to a location accessible to the attacker, either locally or on a network share.
The attacker uses credential harvesting tools (e.g., secretsdump.py from Impacket) to extract user credentials (hashes) from the dumped files.
The attacker cracks the password hashes or uses them directly for pass-the-hash attacks.
Using the harvested credentials, the attacker moves laterally to other systems within the network, escalating privileges as needed.
The attacker achieves their final objective, such as data exfiltration, deployment of ransomware, or other malicious activities.

Impact

Successful exploitation allows attackers to steal domain or local account credentials. These stolen credentials enable unauthorized access to sensitive resources, including critical systems and data. The impact can range from data breaches and financial loss to complete compromise of the affected organization’s network. While the scale of past attacks is not stated in the source, similar credential dumping attacks have led to breaches affecting millions of users.

Recommendation

Deploy the Sigma rule Sensitive File Dump Via Print.EXE to detect abuse of Print.exe for copying sensitive files (logsource: process_creation).
Monitor process creation events for the execution of print.exe with command-line parameters that include sensitive file paths such as \config\SAM, \config\SECURITY, \config\SYSTEM, or \windows\ntds\ntds.dit (logsource: process_creation).
Implement access controls to restrict access to sensitive files like ntds.dit, SAM, SECURITY, and SYSTEM to only authorized accounts and processes.
Investigate any instances of print.exe copying files from the \config or \windows\ntds directories.

PowerShell Token Obfuscation via Process Creation

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

Attackers are increasingly using PowerShell token obfuscation techniques to bypass security measures. This involves manipulating PowerShell command syntax to make it harder for security tools to identify malicious code. This technique leverages Invoke-Obfuscation, a known framework for obfuscating PowerShell scripts. This method allows malicious actors to disguise commands, such as downloading and executing arbitrary code, making traditional signature-based detections less effective. The use of token obfuscation highlights the need for more sophisticated detection strategies that focus on identifying anomalous behavior rather than relying solely on static code analysis. The scope of this threat is broad, as it can be incorporated into various attack vectors, from initial access to lateral movement.

Attack Chain

Initial Access: The attacker gains initial access through an undisclosed method (e.g., phishing, exploit).
PowerShell Execution: The attacker initiates a PowerShell process (powershell.exe).
Token Obfuscation: The attacker employs token obfuscation techniques, such as inserting backticks (), using string concatenation, or manipulating environment variables, to disguise malicious commands. Examples from the source include INVoKe-eXpResSIOnand${eNv:pATh}.
Command Obfuscation: The obfuscated PowerShell command is executed, masking the intent of the command.
Payload Download: The obfuscated command may download a malicious payload from a remote server using methods such as (New-Object Net.WebClient).DownloadString.
Code Execution: The downloaded payload is executed, potentially leading to further compromise of the system.
Persistence: The attacker may establish persistence through various methods.
Lateral Movement/Exfiltration: Depending on the attacker’s objectives, they may move laterally within the network or exfiltrate sensitive data.

Impact

Successful exploitation using PowerShell token obfuscation can lead to complete system compromise, data theft, and disruption of services. The obfuscation techniques make it difficult for traditional security tools to detect and prevent the attack. The number of victims and sectors targeted is currently unknown, but the potential impact is significant due to the widespread use of PowerShell in enterprise environments.

Recommendation

Deploy the Sigma rule “Detect Powershell Token Obfuscation with Backticks” to identify PowerShell commands containing backtick-obfuscated tokens in process_creation logs.
Deploy the Sigma rule “Detect Powershell Token Obfuscation with String Concatenation” to identify PowerShell commands using string concatenation to obfuscate tokens in process_creation logs.
Monitor process_creation logs for PowerShell processes executing commands with environment variable manipulation, as described in the Sigma rules provided.
Investigate any PowerShell processes that exhibit obfuscation techniques to determine if they are malicious.

Invoke-Obfuscation Obfuscated IEX Invocation via PowerShell

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

Attackers leverage Invoke-Obfuscation, a popular PowerShell obfuscation framework, to generate highly obfuscated IEX (Invoke-Expression) commands. This technique allows them to bypass traditional signature-based detections and execute malicious payloads on targeted systems. Invoke-Obfuscation is designed to make PowerShell code difficult to read and analyze, thus hindering security analysts and automated detection systems. The obfuscation techniques include string concatenation using environment variables, character code manipulation, and other methods to mask the true intent of the script. This activity has been observed across various campaigns, typically targeting Windows environments where PowerShell is widely used. Defenders should be aware of this technique and implement robust detection mechanisms to identify and block obfuscated PowerShell execution.

Attack Chain

Initial Access: An attacker gains initial access to the target system through methods such as phishing or exploiting a software vulnerability.
Payload Delivery: The attacker uploads a malicious PowerShell script or downloads it from a remote server.
Obfuscation: The attacker uses Invoke-Obfuscation to obfuscate the PowerShell script, making it difficult to analyze. This can involve techniques like string concatenation using $PSHome or $ShellId, or using complex variable manipulations.
Execution: The attacker executes the obfuscated PowerShell script using powershell.exe.
IEX Invocation: The obfuscated script leverages IEX (Invoke-Expression) to dynamically execute code, further hindering detection. The obfuscated strings are deobfuscated at runtime within the IEX context.
Persistence (Optional): The attacker may establish persistence by creating scheduled tasks or modifying registry keys.
Lateral Movement (Optional): The attacker may use the compromised system as a launching point for lateral movement within the network, using tools like PsExec or WinRM.
Objective: The ultimate objective could be data exfiltration, ransomware deployment, or establishing a long-term foothold for espionage.

Impact

Successful exploitation allows attackers to execute arbitrary code on the compromised system, leading to various malicious activities such as data theft, system compromise, and ransomware deployment. The use of Invoke-Obfuscation makes detection more challenging, potentially allowing attackers to remain undetected for extended periods. This can result in significant financial losses, reputational damage, and operational disruption.

Recommendation

Deploy the Sigma rule Invoke-Obfuscation Obfuscated IEX Invocation to your SIEM to detect obfuscated IEX commands generated by Invoke-Obfuscation.
Monitor PowerShell execution logs for suspicious command-line arguments that resemble obfuscation patterns described in the Sigma rule.
Implement PowerShell Constrained Language Mode to restrict the capabilities of PowerShell and limit the effectiveness of obfuscation techniques.
Enable and review PowerShell Script Block Logging to capture the content of executed scripts, allowing for more in-depth analysis of malicious activity.
Regularly update your endpoint detection and response (EDR) solutions to ensure they have the latest signatures and behavioral detection capabilities.
Educate users about the risks of phishing and other social engineering attacks that may be used to deliver malicious PowerShell scripts.

Enumeration of Privileged Local Groups Membership

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

Attackers often perform reconnaissance after compromising a system to plan their next steps. This includes enumerating network resources, users, connections, files, and installed security software. This activity allows attackers to identify high-value targets for lateral movement and credential theft. This detection identifies processes that are unusually enumerating the membership of privileged local groups on Windows systems, such as Administrators or Remote Desktop Users. It is based on Elastic detection rule “Enumeration of Privileged Local Groups Membership” (rule_id: “291a0de9-937a-4189-94c0-3e847c8b13e4”). The rule excludes common legitimate utilities to reduce false positives. The presence of such enumeration activity, especially by unknown or untrusted processes, should be investigated immediately to determine the scope and intent of the intrusion.

Attack Chain

An attacker compromises a Windows host through an initial access vector like phishing or exploitation.
The attacker executes a reconnaissance command or script to gather information about the system.
The command attempts to enumerate the members of privileged local groups, such as Administrators or Remote Desktop Users, using built-in Windows utilities or custom tools.
Windows Security Event Logs record the event of user-member enumeration with Event ID 4798 or similar events.
The attacker parses the output of the enumeration command to identify potential targets for credential theft or privilege escalation.
The attacker uses the gathered information to move laterally to other systems or escalate privileges on the compromised host.
The attacker compromises additional systems and continues to pursue their objectives, such as data exfiltration or ransomware deployment.

Impact

Successful enumeration of privileged local groups allows attackers to identify accounts with elevated privileges on the compromised system. This information is used to target those accounts for credential theft, enabling lateral movement and further compromise of the network. If successful, the attacker gains access to sensitive data, critical systems, or deploys ransomware, causing significant disruption and financial losses.

Recommendation

Enable Audit Security Group Management to generate the necessary Windows Security Event Logs as described in the Elastic setup guide.
Deploy the Sigma rule “Suspicious Enumeration of Privileged Local Groups Membership” to detect unusual processes enumerating group memberships based on CallerProcessName and TargetSid.
Investigate any alerts generated by the Sigma rule, prioritizing those involving unknown or untrusted processes.
Monitor process execution for command-line arguments and tools commonly used for enumeration, such as net.exe, dsquery, or PowerShell scripts.
Implement least privilege principles to minimize the number of accounts with membership in privileged local groups.

Detection of Obfuscated IP Addresses via Command Line Tools

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

Attackers may attempt to obscure their activities by using obfuscated IP addresses within command-line tools. This is done to bypass simple pattern matching or detection rules that rely on standard IP address formats. The Sigma rule “Obfuscated IP Via CLI” published on 2022-08-03 and modified on 2026-03-16, focuses on detecting this behavior by identifying command lines containing hexadecimal, octal, or other encoded representations of IP addresses used with ping.exe or arp.exe. This activity can indicate reconnaissance, command and control communication, or lateral movement attempts where attackers are trying to hide the true destination of their network traffic.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker opens a command prompt (cmd.exe) or PowerShell.
The attacker uses ping.exe or arp.exe to test network connectivity.
The attacker crafts a command line that includes an obfuscated IP address (e.g., hexadecimal, octal). For example: ping 0121.04.0174.012
The command is executed, attempting to resolve or connect to the obfuscated IP address.
If the obfuscation bypasses security controls, the tool resolves the address.
The attacker gathers information about the target system (if ping is successful) or network.
The attacker uses this information for further exploitation or lateral movement.

Impact

Successful exploitation of obfuscated IPs can lead to undetected reconnaissance, lateral movement, and data exfiltration. By hiding the true destination of network traffic, attackers can bypass traditional security measures and gain a foothold within the network. The impact includes potential data breaches, system compromise, and disruption of services.

Recommendation

Deploy the “Obfuscated IP Via CLI” Sigma rule to your SIEM to detect command-line execution with obfuscated IP addresses.
Enable process creation logging for ping.exe and arp.exe to ensure the Sigma rule has the necessary data.
Investigate any alerts generated by the Sigma rule to determine if the activity is malicious.
Implement network segmentation to limit the scope of potential lateral movement.
Monitor command-line activity for unusual patterns or arguments.

Detection of Important Scheduled Task Deletion or Disablement

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

This brief focuses on the detection of malicious activity related to the deletion or disabling of important scheduled tasks within a Windows environment. Adversaries may target these tasks to disrupt normal system operations, escalate privileges, establish persistence, or facilitate data destruction. The targeted tasks often include critical system functions like System Restore, Windows Defender updates, BitLocker encryption, Windows Backup processes, and Windows Update mechanisms. This…

Deletion of Critical Scheduled Tasks

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

Attackers may attempt to delete scheduled tasks to disable security mechanisms or prevent system recovery, creating an environment conducive to data destruction. This involves using the schtasks.exe utility to remove scheduled tasks related to critical system functions. This activity is designed to impair incident response, prevent restoration of systems, and generally increase the impact of an attack. This is done by removing the scheduled tasks, which prevents the execution of security…

Windows Proxy Execution of .NET Utilities via Scripts

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

This threat brief addresses the abuse of trusted Microsoft .NET binaries as proxies for malicious code execution. Attackers leverage script-based execution (e.g., PowerShell, VBScript, batch files) from atypical or user-writable directories to launch .NET utilities like aspnet_compiler.exe, msbuild.exe, regasm.exe, InstallUtil.exe, and vbc.exe. This method allows threat actors to bypass security controls and blend in with legitimate system activity. Observed activity occurs in environments where endpoint detection and response (EDR) agents are deployed. The lack of command-line variation between the utility’s image path and its executed process reinforces the suspicion of proxy execution. This technique has been associated with malware campaigns, including the deployment of VIP Keylogger.

Attack Chain

An attacker gains initial access to the system (potentially through phishing or exploiting a software vulnerability, although this source does not specify the entry vector).
The attacker drops a malicious script (e.g., a PowerShell script) into a user-writable directory such as C:\Users\Public\ or C:\Temp\.
The malicious script executes, and is often obfuscated to evade detection, from the non-standard location.
The script then calls a legitimate .NET utility (e.g., InstallUtil.exe) to execute malicious code.
The .NET utility executes with minimal command-line arguments, often just the executable path itself, to further blend in with legitimate activity.
The .NET utility loads and executes attacker-controlled code, bypassing application control policies.
The malicious code performs actions such as keylogging (as seen with VIP Keylogger), credential theft, or lateral movement.
The attacker achieves their objective, such as data exfiltration or establishing persistent access.

Impact

Successful exploitation enables attackers to bypass application control and execute arbitrary code, potentially leading to data theft, system compromise, and persistent access. While the number of victims and specific sectors are not detailed in this brief’s source, the use of VIP Keylogger as a payload demonstrates the potential for sensitive data exfiltration. Organizations lacking robust endpoint detection capabilities are at significant risk.

Recommendation

Deploy the Sigma rule “Detect .NET Utility Execution from Unusual Script Parents” to identify potential proxy execution attempts based on process relationships and file paths (rule provided below).
Investigate any instances of .NET utilities (aspnet_compiler.exe, msbuild.exe, regasm.exe, InstallUtil.exe, vbc.exe) being launched from user-writable directories, especially when the parent process is a script interpreter (batch, CMD, PowerShell, JScript, VBScript, HTML).
Monitor process creation events (Sysmon EventID 1 or Windows Event Log Security 4688) for unusual parent-child process relationships involving script interpreters and .NET utilities.
Implement application control policies to restrict the execution of .NET utilities from untrusted locations.

Suspicious Outbound Scheduled Task Activity via PowerShell

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

The detection rule identifies suspicious PowerShell activity related to scheduled tasks. Adversaries exploit Task Scheduler to execute malicious scripts, facilitating lateral movement or remote discovery. The rule monitors for the Task Scheduler DLL load within PowerShell processes (powershell.exe, pwsh.exe, powershell_ise.exe) followed by outbound RPC connections, signaling potential misuse. This activity may be indicative of attackers leveraging scheduled tasks for remote execution or reconnaissance within a compromised network. The detection logic focuses on the sequence of loading taskschd.dll and initiating an RPC connection to port 135, a common port for Distributed Component Object Model (DCOM) communication.

Attack Chain

An attacker gains initial access to a Windows system through various means.
The attacker uses PowerShell to interact with the Task Scheduler service.
PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) loads the taskschd.dll library.
The attacker creates or modifies a scheduled task using PowerShell commands.
The scheduled task is configured to execute a malicious payload.
PowerShell initiates an outbound RPC connection on port 135.
The malicious payload executes, potentially leading to lateral movement or remote discovery.
The attacker achieves their objective, such as gaining control of additional systems or gathering sensitive information.

Impact

Successful exploitation can lead to unauthorized remote code execution, lateral movement within the network, and the potential compromise of sensitive data. The creation or modification of scheduled tasks can provide persistence for attackers, allowing them to maintain access to compromised systems even after reboots. The impact includes potential data breaches, system compromise, and disruption of services.

Recommendation

Enable Sysmon Event ID 7 (Image Loaded) and Event ID 3 (Network Connection) logging to detect the specific activity described in the attack chain.
Deploy the Sigma rule “Outbound Scheduled Task Activity via PowerShell” to your SIEM and tune the maxspan value based on your environment’s typical activity patterns.
Investigate any alerts generated by the Sigma rule, focusing on identifying the specific PowerShell commands used and the scheduled tasks created or modified.
Monitor network connections to port 135 originating from PowerShell processes, and correlate with other security events to identify suspicious patterns.
Implement stricter controls on the creation and modification of scheduled tasks, limiting access to authorized personnel only.
Review and clean up any unauthorized scheduled tasks on systems to prevent persistent malicious activity.

Potential Persistence via Time Provider Modification

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

The Windows Time service (W32Time) synchronizes the system clock with other devices on the network, using time providers implemented as DLL files located in the System32 folder. This architecture can be abused by adversaries to establish persistence by registering and enabling a malicious DLL as a time provider. The W32Time service starts during Windows startup and loads w32time.dll. This technique involves modifying specific registry keys associated with the Time Providers, enabling a malicious DLL to be loaded and executed every time the service starts. This can allow an attacker to maintain persistent access to the system, even after a reboot. The Elastic Security team has identified this persistence method and provided a detection rule to identify such modifications.

Attack Chain

The attacker gains initial access to the system through an exploit, phishing, or other means.
The attacker obtains administrator privileges on the target system.
The attacker crafts or deploys a malicious DLL to be used as a time provider.
The attacker modifies the registry to register the malicious DLL as a valid time provider. The registry keys under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\ are targeted.
The attacker enables the newly registered time provider.
The W32Time service is restarted, or the system is rebooted.
The W32Time service loads the malicious DLL, executing the attacker’s code.
The attacker maintains persistent access to the compromised system.

Impact

Successful exploitation allows the attacker to achieve persistence on the compromised system. The attacker can execute arbitrary code every time the W32Time service starts. This may lead to further malicious activities, such as data theft, lateral movement, or the installation of additional malware. The impact is significant, as the attacker can maintain long-term control over the system.

Recommendation

Deploy the Sigma rule Time Provider DLL Registration to detect the registration of new DLL files as Time Providers in the registry.
Enable Sysmon registry event logging to capture registry modifications, as this is a requirement for the provided Sigma rules.
Investigate any registry changes to the HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\ path, especially those adding new DLLs, using the provided Sigma rule.
Monitor process execution for msiexec.exe installing DLLs in the Program Files\VMware\VMware Tools directory, which could indicate legitimate activity, but should still be validated.
Regularly audit and validate the list of registered Time Providers on critical systems.

Potential Application Shimming via Sdbinst

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

Application shimming is a compatibility mechanism in Windows that allows older applications to run on newer operating systems. However, attackers can abuse this functionality to gain persistence and execute arbitrary code in the context of legitimate Windows processes. This is achieved by using the sdbinst.exe utility to install malicious application compatibility databases (.sdb files). These databases can then be used to inject malicious code into targeted applications. The detection rule focuses on identifying suspicious invocations of sdbinst.exe with arguments that do not include benign flags, indicating potential misuse of the application shimming mechanism. This technique is stealthy because it allows attackers to execute code within trusted processes, making it harder to detect.

Attack Chain

The attacker gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The attacker deploys or creates a malicious .sdb file containing code to be injected.
The attacker uses sdbinst.exe to install the malicious .sdb file. The command line arguments often lack common benign flags like “-m”, “-bg”, or “-mm”.
The operating system loads the shim database when the targeted application is launched.
The malicious code within the .sdb file is executed in the context of the targeted application.
The attacker gains persistent access to the system, as the shim is loaded each time the targeted application is executed.
The attacker performs malicious activities, such as data exfiltration, lateral movement, or further exploitation.

Impact

A successful application shimming attack can allow an attacker to maintain persistent access to a compromised system. This can lead to data theft, system compromise, and further malicious activities. Because the malicious code executes within a trusted process, detection can be challenging, and the attacker can potentially bypass security controls. While the number of victims is unknown, this technique is particularly effective against organizations that rely on specific applications, as the attacker can target those applications for persistence.

Recommendation

Deploy the Sigma rule “Potential Application Shimming via Sdbinst” to your SIEM to detect suspicious invocations of sdbinst.exe.
Enable Sysmon process creation logging to capture the command-line arguments of sdbinst.exe executions, which is required for the Sigma rule.
Investigate and remove any unauthorized or suspicious application compatibility databases (.sdb files) found on systems.
Implement enhanced monitoring and logging for sdbinst.exe executions across the network to detect and respond to future attempts at application shimming.
Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained to avoid overlooking genuine threats.

LSASS Loading Suspicious DLL

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component that manages security policies and user authentication. Attackers often target LSASS to dump credentials, using techniques like injecting malicious DLLs. This detection focuses on identifying instances where LSASS loads a DLL that is either unsigned or not signed by a trusted vendor. The rule excludes known legitimate signatures and file hashes to reduce false positives. This activity is a strong indicator of credential access attempts, potentially leading to further compromise of the system and network. The signatures identified in the rule contain well-known software vendors like Microsoft, McAfee and Citrix.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploiting a vulnerability).
The attacker elevates privileges to gain sufficient access to interact with the LSASS process.
The attacker drops a malicious DLL onto the system, often disguised as a legitimate file.
The attacker injects the malicious DLL into the LSASS process using techniques like Reflective DLL Injection.
LSASS loads the injected DLL, granting the attacker access to sensitive credentials stored in memory.
The malicious DLL dumps credentials, such as plaintext passwords or NTLM hashes.
The attacker uses the stolen credentials for lateral movement to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation leads to credential compromise, allowing attackers to move laterally within the network, access sensitive data, and potentially achieve complete domain dominance. This can result in data breaches, financial losses, and reputational damage. The impact depends on the level of access associated with the compromised credentials.

Recommendation

Deploy the LSASS Loading Untrusted DLL Sigma rule to your SIEM to detect suspicious DLLs loaded by LSASS.
Investigate any alerts generated by the Sigma rule and review the loaded DLL’s code signature and hash.
Block the identified SHA256 hashes listed in the IOC table to prevent the execution of known malicious DLLs.
Implement application whitelisting to restrict which DLLs can be loaded into LSASS.
Enable Sysmon process creation and image load logging to provide the necessary data for detection.

Executable or Script Creation in Suspicious Paths

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

This detection identifies the creation of executable or script files in unusual directories on Windows systems. Adversaries often leverage these unconventional locations to evade standard security monitoring and establish persistence. The technique involves placing malicious files with extensions like .exe, .dll, .ps1, and others in directories such as \windows\fonts\, \users\public\, \Windows\debug\, and others deemed atypical for such file types. This activity can bypass traditional signature-based detections and enable the execution of unauthorized code. The scope of this threat covers Windows systems where such file creation events are logged and monitored. This is important for defenders because successful exploitation leads to arbitrary code execution, persistence and further malicious activity within the compromised environment.

Attack Chain

An attacker gains initial access to the system, potentially through exploitation of a vulnerability or compromised credentials.
The attacker navigates to a suspicious directory, such as C:\Windows\Fonts\ or C:\Users\Public\.
The attacker drops a malicious executable file (e.g., evil.exe) or a script (e.g., evil.ps1) into the chosen directory.
The attacker employs techniques to execute the malicious file, such as creating a scheduled task, modifying registry keys, or leveraging other “living off the land” binaries.
The malicious file executes, performing actions such as establishing persistence, escalating privileges, or deploying additional malware.
The attacker leverages the established persistence to maintain access to the compromised system.
The attacker performs lateral movement to other systems within the network, utilizing tools such as PsExec or PowerShell.
The attacker achieves their ultimate objective, such as data exfiltration, system disruption, or ransomware deployment.

Impact

Successful exploitation can lead to the installation of malware, unauthorized access to sensitive data, and complete system compromise. The creation of executables in suspicious paths is a common technique used by various threat actors. Multiple analytic stories are tagged, including PlugX, LockBit Ransomware, and Volt Typhoon. This technique is leveraged to evade detection and maintain a persistent presence on the compromised system.

Recommendation

Enable Sysmon EventID 11 logging to capture file creation events, which is the data source for the analytic.
Deploy the provided Sigma rule to your SIEM to detect the creation of executables or scripts in suspicious paths.
Investigate and validate any alerts generated by the Sigma rule, focusing on the process and user context.
Implement file integrity monitoring (FIM) on critical directories to detect unauthorized file modifications.
Review and harden file system permissions to restrict write access to suspicious directories.

Detecting Remote Scheduled Task Creation for Lateral Movement

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

This detection identifies remote scheduled task creations on a target host, which can be indicative of lateral movement. Adversaries often leverage scheduled tasks to execute malicious commands, maintain persistence, or escalate privileges. This technique is particularly effective as it uses native Windows functionality, making it harder to distinguish from legitimate administrative actions. This rule is designed for data generated by Elastic Defend and also supports third-party data sources such as SentinelOne Cloud Funnel and Sysmon. Understanding when and how scheduled tasks are created remotely is crucial for detecting and responding to potential intrusions. The rule focuses on network connections from svchost.exe and registry modifications related to task actions.

Attack Chain

The attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker uses the compromised system to scan the network for potential targets.
The attacker attempts to authenticate to a target Windows host using stolen credentials or by exploiting a vulnerability in a network service.
The attacker establishes a network connection to the target host’s Task Scheduler service, typically using ports in the dynamic port range (49152+). This connection originates from svchost.exe.
The attacker creates a new scheduled task on the target system using the Task Scheduler service.
This creation involves modifying the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{TaskID}\Actions to define the task’s actions. The ‘Actions’ value is often base64 encoded.
The scheduled task executes a malicious payload, granting the attacker further access or control over the target system.
The attacker uses the newly gained access for lateral movement, data exfiltration, or other malicious objectives.

Impact

Successful exploitation can lead to unauthorized access to sensitive systems, data breaches, and further lateral movement within the network. The rule is designed to catch this activity, reducing the dwell time of attackers and minimizing potential damage.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune for your environment to detect malicious scheduled task creation.
Enable Sysmon Event ID 3 (Network Connection) and Sysmon Registry Events to enhance visibility into network connections and registry modifications (see Setup instructions).
Review the base64 encoded tasks actions registry value to investigate the task configured action (see rule description).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the scheduled task creation and the intent behind the configured action.

Account Password Reset Remotely

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

This detection rule identifies suspicious remote password resets targeting potentially privileged accounts on Windows systems. Attackers may attempt to reset passwords to maintain unauthorized access, evade password duration policies, or preserve compromised credentials. The rule focuses on network logins followed by password reset actions, specifically targeting privileged accounts to reduce false positives. The rule leverages Windows Security Event Logs to detect successful network logins and subsequent password reset events. The goal is to detect anomalous password reset activities that could indicate malicious activity. The rule was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to the network (e.g., through credential theft or phishing).
The attacker attempts a network login to a Windows system, generating a 4624 event with logon type “Network”.
The system logs a successful authentication event (event ID 4624) with a network logon type.
The attacker identifies a privileged account, such as an administrator account or a service account with elevated permissions.
The attacker initiates a password reset for the privileged account.
A password reset event (event ID 4724) is triggered, indicating that a password has been reset.
The attacker leverages the reset password to maintain persistent access to the compromised account.
The attacker performs malicious actions using the compromised privileged account, potentially leading to data exfiltration or system compromise.

Impact

Successful password resets of privileged accounts can lead to significant security breaches. Attackers can maintain persistent access, escalate privileges, and move laterally within the network. This can result in data theft, system compromise, and disruption of services. If successful, attackers can potentially gain control over critical systems and data, leading to significant financial and reputational damage.

Recommendation

Enable the Windows audit policies for “Audit Logon” and “Audit User Account Management” to generate the necessary events for this detection.
Deploy the Sigma rule “Detect Remote Password Reset of Privileged Account” to your SIEM and tune it to your environment, excluding legitimate administrative accounts and processes.
Investigate any alerts generated by the Sigma rule by reviewing the source IP address and the target account to determine if the password reset was authorized.
Monitor for Event ID 4724 (Account Password Reset) in conjunction with network login events to identify suspicious password reset activity.
Review and update access controls and privileged account management policies to prevent similar incidents in the future, as mentioned in the overview section.
Create exceptions for known IT personnel or service accounts that legitimately perform remote password resets, as detailed in the false positive analysis section.

Suspicious CSC.exe Parent Process

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

Attackers are leveraging the legitimate Csc.exe (C# compiler) to execute malicious code, often as a part of defense evasion or payload delivery. This is achieved by spawning Csc.exe from unusual parent processes such as scripting hosts (cscript.exe, wscript.exe), Office applications (excel.exe, winword.exe), or PowerShell, especially when combined with encoded commands. Observed techniques also include launching Csc.exe from temporary or unusual directories. This activity bypasses traditional application whitelisting and can lead to the execution of arbitrary code. This activity has been associated with WarzoneRAT, DarkVNC, and the delivery of IMAPLoader malware.

Attack Chain

An attacker gains initial access, potentially through phishing or exploiting a vulnerability.
A script or Office macro executes, initiating a command-line process.
This process then invokes a scripting host (e.g., cscript.exe) or PowerShell.
The scripting host or PowerShell executes a command that downloads or creates a C# source code file.
Csc.exe is then invoked, often from a temporary directory, to compile the downloaded/created C# code.
The compiled C# code executes, performing malicious actions.
The malicious code may establish persistence, communicate with a C2 server, or perform data exfiltration.
The final objective might be to deploy ransomware, steal sensitive data, or establish a persistent backdoor.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise systems, steal data, or deploy malware. Depending on the user’s permissions, the attacker could gain elevated privileges. The observed techniques have been associated with ransomware deployment, data theft, and remote access trojans (RATs).

Recommendation

Deploy the Sigma rule “Csc.EXE Execution Form Potentially Suspicious Parent” to detect suspicious parent processes of csc.exe.
Monitor process creation events for csc.exe with parent processes like scripting hosts or Office applications.
Investigate any instances of csc.exe being executed from temporary directories or user profile locations by reviewing process_creation logs.
Enable Sysmon process creation logging to capture detailed process information, including parent-child relationships, for effective detection.

Suspicious Script Execution from Temporary Directory

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

This detection identifies suspicious script executions originating from temporary directories. Threat actors often leverage temporary folders to stage and execute malicious scripts, such as PowerShell, VBScript, or even HTML applications (MSHTA) to evade detection or bypass security controls. These scripts can be delivered through various means, including phishing attacks, drive-by downloads, or as part of a multi-stage malware infection. The execution of scripts from temporary directories is generally uncommon for legitimate software, making it a valuable indicator of potentially malicious activity. This detection focuses on identifying processes like powershell.exe, pwsh.exe, mshta.exe, wscript.exe, and cscript.exe executing from or referencing standard temporary paths in their command line.

Attack Chain

A malicious script (e.g., PowerShell, VBScript) is downloaded or dropped into a temporary directory such as C:\Windows\Temp, \AppData\Local\Temp, or similar.
The attacker uses a process like cmd.exe or powershell.exe to invoke the downloaded script.
The script executes, potentially performing reconnaissance, privilege escalation, or lateral movement.
The script may download additional payloads from a remote server.
The script establishes persistence through registry modification or scheduled tasks.
The script performs malicious actions such as data exfiltration or ransomware deployment.
The attacker attempts to remove the initial script files to cover their tracks.

Impact

Successful exploitation can lead to a range of consequences, including data theft, system compromise, and ransomware infection. The execution of malicious scripts from temporary directories can provide attackers with a foothold in the network, allowing them to move laterally, escalate privileges, and ultimately achieve their objectives. Depending on the script’s capabilities, it could also lead to system instability or denial of service.

Recommendation

Deploy the Sigma rule “Suspicious Script Execution From Temp Folder” to your SIEM to detect script execution from temporary directories. Tune the rule’s filters for known-good software installers in your environment to reduce false positives.
Enable process creation logging with command line arguments to capture the necessary information for the Sigma rule (logsource: process_creation).
Investigate any alerts generated by the Sigma rule, focusing on the parent process and the script’s actions.
Implement application control policies to restrict the execution of scripts from temporary directories where possible.

Windows Delayed Execution via Ping Followed by Malicious Utilities

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

Attackers may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. This delayed execution is often observed during malware installation and is consistent with an attacker attempting to evade detection. The adversary uses ping.exe with the -n argument from within a cmd.exe shell, and the parent process is running under a user context other than SYSTEM. The subsequent process is cmd.exe invoking a known malicious utility, such as powershell.exe, mshta.exe, rundll32.exe, or an executable from the user’s AppData directory without a valid code signature. This behavior is often observed during malware installation.

Attack Chain

The attack begins with an initial access vector (not specified in source).
The adversary executes cmd.exe.
cmd.exe spawns ping.exe with the -n argument to introduce a delay, typically to evade detection (ping.exe -n [number] 127.0.0.1).
After the delay introduced by ping.exe, the same cmd.exe process executes a potentially malicious utility such as powershell.exe, mshta.exe, rundll32.exe, certutil.exe, or regsvr32.exe.
Alternatively, cmd.exe might execute a binary located within the user’s AppData directory that lacks a valid code signature.
The malicious utility executes arbitrary commands or scripts, potentially downloading further payloads or modifying system configurations.
The attacker gains a foothold on the system, enabling further malicious activities such as lateral movement or data exfiltration.

Impact

A successful attack can lead to malware installation, system compromise, and data theft. While the source does not quantify the number of victims or specific sectors targeted, a successful compromise can lead to significant operational disruption and data breaches. The use of delayed execution makes it more difficult for traditional security solutions to detect malicious activity.

Recommendation

Deploy the Sigma rule “Delayed Execution via Ping” to your SIEM to detect the execution of commonly abused Windows utilities via a delayed Ping execution.
Enable process monitoring with command-line argument logging to capture the execution of ping.exe and subsequent processes for analysis.
Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the rule.
Review and tune the provided Sigma rule, including the listed exclusions, to reduce false positives in your specific environment.
Monitor process execution from unusual locations like the AppData directory, especially for unsigned executables, as indicated in the rule’s detection logic.

WScript or CScript Dropper

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

The WScript or CScript Dropper technique is a method employed by attackers to introduce malicious script files into a system. It leverages the built-in Windows scripting hosts, cscript.exe and wscript.exe, to write files with extensions commonly associated with scripting languages (e.g., .js, .vbs, .wsf). These scripts are often written to temporary or user-accessible directories, such as \Temp\, \AppData\, or \Startup\, where they can be executed later, either manually or…

Windows Temporarily Scheduled Task Creation and Deletion

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

This detection focuses on identifying the creation and subsequent deletion of scheduled tasks within a short timeframe on Windows systems. Attackers may abuse the scheduled task functionality to execute malicious code, establish persistence, or perform other unauthorized actions. By quickly deleting the task after execution, they attempt to evade detection and remove traces of their activity. This behavior is often associated with attackers trying to proxy malicious execution via the schedule service and then cleaning up to avoid leaving forensic artifacts. The detection logic looks for the sequence of task creation followed by deletion within a five-minute window. This activity is captured via Windows Security Event Logs when the “Audit Other Object Access Events” setting is enabled.

Attack Chain

An attacker gains initial access to the target system. (T1053.005)
The attacker uses legitimate Windows utilities like schtasks.exe or PowerShell cmdlets to create a new scheduled task.
The scheduled task is configured to execute a malicious payload, such as a script or executable. The payload could be staged on disk or downloaded from a remote server.
The scheduled task executes the malicious payload, achieving the attacker’s objective (e.g., establishing persistence, executing commands, or deploying malware).
The attacker, or the malicious payload itself, uses schtasks.exe or PowerShell to delete the scheduled task.
The deletion occurs within a short time (less than 5 minutes) after task creation to minimize the window for detection.
The attacker may also delete associated log files or other artifacts to further cover their tracks.
The attacker achieves their objective, such as maintaining persistence, escalating privileges, or exfiltrating data.

Impact

Successful exploitation can lead to persistent access, arbitrary code execution, privilege escalation, and data compromise. While the specific impact varies depending on the attacker’s objectives, the ability to execute code via scheduled tasks provides a significant foothold within the compromised system. This can lead to lateral movement, data exfiltration, or further compromise of the network.

Recommendation

Enable “Audit Other Object Access Events” in Windows Security Event Logs to generate the necessary events for detection.
Deploy the Sigma rule “Temporarily Scheduled Task Creation” to your SIEM to detect rapid task creation and deletion.
Investigate any alerts generated by the Sigma rule to determine if the activity is legitimate or malicious.
Monitor scheduled task creation events for unusual task names, command-line arguments, or user accounts.
Implement application control policies to restrict the execution of unauthorized executables and scripts.

Windows Scheduled Task Creation for Persistence

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

Adversaries frequently leverage scheduled tasks in Windows to maintain persistence, elevate privileges, or facilitate lateral movement within a compromised network. This technique involves creating or modifying scheduled tasks to execute malicious code at specific times or intervals. The detection rule focuses on identifying the creation of new scheduled tasks logged in Windows event logs, filtering out tasks created by system accounts and those associated with legitimate software to minimize false positives. This detection is crucial because successful exploitation allows attackers to execute arbitrary commands or programs on a recurring basis, maintaining a foothold even after system reboots or user logoffs. Defenders need to monitor for anomalous task creation events to identify potential malicious activity. The rule references Microsoft Event ID 4698 as a key data source for detecting scheduled task creation.

Attack Chain

Initial Access: An attacker gains initial access to the system through phishing, exploiting a vulnerability, or using compromised credentials.
Privilege Escalation (if needed): The attacker escalates privileges using exploits or by abusing misconfigurations to gain the necessary permissions to create scheduled tasks.
Task Creation: The attacker creates a new scheduled task using tools like schtasks.exe or PowerShell.
Configuration: The attacker configures the task to execute a malicious script or program at a specific time or event trigger.
Persistence: The scheduled task is configured to run at regular intervals or upon system startup, ensuring persistent access to the compromised system.
Execution: When the scheduled task triggers, the malicious payload executes, performing actions such as installing malware, stealing data, or establishing a command and control connection.
Lateral Movement (optional): The attacker uses the compromised system and scheduled task to move laterally to other systems on the network, repeating the task creation process.

Impact

Successful exploitation via scheduled task creation can lead to persistent access within the compromised environment. The attacker can maintain a foothold even after system restarts, enabling them to perform data exfiltration, deploy ransomware, or cause other disruptive activities. While the risk score is relatively low, the potential for persistence makes this a critical area to monitor, especially in environments where lateral movement is a significant concern. The number of affected systems depends on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

Enable “Audit Other Object Access Events” to generate the necessary Windows Security Event Logs for detecting scheduled task creation (reference: setup instructions in the original rule).
Deploy the provided Sigma rules to your SIEM to detect suspicious scheduled task creation events, and tune the rules by adding exclusions for known benign tasks in your environment.
Review the investigation steps outlined in the rule’s notes to triage alerts related to scheduled task creation, focusing on unfamiliar task names, unusual user accounts, and suspicious scheduled actions.
Use the references URL to understand the specific details of Windows Event ID 4698, which is generated when a scheduled task is created.

Suspicious Remote Registry Access via SeBackupPrivilege

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

This detection identifies suspicious activity related to credential access on Windows systems. Specifically, it focuses on scenarios where an account with the SeBackupPrivilege (typically associated with the Backup Operators group) remotely accesses the Windows Registry. Attackers can leverage this privilege to bypass access controls and dump the Security Account Manager (SAM) registry hive, which stores password hashes. This activity often precedes credential access and privilege escalation attempts, where the attacker aims to extract sensitive information from the dumped SAM hive to gain unauthorized access to other systems or elevate their privileges within the network. The detection logic looks for a sequence of events: first, a special logon event indicating the use of SeBackupPrivilege, followed by a network share access event targeting the “winreg” share.

Attack Chain

Initial Access: The attacker gains initial access to a system, potentially through phishing, exploiting a vulnerability, or using stolen credentials.
Privilege Escalation: The attacker attempts to escalate privileges on the compromised system. If the initial access does not grant SeBackupPrivilege, they may exploit vulnerabilities or misconfigurations to gain membership in the Backup Operators group or otherwise acquire the necessary privilege.
Special Logon: The attacker logs in using an account with the SeBackupPrivilege. This triggers a “logged-in-special” event (Event ID 4672) with the SeBackupPrivilege listed.
Remote Registry Access: The attacker uses remote administration tools or scripts to access the registry of a target system remotely, specifically targeting the “winreg” share. This triggers a file share access event (Event ID 5145).
SAM Hive Dump: The attacker uses the SeBackupPrivilege to bypass access controls and copies the SAM registry hive (or portions thereof) to a location accessible to them.
Credential Extraction: The attacker extracts password hashes from the dumped SAM hive using tools like Mimikatz or other offline password cracking utilities.
Lateral Movement: The attacker uses the extracted credentials to move laterally to other systems within the network, gaining access to additional resources and expanding their foothold.
Goal Completion: The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful exploitation can lead to the compromise of domain credentials and widespread lateral movement within the network. This could enable attackers to access sensitive data, disrupt critical services, or deploy ransomware, resulting in significant financial losses and reputational damage. Given the sensitivity of the SAM hive, even a single successful compromise can have far-reaching consequences. The impact is especially high in environments with a large number of systems sharing the same domain, as the attacker can potentially compromise a significant portion of the infrastructure.

Recommendation

Enable both “Audit Detailed File Share” and “Audit Special Logon” Windows audit policies to generate the necessary events for detection, as mentioned in the setup section of the original rule.
Deploy the provided Sigma rules to your SIEM to detect suspicious remote registry access attempts utilizing SeBackupPrivilege, and tune them for your environment.
Review and restrict the use of SeBackupPrivilege to only those accounts that absolutely require it for legitimate backup operations, minimizing the potential attack surface.
Investigate any alerts generated by these detections promptly to determine the scope of the compromise and take appropriate remediation steps.
Monitor for Event ID 5145 with RelativeTargetName containing “winreg” along with Event ID 4672 with SeBackupPrivilege to identify potential credential access attempts (see the original rule’s query field).

Suspicious Microsoft HTML Application Child Process

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

Mshta.exe (Microsoft HTML Application Host) is a Windows utility used to execute HTML Applications (.hta files). Adversaries often abuse Mshta to execute malicious scripts and evade detection, as it is a signed Microsoft binary and can bypass application whitelisting. This activity typically involves Mshta spawning other processes like cmd.exe or powershell.exe to perform malicious actions. This behavior has been observed across various attack campaigns and is a common tactic used to deliver payloads, establish persistence, or perform lateral movement within a network. Defenders need to monitor Mshta.exe process creations and child processes to detect and prevent potential threats. The detection logic focuses on identifying specific child processes commonly associated with malicious activities, while excluding legitimate uses of Mshta, such as those related to HP printer software.

Attack Chain

An attacker gains initial access via an unspecified method (e.g., phishing, drive-by download) that delivers a malicious HTA file.
The user executes the HTA file, which launches Mshta.exe to interpret and execute the embedded script.
The script within the HTA file spawns a suspicious child process, such as cmd.exe or powershell.exe, using CreateProcess.
The spawned process executes malicious commands or scripts to download additional payloads or perform reconnaissance.
Certutil.exe may be used to decode encoded payloads.
The attacker may use bitsadmin.exe to download files from remote servers.
PowerShell is used to execute malicious code directly in memory, bypassing file-based detections.
The attacker achieves their objective, such as establishing persistence, stealing credentials, or deploying ransomware.

Impact

Successful exploitation can lead to a range of consequences, including malware infection, data theft, and system compromise. The impact can vary depending on the attacker’s objectives, but it can result in significant financial losses, reputational damage, and disruption of business operations. While specific numbers of victims are not listed, this technique is widely used and can affect any organization that does not adequately monitor and restrict the use of Mshta.exe. The sectors targeted are broad, as this is a general-purpose technique applicable to various environments.

Recommendation

Enable process creation logging and monitor for Mshta.exe spawning suspicious child processes to enable the “Suspicious Microsoft HTML Application Child Process” rule.
Implement the provided Sigma rule to detect Mshta.exe spawning cmd.exe, powershell.exe, certutil.exe, bitsadmin.exe, curl.exe, msiexec.exe, schtasks.exe, reg.exe, wscript.exe, or rundll32.exe to detect potential defense evasion.
Examine process.command_line and process.parent.command_line for suspicious arguments and file paths to further investigate potential malicious use of Mshta.
Monitor for executables running from user directories using the Sigma rule provided to identify potentially malicious processes spawned by Mshta.exe.
Investigate the parent process of Mshta.exe to determine the initial source of the HTA execution, focusing on browsers, email clients, and other potential delivery mechanisms.
Tune the provided Sigma rules for your environment to reduce false positives and ensure accurate detection of malicious activity.

Potential Masquerading as Svchost

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

Attackers may attempt to evade detection by masquerading as legitimate system processes, specifically svchost.exe. The svchost.exe process is a critical component of the Windows operating system, responsible for hosting multiple Windows services. By naming a malicious executable svchost.exe and placing it in a non-standard directory, attackers aim to blend in with normal system activity and bypass security controls that rely on process names or paths. This technique is particularly effective because svchost.exe is a common and trusted process, making it less likely to be scrutinized by users or security software. This detection focuses on identifying processes named svchost.exe that are not running from the legitimate Windows system directories.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker uploads a malicious executable disguised as svchost.exe to a non-standard directory, such as C:\Users\Public\.
The attacker executes the malicious svchost.exe process from the non-standard location.
The masquerading process attempts to mimic legitimate svchost.exe behavior to avoid suspicion.
The malicious svchost.exe process may establish network connections to external command-and-control servers.
The process may execute malicious payloads, such as downloading additional malware or performing lateral movement.
The attacker leverages the compromised system to access sensitive data or perform other malicious activities.
The attacker attempts to maintain persistence on the system to ensure continued access.

Impact

A successful masquerading attack can lead to undetected execution of malicious code, allowing attackers to compromise systems, steal data, or establish persistent access. Because the malicious process is disguised as a legitimate system component, it may evade detection by traditional security measures. This can result in significant damage to the affected organization, including data breaches, financial loss, and reputational damage.

Recommendation

Enable process creation logging with command line details to capture the execution of processes, including their names and paths.
Deploy the Sigma rule “Potential Svchost Masquerading” to detect svchost.exe processes running from non-standard locations.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the svchost.exe process and its activities.
Implement file integrity monitoring to detect unauthorized modifications to system files, including the svchost.exe executable in the system directories.
Use application control lists (ACLs) to restrict the execution of executables from non-standard directories.

Potential Credential Access via Renamed COM+ Services DLL

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

This detection identifies a suspicious technique where an attacker renames the COMSVCS.DLL, a legitimate Windows component, and then loads it using rundll32.exe. COMSVCS.DLL contains the MiniDumpWriteDump function, which can be used to create a memory dump of a running process. Attackers abuse this technique to dump the LSASS process memory, where credentials are often stored, while attempting to bypass traditional command-line monitoring that might detect direct use of MiniDumpWriteDump. The renaming of the DLL is a defense evasion tactic to avoid detection based on the DLL’s original name. This activity is a strong indicator of potential credential access and requires immediate investigation. The rule specifically looks for renamed COMSVCS.DLL with a matching original filename or imphash being loaded by rundll32.exe.

Attack Chain

Attacker gains initial access to the system, potentially through phishing or exploitation of a vulnerability.
The attacker copies the legitimate COMSVCS.DLL to a new location on the disk, often a temporary directory.
The attacker renames the copied COMSVCS.DLL to an arbitrary name to evade detection.
The attacker uses rundll32.exe to load the renamed COMSVCS.DLL.
The rundll32.exe process executes the MiniDumpWriteDump function exported by the renamed COMSVCS.DLL.
The MiniDumpWriteDump function targets the LSASS process, creating a memory dump file.
The attacker retrieves the LSASS memory dump file.
The attacker uses credential extraction tools to obtain credentials from the dumped LSASS memory.

Impact

Successful execution of this attack chain can lead to the compromise of sensitive credentials stored in LSASS memory, including domain administrator accounts. This allows the attacker to move laterally within the network, gain access to critical systems, and potentially exfiltrate sensitive data or deploy ransomware. The impact is high due to the potential for widespread compromise and data breach.

Recommendation

Enable Sysmon image load logging (Event ID 7) to detect the loading of DLLs, which is essential for this detection.
Deploy the “Potential Credential Access via Renamed COM+ Services DLL” Sigma rule to your SIEM to identify instances of renamed COMSVCS.DLL being loaded by rundll32.exe.
Monitor for rundll32.exe processes loading DLLs from unusual locations, as this could indicate malicious activity.
Investigate any alerts generated by the Sigma rule, focusing on the process that loaded the renamed DLL and any subsequent activity.
Use the IOC (MD5 hash of COMSVCS.DLL imphash: EADBCCBB324829ACB5F2BBE87E5549A8) to search for instances of COMSVCS.DLL copies on your systems.
Enforce strict access control policies to prevent unauthorized users from copying and renaming system DLLs.

Potential Credential Access via MSBuild Loading Credential Management DLLs

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

This detection rule identifies potential credential access attempts leveraging the Microsoft Build Engine (MSBuild). Attackers may abuse MSBuild, a legitimate developer tool, to load malicious DLLs related to Windows credential management, such as vaultcli.dll or SAMLib.dll. This technique enables credential dumping by a trusted Windows utility, making it harder to detect. The rule focuses on detecting the loading of these specific DLLs by MSBuild processes. The rule relies on data from Elastic Defend and Sysmon logs.

Attack Chain

Attacker gains initial access to the target system (e.g., via phishing or exploiting a vulnerability).
Attacker places a malicious .csproj file or a DLL designed to load credential management DLLs on the system.
The attacker executes MSBuild.exe to process the malicious project file.
MSBuild.exe loads the attacker-controlled DLL.
The attacker-controlled DLL loads either vaultcli.dll or SAMLib.dll.
The loaded DLLs are used to dump credentials from the system.
The attacker accesses the dumped credentials.
The attacker uses the compromised credentials for lateral movement or data exfiltration.

Impact

A successful attack can lead to the compromise of sensitive credentials stored on the affected system. This can allow attackers to move laterally within the network, access confidential data, and potentially compromise entire domains. The impact ranges from data breaches to complete system compromise, depending on the privileges of the compromised accounts.

Recommendation

Deploy the Sigma rule MSBuild Loads Credential Management DLL to your SIEM, tuned for your specific environment, to detect instances of MSBuild loading vaultcli.dll or SAMLib.dll.
Enable Sysmon event ID 7 (Image Loaded) logging with the appropriate configurations to capture DLL loading events.
Investigate any instances of MSBuild loading vaultcli.dll or SAMLib.dll from unusual or unexpected locations using the guidance in the rule note.

Msiexec Arbitrary DLL Execution

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

Msiexec.exe is the command-line utility for the Windows Installer, commonly used to execute installation packages (.msi). Attackers are known to abuse msiexec.exe to proxy the execution of arbitrary DLLs, a technique that helps bypass application control and evade detection. This approach leverages the trusted nature of msiexec.exe to execute malicious code, making it harder for security tools to identify and block the activity. The abuse of msiexec.exe has been observed in various attack campaigns, highlighting the need for defenders to monitor its usage closely.

Attack Chain

An attacker gains initial access to the target system, often through phishing or exploitation of a vulnerability.
The attacker uploads a malicious DLL to the compromised system.
The attacker uses msiexec.exe with the /Y flag to execute the malicious DLL. This flag is used to trigger DLL execution via msiexec.
Msiexec.exe loads and executes the malicious DLL.
The malicious DLL performs its intended actions, such as establishing persistence, escalating privileges, or deploying additional malware.
The attacker may use the proxy execution through msiexec.exe to evade detection by security tools monitoring process execution.
The attacker pivots to other systems or begins data exfiltration.
The ultimate objective is often data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation allows attackers to execute arbitrary code on the targeted system, potentially leading to a full system compromise. This can result in data breaches, financial loss, and reputational damage. The technique is particularly effective at bypassing application control solutions, increasing the likelihood of a successful attack. While specific victim counts are unavailable, the widespread use of Windows Installer makes this a relevant threat across various sectors.

Recommendation

Deploy the Sigma rule Suspicious Msiexec Execute Arbitrary DLL to your SIEM to detect the execution of msiexec.exe with the /Y flag, indicative of potential malicious DLL execution.
Investigate any instances of msiexec.exe executing DLLs from unusual or temporary locations.
Implement application control policies to restrict the execution of msiexec.exe to authorized users and legitimate installation processes.
Monitor process creation events for msiexec.exe to identify suspicious command-line arguments and parent processes.

Modification of WDigest Security Provider

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

The WDigest security provider is a legacy authentication protocol that, when enabled, stores user passwords in cleartext within LSASS memory. Modern Windows versions (8.1+ and Server 2012 R2+) disable this behavior by default. Attackers can modify the UseLogonCredential registry value under the WDigest configuration to re-enable plaintext credential caching. This manipulation is a common precursor to credential dumping attacks, where tools like Mimikatz are used to extract sensitive information from LSASS. Defenders should monitor for unauthorized modifications to the WDigest configuration to prevent credential theft. The rule provided by Elastic aims to detect these modifications.

Attack Chain

An attacker gains initial access to a Windows system via compromised credentials or exploiting a vulnerability (e.g., phishing or RDP).
The attacker executes code (e.g., PowerShell script or executable) with sufficient privileges to modify the registry.
The malicious code modifies the UseLogonCredential registry value under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest or a similar path.
The attacker sets the UseLogonCredential value to 1 (or 0x00000001), enabling plaintext storage of credentials.
A user logs on to the system, causing their credentials to be stored in cleartext in LSASS memory.
The attacker uses credential dumping tools like Mimikatz to extract the cleartext passwords from LSASS.
The attacker uses the stolen credentials for lateral movement or to access sensitive data.

Impact

Successful modification of the WDigest security provider can lead to widespread credential compromise. Attackers can harvest credentials for privileged accounts, enabling them to move laterally within the network, access sensitive resources, and potentially achieve domain dominance. This can result in data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule “Modification of WDigest Security Provider” to your SIEM to detect malicious registry modifications (rule d703a5af-d5b0-43bd-8ddb-7a5d500b7da5).
Enable Sysmon registry event logging to capture the necessary data for the provided Sigma rule to function.
Monitor process creation events for unexpected processes modifying registry keys related to WDigest.
Review and restrict access control lists (ACLs) on the WDigest registry keys to prevent unauthorized modifications.
Investigate any alerts generated by the Sigma rule, focusing on the process that made the modification, the user context, and any subsequent activity.

LSASS Memory Dump Handle Access Detection

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows process responsible for enforcing security policy and handling user authentication. Attackers often target LSASS to steal credentials for lateral movement and privilege escalation. This detection identifies attempts to access LSASS memory using specific access masks (0x1fffff, 0x1010, 0x120089, 0x1F3FFF) that are commonly used by tools designed to dump LSASS memory. The rule is designed to be tool-agnostic, detecting the underlying behavior rather than specific tool signatures. It has been validated against various LSASS dumping tools, including SharpDump, Procdump, Mimikatz, and Comsvcs. The rule triggers on Windows systems where handle manipulation is enabled and generates security event logs.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker elevates privileges to an administrative account or SYSTEM, necessary for accessing LSASS memory.
The attacker executes a credential dumping tool, such as Mimikatz, SharpDump, or Procdump.
The tool attempts to open a handle to the LSASS process (lsass.exe) with a specific access mask (0x1fffff, 0x1010, 0x120089, 0x1F3FFF) required for memory dumping.
Windows Security Event ID 4656 is generated, logging the handle request to the LSASS object.
The tool reads the memory contents of the LSASS process.
The dumped memory is parsed to extract sensitive information, such as passwords, NTLM hashes, and Kerberos tickets.
The attacker uses the stolen credentials to move laterally to other systems or access sensitive data.

Impact

Successful LSASS memory dumping allows attackers to steal user credentials, enabling lateral movement and privilege escalation within the network. This can lead to widespread compromise, data breaches, and significant disruption of services. Stolen credentials can be used to access sensitive data, control critical systems, and maintain a persistent presence within the environment.

Recommendation

Enable Audit Handle Manipulation to generate the necessary events for this rule to function, as described in the setup instructions.
Deploy the Sigma rule LSASS Memory Dump Handle Access to your SIEM and tune the exceptions based on your environment to minimize false positives.
Investigate any alerts generated by this rule, focusing on the process execution chain (parent process tree) to identify the source of the LSASS handle request.
Review the processes excluded in the rule (WmiPrvSE.exe, dllhost.exe, svchost.exe, msiexec.exe, explorer.exe) and ensure these exclusions are valid for your environment.
Implement strong password policies and multi-factor authentication to mitigate the impact of credential theft.

Windows Privilege Escalation via Secondary Logon Service

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

The Secondary Logon service in Windows allows users to run processes with different credentials, which can be abused to escalate privileges and bypass access controls. This technique involves an adversary successfully authenticating via the seclogon service, typically from the local host, then spawning a new process under the context of this newly acquired, potentially elevated, token. The detection focuses on identifying successful seclogon authentications where the source IP is the loopback address (::1), tied to subsequent process creations sharing the same logon ID. This is a common method for local privilege escalation.

Attack Chain

An attacker gains initial access to a Windows system through various means.
The attacker attempts to leverage the Secondary Logon service (seclogon) to create a new process with elevated privileges.
A successful logon event is generated, with the LogonProcessName indicating “seclogo*” and source IP address of “::1”, and event ID indicating a successful login.
svchost.exe is used as the process responsible for calling seclogon.
The system assigns a TargetLogonId to the new logon session.
The attacker creates a new process, specifying the TargetLogonId obtained from the previous step.
The new process is launched with the security context of the alternate credentials, potentially granting the attacker elevated privileges.
The attacker performs malicious actions using the newly elevated privileges, such as accessing sensitive data or installing malware.

Impact

Successful exploitation allows attackers to perform actions with elevated privileges, potentially leading to complete system compromise. An attacker can bypass access controls and gain unauthorized access to sensitive resources. If successful, this can lead to data theft, system compromise, or the installation of persistent backdoors.

Recommendation

Enable Audit Logon to generate the events required for the rules in this brief (reference: Setup section in the source).
Deploy the “Process Creation via Secondary Logon” Sigma rule to your SIEM and tune for your environment to detect potential privilege escalation attempts (reference: Sigma rules below).
Monitor for svchost.exe processes initiating secondary logon events from the local loopback address (::1) as an indicator of local privilege escalation.

PowerShell Obfuscation via Backtick-Escaped Variable Expansion

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

This rule detects PowerShell scripts employing backtick-escaped characters within ${} variable expansion, a technique used to reconstruct strings at runtime. Attackers leverage variable-expansion obfuscation to split keywords, conceal commands, and bypass static analysis and AMSI (Antimalware Scan Interface). This obfuscation method involves inserting multiple backticks between word characters inside ${} blocks. Detecting this behavior is crucial as it signifies attempts to evade security measures and potentially execute malicious code on compromised systems. The rule focuses on identifying scripts with a length exceeding 500 characters to minimize false positives and targets PowerShell event code 4104.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a software vulnerability.
The attacker uploads or creates a PowerShell script on the target system.
The PowerShell script employs backtick-escaped variable expansion (e.g., $env:use``r``na``me) to obfuscate its contents.
The obfuscated script is executed using powershell.exe.
The script dynamically reconstructs commands and strings by evaluating the backtick-escaped variables.
The reconstructed commands perform malicious activities, such as downloading additional payloads or modifying system configurations.
The script attempts to evade detection by AMSI and other security tools.
The attacker achieves persistence and control over the compromised system, potentially leading to data exfiltration or further lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, system compromise, and data theft. While the number of victims is unknown, PowerShell is a common attack vector on Windows environments. The sectors most affected are organizations relying on Windows infrastructure without adequate PowerShell monitoring and security controls. Failure to detect and prevent this technique allows attackers to bypass security measures and gain unauthorized access to sensitive data.

Recommendation

Enable PowerShell Script Block Logging to generate event code 4104. (Reference: Setup section)
Deploy the Sigma rule Detect PowerShell Backtick Variable Obfuscation to identify scripts using backtick-escaped variable expansion.
Investigate any alerts generated by the Sigma rule, focusing on scripts with a high Esql.script_block_pattern_count value.
Monitor for process creation events where powershell.exe executes obfuscated commands as detected by the Sigma rule Detect Suspicious PowerShell Encoded Commands.
Review PowerShell logs for event code 4104 and examine powershell.file.script_block_text for suspicious patterns.