{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/aws-security-token-service/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Security Token Service"],"_cs_severities":["medium"],"_cs_tags":["aws","privilege-escalation","cloud"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection identifies when the AWS STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated permissions based on the task policy specified. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. An adversary with compromised user credentials can abuse this action to escalate privileges and gain unauthorized access to AWS resources within an organization. This activity may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows. The rule focuses on successful AssumeRoot events to minimize false positives.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises AWS credentials of a user or role through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to perform the \u003ccode\u003ests:AssumeRoot\u003c/code\u003e action, targeting a specific member account within the AWS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker specifies a \u003ccode\u003etaskPolicyArn\u003c/code\u003e in the \u003ccode\u003eAssumeRoot\u003c/code\u003e request, defining the permissions they wish to assume in the target account.\u003c/li\u003e\n\u003cli\u003eAWS validates the request and, if successful, issues temporary credentials, including an access key ID, secret access key, and session token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary credentials to authenticate to the target member account.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions within the target account, leveraging the elevated permissions granted by the assumed role, such as modifying IAM policies, accessing sensitive data, or disabling security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by creating additional cloud roles (T1098.003)\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful AssumeRoot attack can lead to full compromise of the targeted AWS account. This can allow the attacker to modify or delete resources, steal sensitive data, and disrupt business operations. The severity of the impact depends on the permissions granted by the task policy used during the AssumeRoot call and the resources present in the compromised account. This can affect a single member account or have organization-wide implications if the attacker is able to pivot to other accounts.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS STS AssumeRoot by Rare User\u003c/code\u003e to detect unusual \u003ccode\u003eAssumeRoot\u003c/code\u003e activity in your AWS environment (see rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eAWS STS AssumeRoot by Rare User\u003c/code\u003e rule, focusing on identifying the actor, target account, and actions performed after assuming the role (see rule documentation).\u003c/li\u003e\n\u003cli\u003eRestrict which IAM roles and identities can call \u003ccode\u003ests:AssumeRoot\u003c/code\u003e, using IAM conditions (e.g., \u003ccode\u003eaws:PrincipalArn\u003c/code\u003e, \u003ccode\u003eaws:PrincipalOrgID\u003c/code\u003e, \u003ccode\u003eaws:RequestedRegion\u003c/code\u003e) as mentioned in the overview section.\u003c/li\u003e\n\u003cli\u003eEnsure \u003ccode\u003eAssumeRoot\u003c/code\u003e activity is included in your SIEM dashboards and investigation playbooks as described in the overview section.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging and ensure the logs are being ingested into your SIEM (see index in rule).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-24T00:00:00Z","date_published":"2024-11-24T00:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-11-aws-sts-assumeroot-rare-user/","summary":"The rule detects when the STS AssumeRoot action is performed by a rare user in AWS, potentially indicating privilege escalation.","title":"AWS STS AssumeRoot by Rare User and Member Account","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-sts-assumeroot-rare-user/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Security Token Service"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","defense-evasion","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon Web Services"],"content_html":"\u003cp\u003eThe AWS Security Token Service (STS) GetFederationToken API allows users to request temporary security credentials with a maximum expiration of 36 hours. These tokens can be used to create console sign-in tokens, even for identities that don't already have one. Attackers may exploit this API to gain persistent access to AWS resources, even after the initial compromised identity is revoked. This technique can also bypass IAM API call limitations, allowing adversaries to perform sensitive actions with temporary credentials. The detection of the first occurrence of this API call by a user can help identify potential misuse and unauthorized access attempts within AWS environments. Identifying anomalous GetFederationToken requests is crucial for detecting and responding to potential defense evasion and persistence tactics used by attackers.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of an AWS user identity or service account through credential theft or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised identity to call the \u003ccode\u003eGetFederationToken\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe STS service issues temporary security credentials, including an access key, secret key, and session token.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their tools or scripts to use these temporary credentials for subsequent AWS API calls.\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the temporary credentials to access AWS resources and perform actions that may be restricted by IAM policies on the original compromised identity.\u003c/li\u003e\n\u003cli\u003eThe attacker may also create a console sign-in token using the temporary credentials for console-based access to AWS resources.\u003c/li\u003e\n\u003cli\u003eEven if the initial compromised identity is revoked or deleted, the temporary credentials remain valid for up to 36 hours, allowing the attacker to maintain access.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the persistent access to perform actions such as data exfiltration, resource modification, or further lateral movement within the AWS environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive AWS resources, data breaches, and potential disruption of services. The impact can be significant, as attackers can maintain access for up to 36 hours even after the initial compromised identity is revoked. This persistence allows attackers to perform a wide range of malicious activities, potentially affecting critical business operations and resulting in financial losses and reputational damage. Organizations in all sectors utilizing AWS are potentially vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;AWS First Occurrence of STS GetFederationToken Request by User\u0026quot; to your SIEM to detect suspicious GetFederationToken requests.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unusual user behavior and unexpected request origins.\u003c/li\u003e\n\u003cli\u003eReview the CloudTrail logs for the requesting user (\u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e) to verify if the \u003ccode\u003eGetFederationToken\u003c/code\u003e request was legitimate.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for \u003ccode\u003eGetFederationToken\u003c/code\u003e requests, as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eAttach a policy that denies all actions, such as the \u003ccode\u003eAWSDenyAll\u003c/code\u003e policy, to revoke privileges of compromised users.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T12:00:00Z","date_published":"2024-10-26T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-10-aws-get-federation-token/","summary":"Detection of the first AWS Security Token Service (STS) GetFederationToken request by a user, which adversaries can abuse to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access.","title":"AWS STS GetFederationToken Request for Defense Evasion and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-get-federation-token/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":true,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Security Token Service","AWS Identity and Access Management"],"_cs_severities":["low"],"_cs_tags":["aws","cloudtrail","sts","assume_role","mfa","persistence","privilege_escalation","lateral_movement"],"_cs_type":"threat","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection rule identifies instances of AWS Security Token Service (STS) \u003ccode\u003eAssumeRole\u003c/code\u003e calls where a new Multi-Factor Authentication (MFA) device is used. While legitimate administrative tasks may involve assuming roles with new MFA devices, adversaries can leverage this technique to establish persistence, escalate privileges, or move laterally within an AWS environment. The rule focuses on successful \u003ccode\u003eAssumeRole\u003c/code\u003e, \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e, and \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e events, specifically looking for the presence of a serial number associated with the MFA device in the request parameters, indicating a new MFA device was used. This activity warrants investigation to determine if it is authorized or indicative of malicious behavior. The rule uses a 10-day history window to define \u0026quot;new\u0026quot; MFA devices.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker registers a new MFA device within the compromised AWS account (T1556.006).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS STS \u003ccode\u003eAssumeRole\u003c/code\u003e API to request temporary credentials for a different IAM role (T1550).\u003c/li\u003e\n\u003cli\u003eThe request includes the serial number of the newly registered MFA device in the \u003ccode\u003erequest_parameters\u003c/code\u003e (part of the AssumeRole call).\u003c/li\u003e\n\u003cli\u003eAWS STS validates the MFA and, if successful, issues temporary credentials associated with the assumed role (T1550.001).\u003c/li\u003e\n\u003cli\u003eThe attacker uses these temporary credentials to access resources and perform actions authorized by the assumed role (T1078).\u003c/li\u003e\n\u003cli\u003eThis may involve escalating privileges, accessing sensitive data, or moving laterally to other AWS resources (TA0004, TA0008).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rules to your SIEM to detect the use of new MFA devices in \u003ccode\u003eAssumeRole\u003c/code\u003e calls and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging and ensure proper configuration of the AWS Fleet integration or Filebeat module to capture relevant STS events.\u003c/li\u003e\n\u003cli\u003eReview AWS CloudTrail logs for unusual patterns of MFA device registrations and role assumptions, focusing on privilege escalation or lateral movement attempts.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.\u003c/li\u003e\n\u003cli\u003eCreate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T12:00:00Z","date_published":"2024-10-26T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-assume-role-new-mfa/","summary":"This rule identifies when a user has assumed a role using a new MFA device in AWS, which can be indicative of persistence and privilege escalation attempts by threat actors.","title":"AWS STS AssumeRole with New MFA Device","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-assume-role-new-mfa/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Security Token Service","AWS Identity and Access Management"],"_cs_severities":["medium"],"_cs_tags":["aws","sts","role-chaining","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis threat brief addresses the potential abuse of AWS STS role chaining. Role chaining is a legitimate AWS feature where an assumed role is used to assume another role through the AWS CLI or API. However, malicious actors can exploit this functionality to escalate privileges if the second assumed role has broader permissions than the initial role. The chaining can also be used as a persistence mechanism since each \u003ccode\u003eAssumeRole\u003c/code\u003e action results in a refreshed session token with a maximum duration of one hour. This activity is detected by monitoring CloudTrail logs for the first occurrence of a role (identified by \u003ccode\u003eaws.cloudtrail.user_identity.session_context.session_issuer.arn\u003c/code\u003e) assuming another role (\u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e). Detection focuses on identifying novel role-chaining relationships to highlight potentially unauthorized activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, possibly through compromised credentials or an exposed access key.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to assume an initial IAM role using \u003ccode\u003ests:AssumeRole\u003c/code\u003e. This action is logged in CloudTrail with the \u003ccode\u003eAssumeRole\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker then uses the temporary credentials obtained from the first role to assume a second IAM role, again using \u003ccode\u003ests:AssumeRole\u003c/code\u003e. The \u003ccode\u003eaws.cloudtrail.user_identity.session_context.session_issuer.arn\u003c/code\u003e field identifies the first role, and the \u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e field identifies the second role.\u003c/li\u003e\n\u003cli\u003eIf 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eEach AssumeRole action generates new temporary credentials, effectively refreshing the attacker's session.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence within the AWS environment by repeatedly chaining roles to refresh temporary credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as exfiltrating sensitive data, deploying malware, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect AWS STS Role Chaining\u003c/code\u003e to identify instances of role chaining in AWS CloudTrail logs. Tune the rule to exclude expected role-chaining patterns based on your environment (\u003ccode\u003eaws.cloudtrail.user_identity.session_context.session_issuer.arn\u003c/code\u003e, \u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAssumeRole\u003c/code\u003e events where \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e is \u003ccode\u003eAssumedRole\u003c/code\u003e, focusing on unusual or unexpected role combinations.\u003c/li\u003e\n\u003cli\u003eImplement least privilege policies for all IAM roles, limiting trust policies to only required principals. Periodically review role chaining patterns to validate necessity.\u003c/li\u003e\n\u003cli\u003eUse the \u003ccode\u003eAWS STS Role Chaining\u003c/code\u003e Sigma rule to identify potential role chaining attempts and investigate accordingly.\u003c/li\u003e\n\u003cli\u003eCorrelate CloudTrail logs with other security events (e.g., GuardDuty alerts) to identify potential privilege escalation or data exfiltration activities following role chaining.\u003c/li\u003e\n\u003cli\u003eEnable MFA where possible on \u003ccode\u003eAssumeRole\u003c/code\u003e operations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-25T12:00:00Z","date_published":"2024-10-25T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-role-chaining/","summary":"AWS STS role chaining, where one assumed role is used to assume another, can lead to privilege escalation or persistence by refreshing session tokens, triggering alerts on the first observed role assumption based on CloudTrail logs.","title":"AWS STS Role Chaining for Privilege Escalation and Persistence","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-role-chaining/"}],"language":"en","title":"CraftedSignal Threat Feed - AWS Security Token Service","version":"https://jsonfeed.org/version/1.1"}