Amazon — CraftedSignal Threat Feed

AWS SSM Session Manager Child Process Execution Abuse

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

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

Attack Chain

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

Impact

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

Recommendation

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

AWS IAM Privilege Operations via Lambda Execution Role

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

This threat focuses on the abuse of AWS Lambda execution roles to perform sensitive IAM operations. Lambda functions, often running with over-permissioned roles, can be exploited by adversaries to escalate privileges and establish persistence within an AWS environment. An attacker gaining control of a Lambda function can leverage its execution role to make IAM API calls that would normally require elevated permissions. This includes creating new IAM users or roles, attaching policies to existing IAM entities, and modifying EC2 instance profiles. The scope of this threat includes any AWS environment utilizing Lambda functions with IAM permissions.

Attack Chain

An attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.
The attacker leverages the Lambda function’s execution role, which has excessive IAM permissions.
The attacker executes IAM API calls, such as CreateUser, CreateRole, or CreateAccessKey, to create new IAM identities.
The attacker uses AttachUserPolicy, PutUserPolicy, AttachRolePolicy, or PutRolePolicy to grant elevated permissions to the newly created or existing IAM identities.
The attacker modifies instance profiles using CreateInstanceProfile and AddRoleToInstanceProfile to prepare EC2 instances for lateral movement.
The attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via sts:AssumeRole.
The attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.
The attacker establishes persistence by creating rogue IAM users, roles, or access keys.

Impact

A successful attack can lead to full compromise of the AWS environment. An attacker could create highly privileged IAM users and roles, granting them the ability to access and control all AWS resources. This can result in data breaches, service disruptions, and financial losses. The impact is magnified in environments where Lambda functions are heavily relied upon for critical business operations.

Recommendation

Deploy the Sigma rule “AWS IAM Sensitive Operations via Lambda Execution Role” to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.
Review and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.
Monitor aws.cloudtrail.user_identity.arn to identify the Lambda function and associated deployment path responsible for the IAM API calls.
Investigate aws.cloudtrail.request_parameters for targets such as userName, groupName, roleName, policyArn, or instanceProfileName to understand the scope of the IAM operations.
Revoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.
Remediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.

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.

Local Privilege Escalation Vulnerability 'Copy Fail' in Linux Kernel

hello@craftedsignal.io — Thu, 30 Apr 2026 13:54:47 +0000

A local privilege escalation vulnerability, “Copy Fail” (CVE-2026-31431), impacts Linux kernels released since 2017. Discovered by Theori’s AI-driven pentesting platform Xint Code, the vulnerability allows an unprivileged local attacker to gain root permissions. Theori reported the finding to the Linux kernel security team on March 23, 2026, and patches became available within a week. A proof-of-concept exploit was published, demonstrating a 732-byte script that can root every Linux distribution shipped since 2017. This vulnerability stems from a logic bug in the Linux kernel’s authencesn cryptographic template. Theori demonstrated successful exploits on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16.

Attack Chain

An unprivileged local attacker gains access to a vulnerable Linux system.
The attacker utilizes the AF_ALG socket-based interface to access Linux kernel crypto functions from user space.
The attacker uses the splice() system call to perform a controlled 4-byte write in the page cache of a readable file, instead of a normal buffer.
The attacker targets a setuid-root binary file for modification.
The 4-byte write alters the behavior of the setuid-root binary.
The attacker executes the modified setuid-root binary.
Due to the altered behavior, the binary grants the attacker elevated privileges.
The attacker gains root privileges on the system.

Impact

Successful exploitation of the Copy Fail vulnerability (CVE-2026-31431) allows an unprivileged local attacker to gain root privileges on a vulnerable Linux system. Theori demonstrated and confirmed the exploit on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16, highlighting the widespread impact. Multi-tenant Linux hosts, Kubernetes/container clusters, CI runners/build farms, and cloud SaaS environments running user code are at high risk.

Recommendation

Apply available kernel patches for CVE-2026-31431 on affected Linux distributions, prioritizing multi-tenant environments (e.g., Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16).
As an interim mitigation, disable the vulnerable crypto interface by blocking AF_ALG socket creation or disabling the algif_aead module, as described in the overview.
Monitor for the execution of unusual processes after the modification of binaries in /tmp or /var/tmp using the Sigma rule “Detect Suspicious Splice Usage for Privilege Escalation”.
Deploy the Sigma rule “Detect algif_aead module removal” to detect attempts to disable the vulnerable module.

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.

Suspicious AWS EC2 Key Pair Import Activity

hello@craftedsignal.io — Thu, 19 Dec 2024 00:00:00 +0000

The unauthorized import of SSH key pairs into Amazon Elastic Compute Cloud (EC2) is a technique that malicious actors can leverage to gain unauthorized access to EC2 instances. By importing their own key pairs, attackers can bypass existing security measures and gain persistent access to compromised systems. This activity is often part of a broader attack campaign aimed at compromising sensitive data, disrupting services, or establishing a foothold within an organization’s cloud infrastructure. The initial publication of the detection rule was in December 2024, highlighting the ongoing relevance of this technique in cloud security. Monitoring for this activity can help defenders identify and respond to potential security breaches in a timely manner.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.
The attacker attempts to enumerate existing EC2 instances to identify potential targets.
The attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.
The attacker uses the ImportKeyPair API call within the EC2 service to import the generated or obtained SSH key pair.
The attacker modifies the EC2 instance’s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.
The attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.
Once inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.
The attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.

Impact

A successful key pair import can lead to complete compromise of the affected EC2 instances, potentially impacting dozens of servers depending on the environment. Sensitive data stored on or accessible from these instances could be exfiltrated, leading to financial loss, reputational damage, and regulatory fines. Furthermore, compromised instances can be used as a launchpad for further attacks within the AWS environment, leading to a wider breach. The financial impact can range from tens of thousands to millions of dollars, depending on the scale of the breach and the sensitivity of the data compromised.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect ImportKeyPair events in CloudTrail logs (logsource: aws, service: cloudtrail).
Review IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: ’ec2.amazonaws.com’, eventName: ‘ImportKeyPair’).
Investigate any detected ImportKeyPair events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.

Detect AWS Route Table Modification via CloudTrail

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

The addition of a new route to an AWS route table can be a sign of malicious activity, especially if the route redirects traffic to an unexpected or unauthorized destination. This activity is typically logged in AWS CloudTrail. Attackers might add routes to intercept network traffic, conduct man-in-the-middle attacks, or impair defenses by routing traffic away from security appliances. Understanding who is performing this action and the destination of the new route is critical for identifying potential threats within an AWS environment.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker uses the AWS CLI or the AWS Management Console to interact with the EC2 service.
The attacker identifies the target route table to modify.
The attacker executes the CreateRoute API call, specifying the destination CIDR block and target (e.g., an internet gateway, virtual private gateway, or network interface).
CloudTrail logs the CreateRoute event, capturing details of the action, including the user identity, source IP address, and the route table modification.
Network traffic matching the new route’s destination CIDR block is now redirected to the attacker-controlled target.
The attacker monitors and potentially modifies the redirected traffic for reconnaissance or data exfiltration purposes.

Impact

Successful modification of AWS route tables can lead to significant security breaches. An attacker could redirect critical network traffic to a malicious endpoint, enabling them to intercept sensitive data or disrupt services. This could lead to data breaches, financial loss, and reputational damage. The scope of the impact depends on the criticality of the redirected traffic and the attacker’s objectives.

Recommendation

Deploy the “Detect AWS Route Table Modification via CloudTrail” Sigma rule to your SIEM and tune for your environment to detect suspicious route creation events in AWS CloudTrail logs.
Investigate any CreateRoute events where the user identity is unexpected or the destination CIDR block and target are suspicious.
Monitor AWS CloudTrail logs for CreateRoute events and correlate them with other suspicious activities.
Implement strict IAM policies to limit who can modify route tables (reference the eventSource and eventName fields in the rule below).

New AWS Network ACL Entry Creation Detected

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

The creation of new Network Access Control List (ACL) entries in Amazon Web Services (AWS) environments can be a sign of malicious activity. While legitimate use cases exist, adversaries can leverage these ACL changes to impair existing defenses, create new pathways for lateral movement, or establish persistence mechanisms. This activity is logged by CloudTrail and can be monitored to identify unauthorized or suspicious modifications to network security configurations. Attackers could create overly permissive rules that allow unauthorized access to critical resources or restrictive rules that disrupt legitimate traffic. Monitoring the creation of Network ACL entries is important for maintaining the integrity and security of AWS environments.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).
The attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The CreateNetworkAclEntry event is logged in CloudTrail.
The new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.
Alternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.
The attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.
The attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.

Impact

The creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.

Recommendation

Deploy the Sigma rule “New Network ACL Entry Added” to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).
Investigate any CreateNetworkAclEntry events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.
Review and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.
Monitor CloudTrail logs for other related events, such as DeleteNetworkAclEntry or ReplaceNetworkAclEntry, which may indicate further tampering with network security configurations.

Malicious Usage of AWS IMDS Credentials Outside of Expected Services

hello@craftedsignal.io — Thu, 11 Jul 2024 00:00:00 +0000

This activity focuses on the potential misuse of AWS Instance Metadata Service (IMDS) credentials. When an EC2 instance is compromised, an attacker can extract the temporary credentials stored within the IMDS. These credentials, associated with an assumed role, grant the attacker the ability to interact with other AWS services. The abnormal use of these credentials outside of the expected AWS Simple Systems Manager (SSM) service may indicate malicious activity such as lateral movement, data exfiltration, or resource compromise. This is particularly concerning when the compromised instance is being used as a pivot point to access other AWS resources.

Attack Chain

An EC2 instance is compromised through an initial access vector (e.g., software vulnerability, misconfiguration, or credential compromise).
The attacker gains access to the compromised EC2 instance’s operating system.
The attacker queries the IMDS endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) to obtain temporary AWS credentials associated with the instance’s IAM role.
The attacker configures their local AWS CLI or SDK with the exfiltrated credentials.
The attacker attempts to perform actions against other AWS services using the exfiltrated credentials.
The attacker attempts to escalate privileges or move laterally within the AWS environment.
The attacker attempts to access, modify, or exfiltrate sensitive data from other AWS services.
The attacker maintains persistence by creating new IAM users or roles with excessive permissions.

Impact

Successful exploitation can lead to unauthorized access to sensitive data stored in AWS services such as S3, DynamoDB, and RDS. This could result in data breaches, financial loss, and reputational damage. Attackers can also leverage the compromised credentials to pivot to other AWS resources, potentially impacting critical infrastructure and services. Organizations with lax security configurations and overly permissive IAM roles are at higher risk.

Recommendation

Deploy the Sigma rule “Malicious Usage Of IMDS Credentials Outside Of AWS Infrastructure” to your SIEM and tune for your environment to detect anomalous use of IMDS credentials.
Review and restrict IAM roles assigned to EC2 instances to follow the principle of least privilege, limiting the scope of potential damage from credential exfiltration.
Monitor CloudTrail logs for unusual API calls originating from EC2 instances with assumed roles, specifically those not related to SSM.
Harden EC2 instances to prevent initial compromise by applying security patches, configuring strong authentication, and regularly scanning for vulnerabilities.

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.

AWS Identity API Access from Rare ASN Organizations

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

This detection identifies AWS identities that primarily use API traffic originating from well-known cloud providers (e.g., Amazon, Google, Microsoft), but also exhibit a small amount of traffic from less common Autonomous System (AS) organizations. This pattern can indicate that automation or CI credentials are being reused or pivoted outside of their usual hosted cloud environment. The detection focuses on successful API calls and looks for a combination of high volume from trusted cloud providers and at least one sensitive action originating from an uncommon network. This behavior could be indicative of credential compromise and lateral movement. This rule was published by Elastic on 2026-04-22.

Attack Chain

An attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.
The attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.
The attacker performs reconnaissance, such as GetCallerIdentity, ListBuckets, or ListSecrets, to understand the AWS environment.
The attacker attempts to escalate privileges by calling AssumeRole, AttachUserPolicy, or CreateAccessKey.
The attacker attempts to access sensitive data using actions such as GetObject or GetSecretValue.
The attacker attempts to create new users or modify existing user profiles using actions such as CreateUser, UpdateLoginProfile, or AddUserToGroup.
The attacker may attempt to invoke cloud ML models using InvokeModel or Converse to further their objectives.
The attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.

Impact

A successful attack can lead to unauthorized access to sensitive data stored in S3 buckets, Secrets Manager, or other AWS services. It can also allow the attacker to escalate privileges, create new users, and modify existing configurations, leading to long-term control of the AWS environment. The severity of the impact depends on the level of access granted to the compromised credentials. This can lead to exfiltration of sensitive data, denial of service, or complete compromise of the AWS account.

Recommendation

Enable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (references).
Deploy the Sigma rule “AWS Rare Source AS Organization Activity” translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.
Investigate alerts generated by the rule, focusing on the user.name, aws.cloudtrail.user_identity.type, Esql.src_asn_values, and Esql.untrusted_suspicious_actions to understand the context of the activity.
Rotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.
Tighten IAM and data-plane permissions to limit the impact of compromised credentials.

S3Browser IAM Policy Creation with Default Bucket Name

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

The S3Browser utility is being used to create Inline IAM policies within AWS. This activity is flagged as suspicious when the policy includes the default S3 bucket name placeholder value of . This could indicate that the user has not properly configured the policy or is unaware of the implications of using a generic placeholder, potentially granting unintended access to S3 resources. This behavior was observed being used by the threat actor Guivil. The use of S3Browser in this manner poses a risk of privilege escalation, persistence, and unauthorized access to sensitive data stored in S3 buckets.

Attack Chain

An attacker gains initial access to an AWS account, possibly through compromised credentials or misconfigured IAM roles (T1078.004).
The attacker utilizes the S3Browser utility to interact with AWS S3 buckets.
The attacker attempts to create an Inline IAM policy using S3Browser.
The attacker fails to replace the default bucket name placeholder with a specific bucket ARN.
The attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.
The poorly configured policy is applied to a user, role, or group.
The attacker potentially escalates privileges or gains unauthorized access to S3 resources.
The attacker persists in the environment with the newly created or modified IAM policy.

Impact

Creation of an IAM policy with the default bucket name placeholder leaves S3 buckets open to potential unauthorized access. A successful attack could lead to data exfiltration, data modification, or denial of service. The scope of the impact depends on the specific permissions granted within the policy and the resources accessible through the affected IAM user, role, or group.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser Templated S3 Bucket Policy Creation” to your SIEM and tune for your environment to detect this specific activity.
Investigate any instances where PutUserPolicy events are associated with the S3Browser user agent (logsource: aws/cloudtrail).
Review existing IAM policies for the presence of the default bucket name placeholder arn:aws:s3:::/* (logsource: aws/cloudtrail).

AWS CloudTrail Logging Disabled or Modified

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

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. By recording API calls, CloudTrail provides a history of AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. Attackers may attempt to disable or modify CloudTrail logging to remove traces of their malicious activity, hindering incident response and forensic investigations. This brief focuses on detecting actions that stop logging, update the trail configuration, or delete the trail altogether. These actions directly impact an organization’s ability to detect and respond to security incidents within their AWS environment.

Attack Chain

An attacker gains unauthorized access to an AWS account with sufficient privileges.
The attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.
The attacker executes the StopLogging API call against the CloudTrail service, effectively halting the recording of events.
Alternatively, the attacker may execute the UpdateTrail API call to modify the CloudTrail configuration. This could involve changing the S3 bucket destination, disabling log file validation, or altering event selectors to exclude specific events.
As another option, the attacker may execute the DeleteTrail API call, completely removing the CloudTrail configuration from the AWS account.
After disabling, modifying, or deleting the trail, the attacker proceeds with their malicious activities, knowing that their actions are less likely to be recorded and detected.
The attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.

Impact

Disabling or modifying CloudTrail logging can have severe consequences. It impairs an organization’s ability to detect and respond to security incidents in their AWS environment. Without proper logging, incident responders may struggle to determine the scope and impact of a breach, leading to delayed or ineffective remediation efforts. The inability to audit user activity can also hinder compliance efforts and potentially lead to regulatory penalties.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect StopLogging, UpdateTrail, and DeleteTrail events in CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.
Monitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.
Enable log file validation to ensure the integrity of CloudTrail logs.
Use AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.
Review AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.

AWS KMS Key Policy Updated via PutKeyPolicy

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

This rule detects the successful execution of the PutKeyPolicy API call within Amazon Web Services Key Management Service (AWS KMS). The PutKeyPolicy action replaces the entire key policy associated with a KMS key, potentially granting new or expanded permissions to principals. An adversary who gains the ability to modify KMS key policies (kms:PutKeyPolicy) can escalate privileges by adding external accounts or roles, allowing them to decrypt data protected by the key or maintain persistent access even after credential rotation. This activity is crucial to monitor, as it can lead to significant data breaches and unauthorized access to sensitive information. The rule focuses on identifying deviations from expected KMS key policy management practices to detect potentially malicious activity.

Attack Chain

An attacker compromises an AWS account or obtains IAM credentials with sufficient permissions, including kms:PutKeyPolicy on a target KMS key.
The attacker uses the compromised credentials to call the PutKeyPolicy API, replacing the existing key policy with a modified version.
The modified key policy grants the attacker’s AWS account, or an external account, permissions to perform cryptographic operations on the key, such as kms:Decrypt or kms:GenerateDataKey.
The attacker utilizes the newly granted permissions to decrypt data encrypted with the KMS key, such as data stored in S3 buckets or EBS volumes.
The attacker may also grant administrative actions to new identities.
The attacker exfiltrates the decrypted data to an external location.
The attacker attempts to cover their tracks by deleting CloudTrail logs or modifying other security configurations.

Impact

Successful exploitation can lead to unauthorized access to sensitive data encrypted with the KMS key, potentially resulting in data breaches, financial loss, and reputational damage. The severity depends on the sensitivity of the data protected by the key and the scope of access granted to the attacker. This can impact organizations across various sectors that rely on AWS KMS for data encryption, potentially affecting millions of records and causing significant operational disruption.

Recommendation

Deploy the Sigma rule “AWS KMS Key Policy Updated via PutKeyPolicy” to your SIEM and tune for your environment to detect unauthorized modifications to KMS key policies.
Review the policy document diff in aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements to identify unauthorized changes to principals.
Restrict the kms:PutKeyPolicy permission to break-glass roles only, limiting the potential for unauthorized modifications.
Monitor iam:AttachRolePolicy and sts:AssumeRole events to correlate with potential privilege escalation attempts related to KMS key access.
Restore a known-good KMS policy from backup or IAM/KMS change history to remediate unauthorized modifications.

Successful AWS Console Login Without MFA

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

The absence of multi-factor authentication (MFA) during AWS console logins presents a significant security risk. Threat actors often target AWS environments due to the high value of data and services hosted within. An attacker gaining initial access through compromised credentials can move laterally, escalate privileges, and potentially exfiltrate sensitive data, deploy malicious workloads, or disrupt critical services. This activity can go unnoticed for extended periods, increasing the potential for damage. Detecting successful console logins without MFA is crucial for identifying potential breaches and ensuring the enforcement of security best practices. This brief focuses on detecting these logins to mitigate the risk of unauthorized access and potential data breaches.

Attack Chain

An attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.
The attacker uses the compromised credentials to attempt to log in to the AWS Management Console.
The attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.
After successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.
The attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.
The attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.
The attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.

Impact

A successful AWS console login without MFA can lead to a full compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious workloads. The lack of MFA increases the likelihood of successful credential-based attacks, potentially affecting a large number of organizations hosting data and applications in AWS. Consequences include data breaches, financial losses, reputational damage, and legal liabilities.

Recommendation

Deploy the “AWS Successful Console Login Without MFA” Sigma rule to your SIEM to detect logins without MFA (rule).
Enforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/).
Regularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.
Monitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).

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.

AWS GuardDuty Detector Deletion or Disablement

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

Attackers with sufficient AWS privileges may attempt to disable or delete AWS GuardDuty detectors to evade detection. GuardDuty is a threat detection service that monitors AWS accounts for malicious activity. Disabling it allows attackers to operate with less chance of being detected. This activity may occur post-compromise as part of a broader defense evasion strategy, or as a precursor to malicious activities. The deletion or disabling of GuardDuty detectors should be considered a critical event, warranting immediate investigation to verify legitimacy. The references suggest that this behavior has been observed in the wild and is documented across multiple security vendors.

Attack Chain

An attacker gains initial access to an AWS account through compromised credentials or other means (T1078).
The attacker enumerates existing GuardDuty detectors to identify the target for disabling or deletion (T1068).
The attacker authenticates to the AWS API using stolen credentials or an assumed role with sufficient permissions.
The attacker calls the DeleteDetector API to remove the GuardDuty detector entirely, erasing all existing findings (T1685.002).
Alternatively, the attacker calls the UpdateDetector API to disable the detector by setting the enable parameter to false (T1685.002).
AWS CloudTrail logs the DeleteDetector or UpdateDetector event with a Success or null error code.
With GuardDuty disabled, the attacker performs malicious actions such as lateral movement, data exfiltration, or resource compromise without immediate detection.
The attacker attempts to remove CloudTrail logs to further impair defenses (T1562.008).

Impact

A successful attack can lead to the complete loss of threat detection capabilities within the AWS environment. With GuardDuty disabled, malicious activities can go unnoticed, potentially leading to data breaches, unauthorized access, or resource compromise. The impact is significant because GuardDuty is a primary security control for many organizations using AWS. Depending on the attacker’s objectives, this could result in financial loss, reputational damage, or compliance violations. The references suggest that this is a known technique used by attackers to evade detection in AWS environments.

Recommendation

Deploy the Sigma rule “AWS GuardDuty Detector Deleted Or Updated” to your SIEM using AWS CloudTrail logs to detect attempts to disable or delete GuardDuty (logsource: aws, service: cloudtrail).
Investigate all instances of DeleteDetector and UpdateDetector events in CloudTrail, especially if initiated from unusual locations or IAM roles.
Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (T1110).
Enforce the principle of least privilege by granting only necessary permissions to IAM roles (T1078).
Monitor CloudTrail logs for anomalies that could indicate malicious activity following a GuardDuty disablement.

AWS SES Identity Deletion

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

This threat brief focuses on the detection of the “DeleteIdentity” event within AWS Simple Email Service (SES) logs. An adversary who has gained unauthorized access to an AWS environment and utilized SES for malicious purposes, such as sending phishing emails or distributing malware, might attempt to erase their activity by deleting the SES identity (email address or domain) used in the attack. This action is a form of obfuscation and aims to hinder forensic investigations. While legitimate users may occasionally delete SES identities, the event warrants scrutiny, especially in the context of other suspicious cloud activity.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
The attacker explores the AWS environment, identifying SES as a service to abuse for sending malicious emails.
The attacker configures SES, verifies an email address or domain, and establishes sending capabilities.
The attacker crafts and sends phishing emails or emails containing malicious attachments to external targets.
After the malicious campaign, the attacker attempts to cover their tracks by deleting the SES identity to remove evidence of their activity.
The attacker executes the “DeleteIdentity” API call within SES, specifying the identity to be removed.
AWS CloudTrail logs record the “DeleteIdentity” event, capturing details such as the event source, event name, and user identity.
The attacker may further attempt to delete or modify other CloudTrail logs to eliminate the traces of their actions.

Impact

The successful deletion of an SES identity hinders incident response and forensic investigations. If an attacker successfully removes the SES identity, it becomes more difficult to trace the origin of malicious emails and attribute the activity to a specific actor. The deletion itself does not directly cause harm, but it obstructs the ability to understand the full scope and impact of the attack.

Recommendation

Implement the provided Sigma rule (SES Identity Has Been Deleted) to detect SES identity deletion events within your CloudTrail logs.
Investigate any detected DeleteIdentity events, correlating them with other suspicious AWS activity, such as unusual IAM role usage or unauthorized access attempts.
Enable and monitor AWS CloudTrail logs for all regions within your AWS account to ensure comprehensive event capture.
Implement strong IAM policies and multi-factor authentication (MFA) to prevent unauthorized access to AWS accounts.

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.

AWS SecurityHub Findings Evasion via API Calls

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

Attackers with sufficient AWS privileges can manipulate SecurityHub findings to evade detection and maintain persistence within a compromised environment. This involves using SecurityHub’s API to either modify existing findings, delete insights altogether, or update insights to mask malicious activity. This activity is conducted via API calls to securityhub.amazonaws.com, specifically targeting the BatchUpdateFindings, DeleteInsight, UpdateFindings, and UpdateInsight actions. Successful evasion allows malicious actors to operate without triggering alarms or attracting attention from security personnel, leading to prolonged compromise and potentially greater damage. This is especially critical in production environments where SecurityHub findings are actively monitored.

Attack Chain

The attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role (T1078).
The attacker enumerates existing SecurityHub findings and insights to identify potential targets for modification or deletion.
The attacker calls the BatchUpdateFindings API to modify the severity, confidence, or resolution status of specific findings, effectively silencing alerts (T1562.003).
Alternatively, the attacker calls the UpdateFindings API to modify individual findings.
The attacker calls the DeleteInsight API to remove custom insights that could reveal their activities (T1562).
As another option, the attacker calls the UpdateInsight API to modify the criteria of existing insights, causing them to miss malicious activities.
The attacker validates the changes by querying SecurityHub to confirm that the targeted findings and insights have been successfully altered or removed.
The attacker continues malicious activities, such as data exfiltration or lateral movement, with a reduced risk of detection due to the modified SecurityHub state (TA0005).

Impact

Successful evasion of SecurityHub findings can lead to delayed incident response, prolonged attacker presence within the AWS environment, and increased data exfiltration or system compromise. The impact is particularly severe in production environments where SecurityHub is relied upon for real-time threat detection and alerting. By modifying or deleting findings, attackers can effectively blind security teams, enabling them to operate undetected for extended periods. The number of potential victims is directly proportional to the scale of AWS deployments relying on SecurityHub.

Recommendation

Deploy the Sigma rule “AWS SecurityHub Findings Evasion” to your SIEM and tune for your environment to detect suspicious API calls related to findings manipulation (logsource: aws, service: cloudtrail).
Review and harden IAM policies to restrict access to SecurityHub API actions such as BatchUpdateFindings, DeleteInsight, UpdateFindings, and UpdateInsight to only authorized users and roles.
Implement multi-factor authentication (MFA) for all AWS accounts and roles, especially those with permissions to modify SecurityHub configurations.
Regularly audit CloudTrail logs for suspicious activity related to SecurityHub configuration changes.

AWS Identity Center Identity Provider Modification

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

AWS Identity Center (formerly AWS SSO) enables centralized management of access to AWS accounts and applications. Attackers can manipulate the configured identity provider to gain unauthorized access. The modification of the configured Identity Provider (IdP) within AWS Identity Center can lead to a full compromise of the AWS environment. By associating a malicious directory or disabling/disassociating legitimate directories, attackers can potentially establish persistent access, escalate privileges, and impersonate legitimate users. This can be achieved by utilizing compromised AWS credentials or exploiting vulnerabilities in the AWS environment.

Attack Chain

Initial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.
The attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.
The attacker disassociates the existing, legitimate directory using DisassociateDirectory.
The attacker associates a malicious directory they control using AssociateDirectory. This malicious directory is configured to impersonate legitimate users.
Alternatively, the attacker disables external IdP configuration for the directory using DisableExternalIdPConfigurationForDirectory.
The attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using EnableExternalIdPConfigurationForDirectory.
The attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.
The attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.

Impact

Successful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.
Investigate any detected events related to AssociateDirectory, DisableExternalIdPConfigurationForDirectory, DisassociateDirectory, or EnableExternalIdPConfigurationForDirectory in AWS CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.
Review and restrict IAM permissions to minimize the blast radius of compromised credentials.
Monitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.

AWS IAM User or Access Key Creation via S3 Browser

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

The S3 Browser utility, a Windows-based client for managing Amazon S3 storage and other cloud services, can be abused by threat actors to create new IAM users or access keys within compromised AWS environments. This activity, if unauthorized, can lead to privilege escalation, persistence, or even initial access, depending on the context of the compromise. The use of S3 Browser is identifiable via the userAgent string in AWS CloudTrail logs. While legitimate use of S3 Browser for administrative tasks exists, its unexpected appearance in user activity, particularly in sensitive accounts, should be investigated. This activity is particularly concerning because it can allow attackers to establish a foothold in the cloud environment and move laterally.

Attack Chain

An attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.
The attacker installs and configures S3 Browser on a compromised host or uses an existing installation.
The attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.
The attacker uses S3 Browser to execute the CreateUser API call within AWS IAM.
The attacker configures the new IAM user with elevated privileges, potentially granting administrator access.
Alternatively, the attacker uses S3 Browser to execute the CreateAccessKey API call for an existing IAM user.
The attacker uses the newly created access key to perform actions within the AWS environment.
The attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.

Impact

Successful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser User or AccessKey Creation” to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.
Investigate any instances of CreateUser or CreateAccessKey events in AWS CloudTrail logs where the userAgent contains “S3 Browser”.
Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.
Review and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.

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.

Suspicious Process Accessing Sensitive Identity Files via Auditd

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

This detection focuses on identifying unauthorized access to sensitive identity files on Linux systems. It leverages Auditd to monitor file access events and flags processes that are commonly used for copying, scripting, or staging files from temporary directories. The targeted files include Kubernetes service account tokens, kubelet configurations, cloud CLI configurations for AWS, Azure, and Google Cloud, root SSH keys, and Docker configurations. These files are critical for authentication and authorization within the system, and unauthorized access could lead to credential theft, privilege escalation, or lateral movement. This is especially important in cloud environments and containerized deployments where these files are commonly used for managing access to resources. The rule is designed to exclude user home paths to avoid false positives and focus on system-level access.

Attack Chain

An attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.
The attacker uses a utility like cp, cat, or curl to access sensitive files such as /var/run/secrets/kubernetes.io/serviceaccount/token or /root/.ssh/id_rsa.
Auditd logs the file access event, capturing details about the process, user, and file path.
The detection rule identifies the suspicious process based on its name, executable path (e.g., /tmp/*), or command-line arguments.
The rule checks if the accessed file is in the list of sensitive identity files.
If both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.
The attacker exfiltrates the stolen credentials or uses them to move laterally within the network.
The attacker uses the stolen credentials to access cloud resources or other sensitive systems.

Impact

Successful exploitation 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 financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.

Recommendation

Deploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (auditctl -l) to generate the necessary logs.
Deploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.
Investigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.
Review and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule’s documentation.

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.

Suspicious AWS EC2 Key Pair Creation from Non-Cloud AS

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

This alert identifies suspicious activity related to the creation of EC2 key pairs within an AWS environment. Specifically, it focuses on instances where a new IAM principal (user) creates an EC2 key pair from a network source (IP address) whose autonomous system organization is not commonly associated with major cloud providers like Amazon, Google, or Microsoft. Adversaries often create key pairs for persistence or to enable unauthorized access to EC2 instances, potentially leading to data exfiltration or further malicious activities. The rule uses a new terms approach to baseline user activity, reducing noise from repeated actions while still flagging the initial suspicious key pair creation. This activity is flagged as suspicious due to originating from outside trusted ASNs.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.
The attacker attempts to enumerate existing EC2 instances and associated key pairs.
The attacker uses the CreateKeyPair API call to generate a new SSH key pair within the AWS account. The request originates from a network with an autonomous system organization not attributed to common cloud providers.
The attacker stores the private key material for later use in accessing EC2 instances.
The attacker may then use the new key pair to launch new EC2 instances or import the key to existing instances. This can be done through RunInstances or ImportKeyPair operations.
The attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.
Once inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.

Impact

Successful exploitation can lead to unauthorized access to EC2 instances, potentially compromising sensitive data and disrupting services. A compromised AWS account can allow the attacker to steal data, establish persistence, and move laterally within the cloud environment. The lack of expected cloud provider ASN for the source IP of the CreateKeyPair event raises the risk profile.

Recommendation

Deploy the Sigma rule “AWS EC2 CreateKeyPair from Non-Cloud AS Organization” to your SIEM and tune the source.as.organization.name exclusions based on your environment.
Review AWS CloudTrail logs for any CreateKeyPair events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.
Implement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.
Monitor for RunInstances or ImportKeyPair events using the newly created key names as identified from aws.cloudtrail.request_parameters / response_elements.
Enable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.

Mshta Making Network Connections Indicative of Defense Evasion

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

Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. This activity can be difficult to detect because Mshta.exe is a signed Microsoft binary. This detection identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. Legitimate uses of Mshta.exe include software updates, installations, and automation scripts using HTA files. This rule helps identify unauthorized network connections indicative of malicious intent and flags suspicious use of mshta.exe.

Attack Chain

An attacker gains initial access through an unknown method, such as phishing or exploiting a software vulnerability.
The attacker executes a malicious script, such as VBScript or JavaScript, using Mshta.exe.
Mshta.exe interprets and executes the script, bypassing application control policies due to its signed status.
The script establishes a network connection to an external command and control (C2) server.
The C2 server provides instructions to the compromised host, such as downloading additional malware.
The downloaded malware executes, performing actions such as data exfiltration or lateral movement.
The attacker leverages the compromised host to move laterally within the network, compromising additional systems.
The attacker achieves their objective, such as stealing sensitive data or deploying ransomware.

Impact

Successful exploitation can lead to the execution of arbitrary code, potentially compromising sensitive data, facilitating lateral movement, and establishing a persistent presence within the network. Systems affected by this activity may be used as a beachhead for further attacks, leading to significant data breaches, financial loss, and reputational damage. The number of victims can vary depending on the scope of the initial compromise and the attacker’s objectives.

Recommendation

Enable Sysmon process creation logging to capture the command-line arguments used by Mshta.exe.
Deploy the “Mshta Network Connection” Sigma rule to your SIEM and tune for your environment.
Implement application whitelisting to prevent unauthorized execution of Mshta.exe and similar system binaries.
Monitor network connections initiated by Mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints.

AWS VPC Flow Logs Deletion for Defense Evasion

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

An adversary with sufficient privileges within an AWS environment may attempt to delete VPC Flow Logs. These logs are crucial for monitoring network traffic within a VPC, and their removal can significantly impede incident response and forensic investigations. The deletion is accomplished by making a DeleteFlowLogs API call. This action is often taken to remove evidence of malicious activity, such as lateral movement, command and control communication, or data exfiltration. The impact of this activity can be severe, potentially allowing attackers to operate undetected for extended periods.

Attack Chain

The attacker gains initial access to the AWS environment through compromised credentials or an exploited vulnerability (not detailed in source).
The attacker escalates privileges within the AWS environment to gain the necessary permissions to delete VPC Flow Logs (not detailed in source).
The attacker uses the AWS CLI or AWS Management Console to execute the DeleteFlowLogs API call.
The attacker identifies the specific Flow Log IDs that need to be deleted.
The attacker authenticates to the AWS API using stolen or generated credentials.
The DeleteFlowLogs API call is made, specifying the Flow Log IDs to be deleted.
AWS processes the request and deletes the specified VPC Flow Logs.
The attacker verifies the deletion of the Flow Logs to ensure that their actions are no longer being logged.

Impact

Successful deletion of VPC Flow Logs prevents security teams from detecting malicious activity within the AWS environment. Without these logs, it becomes significantly more difficult to investigate security incidents, track attacker movements, and understand the scope of a compromise. This can lead to delayed incident response, increased dwell time for attackers, and greater overall damage. The absence of flow logs severely limits network visibility, hindering any attempt to reconstruct events or identify compromised assets.

Recommendation

Implement the Sigma rule “AWS VPC Flow Logs Deleted” to detect instances of DeleteFlowLogs API calls (reference: rules section).
Monitor CloudTrail logs for DeleteFlowLogs events and investigate any unexpected occurrences (reference: logsource).
Enforce the principle of least privilege to restrict IAM users and roles from having the ec2:DeleteFlowLogs permission unless absolutely necessary.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges.
Regularly review and audit IAM policies to ensure that permissions are appropriately scoped and not overly permissive.

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 STS AssumeRole Misuse for Lateral Movement and Privilege Escalation

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

The AWS Security Token Service (STS) AssumeRole function allows users or applications to assume a different IAM role, granting temporary access to resources and permissions associated with that role. Attackers who gain initial access to an AWS account can misuse AssumeRole to move laterally to other roles and escalate their privileges. This can occur if the initial role has overly permissive trust relationships or if an attacker can manipulate the role assumption process. This activity is detected through CloudTrail logs that record the AssumeRole event. The impact of this activity can be significant, depending on the permissions associated with the roles assumed.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies IAM roles within the AWS environment that they may be able to assume.
The attacker attempts to use the AssumeRole API call to assume a different role. This call includes parameters specifying the target role ARN and a session name.
AWS STS validates the request. Successful validation depends on the trust policy of the target role and the permissions of the initial user or role.
If the validation is successful, AWS STS returns temporary security credentials (access key ID, secret access key, and session token) to the attacker.
The attacker uses these temporary credentials to access AWS resources and perform actions authorized by the assumed role.
The attacker continues to move laterally and escalate privileges by assuming additional roles.
The attacker achieves their objective, such as accessing sensitive data, modifying configurations, or disrupting services.

Impact

Successful exploitation can lead to a wide range of impacts, including unauthorized access to sensitive data stored in S3 buckets or databases, modification or deletion of critical infrastructure configurations, and disruption of AWS services. The scope of the impact depends on the permissions associated with the roles that the attacker is able to assume. This can affect any organization using AWS, and the consequences can range from data breaches and financial losses to reputational damage and regulatory penalties.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect suspicious AssumeRole activity based on userIdentity.type and userIdentity.sessionContext.sessionIssuer.type.
Review and harden IAM role trust policies to ensure that only authorized entities can assume roles.
Monitor CloudTrail logs for unusual patterns of AssumeRole API calls, especially those originating from unfamiliar user identities or locations.
Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise.

AWS IAM Customer Managed Policy Version Manipulation for Privilege Escalation

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

This detection identifies potentially malicious activity related to AWS Identity and Access Management (IAM) policies. Specifically, it focuses on the creation of new versions of customer-managed policies (CreatePolicyVersion) and the modification of the default version (SetDefaultPolicyVersion). Attackers who have compromised IAM users or roles with sufficient permissions (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion) can use these actions to escalate their privileges within the AWS environment. By introducing a more permissive policy version and setting it as the default, attackers can gain unauthorized access to resources and perform actions that would otherwise be restricted. This activity is especially concerning when the modified policies are attached to highly privileged roles or users, such as those used for administrative tasks or break-glass scenarios.

Attack Chain

An attacker compromises an IAM user or role with permissions to modify IAM policies (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion).
The attacker identifies a customer-managed policy attached to a high-privilege role or user.
The attacker crafts a new policy version with overly permissive rules, such as wildcard actions and resources.
The attacker uses the CreatePolicyVersion API call to upload the malicious policy version to the target policy.
Alternatively, the attacker uses the SetDefaultPolicyVersion API call to set a pre-existing, but less restrictive, policy version as the default.
The compromised IAM user or role assumes the high-privilege role targeted in step 2.
The attacker gains elevated privileges based on the modified IAM policy.
The attacker performs unauthorized actions within the AWS environment, such as accessing sensitive data, modifying infrastructure, or creating new resources.

Impact

Successful exploitation can lead to significant privilege escalation, allowing attackers to gain control over critical AWS resources and data. The number of affected users and roles depends on the scope of the compromised policy and its attachments. The consequences can include data breaches, service disruptions, and financial losses. In environments where IAM policies are not closely monitored, attackers may be able to maintain their elevated access for extended periods, further compounding the damage.

Recommendation

Deploy the Sigma rule “AWS IAM Customer Managed Policy Version Created or Default Version Set” to your SIEM to detect suspicious policy modifications. Tune the rule based on your organization’s baseline activity.
Review aws.cloudtrail.request_parameters logs to identify the policyArn and policyDocument associated with the policy changes detected by the rule.
Implement strong IAM governance practices, including the principle of least privilege and regular reviews of policy permissions, to minimize the impact of policy manipulation.
Monitor CloudTrail logs for AttachUserPolicy, AttachRolePolicy, or CreatePolicyVersion spikes from the same principal as detected policy modifications.
Enable MFA for all IAM users, especially those with permissions to manage IAM policies.

AWS EC2 Stop, Start, and User Data Modification Correlation

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

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

Attack Chain

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

Impact

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

Recommendation

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

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.

AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

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

This detection rule identifies instances of successful AWS AssumeRoleWithWebIdentity calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not Amazon.com, Inc.), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.

Attack Chain

Attacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.
Attacker exfiltrates the service account token from the Kubernetes cluster.
The attacker uses the exfiltrated token to call the AWS STS AssumeRoleWithWebIdentity API.
The AssumeRoleWithWebIdentity call is made from a network with an ASN organization name that is not Amazon.com, Inc..
AWS CloudTrail logs the successful AssumeRoleWithWebIdentity event, including details about the user, source IP, and ASN organization.
The compromised IAM role is used to perform unauthorized actions within the AWS environment.
These actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.

Impact

A successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.

Recommendation

Deploy the Sigma rule AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule by following the investigation steps in the rule’s note field.
Expand the source.as.organization.name exclusions in the Sigma rule for known and trusted egress paths if needed.
Enable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of AssumeRoleWithWebIdentity calls.
Regularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.
Revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.

AWS Root Account Usage Detected

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

The use of the AWS root account should be strictly limited to specific tasks that cannot be performed with IAM users or roles. This alert indicates that the root account was used, which could signify various security concerns. An attacker with access to the root account can perform any action within the AWS environment, including creating new users, modifying security policies, accessing sensitive data, and deleting resources. Defenders should investigate each instance of root account usage to determine legitimacy. This activity may also indicate a misconfiguration where IAM roles should be used.

Attack Chain

An attacker gains access to the AWS root account credentials through credential theft or other means.
The attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.
The attacker enumerates AWS resources to identify potential targets for privilege escalation.
The attacker creates or modifies IAM policies to grant themselves additional permissions.
The attacker may create new IAM users or roles with elevated privileges.
The attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.
The attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.
The attacker could disable logging features to cover tracks.

Impact

Compromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.

Recommendation

Deploy the Sigma rule “AWS Root Credentials” to your SIEM to detect root account usage based on CloudTrail logs.
Investigate all instances of root account usage identified by the “AWS Root Credentials” Sigma rule to determine legitimacy.
Enforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in AWS documentation.
Implement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.
Regularly audit IAM policies and user permissions to identify and remove unnecessary privileges.
Disable or restrict root account access wherever possible, delegating tasks to IAM users/roles.

AWS S3 Bucket Deletion Detected via CloudTrail

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

The deletion of S3 buckets is a critical event to monitor in AWS environments. While legitimate administrative actions may involve bucket deletion, unauthorized or accidental removal of buckets can lead to significant data loss and business disruption. This brief focuses on detecting such events through AWS CloudTrail logs, which record API calls made within the AWS infrastructure. Monitoring for DeleteBucket events helps identify potential malicious activity or unintentional misconfigurations that could compromise data availability and integrity. This detection focuses on identifying DeleteBucket API calls, successful or otherwise, within CloudTrail logs to provide early warning of potential data compromise.

Attack Chain

An attacker gains unauthorized access to an AWS account through compromised credentials or a privilege escalation exploit.
The attacker lists existing S3 buckets to identify potential targets using the ListBuckets API call.
The attacker identifies a target S3 bucket containing sensitive data.
The attacker attempts to delete the target S3 bucket by issuing a DeleteBucket API call using the AWS CLI or SDK.
CloudTrail logs the DeleteBucket event, including the user identity, timestamp, and bucket name.
If successful, the S3 bucket and its contents are permanently deleted.
The attacker may attempt to remove CloudTrail logs to cover their tracks, using the DeleteTrail API call.

Impact

The deletion of an S3 bucket results in the permanent loss of all data stored within that bucket. This can lead to service disruption, data breaches, and financial losses, especially if the bucket contained critical business data or backups. The impact can range from temporary inconvenience to complete business failure depending on the criticality of the data lost and the organization’s backup and recovery capabilities. Without proper monitoring and alerting, an S3 bucket deletion can go unnoticed for extended periods, hindering incident response efforts and potentially exacerbating the damage.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect S3 bucket deletion events in CloudTrail logs.
Investigate any detected DeleteBucket events to verify their legitimacy and ensure they were authorized by appropriate personnel.
Implement multi-factor authentication (MFA) for all AWS accounts to prevent unauthorized access and reduce the risk of credential compromise.
Enforce strict IAM policies and regularly review user permissions to minimize the blast radius of compromised accounts.
Enable versioning on S3 buckets to allow for the recovery of accidentally deleted objects, mitigating the impact of data loss.
Implement data backup and disaster recovery plans to ensure business continuity in the event of a successful bucket deletion attack.

S3 Browser Used to Create IAM Login Profiles

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

The threat involves the use of the S3 Browser utility, a Windows application, to interact with Amazon Web Services (AWS) Identity and Access Management (IAM). Attackers are leveraging S3 Browser to perform reconnaissance, specifically targeting IAM users that do not have a login profile configured. Upon identifying such users, the attacker proceeds to create a login profile for them. This tactic may be indicative of an attempt to gain unauthorized access or maintain persistence within the AWS environment. The activity is detectable via AWS CloudTrail logs and was first publicly reported in May 2023 in connection with the threat actor GUIVIL.

Attack Chain

Attacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.
The attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.
S3 Browser initiates a GetLoginProfile API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.
S3 Browser, upon finding an IAM user without a login profile, initiates a CreateLoginProfile API call.
The attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.
The attacker logs into the AWS console using the newly created credentials.
The attacker leverages the IAM user’s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.
The attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.

Impact

Successful exploitation allows attackers to gain unauthorized console access to previously unprotected IAM user accounts. This can lead to privilege escalation, data breaches, and disruption of cloud services. The lack of multi-factor authentication on newly created login profiles increases the risk of account compromise. The impact can range from reconnaissance to full-scale control of the AWS environment, depending on the permissions associated with the compromised IAM users.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect GetLoginProfile and CreateLoginProfile events originating from the S3 Browser user agent in AWS CloudTrail logs.
Investigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.
Implement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.
Review IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.

AWS GuardDuty IP Set Manipulation for Defense Impairment

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

An adversary may attempt to impair an organization’s defenses by manipulating the IP sets within AWS GuardDuty. GuardDuty IP sets are used to whitelist trusted IPs or blacklist known malicious IPs. By modifying these lists, an attacker can effectively disable alerts for their malicious activity, allowing them to operate undetected within the AWS environment. This activity is typically performed after initial access and lateral movement, as the attacker seeks to maintain persistence and evade detection. The changes could be made via the AWS Management Console, CLI, or programmatically through the AWS API, making it difficult to immediately recognize the change as malicious.

Attack Chain

The attacker gains initial access to the AWS environment through compromised credentials or an exposed IAM role.
The attacker enumerates existing GuardDuty IP sets using the ListIPSets API call to identify potential targets for modification.
The attacker creates a new IP set using CreateIPSet API call, which contains malicious IPs they intend to whitelist, or the legitimate IPs of internal scanners they wish to mimic.
GuardDuty validates the uploaded IP set list.
The attacker activates the newly created IP set within GuardDuty, making it the active trusted or threat list.
The attacker conducts malicious activity, such as lateral movement, data exfiltration, or resource exploitation, from the whitelisted IPs.
GuardDuty, configured with the modified IP sets, does not generate alerts for activity originating from the whitelisted IPs.
The attacker maintains persistence and achieves their objective (e.g., data theft, denial of service) without detection.

Impact

A successful attack can lead to significant data breaches, resource compromise, and prolonged unauthorized access. The modification of IP sets within GuardDuty directly impairs the ability of security teams to detect and respond to ongoing threats. By whitelisting malicious IPs, attackers can bypass security controls and operate freely within the AWS environment. The number of affected organizations depends on the scope of the compromised AWS accounts and the extent to which GuardDuty is relied upon for threat detection.

Recommendation

Deploy the Sigma rule “AWS GuardDuty IP Set Creation” to your SIEM to detect suspicious creation of IP sets in GuardDuty (logsource: aws, service: cloudtrail).
Investigate any changes to GuardDuty configurations, particularly the creation or modification of IP sets, using CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts and IAM roles to prevent unauthorized access (related to initial access).
Regularly review and audit IAM roles and permissions to minimize the blast radius of compromised credentials.

AWS Config Service Disabling Detection

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

This threat brief focuses on detecting the disabling of AWS Config, a service that continuously monitors and records AWS resource configurations. An attacker might disable AWS Config to evade detection and prevent auditing of their malicious activities within the AWS environment. By deleting delivery channels or stopping the configuration recorder, an attacker can effectively blind the security team to changes made to AWS resources. This activity, if unauthorized, signifies a significant attempt to impair defenses. This brief provides detections based on AWS CloudTrail logs.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
The attacker enumerates existing AWS Config resources to identify the delivery channel and configuration recorder.
The attacker executes the DeleteDeliveryChannel API call to stop the delivery of configuration changes to the designated S3 bucket or SNS topic.
The attacker executes the StopConfigurationRecorder API call to halt the recording of configuration changes for AWS resources.
The attacker performs malicious actions within the AWS environment without the activity being recorded by AWS Config.
The attacker may attempt to delete CloudTrail logs, if they have sufficient permissions, to further cover their tracks.
The attacker achieves their objective, such as deploying malicious infrastructure, exfiltrating data, or disrupting services, without immediate detection.

Impact

Successful disabling of AWS Config allows attackers to operate undetected within an AWS environment. This can lead to a delayed response to security incidents, resulting in more significant data breaches, financial losses, or reputational damage. The number of affected AWS accounts and the scope of the damage depend on the attacker’s objectives and the duration of the undetected activity.

Recommendation

Deploy the Sigma rule “AWS Config Disabling Channel/Recorder” to your SIEM and tune for your environment to detect unauthorized disabling of AWS Config resources.
Review AWS IAM policies to ensure that only authorized personnel have the necessary permissions to modify or disable AWS Config settings.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.
Monitor CloudTrail logs for any attempts to disable or modify AWS Config resources, referencing the eventSource and eventName fields in the provided Sigma rule.