Lateral Movement — CraftedSignal Threat Feed

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.

Potential WSUS Abuse for Lateral Movement via PsExec

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

This detection identifies potential abuse of Windows Server Update Services (WSUS) for lateral movement by executing PsExec. WSUS is designed to manage updates for Microsoft products, ensuring only signed binaries are executed. Attackers can exploit this by using WSUS to distribute and execute Microsoft-signed tools like PsExec, which can then be used to move laterally within the network. This technique leverages the trust relationship inherent in WSUS to bypass security controls. The rule focuses on detecting suspicious processes initiated by wuauclt.exe (the Windows Update client) executing PsExec from the SoftwareDistribution Download Install directories. Defenders should monitor WSUS activity and PsExec executions to detect and respond to this potential threat.

Attack Chain

The attacker compromises a system within the target network.
The attacker gains control over the WSUS server or performs a man-in-the-middle attack to spoof WSUS.
The attacker uses the compromised WSUS server to approve a malicious update containing PsExec.
The WSUS client (wuauclt.exe) on targeted machines downloads the “approved” update from the WSUS server, placing PsExec in the C:\Windows\SoftwareDistribution\Download\Install\ directory.
The WSUS client executes PsExec.
PsExec is used to execute commands or transfer files to other systems on the network.
The attacker uses the compromised systems to gather credentials or move laterally to other high-value targets.
The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation allows attackers to achieve lateral movement within the network, leading to the compromise of additional systems and sensitive data. This can result in data breaches, financial loss, and reputational damage. The scope of impact depends on the level of access achieved by the attacker and the value of the compromised systems.

Recommendation

Deploy the Sigma rule WSUS PsExec Execution to detect potential WSUS abuse involving PsExec execution.
Enable Sysmon process creation logging (Event ID 1) to gain visibility into process executions, as referenced in the setup instructions.
Implement enhanced monitoring and logging for WSUS activities to detect unauthorized changes or updates.
Investigate and remove any unauthorized binaries found in the C:\Windows\SoftwareDistribution\Download\Install\ directory.
Review and restrict the accounts authorized to manage WSUS to prevent unauthorized modifications.

Potential Pass-the-Hash (PtH) Attempt Detection

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

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

Attack Chain

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

Impact

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

Recommendation

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

Local Account TokenFilter Policy Modification for Defense Evasion and Lateral Movement

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

The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled (set to 1), allows remote connections from local members of the Administrators group to be granted full high-integrity tokens during negotiation. This bypasses User Account Control (UAC) restrictions, allowing for elevated privileges remotely. Attackers may modify this registry setting to facilitate lateral movement within a network. This rule detects modifications to this specific registry setting, alerting on potential unauthorized changes that could lead to defense evasion and privilege escalation. The modification of this policy has been observed being leveraged in conjunction with pass-the-hash attacks.

Attack Chain

The attacker gains initial access to a system through an exploit, such as phishing or exploiting a vulnerability.
The attacker obtains local administrator credentials on the compromised system.
The attacker modifies the LocalAccountTokenFilterPolicy registry key to a value of 1. This is done to allow remote connections from local administrator accounts to receive high-integrity tokens. The registry key is typically located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
The attacker leverages a “pass the hash” attack (T1550.002) using the compromised local administrator credentials.
The attacker attempts to move laterally to other systems within the network using the “pass the hash” technique and the modified LocalAccountTokenFilterPolicy.
Due to the LocalAccountTokenFilterPolicy being enabled, the remote connection from the local administrator account receives a full high-integrity token.
The attacker bypasses UAC on the remote system, gaining elevated privileges.
The attacker performs malicious activities on the remote system, such as data exfiltration or deploying ransomware.

Impact

Successful modification of the LocalAccountTokenFilterPolicy allows attackers to bypass User Account Control (UAC) and gain elevated privileges on remote systems, potentially leading to unauthorized access to sensitive data, lateral movement across the network, and the deployment of ransomware. The overall impact can include data breaches, financial loss, and reputational damage.

Recommendation

Deploy the Sigma rule Local Account TokenFilter Policy Enabled to your SIEM and tune for your environment to detect unauthorized modifications to the LocalAccountTokenFilterPolicy registry key.
Enable Sysmon registry event logging to capture modifications to the registry, which is required for the Local Account TokenFilter Policy Enabled Sigma rule.
Review the processes excluded in the rule query and ensure they are legitimate and necessary to prevent false positives.
Monitor registry events for changes to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy path, specifically looking for changes to the value data.

UNC6692 Combines Social Engineering, Malware, and Cloud Abuse

hello@craftedsignal.io — Tue, 28 Apr 2026 14:00:00 +0000

UNC6692 is a newly tracked, financially motivated threat group that employs a multi-stage intrusion campaign combining persistent social engineering and custom modular malware. The actor begins by flooding a target’s email inbox before contacting them via Microsoft Teams, posing as help desk personnel to resolve the issue. This leads to a phishing attack where victims are tricked into downloading and executing malicious payloads. UNC6692 abuses legitimate cloud infrastructure, specifically AWS S3 buckets, for payload delivery, command and control (C2), and data exfiltration, allowing them to bypass traditional network reputation filters. The group’s operations are focused on gaining access and stealing credentials for further actions, ultimately aiming to exfiltrate data of interest from compromised systems. The initial campaign was observed in late December.

Attack Chain

The attacker floods a target’s email inbox to create a sense of urgency.
The attacker contacts the target via Microsoft Teams, impersonating help desk personnel.
The attacker sends a phishing link via Teams, promising a local patch to fix the email spamming issue.
The target clicks the link, which downloads a renamed AutoHotKey binary and an AutoHotkey script from a threat actor-controlled AWS S3 bucket.
Execution of the AutoHotKey binary automatically runs the script, initiating reconnaissance commands and installing the SNOWBELT malicious Chromium browser extension.
SNOWBELT facilitates the download of additional tools, including the Snowglaze Python tunneler, the Snowbasin Python bindshell (used as a persistent backdoor), additional AutoHotkey scripts, and a portable Python executable with required libraries.
The attacker uses a Python script to scan the local network for ports 135, 445, and 3389 and enumerate local administrator accounts.
The attacker uses a local administrator account to initiate an RDP session via Snowglaze from the compromised system to a backup server, then dumps LSASS process memory and uses pass-the-hash to move laterally to the domain controller.

Impact

The UNC6692 attack leads to the compromise of targeted systems, credential theft, and potential data exfiltration. If successful, the attacker gains control over the domain controller, allowing them to access sensitive information and potentially cause significant damage to the organization. The abuse of AWS S3 buckets allows the threat actor to blend in with legitimate cloud traffic, making detection more difficult. The financial motivation suggests that stolen credentials and data could be used for further malicious activities, such as ransomware attacks or sale on the dark web.

Recommendation

Monitor for AutoHotKey execution, especially when associated with downloads from unusual locations like AWS S3 buckets, to detect initial payload execution (see Sigma rule below).
Implement network monitoring to detect unusual RDP connections initiated from compromised systems to internal servers, as this is a key lateral movement technique used by UNC6692 (see Sigma rule below).
Monitor for the installation of new Chromium extensions, especially those not distributed through the Chrome Web Store, as this is how the SNOWBELT malware is deployed.
Monitor for the use of Python scripts to scan the local network for open ports (135, 445, 3389) and enumerate local administrator accounts.
Investigate any Microsoft Teams messages delivering links that promise to fix technical problems, as this is the initial social engineering tactic used by UNC6692.

AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure

hello@craftedsignal.io — Wed, 22 Apr 2026 17:45:55 +0000

This threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the github-actions user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.

Attack Chain

An attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.
The attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.
The attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.
The attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker’s source IP address and ASN.
The attacker performs reconnaissance activities, such as calling sts:GetCallerIdentity, ListBuckets, DescribeInstances, or ListUsers, to understand the AWS environment and identify potential targets.
The attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.
The attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.

Impact

Successful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim’s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.

Recommendation

Deploy the Sigma rule “AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure” to your SIEM and tune for your environment to detect suspicious usage patterns.
Rotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.
Implement OIDC-based authentication (aws-actions/configure-aws-credentials with role-to-assume) instead of long-lived access keys as mentioned in the rule documentation.
If using OIDC, add IP condition policies to the IAM role trust policy to restrict AssumeRoleWithWebIdentity to known GitHub runner IP ranges, based on the information in the rule documentation.

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.

BRICKSTORM Malware Targeting VMware vSphere Environments

hello@craftedsignal.io — Thu, 02 Apr 2026 13:55:05 +0000

The BRICKSTORM campaign targets VMware vSphere environments, with a focus on the vCenter Server Appliance (VCSA) and ESXi hypervisors. This campaign, building on previous BRICKSTORM research, highlights the increasing threats targeting virtualized infrastructure. By gaining persistence at the virtualization layer, attackers bypass traditional security measures, such as endpoint detection and response (EDR) agents, which are often ineffective in these environments. The attackers exploit weak security architectures, identity design flaws, lack of host-based configuration enforcement, and limited visibility within the virtualization layer. This allows them to maintain long-term persistence and gain administrative control over the entire vSphere environment, making the VCSA a prime target due to its centralized control. This activity is not due to vendor vulnerabilities but rather misconfigurations and security gaps. vSphere 7 reached End of Life (EoL) in October 2025, so organizations using this version are at increased risk.

Attack Chain

Initial Access: The attacker gains initial access to the vSphere environment, potentially through compromised credentials or vulnerabilities in externally facing services.
VCSA Compromise: The attacker targets the vCenter Server Appliance (VCSA) to gain centralized control over the vSphere environment.
Privilege Escalation: The attacker escalates privileges within the VCSA to gain root or administrative access to the underlying Photon Linux OS.
Persistence: The attacker establishes persistence by modifying system files or creating malicious services that survive reboots. This may involve writing scripts to /etc/rc.local.d or modifying startup files.
Lateral Movement: The attacker uses the compromised VCSA to move laterally to other ESXi hosts and virtual machines within the environment.
Data Access: The attacker accesses the underlying storage (VMDKs) of virtual machines, bypassing operating system permissions and traditional file system security, to exfiltrate sensitive data.
Control of ESXi Hosts: The attacker resets root credentials on any managed ESXi host, providing full control of the hypervisor.
Impact: The attacker can power off, delete, or reconfigure any virtual machine, encrypt datastores, disable virtual networks, and exfiltrate data. The ultimate objective could be data theft, disruption of services, or ransomware deployment.

Impact

A successful BRICKSTORM attack can have severe consequences, including complete compromise of the vSphere environment. This can lead to data exfiltration of Tier-0 assets, disruption of critical services (such as domain controllers), and potential ransomware deployment across all virtual machines. Organizations may face significant financial losses, reputational damage, and legal liabilities. The lack of command-line logging on the Photon OS shell further hinders incident response efforts.

Recommendation

Harden the vCenter Server Appliance (VCSA) by implementing the security configurations recommended in the Mandiant vCenter Hardening Script (reference: vCenter Hardening Script link in Overview).
Implement logging and monitoring for the Photon OS shell to detect unauthorized access and command execution (reference: Phase 4 in Content).
Upgrade to a supported version of vSphere to receive critical security patches (reference: vSphere 7 End of Life in Content).
Enable Secure Boot, strictly firewall management interfaces, and disable shell access on ESXi hosts and the VCSA (reference: Technical Hardening in Content).
Deploy the Sigma rule to detect modifications to startup files for persistence on Photon OS (reference: Sigma rule: “Detect Startup File Modification in Photon OS”).

SSH Authorized Key File Modification Inside a Container

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

This detection focuses on identifying malicious actors who modify SSH authorized_keys files inside containers to gain unauthorized access. SSH authorized keys are used for public key authentication, and modification of these files allows attackers to maintain persistence or move laterally within a containerized environment. The rule specifically looks for file creation and modification events of authorized_keys files within Linux-based containers. Introduced as part of the Defend for Containers integration in Elastic Stack version 9.3.0, this detection is crucial because unauthorized SSH access can lead to significant compromise within cloud environments and containerized workloads. Defenders need to be aware of unexpected SSH key modifications as indicators of compromise inside containerized environments.

Attack Chain

An attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.
The attacker executes commands within the container to locate the SSH authorized_keys file (typically located at /home//.ssh/authorized_keys or /root/.ssh/authorized_keys).
The attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like echo "ssh-rsa AAAAB3Nz..." >> /root/.ssh/authorized_keys.
The attacker uses the newly added SSH key to authenticate and log into the container without needing a password.
The attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.
The attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.

Impact

Successful modification of the authorized_keys file enables persistent, unauthorized SSH access to the compromised container. This can lead to lateral movement within the container environment, privilege escalation, data exfiltration, or further attacks on other systems. The rule aims to detect these modifications early, preventing significant damage. While the number of specific victims isn’t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: SSH Authorized Key File Activity).
Enable Elastic Defend for Containers integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule’s description (rule: SSH Authorized Key File Activity).
Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.
Create exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.

Stealthy WMI Lateral Movement via StealthyWMIExec.py

hello@craftedsignal.io — Mon, 16 Mar 2026 19:03:04 +0000

The information describes a lateral movement technique leveraging Windows Management Instrumentation (WMI) using a tool named StealthyWMIExec.py. This tool aims to provide a “stealthy” approach to executing commands on remote systems. The original post on Reddit’s blueteamsec forum, dating back to March 2026, discusses a method for achieving lateral movement while potentially bypassing traditional security monitoring that focuses on standard command execution patterns. Defenders should consider that adversaries might try to use WMI for command execution to blend in with legitimate activity and evade detection.

Attack Chain

Attacker gains initial access to a system within the target network.
Attacker uses valid credentials or exploits a vulnerability to authenticate to a remote host.
Attacker uses the StealthyWMIExec.py script (or similar WMI-based execution tool).
The script establishes a WMI connection to the target machine.
The script executes commands on the remote host using WMI’s Win32_Process class.
The output of the executed command is retrieved via WMI.
The attacker uses the information obtained to further compromise the network or achieve other objectives.

Impact

Successful exploitation via WMI-based lateral movement can lead to the compromise of multiple systems within a network. This can lead to data exfiltration, ransomware deployment, or other malicious activities, depending on the attacker’s objectives. The use of “stealthy” techniques may allow attackers to remain undetected for longer periods, increasing the potential damage.

Recommendation

Monitor WMI event logs (Event ID 5861, 5857, 5858, 5859) for suspicious WMI activity indicative of lateral movement.
Implement the Sigma rules provided to detect unusual WMI process creation and script execution.
Enable and review process creation logs (Sysmon Event ID 1) with command-line arguments to identify suspicious WMI activity.
Restrict WMI access to authorized users and systems only to limit the attack surface for this technique.

AWS STS Role Assumption by User

hello@craftedsignal.io — Wed, 04 Mar 2026 18:01:49 +0000

This detection rule identifies when an IAM user assumes a role in AWS Security Token Service (STS) within an AWS environment. The AWS Security Token Service (STS) allows users to request temporary, limited-privilege credentials for accessing AWS resources. While legitimate role assumption is common for authorized access, adversaries can abuse this mechanism to escalate privileges or move laterally within a compromised AWS account. This behavior is detected by monitoring AWS CloudTrail logs for AssumeRole events from IAM users. The rule focuses on identifying potentially malicious role assumptions by correlating the user identity, assumed role, and source information.

Attack Chain

An attacker gains initial access to an AWS account as an IAM user, potentially through compromised credentials or an exposed access key.
The attacker enumerates available IAM roles within the AWS environment to identify roles with elevated privileges or access to sensitive resources.
The attacker calls the AssumeRole API in AWS STS, requesting temporary credentials for the target role, using a roleSessionName for context.
The STS service validates the request and, if authorized, issues temporary credentials consisting of an accessKeyId, secretAccessKey, and sessionToken.
The attacker configures their AWS CLI or SDK with the temporary credentials obtained from the STS service.
The attacker uses the temporary credentials to access AWS resources and perform actions permitted by the assumed role, such as modifying security groups, accessing S3 buckets, or launching EC2 instances.
The attacker may attempt to further escalate privileges by assuming additional roles or creating new IAM users with administrative privileges.

Impact

A successful role assumption can grant an attacker access to sensitive data, allow them to disrupt critical services, or provide a foothold for further attacks within the AWS environment. While this rule has a low severity, a high volume of alerts should be reviewed as it could indicate ongoing lateral movement and privilege escalation. The impact of a successful attack can range from data breaches and service disruptions to complete compromise of the AWS environment.

Recommendation

Deploy the Sigma rule provided below to your SIEM and tune for your environment to detect suspicious role assumptions.
Investigate any alerts generated by the rule by reviewing the associated CloudTrail logs, specifically the aws.cloudtrail.user_identity.arn and aws.cloudtrail.resources.arn fields.
Implement additional monitoring for high-risk roles with elevated permissions, and create exceptions for trusted patterns.
Regularly review IAM policies and roles to minimize the risk of privilege escalation.
Refer to the AWS STS documentation for more details on managing and securing AWS STS in your environment.

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…

Bitbucket Global SSH Settings Changed

hello@craftedsignal.io — Fri, 01 Nov 2024 12:00:00 +0000

This brief focuses on the detection of unauthorized changes to Bitbucket’s global SSH settings. While the specific actor remains unknown, the modification of these settings is a significant security concern. The activity is detected via Bitbucket audit logs. Modification of global SSH settings can allow attackers to gain unauthorized access to repositories, potentially leading to code compromise, data breaches, or further lateral movement within the network. This activity is particularly important for organizations relying on Bitbucket for source code management and secure development workflows. The audit logs are the primary source of information, specifically focusing on events categorized as ‘Global administration’ with the action ‘SSH settings changed’.

Attack Chain

The attacker gains initial access to a Bitbucket account with administrative privileges, possibly through credential compromise or exploiting a vulnerability.
The attacker authenticates to the Bitbucket web interface.
The attacker navigates to the global SSH settings configuration page within the Bitbucket administration panel.
The attacker modifies global SSH settings, such as adding a new public key or changing authentication requirements.
Bitbucket logs the ‘SSH settings changed’ event in the audit logs under the ‘Global administration’ category.
The attacker leverages the modified SSH settings to clone repositories or push malicious code.
The attacker uses compromised code or data to move laterally within the organization’s network, targeting other systems and resources.

Impact

Successful modification of Bitbucket global SSH settings can allow unauthorized access to all repositories within the Bitbucket instance. This can lead to code theft, injection of malicious code, and data breaches. The impact may extend beyond the Bitbucket environment if the compromised code is deployed to production systems or used in other development processes. Organizations using Bitbucket for critical projects are at higher risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to Bitbucket global SSH settings in the audit logs.
Investigate any detected instances of “SSH settings changed” in the Bitbucket audit logs to determine the legitimacy of the changes.
Enforce multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to mitigate credential compromise as an initial access vector.
Review Bitbucket’s audit log configuration to ensure the “Advance” log level is enabled to capture the necessary audit events.

OpenCanary HTTPPROXY Login Attempt Detection

hello@craftedsignal.io — Sat, 26 Oct 2024 18:22:34 +0000

This threat brief focuses on detecting malicious attempts to use an OpenCanary node as an HTTP proxy. OpenCanary is a low-interaction honeypot designed to detect intruders on a network. An attacker attempting to use an OpenCanary node as an HTTP proxy is a strong indicator of reconnaissance or lateral movement, as they are attempting to route their traffic through the honeypot. This activity is logged by OpenCanary and can be detected with appropriate monitoring. The default configuration of OpenCanary includes an HTTPPROXY service that listens for proxy requests. Defenders should monitor OpenCanary logs for event ID 7001, which indicates an attempted HTTP proxy login.

Attack Chain

Attacker gains initial access to a network (e.g., through phishing or exploiting a vulnerability).
Attacker performs network reconnaissance to identify potential targets, including the OpenCanary node.
Attacker attempts to configure their system or tools to use the OpenCanary node as an HTTP proxy.
The attacker sends HTTP requests through the configured proxy, attempting to reach other systems on the network.
OpenCanary logs the attempted proxy connection with event ID 7001.
The defender detects the suspicious HTTP proxy attempt in the OpenCanary logs.

Impact

A successful HTTP proxy attempt indicates that an attacker is actively exploring the network and attempting to move laterally. This could lead to further compromise of sensitive systems and data exfiltration. While the OpenCanary node itself is a honeypot and not a production asset, the detection of proxy attempts signals a breach and ongoing malicious activity within the network.

Recommendation

Deploy the provided Sigma rule OpenCanary HTTPPROXY Login Attempt to your SIEM and tune for your environment to detect unauthorized proxy attempts on OpenCanary nodes.
Investigate any alerts generated by the Sigma rule to determine the source and target of the attempted proxy connection.
Review OpenCanary configuration to ensure that the HTTPPROXY service is properly configured and secured.
Implement network segmentation to limit the impact of potential lateral movement by attackers.

Unusual Remote File Size Indicating Lateral Movement

hello@craftedsignal.io — Tue, 30 Apr 2024 10:00:00 +0000

This detection leverages machine learning to identify unusual remote file sizes, a tactic often used during lateral movement. After gaining initial access, adversaries frequently aim to locate and exfiltrate valuable data. To avoid raising alarms with numerous small transfers, they may consolidate data into a single large file. This rule, built upon the Elastic Lateral Movement Detection integration, specifically uses the lmd_high_file_size_remote_file_transfer_ea machine learning job. The integration requires the host.ip field to be populated and Elastic Defend to be properly configured. This detection is critical for organizations seeking to identify and prevent data exfiltration attempts early in the attack lifecycle. The integration assets must be installed and file and Windows RDP process events collected by Elastic Defend.

Attack Chain

Initial Access: An attacker gains access to a host within the network, potentially through compromised credentials or exploitation of a vulnerability.
Discovery: The attacker performs reconnaissance to identify valuable data stores, network shares, and potential exfiltration targets.
Collection: The attacker gathers sensitive data from various sources within the compromised network. This data could include documents, databases, or other confidential information.
Data Consolidation: To avoid detection, the attacker bundles the collected data into a single, large file. This could involve archiving, compression, or other methods of aggregation.
Lateral Tool Transfer: The attacker uses remote services or tools to transfer the large file to a remote host within the network (T1570).
Exfiltration Preparation: The attacker stages the large file on the remote host, preparing it for exfiltration outside the network.
Exfiltration: The attacker initiates the transfer of the large file from the compromised network to an external destination, potentially using protocols like RDP.
Cleanup: The attacker attempts to remove traces of the activity, such as deleting temporary files or logs, to avoid detection.

Impact

A successful attack can lead to the exfiltration of sensitive data, potentially resulting in financial loss, reputational damage, and legal liabilities. The detection of unusual remote file sizes can help organizations identify and prevent data exfiltration attempts before they cause significant harm. Depending on the sensitivity of the exfiltrated data, the impact could range from minor inconvenience to a major security breach affecting thousands of individuals or customers.

Recommendation

Ensure the host.ip field is populated as required by the rule. For Elastic Defend versions 8.18 and above, verify that host IP collection is enabled following the provided helper guide.
Install the Lateral Movement Detection integration assets, including the lmd_high_file_size_remote_file_transfer_ea machine learning job. Follow the setup instructions detailed in the documentation.
Review and tune the anomaly threshold (anomaly_threshold = 70) of the machine learning job based on your environment’s baseline to reduce false positives.
Implement network segmentation to limit lateral movement, as suggested in the “Response and remediation” section of the rule documentation.
Enhance monitoring and logging for unusual file transfer activities and remote access attempts as stated in the rule documentation.

Potential Abuse of AWS Console GetSigninToken

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

The AWS GetSigninToken API, typically used for legitimate console access, can be abused by attackers to generate temporary, federated credentials. This technique, often facilitated by tools like aws_consoler, allows attackers to obfuscate the compromised access keys used to generate the tokens. By pivoting from the AWS CLI to console sessions with these temporary credentials, adversaries bypass MFA requirements and complicate forensic investigations. This activity is crucial for defenders to monitor, especially in environments not configured for AWS SSO, as it can indicate unauthorized access and lateral movement within the AWS infrastructure. The tool aws_consoler is specifically designed to automate this process, creating a streamlined path for malicious actors to leverage compromised credentials for further exploitation.

Attack Chain

An attacker gains initial access to AWS environment using compromised credentials (access key, secret key).
The attacker uses the compromised credentials with the AWS CLI or SDK to call the GetSigninToken API.
AWS CloudTrail logs the GetSigninToken event with the event source signin.amazonaws.com and event name GetSigninToken.
The GetSigninToken API returns a temporary sign-in token.
The attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.
The attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.
Once in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.
The attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.

Impact

Successful abuse of the GetSigninToken API can lead to unauthorized access to the AWS Management Console, enabling lateral movement and data exfiltration. The obfuscation of the original compromised credentials makes incident response more difficult. While the exact number of victims is unknown, this technique has been observed in intrusions targeting telecom and BPO companies. The impact includes potential data breaches, service disruptions, and reputational damage.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious GetSigninToken events in AWS CloudTrail logs.
Investigate any GetSigninToken events originating from outside of expected AWS SSO user agents or other known legitimate sources.
Monitor AWS CloudTrail logs for GetSigninToken events where the requesting user identity does not match expected patterns.
Implement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.
Review and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.

Network-Level Authentication (NLA) Disabled via Registry Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Spike in Number of RDP Connections from a Single Source IP

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

This threat brief addresses the potential for lateral movement within a network facilitated by an unusual spike in Remote Desktop Protocol (RDP) connections originating from a single source IP address. This activity is detected using an Elastic machine learning job designed to identify anomalies in network connection patterns. The rule “Spike in Number of Connections Made from a Source IP” leverages this ML job to flag instances where a single host initiates RDP connections to a significantly higher than normal number of distinct destination IPs, potentially indicating that an attacker is attempting to pivot and gain access to additional systems after compromising an initial foothold. This detection mechanism is available in Elastic Security 9.4.0 and later, with the Lateral Movement Detection integration assets installed.

Attack Chain

Initial Compromise: An attacker gains initial access to a host within the network through methods such as phishing, exploiting a vulnerability, or credential theft.
Establish Foothold: The attacker establishes a foothold on the compromised system, potentially installing tools for reconnaissance and lateral movement.
Internal Reconnaissance: The attacker performs internal reconnaissance to identify potential target systems accessible via RDP.
RDP Connection Attempts: The attacker initiates RDP connections to a large number of internal IP addresses from the compromised host.
Credential Harvesting: The attacker attempts to harvest credentials from the targeted systems to gain further access.
Lateral Movement: The attacker successfully connects to additional systems using RDP, leveraging harvested or stolen credentials.
Privilege Escalation: On newly accessed systems, the attacker attempts to escalate privileges to gain administrative control.
Objective Completion: With broader access and elevated privileges, the attacker achieves their objective, which may include data exfiltration, ransomware deployment, or disruption of services.

Impact

If successful, this lateral movement can result in widespread compromise across the targeted network. A single compromised host can serve as a launching point to access sensitive data, critical systems, and ultimately, inflict significant damage. The “Spike in Number of Connections Made from a Source IP” rule aims to detect these lateral movement attempts early, minimizing potential damage. The impact of a successful attack could range from data breaches and financial losses to operational disruption and reputational damage, affecting organizations across various sectors.

Recommendation

Enable host IP collection if using Elastic Defend (versions 8.18 and above), by following the configuration steps outlined in the Elastic documentation to ensure the host.ip field is populated.
Install the Lateral Movement Detection integration assets as described in the official Elastic documentation.
Review and tune the false positive analysis steps within the detection rule’s documentation. Whitelist known administrative IPs or legitimate RDP usage patterns to minimize noise.
Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface as recommended in the rule’s response and remediation guidance.

Unusually High Mean of RDP Session Duration Detected by Machine Learning

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

This threat brief addresses the detection of unusually long Remote Desktop Protocol (RDP) sessions, identified by a pre-built Elastic machine learning job named lmd_high_mean_rdp_session_duration_ea. Attackers can abuse RDP for lateral movement and maintaining persistence within a network. Extended RDP sessions can also be used to evade detection mechanisms. This detection leverages machine learning to identify deviations from normal RDP session durations, potentially indicating malicious activity. The detection rule has been available since October 2023, and the corresponding ML job is part of the Lateral Movement Detection integration, requiring Elastic Stack version 9.4.0 or later. The rule depends on the host.ip field to be populated, which may require enabling host IP collection in Elastic Defend versions 8.18 and above.

Attack Chain

An attacker gains initial access to a system within the network, possibly through phishing or exploiting a public-facing application.
The attacker leverages valid credentials or exploits a vulnerability to establish an RDP connection to a target system.
The RDP session is maintained for an extended period, significantly longer than typical RDP sessions within the environment.
During the prolonged RDP session, the attacker performs reconnaissance, gathering information about the network and target systems.
The attacker moves laterally to other systems within the network, using the established RDP session as a persistent access point.
The attacker executes malicious commands or transfers files, potentially installing malware or exfiltrating sensitive data.
The unusually long RDP session duration helps the attacker to remain undetected and evade security measures.
The attacker achieves their final objective, such as data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation and undetected lateral movement via prolonged RDP sessions can lead to significant data breaches, system compromise, and financial loss. The impact includes potential theft of sensitive information, disruption of business operations, and reputational damage. If an adversary establishes a persistent foothold via RDP, they can maintain long-term access to the compromised environment.

Recommendation

Ensure host.ip field is populated by enabling host IP collection if using Elastic Defend versions 8.18 and above, as described in the helper guide.
Install and configure the Lateral Movement Detection integration in Kibana as described in the setup guide.
Tune the machine learning job lmd_high_mean_rdp_session_duration_ea by adjusting the anomaly_threshold based on your environment and RDP usage patterns.
Investigate triggered alerts from the “High Mean of RDP Session Duration” rule following the triage and analysis guide.
Monitor Windows RDP process events collected by the Elastic Defend integration for suspicious activity.

Spike in Number of Processes in an RDP Session

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

This detection identifies potential lateral movement by flagging spikes in the number of processes initiated during a single RDP session. The rule, based on an Elastic machine learning job named lmd_high_sum_rdp_number_of_processes_ea, aims to uncover suspicious remote activity indicative of an attacker attempting to execute commands or deploy tools on a compromised host. This detection matters because RDP is a common vector for attackers to gain access to internal networks and subsequently move laterally. The detection leverages Windows RDP process events and file events collected by the Elastic Defend integration. Identifying anomalous process creation within RDP sessions can help defenders identify and respond to potential security incidents faster.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker leverages valid credentials or exploits an RDP vulnerability to establish a remote session (T1021.001).
Once connected via RDP, the attacker begins to execute a series of commands to enumerate the system and network.
The attacker attempts to install malware or other malicious tools, triggering the creation of multiple processes.
The machine learning job detects a significant increase in the number of processes started within the RDP session.
The detection rule triggers, alerting analysts to the anomalous activity.
The attacker uses the newly installed tools to move laterally to other systems on the network.
The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

A successful lateral movement attack can lead to significant damage, including data breaches, system compromise, and financial loss. While the severity is low, a spike in RDP processes can be an early indicator of compromise. Attackers often use RDP to propagate through a network after gaining initial access, making this detection critical for preventing widespread damage.

Recommendation

Enable host IP collection by following the configuration steps in the Elastic Defend documentation to ensure the host.ip field is populated.
Install the Lateral Movement Detection integration assets as described in the rule’s setup instructions to enable the machine learning job lmd_high_sum_rdp_number_of_processes_ea.
Review and tune the anomaly threshold to reduce false positives based on your organization’s typical RDP usage.
Investigate RDP sessions flagged by this rule to identify the source of the process spike and potential malicious activity as described in the rule’s “Triage and Analysis” notes.

Unusual Remote File Directory Lateral Movement Detection

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

This detection identifies potential lateral movement within a network by flagging unusual remote file transfers to directories that are not commonly monitored. Attackers often leverage less scrutinized file paths to evade standard security measures and deploy malicious payloads. This detection relies on the “lmd_rare_file_path_remote_transfer_ea” machine learning job within Elastic Security, which analyzes file and Windows RDP process events to identify anomalous file transfers based on the destination directory. The detection is part of the Lateral Movement Detection integration and requires Elastic Defend and Fleet for full functionality. This is important for defenders because attackers will try to blend in with normal file transfer activity by using uncommon directories.

Attack Chain

The attacker gains initial access to a system within the network (e.g., via phishing or exploitation of a vulnerability).
The attacker identifies a target host for lateral movement.
The attacker uses a remote service (e.g., RDP, SMB) to connect to the target host.
The attacker attempts to transfer malicious files to the target host.
Instead of using common directories like “C:\Windows\Temp” or “C:\ProgramData”, the attacker chooses a less monitored directory to evade detection.
The remote service is leveraged to perform the file transfer to the atypical directory.
The transferred file is then executed, potentially leading to command execution or privilege escalation.
The attacker achieves their objective (e.g., data exfiltration, ransomware deployment) on the target host.

Impact

A successful attack can lead to unauthorized access to sensitive data, compromise of critical systems, and potential disruption of business operations. Although this detection is rated as low severity, successful lateral movement can lead to significant damage. The number of affected hosts and the severity of the impact depends on the attacker’s objectives and the organization’s security posture. Lateral movement allows attackers to gain a deeper foothold within the network and increase the scope of their malicious activities.

Recommendation

Ensure the host.ip field is populated in Elastic Defend events by following the configuration steps in the Elastic documentation.
Install the Lateral Movement Detection integration assets as described in the setup instructions.
Tune the anomaly_threshold in the machine learning job configuration based on your environment’s baseline activity to minimize false positives, as mentioned in the rule’s configuration.
Investigate any alerts generated by this rule, paying close attention to the source and destination IP addresses, the user account involved, and the specific directory used for the file transfer as outlined in the triage and analysis section.

Potential Ransomware Behavior - Note Files Dropped via SMB

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

This detection identifies potential ransomware activity through the rapid creation of ransom notes via SMB shares. The rule focuses on file creation events originating from the SYSTEM account (PID 4), targeting common ransom note file extensions like .txt, .html, .pdf, and image files. This activity suggests an attacker has achieved lateral movement and is deploying ransom notes across multiple systems. The rule aggregates events within a 60-second window to reduce false positives and focus on high-frequency creation patterns indicative of automated ransomware deployment. Successful detection can help defenders quickly identify and contain ransomware outbreaks before widespread encryption occurs. The original Elastic detection rule was published on 2024-05-03 and updated on 2026-05-04.

Attack Chain

The attacker gains initial access to a system through an exploit or compromised credentials.
The attacker moves laterally to other systems on the network using valid accounts or exploits. (T1021.002 - SMB/Windows Admin Shares)
The attacker uses a tool to remotely create files over SMB. (T1021.002 - SMB/Windows Admin Shares)
The SYSTEM account (PID 4) on a compromised host is used to create multiple files with the same name but different paths (C:*) over SMB.
The created files have file extensions commonly associated with ransom notes: .txt, .htm, .html, .hta, .pdf, .jpg, .bmp, .png.
The files are dropped into at least 3 unique paths within a short time frame (60 seconds).
The attacker encrypts data and leaves the ransom notes to instruct victims on how to pay the ransom. (T1486 - Data Encrypted for Impact)
The organization experiences data loss, financial damage, and reputational harm.

Impact

Successful ransomware attacks can lead to significant data loss, financial costs associated with ransom payments, recovery efforts, and reputational damage. Organizations may experience business disruption, regulatory fines, and legal liabilities. The Akira ransomware group, referenced in the original rule’s documentation, has been known to target various sectors, demanding substantial ransoms from victims. The widespread distribution of ransom notes indicates an advanced stage of the ransomware attack, necessitating immediate containment to prevent further data encryption and system compromise.

Recommendation

Deploy the Sigma rule Potential Ransomware Note File Dropped via SMB to your SIEM to detect suspicious file creation activity indicative of ransomware deployment.
Enable Elastic Defend for enhanced endpoint detection and response capabilities, as recommended in the rule’s setup instructions.
Monitor incoming network connections to port 445 (SMB) on critical assets, as suggested in the rule’s triage analysis.
Investigate file names with unusual extensions to identify potential ransom notes, as mentioned in the triage analysis.
Isolate any hosts identified as creating multiple note files over SMB to prevent further lateral movement and data encryption, as described in the rule’s response and remediation steps.
Review and enforce network segmentation policies to limit lateral movement and reduce the impact of potential ransomware attacks (TA0008).

NetExec File Creation Detection

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

NetExec (formerly CrackMapExec) is a widely used post-exploitation tool favored by penetration testers and malicious actors for Active Directory enumeration, credential harvesting, and remote code execution. When executed on a Windows system, NetExec extracts its embedded data files into a temporary directory named “_MEI” followed by a random string, located under the user’s Temp folder. A specific subdirectory, “\nxc\data", within this extraction path contains files unique to NetExec. These file creation events offer a reliable indicator for detecting NetExec execution on a host. This activity is important for defenders as it signals potential reconnaissance, lateral movement attempts, or the establishment of a foothold within the network.

Attack Chain

An attacker gains initial access to a system through various means (e.g., compromised credentials, exploiting a vulnerability).
The attacker uploads the NetExec executable (nxc.exe) to the compromised host.
The attacker executes nxc.exe.
NetExec extracts its embedded data files into a temporary directory. The path follows the pattern: \Temp\_MEI\.
Within the temporary directory, a specific subdirectory \nxc\data\ is created, containing NetExec’s data files.
NetExec utilizes these files for Active Directory enumeration, credential harvesting, and reconnaissance activities.
The attacker leverages gathered information to move laterally within the network, potentially targeting other systems or services.
The attacker may attempt to execute code remotely using harvested credentials, furthering their access and control within the environment.

Impact

Successful NetExec deployment can lead to extensive reconnaissance of Active Directory environments, enabling attackers to map out network infrastructure, identify valuable targets, and harvest credentials. This can result in unauthorized access to sensitive data, lateral movement to critical systems, and ultimately, a complete compromise of the domain. Organizations in all sectors are vulnerable, with the impact ranging from data breaches and financial loss to reputational damage and operational disruption.

Recommendation

Deploy the provided Sigma rule Detect NetExec File Creation to your SIEM to detect NetExec’s unique file creation patterns (logsource: file_event, product: windows).
Monitor file creation events in the \Temp directory for filenames containing _MEI and \nxc\data\, as these indicate NetExec’s extraction process.
Enable process-creation logging with command-line arguments to identify the execution of nxc.exe (logsource: process_creation, product: windows).
Investigate any alerts generated by these rules to determine the extent of the compromise and contain any further lateral movement.

NLTEST.EXE Used for Domain Trust Discovery

hello@craftedsignal.io — Thu, 11 Jan 2024 17:49:00 +0000

The nltest.exe utility is a command-line tool used to manage and troubleshoot Windows NT domains. While legitimate domain administrators may use this utility for information gathering, adversaries can also abuse it to enumerate domain trusts and gain insight into trust relationships, which exposes the state of Domain Controller (DC) replication within a Windows NT Domain. This activity is more suspicious in environments with Windows Server 2012 and newer, where its usage is less common for legitimate purposes. Attackers can leverage this information to facilitate lateral movement and other malicious activities within the network.

Attack Chain

An attacker gains initial access to a compromised host within the target environment.
The attacker executes nltest.exe with specific arguments such as /DOMAIN_TRUSTS, /DCLIST:*, /DCNAME:*, /DSGET*, /LSAQUERYFTI:*, /PARENTDOMAIN, or /BDC_QUERY:* to enumerate domain trusts.
The nltest.exe utility queries the Active Directory to gather information about domain trusts, domain controllers, and other domain-related information.
The attacker parses the output of nltest.exe to identify trust relationships, domain controllers, and other relevant information about the domain infrastructure.
The attacker uses the gathered information to map out potential lateral movement paths within the environment.
The attacker leverages discovered trust relationships to authenticate to other domains or resources.
The attacker moves laterally to other systems or domains, leveraging the discovered trust relationships and compromised credentials.
The attacker establishes persistence and continues to perform malicious activities, such as data exfiltration or ransomware deployment.

Impact

Successful enumeration of domain trusts via nltest.exe can provide attackers with valuable information to facilitate lateral movement and escalate privileges within a Windows NT Domain. This can lead to the compromise of sensitive data, disruption of critical services, and ultimately, a complete takeover of the affected environment. While the specific number of victims and sectors targeted are unknown, the impact can be significant for organizations relying on Active Directory for authentication and authorization.

Recommendation

Monitor process execution for nltest.exe with command-line arguments indicative of domain trust discovery, using the provided Sigma rule.
Investigate any instances of nltest.exe execution, especially when initiated by non-administrative users or from unusual locations, as identified by the Sigma rule.
Enable Sysmon process creation logging to capture the necessary process execution data for the provided Sigma rule.
Review and restrict the use of nltest.exe to authorized personnel only.

PowerShell Share Enumeration via ShareFinder or Native APIs

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

This detection identifies PowerShell scripts utilizing ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or native Windows API calls for share enumeration. These techniques are commonly used by attackers to map accessible network shares within an environment. This reconnaissance is often a precursor to data collection, lateral movement, or the deployment of ransomware. The activity is detected via script block logging, and focuses on identifying specific function calls and API usage within the PowerShell script content. Defenders should be aware of this activity, particularly when performed by unexpected users or on unusual systems, as it may indicate malicious reconnaissance within the network. The references indicate that this activity can lead to corporate insurance policy exfiltration or Conti ransomware deployment.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or compromised credentials.
The attacker executes a PowerShell script, either directly or through a fileless execution method.
The PowerShell script utilizes ShareFinder functions (Invoke-ShareFinder, Invoke-ShareFinderThreaded) or Windows share enumeration APIs (NetShareEnum, NetApiBufferFree) to discover network shares.
The script identifies accessible network shares by leveraging API calls and parsing the results for share names (shi1_netname) and remarks (shi1_remark).
The attacker analyzes the identified shares to determine those that are accessible and contain valuable data.
The attacker may then attempt to access these shares using compromised credentials or exploiting existing vulnerabilities.
Once access is gained, the attacker may collect sensitive data from the shares, move laterally to other systems, or deploy ransomware.
The ultimate goal is data exfiltration, system compromise, or financial gain through ransomware.

Impact

Successful exploitation of this reconnaissance technique can lead to significant data breaches, lateral movement within the network, and potential ransomware deployment. Organizations that fail to detect and prevent share enumeration may suffer financial losses, reputational damage, and operational disruption. The referenced “Stolen Images” campaign led to Conti ransomware deployment, and the “Hunting for corporate insurance policies” post highlights data exfiltration.

Recommendation

Enable PowerShell script block logging to capture the necessary events for detection (as referenced in the rule setup).
Deploy the Sigma rule “PowerShell Share Enumeration Script via Invoke-ShareFinder” to your SIEM and tune for your environment.
Deploy the Sigma rule “PowerShell Share Enumeration via NetShareEnum API” to detect share enumeration using native Windows APIs.
Investigate any alerts generated by these rules, focusing on the PowerShell launch context and the scope of the share discovery (see triage steps in the original rule).
Review and restrict PowerShell execution policies to prevent unauthorized script execution, especially from user-writable locations.

DCOM Lateral Movement via ShellWindows/ShellBrowserWindow

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

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

Attack Chain

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

Impact

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

Recommendation

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

Incoming Execution via PowerShell Remoting

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

This detection identifies potential lateral movement through the exploitation of Windows PowerShell remoting. PowerShell remoting is a feature that enables administrators and attackers to execute commands on remote Windows systems. The detection focuses on identifying incoming network connections on ports 5985 (HTTP) and 5986 (HTTPS), the default ports used for PowerShell Remoting, followed by the execution of processes spawned by wsmprovhost.exe, the Windows Remote Management process host. This activity, when originating from unexpected sources, may indicate unauthorized access and lateral movement within a network. The rule is designed to detect suspicious activity by monitoring network traffic and process execution, flagging potential unauthorized remote executions, and enabling security teams to respond swiftly.

Attack Chain

An attacker gains initial access to a network, possibly through phishing or exploiting a vulnerability on an internet-facing system.
The attacker leverages PowerShell remoting to initiate a connection to a target system on ports 5985 or 5986.
The target system accepts the incoming PowerShell Remoting connection.
The wsmprovhost.exe process is launched on the target system to facilitate the remote PowerShell session.
The attacker executes commands remotely, spawning child processes from wsmprovhost.exe.
The attacker attempts to escalate privileges or move laterally to other systems within the network using the remote PowerShell session.
The attacker uses tools such as net.exe or PsExec over the remote PowerShell session to further propagate.
The attacker achieves their objective, such as data exfiltration or deploying ransomware, by leveraging the established remote session.

Impact

Successful exploitation of PowerShell Remoting for lateral movement can lead to widespread compromise within an organization. An attacker could gain control over multiple systems, potentially leading to data breaches, system outages, or ransomware deployment. The number of affected systems could range from a few critical servers to a significant portion of the network, depending on the attacker’s objectives and the organization’s security posture. The impact could include financial losses, reputational damage, and disruption of business operations.

Recommendation

Deploy the Sigma rule Incoming Execution via PowerShell Remoting to your SIEM to detect suspicious PowerShell remoting activity and tune for your environment.
Monitor network connections to ports 5985 and 5986, and investigate any unauthorized or unexpected traffic using the network_connection log source.
Investigate processes spawned by wsmprovhost.exe for unusual or malicious activity using the process_creation log source.
Whitelist authorized administrative IP addresses or user accounts that frequently perform remote management tasks, as mentioned in the false positives analysis.
Review and document automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance, then create exceptions for their specific process names or execution paths.

Unusual Time or Day for an RDP Session Detected by Machine Learning

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

This alert originates from a machine learning job designed to detect anomalous RDP session start times. RDP is a common vector for lateral movement, and attackers may initiate sessions during off-peak hours to evade detection. The machine learning model flags sessions started outside of normal business hours or on unusual weekdays. While not inherently malicious, this activity warrants investigation as it can be an early indicator of a broader attack. The rule is part of the Lateral Movement Detection (LMD) integration from Elastic, requiring a minimum stack version of 9.4.0 and leverages Entity Analytics (EA) fields. Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events using Elastic’s Anomaly Detection feature.

Attack Chain

An attacker gains initial access to a system, possibly through compromised credentials or a software vulnerability (not described in source).
The attacker leverages RDP to attempt lateral movement to other systems within the network.
The RDP session is initiated at an unusual time or day, deviating from typical user behavior.
The machine learning job detects this anomaly based on the unusual RDP session start time.
An alert is triggered, flagging the potentially suspicious activity.
The attacker may attempt to access sensitive data or resources on the target system.
The attacker could install malware or establish persistence mechanisms (not described in source).

Impact

A successful lateral movement attack can allow an attacker to gain access to sensitive data, compromise critical systems, and ultimately disrupt business operations. While the detection of an unusual RDP session is an early warning sign, it is critical to investigate these alerts promptly to prevent further escalation. If the suspicious RDP session is part of a broader attack, the impact could range from data theft to ransomware deployment. The lack of immediate action could lead to significant financial and reputational damage.

Recommendation

Enable host IP collection within Elastic Defend if using versions 8.18 and above, following the configuration steps in the helper guide.
Ensure the Lateral Movement Detection integration assets are installed, as well as file and Windows RDP process events collected by the Elastic Defend integration, as mentioned in the setup instructions.
Investigate all alerts generated by the “Unusual Time or Day for an RDP Session” rule, correlating the RDP session with other security events.
Tune the anomaly threshold (currently 70) to reduce false positives while maintaining effective detection capabilities.

Suspicious AWS SAML Activity Detection

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

This detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for AssumeRoleWithSAML and UpdateSAMLProvider events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.

Attack Chain

The attacker compromises or creates a malicious SAML identity provider.
The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

Successful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.

Recommendation

Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

Unusual Remote File Extension Detected via Machine Learning

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

This brief focuses on a detection rule from Elastic’s Lateral Movement Detection (LMD) integration that utilizes machine learning to identify unusual remote file transfers. The rule, “Unusual Remote File Extension,” is designed to detect anomalies in file transfers, specifically those involving rare file extensions, which could be indicative of lateral movement within a network. This rule leverages the lmd_rare_file_extension_remote_transfer_ea machine learning job ID. The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. The rule operates by analyzing host.ip and detecting anomalies in file transfers, where host IP collection needs to be enabled on Elastic Defend versions 8.18 and above.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker attempts to move laterally to other systems using remote services like RDP or SMB.
As part of the lateral movement, the attacker transfers tools or files to the remote system.
The attacker uses a rare or uncommon file extension for the transferred files, potentially to evade detection based on known file types.
The file transfer occurs over the network, triggering file event logs on the source and destination systems.
Elastic Defend, with host IP collection enabled, monitors these file events and forwards the data to the Elastic Security platform.
The “Unusual Remote File Extension” machine learning job identifies the transfer of a file with a rare extension, comparing it against historical data.
If the file extension is deemed anomalous based on its rarity, the rule triggers, indicating potential lateral movement.

Impact

A successful lateral movement attack can allow an adversary to gain access to sensitive data, critical systems, or privileged accounts. By using uncommon file extensions, attackers attempt to bypass security measures that rely on identifying known file types. This can lead to undetected malware deployment, data exfiltration, or further compromise of the network. Though this rule is of low severity, it can provide an early warning signal to stop an attack before greater damage occurs.

Recommendation

Enable the host.ip field within Elastic Defend configurations (versions 8.18 and above) to ensure proper data collection for the machine learning job.
Install the Lateral Movement Detection integration assets within Kibana as per the provided setup instructions to activate the “Unusual Remote File Extension” rule.
Tune the anomaly threshold of the machine learning job to reduce false positives, considering your organization’s typical file transfer patterns.
Deploy the “Detect Remote File Extension Transfer” Sigma rule to identify file transfers with rare extensions using process creation logs.
Review the triage and analysis steps in the rule’s documentation to effectively investigate and respond to triggered alerts.

Potential Remote Credential Access via Registry

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

This detection identifies potential remote access to the Windows registry to dump credential data from the Security Account Manager (SAM) registry hive. This activity often precedes credential access and privilege elevation attempts. The rule focuses on detecting the creation of specific file types by svchost.exe, a legitimate Windows process, in temporary directories. However, when svchost.exe creates files with registry file (REGF) header bytes in temporary locations, and those files are also of a significant size, it indicates a potential secretsdump-style attack. The rule is designed for data generated by Elastic Defend.

Attack Chain

Attacker gains initial access to the target system via compromised credentials or exploiting a vulnerability.
Attacker uses remote registry tools or scripts, such as those based on Impacket’s secretsdump.py, to connect to the target system’s registry service.
The attacker initiates a connection to the RemoteRegistry service.
The svchost.exe process on the target system is leveraged to access the SAM, SECURITY, and SYSTEM registry hives.
svchost.exe creates a temporary file (e.g., a .tmp file) in the \Windows\System32\ or \WINDOWS\Temp\ directory.
The temporary file contains the contents of the registry hive, identifiable by the “72656766” (REGF) header bytes and a file size greater than 30000 bytes.
The attacker retrieves the dumped registry hive files from the target system.
The attacker parses the registry hives offline to extract sensitive credential information, such as password hashes. This leads to lateral movement and privilege escalation.

Impact

A successful attack allows adversaries to extract sensitive credentials, including password hashes, from the compromised system. This can lead to lateral movement within the network, privilege escalation, and ultimately, domain compromise. The extraction of credentials provides the attacker with persistent access and the ability to move undetected through the environment.

Recommendation

Deploy the Sigma rule Suspicious Svchost.exe Registry Hive Dump to detect the creation of registry hive files by svchost.exe in temporary directories based on the file.Ext.header_bytes and file.path fields.
Deploy the Sigma rule Suspicious RemoteRegistry File Creation to detect files with REGF header bytes created by svchost.exe, outside the standard system path to catch unusual service context.
Enable and monitor process creation events, specifically focusing on svchost.exe and its command-line arguments, to identify suspicious service groups.
Monitor file creation events for files with the .tmp extension in the \Windows\System32\ and \WINDOWS\Temp\ directories, paying attention to file sizes and header bytes, as indicated by the file path and size conditions in the rule.
Review the investigation steps outlined in the rule documentation to properly triage and analyze potential incidents.

AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity

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

This detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing AssumeRoleWithWebIdentity. It focuses on detecting instances where credentials obtained via this method are subsequently used to perform several distinct AWS control-plane actions within a single session. This behavior deviates from typical pod traffic and could signify unauthorized access or privilege escalation. The rule prioritizes the detection of sensitive API usage, including reconnaissance activities, access to secrets, IAM modifications, and compute creation events, while strategically excluding high-volume S3 data-plane operations to minimize false positives. The targeted environments are those leveraging EKS IAM Roles for Service Accounts.

Attack Chain

A Kubernetes service account projects a token.
The service account uses AssumeRoleWithWebIdentity to exchange the token for short-lived IAM credentials.
The attacker leverages the assumed role to perform reconnaissance activities such as ListUsers, ListRoles, and DescribeInstances.
The attacker attempts to access secrets using actions like GetSecretValue and ListSecrets.
The attacker escalates privileges by modifying IAM policies with actions like AttachRolePolicy and PutRolePolicy.
The attacker attempts to create new users or roles within the AWS environment using actions like CreateUser and CreateRole.
The attacker performs lateral movement using actions like SendCommand and StartSession.
The attacker attempts to evade detection by stopping logging with the StopLogging action.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to AssumeRoleWithWebIdentity and tune for your environment.
Review and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the IAM OIDC identity provider documentation.
Implement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in EKS IAM roles for service accounts.
Monitor CloudTrail logs for AssumeRoleWithWebIdentity events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.

Detection of NetExec Hacktool Execution

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

NetExec, previously known as CrackMapExec, is a post-exploitation tool commonly used during Active Directory penetration testing. It is also favored by red teams and malicious actors for reconnaissance, lateral movement, and credential harvesting within Windows networks. This tool allows for the enumeration of hosts, exploitation of network services, and remote command execution. The use of NetExec in an enterprise environment is considered suspicious due to its capabilities for identifying vulnerable systems and facilitating unauthorized access. Defenders should monitor for its execution, as it is often a precursor to more serious attacks, including ransomware deployment, such as the Lynx ransomware.

Attack Chain

An attacker gains initial access to a Windows system via an exploit or compromised credentials.
NetExec (nxc.exe) is deployed on the compromised host, often copied to a temporary directory.
NetExec is executed with commands to enumerate network shares and identify potential targets using SMB.
The tool uses LDAP to query Active Directory for user accounts, groups, and organizational units.
NetExec attempts to authenticate to other systems using gathered or compromised credentials via protocols such as SMB, SSH, or RDP.
Successful authentication allows for remote command execution via WMI or WinRM.
The attacker leverages identified vulnerabilities or misconfigurations to escalate privileges on the target systems.
The attacker moves laterally through the network, gaining access to sensitive data or deploying ransomware like Lynx.

Impact

Successful execution of NetExec can lead to widespread compromise within an Active Directory environment. Attackers can identify and exploit vulnerable systems, harvest credentials, and move laterally to gain access to critical assets. This can result in data theft, system disruption, and ransomware deployment, potentially affecting hundreds or thousands of systems depending on the size of the organization. The tool is often used as a precursor to ransomware attacks, where entire networks can be encrypted, leading to significant financial and reputational damage.

Recommendation

Deploy the Sigma rule HackTool - NetExec Execution to your SIEM to detect the execution of NetExec based on process creation logs.
Monitor process creation events for nxc.exe with command-line arguments associated with network protocols like ftp, ldap, mssql, nfs, rdp, smb, ssh, vnc, winrm, and wmi.
Implement strict access controls and regularly audit Active Directory to minimize the potential for lateral movement.
Consider using application control solutions to prevent the execution of unauthorized tools like nxc.exe.

RDP (Remote Desktop Protocol) from the Internet

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

Remote Desktop Protocol (RDP) is a common tool for system administrators to remotely manage systems, however, exposing RDP directly to the internet creates a significant attack surface. Threat actors frequently target and exploit RDP for initial access, lateral movement, and establishing backdoors within compromised networks. This activity is detected by monitoring network traffic for RDP connections originating from outside the internal network (RFC1918 IP ranges). This is important because successful RDP compromise often leads to broader network infiltration and data exfiltration. This detection focuses on the network level characteristics of RDP connections from the internet to internal assets.

Attack Chain

An attacker identifies a publicly accessible RDP service.
The attacker attempts to brute-force RDP login credentials or exploits a known RDP vulnerability (e.g. BlueKeep CVE-2019-0708).
Upon successful authentication or exploitation, the attacker gains remote access to the targeted system.
The attacker uses the compromised system as a pivot point to perform reconnaissance on the internal network.
The attacker moves laterally within the network using stolen credentials or by exploiting other vulnerabilities.
The attacker installs malware or establishes persistence mechanisms (e.g., creating new user accounts or modifying system configurations).
The attacker gathers sensitive data from internal systems.
The attacker exfiltrates the stolen data to an external server or deploys ransomware.

Impact

Compromised RDP services can lead to significant data breaches, system downtime, and financial losses. Attackers can leverage RDP access to steal sensitive information, install ransomware, or disrupt critical business operations. While the number of affected organizations varies, RDP exploitation remains a prevalent attack vector, especially for organizations with inadequate security practices. The impact of a successful RDP attack ranges from several thousands to millions of dollars, depending on the size of the organization and the sensitivity of the compromised data.

Recommendation

Deploy the “RDP (Remote Desktop Protocol) from the Internet” Sigma rule to your SIEM to detect unauthorized RDP connections from outside the network.
Review firewall rules and network configurations to ensure RDP services are not exposed directly to the internet. Implement a VPN or RDP gateway for secure remote access.
Enable and monitor network traffic logs (category: network_traffic, product: windows|linux|macos) to provide data for the Sigma rule.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address and user accounts involved in the RDP connection.
Implement network segmentation to limit the blast radius of a potential RDP compromise.

Kubelet API Connection Attempt to Internal IP

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

This detection rule identifies suspicious network connections to the Kubernetes Kubelet API, specifically targeting ports 10250 and 10255, from Linux hosts within internal network ranges. Attackers frequently exploit weak authentication or network controls to access the Kubelet API, potentially enabling them to enumerate pods, retrieve logs, and execute commands on nodes. This activity often originates from common scripting utilities like curl, wget, or interpreters like python and node, particularly when executed from world-writable directories such as /tmp, /var/tmp, or /dev/shm. This technique is often a component of container and cluster lateral movement, where the attacker seeks to expand their access within the Kubernetes environment. The rule is designed to detect these unauthorized attempts and alert security teams to investigate potential breaches.

Attack Chain

An attacker gains initial access to a compromised container or host within the Kubernetes cluster, potentially through exploiting a vulnerability in a running application.
The attacker executes a reconnaissance command, such as curl or wget, from within the compromised container, targeting the Kubelet API on port 10250 or 10255.
The curl or wget command is executed from a temporary directory like /tmp or /dev/shm to avoid detection.
The attacker attempts to enumerate running pods and services by querying the /pods or /runningpods endpoints of the Kubelet API.
If successful, the attacker identifies a target pod within the cluster based on the enumerated information.
The attacker leverages the Kubelet API to execute commands within the target pod, potentially escalating privileges or accessing sensitive data.
The attacker attempts to move laterally to other nodes or containers within the Kubernetes cluster, repeating the reconnaissance and exploitation steps.
The ultimate goal is to gain control over the entire Kubernetes cluster, enabling data exfiltration, resource hijacking, or disruption of services.

Impact

Successful exploitation of the Kubelet API can lead to a complete compromise of the Kubernetes cluster. Attackers can gain unauthorized access to sensitive data, escalate privileges, and disrupt critical services. While the number of victims may vary depending on the organization’s security posture, a successful attack could impact all applications and data managed by the cluster. Organizations in any sector utilizing Kubernetes are potentially at risk.

Recommendation

Enable syscall auditing and ensure that event.category:network events are generated for network connections, as outlined in the rule’s setup guide.
Deploy the provided Sigma rule to your SIEM and tune it based on your environment to reduce false positives.
Restrict pod-to-node access to port 10250 using network policies or security groups to limit the attack surface, as noted in the rule’s documentation.
Implement Kubernetes API audit logging to detect unauthorized access attempts and credential access, correlating with process argument telemetry as mentioned in the triage steps.

Detection of Azure Service Principal Creation

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

The creation of service principals in Azure can be a legitimate administrative task, but it can also be an indicator of malicious activity. Attackers may create service principals to establish persistence, move laterally within the Azure environment, or gain unauthorized access to resources. This activity is particularly concerning when performed by unfamiliar users or from unusual locations. Monitoring for unexpected service principal creation is crucial for detecting potential security breaches in Azure environments. This alert focuses on detecting the “Add service principal” message within Azure Activity Logs.

Attack Chain

An attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.
The attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.
The attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.
Azure Activity Logs record the “Add service principal” event.
The attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.
The attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.
The service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.

Impact

Successful creation and misuse of a service principal can lead to unauthorized access to sensitive data, resources, and services within the Azure environment. The impact can range from data breaches and service disruption to complete control over the Azure subscription, potentially affecting hundreds or thousands of resources and users. The attacker can leverage the compromised service principal to perform actions with the permissions assigned to it, leading to significant damage and financial loss.

Recommendation

Deploy the Sigma rule “Azure Service Principal Created” to your SIEM and tune for your environment to detect suspicious service principal creations.
Investigate any alerts generated by the “Azure Service Principal Created” rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.
Review and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.
Implement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.

Detecting RPC Traffic to the Internet

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

The Remote Procedure Call (RPC) protocol, while essential for legitimate system administration tasks such as remote maintenance and resource sharing within internal networks, poses a significant security risk when exposed to the internet. Threat actors frequently target and exploit RPC services as an initial access vector or to establish backdoors within compromised systems. This exposure allows attackers to remotely execute commands, move laterally within the network, and potentially exfiltrate sensitive data. This brief provides detection strategies to identify such anomalous RPC traffic, enabling security teams to proactively mitigate potential threats. The detection focuses on identifying TCP traffic to port 135 from internal IP ranges to external IP addresses.

Attack Chain

The attacker compromises a host within the internal network, potentially through phishing or exploiting a vulnerability.
The compromised host initiates an RPC connection to an external IP address on TCP port 135.
The attacker uses the RPC connection to enumerate network resources and identify potential targets for lateral movement.
Using the RPC connection, the attacker attempts to authenticate to other systems within the network.
Upon successful authentication, the attacker remotely executes commands on the target system via RPC.
The attacker installs malware or a backdoor on the target system for persistence.
The attacker leverages the established foothold to further propagate within the network, compromising additional systems.

Impact

Successful exploitation of RPC services exposed to the internet can lead to a complete compromise of the internal network. Attackers can gain initial access, move laterally, exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations. A single exposed RPC service can serve as a gateway for widespread damage.

Recommendation

Implement the provided Sigma rule to detect RPC traffic from internal IP ranges to external destinations on TCP port 135, focusing on network traffic logs.
Investigate any alerts generated by the Sigma rule, prioritizing systems exhibiting suspicious RPC activity (Sigma rule, logsource: network_connection).
Ensure that RPC services are not directly exposed to the internet. Implement firewall rules to restrict access to authorized internal IP ranges only.
Continuously monitor network traffic for anomalous RPC activity and correlate with other security events (logsource: network_connection).
Review and update firewall configurations to block unauthorized outbound connections on port 135 (logsource: firewall).

Remote Execution via File Shares

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

This detection identifies lateral movement via network file shares by detecting the execution of a file that was recently created by the virtual system process (PID 4), commonly associated with file share operations. Adversaries may leverage network shares to distribute malicious payloads or tools across the network to compromise additional hosts. This technique allows attackers to execute code remotely, expanding their foothold within the environment. The rule focuses on Windows systems and monitors for newly created executable files (e.g., .exe, .scr, .pif, .com) that are then executed. Exceptions are made for known legitimate software vendors and specific file paths to reduce false positives.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker uploads a malicious executable (e.g., malware, custom tool) to a network file share. The file creation event is attributed to PID 4.
A user or automated process on a remote system accesses the file share.
The malicious executable is copied or accessed from the network share onto the remote system.
The user, either intentionally or through deception, executes the malicious executable.
The executed file initiates malicious activities on the remote system.
The attacker achieves code execution on the remote system.
The attacker uses this foothold for further lateral movement, data exfiltration, or other malicious objectives.

Impact

Successful exploitation through remote execution via file shares can lead to widespread compromise across the network. Attackers can gain unauthorized access to sensitive data, install backdoors, or deploy ransomware. The impact ranges from data breaches and financial losses to significant disruption of business operations. The severity of the impact depends on the attacker’s objectives and the extent of their lateral movement within the environment.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious executions of files created by PID 4 on Windows systems.
Review and restrict write access to network shares to minimize the risk of unauthorized file uploads.
Monitor file creation events (event.type in (“creation”, “change”)) on network shares for unusual activity using file integrity monitoring tools.
Investigate any alerts generated by the Sigma rule by examining the process execution chain and associated network connections.
Enrich process creation events (category: process_creation) with code signature information to validate the legitimacy of executed files.
Use osquery to retrieve the files’ SHA-256 hash values using the PowerShell Get-FileHash cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

Remote Execution via File Shares

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

This detection rule identifies a specific sequence of events that may indicate lateral movement within a Windows environment. The rule focuses on scenarios where a file is created or modified by the System process (PID 4), which is then subsequently executed. This behavior is often associated with attackers leveraging network file shares to distribute malicious tools or payloads across multiple systems. The rule aims to detect this activity while excluding legitimate software installations or updates by filtering out processes signed by trusted vendors such as Veeam, Elasticsearch, CrowdStrike, and Microsoft. This exclusion is designed to reduce false positives and focus on potentially malicious activity. The rule is designed for data generated by Elastic Defend.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker uploads a malicious executable (e.g., EXE, SCR, PIF, COM) to a network file share accessible to other systems. The file’s header starts with 4d5a.
The System process (PID 4) creates or modifies the malicious executable on the target system via the network share. This can happen through normal network file operations.
The attacker uses lateral movement techniques, such as exploiting SMB/Windows Admin Shares, to remotely trigger the execution of the malicious executable on the target system.
The malicious executable begins to execute, initiating attacker-controlled code on the target system.
The process attempts to establish command and control (C2) communication with an external server.
The attacker uses the compromised system to further propagate within the network, potentially deploying additional malicious tools or escalating privileges.
The attacker achieves their final objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to widespread compromise of systems within the network. Attackers can leverage compromised systems for data theft, deployment of ransomware, or other malicious activities. The impact can range from business disruption and data loss to significant financial damage and reputational harm. Even with trusted vendor exclusions, a determined adversary could still bypass protections, potentially leading to the compromise of critical infrastructure.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect remote execution via file shares, and tune exclusions for your specific environment.
Enable Elastic Defend to generate the necessary process and file events for the Sigma rule to function effectively (see logs-endpoint.events.process-*, logs-endpoint.events.file-* in index).
Review and restrict write access to network shares to minimize the risk of unauthorized file uploads (see “Review the privileges needed to write to the network share”).
Investigate any alerts triggered by the Sigma rule to determine the legitimacy of the activity and take appropriate remediation steps.
Implement file integrity monitoring (FIM) on network shares to detect unauthorized file modifications or additions.
Use threat intelligence platforms to enrich file hash values and identify known malicious files.

Kerberos Traffic from Unusual Process

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

This detection identifies unusual processes initiating network connections to the standard Kerberos port (88) on Windows systems. Typically, the lsass.exe process handles Kerberos traffic on domain-joined hosts. The rule aims to detect processes other than lsass.exe communicating with the Kerberos port, which could indicate malicious activity such as Kerberoasting (T1558.003) or Pass-the-Ticket (T1550.003). The detection is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. This can help security teams identify potential credential access attempts and lateral movement within the network.

Attack Chain

An attacker compromises a user account or system within the domain.
The attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.
The malicious process attempts to request Kerberos service tickets (TGS) for various services within the domain. This is done by connecting to the Kerberos port (88) on a domain controller.
The attacker uses tools like Rubeus or Kerberoast.ps1 to enumerate and request TGS tickets.
The unusual process (not lsass.exe) sends Kerberos traffic to the domain controller.
The attacker extracts the Kerberos tickets from memory or network traffic.
The attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).
The attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.

Impact

A successful Kerberoasting or Pass-the-Ticket attack can lead to unauthorized access to sensitive resources and lateral movement within the network. Attackers can compromise service accounts with elevated privileges, potentially leading to domain-wide compromise. Detection of this behavior can prevent attackers from gaining access to critical assets. While the exact number of victims and sectors targeted are unknown, this technique is widely used by various threat actors in targeted attacks.

Recommendation

Deploy the “Kerberos Traffic from Unusual Process” Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.
Review event ID 4769 for suspicious ticket requests as mentioned in the rule’s documentation.
Examine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.
Monitor for processes connecting to port 88, filtering out legitimate Kerberos clients like lsass.exe, using the “Detect Kerberos Traffic from Non-Standard Process” Sigma rule.
Investigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.

Detecting Remote Windows Service Installation for Lateral Movement

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

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

Attack Chain

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

Impact

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

Recommendation

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

WMI Incoming Lateral Movement

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

This threat brief focuses on the detection of lateral movement within a Windows environment via Windows Management Instrumentation (WMI). WMI, a core Windows feature, is often exploited by adversaries to remotely execute processes, bypassing traditional security measures. This activity is detected by monitoring network connections and process executions, while filtering out common false positives associated with legitimate administrative use, security tools, and system processes. The goal is to highlight potential threats indicative of unauthorized lateral movement.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker uses WMI to initiate a connection to a remote host on port 135.
The svchost.exe process on the target host accepts an incoming RPC connection from the attacker-controlled system.
WmiPrvSE.exe, the WMI provider host process, spawns a new process based on the attacker’s WMI command.
The spawned process executes the attacker’s payload or command on the remote host.
The attacker leverages the executed process for further actions, such as data exfiltration or establishing persistence.

Impact

Successful exploitation and lateral movement via WMI can lead to unauthorized access to sensitive data, compromise of critical systems, and propagation of malware throughout the network. While specific victim counts or sector targeting data are unavailable, the broad applicability of WMI across Windows environments makes this a relevant threat for a wide range of organizations.

Recommendation

Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging to provide necessary data for the rules below.
Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious WMI activity and tune them for your environment.
Review and create exceptions for known administrative accounts or specific IP addresses used by IT staff to reduce false positives, as mentioned in the overview.
Isolate any affected host from the network to prevent further lateral movement if suspicious WMI activity is detected.
Monitor network connections with destination port 135 for unusual activity.

Windows Scheduled Tasks AT Command Enabled via Registry Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Unusual Process Connecting to Docker or Containerd Socket

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

This threat involves unauthorized processes connecting directly to container runtime sockets (Docker or Containerd) on Linux systems. This bypasses Kubernetes API server restrictions, potentially allowing attackers to create, execute, or manipulate containers without proper authorization or logging. The risk lies in attackers circumventing RBAC, admission webhooks, and pod security standards. The attack can start when a compromised process attempts to connect to the Docker or Containerd socket, potentially leading to privilege escalation and lateral movement within the containerized environment. This attack is significant because it undermines core security controls within container orchestration platforms.

Attack Chain

A malicious or compromised process gains initial access to the host system.
The process attempts to connect to the container runtime socket (e.g., /var/run/docker.sock or /run/containerd/containerd.sock).
The process bypasses the Kubernetes API server and associated security controls.
The attacker exploits the direct socket connection to create a new container.
The attacker gains access to sensitive data or resources within the container.
The attacker escalates privileges within the compromised container.
The attacker uses the compromised container to move laterally to other containers or hosts within the environment.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to bypass Kubernetes security measures, create unauthorized containers, and potentially gain control over the entire cluster. The observed impact includes privilege escalation, lateral movement, and data exfiltration. The severity of this attack depends on the level of access granted to the compromised container and the sensitivity of the data and resources within the cluster.

Recommendation

Enable Auditd Manager to capture network and socket events, specifically monitoring for connect calls to Unix sockets as described in the Auditd Manager documentation.
Deploy the Sigma rule “Unusual Process Connecting to Docker or Containerd Socket” to detect suspicious processes connecting to container runtime sockets, tuning process.executable and user.name for known legitimate processes.
Monitor file permissions on the socket paths (/var/run/docker.sock, /run/docker.sock, /var/run/containerd/containerd.sock, /run/containerd/containerd.sock) and restrict access to trusted groups only.

Suspicious Use of sc.exe for Remote Service Manipulation

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

This detection rule identifies the suspicious use of sc.exe (Service Control Manager) to create, modify, or start services on remote Windows hosts. While system administrators may legitimately use this tool, its use for lateral movement is a known technique used by attackers. This activity is often part of a larger attack campaign, where adversaries attempt to gain access to sensitive data or critical systems. The rule aims to detect unauthorized attempts to manipulate services on remote systems, differentiating between legitimate administrative tasks and malicious activities. The rule is designed for data generated by Elastic Defend, but also supports Sysmon data.

Attack Chain

An attacker gains initial access to a compromised host within the network.
The attacker uses sc.exe with the create command to create a new service on a remote host, specifying a malicious executable as the binPath.
The attacker uses sc.exe with the config command to modify an existing service on a remote host, changing its binPath to point to a malicious executable.
The attacker uses sc.exe with the failure command to configure service failure options to execute a malicious command.
The attacker uses sc.exe with the start command to start a service on a remote host, triggering the execution of the malicious executable.
The malicious executable executes on the remote host, providing the attacker with a foothold for further actions.
The attacker leverages the newly established foothold to move laterally to other systems within the network, potentially escalating privileges and accessing sensitive data.
The attacker establishes persistence through the created or modified service, allowing continued access even after system reboots.

Impact

Successful exploitation can allow attackers to move laterally within a network, gain unauthorized access to sensitive data, and establish persistence on compromised systems. While the source material doesn’t provide specific victim counts or sectors targeted, the impact of successful lateral movement can be significant, potentially leading to data breaches, system disruption, and financial losses.

Recommendation

Deploy the Sigma rule “Service Command Lateral Movement” to your SIEM and tune for your environment based on observed false positives from administrative activity.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging to enhance visibility into sc.exe activity.
Review and whitelist legitimate administrative scripts or tools that use sc.exe by their process names or paths to reduce false positives, as described in the rule’s documentation.
Implement network segmentation to limit the ability of adversaries to move laterally across the network, mitigating the impact of successful exploitation.

Suspicious SMB Connections via LOLBin or Untrusted Process

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

This detection rule, originally published by Elastic, identifies potentially suspicious processes making Server Message Block (SMB) network connections over port 445. Windows File Sharing is typically implemented over SMB, which communicates between hosts using port 445. Legitimate SMB connections are generally established by the kernel (PID 4). This rule focuses on detecting processes that are not trusted (not signed by Microsoft) or living-off-the-land binaries (LOLBins) initiating SMB connections. It helps to detect port scanners, exploits, or user-level processes attempting lateral movement within the network by leveraging SMB connections. The rule is designed for data generated by Elastic Defend.

Attack Chain

An attacker gains initial access to a Windows host through various means.
The attacker executes a binary that is not signed by Microsoft and not a known LOLBin.
This process attempts to establish a network connection to a remote host on port 445 (SMB).
The attacker may use this connection to enumerate shares.
The attacker attempts to authenticate to the remote SMB share.
Upon successful authentication, the attacker may copy malicious payloads to the remote share.
The attacker executes the copied payloads on the remote system, achieving lateral movement.

Impact

A successful attack can lead to lateral movement within the network, allowing the attacker to compromise additional systems and gain further access to sensitive data. The scope of the impact depends on the permissions of the compromised account and the level of access granted to the attacker on the target systems. This could result in data exfiltration, system disruption, or ransomware deployment.

Recommendation

Deploy the Sigma rule Detect Outbound SMB Connection by Untrusted Process to your SIEM and tune for your environment.
Investigate any alerts generated by this rule, focusing on the process execution chain and network connections.
Implement network segmentation to limit lateral movement possibilities.
Ensure that systems are patched against known SMB vulnerabilities.
Monitor process creation events for unusual processes that are not signed by Microsoft.
Enable network connection logging to monitor SMB traffic for suspicious activity.

Suspicious AWS STS GetSessionToken Usage

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

The AWS Security Token Service (STS) GetSessionToken API allows IAM users to create temporary security credentials. Attackers can abuse this functionality by generating tokens with elevated privileges or for lateral movement within an AWS environment if an IAM user’s credentials have been compromised. This activity can be difficult to detect as GetSessionToken is a legitimate function, but unusual patterns or IAM users generating tokens where it is not expected should be investigated. This activity is of particular concern because it bypasses normal IAM role assumption logging and creates a separate credential for an attacker to abuse, making access more difficult to track. The impact is significant, allowing attackers to perform actions as the compromised IAM user or escalate privileges.

Attack Chain

An attacker gains initial access to an AWS environment, potentially through compromised IAM user credentials.
The attacker authenticates to AWS using the compromised IAM user credentials.
The attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user’s policies).
AWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).
The attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.
The attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.
The attacker covers their tracks by deleting the CloudTrail logs.
The attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.

Impact

Compromised AWS environments can lead to data breaches, service disruptions, and financial losses. Successful exploitation via GetSessionToken misuse allows attackers to move laterally, escalate privileges, and perform unauthorized actions within the AWS infrastructure. The number of affected organizations is currently unknown, but any organization relying on AWS is potentially at risk. If successful, attackers can steal sensitive data, compromise critical systems, and disrupt business operations.

Recommendation

Deploy the Sigma rule “AWS STS GetSessionToken Misuse” to your SIEM to detect suspicious GetSessionToken API calls (see rules section).
Investigate GetSessionToken calls where userIdentity.type is IAMUser to determine if the request is legitimate.
Monitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.
Implement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.
Review the false positives section of the Sigma rule to tune the rule for your specific environment.

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

Remote File Copy to a Hidden Share

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

This detection rule identifies attempts to copy files to hidden network shares in Windows environments, which can be indicative of lateral movement or data staging by malicious actors. Attackers may leverage hidden shares, typically used for legitimate administrative purposes, to move laterally within a network or to stage data for exfiltration without being easily detected. The rule focuses on detecting the use of command-line tools such as cmd.exe and powershell.exe with arguments that specify the copying of files to network paths that match a hidden share pattern (e.g., \\\\*\\\\*$). This activity helps identify suspicious file transfer operations that deviate from normal administrative or user behavior. The rule was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to a compromised host within the network.
The attacker uses cmd.exe or powershell.exe to execute a file copy command.
The command line includes arguments to copy files to a hidden network share (e.g., \\\\\\$).
The copy, move, cp, or mv commands are used to transfer the file.
The target hidden share is accessed using the compromised account’s credentials.
The file is successfully copied to the hidden share.
The attacker may then access the copied file from another compromised host.
The attacker proceeds to exfiltrate the staged data or uses the copied files for lateral movement.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement to other systems within the network, and potential data exfiltration. While the number of victims and specific sectors targeted are not specified, a successful compromise can significantly impact an organization’s data security and overall network integrity. The impact includes potential data loss, reputational damage, and disruption of normal business operations.

Recommendation

Deploy the “Detect Remote File Copy to Hidden Share” Sigma rule to your SIEM and tune for your environment to detect suspicious file copy activities.
Enable Sysmon process-creation logging to capture the command-line arguments used in file copy operations, activating the rule above.
Review and restrict permissions on network shares, especially hidden shares, to ensure only authorized users have access, as described in the investigation guide.
Investigate any alerts generated by the Sigma rule by examining the process details (cmd.exe, powershell.exe) and the network share path, as outlined in the investigation guide.
Correlate events with other logs or alerts from the same host or user to identify any additional suspicious activities, enhancing the detection capabilities.

RDP Enabled via Registry Modification

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

Attackers may enable Remote Desktop Protocol (RDP) to facilitate lateral movement within a compromised network. By modifying the fDenyTSConnections registry key to a value of 0, attackers can enable remote desktop connections, allowing them to access systems remotely. This technique can be employed using remote registry manipulation or tools like PsExec. The modification of the registry key is a common tactic used by ransomware operators and other threat actors to gain unauthorized access to victim servers. This activity can be performed to enable remote access for initial access or to regain access after persistence mechanisms have failed.

Attack Chain

An attacker gains initial access to a system via an exploit or compromised credentials.
The attacker uses a tool like PsExec or leverages remote registry modification capabilities.
The attacker modifies the fDenyTSConnections registry key, setting its value to 0. This key is typically located in HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server.
The system’s RDP service is enabled or re-enabled as a result of the registry change.
The attacker attempts to connect to the now-enabled RDP service using valid or brute-forced credentials.
Upon successful authentication, the attacker gains interactive access to the system via RDP.
The attacker performs reconnaissance, elevates privileges, and moves laterally to other systems.
The attacker deploys ransomware, exfiltrates data, or achieves other objectives.

Impact

Successful modification of the fDenyTSConnections registry key allows unauthorized remote access to systems, potentially leading to lateral movement, data theft, or ransomware deployment. Organizations could suffer significant financial losses, reputational damage, and operational disruption. The scope of the impact depends on the attacker’s objectives and the level of access they gain within the environment.

Recommendation

Deploy the Sigma rule “RDP Enabled via Registry” to detect modifications to the fDenyTSConnections registry key (rules).
Monitor process creation events for suspicious use of reg.exe or PowerShell to modify registry keys related to RDP (rules).
Implement network segmentation and firewall rules to restrict RDP traffic to authorized hosts (overview).
Review the privileges assigned to users and ensure the principle of least privilege is enforced (overview).
Enable Sysmon registry event logging to capture registry modifications (setup).
Investigate any alerts related to registry modifications on critical systems (overview).

PsExec Lateral Movement via Network Connection

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

This detection identifies the execution of PsExec, a dual-use tool commonly employed for both legitimate administration and malicious lateral movement. PsExec, part of the Sysinternals Suite, allows for remote command execution with elevated privileges, often abused by attackers to disable security controls and move laterally within a network. This rule specifically detects the creation of PsExec.exe followed by a network connection initiated by the process, which is a strong indicator of potential malicious activity. While PsExec has legitimate uses, its prevalence in attack scenarios necessitates careful monitoring. The rule is designed to work with data from Elastic Defend, SentinelOne Cloud Funnel, and Sysmon.

Attack Chain

An attacker gains initial access to a system within the network (e.g., via phishing or exploiting a vulnerability).
The attacker uploads or transfers the PsExec tool (PsExec.exe) to the compromised host, potentially using SMB shares or other file transfer methods.
The attacker executes PsExec with the -accepteula flag, which suppresses the license dialog, potentially indicating a first-time execution on the machine.
PsExec establishes a network connection to a remote target system, leveraging SMB/Windows Admin Shares (T1021.002) to facilitate remote command execution.
The attacker uses PsExec to execute commands on the remote system, potentially with SYSTEM privileges, to install malware, gather credentials, or perform reconnaissance.
The attacker leverages the newly compromised system as a pivot point to move laterally to other systems within the network, repeating the process.
The attacker escalates privileges on multiple systems.
The attacker achieves their objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to widespread compromise across the network. Attackers can leverage PsExec to gain control over critical systems, disable security controls, and exfiltrate sensitive data. Lateral movement facilitated by PsExec can enable attackers to rapidly expand their footprint within an organization, impacting numerous systems and services. While the rule’s severity is low due to the dual-use nature of PsExec, the potential impact of unchecked lateral movement is significant.

Recommendation

Deploy the Sigma rule PsExec Network Connection to your SIEM and tune the process.executable and process.parent.executable filters for your environment to reduce false positives.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into PsExec activity.
Review and enforce the principle of least privilege to limit the accounts that can run PsExec and access sensitive systems.
Investigate any alerts generated by the PsExec Network Connection rule promptly to determine if the activity is legitimate or malicious.
Monitor network connections originating from systems where PsExec is executed using the PsExec Outbound Network Connection Sigma rule.

Potential Lateral Tool Transfer via SMB Share

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

This detection rule identifies the potential transfer of malicious tools within a Windows environment using SMB shares. Attackers commonly leverage SMB shares to propagate malware, tools, or scripts to compromised systems for lateral movement. The rule focuses on detecting the creation or modification of executable files (e.g., .exe, .dll, .ps1) on network shares, which is a strong indicator of malicious activity. The rule leverages Elastic Defend data to detect this activity and can be used to identify systems that may be compromised. This technique is used to deploy additional payloads, credential dumpers, or other malicious tools.

Attack Chain

An attacker gains initial access to a system within the network.
The attacker identifies accessible SMB shares within the compromised environment.
The attacker uses the compromised system to connect to a target SMB share (port 445) on another system.
The attacker copies an executable file (e.g., malware, a credential dumping tool, or a PowerShell script) to the SMB share.
The target system detects a new file creation or change event on the SMB share.
A user or process on the target system executes the transferred file.
The executed file performs malicious actions on the target system, such as credential theft or lateral movement.
The attacker uses the newly compromised system to further expand their access within the network.

Impact

Successful exploitation allows attackers to propagate malware or malicious tools throughout the network, leading to widespread compromise. Lateral movement enables attackers to access sensitive data, escalate privileges, and ultimately achieve their objectives, which may include data exfiltration, ransomware deployment, or system disruption. The rule aims to detect this activity early in the attack chain and mitigate potential damage.

Recommendation

Deploy the provided Sigma rules to your SIEM to detect suspicious executable file creation/modification events on SMB shares.
Enable Elastic Defend on all Windows endpoints to provide the necessary data for the detection rule to function.
Investigate any alerts triggered by the Sigma rules, focusing on the process execution chain, file reputation, and user activity.
Review and restrict write access to network shares to minimize the risk of unauthorized file transfers.
Monitor network connections to port 445 (SMB) for suspicious activity, especially connections originating from unusual source IPs (Sigma rule, log source).

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.

Outbound SMB Traffic Detection

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

This detection identifies outbound Server Message Block (SMB) traffic from internal hosts to external servers. The activity is identified by monitoring network traffic for SMB requests directed towards the Internet, an unusual occurrence in standard operations. This analytic is crucial for Security Operations Centers (SOCs) as it can signal an attacker’s attempt to retrieve credential hashes via compromised internal systems, a critical step in lateral movement and privilege escalation. The source mentions specific relevance to “Hidden Cobra Malware”, “DHS Report TA18-074A”, and “NOBELIUM Group”, suggesting possible connections to these threat actors or campaigns.

Attack Chain

An internal host is compromised through an initial access vector (e.g., phishing, exploit).
The attacker attempts to enumerate network resources accessible from the compromised host.
The attacker leverages SMB to connect to external servers, typically on ports 139 or 445.
The SMB connection attempts to authenticate or negotiate with the external server.
The attacker may attempt to exploit vulnerabilities in the SMB protocol or server.
The attacker captures or relays credential hashes transmitted over the SMB connection.
The attacker uses the captured credentials to move laterally to other systems or escalate privileges.
The attacker achieves their final objective, such as data exfiltration or system compromise.

Impact

Successful exploitation of outbound SMB traffic can lead to unauthorized access to sensitive data and full system compromise. Lateral movement and privilege escalation are key goals. Confirmed malicious SMB traffic could enable attackers to move through the network, potentially impacting numerous systems and leading to significant data breaches. While the number of victims isn’t specified, the detection’s relevance to known threat actors suggests potentially widespread impact.

Recommendation

Deploy the Sigma rule Outbound SMB Traffic Detected to your SIEM and tune it for your environment, using the provided positive and negative test cases to ensure accurate detection.
Investigate and block any detected outbound SMB connections that are not explicitly authorized by legitimate business needs (reference detect_outbound_smb_traffic_filter macro in the original search).
Implement network segmentation to restrict internal hosts from directly accessing external SMB services.
Enforce strong password policies and multi-factor authentication to mitigate the impact of credential theft.
Categorize internal CIDR blocks as internal in your asset management system to reduce false positives (reference “known_false_positives” section).
Consider blocking external communications of all SMB versions and related protocols at the network boundary.

NullSessionPipe Registry Modification for Lateral Movement

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

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

Attack Chain

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

Impact

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

Recommendation

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

Incoming Execution via WinRM Remote Shell

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

Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. This detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM (winrshost.exe), flagging potential unauthorized remote executions. The rule is designed for data generated by Elastic Defend, but also supports SentinelOne Cloud Funnel and Sysmon event logs. This detection can help identify attackers moving laterally within a Windows environment.

Attack Chain

The attacker gains initial access to a machine within the network (e.g., via phishing or exploiting a vulnerability).
The attacker uses this compromised machine to scan the network for potential targets with WinRM enabled.
The attacker attempts to authenticate to a target machine using stolen credentials or by exploiting a vulnerability in WinRM.
Upon successful authentication, the attacker establishes a WinRM session to the target machine over ports 5985 (HTTP) or 5986 (HTTPS).
The attacker executes malicious commands on the target machine using the WinRM remote shell, often leveraging winrshost.exe.
The executed commands may include reconnaissance activities (e.g., whoami, net user), privilege escalation attempts, or malware deployment.
The attacker may use the compromised target to pivot to other systems, repeating the process and expanding their foothold.
The final objective is typically data exfiltration, system compromise, or deployment of ransomware.

Impact

Successful exploitation via WinRM can lead to unauthorized access to sensitive data, system compromise, and lateral movement within the network. Attackers can leverage WinRM to execute arbitrary commands, deploy malware, and ultimately achieve their objectives, such as data theft or ransomware deployment. The impact can range from individual system compromise to widespread network breaches, depending on the attacker’s goals and the organization’s security posture.

Recommendation

Enable Sysmon process creation (Event ID 1) and network connection (Event ID 3) logging to provide the necessary data for the Sigma rules.
Deploy the Sigma rule Detect Incoming WinRM Remote Shell Execution via Network Connection to identify suspicious network connections on ports 5985 and 5986.
Deploy the Sigma rule Detect Suspicious WinRM Processes to detect suspicious processes spawned by winrshost.exe.
Review and whitelist known administrative IP addresses or users to reduce false positives as noted in the rule documentation.
Implement network segmentation to limit the ability of threats to move laterally across the network as described in the remediation steps.

GPO Scheduled Task Abuse for Privilege Escalation and Lateral Movement

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

Attackers can abuse Group Policy Objects (GPOs) to execute scheduled tasks at scale, compromising objects controlled by a given GPO. This involves modifying the contents of the \\Machine\\Preferences\\ScheduledTasks\\ScheduledTasks.xml file. By altering the XML file to include malicious commands, attackers can achieve privilege escalation or lateral movement within the domain. This technique leverages a legitimate Active Directory mechanism, making it essential to differentiate between authorized administrative actions and malicious activities. The modification can be identified through changes to gPCMachineExtensionNames or gPCUserExtensionNames attributes within Active Directory.

Attack Chain

Attacker gains initial access to a system with permissions to modify GPOs.
Attacker modifies the ScheduledTasks.xml file within the SYSVOL share of a targeted GPO (\\\\*\\SYSVOL).
The attacker changes the contents of the XML file to include a malicious and tag.
The modified GPO is replicated to domain controllers.
Target systems receive the updated GPO during regular group policy refresh cycles.
The scheduled task defined in the modified ScheduledTasks.xml is executed on the target systems.
The malicious command executes, potentially escalating privileges or facilitating lateral movement.
Attacker achieves desired objective, such as installing malware, creating new accounts, or exfiltrating data.

Impact

Successful exploitation allows attackers to execute arbitrary code on systems managed by the modified GPO. The scope of impact depends on the targeted GPO and the permissions of the scheduled task. This can lead to widespread compromise, affecting numerous systems and users within the domain. The modification of GPOs can be difficult to detect without proper monitoring, potentially allowing attackers to maintain persistence and control over the environment.

Recommendation

Enable and monitor Windows audit policies for “Audit Directory Service Changes” and “Audit Detailed File Share” to detect modifications to GPOs and file share access, as outlined in the setup section.
Deploy the Sigma rule “Scheduled Task Execution via GPO Attribute Modification” to detect modifications to the gPCMachineExtensionNames or gPCUserExtensionNames attributes (rule: Scheduled Task Execution via GPO Attribute Modification).
Deploy the Sigma rule “Scheduled Task XML File Modification in SYSVOL” to detect modifications to the ScheduledTasks.xml file in SYSVOL shares (rule: Scheduled Task XML File Modification in SYSVOL).
Review and validate any changes to GPOs, specifically those related to scheduled tasks, to ensure they are authorized and legitimate.
Monitor for the execution of unexpected or malicious commands originating from scheduled tasks created or modified via GPOs.
Regularly audit and review GPO configurations to identify any potential weaknesses or misconfigurations that could be exploited.

AWS STS GetFederationToken with AdministratorAccess in Request

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

The AWS Security Token Service (STS) GetFederationToken API allows for the creation of temporary security credentials for federated users. These credentials inherit permissions from the calling IAM user and any session policy included in the request. This detection focuses on instances where the request parameters of GetFederationToken reference AdministratorAccess, either directly or through an equivalent string. The inclusion of AdministratorAccess within the session policy grants overly broad privileges to the temporary credentials, potentially leading to privilege escalation or abuse. This scenario is often indicative of legacy systems, misconfigured tooling, or malicious intent, posing a significant risk to the security posture of AWS environments. Defenders should prioritize identifying and mitigating instances of this behavior to enforce least privilege principles and prevent unauthorized access.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised IAM user credentials or an exploited vulnerability.
The attacker identifies an IAM user with the necessary permissions to call the STS GetFederationToken API.
The attacker crafts a GetFederationToken API request, including a session policy that directly references “AdministratorAccess” or includes a policy ARN that grants administrator privileges.
The GetFederationToken API call is successfully executed, generating temporary security credentials with broad administrator permissions.
The attacker uses the temporary credentials to perform privileged actions within the AWS environment, such as modifying IAM policies, accessing sensitive data, or deploying malicious resources.
The attacker may attempt to laterally move within the AWS environment by leveraging the newly acquired administrator privileges to compromise other resources or accounts.
The attacker could establish persistence by creating new IAM users or roles with elevated permissions, ensuring continued access even after the temporary credentials expire.
The attacker achieves their final objective, which could include data exfiltration, service disruption, or financial gain.

Impact

Successful exploitation can lead to complete compromise of the AWS environment. An attacker with temporary administrator credentials can modify security configurations, access sensitive data, and disrupt critical services. While no specific victim counts or sectors are mentioned, the broad permissions granted by AdministratorAccess make any AWS environment vulnerable to significant damage. The risk score of 73 highlights the potential for severe impact.

Recommendation

Deploy the Sigma rule “AWS STS GetFederationToken with AdministratorAccess in Request” to your SIEM to detect instances of this activity (rule title).
Investigate any alerts generated by the Sigma rule, focusing on the aws.cloudtrail.request_parameters to identify the specific policy being used (rule title).
Revoke or rotate the IAM user access keys involved in the GetFederationToken call and enforce least privilege on the user (rule description).
Monitor CloudTrail logs for subsequent events using response_elements.credentials.accessKeyId from the same response to identify actions taken with the temporary credentials (rule description).
Review and update IAM policies to ensure that session policies used with GetFederationToken adhere to the principle of least privilege (rule description).
Implement automated checks to prevent the creation or modification of IAM policies that grant AdministratorAccess except in explicitly approved scenarios (rule description).

AWS EC2 Instance Profile Associated with Running Instance

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

This threat brief focuses on the potential for privilege escalation and lateral movement within Amazon Web Services (AWS) environments by abusing the ability to associate or replace IAM instance profiles on running EC2 instances. An attacker with the necessary permissions (ec2:AssociateIamInstanceProfile or ec2:ReplaceIamInstanceProfile and typically iam:PassRole) can elevate the privileges of a compromised EC2 instance. This is achieved by attaching a more privileged IAM role to the instance, granting the attacker access to resources and permissions beyond their initial scope. The event is logged in AWS CloudTrail, providing a critical detection opportunity for security teams.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or a vulnerable application.
The attacker identifies a running EC2 instance with limited privileges.
The attacker identifies or creates a more privileged IAM role that grants broader access to AWS resources.
The attacker uses the AssociateIamInstanceProfile or ReplaceIamInstanceProfile API calls to associate the privileged IAM role with the target EC2 instance. This requires appropriate IAM permissions.
The EC2 instance’s metadata service now provides credentials for the newly associated IAM role.
The attacker leverages the elevated privileges to access sensitive data or resources, potentially including other EC2 instances, databases, or storage buckets.
The attacker moves laterally within the AWS environment, compromising additional resources and escalating their access.
The attacker achieves their objective, such as exfiltrating data, deploying malicious code, or disrupting services.

Impact

Successful exploitation allows attackers to elevate privileges within the AWS environment, potentially leading to unauthorized access to sensitive data, lateral movement to other systems, and disruption of critical services. The impact could range from data breaches and financial losses to reputational damage and regulatory fines. Identifying and responding to these events quickly is crucial to minimizing potential damage.

Recommendation

Deploy the Sigma rule “AWS EC2 Instance Profile Associated with Running Instance” to your SIEM using AWS CloudTrail logs to detect suspicious activity.
Review and harden IAM permissions related to ec2:AssociateIamInstanceProfile and ec2:ReplaceIamInstanceProfile to limit who can modify instance profiles.
Enable CloudTrail logging for all regions in your AWS account to ensure comprehensive audit coverage.
Implement least privilege principles for IAM roles assigned to EC2 instances to minimize the impact of potential privilege escalation.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address, user identity, and the IAM role associated with the instance profile.

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.

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 Remote Registry Access via SeBackupPrivilege

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious RDP Client Image Load

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

This detection identifies suspicious instances of the Remote Desktop Services ActiveX Client (mstscax.dll) being loaded from unusual or unauthorized locations on Windows systems. Attackers may leverage RDP lateral movement techniques by loading this DLL in unauthorized contexts to gain access and control over other systems within the network. The rule focuses on detecting anomalous loading patterns of mstscax.dll outside typical system paths, which can be indicative of malicious lateral movement attempts. This detection is applicable to environments using Elastic Defend and Sysmon.

Attack Chain

An attacker compromises a system within the network.
The attacker attempts to move laterally using RDP.
To facilitate the RDP connection, the attacker executes a process that loads the mstscax.dll.
The mstscax.dll is loaded from a location outside the standard system paths (e.g., not from C:\Windows\System32).
The system logs the image load event, capturing the process and the location from which mstscax.dll was loaded.
The detection rule identifies the unusual loading of mstscax.dll based on the configured criteria.
The attacker establishes a remote desktop session to a target system.
The attacker gains control over the target system, enabling further malicious activities.

Impact

A successful attack can allow unauthorized access to sensitive systems and data, leading to potential data breaches, financial losses, and reputational damage. Lateral movement via RDP can allow attackers to expand their control within the network, compromising additional systems and escalating the impact of the attack. Early detection of suspicious mstscax.dll loading can prevent further propagation of the attack.

Recommendation

Deploy the Sigma rule Suspicious RDP Client Image Load to your SIEM and tune the process.executable exclusions for your environment to reduce false positives.
Enable Sysmon Event ID 7 (Image Loaded) to capture the necessary data for the Sigma rule Suspicious RDP Client Image Load to function.
Review the process executable path in alerts to determine if mstscax.dll was loaded from an unusual or unauthorized location.
Investigate the network connections associated with the process to identify any suspicious remote connections or lateral movement attempts as described in the Overview.
Implement network segmentation to limit the ability of adversaries to move laterally within the network as described in the Overview.

Spike in Remote File Transfers via Lateral Movement

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

The “Spike in Remote File Transfers” detection identifies potential lateral movement activity within a network by monitoring for unusual volumes of remote file transfers. Attackers often aim to locate and exfiltrate valuable information after gaining initial access. To evade detection, they may attempt to mimic normal egress activity through numerous small transfers. This detection leverages machine learning to establish a baseline of normal transfer activity and identify deviations that may indicate malicious behavior. The rule requires the Lateral Movement Detection integration assets to be installed. For Elastic Defend events on versions 8.18 and above, host.ip collection must be enabled.

Attack Chain

Initial Access: An attacker gains initial access to a host within the network through an exploit or compromised credentials.
Internal Reconnaissance: The attacker performs internal reconnaissance to identify valuable data and potential target systems.
Lateral Movement: The attacker uses stolen credentials or exploits remote services (T1210) to gain access to other systems on the network.
Tool Transfer: The attacker transfers malicious tools or scripts (T1570) to the compromised systems to facilitate further actions.
Data Collection: The attacker gathers sensitive data from the compromised systems.
Egress Activity: The attacker initiates numerous small remote file transfers, attempting to blend in with normal network traffic.
Data Exfiltration: The attacker exfiltrates the stolen data to an external location.

Impact

A successful lateral movement attack involving anomalous file transfers can lead to data exfiltration, intellectual property theft, and reputational damage. Even though the severity is low, undetected lateral movement can escalate quickly into high severity incidents like ransomware or data breaches. This detection focuses on the early stages of lateral movement, allowing security teams to respond before significant damage occurs.

Recommendation

Ensure host IP collection is enabled in Elastic Defend configurations, following the steps in the helper guide.
Install the Lateral Movement Detection integration assets as described in the setup instructions in the rule documentation.
Investigate alerts generated by the “Spike in Remote File Transfers” rule, paying close attention to the source and destination of the file transfers.
Review authentication logs for signs of compromised accounts, such as unusual login times or locations, as described in the rule’s triage notes.
Tune the machine learning job’s anomaly threshold based on your environment’s baseline activity and false positive analysis.

SMB Registry Hive Exfiltration

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

This threat brief addresses the potential exfiltration of Windows registry hives via SMB shares, a tactic often employed after credential dumping. Attackers target sensitive hives like the Security Account Manager (SAM) to extract cached credentials. By copying these hives to an attacker-controlled system, they evade local host-based detection and facilitate offline credential decryption. The Elastic detection rule a4c7473a-5cb4-4bc1-9d06-e4a75adbc494 identifies the creation or modification of registry hive files (identified by the “regf” header) exceeding 30KB on SMB shares, specifically when performed by the SYSTEM process (PID 4) under a user context associated with system accounts (S-1-5-21 or S-1-12-1). This behavior raises suspicion, particularly when observed outside expected file paths. Defenders should monitor for this activity as it often precedes lateral movement and further compromise.

Attack Chain

Attacker gains initial access to a Windows system.
The attacker elevates privileges to SYSTEM or a similar high-privilege account.
The attacker executes a credential dumping tool (e.g., reg save HKLM\SAM sam.hive) to extract the SAM registry hive.
The attacker executes reg save HKLM\SYSTEM system.hive to extract the SYSTEM registry hive, enabling decryption of SAM secrets.
The attacker connects to a remote SMB share (e.g., \\attacker.example.com\share) from the compromised host.
The SYSTEM process (PID 4) creates or modifies a file on the SMB share, identified as a registry hive by its header (“regf”).
The exfiltrated registry hive file is larger than 30KB, bypassing size-based filtering.
The attacker utilizes the exfiltrated SAM and SYSTEM hives to extract user credentials offline, facilitating lateral movement or further malicious activities.

Impact

Successful exfiltration of registry hives can lead to widespread credential compromise, enabling attackers to move laterally within the network, access sensitive data, and potentially achieve domain dominance. The impact includes unauthorized access to critical systems, data breaches, and significant disruption of business operations. The number of affected systems directly correlates with the scope of credential access achieved by the attacker.

Recommendation

Deploy the Elastic detection rule a4c7473a-5cb4-4bc1-9d06-e4a75adbc494 or the Sigma rules provided in this brief to your SIEM and tune for your environment to detect registry hive exfiltration attempts.
Enable file creation and modification logging on SMB shares, specifically focusing on events associated with the SYSTEM process and registry hive file signatures, to increase visibility.
Review and harden SMB share permissions to restrict unauthorized access and prevent credential dumping from remote systems.
Investigate any alerts generated by these rules promptly, focusing on identifying the source host, the user account involved, and the destination SMB share.
Implement multi-factor authentication (MFA) for all user accounts to mitigate the impact of credential theft.

Remote Registry Lateral Movement via RPC Firewall

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

This threat brief focuses on detecting lateral movement attempts that leverage remote procedure calls (RPC) to modify registry keys on target systems. The technique abuses the remote registry protocol to achieve persistence or execute arbitrary code. Defenders can use RPC Firewall logs to identify and block this activity, specifically by monitoring for calls to the Registry Remote Protocol (MS-RRP) interface with specific operation numbers indicative of registry manipulation. This activity is often associated with post-exploitation phases, where attackers attempt to gain a foothold and expand their control within a network. The RPC Firewall detailed in this brief allows for monitoring and blocking of this behavior.

Attack Chain

The attacker gains initial access to a system within the network (e.g., through phishing or exploiting a vulnerability).
The attacker discovers accessible target systems on the network.
The attacker attempts to connect to the target system’s RPC endpoint for the Remote Registry service (UUID 338cd001-2244-31f1-aaaa-900038001003).
The attacker uses RPC calls with operation numbers 6, 7, 8, 13, 18, 19, 21, 22, 23, or 35 to interact with the registry remotely.
The attacker modifies registry keys related to startup programs or services.
The attacker triggers the execution of malicious code through the modified registry keys, achieving persistence.
The malicious code executes, allowing the attacker to perform actions such as data exfiltration or further lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence, escalate privileges, and move laterally within the network. This can lead to data theft, system compromise, and disruption of services. If lateral movement succeeds, attackers can gain control over critical assets, leading to significant financial and reputational damage.

Recommendation

Install and configure RPC Firewall on all critical systems, auditing RPC calls to the Registry Remote Protocol interface (UUID 338cd001-2244-31f1-aaaa-900038001003) as described in the definition within the logsource section.
Deploy the provided Sigma rule to your SIEM to detect anomalous RPC calls related to registry modification as outlined in the detection section.
Investigate and block any identified malicious RPC connections using RPC Firewall based on the logs generated and reviewed from the deployed Sigma rule.

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

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

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

Attack Chain

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

Impact

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

Recommendation

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

Mounting of Hidden or WebDav Remote Shares via Net Utility

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

The threat involves the abuse of the legitimate Windows net.exe utility to mount remote shares, including hidden (e.g., administrative shares) and WebDav shares. This activity may signal lateral movement within a network, preparation for data exfiltration, or initial access through reconnaissance of available network resources. The detection focuses on identifying specific command-line patterns used with net.exe to mount these shares. While the primary data source for the detection rule is Elastic Defend, it also supports data from CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs. This activity can be masked within normal administrative functions, so tuning and baselining are important.

Attack Chain

An attacker gains initial access to a compromised system through various means (e.g., phishing, exploiting a vulnerability).
The attacker executes net.exe or net1.exe to discover available network shares, identifying potential targets for lateral movement or data exfiltration.
The attacker uses net.exe to attempt to mount a hidden or WebDav share, often using stolen credentials or exploiting existing permissions. The command includes use and specifies a share path like \\\\\ or http(s):///.
If successful, the attacker gains access to the remote share, potentially browsing its contents to identify valuable data or resources.
The attacker copies sensitive data from the remote share to the compromised system.
The attacker stages the exfiltrated data on the compromised system, preparing it for transfer to an external location.
The attacker uses another tool or protocol (e.g., FTP, SCP, web upload) to exfiltrate the data to a destination controlled by the attacker.
The attacker cleans up any traces of their activity on the compromised system and the remote share, attempting to avoid detection.

Impact

Successful exploitation could lead to unauthorized access to sensitive data, lateral movement to other systems, and ultimately, data exfiltration. The mounting of hidden shares gives the attacker the ability to move laterally and escalate their privileges. Depending on the data stored on the shares, data breaches and financial losses are possible. Targeted sectors are broad, as net.exe is a standard Windows utility.

Recommendation

Deploy the “Mounting Hidden or WebDav Remote Shares” rule to your SIEM, tuning it for your environment to minimize false positives and detect suspicious activity.
Enable Sysmon process creation logging (Event ID 1) to capture detailed information about process executions, including net.exe and its command-line arguments as outlined in the rule description.
Investigate and validate any alerts generated by the “Mounting Hidden or WebDav Remote Shares” rule, focusing on the process details, arguments, and associated user accounts, as suggested in the rule’s triage and analysis section.
Implement network segmentation to limit lateral movement possibilities, mitigating the potential impact of successful share mounting as mentioned in the response and remediation steps.

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.

Impossible Travel Detection in Azure AD

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

This rule detects “impossible travel” events within Azure Active Directory (Azure AD), a common indicator of account compromise. The scenario involves a user account exhibiting login activity from two geographically distant locations in a timeframe that makes physical travel between them impossible. This anomalous behavior often signifies that an attacker has gained unauthorized access to the account and is operating from a different location than the legitimate user. The rule leverages Azure AD Identity Protection’s risk detection capabilities to identify such instances. This detection is crucial for defenders as it highlights potential breaches and enables swift remediation actions to prevent further damage.

Attack Chain

An attacker gains initial access to a user’s credentials, potentially through phishing (T1566), credential stuffing, or malware.
The attacker authenticates to Azure AD from a geographic location different from the legitimate user’s typical location.
Shortly after the initial authentication, the legitimate user authenticates to Azure AD from their usual location.
Azure AD Identity Protection flags the activity as “impossible travel” due to the conflicting geographic locations and the short timeframe between the authentications.
The “impossibleTravel” risk event is logged within Azure AD’s risk detection logs.
The attacker may attempt to escalate privileges within the compromised account (T1068) to gain broader access to resources.
The attacker may move laterally within the organization (T1021) to access sensitive data or systems.
The attacker’s ultimate goal could be data exfiltration, financial theft, or disruption of services, depending on the organization’s profile.

Impact

A successful “impossible travel” attack can lead to a full compromise of the user’s account, granting the attacker access to sensitive data, internal systems, and other resources accessible to the user. Depending on the user’s role and permissions, the impact could range from data breaches to financial losses and significant reputational damage. Organizations in all sectors are vulnerable, with a higher risk for those handling sensitive data or operating critical infrastructure. The number of affected users depends on the attacker’s ability to move laterally and escalate privileges after compromising the initial account.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect “impossible travel” events flagged by Azure AD Identity Protection, focusing on the riskEventType: 'impossibleTravel' (logsource: azure, service: riskdetection).
Investigate any triggered alerts promptly, focusing on the user account involved and the geographic locations of the login attempts (logsource: azure, service: riskdetection).
Review and enhance user training programs to educate employees on the risks of phishing and credential compromise (T1566).
Implement multi-factor authentication (MFA) for all users to mitigate the risk of unauthorized access even if credentials are compromised (T1110).
Review and adjust the sensitivity of Azure AD Identity Protection’s risk detection policies to align with your organization’s risk tolerance.
Consider implementing conditional access policies that restrict access based on geographic location or require MFA for logins from unfamiliar locations.

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.

High Variance in RDP Session Duration Detected via Machine Learning

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

This threat brief addresses the detection of high variance in Remote Desktop Protocol (RDP) session durations using machine learning. The detection, implemented in Elastic Security’s Lateral Movement Detection integration, aims to identify anomalous RDP usage patterns that may indicate malicious activity. Adversaries might establish long RDP sessions to maintain persistence and move laterally within a network. The prebuilt Elastic ML job “lmd_high_var_rdp_session_duration_ea” analyzes RDP session data to identify unusual deviations in session lengths, which could signify unauthorized access or malicious exploitation of compromised systems. The rule is triggered when the anomaly score exceeds a threshold of 70. Defenders should investigate any alerts generated by this rule to determine if the RDP sessions are legitimate or indicative of malicious activity.

Attack Chain

Initial Access: An attacker gains initial access to a system via phishing or exploiting a vulnerability (not detailed in the source).
RDP Enabled: The attacker enables RDP on the compromised host or utilizes existing RDP configurations.
Credential Theft: The attacker steals credentials from the initially compromised system (not detailed in the source).
Lateral Movement: Using the stolen credentials, the attacker establishes an RDP session to another host within the network.
Session Persistence: The attacker maintains a long and variable RDP session to the target host, potentially evading detection mechanisms.
Privilege Escalation: The attacker attempts to escalate privileges on the target host to gain further control (not detailed in the source).
Data Exfiltration/Malware Deployment: The attacker uses the established RDP session to exfiltrate sensitive data or deploy malware to other systems (not detailed in the source).

Impact

Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and potential deployment of malware or ransomware. While the exact number of potential victims is unknown, organizations that heavily rely on RDP for remote access are particularly vulnerable. This can disrupt business operations, lead to data breaches, and cause significant financial losses. The low severity of this rule reflects its nature as an anomaly detection rather than a signature-based detection of confirmed malicious activity.

Recommendation

Ensure host.ip field is populated for Elastic Defend events by following the helper guide.
Install the Lateral Movement Detection integration assets as described in the setup section of the rule.
Review and tune the anomaly threshold in the “High Variance in RDP Session Duration” rule in Elastic to minimize false positives based on your environment.
Investigate any alerts generated by the “High Variance in RDP Session Duration” rule by following the triage steps outlined in the rule’s note section.