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

Enumerating Domain Trusts via DSQUERY.EXE

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

The dsquery.exe utility is a command-line tool in Windows used to query Active Directory. Attackers may leverage dsquery.exe to discover domain trust relationships within a Windows environment, mapping out potential lateral movement paths. This discovery is often an early stage in reconnaissance, before an attacker attempts to move laterally to other systems. This activity can be detected across various endpoint detection platforms including Elastic Defend, CrowdStrike, Microsoft Defender XDR, and SentinelOne. This activity is not inherently malicious, as administrators also use it for legitimate purposes.

Attack Chain

An attacker gains initial access to a compromised host within the target environment.
The attacker executes dsquery.exe with the argument objectClass=trustedDomain to enumerate domain trusts.
The command execution is logged by endpoint detection and response (EDR) solutions or Windows Security Event Logs.
The attacker parses the output of the dsquery.exe command to identify trusted domains and their attributes.
The attacker uses the discovered trust information to plan lateral movement strategies.
The attacker attempts to authenticate to other systems within the trusted domains using stolen credentials or other exploits.

Impact

Successful enumeration of domain trusts enables attackers to map out the Active Directory environment and identify potential pathways for lateral movement. While the enumeration itself is low impact, it facilitates subsequent actions like credential theft, privilege escalation, and data exfiltration. This can lead to widespread compromise across the organization, impacting numerous systems and sensitive data.

Recommendation

Deploy the Sigma rule “Detect Enumerating Domain Trusts via DSQUERY.EXE” to your SIEM and tune for your environment.
Investigate any execution of dsquery.exe with the argument objectClass=trustedDomain to identify potentially malicious activity.
Monitor process execution events for dsquery.exe to detect suspicious command-line arguments and execution patterns.

AWS EC2 Role GetCallerIdentity from New Source AS Organization

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

This detection identifies when an EC2 instance role session calls the AWS STS GetCallerIdentity API from a source Autonomous System (AS) Organization name that has not been previously observed. The GetCallerIdentity API is often used by adversaries to validate stolen instance role credentials from infrastructure outside the victim’s normal egress points. By baselining the combination of identity and source network, the rule reduces noise associated with stable NAT or AWS-classified egress, focusing on truly novel access patterns. This detection is specifically designed to complement other rules that may detect general GetCallerIdentity calls, by excluding previously seen combinations of user identity and source AS organization.

Attack Chain

An attacker gains unauthorized access to an EC2 instance through methods like exploiting a Server-Side Request Forgery (SSRF) vulnerability, compromising application code or exploiting IMDS abuse.
The attacker leverages the instance’s IAM role to obtain temporary AWS credentials.
The attacker attempts to validate the stolen credentials using the GetCallerIdentity API call.
The GetCallerIdentity API call originates from an IP address associated with a new and unexpected Autonomous System Organization (ASO).
The AWS CloudTrail logs record the GetCallerIdentity event, including the user identity ARN and the source AS organization name.
The detection rule triggers due to the new combination of user identity and source AS organization.
The attacker uses the validated credentials to perform reconnaissance and identify valuable resources within the AWS environment (e.g., S3 buckets, databases).
The attacker attempts to exfiltrate sensitive data or deploy malicious workloads using the stolen credentials.

Impact

A successful attack can lead to unauthorized access to sensitive data stored within the AWS environment. The attacker may be able to escalate privileges, compromise other resources, and disrupt services. The potential impact includes data breaches, financial loss, and reputational damage. The lack of specific victim counts or sectors targeted suggests a broad applicability across various AWS users.

Recommendation

Deploy the Sigma rule “AWS EC2 Role GetCallerIdentity from New Source AS Organization” to your SIEM to detect suspicious activity.
Investigate alerts triggered by the Sigma rule, focusing on the aws.cloudtrail.user_identity.arn and source.as.organization.name fields.
Monitor AWS CloudTrail logs for GetCallerIdentity API calls, particularly those originating from unfamiliar source IP addresses and ASNs.
Revoke compromised IAM role sessions by stopping the affected EC2 instances or removing the role from the instance profile.
Rotate any long-lived secrets accessible by the EC2 instance, based on the aws.cloudtrail.user_identity.access_key_id.

AWS Discovery API Calls from VPN ASN by New Identity

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

This detection identifies the first-time occurrence of an IAM principal invoking discovery APIs from a source IP address associated with a known VPN autonomous system number (ASN). The rule focuses on high-signal discovery actions, such as credential checks, account enumeration, bucket inventory, compute inventory, and logging introspection within AWS CloudTrail logs. The goal is to detect potential reconnaissance activities originating from anonymizing networks, which may indicate malicious intent. The rule specifically omits broad List* and Describe* patterns to reduce false positives, focusing instead on a curated list of ASNs commonly associated with VPN providers and hosting services. It’s important to validate ASN data using local intelligence and tailor the event.action list based on your environment’s baseline. Hosting ASNs are dual-use and require careful monitoring.

Attack Chain

An attacker gains unauthorized access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
The attacker initiates a VPN connection to mask their origin and evade geographic restrictions or monitoring. The VPN endpoint’s ASN belongs to a known VPN provider.
Using the compromised credentials and VPN connection, the attacker calls the AWS API to execute GetCallerIdentity to validate access.
The attacker enumerates IAM users and roles using ListUsers and ListRoles to map out the AWS environment’s identity landscape.
The attacker inventories S3 buckets using ListBuckets to identify potential targets for data exfiltration or manipulation.
The attacker gathers information about EC2 instances, VPCs, and security groups using DescribeInstances, DescribeVpcs, and DescribeSecurityGroups to understand the network infrastructure.
The attacker lists available Lambda functions using ListFunctions to discover potential code execution opportunities.
The attacker collects logging configurations by calling DescribeTrails to identify logging gaps.

Impact

A successful attack leveraging these discovery techniques can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the AWS environment. By mapping out the cloud infrastructure, attackers can identify vulnerabilities and misconfigurations to exploit. Compromised AWS environments can result in data breaches, service disruptions, and financial losses.

Recommendation

Deploy the Sigma rule AWS Discovery API Calls from VPN ASN by New Identity to detect anomalous discovery activity originating from VPN ASNs.
Review the curated list of VPN-oriented ASNs within the rule query and update it with local intelligence from sources like RIPE, BGPView, or PeeringDB.
Enable AWS CloudTrail logs to capture the necessary event data for the Sigma rule to function effectively.
Tune the Sigma rule’s event.action filter to include additional discovery-related API calls relevant to your environment, based on baseline analysis.
Investigate alerts generated by the Sigma rule by examining aws.cloudtrail.user_identity.arn, event.action, event.provider, source.ip, and source.as.organization.name.
Implement automated response actions, such as revoking sessions or rotating keys, when unexpected discovery activity is detected from VPN ASNs.

Rapid Enumeration of AWS S3 Buckets

hello@craftedsignal.io — Fri, 01 May 2026 19:43:38 +0000

This threat brief covers suspicious activity related to the rapid enumeration of AWS S3 buckets. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs from the same source IP address within a short timeframe. This pattern is often associated with reconnaissance efforts, security scanning tools, or post-compromise enumeration activities. The behavior is similar to that observed with CSPM tools and by threat actors like Team PCP. The detection specifically excludes AWS service principals and requires programmatic-style sessions (i.e., not Management Console credentials). It focuses on scenarios where resource and identity fields are populated to avoid skewed results from null values. The detection threshold is set to greater than 15 distinct aws.cloudtrail.resources.arn values within a 10-second window.

Attack Chain

An attacker gains initial access to an AWS environment using compromised credentials or through an exposed IAM role. (T1530)
The attacker authenticates to AWS using the obtained credentials, creating a programmatic session.
The attacker issues a series of GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning API calls to S3.
These API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).
The attacker collects information about the bucket’s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)
The collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.
The attacker uses identified vulnerabilities to exfiltrate data.
The attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.

Impact

Successful enumeration of S3 buckets can lead to the discovery of sensitive data, misconfigurations, and publicly accessible resources. This can result in data breaches, unauthorized access, and further compromise of the AWS environment. The enumeration allows an attacker to map out the S3 storage landscape, identifying targets for data exfiltration or privilege escalation. The rapid nature of the enumeration suggests automated scanning or reconnaissance, potentially indicating a larger attack campaign.

Recommendation

Deploy the following Sigma rule to detect rapid S3 bucket enumeration activity based on AWS CloudTrail logs, adjusting the threshold of 15 distinct buckets to suit your environment.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address (source.ip), AWS principal ARN (aws.cloudtrail.user_identity.arn), and the list of accessed buckets (aws.cloudtrail.resources.arn).
Review IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.
Monitor CloudTrail logs for related events, such as ListBuckets, GetObject, PutBucketPolicy, AssumeRole, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.
Implement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.
Document approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.

AWS Discovery API Calls via CLI from a Single Resource

hello@craftedsignal.io — Fri, 01 May 2026 19:43:38 +0000

This detection rule identifies suspicious AWS reconnaissance activity originating from the AWS CLI. It triggers when a single AWS identity (IAM user, role, or service principal) makes more than five unique discovery-related API calls (such as Describe*, List*, Get*, or Generate*) within a 10-second window. The rule is designed to detect adversaries attempting to map out an AWS environment after gaining unauthorized access through compromised credentials or a compromised EC2 instance. The tool focuses on API calls related to key AWS services like EC2, IAM, S3, and KMS. This rule helps defenders identify and respond to early-stage reconnaissance activity, preventing further exploitation or data exfiltration. The rule excludes activity from AWS service accounts and the AWS Management Console, and it requires a minimum stack version of 9.2.0 with AWS integration version 4.6.0.

Attack Chain

Initial Access: An attacker gains access to an AWS environment, potentially through compromised credentials or by compromising an EC2 instance.
Credential Usage: The attacker leverages the AWS CLI to interact with the AWS environment using the compromised credentials.
Reconnaissance: The attacker initiates a series of discovery API calls to gather information about the AWS infrastructure. This includes using Describe*, List*, Get*, and Generate* commands.
Resource Enumeration: The attacker enumerates various AWS resources, including EC2 instances, IAM roles, S3 buckets, and KMS keys, by querying their respective APIs.
Target Identification: The attacker analyzes the gathered information to identify potential targets for further exploitation, such as vulnerable EC2 instances or misconfigured S3 buckets.
Privilege Escalation (Optional): If the compromised credentials have limited permissions, the attacker might attempt to escalate privileges to gain broader access to the AWS environment.
Lateral Movement (Optional): The attacker might attempt to move laterally to other AWS accounts or services to expand their reach and impact.
Data Exfiltration/Impact: Based on the attacker’s goals, they may attempt to exfiltrate sensitive data or cause disruption by modifying or deleting resources.

Impact

Successful exploitation could lead to unauthorized access to sensitive data, such as customer information, intellectual property, or financial records. The attacker could also disrupt business operations by modifying or deleting critical resources. Identifying and responding to such activity in a timely manner can help prevent significant damage and maintain the security and integrity of the AWS environment.

Recommendation

Deploy the following Sigma rule to your SIEM and tune for your environment to detect the described reconnaissance activity.
Enable AWS CloudTrail logging for all AWS regions and accounts in your organization to ensure the required logs are available for detection.
Investigate any alerts generated by the Sigma rule, focusing on identifying the affected AWS identity, the source IP address, and the specific API calls made (as captured by the Sigma rule).
If suspicious activity is confirmed, follow AWS’s incident-handling guidance, including disabling or rotating the access key used and restricting outbound connectivity from the source (reference the AWS Security Incident Response Guide).

AWS STS GetCallerIdentity API Called for the First Time

hello@craftedsignal.io — Fri, 10 Apr 2026 16:48:32 +0000

The AWS Security Token Service (STS) GetCallerIdentity API allows a user to retrieve information about the IAM user or role associated with the credentials being used. While a legitimate user should already know the account they are operating in, an attacker with compromised credentials may use this API to verify the validity of the credentials and enumerate account details. This activity, especially when observed for the first time from a particular user identity, can indicate malicious reconnaissance. This detection focuses on identifying the initial use of the GetCallerIdentity API, excluding instances where an assumed role is involved due to the common practice of using GetCallerIdentity after assuming a role. This event is flagged as anomalous, potentially signaling unauthorized access or credential misuse within an AWS environment.

Attack Chain

An attacker gains unauthorized access to AWS credentials, either through phishing, credential stuffing, or compromised systems.
The attacker uses the compromised credentials to authenticate to the AWS environment.
The attacker executes the sts:GetCallerIdentity API call to identify the associated AWS account ID, IAM user, or role.
The AWS STS service processes the request and returns the identity information to the attacker.
The attacker analyzes the returned identity information to understand the scope and privileges of the compromised credentials.
The attacker uses the gathered information to perform further reconnaissance activities, such as identifying accessible resources and services.
Based on the discovered information, the attacker may attempt to escalate privileges or move laterally within the AWS environment.
The final objective could include data exfiltration, deployment of malicious workloads, or disruption of services.

Impact

Successful exploitation and undetected reconnaissance can lead to significant damage, including unauthorized access to sensitive data, compromised workloads, and disruption of critical services. The impact can range from data breaches and financial losses to reputational damage and regulatory fines. Depending on the scope of the compromised credentials, the attacker may be able to access and control a large portion of the AWS environment. In the event of a breach, the organization may incur costs related to incident response, data recovery, and legal settlements.

Recommendation

Deploy the Sigma rule “AWS STS GetCallerIdentity API Called for the First Time by New Identity” to your SIEM and tune for your environment to detect anomalous usage of the GetCallerIdentity API.
Investigate any alerts generated by the Sigma rule, focusing on identifying the source IP address, user agent, and the user identity associated with the API call.
Review IAM permission policies for the user identity associated with the GetCallerIdentity API call to ensure the least privilege principle is followed.
Enable AWS CloudTrail logging for all AWS regions in your account to ensure comprehensive event logging, as required by the detection rule.
Consider adding exceptions based on user.id or aws.cloudtrail.user_identity.arn values for automation workflows that legitimately rely on the GetCallerIdentity API, as mentioned in the overview.
Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise, as suggested in the documentation.

Kubernetes Endpoint Permission Enumeration

hello@craftedsignal.io — Thu, 05 Mar 2026 13:13:30 +0000

This detection identifies potential endpoint enumeration attempts within a Kubernetes environment. An attacker, or a compromised account, may attempt to map accessible resources within the Kubernetes cluster by issuing a burst of API calls across multiple endpoints from a single user and source IP address. This is achieved through a combination of both successful and failed API requests. The behavior is not typical of normal Kubernetes cluster operation. Attackers leverage this reconnaissance to identify high-value targets like secrets, pods, or nodes before attempting privilege escalation or lateral movement. The rule specifically looks for unusual patterns in Kubernetes audit logs.

Attack Chain

The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.
The attacker uses kubectl or a similar tool to send a series of API requests.
The attacker attempts to enumerate Kubernetes API endpoints using “get”, “list”, “watch”, “create”, “update”, and “patch” verbs.
The requests target a variety of resources, including pods, services, deployments, secrets, and nodes.
The attacker analyzes the responses to identify endpoints and resources that are accessible with the current credentials. Successful and failed responses are both valuable for mapping permissions.
The attacker identifies valuable targets, such as secrets or sensitive data stored in configmaps.
The attacker attempts to escalate privileges by exploiting identified vulnerabilities or misconfigurations.
The attacker moves laterally within the cluster to gain access to other resources or workloads.

Impact

Successful enumeration can lead to privilege escalation, lateral movement, and data exfiltration within the Kubernetes cluster. Attackers can identify and compromise sensitive resources such as secrets, configmaps, and pods. The number of affected systems and the scope of the impact depend on the extent of the attacker’s access and the sensitivity of the compromised resources.

Recommendation

Enable Kubernetes audit logging to capture API server requests and responses, which is required for the provided rules and the original Elastic rule.
Deploy the Sigma rules provided below to your SIEM to detect enumeration attempts and tune them based on your environment.
Enforce the principle of least privilege by assigning appropriate RBAC roles to users and service accounts to limit potential enumeration damage.
Monitor Kubernetes audit logs for unusual API request patterns, specifically a high number of requests from a single user and IP address.
Review RBAC bindings for unexpected or overly broad access as mentioned in the overview.
Segment API access with network controls (private endpoint/VPN allowlists) as suggested in the response section of the overview.

Potential Enumeration via Active Directory Web Service

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

The Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. This attack involves loading Active Directory related modules and establishing network connections to the ADWS dedicated TCP port 9389. The goal is to gather information about the domain, user accounts, and permissions, which can be used for lateral movement, privilege escalation, and data exfiltration. Detection focuses on identifying suspicious processes loading System.DirectoryServices*.dll or System.IdentityModel*.dll and then connecting to the ADWS port.

Attack Chain

An attacker gains initial access to a compromised host within the target network.
The attacker executes a reconnaissance tool or script (e.g., PowerShell) on the compromised host.
The reconnaissance tool loads Active Directory related modules such as System.DirectoryServices*.dll and System.IdentityModel*.dll.
The reconnaissance tool attempts to establish a network connection to the ADWS service on TCP port 9389, the dedicated port for ADWS.
The tool queries ADWS to retrieve information about domain users (T1087.002), groups (T1069.002), systems (T1018), and permissions.
The attacker analyzes the gathered information to identify privileged accounts and potential targets for lateral movement.
The attacker uses the discovered information to move laterally within the network.
The attacker escalates privileges, and exfiltrates sensitive data.

Impact

Successful exploitation allows attackers to gain detailed knowledge of the Active Directory environment. This information can be used to identify high-value targets, compromise privileged accounts, move laterally within the network, and ultimately achieve their objectives, which could include data theft, ransomware deployment, or disruption of services. The impact can range from data breaches to complete compromise of the Active Directory domain, depending on the attacker’s goals and the level of access they achieve.

Recommendation

Deploy the Sigma rule “Potential ADWS Enumeration via Suspicious Library Loading” to detect processes loading AD-related DLLs (e.g., System.DirectoryServices*.dll, System.IdentityModel*.dll).
Deploy the Sigma rule “Potential ADWS Enumeration via Network Connection” to monitor for network connections to destination port 9389 from unusual processes.
Review and whitelist legitimate administrative tools or scripts that load Active Directory-related modules and connect to the ADWS port as described in the “False positive analysis” section of the original rule documentation.
Implement network segmentation to limit access to the ADWS port (9389) to only trusted systems and users.

Detection of Obfuscated IP Address Usage in Download Commands

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

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

Attack Chain

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

Impact

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

Recommendation

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

Group Policy Discovery via Microsoft GPResult Utility

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

Attackers may leverage the gpresult.exe utility, a built-in Windows tool, to gather information about Group Policy Objects (GPOs) within an Active Directory environment. This reconnaissance activity allows adversaries to understand the existing security policies, identify potential misconfigurations, and discover pathways for privilege escalation or lateral movement. The rule focuses on detecting the execution of gpresult.exe with specific command-line arguments (/z, /v, /r, /x) commonly associated with malicious reconnaissance. This behavior is typically observed after an initial compromise, where the attacker is attempting to map out the network and identify valuable targets. This activity matters for defenders as it provides an early indicator of post-compromise activity and can help prevent further damage.

Attack Chain

The attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using stolen credentials.
The attacker executes gpresult.exe from the command line or through a script.
The attacker uses command-line arguments such as /z, /v, /r, or /x to request detailed information about Group Policy settings.
gpresult.exe queries the Active Directory domain to retrieve GPO information applicable to the user or computer.
The attacker parses the output of gpresult.exe to identify security policies, user rights assignments, and other relevant configurations.
The attacker identifies potential weaknesses in the GPO configuration, such as overly permissive user rights or insecure password policies.
The attacker uses the gathered information to exploit identified weaknesses and escalate privileges or move laterally to other systems within the network.
The attacker achieves their objective, such as data exfiltration, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to a comprehensive understanding of the target environment’s security posture, enabling attackers to identify and exploit weaknesses for privilege escalation and lateral movement. While the source does not specify a number of victims or sectors targeted, the impact of a successful attack can range from data breaches and financial losses to reputational damage and disruption of operations. The discovery of misconfigured group policies can open doors for attackers to compromise critical systems and data within the network.

Recommendation

Deploy the Sigma rule “Group Policy Discovery via GPResult” to your SIEM to detect the execution of gpresult.exe with suspicious parameters.
Enable Windows process creation logging to capture command-line arguments used with gpresult.exe and other executables.
Review and harden Group Policy configurations to minimize the risk of exploitation by attackers.
Investigate any alerts generated by the Sigma rule “Group Policy Discovery via GPResult” to determine the context and intent of the activity.

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.

Account Discovery Command via SYSTEM Account

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

This detection rule identifies instances where the SYSTEM account is used to execute account discovery utilities, such as whoami.exe and net1.exe. This behavior is commonly observed after an attacker has successfully achieved privilege escalation within a Windows environment, or after exploiting a web application. The rule is designed to detect post-exploitation discovery activity where an adversary attempts to gain situational awareness by enumerating accounts and system information using the elevated SYSTEM context. The rule leverages data from Elastic Defend and Sysmon Event ID 1 to identify these behaviors, helping defenders spot potential privilege escalation and lateral movement attempts. The original rule was created 2020/03/18 and updated 2026/05/04.

Attack Chain

An attacker gains initial access to a system, potentially through exploiting a vulnerability in a web application or through phishing.
The attacker escalates privileges to the SYSTEM account, possibly by exploiting a local privilege escalation vulnerability.
The attacker executes whoami.exe or net1.exe via the SYSTEM account to enumerate user accounts and gather system information.
The whoami.exe or net1.exe process is spawned by a parent process such as a web server process (e.g., w3wp.exe) or a service process.
The attacker uses the discovered account information to plan further actions, such as lateral movement or credential theft.
The attacker may use net1.exe to query domain information.
The attacker leverages the gained information to identify valuable targets within the network.
The final objective is often data exfiltration, deployment of ransomware, or further compromise of the network.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Although this rule has low severity, the execution of discovery commands by the SYSTEM account can be a critical indicator of compromise. Early detection of such activity can prevent more severe damage.

Recommendation

Deploy the provided Sigma rules to detect account discovery commands executed via the SYSTEM account and tune for your environment.
Enable Sysmon process creation logging (Event ID 1) to ensure the necessary data is available for detection.
Investigate any alerts generated by these rules, focusing on the process execution chain to identify the source of the SYSTEM account usage.
If the process tree includes a web-application server process, investigate suspicious file creation or modification to assess for webshell backdoors.
Review and harden web application security to prevent initial access and privilege escalation.

Suspicious PDF Reader Child Process Activity

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

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

Attack Chain

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

Impact

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

Recommendation

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

Windows Account Discovery of Administrator Accounts

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

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

Attack Chain

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

Impact

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

Recommendation

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

Suspicious Enumeration Commands Spawned via WMIPrvSE

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

MSIExec Spawning Discovery Commands

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

This detection focuses on identifying suspicious behavior where msiexec.exe, a legitimate Windows utility for installing, uninstalling, and configuring software, is used to spawn multiple discovery commands. This activity is often associated with attackers attempting to gather system information, enumerate the network, and identify potential targets for lateral movement. The technique is typically observed post-compromise, after initial access has been achieved through other means. This behavior matters to defenders as it is a key indicator of malicious activity and potential privilege escalation or data exfiltration attempts. The detection leverages Endpoint Detection and Response (EDR) data, specifically process creation events, to identify instances where msiexec.exe is the parent process of common discovery tools.

Attack Chain

An attacker gains initial access to the system through a vulnerability, phishing, or other means.
The attacker leverages msiexec.exe to execute discovery commands.
msiexec.exe spawns processes such as ipconfig.exe, net.exe, systeminfo.exe, or wmic.exe to gather network configuration, user information, and system details.
The attacker uses commands within cmd.exe or powershell.exe to execute the discovery commands. For example, cmd.exe /c ipconfig /all or powershell.exe Get-NetIPConfiguration.
The attacker filters the output of these commands to identify valuable information such as domain names, user accounts, and system architecture.
The attacker uses the gathered information to identify potential targets for lateral movement and privilege escalation.
The attacker attempts to move laterally to other systems using stolen credentials or exploits.

Impact

Successful exploitation of this technique can lead to a comprehensive understanding of the compromised environment. Attackers can leverage gathered information to escalate privileges, move laterally to other systems, and ultimately exfiltrate sensitive data or deploy ransomware. The impact could range from a single compromised workstation to a complete network breach, depending on the scope of the attacker’s activity.

Recommendation

Enable process monitoring and command-line logging on all endpoints to capture the necessary data for detection.
Deploy the Sigma rule MSIExec Spawning Discovery Commands to your SIEM and tune it to your environment.
Investigate any instances of msiexec.exe spawning multiple discovery commands, as this behavior is unusual in normal system operations.
Implement least privilege principles to limit the impact of compromised accounts and prevent lateral movement.

Kubernetes Multi-Resource Discovery Reconnaissance

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

After gaining initial access to a Kubernetes cluster, adversaries often conduct reconnaissance to understand the environment before further actions like exfiltration or privilege escalation. This involves mapping the cluster’s structure, identifying workloads, and understanding role-based access control (RBAC) configurations. This reconnaissance is achieved by rapidly querying various API resources, including namespaces, pods, roles, ClusterRoles, ConfigMaps, and ServiceAccounts. The activity is characterized by a burst of get and list requests across multiple resource types within a short timeframe, which is atypical for normal cluster operations and may indicate malicious probing or permission reconnaissance. This detection focuses on identifying such cross-resource bursts from a single client to distinguish reconnaissance activities from routine automation.

Attack Chain

The attacker gains initial access to the Kubernetes cluster using compromised credentials or by exploiting a vulnerability. (T1190, T1566)
The attacker authenticates to the Kubernetes API server using the compromised credentials or a valid service account token.
The attacker begins enumerating namespaces to understand the logical divisions within the cluster using kubectl get namespaces or equivalent API calls. (T1068)
The attacker queries pods within the discovered namespaces to identify running workloads and potential targets. (T1068)
The attacker lists roles and cluster roles to understand the existing RBAC configurations and identify potential privilege escalation opportunities. (T1069)
The attacker retrieves service accounts to identify applications and their associated permissions, potentially discovering more attack vectors.
The attacker analyzes the collected information to identify vulnerable services, misconfigured permissions, or sensitive data.
Based on the reconnaissance, the attacker proceeds with lateral movement, privilege escalation, data exfiltration, or other malicious objectives.

Impact

Successful reconnaissance allows attackers to gain a comprehensive understanding of the Kubernetes environment, facilitating further malicious activities such as lateral movement, privilege escalation, and data exfiltration. This can lead to the compromise of sensitive data, disruption of services, and unauthorized access to critical resources. The impact is magnified in clusters with weak RBAC policies or exposed sensitive information.

Recommendation

Deploy the Sigma rule “Kubernetes Multi-Resource Discovery” to your SIEM and tune for your environment to detect reconnaissance activities.
Investigate alerts generated by the Sigma rule by pivoting on user.name, source.ip, and user_agent.original to determine the sequence of API calls.
Correlate the identified activity with RBAC configurations to identify potential violations of the principle of least privilege as described in the rule’s Triage and Analysis section.
Baseline automation by allowlisting known service accounts or source networks that legitimately span multiple resource types in a short window, as described in the rule’s False Positive Analysis section.
Review and tighten RBAC configurations to minimize the impact of compromised credentials as described in the Response and Remediation section.

Windows Netsh Tool Used for Firewall Discovery

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

This detection focuses on identifying instances where the netsh.exe utility is used to query firewall configurations on a Windows system. While netsh.exe is a legitimate tool for network configuration, adversaries can leverage it to gather information about firewall rules and settings. This information can then be used to plan further attacks, such as bypassing firewall restrictions or identifying vulnerable network services. This activity is typically seen during the reconnaissance phase of an attack. The scope of this detection covers any Windows environment where Endpoint Detection and Response (EDR) logs are available.

Attack Chain

An attacker gains initial access to a compromised system through various means, such as phishing or exploiting a vulnerability.
The attacker executes netsh.exe with specific commands to enumerate firewall rules and configurations (e.g., netsh firewall show state, netsh firewall show config).
The netsh.exe process retrieves the requested firewall information from the Windows operating system.
The collected firewall information is parsed to identify potential weaknesses or misconfigurations.
The attacker uses the gathered information to modify existing firewall rules or create new rules to allow unauthorized access.
The attacker leverages the modified firewall configuration to establish a covert communication channel or to move laterally within the network.
The attacker attempts to exfiltrate sensitive data or deploy ransomware.

Impact

Successful exploitation can lead to unauthorized network access, data exfiltration, or the deployment of ransomware. The enumeration of firewall configurations can provide attackers with valuable insights into the network’s security posture, enabling them to bypass security controls and compromise critical assets. This can result in significant financial losses, reputational damage, and disruption of business operations.

Recommendation

Deploy the Sigma rule Detect Suspicious Netsh Firewall Discovery to your SIEM and tune for your environment to detect netsh.exe executions with firewall discovery commands.
Enable Sysmon process-creation logging (Event ID 1) to capture the necessary command-line details.
Investigate any identified instances of netsh.exe being used to query firewall settings, especially when initiated from unusual processes or user accounts.
Monitor parent-child process relationships to identify suspicious process spawning, as highlighted by the Processes.parent_process_name field.
Review firewall configurations regularly to identify and remediate any misconfigurations or overly permissive rules.

Suspicious Whoami Process Activity

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

The whoami utility is commonly used by attackers post-compromise to gather information about the current user and their privileges on a compromised system. This information helps attackers assess their level of access and plan further actions within the environment, such as privilege escalation or lateral movement. This activity is most concerning when executed by SYSTEM accounts or from unusual parent processes. This detection identifies unusual or suspicious executions of whoami.exe, especially when associated with system privileges or specific parent processes known to be abused by attackers. The rule is designed to function across various Windows environments and considers potential false positives from legitimate administrative tools.

Attack Chain

Initial Access: The attacker gains initial access to the Windows system through an exploit or compromised credentials.
Privilege Escalation (Optional): The attacker may attempt to elevate privileges to a higher level, potentially SYSTEM.
Discovery: The attacker executes whoami.exe to determine the current user and their privileges.
Information Gathering: The attacker analyzes the output of whoami.exe to understand the context of the compromised system.
Lateral Movement (Conditional): Based on the information gathered, the attacker may attempt to move laterally to other systems.
Further Exploitation: The attacker leverages the gathered information to further exploit the compromised system or network.
Persistence (Optional): The attacker may establish persistence to maintain access to the compromised system.
Objective Completion: The attacker achieves their final objective, such as data exfiltration or system disruption.

Impact

Successful exploitation and reconnaissance can allow attackers to gain a deeper understanding of a compromised system. This may lead to further exploitation, lateral movement, and ultimately, the exfiltration of sensitive data or the disruption of critical services. While the whoami command itself is not inherently malicious, its suspicious usage often indicates malicious activity within a compromised environment. The severity is low because the execution of whoami by itself is not enough to confirm malicious activity, and further investigation is needed.

Recommendation

Enable process creation logging with command line arguments to detect whoami.exe executions (reference: logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*).
Deploy the Sigma rule “Whoami Process Activity” to your SIEM and tune for your environment (reference: rule).
Investigate parent processes of whoami.exe for any suspicious or unusual activity (reference: Attack Chain).
Monitor for other discovery commands executed around the same time as whoami.exe (reference: Related rules).
Review and tune the false positives outlined in the rule to minimize noise (reference: false_positives).

Suspicious MS Office Child Process

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

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

Attack Chain

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

Impact

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

Recommendation

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

Enumeration of Privileged Local Groups Membership

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

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

Attack Chain

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

Impact

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

Recommendation

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

Active Directory Discovery via ADExplorer Execution

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

ADExplorer is an advanced Active Directory (AD) viewer and editor, it includes the ability to save snapshots of an AD database for offline viewing and comparisons. Adversaries may abuse this utility to perform domain reconnaissance, gather sensitive information about the AD structure, user accounts, and group memberships. The execution of ADExplorer is a potential indicator of malicious activity, especially when observed in environments where its use is not typical or when executed by unauthorized users. This activity can lead to further exploitation, such as privilege escalation and lateral movement within the network.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., compromised credentials, phishing).
The attacker downloads the ADExplorer utility (ADExplorer.exe) to the compromised host.
The attacker executes ADExplorer.exe to begin enumeration of the Active Directory environment.
ADExplorer interacts with the Active Directory domain controllers, querying information about users, groups, computers, and organizational units.
The attacker may use ADExplorer to save snapshots of the AD database for offline analysis.
The attacker analyzes the gathered information to identify privileged accounts, critical assets, and potential vulnerabilities within the AD environment.
The attacker uses the discovered information to plan further attacks, such as lateral movement or privilege escalation.

Impact

Successful execution of ADExplorer by malicious actors can lead to the discovery of sensitive information about the Active Directory environment. This information can be leveraged to facilitate lateral movement, privilege escalation, and data exfiltration. While the initial risk score is low, the reconnaissance activity enables follow-on attacks that can have severe consequences, potentially leading to full domain compromise.

Recommendation

Implement the Sigma rule Detect ADExplorer Execution via Process Name to detect the execution of ADExplorer based on process name.
Implement the Sigma rule Detect ADExplorer Execution via Original File Name to detect the execution of ADExplorer based on the process’s original file name.
Monitor process creation events on Windows endpoints for the execution of ADExplorer.exe or processes with an original file name of “AdExp” to detect potential reconnaissance activities.
Investigate and validate any execution of ADExplorer by non-administrator accounts.
Review ADExplorer use and restrict its usage to authorized personnel.

Windows Peripheral Device Discovery via fsutil

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

Attackers may leverage native operating system tools like fsutil.exe to perform reconnaissance activities within a compromised environment. The fsutil fsinfo drives command provides information about connected drives, including removable media, mapped network drives, and backup locations. Discovery of these devices can help adversaries identify valuable data stores for exfiltration or encryption as part of a broader attack campaign. This command can be run interactively or via automated scripts, making it a versatile tool for post-exploitation activities. Defenders should monitor for unusual execution of fsutil with the fsinfo drives arguments, particularly when executed by non-administrative users or from unusual locations.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The attacker executes fsutil.exe via command line or script.
The fsutil command uses the fsinfo subcommand.
The fsinfo subcommand uses the drives argument to list connected drives.
The system returns a list of attached drives and their types (e.g., local, network, removable).
The attacker analyzes the output to identify potentially valuable targets.
The attacker moves laterally to access identified drives.
The attacker exfiltrates sensitive data or deploys ransomware on the identified drives.

Impact

Successful discovery of peripheral devices can lead to the identification of backup locations, mapped network drives, and removable media containing sensitive information. This information enables attackers to expand their reach within the compromised environment and increase the potential for data theft, encryption, or destruction. The low severity reflects the fact that this activity on its own is simply reconnaissance; the actual damage comes from subsequent actions.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious execution of fsutil.exe (see below).
Enable process creation logging with command line arguments to capture fsutil executions (see setup instructions in the Overview).
Investigate any process executions of fsutil.exe where the parent process is unexpected or the user context is unusual (see Triage and Analysis).

Suspicious Access to LDAP Attributes

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

This rule identifies read access to a high number of Active Directory object attributes, which can help adversaries find vulnerabilities, elevate privileges, or collect sensitive information. The rule focuses on event code 4662, filtering for ‘Read Property’ access where the number of properties accessed is greater than or equal to 2000. The rule is designed to detect potential reconnaissance activities within an Active Directory environment, providing security teams with insights into unusual access patterns that may indicate malicious intent. This detection logic helps security teams proactively identify and respond to potential threats targeting Active Directory environments.

Attack Chain

The attacker gains initial access to a system within the target network, possibly through compromised credentials or a phishing attack (not directly covered in the provided source).
The attacker uses the compromised account to query Active Directory via LDAP.
The attacker issues a series of LDAP queries, requesting a large number of attributes for various Active Directory objects, triggering event ID 4662.
The event logs record the excessive number of read property accesses (winlog.event_data.Properties), exceeding the threshold of 2000.
The attacker analyzes the gathered information to identify potential targets, such as privileged accounts, sensitive data stores, or vulnerable systems.
The attacker attempts to elevate privileges by exploiting identified vulnerabilities or misconfigurations within Active Directory.
The attacker uses the elevated privileges to access sensitive information or move laterally within the network.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to gather sensitive information about the Active Directory environment, identify potential vulnerabilities, elevate privileges, and move laterally within the network. This can lead to data breaches, system compromise, and significant disruption to business operations. The number of victims and sectors targeted are dependent on the scope and objectives of the attacker.

Recommendation

Enable Audit Directory Service Access to generate the necessary events (event code 4662) as mentioned in the setup instructions.
Deploy the Sigma rule “Suspicious Access to LDAP Attributes” to your SIEM and tune the threshold (length(winlog.event_data.Properties) >= 2000) for your environment.
Review event logs for event code 4662, focusing on the winlog.event_data.Properties field, to understand which attributes were accessed.
Investigate the source machine from which the LDAP queries originated by examining the winlog.event_data.SubjectUserSid field.

Kubernetes Secrets Enumeration from Non-Loopback Client

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

This detection identifies Kubernetes Secrets listing events originating from non-loopback clients. Attackers may attempt to enumerate Kubernetes Secrets to gain access to sensitive information such as credentials, API keys, and other confidential data stored within the cluster. The rule specifically focuses on requests targeting cluster-wide secrets or list operations under the kube-system or default namespaces, which are often targeted due to their high concentration of sensitive information. This activity is indicative of potential credential access or discovery attempts within the Kubernetes environment. This rule helps defenders identify and respond to potential reconnaissance or lateral movement activities within their Kubernetes clusters.

Attack Chain

An attacker gains initial access to a node within the Kubernetes cluster or a system with access to the Kubernetes API.
The attacker authenticates to the Kubernetes API server using compromised credentials or by exploiting a vulnerability.
The attacker crafts a list request targeting the /api/v1/secrets endpoint to enumerate all secrets in the cluster.
Alternatively, the attacker targets secrets within the kube-system namespace using /api/v1/namespaces/kube-system/secrets or default namespace using /api/v1/namespaces/default/secrets.
The API server responds with a list of secrets, potentially including sensitive information.
The attacker analyzes the retrieved secrets to identify valuable credentials or configuration data.
The attacker uses the acquired credentials to escalate privileges, move laterally within the cluster, or access external resources.

Impact

Successful enumeration of Kubernetes secrets can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and significant financial losses. The targeting of kube-system and default namespaces poses a particularly high risk due to the presence of core system components and sensitive configurations.

Recommendation

Deploy the Sigma rule Kubernetes Secrets List in Sensitive Namespaces to your SIEM to detect suspicious secret enumeration activities based on kubernetes.audit.requestURI.
Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for list operations on the secrets resource, specifically targeting /api/v1/secrets and sensitive namespaces.
Implement network policies to restrict access to the Kubernetes API server from untrusted networks.
Review and harden the security configuration of the kube-system and default namespaces.
Enforce the principle of least privilege for service accounts and user access to minimize the impact of credential compromise.
Investigate any alerts generated by the Sigma rule and correlate with other security events to identify potential attacks.