{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/aws-identity-and-access-management-iam/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":["AWS"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Identity and Access Management (IAM)"],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","aws"],"_cs_type":"threat","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection identifies when the AWS-managed \u003ccode\u003eCompromisedKeyQuarantine\u003c/code\u003e or \u003ccode\u003eCompromisedKeyQuarantineV2\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Exposure:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAWS Detection:\u003c/strong\u003e AWS detects the exposed credentials through its monitoring systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Attachment:\u003c/strong\u003e AWS uses the \u003ccode\u003eAttachUserPolicy\u003c/code\u003e API operation to attach the \u003ccode\u003eCompromisedKeyQuarantine\u003c/code\u003e or \u003ccode\u003eCompromisedKeyQuarantineV2\u003c/code\u003e AWS managed policy to the affected IAM user. This policy restricts the user's permissions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSupport Case Creation:\u003c/strong\u003e AWS creates a support case detailing the compromised credentials and providing instructions for remediation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNotification:\u003c/strong\u003e The AWS account owner is notified of the support case and the attached quarantine policy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInvestigation:\u003c/strong\u003e The security team investigates the root cause of the credential exposure.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRemediation:\u003c/strong\u003e Following the instructions in the support case, the security team disables or rotates the compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Removal:\u003c/strong\u003e After the compromised credentials have been addressed, the security team detaches the quarantine policy.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe attachment of the \u003ccode\u003eCompromisedKeyQuarantine\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the attachment of the \u003ccode\u003eCompromisedKeyQuarantine\u003c/code\u003e policy via the \u003ccode\u003eAttachUserPolicy\u003c/code\u003e API call in CloudTrail logs to quickly identify compromised IAM user accounts.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e field in the CloudTrail logs to identify the specific \u003ccode\u003euserName\u003c/code\u003e that has been quarantined (as referenced in the \u0026quot;Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User\u0026quot; section) and correlate with any AWS support cases.\u003c/li\u003e\n\u003cli\u003eFollow the instructions provided in the AWS support case, prioritizing credential rotation or revocation to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eReview and update policies on credential storage to prevent public exposure, as highlighted in the \u0026quot;Policy Update\u0026quot; remediation step, referencing the AWS IAM User Guide.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-20T16:27:52Z","date_published":"2024-07-20T16:27:52Z","id":"https://feed.craftedsignal.io/briefs/2024-07-aws-compromised-key-quarantine/","summary":"Detection of the AWS `CompromisedKeyQuarantine` policy being attached to an IAM user, indicating that AWS has flagged the user's credentials as compromised or publicly exposed, and is providing instructions via a support case for remediation.","title":"AWS IAM CompromisedKeyQuarantine Policy Attachment","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-compromised-key-quarantine/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Key Management Service (KMS)","Amazon S3","AWS CloudTrail","AWS Identity and Access Management (IAM)"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","kms","s3","encryption"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an AWS account, potentially through compromised credentials or misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies S3 buckets containing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker discovers KMS keys with permissions to encrypt data in the target S3 buckets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the KMS keys to encrypt existing objects in the S3 bucket or encrypts new objects as they are uploaded.\u003c/li\u003e\n\u003cli\u003eThe encryption operation is logged in AWS CloudTrail.\u003c/li\u003e\n\u003cli\u003eA detection rule identifies the user utilizing KMS keys for S3 encryption based on CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the activity to determine if it is legitimate or malicious.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect AWS KMS Key User Performing S3 Encryption\u003c/code\u003e to identify users with KMS keys performing encryption operations on S3 buckets based on CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all regions in your AWS environment to ensure comprehensive monitoring of API activity.\u003c/li\u003e\n\u003cli\u003eRegularly review IAM policies and KMS key policies to ensure that permissions are appropriately restricted.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the encryption activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-kms-s3-encryption/","summary":"Detection of AWS users utilizing KMS keys to perform encryption operations on S3 buckets, indicating potential misuse or malicious activity within the cloud environment.","title":"AWS KMS Key User Performing S3 Encryption Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-kms-s3-encryption/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Identity and Access Management (IAM)","AWS CloudTrail","AWS GuardDuty"],"_cs_severities":["low"],"_cs_tags":["cloud","aws","iam","session-token","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting the abuse of temporary session tokens within AWS environments. Temporary session tokens, identified by access key IDs starting with \u0026quot;ASIA,\u0026quot; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an IAM user or role within an AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to request a temporary session token via sts:GetSessionToken or sts:AssumeRole.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS API using the temporary session token (access key ID starting with ASIA).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new IAM user using the CreateUser API call.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to modify an existing IAM user's policy using the PutUserPolicy API call.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to update the AssumeRolePolicy associated with an IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker may also attempt to modify CloudTrail or GuardDuty configurations for defense evasion.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by creating new administrative users or roles, or by modifying existing permission policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u003ccode\u003eAWS IAM API Calls via Temporary Session Tokens\u003c/code\u003e rule to detect suspicious API calls made with temporary session tokens. Tune the rule based on expected usage patterns within your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate all alerts generated by the rule, focusing on actions that modify IAM roles, user policies, and trust relationships, as described in the rule's \u003ccode\u003einvestigation_fields\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnforce MFA for all privileged IAM actions using \u003ccode\u003eaws:MultiFactorAuthPresent\u003c/code\u003e conditions to mitigate the risk of session token abuse, as mentioned in the rule's \u003ccode\u003enote\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement detection coverage for follow-on persistence actions such as \u003ccode\u003eiam:CreateAccessKey\u003c/code\u003e, \u003ccode\u003eiam:PutUserPolicy\u003c/code\u003e, and \u003ccode\u003eiam:UpdateAssumeRolePolicy\u003c/code\u003e, as recommended in the rule's \u003ccode\u003enote\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-iam-session-token-abuse/","summary":"Detection of AWS IAM API operations using temporary session credentials, indicating potential credential theft, session hijacking, or privileged role abuse for persistence and defense evasion.","title":"AWS IAM API Calls via Temporary Session Tokens","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-iam-session-token-abuse/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Identity and Access Management (IAM)"],"_cs_severities":["low"],"_cs_tags":["aws","iam","persistence","cloud"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eCreateGroup\u003c/code\u003e 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 \u0026quot;AWS IAM Group Creation,\u0026quot; last updated on April 10, 2026, aims to identify this activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of AWS credentials with IAM write privileges (e.g., via phishing, credential stuffing).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS environment using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eCreateGroup\u003c/code\u003e API call via the AWS CLI or AWS Management Console to create a new IAM group.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAttachGroupPolicy\u003c/code\u003e API call to attach a highly permissive policy (e.g., AdministratorAccess) to the newly created IAM group.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAddUserToGroup\u003c/code\u003e API call to add existing IAM users or roles to the newly created IAM group, granting them elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly gained privileges to access resources, modify configurations, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access by utilizing the added users/roles even if initial credentials are revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect anomalous IAM group creation events.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateGroup\u003c/code\u003e events, especially when followed by \u003ccode\u003eAttachGroupPolicy\u003c/code\u003e or \u003ccode\u003eAddUserToGroup\u003c/code\u003e events within a short timeframe (see \u0026quot;AWS IAM Group Creation\u0026quot; rule and investigation guide).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eCreateGroup\u003c/code\u003e events and correlate them with other IAM activity to identify suspicious patterns (refer to the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and related fields described in the provided documentation).\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege, restricting who can call \u003ccode\u003eiam:CreateGroup\u003c/code\u003e, \u003ccode\u003eiam:AttachGroupPolicy\u003c/code\u003e, and \u003ccode\u003eiam:AddUserToGroup\u003c/code\u003e (as mentioned in the remediation steps).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T10:00:00Z","date_published":"2024-01-03T10:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-aws-iam-group-creation/","summary":"An adversary with compromised IAM write privileges creates a new group in AWS IAM and grants it excessive permissions to establish a persistence mechanism.","title":"AWS IAM Group Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-iam-group-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Management Console","AWS CloudTrail","AWS Identity and Access Management (IAM)"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","initial-access"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThe 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 (\u003ccode\u003eConsoleLogin\u003c/code\u003e events with \u003ccode\u003euserIdentity.type: Root\u003c/code\u003e and \u003ccode\u003eevent.outcome: Success\u003c/code\u003e). 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to the AWS root user credentials, potentially through phishing, credential stuffing, or leaked credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised root credentials to authenticate to the AWS Management Console.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eConsoleLogin\u003c/code\u003e event, including the \u003ccode\u003euserIdentity.type: Root\u003c/code\u003e and \u003ccode\u003eevent.outcome: Success\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the root user privileges to create new IAM users or roles with elevated permissions, establishing persistence within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security policies, such as attaching roles or putting bucket policies, to further escalate privileges and gain access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker disables or deletes CloudTrail trails and Security Hub findings suppression in order to cover their tracks.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses and exfiltrates sensitive data stored in S3 buckets or other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further compromise other AWS accounts or resources by leveraging the compromised root credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;AWS Management Console Root Login\u0026quot; to your SIEM using AWS CloudTrail logs to detect successful root user logins.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication (MFA) for the root user account and enforce its usage.\u003c/li\u003e\n\u003cli\u003eMonitor the \u003ccode\u003esource.ip\u003c/code\u003e field in CloudTrail logs for root logins and investigate any unfamiliar IP addresses or locations.\u003c/li\u003e\n\u003cli\u003eReview 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.\u003c/li\u003e\n\u003cli\u003eInvestigate follow-on actions in CloudTrail logs immediately after root login events, such as the creation of new IAM users, roles, or policies.\u003c/li\u003e\n\u003cli\u003eImplement automated alerts for any future \u003ccode\u003euserIdentity.type: Root\u003c/code\u003e logins to ensure real-time detection and response.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-aws-root-login/","summary":"Detection of a successful AWS Management Console login by the Root user, which is an original identity with unrestricted privileges, indicates a potential security breach requiring immediate investigation.","title":"AWS Management Console Root Login Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-root-login/"}],"language":"en","title":"CraftedSignal Threat Feed - AWS Identity and Access Management (IAM)","version":"https://jsonfeed.org/version/1.1"}