AWS Identity and Access Management (IAM) - CraftedSignal Threat Feed

AWS IAM CompromisedKeyQuarantine Policy Attachment

hello@craftedsignal.io — Sat, 20 Jul 2024 16:27:52 +0000

This detection identifies when the AWS-managed CompromisedKeyQuarantine or CompromisedKeyQuarantineV2 policy is attached to an IAM user. This action is performed by AWS in response to identifying compromised or publicly exposed credentials associated with that user. The attachment of this policy restricts the user's ability to perform certain actions within the AWS environment. AWS typically accompanies this action with a support case that provides specific instructions for remediating the compromised credentials and restoring normal access. The rule is designed to alert security teams to this AWS-initiated quarantine so that they can investigate the root cause of the credential compromise and follow AWS's recommended remediation steps. This activity is flagged as high severity because it confirms active credential compromise impacting the cloud environment.

Attack Chain

Credential Exposure: An IAM user's credentials (access key ID and secret access key) are exposed publicly, e.g., through a code repository, public forum, or misconfigured system.
AWS Detection: AWS detects the exposed credentials through its monitoring systems.
Policy Attachment: AWS uses the AttachUserPolicy API operation to attach the CompromisedKeyQuarantine or CompromisedKeyQuarantineV2 AWS managed policy to the affected IAM user. This policy restricts the user's permissions.
Support Case Creation: AWS creates a support case detailing the compromised credentials and providing instructions for remediation.
Notification: The AWS account owner is notified of the support case and the attached quarantine policy.
Investigation: The security team investigates the root cause of the credential exposure.
Remediation: Following the instructions in the support case, the security team disables or rotates the compromised credentials.
Policy Removal: After the compromised credentials have been addressed, the security team detaches the quarantine policy.

Impact

The attachment of the CompromisedKeyQuarantine policy by AWS indicates a significant security event. The user's access to AWS resources is immediately restricted, potentially disrupting legitimate operations. While AWS initiates this quarantine to prevent further damage, the underlying credential compromise could have allowed unauthorized access to sensitive data or resources prior to the quarantine. Successful exploitation prior to detection and remediation could lead to data breaches, resource hijacking, or other malicious activities. The number of affected users and the extent of the potential damage depend on the scope of access granted to the compromised IAM user.

Recommendation

Deploy the provided Sigma rule to detect the attachment of the CompromisedKeyQuarantine policy via the AttachUserPolicy API call in CloudTrail logs to quickly identify compromised IAM user accounts.
Review the aws.cloudtrail.request_parameters field in the CloudTrail logs to identify the specific userName that has been quarantined (as referenced in the "Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User" section) and correlate with any AWS support cases.
Follow the instructions provided in the AWS support case, prioritizing credential rotation or revocation to prevent further unauthorized access.
Review and update policies on credential storage to prevent public exposure, as highlighted in the "Policy Update" remediation step, referencing the AWS IAM User Guide.

AWS KMS Key User Performing S3 Encryption Detection

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

This brief focuses on detecting potentially malicious or unauthorized use of AWS Key Management Service (KMS) keys to encrypt data stored in Simple Storage Service (S3) buckets. The detection logic is based on identifying AWS CloudTrail logs indicating encryption operations performed by users who possess KMS keys. While the provided source material does not specify a particular threat actor or campaign, the ability to monitor and detect such activity is crucial for identifying insider threats, compromised accounts, or misconfigured permissions that could lead to data breaches or unauthorized access. This detection capability is a part of the Splunk Enterprise Security Content Update (ESCU) project and allows security teams to quickly identify potentially suspicious activity in their AWS environments.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or misconfigured IAM roles.
The attacker identifies S3 buckets containing sensitive data.
The attacker discovers KMS keys with permissions to encrypt data in the target S3 buckets.
The attacker uses the KMS keys to encrypt existing objects in the S3 bucket or encrypts new objects as they are uploaded.
The encryption operation is logged in AWS CloudTrail.
A detection rule identifies the user utilizing KMS keys for S3 encryption based on CloudTrail logs.
Security analysts investigate the activity to determine if it is legitimate or malicious.

Impact

Successful unauthorized encryption of S3 buckets using KMS keys can lead to data unavailability, data breaches, and compliance violations. A malicious actor could encrypt data and demand ransom for decryption keys, or they could encrypt data to hide their activities or disrupt services. The number of affected buckets and the sensitivity of the data they contain will determine the scope of the impact. Failure to detect and respond to this type of activity can result in significant financial losses, reputational damage, and legal consequences.

Recommendation

Implement the Sigma rule Detect AWS KMS Key User Performing S3 Encryption to identify users with KMS keys performing encryption operations on S3 buckets based on CloudTrail logs.
Enable AWS CloudTrail logging for all regions in your AWS environment to ensure comprehensive monitoring of API activity.
Regularly review IAM policies and KMS key policies to ensure that permissions are appropriately restricted.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the encryption activity.

AWS IAM API Calls via Temporary Session Tokens

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

This threat brief focuses on detecting the abuse of temporary session tokens within AWS environments. Temporary session tokens, identified by access key IDs starting with "ASIA," are commonly issued via sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins. While legitimate for short-term use, their use for privileged IAM actions like creating users, updating policies, or modifying trust relationships is unusual and indicative of malicious activity. Attackers might leverage compromised IAM users or roles to obtain these session tokens and perform unauthorized actions, aiming for persistence, privilege escalation, or defense evasion. This detection excludes console login sessions to reduce false positives, focusing on programmatic abuse.

Attack Chain

An attacker compromises an IAM user or role within an AWS environment.
The attacker uses the compromised credentials to request a temporary session token via sts:GetSessionToken or sts:AssumeRole.
The attacker authenticates to the AWS API using the temporary session token (access key ID starting with ASIA).
The attacker attempts to create a new IAM user using the CreateUser API call.
The attacker attempts to modify an existing IAM user's policy using the PutUserPolicy API call.
The attacker attempts to update the AssumeRolePolicy associated with an IAM role.
The attacker may also attempt to modify CloudTrail or GuardDuty configurations for defense evasion.
The attacker achieves persistence by creating new administrative users or roles, or by modifying existing permission policies.

Impact

Successful exploitation can allow attackers to establish persistent access within the AWS environment, escalate privileges to gain broader control, and evade detection by modifying security configurations. The impact includes unauthorized access to sensitive data, potential data breaches, and disruption of cloud services. While the specific number of victims or sectors targeted is unknown, organizations heavily reliant on AWS infrastructure are most at risk.

Recommendation

Deploy the AWS IAM API Calls via Temporary Session Tokens rule to detect suspicious API calls made with temporary session tokens. Tune the rule based on expected usage patterns within your environment.
Investigate all alerts generated by the rule, focusing on actions that modify IAM roles, user policies, and trust relationships, as described in the rule's investigation_fields.
Enforce MFA for all privileged IAM actions using aws:MultiFactorAuthPresent conditions to mitigate the risk of session token abuse, as mentioned in the rule's note.
Implement detection coverage for follow-on persistence actions such as iam:CreateAccessKey, iam:PutUserPolicy, and iam:UpdateAssumeRolePolicy, as recommended in the rule's note.

AWS IAM Group Creation for Persistence

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

This threat brief focuses on the malicious creation of AWS IAM groups as a persistence mechanism. An attacker who has gained unauthorized access to an AWS account, specifically with IAM write privileges, might create a new IAM group. This new group is then configured with highly permissive policies, such as AdministratorAccess, or policies allowing broad access to resources such as S3 buckets or other IAM resources. The adversary can then add users or roles to this newly created group, granting them the inherited, elevated privileges. This activity is logged as a CreateGroup event within AWS CloudTrail. This technique allows the attacker to quietly maintain access to the AWS environment, even if the initially compromised credentials are revoked. The Elastic detection rule "AWS IAM Group Creation," last updated on April 10, 2026, aims to identify this activity.

Attack Chain

Initial compromise of AWS credentials with IAM write privileges (e.g., via phishing, credential stuffing).
The attacker authenticates to the AWS environment using the compromised credentials.
The attacker executes the CreateGroup API call via the AWS CLI or AWS Management Console to create a new IAM group.
The attacker uses the AttachGroupPolicy API call to attach a highly permissive policy (e.g., AdministratorAccess) to the newly created IAM group.
The attacker uses the AddUserToGroup API call to add existing IAM users or roles to the newly created IAM group, granting them elevated privileges.
The attacker uses the newly gained privileges to access resources, modify configurations, or exfiltrate data.
The attacker maintains persistent access by utilizing the added users/roles even if initial credentials are revoked.

Impact

A successful attack can lead to a significant breach of confidentiality, integrity, and availability. An attacker with persistent, high-privilege access can modify critical infrastructure, steal sensitive data, or disrupt services. While the number of direct victims isn't specified in this source, the impact can range from a single compromised AWS account to widespread disruption across multiple organizations relying on the compromised AWS services. The severity depends on the level of access granted to the malicious group and the value of the resources accessible through that group.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect anomalous IAM group creation events.
Investigate any CreateGroup events, especially when followed by AttachGroupPolicy or AddUserToGroup events within a short timeframe (see "AWS IAM Group Creation" rule and investigation guide).
Monitor CloudTrail logs for CreateGroup events and correlate them with other IAM activity to identify suspicious patterns (refer to the aws.cloudtrail.user_identity.arn and related fields described in the provided documentation).
Implement the principle of least privilege, restricting who can call iam:CreateGroup, iam:AttachGroupPolicy, and iam:AddUserToGroup (as mentioned in the remediation steps).

AWS Management Console Root Login Detected

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

The AWS root user possesses unrestricted privileges over all resources within an AWS account, bypassing IAM boundaries. AWS recommends that the root user should not be used for everyday tasks including administrative ones, and root credentials should be locked away for very specific account-level administrative actions. This rule detects successful AWS Management Console logins by the root user (ConsoleLogin events with userIdentity.type: Root and event.outcome: Success). The login event is sourced from AWS CloudTrail logs, providing detailed information about the source IP, user agent, and geolocation of the login attempt. Identifying these logins is critical for maintaining the security and integrity of the AWS environment, as unauthorized access can lead to significant data breaches and system compromises.

Attack Chain

An attacker gains unauthorized access to the AWS root user credentials, potentially through phishing, credential stuffing, or leaked credentials.
The attacker uses the compromised root credentials to authenticate to the AWS Management Console.
AWS CloudTrail logs the successful ConsoleLogin event, including the userIdentity.type: Root and event.outcome: Success.
The attacker leverages the root user privileges to create new IAM users or roles with elevated permissions, establishing persistence within the AWS environment.
The attacker modifies security policies, such as attaching roles or putting bucket policies, to further escalate privileges and gain access to sensitive resources.
The attacker disables or deletes CloudTrail trails and Security Hub findings suppression in order to cover their tracks.
The attacker accesses and exfiltrates sensitive data stored in S3 buckets or other AWS services.
The attacker may attempt to further compromise other AWS accounts or resources by leveraging the compromised root credentials.

Impact

A successful compromise of the AWS root user can lead to complete control over the AWS account, resulting in data breaches, financial losses, and reputational damage. The attacker can access and exfiltrate sensitive data, modify or delete critical resources, and disrupt business operations. The severity of the impact depends on the scope of the attacker's actions and the sensitivity of the data stored in the AWS environment. Because the root user has unrestricted privileges, the potential for damage is very high.

Recommendation

Deploy the Sigma rule "AWS Management Console Root Login" to your SIEM using AWS CloudTrail logs to detect successful root user logins.
Enable multi-factor authentication (MFA) for the root user account and enforce its usage.
Monitor the source.ip field in CloudTrail logs for root logins and investigate any unfamiliar IP addresses or locations.
Review AWS Identity and Access Management (IAM) configurations to ensure that the root user account is not being used for routine tasks and that appropriate least privilege principles are followed.
Investigate follow-on actions in CloudTrail logs immediately after root login events, such as the creation of new IAM users, roles, or policies.
Implement automated alerts for any future userIdentity.type: Root logins to ensure real-time detection and response.