Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials (T1078.004).
2. The attacker registers a new MFA device within the compromised AWS account (T1556.006).
3. The attacker uses the AWS STS AssumeRole API to request temporary credentials for a different IAM role (T1550).
4. The request includes the serial number of the newly registered MFA device in the request_parameters (part of the AssumeRole call).
5. AWS STS validates the MFA and, if successful, issues temporary credentials associated with the assumed role (T1550.001).
6. The attacker uses these temporary credentials to access resources and perform actions authorized by the assumed role (T1078).
7. This may involve escalating privileges, accessing sensitive data, or moving laterally to other AWS resources (TA0004, TA0008).

Impact

A successful attack using a new MFA device to assume a role can lead to unauthorized access to sensitive AWS resources. The attacker can escalate privileges, move laterally to other resources, or establish persistent access within the environment. This can result in data breaches, service disruption, or other malicious activities, impacting the confidentiality, integrity, and availability of the organization's cloud infrastructure. The risk score is 21, indicating a potential but not immediately critical threat.

Recommendation

• Deploy the following Sigma rules to your SIEM to detect the use of new MFA devices in AssumeRole calls and tune for your environment.
• Enable AWS CloudTrail logging and ensure proper configuration of the AWS Fleet integration or Filebeat module to capture relevant STS events.
• Review AWS CloudTrail logs for unusual patterns of MFA device registrations and role assumptions, focusing on privilege escalation or lateral movement attempts.
• Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
• Create exceptions for known onboarding activities or routine device replacements by correlating with HR records or IT support tickets as described in the rule's false positives section.

Attack Chain

1. An attacker gains initial access to an AWS account, possibly through compromised credentials or an exposed access key.
2. The attacker uses the compromised credentials to assume an initial IAM role using sts:AssumeRole. This action is logged in CloudTrail with the AssumeRole event.
3. The attacker then uses the temporary credentials obtained from the first role to assume a second IAM role, again using sts:AssumeRole. The aws.cloudtrail.user_identity.session_context.session_issuer.arn field identifies the first role, and the aws.cloudtrail.resources.arn field identifies the second role.
4. If the second role has more permissions than the first, the attacker can use the second role's credentials to perform actions they couldn't do before (privilege escalation). This could involve actions related to IAM, EC2, S3 or other AWS services.
5. The attacker leverages the increased permissions to access sensitive data stored in S3 buckets, modify IAM policies to grant themselves further access, or launch EC2 instances for malicious purposes.
6. Each AssumeRole action generates new temporary credentials, effectively refreshing the attacker's session.
7. The attacker maintains persistence within the AWS environment by repeatedly chaining roles to refresh temporary credentials.
8. The attacker achieves their objective, such as exfiltrating sensitive data, deploying malware, or disrupting services.

Impact

Successful exploitation via role chaining can lead to significant privilege escalation within an AWS environment. This can enable attackers to gain unauthorized access to sensitive data, modify critical infrastructure configurations, and potentially disrupt business operations. The persistence aspect of role chaining can allow attackers to maintain a foothold in the environment for extended periods, making detection and remediation more challenging. The blast radius can extend across multiple AWS accounts if cross-account role chaining is involved.

Recommendation

• Deploy the Sigma rule Detect AWS STS Role Chaining to identify instances of role chaining in AWS CloudTrail logs. Tune the rule to exclude expected role-chaining patterns based on your environment (aws.cloudtrail.user_identity.session_context.session_issuer.arn, aws.cloudtrail.resources.arn).
• Monitor CloudTrail logs for AssumeRole events where aws.cloudtrail.user_identity.type is AssumedRole, focusing on unusual or unexpected role combinations.
• Implement least privilege policies for all IAM roles, limiting trust policies to only required principals. Periodically review role chaining patterns to validate necessity.
• Use the AWS STS Role Chaining Sigma rule to identify potential role chaining attempts and investigate accordingly.
• Correlate CloudTrail logs with other security events (e.g., GuardDuty alerts) to identify potential privilege escalation or data exfiltration activities following role chaining.
• Enable MFA where possible on AssumeRole operations.

Attack Chain

1. Initial Compromise: (Assumed) The attacker gains initial access to an AWS account, possibly through compromised credentials or an exposed API key (Not documented in source).
2. Privilege Escalation: The attacker attempts to escalate their privileges within the AWS environment, either through exploiting misconfigurations or leveraging existing IAM roles (Not documented in source).
3. IAM Manipulation: The attacker interacts with the AWS IAM service, specifically targeting user management (Observed - CreateLoginProfile).
4. Create Login Profile: The attacker uses the CreateLoginProfile API call to create a login profile for a new or existing IAM user. This provides the user with console access, enabling interactive login.
5. Persistence: The attacker leverages the newly created user with console access as a means of persistence within the AWS environment.
6. Lateral Movement: The attacker uses the new or modified user to access other AWS resources or services, expanding their control within the environment.
7. Data Exfiltration / Damage: (Assumed) The attacker utilizes their access to exfiltrate sensitive data or cause damage to the AWS infrastructure. (Not documented in source).

Impact

The successful creation of a login profile by a malicious actor can lead to unauthorized access to AWS resources, data breaches, and service disruption. Attackers may use these profiles to maintain persistence, escalate privileges, and move laterally within the AWS environment. The number of victims depends on the scope of the attacker's access and the sensitivity of the compromised resources.

Recommendation

• Deploy the Sigma rule for AWS CreateLoginProfile Activity to your SIEM and tune for your environment (Reference: aws_createloginprofile.yml).
• Investigate any instances of CreateLoginProfile events, especially those performed by unfamiliar IAM entities, to validate legitimacy.
• Monitor AWS CloudTrail logs for CreateLoginProfile events to ensure comprehensive visibility into IAM activity.
• Enforce multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (General Security Best Practice).

Attack Chain

1. Initial compromise of an AWS account with sufficient permissions to modify IAM resources (e.g., via compromised credentials or an EC2 instance with an overly permissive role).
2. The attacker uses the AWS CLI or the AWS Management Console to list existing SAML Identity Providers.
3. The attacker identifies the target SAML Identity Provider to modify.
4. The attacker modifies the SAML metadata document associated with the Identity Provider, potentially injecting malicious claims or altering role mappings.
5. The attacker updates the SAML Identity Provider configuration in AWS IAM with the modified metadata document using the UpdateSAMLIdentityProvider API call.
6. The attacker tests the modified configuration to ensure it achieves the desired privilege escalation or access disruption.
7. Legitimate users attempt to authenticate via SAML, potentially receiving incorrect roles/permissions or being denied access.

Impact

Successful modification of an AWS SAML Identity Provider can have significant consequences. An attacker could escalate their privileges within the AWS environment, gaining access to sensitive data and resources. They may also disrupt legitimate user access, leading to denial-of-service conditions for federated users. While the scale of impact depends on the scope of the compromised AWS account and the criticality of the federated applications, this attack can severely compromise cloud security.

Attack Chain

1. An attacker gains unauthorized access to an AWS account, either through compromised credentials or exploiting a misconfigured IAM role.
2. The attacker enumerates available S3 buckets and identifies a target bucket containing sensitive data.
3. The attacker identifies or creates a KMS key within the AWS environment.
4. The attacker configures the target S3 bucket to use the identified KMS key for encryption of objects stored within it.
5. The attacker uploads or modifies objects within the S3 bucket, triggering encryption using the KMS key.
6. The attacker attempts to exfiltrate the encrypted data.

Impact

Successful exploitation could lead to unauthorized access to sensitive data stored within S3 buckets. Depending on the nature of the data, this could result in financial losses, reputational damage, and legal repercussions. Furthermore, if the attacker controls the KMS key, they could render the data inaccessible, effectively holding it hostage. The impact can vary based on the scope of the compromised data and the attacker's objectives, potentially affecting customer data, intellectual property, or critical business information.

Attack Chain

1. Initial Access: An attacker gains access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.
2. Privilege Escalation (Attempt): The attacker attempts to escalate privileges to gain the necessary permissions to delete IAM groups. This could involve exploiting existing roles or policies.
3. Reconnaissance: The attacker enumerates existing IAM groups within the AWS account to identify potential targets for deletion.
4. IAM Group Deletion Attempt: The attacker attempts to delete a specific IAM group using the AWS CLI, API calls, or the AWS Management Console.
5. Deletion Failure: The deletion attempt fails due to insufficient permissions, resource dependencies, or other IAM constraints.
6. Retry or Lateral Movement: The attacker may retry the deletion with different credentials or attempt to move laterally within the AWS environment to gain the necessary permissions.
7. Persistence (Alternative): If group deletion fails, attacker may attempt to modify group policies to weaken security posture
8. Impact (Potential): Successful group deletion would alter permissions structure of the AWS environment.

Impact

A failed IAM group deletion, while not directly causing immediate damage, can signify ongoing malicious activity. If successful, deleting IAM groups can lead to unauthorized access to resources, disruption of services, and potential data breaches. The number of affected users and the severity of the impact depend on the privileges associated with the deleted groups. Targeted sectors include any organization leveraging AWS IAM for identity and access management. A successful attack could lead to significant financial losses and reputational damage.

Attack Chain

1. Attacker gains initial access to an AWS account using compromised credentials (e.g., leaked access keys or credentials obtained through phishing).
2. The attacker authenticates to the AWS environment using the compromised credentials, leveraging the AWS CLI or API.
3. The attacker identifies a target IAM user for persistence or privilege escalation.
4. The attacker invokes the CreateAccessKey API call, specifying the target IAM user's username in the aws.cloudtrail.request_parameters.userName field, while using the compromised credentials in the aws.cloudtrail.user_identity.arn to authenticate.
5. AWS IAM service processes the CreateAccessKey request and generates a new access key ID and secret access key pair for the target user.
6. The attacker retrieves the new access key ID (aws.cloudtrail.response_elements.accessKey.accessKeyId) and secret access key from the API response.
7. The attacker uses the newly created access keys to authenticate as the target user and perform unauthorized actions, such as accessing S3 buckets or launching EC2 instances.
8. The attacker maintains persistent access to the AWS environment, even if the original compromised credentials are rotated or revoked.

Impact

Successful exploitation allows the attacker to maintain persistent access to the AWS environment. The attacker can then perform unauthorized actions as the target user, potentially leading to data breaches, resource hijacking, and service disruption. Depending on the privileges associated with the target IAM user, the attacker could escalate privileges, access sensitive data stored in S3 buckets, or launch malicious EC2 instances. The impact is highly dependent on the permissions assigned to the compromised IAM user, the level of access achieved, and the sensitivity of the data and resources involved.

Recommendation

• Deploy the following Sigma rules to your SIEM to detect suspicious IAM access key creation events. Tune the rules based on your environment and expected administrative activity.
• Monitor AWS CloudTrail logs for CreateAccessKey API calls where the calling user differs from the target user (identified by aws.cloudtrail.user_identity.arn and aws.cloudtrail.request_parameters.userName respectively).
• Implement least-privilege IAM policies to limit the ability of users to create access keys for other users.
• Enforce multi-factor authentication (MFA) for all IAM users, especially those with administrative privileges.
• Review and audit IAM policies regularly to ensure they adhere to the principle of least privilege.
• Follow the guidance in the AWS IR Playbooks for Credential Compromise and IAM Misuse for incident response procedures.

Attack Chain

1. Initial Access: The attacker gains access to AWS account credentials through phishing, credential stuffing, or other means.
2. Login Attempt: The attacker attempts to log into the AWS Management Console or uses the AWS CLI with the compromised credentials.
3. Verification Check: The system prompts for MFA if enabled for the user. If not enabled, the attacker proceeds to enable it.
4. Register MFA: The attacker initiates the process of registering a new virtual MFA device within the AWS IAM settings.
5. QR Code/Secret Key Retrieval: The attacker retrieves the QR code or secret key required to activate the virtual MFA device on their own device.
6. Virtual MFA Activation: The attacker uses an authenticator app (e.g., Google Authenticator, Authy) to scan the QR code or manually enters the secret key, generating a time-based one-time password (TOTP).
7. MFA Verification: The attacker enters the TOTP into the AWS console to successfully register the virtual MFA device.
8. Persistence: The attacker now has persistent access to the AWS account, bypassing original MFA configuration and maintains access even if the password changes.

Impact

A successful registration of a rogue virtual MFA device grants the attacker persistent access to the AWS account. This can lead to unauthorized access to sensitive data, modification of AWS resources, deployment of malicious workloads, or even complete account takeover, resulting in significant financial loss, data breaches, and reputational damage. Organizations in all sectors that rely on AWS infrastructure are vulnerable.

Recommendation

• Deploy the provided Sigma rule "Detect AWS Virtual MFA Device Registration" to your SIEM and tune for your environment to alert on successful registrations.
• Monitor AWS CloudTrail logs for CreateVirtualMFADevice events to detect the creation of new virtual MFA devices (reference log source in Sigma rule).
• Investigate any alerts generated by the Sigma rule by validating the source IP addresses and user agents associated with MFA device registration attempts.

Attack Chain

1. Initial Access: An attacker compromises an AWS account with sufficient privileges to modify SAML identity providers. This might involve exploiting a vulnerability, using stolen credentials, or through social engineering.
2. Privilege Escalation (If Needed): The compromised account may require privilege escalation to gain the necessary permissions to modify the SAML provider.
3. Discovery: The attacker enumerates existing SAML identity providers in the AWS environment to identify a target for modification.
4. Credential Access: The attacker modifies the SAML provider configuration to inject malicious assertions or redirect authentication to an attacker-controlled endpoint (Golden SAML).
5. Persistence: By modifying the SAML provider, the attacker establishes a persistent backdoor, allowing them to authenticate as any user within the federated domain.
6. Lateral Movement: The attacker uses the forged SAML assertions to move laterally within the AWS environment, accessing resources and services under the guise of legitimate users.
7. Data Exfiltration / Impact: The attacker accesses sensitive data, compromises critical systems, or disrupts services based on the compromised federated identities.
8. Covering Tracks: The attacker may attempt to disable or modify CloudTrail logs to hide their activity.

Impact

Successful modification of a SAML identity provider can have severe consequences, potentially affecting all users and resources that rely on the compromised provider. This can lead to unauthorized access to sensitive data, disruption of critical services, and significant financial losses. The impact can extend beyond the immediate breach, potentially affecting downstream systems and partner organizations that rely on the compromised AWS environment. The CISA alert AA21-008A highlights the risks associated with Golden SAML attacks, underscoring the importance of detecting and preventing such activity.

Recommendation

• Deploy the provided Sigma rule AWS SAML Provider Updated to detect unauthorized modifications to SAML identity providers by monitoring UpdateSAMLProvider events in CloudTrail logs.
• Investigate any detected UpdateSAMLProvider events for unexpected source IP addresses, user agents, or IAM roles. Correlate with other security events to identify potentially compromised accounts.
• Implement strict access controls and multi-factor authentication (MFA) for all IAM users and roles, particularly those with permissions to manage SAML identity providers.
• Regularly review and audit SAML identity provider configurations for any unauthorized changes or suspicious activity.
• Monitor for suspicious activity originating from the source IP addresses identified in the detection rule (src_endpoint.ip).
• Enable and monitor AWS CloudTrail logs for all AWS accounts and regions to ensure comprehensive logging of API activity.
• Use the provided drilldown searches to investigate detection results for specific users.

Attack Chain

1. An attacker gains initial access to an AWS account, possibly through credential compromise or other means.
2. The attacker identifies a target user account with higher privileges or valuable access rights.
3. The attacker uses the compromised account to execute the "UpdateLoginProfile" AWS API call.
4. In the UpdateLoginProfile request, the attacker specifies the target user's username (requestParameters.userName) but uses the compromised account's credentials (userIdentity.userName).
5. The AWS CloudTrail logs record the UpdateLoginProfile event, capturing the discrepancy between the user making the request and the user whose profile is being modified.
6. Successful modification of the login profile allows the attacker to reset passwords, change MFA settings, or otherwise control the target user's account.
7. The attacker leverages the now-compromised higher-privilege account to access sensitive data or resources.

Impact

A successful attack can lead to privilege escalation, where an attacker gains unauthorized access and control over critical AWS resources. This could result in data breaches, service disruption, or financial loss. The exact impact depends on the privileges associated with the compromised target account. Organizations using AWS are vulnerable if their IAM policies are not correctly configured or if user accounts are compromised.

Recommendation

• Deploy the Sigma rule AWS Login Profile Update by Different User to your SIEM and tune for your environment to detect suspicious UpdateLoginProfile events.
• Investigate any alerts generated by the AWS Login Profile Update by Different User Sigma rule, focusing on the user accounts involved and the source of the API call.
• Review IAM policies to ensure least privilege and restrict the ability of users to modify other users' login profiles.
• Monitor AWS CloudTrail logs for any unusual or unauthorized API calls related to IAM or user management.

Attack Chain

1. An attacker gains initial access to an AWS IAM user's credentials, potentially through credential stuffing or phishing.
2. The attacker authenticates to the AWS Management Console or via the AWS CLI using the compromised credentials.
3. The attacker identifies that MFA is enabled on the compromised account.
4. The attacker initiates the DeactivateMFADevice API call to remove the MFA association from the user account.
5. Alternatively, the attacker initiates the DeleteVirtualMFADevice API call to delete the virtual MFA device.
6. AWS CloudTrail logs the DeactivateMFADevice or DeleteVirtualMFADevice event.
7. With MFA disabled, the attacker maintains persistent access to the AWS environment.
8. The attacker performs unauthorized actions, such as data exfiltration, resource modification, or lateral movement, without MFA protection.

Impact

Successful disabling of MFA on an AWS IAM account can lead to significant security breaches. The attacker gains persistent access to the AWS environment, enabling data exfiltration, unauthorized resource modification, and lateral movement. This can result in data loss, service disruption, and financial damages. The impact is amplified if the compromised account has administrative privileges, potentially affecting critical AWS services and resources.

Recommendation

• Deploy the Sigma rule Detect AWS MFA Deactivation to your SIEM and tune for your environment.
• Enable AWS CloudTrail logging and ensure logs are being ingested into your SIEM to detect the events described in this brief.
• Investigate any instances of DeleteVirtualMFADevice or DeactivateMFADevice events in AWS CloudTrail to determine if they are legitimate administrative actions.
• Implement strict MFA enforcement policies and regularly audit MFA status across all IAM users to prevent unauthorized disabling of MFA.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role (T1078).
2. The attacker leverages existing AWS CLI or SDK tools to interact with the AWS environment.
3. The attacker calls the CreateLoginProfile API to create a new user login profile using the compromised or misused credentials or role (T1098).
4. The attacker configures password policies or other settings for the newly created user, ensuring continued access (T1543).
5. The newly created user is then used to perform reconnaissance activities, such as listing resources, identifying sensitive data stores, or mapping network configurations.
6. Privilege escalation is attempted by assigning the new user to groups or roles with broader permissions.
7. Sensitive data is accessed, exfiltrated, or manipulated using the newly escalated privileges (TA0009).

Impact

Successful exploitation via unauthorized login profile creation can lead to significant data breaches, service disruption, and reputational damage. The impact ranges from unauthorized access to sensitive data and resources to the complete compromise of the AWS environment, depending on the permissions granted to the newly created or modified user accounts.

Attack Chain

1. An attacker compromises an AWS account or obtains valid credentials.
2. The attacker authenticates to the AWS Management Console or uses the AWS CLI with the compromised credentials.
3. The attacker uses the CreatePolicyVersion API call to create a new version of an existing IAM policy.
4. The policy document included in the CreatePolicyVersion API call specifies Action: "*" and Resource: "*" effectively granting all permissions on all resources.
5. The attacker attaches the modified IAM policy to a user, group, or role.
6. The user, group, or role now has excessive permissions, allowing them to perform actions they were not previously authorized to do.
7. The attacker leverages these elevated privileges to perform unauthorized actions, such as accessing sensitive data, modifying critical infrastructure, or launching new resources.
8. The attacker may further escalate privileges or move laterally within the AWS environment, compromising additional resources.

Impact

Successful exploitation allows an attacker to gain extensive access to AWS resources, leading to unauthorized actions, data exfiltration, or further compromise of the AWS environment. The principle of least privilege is violated, potentially exposing the environment to misuse or abuse. The scope of the impact depends on the level of access granted by the overly permissive policy. It could lead to complete compromise of the AWS environment.

Recommendation

• Deploy the Sigma rule AWS IAM Policy Allows All Actions on All Resources to detect the creation of overly permissive IAM policies based on CloudTrail logs.
• Review all instances flagged by the Sigma rule and verify the legitimacy of the policy changes.
• Implement IAM Access Analyzer to identify existing IAM policies that grant overly broad access (reference: AWS documentation).
• Enforce the principle of least privilege by granting only the permissions required to perform specific tasks (reference: AWS documentation).

Attack Chain

1. The attacker gains initial access to an AWS account, possibly through compromised credentials or a vulnerability in an application with IAM roles.
2. The attacker enumerates existing IAM policies to identify potential targets for manipulation.
3. The attacker identifies policy versions with more permissive settings than the currently active version.
4. The attacker calls the SetDefaultPolicyVersion API to revert to a previous policy version with the broader permissions. The event SetDefaultPolicyVersion is logged in CloudTrail.
5. The attacker attempts to perform actions that were previously unauthorized but are now permitted due to the changed policy version.
6. The attacker exploits the elevated privileges to access sensitive data stored in S3 buckets, databases, or other AWS resources.
7. The attacker exfiltrates the stolen data to an external location.

Impact

A successful attack can lead to unauthorized access to sensitive data, potentially impacting thousands or millions of users depending on the organization's data storage practices. Industries like finance, healthcare, and government are particularly at risk due to the sensitive nature of their data. The attacker can also use the elevated privileges to disrupt services, modify configurations, or deploy malicious infrastructure within the compromised AWS environment. The damage can range from data breaches and financial losses to reputational damage and compliance violations.

Recommendation

• Deploy the Sigma rule Detect AWS IAM Policy Default Version Change to your SIEM and tune for your environment to detect suspicious activity (logsource: aws:cloudtrail, eventName: SetDefaultPolicyVersion).
• Investigate any instances of SetDefaultPolicyVersion where the user is not a designated IAM administrator.
• Review the policy versions being set as default to ensure they adhere to the principle of least privilege.
• Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (T1078.004).
• Enable and monitor AWS CloudTrail logs for IAM-related events to provide visibility into policy changes.

Attack Chain

1. Initial compromise of an IAM user's credentials through phishing or credential stuffing.
2. Attacker logs into the AWS environment using compromised credentials.
3. Attacker enumerates MFA devices associated with the target IAM user by using API calls like ListMFADevices.
4. Attacker calls DeactivateMFADevice to remove the MFA requirement for the targeted user.
5. The AWS IAM service processes the DeactivateMFADevice request and, if authorized based on the attacker's privileges, removes the MFA association.
6. Attacker may then create new access keys (CreateAccessKey) or modify IAM policies (AttachUserPolicy) to further their access.
7. Attacker accesses sensitive AWS resources, such as S3 buckets or EC2 instances, without MFA.
8. Attacker establishes persistence by creating backdoors or modifying IAM roles to maintain access after the initial compromise is detected.

Impact

A successful MFA deactivation can lead to unauthorized access to sensitive data, service disruption, or complete account takeover. The impact is magnified when privileged accounts are targeted. The lack of MFA significantly reduces the security posture of the affected AWS account, making it easier for attackers to move laterally within the AWS environment and exfiltrate data. Organizations relying heavily on AWS services could face significant financial losses and reputational damage.

Recommendation

• Deploy the Sigma rule AWS IAM MFA Deactivation to detect successful DeactivateMFADevice API calls (see rule below).
• Investigate any detected DeactivateMFADevice events by reviewing aws.cloudtrail.user_identity.arn and source.ip to determine the initiator and origin.
• Enable AWS CloudTrail logging and monitor for IAM configuration changes, focusing on events related to MFA device management.
• Enforce MFA for all IAM users, particularly those with elevated privileges, using service control policies (SCPs).
• Implement automated alerts for unusual IAM activity, such as MFA deactivation outside of business hours or from unfamiliar IP addresses.
• Review CloudTrail logs for related API calls like ListMFADevices, CreateAccessKey, or AttachUserPolicy following the DeactivateMFADevice event.

Attack Chain

1. Attacker gains access to AWS Management Console or uses compromised AWS CLI credentials.
2. Attacker identifies a target IAM policy to modify, querying IAM policies to find a suitable target.
3. Attacker retrieves the current default policy version ARN using AWS API calls.
4. Attacker crafts a modified IAM policy version with reduced permissions or unintended access.
5. Attacker creates a new IAM policy version using the AWS API, while keeping the original intact.
6. Attacker uses the aws iam set-default-policy-version command to set the newly crafted policy version as the default.
7. Legitimate users or services relying on the IAM policy now operate under the modified (potentially weakened) permissions.
8. Attacker leverages the broadened permissions for lateral movement, data access, or other malicious objectives.

Impact

Successful modification of the default IAM policy version can lead to privilege escalation, unauthorized access to sensitive data, and potential disruption of services relying on the affected policy. The impact depends on the scope of the policy and the permissions altered. A successful attack can affect multiple AWS services and resources governed by the modified policy. The change can be subtle and persist for a long time if not detected, leading to significant data breaches or service outages.

Attack Chain

1. Initial Access: An attacker gains initial access to an AWS account's username and password through credential harvesting (T1586.003) or other means.
2. Login Attempt: The attacker attempts to log in to the AWS Management Console using the compromised credentials.
3. MFA Bypass: If MFA is not enforced for the account, the attacker successfully logs in without providing a second factor.
4. Privilege Escalation: The attacker attempts to escalate privileges within the AWS environment by exploiting misconfigured IAM roles or policies.
5. Resource Access: The attacker accesses sensitive AWS resources, such as S3 buckets, EC2 instances, or databases.
6. Data Exfiltration: The attacker exfiltrates sensitive data from compromised AWS resources to an external location.
7. Resource Manipulation: The attacker modifies or deletes AWS resources, causing disruption or damage to the environment.

Impact

A successful AWS account compromise due to the absence of MFA can have severe consequences. These include unauthorized access to sensitive data, potential data exfiltration, resource manipulation, and significant financial losses. The impact can extend to compliance violations, reputational damage, and disruption of critical business operations. The analytic story "AWS Identity and Access Management Account Takeover" highlights this threat.

Recommendation

• Enable and enforce MFA for all AWS IAM users to mitigate the risk of account compromise (reference: https://aws.amazon.com/what-is/mfa/).
• Deploy the Sigma rule AWS Console Login Without MFA to detect successful console logins without MFA based on AWS CloudTrail logs.
• Investigate any detected instances of successful single-factor authentication to determine the legitimacy of the login attempt.
• Review and strengthen AWS IAM policies to minimize the potential for privilege escalation (related to T1078.004).

Attack Chain

1. Initial Access: The attacker gains initial access to an AWS account through compromised credentials (e.g., stolen passwords or leaked API keys).
2. Privilege Escalation (if needed): The attacker escalates privileges within the AWS account to obtain the necessary permissions to create MFA devices.
3. Identify Target User: The attacker identifies a user account (potentially an administrator account) to associate the new MFA device with.
4. Create Virtual MFA Device: The attacker invokes the CreateVirtualMFADevice API call to create a new virtual MFA device.
5. Associate MFA Device: The attacker associates the newly created virtual MFA device with the target user account.
6. Activate MFA Device: The attacker activates the virtual MFA device using the activation code.
7. Persistence: With the new MFA device activated, the attacker now has persistent access to the AWS account, even if the original compromised credentials are revoked.
8. Lateral Movement/Data Exfiltration: Using the persistent access, the attacker moves laterally within the AWS environment, accesses sensitive data, and potentially exfiltrates it.

Impact

Compromised AWS accounts can lead to significant data breaches, denial of service, and financial losses. If an attacker successfully registers a new MFA device, they can effectively lock out legitimate users and maintain persistent access. This can lead to the exfiltration of sensitive data, modification or deletion of critical resources, and the deployment of malicious workloads. The impact is especially high for organizations that rely heavily on AWS for their infrastructure and services.

Recommendation

• Deploy the Sigma rule AWS New Virtual MFA Device Creation to detect the CreateVirtualMFADevice event in AWS CloudTrail logs.
• Investigate any alerts generated by the Sigma rule, paying close attention to the user, source IP address, and user agent associated with the event.
• Implement multi-factor authentication (MFA) for all AWS users, especially those with administrative privileges, as described in the AWS documentation.
• Monitor AWS CloudTrail logs for other suspicious activities, such as unusual API calls or unauthorized access attempts.
• Review and enforce least privilege access controls to limit the impact of compromised credentials.

Attack Chain

1. An attacker gains access to valid AWS credentials, potentially through compromised user accounts or leaked API keys.
2. The attacker uses the AWS CLI to create a new S3 bucket using the aws s3api create-bucket command.
3. The attacker then uses the aws s3api put-bucket-acl command to modify the bucket's Access Control List (ACL).
4. In the put-bucket-acl command, the attacker sets permissions to grant read, write, or full control to "AuthenticatedUsers" or "AllUsers" by manipulating the x-amz-grant-read, x-amz-grant-write, and x-amz-grant-full-control parameters.
5. AWS CloudTrail logs the PutBucketAcl event, capturing details of the user, bucket name, and ACL configuration.
6. The attacker uploads sensitive data to the newly created, publicly accessible S3 bucket.
7. Unauthorized users or automated bots discover the public S3 bucket and access the exposed data.
8. The attacker exfiltrates the publicly available data, or modifies/corrupts data within the bucket.

Impact

Creation of publicly accessible S3 buckets can lead to severe data breaches. Unauthorized access to sensitive data stored in these buckets can result in financial loss, reputational damage, and legal liabilities. The number of affected individuals or organizations can vary widely, depending on the type and amount of data exposed. Public buckets can be indexed by search engines, further increasing the risk of unauthorized access. Data exfiltration or corruption can severely disrupt business operations and erode customer trust.

Recommendation

• Deploy the Sigma rule "Detect Public AWS S3 Bucket Creation via CLI" to your SIEM and tune for your environment to detect the described activity based on CloudTrail logs.
• Review and harden IAM policies to restrict the ability of users and roles to modify S3 bucket ACLs, preventing unintended public access.
• Regularly audit existing S3 buckets to identify and remediate any publicly accessible buckets, using AWS Trusted Advisor or similar tools.
• Implement automated monitoring and alerting for S3 bucket ACL changes using AWS CloudWatch Events and Lambda functions.
• Enforce the principle of least privilege by granting only necessary permissions to users and roles, minimizing the risk of accidental or malicious misconfiguration.