Execution — CraftedSignal Threat Feed

Kubernetes Pod Exec Sensitive File or Credential Path Access

hello@craftedsignal.io — Mon, 04 May 2026 21:42:34 +0000

This detection identifies Kubernetes pod exec sessions accessing sensitive files or credential paths. The goal is to detect attackers attempting to steal credentials or configuration information from within Kubernetes pods. This often occurs after initial access and may precede lateral movement, privilege escalation, or data exfiltration. The detection focuses on command lines that reference paths related to service account tokens, kubelet configuration, host identity stores, common private keys, keystore extensions, process environment dumps, and configuration files with embedded secrets. The rule is designed to catch both interactive and scripted access, and includes exclusions for benign reads of resolv.conf.

Attack Chain

Attacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.
Attacker uses kubectl exec or similar tools to execute commands within a pod.
The executed command attempts to read sensitive files or directories within the pod’s filesystem, such as /var/run/secrets/kubernetes.io/serviceaccount/token to obtain the pod’s service account token.
The command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like /etc/shadow or /etc/passwd for credential access.
The attacker may attempt to dump process environments via /proc//environ to extract sensitive information stored as environment variables.
The attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.
The attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.
The final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.

Impact

A successful attack can lead to the compromise of sensitive data, including credentials, configuration files, and application secrets. This can enable attackers to move laterally within the Kubernetes cluster, escalate privileges, and potentially gain control over the entire environment. The severity of the impact depends on the sensitivity of the data exposed and the level of access achieved by the attacker.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.
Investigate any alerts triggered by the Sigma rule, focusing on the Esql.access_type field to prioritize incidents.
Review and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.
Implement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.
Monitor Kubernetes audit logs for suspicious kubectl exec activity, including unusual command lines or access patterns.
Regularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.
Use the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.

Potential Direct Kubelet API Access via Process Arguments

hello@craftedsignal.io — Mon, 04 May 2026 21:18:23 +0000

This detection identifies potential direct Kubelet API access attempts on Linux systems. The Kubelet, acting as the primary node agent, exposes an API accessible via ports 10250 and 10255. Attackers may exploit this API to enumerate pods, fetch logs, or even attempt remote execution. This access can lead to significant breaches in Kubernetes environments, facilitating discovery, lateral movement, and ultimately, compromise of sensitive data or control over cluster resources. The detection focuses on identifying process executions where the command-line arguments contain URLs targeting these Kubelet ports, indicating a potential attempt to interact with the Kubelet API directly.

Attack Chain

An attacker gains initial access to a compromised host within the Kubernetes cluster or a host with network access to the Kubelet ports.
The attacker uses a utility like curl, wget, python, or similar tools to craft an HTTP request targeting the Kubelet API on ports 10250 or 10255.
The request includes a path like /pods, /runningpods, /metrics, /exec, or /containerLogs to gather information about the cluster’s state and configuration.
The attacker examines the response to identify potential targets for lateral movement, such as specific pods or containers of interest.
The attacker attempts to execute commands within a container using the /exec endpoint, potentially leveraging exposed service account tokens or other credentials.
The attacker uses gathered information to move laterally to other pods or nodes within the cluster, escalating privileges as they go.
The attacker compromises sensitive data or critical applications running within the Kubernetes cluster.

Impact

Successful exploitation can lead to full cluster compromise. Attackers can gain unauthorized access to sensitive data, disrupt critical applications, and move laterally to other resources within the Kubernetes environment. This could lead to significant financial losses, reputational damage, and legal liabilities. The potential impact includes data breaches, denial of service, and complete control over the Kubernetes infrastructure.

Recommendation

Deploy the Sigma rule Kubelet API Access via Process Arguments to your SIEM to detect suspicious process executions.
Restrict access to Kubelet ports 10250/10255 at the network layer to limit pod-to-node or host-to-node traffic as recommended in the overview section.
Harden Kubelet configuration by disabling anonymous authentication and enforcing webhook authentication/authorization as described in the overview section.

Suspicious Zoom Child Process Execution

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Windows PowerShell Arguments Detected

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

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

Attack Chain

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

Impact

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

Recommendation

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

Potential DLL Side-Loading via Trusted Microsoft Programs

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

This detection rule identifies instances of Windows trusted programs such as WinWord.exe, EXPLORER.EXE, w3wp.exe, and DISM.EXE executing from unusual paths or after being renamed, which may indicate DLL side-loading. DLL side-loading is a defense evasion technique where a malicious DLL is placed in the same directory as a legitimate executable. When the executable runs, it may load the malicious DLL instead of the legitimate one, allowing the attacker to execute arbitrary code within the context of the trusted process. The detection logic focuses on process executions that deviate from standard installation paths. The targeted processes are commonly used and often whitelisted, making this a potent technique for adversaries to bypass security controls.

Attack Chain

The attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).
The attacker identifies a trusted Windows program vulnerable to DLL side-loading (WinWord.exe, EXPLORER.EXE, w3wp.exe, or DISM.EXE).
The attacker drops a malicious DLL into a directory where the trusted program is expected to load DLLs from, often alongside a renamed or copied version of the legitimate executable.
Alternatively, the attacker renames the trusted program and places it in a non-standard path.
The attacker executes the renamed or moved trusted program from the non-standard path.
The trusted program loads the malicious DLL due to DLL search order hijacking.
The malicious DLL executes arbitrary code within the context of the trusted process.
The attacker achieves persistence, elevates privileges, or performs other malicious activities, potentially evading detection due to the trusted process context.

Impact

A successful DLL side-loading attack allows the attacker to execute arbitrary code within the context of a trusted Microsoft process. This can lead to privilege escalation, persistence, and further compromise of the system. Since the malicious code is running within a trusted process, it can bypass application whitelisting and other security controls, making it difficult to detect. This can lead to data theft, system disruption, or the installation of malware.

Recommendation

Deploy the Sigma rule “Potential DLL Side-Loading via Trusted Microsoft Programs” to your SIEM to detect suspicious executions of trusted programs from non-standard paths or with modifications.
Enable Sysmon process creation logging (Event ID 1) to provide the necessary data for the Sigma rule to function correctly.
Review and tune the exclusion paths in the Sigma rule to avoid false positives from legitimate software updates, custom enterprise applications, or virtual environments.
Monitor process execution paths using the Sigma rule “Potential DLL Side-Loading via Trusted Microsoft Programs” and investigate any deviations from standard installation paths.

Command Shell Activity Started via RunDLL32

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

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

Attack Chain

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

Impact

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

Recommendation

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

AWS SSM Session Manager Child Process Execution Abuse

hello@craftedsignal.io — Fri, 01 May 2026 20:57:28 +0000

AWS Systems Manager (SSM) Session Manager provides interactive shell access to EC2 instances and hybrid nodes without the need for bastion hosts or open inbound ports. Attackers can abuse this functionality by leveraging compromised AWS credentials or IAM roles with ssm:StartSession permissions to gain unauthorized access to target systems. This allows for remote execution of commands and lateral movement within the AWS environment. The technique involves spawning child processes from the SSM session worker process to perform malicious activities. Defenders should monitor for unusual process execution patterns originating from SSM sessions to identify potential abuse.

Attack Chain

Attacker gains access to valid AWS credentials or IAM role with ssm:StartSession permissions.
Attacker initiates an SSM session to a target EC2 instance or hybrid node using the compromised credentials.
The ssm-session-worker process is started on the target instance to manage the interactive session.
Attacker executes commands within the session, spawning child processes from the ssm-session-worker process.
Attacker may use scripting languages such as PowerShell or Bash to execute malicious code (e.g., using awsrunPowerShellScript or awsrunShellScript).
These scripts perform reconnaissance, download additional tools, or attempt credential access.
Attacker moves laterally to other instances or resources within the AWS environment.
The ultimate objective is often data exfiltration, privilege escalation, or maintaining persistent access.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, compromise of critical systems, and lateral movement within the AWS environment. The impact can range from data breaches to complete control of the compromised infrastructure. The number of affected systems depends on the scope of the compromised credentials and the attacker’s ability to move laterally. Organizations using AWS SSM are at risk.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious child processes spawned by ssm-session-worker.
Correlate process activity with AWS CloudTrail logs for StartSession and related API calls to identify the IAM principal initiating the session (see the overview section for API names).
Implement strict IAM policies and regularly review AWS credentials to minimize the risk of credential compromise.
Monitor process.command_line, process.executable, process.user.name for unusual activity within SSM sessions.

Multiple Vulnerabilities in CUPS

hello@craftedsignal.io — Thu, 30 Apr 2026 09:43:58 +0000

Multiple vulnerabilities have been identified in CUPS, a popular open-source printing system. These vulnerabilities can be exploited by an attacker to bypass security measures, execute arbitrary code, escalate privileges, manipulate data, or cause a denial-of-service (DoS) condition. The specifics of the vulnerabilities are not detailed in the source document, but the potential impact suggests a high level of risk. Defenders should monitor CUPS deployments for suspicious activity.

Attack Chain

Attacker gains initial access to a system with a vulnerable CUPS installation.
The attacker exploits a vulnerability in CUPS (specific CVE not identified) to bypass authentication or authorization controls.
Leveraging the bypassed security measures, the attacker executes arbitrary code within the context of the CUPS service.
The attacker escalates privileges, potentially gaining root or system-level access, due to insecure configurations or further vulnerabilities within CUPS.
With elevated privileges, the attacker manipulates sensitive data related to print jobs, configurations, or user information.
Alternatively, the attacker triggers a denial-of-service condition, rendering the printing service unavailable by exploiting a resource exhaustion vulnerability.
The attacker leverages the compromised CUPS service as a pivot point to gain access to other systems on the network.
The final objective is to compromise sensitive data, disrupt printing services, or gain a foothold for further attacks within the network.

Impact

Successful exploitation of these CUPS vulnerabilities could lead to significant damage, including unauthorized access to sensitive documents, disruption of critical printing services, and potential compromise of other systems on the network. The lack of specific victim numbers or sector targeting in the source document suggests this is a general advisory.

Recommendation

Monitor CUPS server logs for unexpected process execution and privilege escalation attempts (enable process_creation logging and deploy the “Detect Suspicious CUPS Process Execution” Sigma rule).
Inspect CUPS configuration files for unauthorized modifications that could indicate malicious activity (enable file_event logging and deploy the “Detect Suspicious CUPS Configuration Modification” Sigma rule).
Analyze network traffic to and from CUPS servers for anomalous patterns that may indicate exploitation attempts or data exfiltration (enable network_connection logging).

Multiple Vulnerabilities in Red Hat Linux Kernel

hello@craftedsignal.io — Thu, 30 Apr 2026 00:00:00 +0000

On April 30, 2026, CERT-FR published an advisory regarding multiple vulnerabilities in the Red Hat Linux kernel. These vulnerabilities, detailed in Red Hat Security Advisories RHSA-2026:10756, RHSA-2026:10996, and RHSA-2026:11313, can lead to significant security risks including arbitrary code execution, privilege escalation, and remote denial of service. The affected systems include various versions and architectures of Red Hat CodeReady Linux Builder and Red Hat Enterprise Linux. Successful exploitation of these vulnerabilities could allow attackers to gain unauthorized access, control systems, or disrupt services, impacting the confidentiality, integrity, and availability of affected systems.

Attack Chain

Initial Compromise (via unconfirmed vector): An attacker identifies a vulnerable Red Hat Linux system running an affected kernel version. While the exact exploit vector isn’t specified in the advisory, it involves a vulnerability in the kernel.
Exploit Trigger: The attacker triggers a specific kernel vulnerability, such as those identified as CVE-2026-23001 or CVE-2026-31402, by sending a crafted input to a vulnerable kernel component. The specific method depends on the nature of each CVE.
Code Execution: Upon successful exploitation, the attacker achieves arbitrary code execution within the kernel context. This allows the attacker to run malicious code directly on the system.
Privilege Escalation: Leveraging the code execution capability, the attacker exploits another vulnerability (e.g., CVE-2025-68741) to escalate privileges to root or SYSTEM. This may involve exploiting race conditions, memory corruption bugs, or other privilege escalation flaws within the kernel.
System Control: With elevated privileges, the attacker gains full control over the compromised system. They can now access sensitive data, modify system configurations, install backdoors, or move laterally to other systems within the network.
Lateral Movement (Optional): The attacker uses the compromised system as a launching point to attack other systems on the network, potentially exploiting other vulnerabilities or using stolen credentials.
Persistence (Optional): The attacker establishes persistence on the compromised system to maintain access even after reboots. This may involve installing rootkits, modifying system startup scripts, or creating rogue user accounts.
Denial of Service/Data Exfiltration/etc.: Depending on their objectives, the attacker may use the compromised system to launch denial-of-service attacks against other targets, exfiltrate sensitive data, or cause other damage.

Impact

Successful exploitation of these kernel vulnerabilities can lead to complete system compromise, allowing attackers to execute arbitrary code, escalate privileges, and cause denial of service. The wide range of affected Red Hat Enterprise Linux and CodeReady Linux Builder versions implies a potentially large number of vulnerable systems. This can result in significant data breaches, system downtime, financial losses, and reputational damage for affected organizations.

Recommendation

Apply the patches provided in Red Hat Security Advisories RHSA-2026:10756, RHSA-2026:10996, and RHSA-2026:11313 to remediate the vulnerabilities.
Prioritize patching systems based on their criticality and exposure to external networks.
Monitor systems for suspicious activity that may indicate exploitation attempts, focusing on unexpected kernel module loads or privilege escalations using process_creation logging.
Deploy the Sigma rule detecting suspicious kernel module loading to identify potential rootkit installation attempts.
Investigate any alerts generated by the deployed Sigma rules to determine the scope and impact of potential compromises.

OpenClaw StrictInlineEval Approval Bypass Vulnerability (CVE-2026-42423)

hello@craftedsignal.io — Wed, 29 Apr 2026 12:00:00 +0000

OpenClaw, a software application, is vulnerable to an approval-timeout bypass (CVE-2026-42423) affecting versions prior to 2026.4.8. This vulnerability stems from a flaw in the strictInlineEval approval mechanism, where an approval-timeout fallback allows the execution of inline eval commands without explicit user approval. An attacker with low privileges can exploit this vulnerability on gateway and node exec hosts to circumvent the intended security boundary. This can lead to unauthorized command execution and potential system compromise. Defenders should upgrade to version 2026.4.8 or implement mitigations to prevent exploitation.

Attack Chain

Attacker gains low-privilege access to a gateway or node exec host running a vulnerable version of OpenClaw (prior to 2026.4.8).
The attacker crafts a malicious inline eval command intended to be executed on the system.
The attacker attempts to execute the malicious inline eval command, triggering the strictInlineEval approval mechanism.
The system initiates the explicit approval process, awaiting user confirmation before executing the command.
The attacker waits for the pre-configured approval-timeout to expire without providing any explicit approval.
The approval-timeout fallback mechanism is triggered due to the lack of user approval within the defined timeframe.
The system bypasses the explicit-approval requirement due to the timeout fallback, and the malicious inline eval command is executed.
The attacker achieves arbitrary command execution on the affected host, potentially escalating privileges and compromising the system.

Impact

Successful exploitation of CVE-2026-42423 allows an attacker to bypass intended security boundaries and execute arbitrary commands on OpenClaw gateway and node exec hosts. This can lead to privilege escalation, unauthorized data access, and potential system compromise. The severity is rated as high (CVSS 7.5) due to the potential for significant impact on confidentiality, integrity, and availability. The number of affected systems depends on the deployment scope of vulnerable OpenClaw versions.

Recommendation

Upgrade OpenClaw to version 2026.4.8 or later to patch CVE-2026-42423.
Monitor OpenClaw logs for indicators of unauthorized inline eval command execution, focusing on unexpected activity following approval timeouts.
Implement network segmentation to limit the blast radius of potential compromises, should an attacker successfully exploit CVE-2026-42423 and gain unauthorized access.

Bad Apples: Weaponizing Native macOS Primitives for Lateral Movement and Execution

hello@craftedsignal.io — Tue, 21 Apr 2026 10:01:16 +0000

With macOS adoption growing in enterprise environments, particularly among developers and DevOps teams, it has become an attractive target for malicious actors. This report highlights the under-documented “living-off-the-land” (LOTL) techniques specific to macOS. Attackers are exploiting native features like Remote Application Scripting (RAS) to achieve remote execution and are abusing Spotlight metadata (Finder comments) for payload staging, evading traditional static file analysis. Additionally, attackers can use built-in protocols such as SMB, Netcat, Git, TFTP, and SNMP to establish persistence and move toolkits. Defenders should shift their focus from static file scanning to monitoring process lineage, inter-process communication (IPC) anomalies, and enforcing strict MDM policies to disable unnecessary administrative services.

Attack Chain

Initial Access: The attacker gains initial access to a macOS system, possibly through spearphishing or exploiting a vulnerability in a network service (details of initial access aren’t specified in the provided document but is a necessary assumption for the rest of the chain).
Discovery: The attacker uses native tools to enumerate the environment, such as diskutil list to identify connected volumes.
Credential Access: The attacker attempts to access stored credentials, SSH keys, or cloud credentials.
Lateral Movement (RAS): The attacker leverages Remote Application Scripting (RAS) to remotely query Finder for mounted volumes using osascript -e 'tell application "Finder" to get the name of every disk' eppc://user:password@target_ip.
Remote Execution (RAS): The attacker uses RAS and Terminal.app as an execution proxy to bypass Apple’s security restrictions.
Payload Deployment (RAS/Base64): The attacker encodes a malicious script using Base64 and uses RAS to instruct the remote Terminal.app to decode the script to a temporary file and make it executable using chmod +x.
Payload Invocation (RAS/bash): The attacker uses a second RAS command to explicitly invoke the deployed script via bash, ensuring a proper shell context.
Persistence (SMB/Netcat/Git/TFTP/SNMP): The attacker utilizes built-in protocols such as SMB, Netcat, Git, TFTP, or SNMP to establish persistence on the compromised system.

Impact

Successful exploitation of these LOTL techniques allows attackers to bypass traditional security controls on macOS systems, leading to unauthorized access to sensitive data, source code repositories, and cloud infrastructure. With over 45% of organizations utilizing macOS, these attacks can result in significant financial losses, reputational damage, and disruption of business operations. Compromised developer or DevOps workstations can be leveraged as pivot points to further compromise production environments.

Recommendation

Monitor process creation events for osascript executing with the eppc:// URI to detect potential RAS-based lateral movement (see Sigma rule “Detect Remote Apple Event Lateral Movement”).
Monitor process creation for Terminal.app executing bash with command-line arguments indicative of Base64 decoding and execution to identify RAS-based remote execution attempts (see Sigma rule “Detect Terminal.app as Execution Proxy”).
Implement strict MDM policies to disable unnecessary administrative services and protocols like Remote Apple Events to reduce the attack surface.
Monitor inter-process communication (IPC) anomalies, particularly involving AppleEventsD, to identify suspicious activity related to RAS.
Enable Sysmon process-creation logging to capture the process lineage and command-line arguments necessary for the rules above.

CVE-2026-32157 - Remote Desktop Client Use-After-Free Vulnerability

hello@craftedsignal.io — Wed, 15 Apr 2026 12:00:00 +0000

CVE-2026-32157 is a critical use-after-free vulnerability affecting the Remote Desktop Client. This flaw allows an unauthenticated attacker to achieve remote code execution on a vulnerable system simply by interacting with the RDP service over a network. The vulnerability stems from improper memory management within the RDP client, leading to a condition where a program attempts to access memory that has already been freed, potentially resulting in arbitrary code execution. Successful exploitation of this vulnerability could lead to complete system compromise. The CVE was published on 2026-04-14, and defenders should prioritize patching and monitoring for exploitation attempts.

Attack Chain

Attacker identifies a vulnerable Remote Desktop Client via network scanning or other reconnaissance methods.
Attacker crafts a malicious RDP request designed to trigger the use-after-free vulnerability.
The crafted RDP request is sent to the target system via TCP port 3389 (default RDP port).
The Remote Desktop Client on the target system processes the malicious request, triggering the memory corruption.
The use-after-free condition allows the attacker to overwrite memory, potentially injecting malicious code.
The injected code is executed within the context of the Remote Desktop Client process (mstsc.exe).
The attacker gains control of the system, potentially escalating privileges to SYSTEM.
The attacker can then install malware, exfiltrate data, or perform other malicious actions.

Impact

Successful exploitation of CVE-2026-32157 can lead to complete compromise of the affected system. An attacker could gain unauthorized access to sensitive data, install malware, or use the compromised system as a foothold to pivot to other systems on the network. Given the ubiquitous nature of RDP in enterprise environments, a successful widespread exploitation could have significant impact across various sectors.

Recommendation

Apply the patch released by Microsoft to address CVE-2026-32157 immediately on all systems running Remote Desktop Client. The advisory URL is https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32157.
Deploy the Sigma rules provided in this brief to your SIEM to detect potential exploitation attempts targeting CVE-2026-32157.
Monitor network traffic for suspicious RDP connections and unusual activity originating from the mstsc.exe process based on the network_connection and process_creation Sigma rules.
Enable process creation logging to capture the execution of any malicious code injected via this vulnerability, as covered by the process_creation Sigma rule.

AWS SSM Command Document Created by Rare User

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This rule identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. The rule focuses on detecting anomalous creation of SSM command documents. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, and data exfiltration. The rule utilizes AWS CloudTrail logs to monitor the CreateDocument API call within the SSM service. This activity is flagged when the user or role creating the document deviates from established patterns, indicating a potential security risk. This detection is relevant for organizations using AWS SSM for managing their infrastructure and aims to prevent unauthorized command execution on managed instances.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role.
The attacker attempts to create a new SSM Command document using the CreateDocument API call.
The CreateDocument API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.
The detection rule analyzes CloudTrail logs, specifically looking for the CreateDocument event with a document type of Command.
The rule identifies the user or role associated with the CreateDocument API call by inspecting the aws.cloudtrail.user_identity.arn field.
If the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.
The attacker could then use the created document to execute arbitrary commands on managed instances.
Successful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.

Impact

The successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.

Recommendation

Deploy the Sigma rule “AWS SSM Command Document Created by Rare User” to your SIEM, ensuring proper indexing of CloudTrail logs (index = [“filebeat-*”, “logs-aws.cloudtrail-*”]).
Review the aws.cloudtrail.request_parameters.content field in the CloudTrail logs for any suspicious commands within the created SSM document.
Restrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.
Monitor the SendCommand API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.

AWS EC2 LOLBin Execution via SSM SendCommand

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This threat brief focuses on detecting the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on Amazon EC2 instances via AWS Systems Manager (SSM) SendCommand API. The technique involves correlating AWS CloudTrail SendCommand events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. This is critical because adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access. They can leverage legitimate system utilities for various malicious purposes, including data exfiltration, establishing reverse shells, or facilitating lateral movement within the cloud environment. The rule was last updated on 2026-04-10.

Attack Chain

An attacker gains initial access to AWS via compromised credentials or an exposed IAM role.
The attacker uses the AWS CLI or API to initiate an SSM SendCommand to a target EC2 instance. The DocumentName parameter is set to AWS-RunShellScript.
The SSM agent on the EC2 instance receives the SendCommand request.
The SSM agent executes a shell script (_script.sh) within a dedicated directory for orchestration.
The shell script executes a LOLBin, such as curl, wget, python, or perl, to perform malicious actions. The parent process of the LOLBin will be the SSM shell script.
The LOLBin is used to download a malicious payload, establish a reverse shell, or exfiltrate data.
The attacker uses the established reverse shell to perform further actions on the EC2 instance.

Impact

Successful exploitation can lead to unauthorized access to EC2 instances, data exfiltration, deployment of malware, and lateral movement within the AWS environment. Although a number of impacted organizations is not available, this attack is able to bypass traditional network security controls. Organizations in any sector utilizing AWS EC2 instances and SSM are potentially at risk. The lack of required SSH or RDP access makes this technique particularly stealthy.

Recommendation

Enable AWS CloudTrail logging to capture SendCommand events and monitor for AWS-RunShellScript in the request_parameters.
Deploy the Sigma rule “Detect AWS EC2 LOLBin Execution via SSM SendCommand” to your SIEM and tune for your environment.
Monitor endpoint process execution logs for the execution of LOLBins like curl, wget, python, perl, nc, etc., with parent processes related to SSM.
Implement strict IAM policies to restrict SSM SendCommand permissions to only authorized users and roles.
Review and audit existing SSM configurations to identify and remediate any overly permissive settings.

OpenClaw Agent Suspicious Child Process Execution

hello@craftedsignal.io — Wed, 08 Apr 2026 12:07:54 +0000

OpenClaw (formerly Clawdbot, rebranded to Moltbot) is an AI coding assistant that can execute shell commands and scripts. Threat actors are exploiting the skill ecosystem (ClawHub) to distribute malicious skills, observed as early as January 2026, that execute download-and-execute commands, targeting cryptocurrency wallets and credentials. These skills are often obfuscated and distributed through public registries like ClawHub. The attacks leverage the AI agents’ ability to execute commands through skills or prompt injection. Defenders should monitor for suspicious child processes spawned by Node.js processes running OpenClaw/Moltbot, as these may indicate malicious activity originating from compromised or malicious skills. This activity has been observed across Linux, macOS, and Windows environments.

Attack Chain

A user installs the OpenClaw agent, potentially from a legitimate or typosquatted domain.
The user installs a malicious skill from ClawHub or is subject to a prompt injection attack.
The OpenClaw agent, running under Node.js, receives a command to execute a shell command.
The Node.js process spawns a shell process (e.g., bash, sh, cmd.exe, powershell.exe).
The shell process executes a command to download a payload from a remote server using tools like curl or certutil.
The downloaded payload is saved to disk, often with an obfuscated name.
The shell process executes the downloaded payload using chmod +x and ./, rundll32.exe, or powershell.exe.
The payload performs malicious actions such as credential theft or cryptocurrency wallet compromise.

Impact

Compromised OpenClaw agents can lead to cryptocurrency wallet theft, credential compromise, and potential data exfiltration. A successful attack allows threat actors to gain access to sensitive data and potentially pivot to other systems on the network. The number of victims is currently unknown, but the targeting of cryptocurrency wallets suggests financially motivated actors. The observed typosquatting activity indicates a campaign to impersonate the legitimate software and trick users into installing malicious versions.

Recommendation

Monitor process creation events for suspicious child processes of Node.js processes running OpenClaw/Moltbot, specifically shells and scripting interpreters, using the provided Sigma rule (Execution via OpenClaw Agent - Linux/macOS/Windows).
Block known typosquat domains (moltbot.you, clawbot.ai, clawdbot.you) at the DNS resolver based on the IOCs provided.
Implement application control policies to restrict the execution of unsigned or untrusted executables, mitigating the impact of downloaded payloads.
Review OpenClaw skill installation logs and user AI conversation history for signs of malicious activity or prompt injection attempts.
Enable process command-line auditing to capture the full command line of spawned processes, aiding in the identification of malicious commands.
Deploy the Sigma rule to detect execution of curl/certutil downloads (OpenClaw Download Activity).

JetAudio jetCast Server 2.0 Stack-Based Buffer Overflow

hello@craftedsignal.io — Tue, 24 Mar 2026 12:00:00 +0000

JetAudio jetCast Server 2.0 is susceptible to a stack-based buffer overflow vulnerability (CVE-2019-25609) within the Log Directory configuration field. This flaw allows a local attacker with access to the server’s configuration settings to overwrite Structured Exception Handling (SEH) pointers. By injecting carefully crafted, alphanumeric-encoded shellcode into the Log Directory field, an attacker can trigger an SEH exception handler. This ultimately leads to the execution of arbitrary code under the privileges of the application. The vulnerability poses a significant risk to systems running the vulnerable software, as it enables local privilege escalation and potentially complete system compromise.

Attack Chain

Attacker gains local access to a system running JetAudio jetCast Server 2.0.
Attacker identifies the Log Directory configuration setting within JetCast Server 2.0.
The attacker crafts alphanumeric shellcode designed to overwrite the SEH chain.
The attacker injects the malicious shellcode into the Log Directory configuration field, exceeding the expected buffer size.
The application attempts to handle the oversized input, causing a stack-based buffer overflow.
The overflow corrupts the SEH chain, replacing legitimate handler addresses with attacker-controlled addresses.
An exception is triggered within the application due to the corrupted state.
The SEH handler is invoked, redirecting execution to the attacker’s shellcode, resulting in arbitrary code execution with application privileges.

Impact

Successful exploitation of this vulnerability allows a local attacker to execute arbitrary code with the privileges of the JetAudio jetCast Server application. Given the base CVSS score of 8.4, this could lead to complete system compromise, including data theft, modification, or destruction. While the number of affected installations is unknown, organizations utilizing JetAudio jetCast Server 2.0 are at risk.

Recommendation

Apply available patches or upgrade to a secure version of JetAudio jetCast Server to remediate CVE-2019-25609.
Monitor process creation events for unusual processes spawned by the JetAudio jetCast Server process (see process creation rule below).
Implement access controls to restrict who can modify the Log Directory configuration, mitigating the initial access vector.
Monitor network connections originating from the JetAudio jetCast Server process to detect potential command and control activity after successful exploitation (see network connection rule below).

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…

Linux Shell Invocation via Env Command

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

The ’env’ command in Linux is typically used to run a program in a modified environment without altering the existing environment variables. However, attackers can abuse this command to invoke a shell directly, potentially bypassing restricted environments. This is often a technique used for privilege escalation or executing arbitrary commands in situations where direct shell access is limited. This activity matters for defenders because it can indicate an attacker attempting to gain…

Unsigned DLL Loaded by DNS Service

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

The detection rule identifies the loading of unusual DLLs by the Windows DNS Server process (dns.exe), potentially indicating the abuse of the ServerLevelPluginDll functionality, as described in public research and proof-of-concept code. This technique allows attackers to load arbitrary DLLs into the DNS service, leading to privilege escalation and remote code execution with SYSTEM privileges. The rule focuses on detecting unsigned or untrusted DLLs loaded by dns.exe, highlighting potential exploitation attempts and unauthorized modifications to the DNS service. Successful exploitation grants the attacker elevated privileges, allowing them to perform malicious actions on the system. The rule is designed for data generated by Elastic Defend and supports Sysmon Event ID 7 (Image Loaded) as an additional data source.

Attack Chain

An attacker gains initial access to the system through unspecified means.
The attacker modifies the DNS Server configuration to enable the loading of server-level plugin DLLs.
The attacker places a malicious, unsigned DLL in a location accessible to the DNS service.
The DNS service (dns.exe) loads the malicious DLL upon startup or configuration change.
The malicious DLL executes code within the context of the DNS service, inheriting SYSTEM privileges.
The attacker uses the elevated privileges to perform malicious actions, such as installing backdoors or modifying system settings.
The attacker maintains persistence by ensuring the malicious DLL is loaded on subsequent system restarts.

Impact

Successful exploitation allows attackers to execute arbitrary code with SYSTEM privileges, granting them complete control over the compromised system. This can lead to data theft, system corruption, or the installation of persistent backdoors. The impact includes potential privilege escalation, remote code execution, and complete system compromise.

Recommendation

Deploy the Sigma rule “Unsigned DLL loaded by DNS Service” to your SIEM and tune for your environment.
Ensure Sysmon Event ID 7 (Image Loaded) is enabled to provide the necessary data for the detection rule.
Investigate any alerts generated by the Sigma rule by reviewing the DLL file path and code signature status.
Regularly review and validate the DNS server configuration to ensure that only trusted DLLs are loaded.
Implement code signing policies to prevent the loading of unsigned DLLs.

Microsoft Management Console File Execution from Unusual Path

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious ScreenConnect Client Child Process Activity

hello@craftedsignal.io — Thu, 16 May 2024 16:10:00 +0000

This threat brief focuses on the detection of suspicious activities related to the ScreenConnect remote access tool. ScreenConnect is a legitimate remote support software, but adversaries can exploit it to execute unauthorized commands on compromised systems. This detection identifies suspicious child processes spawned by ScreenConnect client processes, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, which can indicate malicious activities such as spawning PowerShell or cmd.exe with unusual arguments. This activity can indicate potential abuse of remote access capabilities, leading to data exfiltration, command and control communication, or the establishment of persistence mechanisms. Recent exploitation of CVE-2024-1709 and CVE-2024-1708 have highlighted the risk associated with ScreenConnect exploitation.

Attack Chain

The attacker gains unauthorized access to a system with ScreenConnect installed. This could be achieved through exploiting vulnerabilities like CVE-2024-1709 and CVE-2024-1708, or through credential compromise.
The attacker uses ScreenConnect to connect to the compromised system remotely.
The attacker uses the ScreenConnect interface to execute commands on the remote system.
The attacker spawns a command interpreter, such as cmd.exe, using ScreenConnect. This process is a child process of the ScreenConnect client process.
The attacker uses cmd.exe to execute malicious commands, such as downloading and executing a malicious payload.
Alternatively, the attacker spawns powershell.exe with encoded commands or commands to download and execute malicious payloads from a remote server.
The attacker establishes persistence by creating a scheduled task using schtasks.exe or creates a new service using sc.exe.
The attacker uses tools like net.exe to modify user accounts or privileges to maintain access to the compromised system.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, installation of malware, and establishment of persistent access to the compromised system. This can result in data theft, disruption of services, and further lateral movement within the network. The number of victims and specific sectors targeted varies depending on the attacker’s objectives, but the impact can be significant for organizations relying on ScreenConnect for remote support.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious child processes spawned by ScreenConnect and tune for your environment.
Monitor process creation events for ScreenConnect client processes spawning suspicious child processes like powershell.exe, cmd.exe, net.exe, schtasks.exe, sc.exe, rundll32.exe, mshta.exe, certutil.exe, wscript.exe, cscript.exe, curl.exe, ssh.exe, scp.exe, wevtutil.exe, wget.exe, or wmic.exe as detailed in the Sigma rules.
Enable Sysmon process-creation logging to capture the necessary process execution data to activate the rules above.
Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe as described in the attack chain.

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

Remote File Download via Script Interpreter

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

Attackers commonly use Windows Script Host (WSH) scripts as an initial access method or to download tools and utilities. This involves using built-in Windows script interpreters like cscript.exe or wscript.exe to download executable files from remote destinations. This behavior is significant because it allows attackers to bypass traditional defenses and establish a foothold in the system or download further tools. Defenders should monitor for suspicious network connections initiated by script interpreters followed by the creation of executable files on the system.

Attack Chain

An attacker gains initial access to a Windows system (delivery mechanism not specified in source).
The attacker executes a script using cscript.exe or wscript.exe.
The script interpreter makes an outbound network connection to a remote server.
The remote server hosts a malicious executable file (e.g., .exe, .dll).
The script downloads the malicious executable to the compromised system.
The downloaded file is saved to disk.
The attacker executes the downloaded malicious file to establish persistence or further compromise the system.
The attacker performs additional actions, such as lateral movement or data exfiltration (not detailed in the source).

Impact

Successful exploitation can lead to the installation of malware, unauthorized access to sensitive data, and further compromise of the affected system. This can result in data breaches, financial losses, and reputational damage. The source does not contain specific victim numbers or sectors targeted.

Recommendation

Deploy the Sigma rule “Remote File Download via Script Interpreter - File Creation” to your SIEM to detect the creation of executable files after network activity from cscript.exe or wscript.exe.
Deploy the Sigma rule “Remote File Download via Script Interpreter - Network Connection” to detect network connections from cscript.exe or wscript.exe.
Enable Sysmon Event ID 3 (Network Connection) and Event ID 11 (File Create) for enhanced visibility into network and file activity related to script interpreters.

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.

Unusual Executable File Creation by a System Critical Process

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

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

Attack Chain

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

Impact

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

Recommendation

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

Windows Script Execution from Archive File

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

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

Attack Chain

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

Impact

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

Recommendation

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

Executable File Creation with Multiple Extensions

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

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

Attack Chain

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

Impact

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

Recommendation

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

Curl or Wget Execution from Container Context

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

This detection rule identifies instances of curl or wget being executed from within containers managed by runc on Linux systems. The rule leverages Auditd Manager to monitor system calls and flags processes running with the title runc init that then execute curl or wget. This activity is noteworthy because attackers often use these tools to download malicious payloads (stagers, scripts, implants) or to exfiltrate data after compromising a container. While these tools can be used legitimately within containers, their execution in the context of runc init suggests a higher risk of malicious activity. The rule focuses on narrowing the signal to the container runtime boundary where unexpected download clients are more worthy of review. The rule specifically leverages Auditd Manager for data collection.

Attack Chain

An attacker gains initial access to a host system, possibly through exploiting a vulnerability in an application running outside the container (e.g., web application).
The attacker identifies a containerized application running on the compromised host.
The attacker exploits a vulnerability within the container, or abuses a privileged workload within the container, to gain elevated privileges or code execution within the container.
The attacker uses curl or wget to download additional tools or scripts into the container. These tools might include reverse shells, credential dumping tools, or data exfiltration utilities.
The attacker executes the downloaded tools to further compromise the container or the underlying host.
The attacker uses curl or wget to stage data for exfiltration to an external server. This may involve compressing and encoding data before transmission.
The attacker initiates the data exfiltration process using curl or wget to send the staged data to a remote server controlled by the attacker.
The attacker achieves their final objective, which could include data theft, system disruption, or further lateral movement within the network.

Impact

Compromised containers can lead to data breaches, service disruptions, and further attacks on internal systems. Successful exploitation could allow attackers to steal sensitive data, install malware, or pivot to other parts of the network, impacting confidentiality, integrity, and availability. The number of affected systems depends on the scope of the container deployment and the privileges granted to the compromised container.

Recommendation

Deploy the Sigma rule Detect Curl or Wget Execution from Container Context to your SIEM and tune for your environment.
Enable Auditd Manager with syscall coverage including execve to capture process execution and arguments within containers, as mentioned in the rule’s setup instructions.
Correlate alerts from this rule with network logs to identify the destination IP addresses and domains contacted by the compromised container.
Baseline trusted images and exclude stable image digests or namespaces when noisy to reduce false positives, as suggested in the rule’s false positives section.

Suspicious WMIC XSL Script Execution

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

This detection identifies WMIC allowlist bypass techniques by alerting on suspicious execution of scripts. When WMIC loads scripting libraries, such as jscript.dll or vbscript.dll, it may be indicative of an allowlist bypass. Adversaries exploit WMIC to bypass security measures by executing scripts via XSL files. This technique is often used for defense evasion and execution of malicious code. The detection logic focuses on monitoring WMIC executions with atypical arguments (format*:, /format:, -format:) in conjunction with the loading of scripting libraries, indicating potential misuse. The rule is designed for data generated by Elastic Defend and also supports Sysmon data sources.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploit).
The attacker executes WMIC.exe or wmic.exe with suspicious arguments such as “format*:”, “/format:”, or “-format*:*” to leverage XSL script processing.
WMIC attempts to load scripting libraries like jscript.dll or vbscript.dll to enable script execution.
The attacker uses the loaded scripting libraries to execute malicious code embedded in an XSL file.
The script performs various malicious actions, such as downloading additional payloads, modifying system configurations, or escalating privileges.
The attacker leverages the WMI functionality for lateral movement or persistence within the network.
The attacker evades detection by abusing trusted system binaries (WMIC) and allowlisted scripting engines.
The final objective is to achieve code execution and maintain control over the compromised system for data exfiltration or further malicious activities.

Impact

Successful exploitation allows attackers to bypass security measures and execute malicious code on compromised systems. This can lead to a range of adverse effects, including data theft, system compromise, and further propagation of malware within the network. The use of WMIC for defense evasion can make it difficult to detect malicious activity, increasing the risk of successful attacks.

Recommendation

Deploy the Sigma rule Detect Suspicious WMIC XSL Script Execution to your SIEM and tune for your environment.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 7 (Image Loaded) logging to activate the Sigma rule above.
Investigate any alerts triggered by the Sigma rule by reviewing process execution details and command-line arguments.
Review the parent process of suspicious WMIC executions to understand the context and origin of the activity.
Correlate the process.entity_id with other related events within a 2-minute window to identify any additional suspicious activities.
Implement application control policies to restrict the execution of unauthorized or suspicious XSL files and scripts.

Unsigned DLL Loaded by Svchost for Persistence and Privilege Escalation

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

Attackers may attempt to load malicious, unsigned DLLs into svchost.exe, a legitimate Windows service host process, to maintain persistence or escalate privileges. This technique abuses the shared service host process to execute arbitrary code with SYSTEM privileges. The svchost.exe process, which typically hosts multiple Windows services, can be targeted to load malicious DLLs from unusual file paths, potentially bypassing security measures that rely on code signing validation. This is especially concerning because svchost.exe is a trusted process, making detection more challenging. The loading of unsigned DLLs by svchost.exe from atypical directories is a strong indicator of potential malicious activity, as legitimate Windows services rarely load unsigned libraries from such locations.

Attack Chain

An adversary gains initial access to the system through an undisclosed method (e.g., exploitation of a vulnerability or social engineering).
The attacker creates a malicious, unsigned DLL on the compromised system in a non-standard directory like C:\ProgramData\.
The attacker modifies the Windows Registry to configure a service hosted by svchost.exe to load the malicious DLL. This often involves manipulating service dependencies or service parameters.
The system is restarted, or the targeted service is manually restarted, causing svchost.exe to load the specified DLL.
svchost.exe executes the code within the malicious DLL, now running with the privileges of the hosted service (typically SYSTEM).
The malicious DLL performs actions such as installing backdoors, escalating privileges further, or establishing command and control (C2) communication.
The attacker uses the established C2 channel to remotely control the compromised system, exfiltrate data, or perform other malicious activities.
The attacker maintains persistence on the system by ensuring the malicious DLL is loaded each time the service or system starts.

Impact

Successful exploitation allows attackers to gain persistent access to the compromised system with elevated (SYSTEM) privileges. This can lead to complete system compromise, data theft, installation of backdoors, and lateral movement within the network. The use of svchost.exe as a host for malicious DLLs makes detection more difficult, allowing attackers to operate undetected for extended periods.

Recommendation

Implement the provided Sigma rule to detect unsigned DLLs loaded by svchost.exe, focusing on the specified file paths and code signature status.
Examine dll.Ext.relative_file_creation_time to identify DLLs created shortly before being loaded to catch newly created malicious files.
Review and validate the legitimacy of all DLLs loaded by svchost.exe, focusing on those located in unusual paths.
Update endpoint detection and response (EDR) systems to specifically monitor for the loading of unsigned DLLs by system processes like svchost.exe.
Continuously update the exclusion list of known good DLL hashes to reduce false positives.

Uncommon Destination Port Connection by Web Server on Linux

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

This detection rule focuses on identifying potentially malicious activity stemming from Linux-based web servers. The rule is triggered when a web server process, such as Apache, Nginx, or others, initiates an outbound network connection to a destination port that is considered non-standard. This activity can signal the presence of a web shell, a malicious script uploaded to a web server to enable remote access and control. Attackers may exploit compromised web servers to establish covert communication channels, exfiltrate data, or launch further attacks on internal systems. The rule leverages data from Elastic Defend to monitor network connections and filter out legitimate traffic based on a predefined list of common ports and internal IP ranges.

Attack Chain

Initial access is gained via exploitation of a vulnerability in a web application or web server component running on a Linux system (e.g., through SQL injection or remote code execution).
A web shell is uploaded to the compromised web server, often disguised as a legitimate file or hidden within existing directories.
The attacker interacts with the web shell through HTTP requests, using it as a command and control interface.
The web shell executes commands on the server, initiating outbound network connections to non-standard ports.
These connections may be used to communicate with external C2 servers, download additional payloads, or exfiltrate sensitive data.
The attacker uses the web shell to move laterally within the network, targeting other systems and services.
The attacker attempts to establish persistence on the compromised server, ensuring continued access even after system reboots.
The final objective is data theft, system compromise, or disruption of services.

Impact

Compromised web servers can lead to significant data breaches, system downtime, and reputational damage. While this rule triggers on low-severity behavior, successful exploitation can lead to complete system compromise. The number of affected systems depends on the scope of the initial vulnerability and the attacker’s ability to move laterally. Organizations in all sectors that rely on web-based applications are potentially at risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect web server processes initiating connections to unusual destination ports and tune for your environment.
Enable Elastic Defend integration to collect the necessary network event data from Linux endpoints to activate the rule.
Review and customize the list of excluded destination ports and internal IP ranges in the Sigma rule to match your organization’s specific network configuration and legitimate traffic patterns.
Investigate any alerts generated by the rule to determine if the activity is malicious or benign, focusing on the process name, user, destination IP, and destination port.

Microsoft Build Engine Started by an Office Application

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious WMI Image Load from MS Office

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

This detection rule identifies suspicious image loading of wmiutils.dll from Microsoft Office processes (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE). Adversaries can use this technique to execute code and evade traditional parent/child processes spawned from Microsoft Office products. This behavior may indicate adversarial activity where child processes are spawned via Windows Management Instrumentation (WMI).

Attack Chain

User opens a malicious Microsoft Office document (e.g., Word, Excel).
The document contains a macro or exploit that triggers the execution of WMI commands.
The Office application spawns a WMI process or utilizes existing WMI infrastructure.
The WMI process loads the wmiutils.dll library, which is unusual for normal Office operations.
The WMI commands execute malicious code, potentially downloading or executing further payloads.
The attacker establishes persistence through WMI event subscriptions or other methods.
The attacker performs lateral movement using WMI to execute commands on other systems.

Impact

Successful exploitation allows attackers to execute arbitrary code, establish persistence, and move laterally within the network, potentially leading to data exfiltration, system compromise, or ransomware deployment. While the number of victims is unknown, this technique can be used in targeted attacks against organizations that heavily rely on Microsoft Office applications.

Recommendation

Deploy the Sigma rule “Suspicious WMI Image Load from MS Office” to your SIEM and tune for your environment.
Enable Sysmon event ID 7 (Image Loaded) logging for comprehensive image load monitoring as suggested in the setup instructions.
Monitor process creation events for Microsoft Office applications spawning WMI-related processes (e.g., wbemtest.exe, wmic.exe) to detect potential WMI abuse.
Implement network segmentation to limit lateral movement in case of a successful WMI-based attack.

Suspicious PDF Reader Child Process Activity

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

Attackers are increasingly leveraging PDF reader applications as an initial access vector, exploiting vulnerabilities within these programs or using social engineering to trick users into opening malicious PDF documents. Upon successful exploitation, adversaries often spawn built-in Windows utilities from the compromised PDF reader process to perform reconnaissance, escalate privileges, or establish persistence. This activity is designed to blend in with normal system operations, making it difficult to detect without specific monitoring and detection rules. The targeted software commonly includes Adobe Acrobat, Adobe Reader, and Foxit Reader. Defenders should be vigilant for unexpected child processes of PDF readers, especially command-line interpreters and system administration tools.

Attack Chain

A user receives a malicious PDF document via phishing or other means.
The user opens the PDF document using a vulnerable PDF reader application (e.g., Adobe Acrobat, Foxit Reader).
The PDF document exploits a vulnerability or uses a malicious script to execute an arbitrary command.
The PDF reader application spawns a command-line interpreter (e.g., cmd.exe, powershell.exe) or a system administration tool (e.g., reg.exe, net.exe).
The spawned process executes commands to gather system information (e.g., ipconfig.exe, systeminfo.exe, whoami.exe).
The attacker may attempt to discover network configuration, user accounts, or running processes.
The attacker could leverage the spawned process to download and execute further payloads.
The attacker gains a foothold on the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation of PDF reader applications can lead to initial access, privilege escalation, and further compromise of the affected system. While individual incidents may have a low risk score, widespread exploitation can lead to significant data breaches, system downtime, and reputational damage. The use of legitimate system utilities for malicious purposes can make detection challenging, allowing attackers to operate undetected for extended periods.

Recommendation

Enable process creation logging with command line arguments to capture the execution of suspicious child processes (Sysmon Event ID 1, Windows Security Event Logs).
Deploy the Sigma rule “Suspicious PDF Reader Child Process” to your SIEM and tune for your environment to detect the execution of suspicious processes spawned by PDF reader applications.
Monitor for network connections originating from PDF reader applications to unusual or external IP addresses.
Implement application control policies to restrict the execution of unauthorized or unknown executables.

Detection of Downloaded URL Files Used in Phishing Campaigns

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

Attackers commonly use .url shortcut files in phishing campaigns to deliver malicious payloads. These files, when downloaded from non-local sources, may bypass traditional security measures. This detection rule identifies such files by monitoring their creation events on Windows systems. The rule focuses on files with the .url extension and a zone identifier indicating they originated from outside the local network. These files are often delivered via email or malicious websites, tricking users into clicking them, which can lead to the execution of arbitrary commands or the redirection to malicious websites. This technique allows attackers to gain initial access or execute malicious code on the victim’s machine.

Attack Chain

The attacker crafts a phishing email or a malicious website containing a link to a .url file.
The victim clicks the link, resulting in the download of the .url file to their Windows system.
The .url file is created on the filesystem, triggering a file creation event.
The operating system assigns a Zone Identifier to the file, marking it as originating from an external source.
The victim double-clicks the .url file, which contains a URL pointing to a malicious website or an executable.
The operating system attempts to open the URL using the default web browser or execute the embedded command.
If the URL points to a malicious website, the victim may be prompted to download and execute malware.
The malware executes, potentially leading to system compromise, data theft, or other malicious activities.

Impact

Successful exploitation can lead to the execution of arbitrary commands, redirection to malicious websites, and subsequent malware infection. If successful, attackers can compromise user systems, steal sensitive information, or establish a foothold for further malicious activities within the organization’s network. The impact can range from individual system compromise to broader network breaches, depending on the attacker’s objectives and the extent of the infection.

Recommendation

Deploy the Sigma rule Downloaded URL Files Created to your SIEM to detect the creation of downloaded .url files with a non-local Zone Identifier and tune for your environment.
Investigate any file creation events where file.extension == "url" and file.Ext.windows.zone_identifier == 3 using the provided investigation steps in the advisory.
Update security policies and endpoint protection configurations to block the download and execution of .url files from untrusted sources, as mentioned in the advisory.
Educate users on safe downloading practices and the risks associated with opening .url files from untrusted sources, as highlighted in the advisory’s false positive analysis.

Abuse of Windows Update Client for DLL Loading

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

Attackers are abusing the Windows Update Auto Update Client (wuauclt.exe) to execute arbitrary code by loading malicious DLLs. This technique allows malicious actors to evade defenses by masquerading their activity as legitimate Windows processes. The abuse involves using specific command-line arguments with wuauclt.exe to load a DLL from a user-writable directory. This behavior has been observed in various attacks aimed at evading traditional security measures. This is an effective defense evasion and execution technique, allowing attackers to execute code while blending in with normal system processes, potentially bypassing application control and other security mechanisms.

Attack Chain

An attacker gains initial access to the system through an unrelated method.
The attacker places a malicious DLL in a directory writable by standard users, such as C:\Users\\, C:\ProgramData\, C:\Windows\Temp\, or C:\Windows\Tasks\.
The attacker executes wuauclt.exe with the arguments /RunHandlerComServer and /UpdateDeploymentProvider along with the path to the malicious DLL. For example: wuauclt.exe /RunHandlerComServer /UpdateDeploymentProvider /dll:.
wuauclt.exe loads the specified malicious DLL.
The malicious DLL executes arbitrary code within the context of the wuauclt.exe process.
The malicious code performs its intended actions, such as establishing persistence, communicating with a C2 server, or escalating privileges.
The attacker may then use the compromised system as a foothold for lateral movement within the network.

Impact

Successful exploitation allows attackers to execute arbitrary code within a trusted Windows process, potentially bypassing security controls and making detection more difficult. While specific victim counts are unavailable, this technique can be used in targeted attacks against organizations where defense evasion is a priority for the adversary. Successful execution can lead to complete system compromise, data theft, or further malicious activities.

Recommendation

Deploy the Sigma rule ImageLoad via Windows Update Auto Update Client to detect the execution of wuauclt.exe with suspicious arguments.
Monitor process creation events for wuauclt.exe with the arguments /RunHandlerComServer and /UpdateDeploymentProvider, focusing on DLL paths in user-writable directories.
Enable Sysmon process-creation and image-load logging to improve visibility into this type of attack.
Audit DLLs loaded by wuauclt.exe and investigate any unsigned or unexpected DLLs.

Process Activity via Compiled HTML File Execution

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

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

Attack Chain

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

Impact

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

Recommendation

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

Detection of Downloaded Shortcut Files

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

This detection identifies suspicious .lnk files created on Windows systems, especially those downloaded from external sources, which may indicate potential phishing attempts. The rule leverages file creation events and zone identifiers to trace the file’s origin. Adversaries exploit shortcut files by embedding malicious commands within them, often distributing these files via phishing campaigns. This can lead to arbitrary code execution upon user interaction. The rule is designed for data generated by Elastic Defend.

Attack Chain

User receives a phishing email containing a malicious .lnk file.
The user downloads the .lnk file to their Windows system.
The Windows OS marks the file with a Zone Identifier indicating it came from an external source.
The user double-clicks the .lnk file, triggering its execution.
The .lnk file executes embedded commands, such as PowerShell or cmd.exe.
The command downloads and executes a malicious payload from a remote server.
The payload establishes persistence on the compromised system.
The attacker gains remote access and control over the infected host.

Impact

A successful attack can lead to the compromise of the user’s system, potentially resulting in data theft, malware installation, or further propagation of the attack within the network. The severity of the impact depends on the privileges of the compromised user account and the attacker’s objectives. The rule aims to detect and prevent such attacks early in the attack chain, reducing the potential damage.

Recommendation

Deploy the Sigma rule “Downloaded Shortcut Files” to your SIEM and tune for your environment.
Enable Elastic Defend to capture the necessary file creation events for the rule to function.
Investigate any alerts generated by the rule, paying close attention to the file path, zone identifier, and associated user account.
Update security policies to restrict the execution of .lnk files from untrusted sources.
Educate users about the risks of opening suspicious attachments, especially .lnk files, to prevent initial access.

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

Network Connection via Compiled HTML File

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

Adversaries may conceal malicious code in a compiled HTML file (.chm) and deliver it to a victim for execution. CHM content is loaded by the HTML Help executable program (hh.exe). Attackers can use CHM files to proxy the execution of malicious payloads via a signed binary to bypass security controls, and also to gain initial access to environments via social engineering methods. This rule identifies network connections done by hh.exe, which can potentially indicate abuse to download malicious files or tooling, or masquerading. The detection logic focuses on network connections originating from hh.exe to external IPs, excluding private or reserved IP ranges.

Attack Chain

The user receives a compiled HTML file (.chm), often through social engineering tactics such as phishing.
The user opens the .chm file, which is then executed by the HTML Help executable (hh.exe).
The hh.exe process loads and renders the HTML content within the .chm file.
Embedded within the HTML content is malicious JavaScript or other scripting code.
The malicious script executes, initiating a network connection via hh.exe to an external server.
The external server hosts a malicious payload, such as a reverse shell or an executable file.
Hh.exe downloads the malicious payload to the victim’s machine.
The downloaded payload is executed, granting the attacker initial access or performing other malicious actions like data exfiltration or lateral movement.

Impact

A successful attack can lead to initial access to a victim’s system, potentially bypassing security controls through a signed Microsoft binary. This can result in the download and execution of arbitrary payloads, leading to data exfiltration, lateral movement within the network, or installation of malware. The exploitation can spread rapidly through social engineering, affecting multiple users within an organization. While the severity is rated as medium, the potential for escalation to a critical compromise is high if the attacker gains a foothold in the environment.

Recommendation

Enable process and network monitoring on Windows endpoints, focusing on hh.exe activity (Data Source: Elastic Defend, Sysmon, SentinelOne).
Deploy the Sigma rule Network Connection via Compiled HTML File to your SIEM and tune for your environment to detect suspicious network connections initiated by hh.exe.
Monitor for hh.exe spawning child processes, which could indicate the execution of downloaded payloads. Create a Sigma rule to detect such events.
Implement network segmentation to limit the impact of a compromised host and restrict lateral movement.
Conduct regular security awareness training to educate users about the risks of opening unsolicited .chm files.
Inspect the digital signatures of hh.exe and other system binaries to ensure their integrity and authenticity.

Long Base64 Encoded Command via Scripting Interpreter

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

This rule identifies the execution of scripting interpreters (Python, PowerShell, Node.js, and Deno) with unusually long command lines containing base64 encoded payloads. The rule focuses on scenarios where the initial process.command_line field is ignored due to its excessive length, but the complete command line is still available in process.command_line.text. Attackers leverage this technique to evade traditional command-line inspection and execute malicious content across Windows, macOS, and Linux systems. This approach allows attackers to embed and execute code without writing it to disk, making it harder to detect. The rule is designed to detect this behavior, allowing for closer inspection of the executed commands and their intent.

Attack Chain

An attacker gains initial access to a system (e.g., via phishing or exploiting a vulnerability).
The attacker uses PowerShell, Python, Node.js, or Deno to execute commands.
A long, base64-encoded string is crafted, designed to evade detection.
The interpreter is invoked with the encoded string passed as an argument, exceeding typical command-line limits.
The process.command_line field is truncated due to its length, but the full command line is available in process.command_line.text.
The interpreter decodes and executes the payload from the process.command_line.text.
The decoded payload performs malicious actions such as downloading malware, establishing persistence, or exfiltrating data.
The attacker achieves their objective, such as gaining control of the system or stealing sensitive information.

Impact

Successful exploitation can lead to a wide range of malicious activities, including malware installation, data theft, privilege escalation, and system compromise. Due to the defense evasion capabilities, it is difficult to identify and prevent. The impact includes potential data breaches, financial losses, and reputational damage. The rule’s detection helps defenders identify this attack vector and prevent further exploitation of affected systems.

Recommendation

Deploy the Sigma rule Detect Long Base64 Encoded Command via Scripting Interpreter to your SIEM to detect this behavior.
Investigate any alerts generated by this rule, focusing on the process.command_line.text field to understand the full command being executed.
Review parent processes and execution chains of the interpreter to understand the initial attack vector.
Implement controls to restrict the execution of scripting interpreters from untrusted sources.
Monitor process execution logs for command lines exceeding a certain length threshold.
Improve logging coverage to capture the full command line even when it exceeds standard limits.

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

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Process Access via Direct System Call

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

This detection identifies suspicious process access events on Windows systems where a process attempts to access another process’s memory via direct system calls, bypassing standard Windows API calls. Endpoint security solutions often hook userland Windows APIs to detect malicious code execution. Attackers can evade these hooks by directly invoking syscalls, which are lower-level instructions that interact directly with the operating system kernel. The rule specifically looks for process access events (Sysmon Event ID 10) where the call trace does not originate from known Windows system DLLs like ntdll.dll, indicating a potential attempt to bypass security measures. The rule excludes certain legitimate applications, such as Malwarebytes Anti-Exploit, Cisco AMP, Microsoft EdgeWebView, and Adobe Acrobat DC, to reduce false positives. This technique is often employed by advanced malware and red teams to evade detection.

Attack Chain

A malicious process is executed on the system, either through user interaction or exploitation of a vulnerability.
The process attempts to gain access to another process’s memory space (Target Process).
Instead of using standard Windows API calls, the malicious process directly invokes system calls (syscalls) to access the target process’s memory.
The CallTrace in the Sysmon event does not originate from expected system DLLs like ntdll.dll, sysfer.dll, wow64cpu.dll, wow64win.dll, or win32u.dll, indicating a direct syscall.
The process might attempt to read sensitive information such as credentials, inject malicious code, or manipulate the target process’s behavior.
The malicious process performs actions within the context of the target process, such as executing injected code or accessing sensitive data.
The attacker leverages the compromised process to achieve their objectives, such as data exfiltration, lateral movement, or privilege escalation.
The attacker cleans up any traces of their activity and attempts to maintain persistence on the compromised system.

Impact

Successful exploitation can lead to the compromise of sensitive data, the injection of malicious code into legitimate processes, and the complete takeover of the affected system. This can result in data breaches, financial loss, and reputational damage. The impact is especially significant if the target process holds sensitive credentials, browser secrets, or has security-product context.

Recommendation

Enable Sysmon process access logging (Event ID 10) with call tracing and ingest the logs into your SIEM to activate the rules above (https://ela.st/sysmon-event-10-setup).
Deploy the Sigma rules provided in this brief to your SIEM and tune them for your environment to detect direct syscall process access.
Investigate any alerts generated by these rules, focusing on the SourceImage, TargetImage, GrantedAccess, and CallTrace fields in the Sysmon event to determine the legitimacy of the process access attempt.
Prioritize investigation of alerts where the target process is lsass.exe or other security-sensitive processes.
Implement robust endpoint detection and response (EDR) solutions to detect and prevent malicious activity on endpoints.
Monitor for suspicious process creation events originating from the flagged processes.

Suspicious Enumeration Commands Spawned via WMIPrvSE

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

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

Attack Chain

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

Impact

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

Recommendation

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

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

Suspicious PowerShell Execution via Windows Script Host

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

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

Attack Chain

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

Impact

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

Recommendation

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

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

Kubernetes Pod Exec with Curl or Wget to HTTPS

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

This detection rule identifies suspicious activity within Kubernetes environments where attackers leverage kubectl exec or similar API calls to execute commands within pods. Specifically, it focuses on instances where these commands involve using curl or wget to retrieve content over HTTPS. Attackers may use this technique to download malicious scripts, tools, or exfiltrate sensitive data from compromised pods. This activity is flagged based on decoded request URIs from Kubernetes audit logs, reconstructed command strings, and filtering of benign traffic related to cluster health checks and OIDC/JWKS endpoints. The rule aims to detect anomalous behavior that deviates from typical pod execution patterns, helping defenders identify potential intrusions or misuse of pod execution privileges. The rule was created on 2026/04/23 and last updated on 2026/04/23 according to the source.

Attack Chain

An attacker gains unauthorized access to the Kubernetes cluster, possibly through compromised credentials or a vulnerability.
The attacker identifies a target pod within the cluster to execute commands within.
The attacker uses kubectl exec or a similar API call to initiate a shell session within the target pod.
The attacker crafts a command using curl or wget to download a malicious script, tool, or exfiltrate data over HTTPS. The URL is often encoded in the requestURI.
The Kubernetes API server records the exec call and its parameters in the audit logs.
The detection rule decodes the requestURI, extracts the command string, and identifies the use of curl or wget with an HTTPS URL.
The rule filters out known benign URLs associated with cluster health checks or OIDC/JWKS endpoints.
If the command is identified as malicious, an alert is triggered, indicating a potential compromise.

Impact

Successful exploitation can lead to the deployment of malicious tools within the Kubernetes environment, potentially enabling lateral movement, data theft, or denial-of-service attacks. Compromised pods could expose sensitive data or be used as a launchpad for further attacks on the cluster or other systems. The scope of impact depends on the permissions granted to the compromised pod and the attacker’s objectives.

Recommendation

Deploy the Sigma rule “Kubernetes Pod Exec with Curl or Wget to HTTPS” to your SIEM and tune for your environment.
Review Kubernetes RoleBindings for pods/exec to ensure only required principals retain access on sensitive namespaces.
Investigate any alerts generated by the Sigma rule by reviewing the decoded URI and reconstructed command in the alert details.
Implement network policies to restrict egress traffic from pods, limiting the potential for data exfiltration via HTTPS.
Regularly audit Kubernetes audit logs for suspicious activity related to pod execution and API calls.

Suspicious PowerShell Engine ImageLoad

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

Attackers can leverage the PowerShell engine without directly executing powershell.exe. This technique, often referred to as “PowerShell without PowerShell,” involves using the underlying System.Management.Automation namespace. This approach allows attackers to bypass application allowlisting and PowerShell security features, operating more stealthily within a compromised environment. This technique makes detection more challenging, as standard PowerShell execution logs might not capture the activity. The activity is detected by monitoring which processes load the System.Management.Automation.dll or System.Management.Automation.ni.dll libraries. This activity can legitimately happen where vendors have their own PowerShell implementations that are shipped with some products.

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 deploys a custom tool or script on the target system. This tool is designed to interact with the System.Management.Automation namespace directly.
The custom tool loads the System.Management.Automation.dll or System.Management.Automation.ni.dll library into its process space.
The tool uses the loaded PowerShell engine to execute malicious commands or scripts without invoking powershell.exe.
The attacker performs reconnaissance activities, such as gathering system information or network configurations, using PowerShell commands.
The attacker attempts to move laterally within the network, leveraging the PowerShell engine to execute commands on other systems.
The attacker installs malware or backdoors using the PowerShell engine to maintain persistence within the compromised environment.
The attacker exfiltrates sensitive data or causes damage to the system, completing the objectives of the attack.

Impact

A successful attack leveraging “PowerShell without PowerShell” can lead to significant compromise of Windows systems. Attackers can bypass traditional security measures, potentially leading to data theft, system disruption, or the installation of persistent malware. The technique’s stealthy nature can prolong the time to detection, increasing the potential for widespread damage.

Recommendation

Deploy the Sigma rule Suspicious PowerShell Engine ImageLoad to your SIEM to detect when the System.Management.Automation.dll or System.Management.Automation.ni.dll libraries are loaded by unexpected processes.
Investigate any alerts generated by the Sigma rule, focusing on the process execution chain (parent process tree) for unknown processes.
Implement endpoint detection and response (EDR) solutions like Elastic Defend to provide visibility into process behavior and library loading events, activating the process_creation and image_load log sources.
Review and tune exclusions to the Sigma rule based on legitimate vendor applications to reduce false positives.

Suspicious MSBuild Execution from Scripting Processes

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

The Microsoft Build Engine (MSBuild) is a software build platform typically used by developers. However, attackers can abuse MSBuild to execute malicious code by using it as a proxy execution method, allowing them to bypass traditional defenses. This technique involves invoking MSBuild from scripting environments like PowerShell or cmd.exe to run arbitrary code within the context of a trusted process. The activity detected by this rule focuses on instances where MSBuild is launched by a script interpreter, which is not typical for standard software development workflows. This behavior, observed since at least 2020, can be used for stealthy execution of payloads and defense evasion tactics, especially in environments that trust MSBuild as a legitimate system utility. Defenders should be aware of this technique as it allows attackers to blend in with normal system activity and bypass application control policies.

Attack Chain

The attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
A script (e.g., PowerShell, cmd.exe) is used to execute a malicious command or series of commands.
The script invokes msbuild.exe with specific arguments to execute arbitrary code. This might involve inline tasks or references to external XML project files containing malicious instructions.
MSBuild processes the provided XML file or inline task, interpreting and executing the malicious code.
The executed code performs actions such as downloading additional payloads, modifying system configurations, or establishing persistence.
MSBuild, acting as a proxy, executes the attacker’s code within a trusted process, potentially evading detection by security software.
The attacker leverages the compromised system to move laterally within the network, escalating privileges, and accessing sensitive data.
The attacker’s final objective is achieved, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation allows attackers to execute arbitrary code on Windows systems, potentially leading to data theft, system compromise, and further propagation within the network. This technique can bypass application control and other security measures, making it difficult to detect and prevent. The impact can range from minor data breaches to complete system takeover, depending on the attacker’s objectives and the compromised system’s role within the organization.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture the process tree and command-line arguments, enabling detection of suspicious MSBuild executions.
Deploy the Sigma rule Microsoft Build Engine Started by a Script Process to your SIEM to identify instances of MSBuild being invoked by script interpreters. Tune the rule with appropriate whitelisting for known development activities to reduce false positives.
Monitor process execution events for msbuild.exe with parent processes such as cmd.exe, powershell.exe, cscript.exe, and mshta.exe.
Implement application control policies to restrict the execution of MSBuild to authorized users and directories.
Regularly review and update the list of excluded processes and directories in the Sigma rule to adapt to changing development practices.

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

Execution from Unusual Directory - Command Line

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

This detection rule identifies instances of process execution originating from suspicious default Windows directories. Attackers often exploit these locations to conceal malware, leveraging the implicit trust associated with system or application paths to evade security measures. This tactic is employed to make malicious executions appear less conspicuous. The rule focuses on detecting specific processes, including wscript.exe, cscript.exe, rundll32.exe, regsvr32.exe, and others, when they are executed from unusual directories, such as C:\\PerfLogs\\, C:\\Users\\Public\\, and C:\\Windows\\Tasks\\. The intent is to highlight anomalous process behaviors that deviate from expected norms, providing early warning of potential malicious activity. The detection logic also includes filters to reduce false positives by excluding known legitimate executables and command line arguments from the specified directories.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker uploads or drops a malicious payload into a suspicious directory like C:\\Users\\Public\\ or C:\\Windows\\Tasks\\.
The attacker uses a legitimate Windows utility such as cmd.exe, powershell.exe, or wscript.exe to execute the malicious payload.
The executed script or binary performs malicious actions, such as establishing persistence.
The attacker attempts to evade detection by masquerading the malicious activity as legitimate system processes.
The malware may attempt to communicate with a command-and-control server.
The malware may perform lateral movement within the network.
The final objective of the attacker is to exfiltrate sensitive data or cause damage to the system.

Impact

Successful exploitation can lead to malware infection, data compromise, and system instability. Attackers can establish persistent access, escalate privileges, and perform lateral movement within the network. The impact ranges from minor disruptions to significant data breaches depending on the attacker’s objectives and the compromised system’s role within the organization. The targeted sectors are broad, as this technique is applicable across various industries and organizational sizes.

Recommendation

Deploy the Sigma rule “Execution from Unusual Directory - Command Line” to your SIEM and tune for your environment to detect suspicious process executions from unusual directories.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and command-line arguments.
Enable process creation logging with command line arguments to provide the necessary data for the Sigma rule (reference log source in rule).
Regularly review and update the list of suspicious directories in the Sigma rule to reflect changes in your environment.
Implement application whitelisting to restrict the execution of unauthorized applications from unusual directories.

Windows Script Interpreter Executing Process via WMI

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

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

Attack Chain

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

Impact

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

Recommendation

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

Unusual Parent Process for cmd.exe

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious SolarWinds Child Process Execution

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious 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 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 MS Office Child Process

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

This detection identifies suspicious child processes spawned by Microsoft Office applications (Word, PowerPoint, Excel, Outlook), which are commonly targeted for initial access via malicious documents or macro exploitation. The rule focuses on identifying anomalous process executions originating from these applications, a tactic often employed to execute arbitrary code or download additional payloads. Attackers leverage Office applications due to their widespread use and inherent scripting capabilities. Successful exploitation can lead to arbitrary code execution, lateral movement, and data exfiltration. This detection helps defenders identify and respond to potential security breaches originating from Microsoft Office applications, reducing the attack surface and minimizing potential damage. The rule specifically looks for processes like cmd.exe, powershell.exe, mshta.exe, wscript.exe, and others being spawned by Office applications.

Attack Chain

A user receives a malicious Microsoft Office document (e.g., Word, Excel) via email or downloads it from a compromised website.
The user opens the document, triggering the execution of a malicious macro or exploitation of a vulnerability within the Office application.
The Office application (e.g., winword.exe, excel.exe) spawns a suspicious child process such as cmd.exe or powershell.exe.
The spawned process executes a command to download a malicious payload from a remote server using bitsadmin.exe or certutil.exe.
The downloaded payload is a reverse shell or a malware dropper, which establishes a connection to an attacker-controlled server.
The attacker gains initial access to the compromised system and attempts to escalate privileges and perform reconnaissance.
The attacker uses discovery commands with net.exe, ipconfig.exe, tasklist.exe, and whoami.exe to map the environment and identify valuable targets.
The attacker moves laterally to other systems within the network, aiming to compromise critical assets and achieve their objectives, such as data theft or ransomware deployment.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to gain initial access to the compromised system. This can result in data theft, installation of malware, lateral movement to other systems, and ultimately, significant disruption to business operations. The widespread use of Microsoft Office makes it a prime target, potentially affecting a large number of users and organizations. Failure to detect and respond to these attacks can result in significant financial losses, reputational damage, and compromise of sensitive data.

Recommendation

Enable process creation logging (Sysmon Event ID 1 or Windows Security Event Logs) to ensure the visibility required to detect suspicious child processes.
Deploy the Sigma rule Suspicious MS Office Child Process to your SIEM and tune the rule based on your environment to reduce false positives.
Investigate any alerts generated by the Suspicious MS Office Child Process Sigma rule by examining the parent process tree and associated network connections.
Implement application control policies to restrict the execution of unauthorized processes from Microsoft Office applications.
Regularly update Microsoft Office applications to patch known vulnerabilities.
Block known malicious domains or IPs associated with malware delivery and command and control, based on threat intelligence feeds and IOCs from external sources.

Suspicious Mofcomp Activity

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Microsoft Antimalware Service Executable Execution

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Image Load (taskschd.dll) from MS Office

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

This detection rule identifies a suspicious image load (taskschd.dll) originating from Microsoft Office applications (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE). The behavior suggests potential adversarial activity involving the creation of scheduled tasks through the Windows Component Object Model (COM). Attackers may exploit this technique to establish persistence, circumventing traditional monitoring focused on the schtasks.exe utility. The use of COM for scheduled task management allows for stealthier operation and evasion of standard security controls, making it a valuable persistence mechanism for malicious actors. The rule is designed for data generated by Elastic Defend, Sysmon, and other endpoint detection platforms.

Attack Chain

User opens a malicious Microsoft Office document (e.g., Word, Excel).
The document executes embedded macro code or exploits a vulnerability.
The macro or exploit leverages the Component Object Model (COM).
The Office application (e.g., WINWORD.EXE) loads the taskschd.dll library, providing access to the Task Scheduler service.
The COM interface is used to programmatically create a new scheduled task.
The scheduled task is configured to execute a malicious payload at a later time or on a recurring basis.
The malicious payload could be a script, executable, or command-line instruction.
Upon execution, the payload achieves the attacker’s objective, such as establishing persistence, downloading additional malware, or compromising the system.

Impact

A successful attack leveraging this technique can allow adversaries to maintain persistent access to a compromised system. This can lead to long-term data exfiltration, lateral movement within the network, and deployment of ransomware. The low severity score assigned to the original rule may underestimate the potential impact, as persistence is a critical component of many advanced attacks. Affected systems may require extensive remediation to remove all traces of the malicious activity.

Recommendation

Deploy the Sigma rule “Office Application Loading Task Scheduler DLL” to your SIEM and tune for your environment to detect this specific activity.
Enable Sysmon Event ID 7 (Image Loaded) logging on Windows endpoints to provide visibility into DLL loading events, which is a prerequisite for the Sigma rule.
Investigate any alerts generated by the Sigma rule, focusing on the specific scheduled tasks that are created and the payloads they execute.
Monitor for scheduled task creation events (Event ID 4698) and deletion events (Event ID 4699) in the Windows Event Logs, as referenced in the rule’s investigation guide.

Suspicious Execution via Windows Subsystem for Linux

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Execution from VS Code Extension

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

A malicious VS Code extension, configured to run upon editor startup, can execute arbitrary commands, potentially leading to the installation of remote access trojans (RATs) or other malicious payloads. The attack vector leverages the extension host under .vscode/extensions/ to spawn processes such as script interpreters or download utilities. This activity has been observed in campaigns like the fake Clawdbot extension that installed ScreenConnect RAT. The execution can involve Living-off-the-Land binaries (LOLBins) or recently created executables from non-standard paths, posing a significant risk to Windows systems.

Attack Chain

A user installs a malicious VS Code extension.
The extension is configured with activationEvents: ["onStartupFinished"] to run automatically when VS Code starts.
The VS Code extension host (Code.exe or node.exe) spawns a script interpreter (e.g., powershell.exe, cmd.exe) from within the .vscode/extensions/ directory.
The script interpreter executes a command to download a malicious payload from a remote server using tools like curl.exe, bitsadmin.exe, or mshta.exe.
The downloaded payload is saved to disk, often in a temporary directory outside of Program Files.
The script interpreter executes the downloaded payload, leading to further malicious activity. For example, ScreenConnect might be installed.
Persistence mechanisms are established (e.g., via registry keys or scheduled tasks).
The attacker gains remote access to the compromised system.

Impact

A successful attack can lead to the complete compromise of a developer’s workstation, potentially affecting intellectual property and sensitive data. The installation of RATs like ScreenConnect can enable persistent remote access, allowing attackers to perform data exfiltration, lateral movement, and further malicious activities. The compromised machine can then be used as a pivot point to attack other systems within the organization.

Recommendation

Deploy the “Suspicious Execution from VS Code Extension” Sigma rule to your SIEM to detect malicious process execution from VS Code extensions.
Monitor process creation events for script interpreters and LOLBins spawned from the .vscode/extensions/ directory.
Implement application control policies to restrict the execution of unsigned or untrusted executables.
Regularly review and audit installed VS Code extensions for suspicious activity or unnecessary permissions.
Educate developers about the risks of installing extensions from untrusted sources.
Block the C2 domains associated with ScreenConnect and other RATs at the firewall/DNS resolver.

Schtasks Run Task On Demand

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

This analytic detects the execution of Windows Scheduled Tasks on demand using the schtasks.exe utility. The detection focuses on identifying schtasks.exe being executed with the run command, which is often used by adversaries to force the execution of previously created scheduled tasks. This activity is significant because attackers frequently leverage scheduled tasks for persistent access, privilege escalation, or lateral movement within a compromised network. Detecting this behavior can help defenders identify and respond to malicious activity before it leads to further compromise. The technique has been associated with various threat actors and malware families including Qakbot, XMRig, and Medusa Ransomware as well as campaigns such as CISA AA22-257A and Industroyer2.

Attack Chain

An attacker gains initial access to the system through various means (e.g., exploiting a vulnerability, phishing).
The attacker establishes persistence by creating a new scheduled task using schtasks.exe.
The attacker uses schtasks.exe with the run command to trigger the malicious scheduled task on demand.
The scheduled task executes a malicious payload, such as a script or executable.
The payload may perform various malicious actions, such as downloading additional malware, escalating privileges, or gathering sensitive information.
The attacker moves laterally to other systems on the network by creating and running scheduled tasks remotely.
The attacker attempts to disable security controls or evade detection by modifying existing scheduled tasks.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or system disruption.

Impact

Successful exploitation can lead to persistent access, lateral movement, and privilege escalation within the compromised environment. Attackers can use this technique to maintain a foothold on the system, spread malware to other systems on the network, and ultimately achieve their objectives, such as data theft, ransomware deployment, or disruption of critical services.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the execution of schtasks.exe with the run command, tuning it to exclude known legitimate uses.
Investigate any detected instances of schtasks.exe execution with the run command to determine if they are malicious.
Monitor process execution data for unusual or unexpected processes being launched by scheduled tasks.
Implement strict access controls and regularly review and audit scheduled tasks to prevent unauthorized modifications or creations.
Enable Sysmon process-creation logging (Event ID 1) to capture detailed information about process executions, including command-line arguments.

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

Potential Direct Kubelet Access via Process Arguments

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

This rule detects potential direct Kubelet access via process arguments within Linux containers. Attackers may target the Kubelet API to gain unauthorized access to the Kubernetes API server or other sensitive resources within the cluster. Observed requests are often used for reconnaissance, such as enumerating pods and cluster resources, or for executing commands directly on the API server. This activity indicates a potential attempt to move laterally within the Kubernetes environment. The activity is detected by monitoring process arguments for HTTP requests directed at the Kubelet API on ports 10250 or 10255. The detection leverages Elastic Defend for Containers, introduced in version 9.3.0.

Attack Chain

An attacker gains initial access to a container within the Kubernetes cluster, potentially through exploiting a vulnerable application.
The attacker opens an interactive shell within the compromised container.
Using command-line tools such as curl or wget, the attacker crafts an HTTP request targeting the Kubelet API, typically on port 10250 or 10255.
The HTTP request is embedded within the process arguments, including specific Kubelet endpoints such as /pods, /exec, /run, or /logs.
The attacker attempts to enumerate pods and other cluster resources by querying the /pods endpoint.
The attacker attempts to execute commands within containers by leveraging the /exec or /run endpoints.
The attacker attempts to retrieve container logs using the /logs endpoint.
Successful exploitation allows the attacker to move laterally within the Kubernetes cluster, potentially gaining access to sensitive data or control over other resources.

Impact

Successful exploitation of direct Kubelet access can lead to significant compromise within a Kubernetes cluster. Attackers can enumerate sensitive information, execute arbitrary commands within containers, and move laterally to other parts of the cluster. This can result in data exfiltration, denial of service, or complete cluster takeover. Due to the high level of access granted by Kubelet, a successful attack allows the attacker to take complete control over the target node.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune them for your environment. Enable Elastic Defend for Containers with a minimum version of 9.3.0 to generate the necessary logs for these detections.
Review network policies to restrict pod access to Kubelet ports (10250, 10255) except from approved node-local agents (references: https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster).
Harden Kubelet authentication and authorization by disabling anonymous access and requiring webhook authorization (references: https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/).
Enforce pod security policies to restrict privileged pods and host networking, reducing the attack surface for node API access.

Persistence via WMI Event Subscription

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

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

Attack Chain

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

Impact

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

Recommendation

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

MSBuild Started by System Process for Defense Evasion and Execution

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

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

Attack Chain

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

Impact

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

Recommendation

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

Microsoft Build Engine Executed After Renaming

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

Attackers may rename legitimate utilities, such as MSBuild, to evade detection, application allowlists, and other security protections. MSBuild, the Microsoft Build Engine, is a platform for building applications. Attackers can abuse MSBuild to proxy the execution of malicious code. The detection rule identifies instances where MSBuild is started after being renamed, indicating a potential attempt to evade detection. The rule focuses on identifying processes where the original file name is MSBuild.exe, but the process name is different, suggesting a renaming attempt.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker renames the legitimate MSBuild.exe executable to a different name (e.g., evil.exe) to evade detection.
The attacker executes the renamed MSBuild executable (evil.exe) with a malicious project file (.csproj or similar).
MSBuild processes the project file, which contains commands or scripts to be executed.
The malicious commands within the project file are executed by MSBuild, potentially downloading or executing further payloads.
The attacker may use MSBuild to execute PowerShell commands or other scripting languages for lateral movement or further exploitation.
MSBuild can be used to modify files, registry entries, or other system settings.
The attacker achieves their final objective, such as data exfiltration or establishing persistence.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to install malware, steal sensitive information, or compromise the entire system. The renaming of MSBuild can bypass standard application allowlisting and detection mechanisms.

Recommendation

Enable Sysmon process creation logging to capture the Image and OriginalFileName fields.
Deploy the Sigma rule “Microsoft Build Engine Using an Alternate Name” to your SIEM and tune for your environment to detect renamed MSBuild executables based on process metadata and command-line arguments.
Monitor process execution events for processes with OriginalFileName of “MSBuild.exe” and a different process.name.
Implement application control policies to restrict the execution of renamed executables, specifically those with an OriginalFileName of “MSBuild.exe.”

Kubernetes Pod Exec Potential Reverse Shell Activity Detected

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

This detection identifies attempts to establish reverse shells or bind shells within Kubernetes pods. The rule analyzes Kubernetes audit logs, specifically targeting kubectl exec commands where a user is attempting to execute commands inside a container. By decoding the URL-encoded command parameters and searching for known reverse shell patterns (e.g., usage of /dev/tcp, nc -e, socat), the rule aims to detect unauthorized interactive access and command-and-control activity originating from compromised pods. This activity is often indicative of post-exploitation behavior, where an attacker seeks to gain persistent access to the Kubernetes cluster. The rule is based on the Elastic detection rule released on 2026-04-23. It is critical to investigate these alerts promptly, as successful reverse shell establishment can lead to data exfiltration, lateral movement within the cluster, and further compromise of sensitive resources.

Attack Chain

An attacker gains initial access to a Kubernetes cluster, potentially through a vulnerability in an application running within a pod, or by compromising a user’s credentials.
The attacker uses kubectl exec to execute a command within a target pod. The command is embedded within the requestURI parameter, URL-encoded to evade basic detection.
The requestURI includes the command= parameter, followed by a string containing shell commands designed to initiate a reverse or bind shell.
The malicious command utilizes utilities such as nc, socat, or bash with redirection to /dev/tcp to establish a network connection back to the attacker’s controlled machine.
The reverse shell connects back to the attacker, providing interactive command execution within the compromised pod.
The attacker uses the reverse shell to perform reconnaissance, discover sensitive information, and potentially escalate privileges within the pod.
The attacker might attempt to move laterally to other pods or nodes within the cluster, leveraging stolen credentials or exploiting further vulnerabilities.
The attacker achieves their objective, which may include data exfiltration, deployment of malicious containers, or disruption of services.

Impact

A successful reverse shell attack within a Kubernetes cluster can have severe consequences. Attackers can gain unauthorized access to sensitive data, compromise critical applications, and disrupt services. Lateral movement within the cluster can lead to widespread compromise, potentially affecting numerous pods and nodes. The lack of proper monitoring and alerting for kubectl exec commands can allow attackers to operate undetected for extended periods, increasing the potential for significant damage. The financial impact can range from tens of thousands to millions of dollars, depending on the severity of the breach and the value of the compromised data.

Recommendation

Deploy the “Kubernetes Pod Exec Potential Reverse Shell” Sigma rule to your SIEM and tune for your environment to detect malicious kubectl exec commands.
Enable Kubernetes audit logging to capture kubectl exec events and ensure that the audit logs are ingested into your SIEM.
Implement network policies to restrict outbound connections from pods, limiting the ability of attackers to establish reverse shells.
Monitor Kubernetes audit logs for suspicious user activity, such as unusual API calls or access to sensitive resources.
Regularly review and update RBAC (Role-Based Access Control) policies to minimize the privileges assigned to users and service accounts, reducing the attack surface.
Implement the provided regex pattern in the Sigma rule within your existing detection logic, ensuring adequate coverage of reverse shell attempts.

Kubernetes Pod Exec Cloud Instance Metadata Access

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

This alert focuses on detecting Kubernetes pod exec sessions that attempt to access cloud instance metadata endpoints. The activity is flagged when the decoded command line of a pod exec session contains references to cloud instance metadata services across AWS, GCP, and Azure. Attackers may exploit this to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor. This is a high-risk behavior because it can expose short-lived cloud credentials to code running inside a container, particularly concerning in multi-tenant and regulated environments. This detection classifies the cloud target and whether the command indicates credential theft or reconnaissance.

Attack Chain

Attacker gains initial access to a Kubernetes cluster.
Attacker identifies a vulnerable pod within the cluster.
The attacker uses kubectl exec to gain shell access to the pod.
Inside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.
The command, often using curl or wget, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.
The IMDS responds with the requested data, which may include credentials or configuration details.
The attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.
Attacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.

Impact

Compromised credentials can lead to unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. A successful attack could impact multiple organizations sharing the same Kubernetes cluster. The impact could include financial losses, reputational damage, and regulatory fines, depending on the type of data compromised and the extent of the breach.

Recommendation

Deploy the Sigma rule Kubernetes Pod Exec IMDS Access to detect suspicious command-line activity within Kubernetes pods.
Block access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.
Regularly review and tighten RBAC permissions related to pods/exec to limit the ability of attackers to gain shell access.
Monitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.
Implement workload identity solutions to avoid the need to expose instance metadata to pods.
Baseline approved images and tune exclusions narrowly to avoid false positives.

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.

Execution via Windows Subsystem for Linux

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

This rule detects attempts to execute programs on the host from the Windows Subsystem for Linux (WSL). Adversaries may enable and use WSL for Linux to avoid detection by executing malicious scripts or binaries, bypassing traditional Windows security mechanisms. The rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion. This detection focuses on identifying when a process is spawned by wsl.exe or wslhost.exe and is not within a known good path. 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

An attacker gains initial access to a Windows system.
The attacker enables the Windows Subsystem for Linux (WSL).
The attacker transfers or creates malicious scripts or binaries within the WSL environment.
The attacker executes the malicious script or binary using a Linux shell within WSL, such as bash.
The WSL environment interacts with the Windows host to execute commands or access resources.
The executed commands perform malicious actions, such as data exfiltration or lateral movement.
The attacker leverages WSL’s integration with Windows to evade traditional Windows-based security measures.
The final objective is to compromise the system or network while remaining undetected.

Impact

Successful exploitation allows adversaries to execute malicious code while potentially evading traditional Windows-based security measures. This can lead to system compromise, data theft, or further propagation of malware within the network. The rule’s medium severity reflects the potential for significant impact, necessitating prompt investigation and response.

Recommendation

Deploy the Sigma rule Execution via Windows Subsystem for Linux to your SIEM to detect potential malicious activity originating from WSL.
Enable Sysmon process creation logging (Event ID 1) or Windows process creation logs to provide the necessary data for the Sigma rule to function.
Investigate any alerts generated by the Sigma rule, focusing on identifying the executed process, parent process (wsl.exe or wslhost.exe), and associated user account.
Correlate alerts with other security events from Microsoft Defender XDR, SentinelOne, or Crowdstrike to identify related suspicious activities or patterns.
Implement exceptions for known administrative scripts or development tools that are frequently executed via WSL to reduce false positives, as outlined in the rule’s analysis.
Monitor the WSL configuration and installed Linux distributions on affected systems to identify unauthorized changes or installations.

Execution via Local SxS Shared Module

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

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

Attack Chain

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

Impact

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

Recommendation

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

Execution of a Downloaded Windows Script

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

This detection rule identifies a common attack vector where adversaries download and execute malicious scripts on Windows systems. The rule focuses on detecting scripts (e.g., .js, .vbs, .ps1, .msi) that originate from internet sources (identified by the presence of file.origin_url or file.origin_referrer_url ) and are subsequently executed using scripting utilities. The rule specifically looks for file creations by web browsers and archive utilities (chrome.exe, msedge.exe, winrar.exe, 7zFM.exe, etc.) followed by execution of script interpreters (wscript.exe, cscript.exe, powershell.exe, mshta.exe, msiexec.exe) with command-line arguments referencing the downloaded script. This activity is often indicative of malicious intent, as legitimate scripts are typically sourced from trusted internal repositories or local file systems, and not directly downloaded and executed. The rule aims to detect suspicious parent-child process relationships (e.g., browser spawning a script interpreter) and identify potential initial access or execution attempts. The rule requires Elastic Defend and a minimum Elastic Stack version of 9.2.0.

Attack Chain

A user browses to a malicious website or opens a compromised email containing a link.
The user clicks the link, which initiates a download of a malicious script file (e.g., .js, .vbs, .ps1, .msi) via a web browser (chrome.exe, msedge.exe).
The browser saves the downloaded script file to the user’s Downloads folder.
The user, either intentionally or through social engineering, executes the downloaded script.
Windows executes the script using a scripting utility like wscript.exe, cscript.exe, powershell.exe, mshta.exe, or msiexec.exe.
The scripting utility executes the malicious code within the script, potentially establishing persistence, downloading additional payloads, or performing reconnaissance.
The script may attempt to elevate privileges or bypass security controls to gain further access to the system.
The attacker achieves their objective, such as deploying ransomware, stealing sensitive data, or establishing a remote access backdoor.

Impact

A successful attack can lead to a variety of negative outcomes, including malware infection, data theft, and system compromise. If the downloaded script is malicious, it can allow attackers to gain a foothold on the system, escalate privileges, and move laterally within the network. This can result in significant financial losses, reputational damage, and disruption of business operations. The number of victims and affected sectors can vary depending on the scale and scope of the attack.

Recommendation

Deploy the Elastic Defend integration to collect necessary event data, as described in the setup instructions.
Deploy the Sigma rule “Execution of a Downloaded Windows Script” to your SIEM and tune for your environment to detect the execution of downloaded scripts.
Enable Sysmon process creation logging and file creation events to provide the necessary data for the Sigma rules to function correctly.
Implement application whitelisting to restrict the execution of unauthorized scripts and scripting utilities to reduce the risk of similar threats in the future, as mentioned in the “Response and remediation” section.
Block known malicious domains and URLs identified in related threat intelligence feeds to prevent users from downloading malicious scripts in the first place.
Educate users about the dangers of downloading and executing untrusted scripts from the internet, as this is a common initial access vector.

Executable or Script Creation in Temporary Paths

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

This threat brief focuses on the creation of executable files or scripts within temporary directories on Windows systems, a common tactic used by adversaries to bypass security controls and establish persistence. This behavior is often indicative of malicious activity, such as malware installation, privilege escalation, or unauthorized code execution. The observed activity involves writing files with extensions like .exe, .dll, .ps1, and .bat into common temporary locations like \Windows\Temp\ or \AppData\Local\Temp\. This technique allows attackers to hide malicious files among legitimate temporary files, making detection more challenging. References to campaigns like Volt Typhoon, and ransomware families like LockBit highlight the importance of detecting this behavior.

Attack Chain

The attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker drops a malicious executable or script onto the compromised system.
To evade detection, the malicious file is created in a temporary directory such as C:\Windows\Temp\ or C:\Users\\AppData\Local\Temp\.
The attacker uses a dropper or installer to write the malicious file (e.g., using cmd.exe, powershell.exe).
The attacker may rename the file to further disguise its purpose.
The attacker executes the malicious file, potentially leading to code execution, privilege escalation, or persistence.
The executed malware performs malicious actions, such as lateral movement, data exfiltration, or ransomware deployment.
The attacker maintains persistence on the system, ensuring continued access and control.

Impact

Successful exploitation can lead to unauthorized code execution, privilege escalation, and persistent access within the targeted environment. This can result in data theft, system compromise, or ransomware deployment. The references to campaigns like Volt Typhoon and ransomware families like LockBit highlight the potential for significant disruption and financial loss. Multiple analytic stories, such as AsyncRAT, DarkGate Malware, and Qakbot, highlight the prevalence of this technique across various threat actors.

Recommendation

Enable Sysmon EventID 11 (FileCreate) logging to monitor file creation events on endpoints.
Deploy the Sigma rule “Executable or Script Creation in Temp Path” to your SIEM and tune for your environment.
Investigate any file creation events in temporary directories involving executable or script file types (.exe, .dll, .ps1, .bat, etc.).
Review and filter events based on your organization’s normal activity to reduce false positives, as mentioned in the “known_false_positives” section of the source.
Monitor for processes spawned from temporary directories, using a process creation monitoring tool and correlate with other suspicious activities.

Exchange Mailbox Export via PowerShell

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

Attackers may target user email to collect sensitive information. The New-MailBoxExportRequest cmdlet is used to export the contents of a primary mailbox or archive to a .pst file. Note that this is done on a per-mailbox basis and this cmdlet is available only in on-premises Exchange. Attackers can abuse this functionality in preparation for exfiltrating contents, which is likely to contain sensitive and strategic data. This activity is typically performed using PowerShell or similar scripting tools and can be difficult to detect without specific monitoring in place. The activity may be part of a larger attack campaign targeting sensitive information.

Attack Chain

An attacker gains initial access to a compromised system with sufficient privileges to access Exchange PowerShell.
The attacker authenticates to the Exchange server using PowerShell.
The attacker uses the New-MailboxExportRequest cmdlet to initiate the export of a target mailbox to a .pst file. The command may include parameters to filter specific content.
The Exchange server processes the export request, creating a .pst file containing the mailbox data.
The attacker retrieves the exported .pst file from the designated file path.
The attacker may compress and archive the .pst file to reduce its size for exfiltration.
The attacker exfiltrates the .pst file to an external location controlled by the attacker.
The attacker analyzes the .pst file to extract sensitive information such as credentials, financial data, or intellectual property.

Impact

Successful exploitation allows the attacker to gain access to sensitive information contained within the exported mailboxes. This could lead to financial loss, reputational damage, or compromise of intellectual property. Depending on the scope of the export requests, multiple mailboxes may be compromised, impacting a large number of users. The impact is significant because email often contains highly sensitive business communications and data.

Recommendation

Enable Sysmon process creation logging to monitor PowerShell execution with command-line arguments (Data Source: Sysmon).
Implement the provided Sigma rule to detect the use of New-MailboxExportRequest cmdlet in PowerShell commands.
Review the privileges of users with the “Mailbox Import Export” privilege to ensure that the least privilege principle is being followed.
Monitor Windows Security Event Logs for PowerShell activity related to mailbox export requests (Data Source: Windows Security Event Logs).
Investigate any alerts generated by the Sigma rules to identify potential malicious activity.

Detection of Python Base64 Encoded Execution on Linux

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

Attackers are increasingly leveraging Python one-liners with base64 encoding on Linux systems to deliver and execute malicious payloads. This technique allows for effective obfuscation, making it harder for conventional security solutions to detect the true nature of the executed commands. The use of base64 within Python scripts executed directly from the command line is a red flag, as it is rarely observed in standard administrative tasks but is frequently used to hide malicious intent. Defenders must prioritize detecting this behavior to uncover potentially compromised systems and prevent further escalation. This activity has been observed in conjunction with fake AI websites used to deliver malware.

Attack Chain

An attacker gains initial access to a Linux system through an undisclosed method (e.g., exploiting a vulnerability or social engineering).
The attacker uploads or creates a script containing a base64-encoded payload.
The attacker uses a Python one-liner, invoking the python interpreter.
The Python script imports the base64 module.
The script decodes the base64-encoded payload using functions like b64decode, b32decode, or similar.
The decoded payload is executed using eval() or exec() within the same Python one-liner.
The executed payload establishes persistence, downloads further malware, or performs lateral movement.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation can lead to a full system compromise, data exfiltration, or the deployment of persistent backdoors. The obfuscation techniques make detection difficult, potentially allowing attackers to operate undetected for extended periods. While the specific number of victims and targeted sectors remain unknown, the technique’s effectiveness in evading security measures makes it a high-priority threat.

Recommendation

Deploy the Sigma rule “Detect Python Base64 One-Liners - Linux” to your SIEM to detect the execution of Python one-liners utilizing base64 decoding (logsource: process_creation/linux).
Investigate any process creation events matching the Sigma rule, focusing on the parent processes and executed commands to identify the source of the malicious activity.
Enable and monitor process creation logs on Linux systems to ensure visibility of command-line execution, which is essential for detecting this type of attack (logsource: process_creation/linux).
Implement application control policies to restrict the execution of unsigned or untrusted scripts, mitigating the risk of malicious payload execution after decoding.

AWS EC2 Stop, Start, and User Data Modification Correlation

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

This detection identifies a specific sequence of AWS EC2 API calls suggesting malicious intent. An adversary may update the userData attribute of an EC2 instance and then restart the instance to execute malicious scripts with elevated privileges (root on Linux, SYSTEM on Windows). The technique involves modifying instance attributes to inject malicious code or scripts, followed by stopping and starting the instance to trigger execution of the modified user data. This can lead to privilege escalation, persistence, or other malicious activities within the AWS environment. The detection focuses on the correlation of StopInstances, StartInstances, and ModifyInstanceAttribute events that reference userData within a 5-minute window. The rule groups these events by instance ID, username, account ID, source IP, and user agent, triggering an alert only when all three distinct API calls are observed within the same group. This aims to reduce false positives by requiring the complete sequence of actions associated with this technique.

Attack Chain

An attacker gains initial access to an AWS account with sufficient permissions to manage EC2 instances (e.g., via compromised credentials or an IAM role).
The attacker identifies a target EC2 instance.
The attacker uses the ModifyInstanceAttribute API call to update the userData attribute of the target instance, injecting malicious code or scripts.
The attacker uses the StopInstances API call to stop the target EC2 instance.
The attacker uses the StartInstances API call to start the target EC2 instance.
Upon instance start, the modified userData script executes with elevated privileges, potentially installing malware, establishing persistence, or performing other malicious actions.
The attacker may use the compromised instance to further explore the AWS environment, escalate privileges, or exfiltrate data.

Impact

Successful exploitation can lead to unauthorized code execution within the AWS environment. Attackers can gain elevated privileges on the compromised EC2 instance, potentially leading to full control of the instance and the ability to access sensitive data or resources within the AWS account. This can result in data breaches, service disruptions, and financial losses. The modification of user data allows for persistent malicious code execution each time the instance restarts.

Recommendation

Deploy the following Sigma rules to your SIEM to detect the described attack pattern, and tune them to your environment.
Review CloudTrail logs for ModifyInstanceAttribute events with userData to identify potentially malicious modifications.
Monitor EC2 instance state transitions (stop/start) in conjunction with user data modifications.
Implement least privilege IAM policies to restrict access to EC2 management APIs.
Use AWS Secrets Manager or Parameter Store to manage secrets instead of embedding them in userData.
Investigate any alerts generated by the Sigma rules and correlate them with other security events.

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

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

PowerShell Execution via Environment Variables

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

Attackers are increasingly leveraging PowerShell to execute malicious code embedded within environment variables. This method involves storing commands or encoded content in environment variables and then using Invoke-Expression (or its alias iex) to dynamically construct and execute code at runtime. This tactic is employed to evade traditional static analysis techniques and conceal the true intent of the executed code. Observed in malware loaders and stagers, including those associated with the VIP Keylogger campaign, this technique is a significant threat. Defenders should be aware of this trend and implement appropriate detection mechanisms. The focus is on identifying PowerShell scripts that combine environment variable access ($env:) with Invoke-Expression or its aliases, based on PowerShell Script Block Logging (Event ID 4104).

Attack Chain

The attacker gains initial access to the system, possibly through phishing or exploiting a software vulnerability.
PowerShell is invoked, either directly or indirectly, via a script or another process.
The attacker sets an environment variable containing malicious code or a command. This might involve using [Environment]::SetEnvironmentVariable.
A PowerShell script is executed that reads the content of the environment variable using $env:.
The content read from the environment variable is passed to Invoke-Expression or its alias iex.
Invoke-Expression dynamically executes the code, effectively bypassing static analysis.
The executed code downloads and executes a secondary payload, such as a keylogger or a remote access tool.
The attacker achieves their objective, such as stealing credentials or establishing persistent access.

Impact

Successful exploitation can lead to the execution of arbitrary code on the compromised system, allowing attackers to install malware, steal sensitive data, or establish a persistent foothold. The VIP Keylogger campaign, for example, demonstrates how this technique can be used to harvest user credentials. Due to the obfuscated nature of this attack, it is difficult to detect and remediate, often leading to extended dwell time for the attacker. Compromised systems can be further used as a launchpad for attacks against other systems within the network.

Recommendation

Enable PowerShell Script Block Logging (Event ID 4104) on all Windows systems to capture the de-obfuscated script blocks before execution.
Deploy the provided Sigma rules to your SIEM to detect PowerShell scripts that access environment variables and use Invoke-Expression or its aliases. Tune these rules to your environment to reduce false positives.
Investigate any alerts generated by these rules to determine if malicious activity is occurring.
Monitor PowerShell execution for suspicious environment variable access and dynamic code execution.
Implement application control to prevent the execution of unauthorized PowerShell scripts.
Review and harden PowerShell execution policies to limit the attack surface.

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.

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.

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.

Suspicious Svchost.exe Child Process: cmd.exe

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

The Service Host process (svchost.exe) is a legitimate Windows system process designed to host multiple Windows services. It is not intended to be used by non-Windows services or to spawn command interpreters directly. This detection focuses on identifying instances where cmd.exe is launched as a child process of svchost.exe. This activity is highly suspicious and may suggest that a malicious process is masquerading as svchost.exe or that an attacker has gained control and is attempting privilege escalation or lateral movement within the compromised system. The rule leverages process monitoring logs to identify this anomalous parent-child relationship. The original Elastic detection rule was published in 2020, and updated in May 2026.

Attack Chain

Initial Compromise: An attacker gains initial access to a Windows system through various means, such as exploiting a vulnerability or using stolen credentials.
Privilege Escalation: The attacker attempts to escalate privileges to gain higher-level access to the system.
Service Exploitation: The attacker exploits a service hosted by svchost.exe or injects malicious code into a service process.
Command Execution: The attacker leverages the compromised service to spawn cmd.exe as a child process of svchost.exe.
Reconnaissance: The attacker uses cmd.exe to perform reconnaissance activities, such as gathering system information or network configuration details.
Lateral Movement: The attacker uses cmd.exe to move laterally to other systems on the network, potentially using stolen credentials or exploiting vulnerabilities.
Persistence: The attacker establishes persistence on the compromised system to maintain access even after a reboot.
Data Exfiltration or System Damage: The attacker exfiltrates sensitive data from the compromised system or damages the system to disrupt operations.

Impact

A successful attack can lead to privilege escalation, lateral movement, data theft, or system compromise. The impact could range from minor data breaches to significant disruptions of business operations, depending on the attacker’s objectives and the extent of the compromise. Since svchost.exe is a critical system process, any compromise could result in widespread damage across the affected system.

Recommendation

Deploy the “Svchost spawning Cmd” Sigma rule to your SIEM to detect this suspicious parent-child relationship.
Enable process monitoring with command-line logging on Windows endpoints to provide the necessary data for the Sigma rule to function.
Investigate any alerts generated by the Sigma rule to determine the root cause and scope of the compromise.
Review and harden the security configuration of Windows services to prevent exploitation.
Enforce the principle of least privilege to limit the impact of a compromised service account.
Use threat intelligence platforms to identify and block known malicious indicators associated with svchost.exe exploits.

Suspicious Explorer Child Process via DCOM

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

Attackers frequently exploit Windows Explorer (explorer.exe) to execute malicious code due to its inherent trust within the operating system. This involves spawning child processes such as PowerShell, cmd.exe, or other scripting engines via Component Object Model (COM) and Distributed Component Object Model (DCOM). This technique enables attackers to bypass security controls, blending malicious activity with legitimate system processes. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats. This activity is frequently associated with initial access and execution of follow-on malware.

Attack Chain

The attack begins with an initial access vector such as spearphishing (T1566).
A user clicks a malicious link or opens an attachment, leading to code execution.
The initial payload exploits explorer.exe through DCOM using the -Embedding argument.
Explorer.exe spawns a child process such as powershell.exe, cmd.exe, or mshta.exe (T1059, T1218).
The spawned process executes malicious commands or scripts.
These commands might download or execute additional payloads.
The attacker achieves code execution, potentially gaining persistence on the system.
The ultimate objective is often lateral movement, data exfiltration, or deploying ransomware.

Impact

Successful exploitation allows attackers to execute arbitrary code within a trusted process context, bypassing application whitelisting and other security controls. This can lead to initial access, privilege escalation, and persistence within the compromised system. The compromise can remain undetected for extended periods due to the trusted nature of the parent process (explorer.exe), enabling attackers to perform reconnaissance, deploy malware, exfiltrate data, or disrupt services.

Recommendation

Enable process creation logging with command line details to detect suspicious explorer.exe child processes.
Deploy the Sigma rule “Suspicious Explorer Child Process - PowerShell” to identify instances of PowerShell spawned by explorer.exe with suspicious arguments.
Deploy the Sigma rule “Suspicious Explorer Child Process - Scripting Engines” to detect other scripting engines launched by explorer.exe.
Monitor process execution events for processes like powershell.exe, cmd.exe, cscript.exe, wscript.exe, mshta.exe, regsvr32.exe, and rundll32.exe with a parent process of explorer.exe and the argument “-Embedding” via process creation logs.
Implement application control policies to restrict execution of unsigned or untrusted scripts and executables.

Suspicious Command Prompt Network Connection

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

This detection identifies suspicious network connections initiated by the command prompt (cmd.exe) on Windows systems. The rule focuses on cmd.exe processes executed with specific arguments, such as those indicating script execution (e.g., *.bat, *.cmd), access to remote resources (e.g., URLs), or those spawned by Microsoft Office applications (Excel, Word, etc.). Attackers frequently abuse cmd.exe to download malicious payloads, execute commands, or establish command and control channels. This detection aims to identify such potentially malicious activity by correlating process creation events with subsequent network connections. The rule excludes common private and reserved IP address ranges to reduce false positives. The targeted systems are Windows endpoints where adversaries attempt to leverage cmd.exe for malicious purposes.

Attack Chain

A user opens a malicious document (e.g., Word, Excel) or executes a seemingly benign application.
The document or application contains a macro or script that initiates a cmd.exe process.
The cmd.exe process is launched with arguments indicating script execution (/c, /k) and referencing a remote resource (e.g., a URL) or a local batch file.
The cmd.exe process attempts to download a payload from a remote server using protocols like HTTP, HTTPS, or FTP.
The downloaded payload is saved to disk, often with a disguised filename.
The cmd.exe process executes the downloaded payload, initiating further malicious actions.
The malicious payload establishes a command and control (C2) channel with a remote server.
The attacker uses the C2 channel to send commands to the compromised system, potentially leading to data exfiltration or other malicious activities.

Impact

Successful exploitation can lead to the compromise of Windows endpoints, potentially enabling attackers to download and execute malicious payloads, establish command and control channels, and perform further malicious activities such as data theft, lateral movement, or ransomware deployment. While this detection has a low severity, it serves as an early warning sign of potential compromise and should be investigated promptly.

Recommendation

Enable process creation logging with command line arguments to capture the full context of cmd.exe executions.
Monitor network connections from cmd.exe processes, focusing on connections to external IP addresses, using a network monitoring solution.
Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious cmd.exe network connections.
Investigate any alerts generated by the Sigma rules, focusing on cmd.exe processes spawned by Office applications or those executing scripts from remote URLs.

Service Control Executed from Script Interpreters

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

This detection identifies instances where the Service Control utility (sc.exe) is executed from within a script interpreter, such as cmd.exe, PowerShell, or wscript.exe. Attackers may leverage this behavior to create, modify, or start Windows services, often with the intent to elevate privileges or establish persistence on a compromised system. The sc.exe is a legitimate Windows command-line tool used for managing services. Abusing this tool allows attackers to perform malicious actions under the guise of legitimate system administration. This detection is designed to identify anomalous use of sc.exe that deviates from typical administrative tasks, focusing on instances where it’s spawned from scripting environments often used for malicious activities. The rule specifically excludes service creations performed by the SYSTEM user.

Attack Chain

An attacker gains initial access to a Windows system via an exploit or compromised credentials.
The attacker executes a script interpreter (e.g., cmd.exe, powershell.exe).
Within the script interpreter, the attacker uses sc.exe to manage Windows services.
The sc.exe command is used with arguments such as “create”, “start”, “stop”, “delete”, or “config” to manipulate service configurations.
A new service is created or an existing service is modified to execute a malicious payload.
The malicious service is started, allowing the attacker to execute code with elevated privileges (SYSTEM).
The attacker achieves persistence by ensuring the malicious service automatically starts upon system reboot.
The attacker may use the created service to execute additional malicious commands or maintain remote access.

Impact

A successful attack could lead to complete system compromise with the attacker gaining SYSTEM level privileges. This can allow for lateral movement within the network, data exfiltration, or installation of persistent backdoors. While the frequency of this specific technique may be low, the potential impact is high due to the elevated privileges gained.

Recommendation

Deploy the Sigma rule Service Control Spawning via Script Interpreter to your SIEM to detect this specific behavior and tune it to your environment.
Monitor process creation events for sc.exe being executed by script interpreters like PowerShell or cmd.exe (as covered in the rule description).
Investigate any instances of sc.exe being used with the arguments “create”, “start”, “stop”, “delete”, or “config” from scripting environments to identify potentially malicious activity.
Ensure proper access controls are in place to limit the ability of users to create or modify services.

Kubeletctl Execution Inside Container Detected

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

This rule detects the execution of kubeletctl inside a container. Kubeletctl is a command-line tool that interacts with the Kubelet API directly, making the often undocumented API more accessible. Attackers may use it to enumerate the Kubelet API or other resources within the container, potentially indicating lateral movement within the pod. The detection is based on the “Defend for Containers” integration (version 9.3.0 and later) within the Elastic stack. This activity is significant because kubeletctl can expose pod and node details, enabling actions that facilitate discovery and lateral movement from a compromised container.

Attack Chain

An attacker gains initial access to a container, possibly through a vulnerability in the containerized application or a misconfigured Kubernetes environment.
The attacker executes kubeletctl inside the compromised container. This could be facilitated by the tool being present in the container image or downloaded post-compromise.
The attacker uses kubeletctl scan to discover Kubelet endpoints within the Kubernetes cluster.
The attacker leverages kubeletctl pods or kubeletctl runningpods to enumerate running pods and their details.
The attacker uses the discovered pod information to identify potential targets for lateral movement.
The attacker attempts to use kubeletctl exec or kubeletctl attach to gain access to other pods within the cluster.
The attacker attempts to port forward using kubeletctl portForward to establish connections to services running in other pods.
Upon successful lateral movement, the attacker performs further reconnaissance or deploys malicious payloads to achieve their objectives, such as data exfiltration or denial-of-service.

Impact

Successful execution of kubeletctl within a container can lead to the exposure of sensitive information about the Kubernetes cluster, including pod details and internal network configurations. This can enable attackers to move laterally within the cluster, potentially compromising other applications and data. The impact could range from data breaches and service disruptions to full cluster compromise depending on the attacker’s objectives and the scope of the compromised container’s access.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the execution of kubeletctl within containers based on process name and arguments.
Monitor container network activity for connections to node addresses on Kubelet ports (commonly 10250/10255) and investigate any suspicious patterns.
Implement network policies to restrict pod-to-node access to the Kubelet API.
Harden container images by removing unnecessary tools like kubeletctl and enforce least privilege principles.
Enable and review Kubernetes audit logs to identify the source of interactive sessions into containers, correlating with timestamps of kubeletctl execution.
Enforce Pod Security Standards to restrict privileged pods and limit node API exposure.

Xwizard COM Object Execution for Defense Evasion

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

The Windows Component Object Model (COM) facilitates communication between software components. Attackers can leverage Xwizard, a legitimate Windows system binary, to execute COM objects and bypass security measures. This technique allows adversaries to proxy the execution of malicious code through a trusted system utility, making detection more challenging. This activity has been observed since at least 2017, with potential links to PlugX malware variants. The scope of targeting is broad, as any Windows system with vulnerable COM configurations could be susceptible. Defenders should monitor Xwizard execution for suspicious arguments and deviations from expected file paths to identify potential misuse of COM objects.

Attack Chain

The attacker gains initial access via an unconfirmed method (e.g., phishing, exploit).
The attacker modifies the Windows Registry to create a malicious COM object.
The attacker invokes xwizard.exe with the RunWizard argument and a GUID referencing the malicious COM object.
xwizard.exe reads the COM object’s configuration from the registry.
xwizard.exe executes the code associated with the malicious COM object.
The malicious COM object performs unauthorized actions, such as downloading additional payloads or establishing command and control.
The attacker achieves persistence by ensuring the malicious COM object is executed on system startup or user login.
The attacker executes arbitrary code, potentially leading to data theft or system compromise.

Impact

Successful exploitation allows attackers to execute arbitrary code on compromised systems. This can lead to data theft, malware installation, or complete system compromise. The targeted sectors are broad, as any Windows system with vulnerable COM configurations is susceptible. While specific victim counts are unavailable, the widespread use of Windows makes this a potentially significant threat. If the attack succeeds, attackers can gain persistent access, escalate privileges, and move laterally within the network.

Recommendation

Monitor process execution events for instances of xwizard.exe with suspicious arguments like RunWizard and GUIDs using the “Execution of COM object via Xwizard” rule as a baseline.
Implement the Sigma rules provided to detect anomalous Xwizard executions and COM object abuse.
Audit and monitor registry modifications, specifically looking for COM object registrations using registry_set rules.
Ensure that endpoint detection and response (EDR) solutions are configured to detect and block suspicious process executions originating from xwizard.exe.
Enable Sysmon process creation logging (Event ID 1) and registry event logging (Event ID 12, 13, 14) for enhanced visibility, as mentioned in the setup guide.

Remote Execution of Windows Services via RPC

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

This detection rule identifies the remote execution of Windows services over Remote Procedure Call (RPC), a technique often employed for lateral movement within a network. The rule focuses on correlating network connections initiated by services.exe with subsequent child process creation events. While this activity can be a legitimate function of administrators using remote management tools, it also represents a potential attack vector. The rule aims to strike a balance between detecting malicious activity and minimizing false positives arising from routine administrative tasks. The detection logic is based on identifying network connections to services.exe followed by the creation of child processes that are not commonly associated with legitimate service management. The rule requires the use of Elastic Defend or Sysmon for adequate logging coverage.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker attempts to move laterally to other systems.
The attacker establishes a connection to the target system’s services.exe process over RPC using a high port (>= 49152).
The attacker uses the established RPC connection to create or start a new service on the remote system.
The services.exe process on the remote system spawns a child process related to the newly created or started service.
This new process executes the attacker’s payload, potentially granting further access or executing malicious commands.
The attacker leverages the newly executed service for persistent access or further lateral movement.

Impact

A successful attack could result in unauthorized access to sensitive data, disruption of critical services, or the deployment of ransomware. Lateral movement allows attackers to compromise multiple systems within the network, escalating the impact of the initial breach. Due to the nature of the technique, it can be challenging to distinguish between legitimate administrative activity and malicious actions, leading to delayed detection and increased dwell time for attackers.

Recommendation

Deploy the provided Sigma rules to your SIEM and tune the filters for known-good executables in your environment to reduce false positives.
Enable Sysmon process-creation (Event ID 1) and network connection (Event ID 3) logging to ensure the required data for the Sigma rules is available.
Investigate any alerts triggered by these rules, focusing on the parent process and network connection details associated with the spawned child process.
Consider excluding known remote management tools from triggering the detection by adding exceptions based on process.executable or process.args in the Sigma rules.
Monitor the network for unusual RPC activity, especially connections to services.exe from unexpected source IPs.

Execution via GitHub Actions Runner

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

This threat focuses on the exploitation of GitHub Actions runners by malicious actors. By gaining the ability to modify or trigger workflows in a linked GitHub repository, attackers can execute arbitrary commands on the runner host. The attack leverages the Runner.Worker process or shell interpreters launched via runner entrypoint scripts. Successful exploitation can lead to malicious workflow activity, including code execution, reconnaissance, credential harvesting, and network exfiltration. This presents a significant risk, particularly for organizations relying on self-hosted runners, as it allows attackers to potentially compromise the underlying infrastructure and sensitive data. The Elastic detection rule aims to identify such malicious activity.

Attack Chain

An attacker gains unauthorized access to a GitHub repository linked to a self-hosted runner.
The attacker modifies an existing workflow or creates a new one to inject malicious commands.
The compromised workflow is triggered, initiating the Runner.Worker process on the runner host.
The Runner.Worker process executes a shell interpreter (e.g., bash, sh, zsh) via an entrypoint script.
The shell interpreter executes malicious commands specified in the compromised workflow, such as downloading a payload using curl or wget.
The downloaded payload is executed, establishing a reverse shell connection to an attacker-controlled server using nc or socat.
The attacker performs reconnaissance, credential harvesting, or lateral movement within the runner host and connected network.
Sensitive data is exfiltrated from the compromised runner host to the attacker’s infrastructure.

Impact

A successful attack can lead to the complete compromise of the self-hosted runner environment. This could result in the theft of sensitive source code, credentials, and other proprietary information. The attack can also be used as a stepping stone for further attacks on the organization’s internal network and infrastructure. Affected sectors include software development, DevOps, and any organization using GitHub Actions with self-hosted runners.

Recommendation

Deploy the Sigma rule Execution via GitHub Actions Runner to your SIEM to detect suspicious commands executed by the GitHub Actions Runner.
Monitor process creation events for commands like curl, wget, nc, socat, powershell.exe, cmd.exe, bash, and ssh spawned by Runner.Worker or shell interpreters with entrypoint.sh in their command line (see Sigma rule).
Implement strict access control policies for GitHub repositories and workflows to prevent unauthorized modifications.
Regularly review and audit GitHub Actions workflows for suspicious or unexpected commands.
Isolate self-hosted runners in a segmented network to limit the impact of a potential compromise.
Enable Sysmon process-creation logging to provide detailed process execution information for effective detection.