{
	"id": "6e341937-603c-4b2c-a7c0-7882c7d789f7",
	"created_at": "2026-04-06T01:29:37.899568Z",
	"updated_at": "2026-04-10T03:21:28.099226Z",
	"deleted_at": null,
	"sha1_hash": "cac53126f03d2939cb06d70ed33b0baab12a68df",
	"title": "How Adversaries Can Persist with AWS User Federation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 9685432,
	"plain_text": "How Adversaries Can Persist with AWS User Federation\r\nBy Vaishnav Murthy - Joel Eng\r\nArchived: 2026-04-06 01:18:23 UTC\r\nCrowdStrike Services identified a novel technique used by threat actors that escapes typical containment\r\npractices and permits persistence in victim AWS environments.\r\nThe technique requires that the adversary first obtain valid AWS API credentials with the necessary\r\nsecurity token service (STS) and identity and access management (IAM) permissions, and then use the\r\nsts:GetFederationToken API call to create a federated user session.\r\nPermissions and access to the federated sign-in session survive the deactivation of the base user’s API\r\ncredentials.\r\nResponders should attach an explicit deny-all IAM policy to compromised IAM users as a containment\r\nmeasure. If a root API key is compromised, containment is much more challenging and may not always be\r\npossible. Note: Creating an AWS API key (a prerequisite for this technique) for the root user is\r\ndiscouraged by AWS. Organizations should use the root user sparingly, and only via the AWS console.\r\nIn recent incident response investigations, CrowdStrike Services has observed adversaries use the\r\nsts:GetFederationToken API call to create federated sessions from IAM users. In this scenario, the federated\r\nsession inherits permissions from the base IAM user.\r\nPerhaps surprising to many incident responders, the privileges and access of the federated session are not revoked\r\nwhen the base IAM user’s credentials are deactivated. Many defenders may not realize it, but this is a\r\ncharacteristic of all forms of temporary credentials obtained via the various API calls to AWS STS. The resulting\r\nsessions are independent of the long-term credentials of the underlying IAM or root user. The privileges of the\r\nfederated session are only reduced or revoked when the IAM policies attached to the base IAM user are modified\r\nto reduce or revoke those permissions. (Deleting the IAM user will effectively revoke all privileges but\r\nCrowdStrike does not recommend doing so, as detailed below.). The federated session remains active until the\r\nsession token expires.1\r\nIt is common for incident responders to only deactivate the base IAM user’s credentials. However, this will not be\r\nsufficient to contain an attack utilizing this technique. CrowdStrike is posting this blog to raise awareness of the\r\nuse of this technique by threat actors and how threat actors can expand its use to establish persistence and escalate\r\nprivileges within AWS environments if the underlying IAM user already had those escalation privileges.\r\nLearn how CrowdStrike Services can help your organization respond to and recover from incidents with\r\nspeed and precision, prepare to defend against sophisticated threats and fortify your cybersecurity\r\npractices.\r\nWhat Is a Federated Session?\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 1 of 13\n\nA federated session in AWS involves exchanging long-lived credentials for a temporary set of credentials: an AWS\r\naccess key, AWS secret key and AWS session token, issued by AWS STS. AWS has stated that federated sessions\r\nwere predominantly used within custom access brokers before the advent of modern methods using IAM roles\r\ninstead.\r\nAWS’s best practice is to use temporary credentials instead of long-lived credentials (such as API keys and\r\npasswords tied to local IAM users) in most use cases. AWS also recommends using federation-based AWS\r\nIdentity Center for managing access for all human users. Using temporary security credentials enhances security\r\nby eliminating the exposure from static credentials that are vulnerable to theft and ensuring that any stolen session\r\ntokens have a limited lifespan.\r\nA method for federating users that, in CrowdStrike’s experience, is not well known by cloud practitioners is\r\nfederating directly from IAM user and root principals. All IAM users that have been granted the permission\r\nsts:GetFederationToken and the account’s root user are capable of acting as local identity providers and issuing\r\ntemporary credentials for this type of federation. AWS describes a use case for this capability as:\r\nA typical use is in a proxy application that gets temporary security credentials on behalf of distributed\r\napplications inside a corporate network. You must call the GetFederationToken operation using the\r\nlong-term security credentials of an IAM user. As a result, this call is appropriate in contexts where\r\nthose credentials can be safely stored, usually in a server-based application.\r\nBecause it is older and less commonly used, most organizations are unaware of the user-based federation\r\ncapability and treat IAM users as local service accounts whose permissions are bound to the long-term credentials\r\nof that single entity. However, using the sts:GetFederationToken API, a user can pass its privileges for use in a\r\nderivative federated session, which operates with distinct credentials.\r\nAWS places certain limits on federation-based privilege inheritance: The temporary credentials associated with the\r\nfederated session cannot have greater privileges than the original identity. In addition, the federated session is\r\nblocked from exercising IAM actions from the AWS CLI or API. However, these IAM limits do not apply to\r\nconsole sessions, which is how an adversary with the compromised credentials of an IAM user with certain IAM\r\nprivileges can abuse user-based federation to persist despite deactivation of the base identity’s compromised\r\ncredentials.\r\nAWS previously indicated in its documentation that IAM limitations for federated sessions were limited to the\r\nCLI/SDK and did not apply when using the AWS console,2 but after being notified of these concerns by\r\nCrowdStrike, AWS agreed the documentation could be made clearer and has done so by stating explicitly that\r\nIAM limitations do not apply to console usage. This change was made prior to the publication of this blog post.\r\nPersistence Technique\r\nThis persistence technique takes advantage of the following:\r\nIncident response teams are trained to preserve artifacts and affected resources such as IAM users during\r\nan incident. So instead of deleting the affected IAM user, or detaching IAM policies, they often will simply\r\ndisable an IAM user’s API keys as a method of containment.\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 2 of 13\n\nFederated sessions can be used to make IAM changes via the AWS console\r\nThe steps to utilize this technique are outlined below. Note that the technique works for an account’s root user as\r\nwell as any IAM user with the required permissions, but in the interest of clarity, only the IAM user approach is\r\ndescribed.\r\n1. Compromise an IAM user with the required permissions\r\nThe technique begins when an adversary compromises a user who has the minimum permissions set of\r\nsts:GetFederationToken , iam:ListAccessKeys and iam:UpdateAccessKey . This is unfortunately a common\r\nscenario, given that many operations teams attach the highly privileged AdministratorAccess IAM policy to\r\nIAM users for ease of use, which allows all API actions.\r\nFigure 1. IAM policy granting permission to call the sts:GetFederationToken API call (click to enlarge)\r\nThis IAM user does not need to have a password (console access) configured. The technique will work as long\r\nas the adversary has access to API keys associated with the base IAM user.\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 3 of 13\n\nFigure 2. IAM user has no password, only an access key (clock to enlarge)\r\n2. Create a federated session from this IAM identity\r\nThe next step is to use an API key associated with the compromised IAM user to get a federation token derived\r\nfrom the identity of that user. The API call requires the caller to specify a name for the session (in this case,\r\n“UnauthorizedUser”) and one or more in-line policies or policy ARNs to limit the privileges that will be granted\r\nto the session. The effective permissions of the resulting temporary credentials are the least-privileged subset of\r\nthe requested permissions and the calling user’s permissions. By specifying AdministratorAccess , which allows\r\nall API actions, the adversary ensures that the federated session will have all of the permissions of the calling user.\r\nFigure 3. API call creating the federated session from the base IAM user (click to enlarge)\r\n3. The federated session permissions allow the adversary to perform all actions that the IAM user\r\ncan perform.\r\nIn the example in Figure 4, the adversary uses the new federated session tokens to exercise the\r\nec2:DescribeRegions permission inherited from the federating IAM user.\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 4 of 13\n\nFigure 4. API calls made using the federated session (click to enlarge)\r\n4. The adversary can use the federated session to log into the console, even if the IAM user has no\r\npassword.\r\nConverting the AWS CLI session to a console session is accomplished by using the federated session token to\r\nrequest a sign-in token from https://signin.aws.amazon\u003c.\u003ecom/federation and then using that token to\r\nauthenticate to the AWS console endpoint https://console.aws.amazon\u003c.\u003ecom/console/home . NetSPI has an\r\neasy-to-use tool for this on GitHub. CrowdStrike has responded to incidents in which adversaries used the\r\naws_consoler tool to generate a sign-in token to access the AWS console using AWS API keys.\r\nFigure 5. Console login using the federated session (click to enlarge)\r\n5. Changing permissions of the originating IAM user immediately affects the federated session,\r\nbut disabling the access key that was used to issue the session does not.\r\nWhile changes to the permissions of the base IAM user are propagated to the federated session, CrowdStrike\r\nfound that disabling the access key that produced the federation session leaves the session intact for the remainder\r\nof the duration specified when it was created. In an incident response situation involving a compromised IAM\r\nuser, many incident response teams leave the IAM user in place, but disable all access keys as part of containment.\r\nBased on CrowdStrike’s observations, this commonly leveraged remediation action is insufficient. Defenders must\r\ninstead revoke or override all permissions for that user. CrowdStrike recommends attaching an explicit deny-all\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 5 of 13\n\nIAM policy to the IAM user, since explicit deny statements take precedence over allow statements. This would let\r\nincident responders preserve the IAM user’s existing permissions instead of having to record them separately and\r\nrecreate them later.\r\nFigure 6. Disabling the base user’s access key does not invalidate the federated session (click to enlarge)\r\n6. If the base IAM user has the UpdateAccessKey IAM permissions assigned to it, the adversary\r\ncan reactivate the deactivated credentials, establishing persistence.\r\nAdversaries also have a way to reestablish persistence using a lingering federated session. As noted earlier, AWS\r\ndocumentation on the GetFederationToken API stated prior to the release of this blog post:\r\nYou can use temporary credentials generated by GetFederationToken in any AWS service except the\r\nfollowing: You cannot call any IAM operations using the AWS CLI or the AWS API.\r\nWhile most IAM actions are denied when using the AWS CLI or the AWS API, these actions are allowed when\r\ndone using the AWS console. A lingering federated session allows the adversary to avoid the additional limitations\r\nAWS places on CLI/SDK-based IAM operations by converting to a console session. An adversary using a\r\ncompromised access key with the sufficient IAM permissions can simply re-enable the key after incident\r\nresponders have performed containment and then issue itself another session.\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 6 of 13\n\nFigure 7. The federated session is able to re-enable the disabled access key of the base user (click to enlarge)\r\nIn comparison, the IAM actions are denied through the CLI regardless of permissions.\r\nFigure 8. The same IAM actions are not allowed using the CLI (click to enlarge)\r\nThe CloudTrail log generated from this activity can be found below:3\r\n{\r\n \"eventVersion\": \"1.08\",\r\n \"userIdentity\": {\r\n \"type\": \"FederatedUser\",\r\n \"principalId\": \"XXXXXXXXXXXX:UnauthorizedUser\",\r\n \"arn\": \"arn:aws:sts::XXXXXXXXXXXX:federated-user/UnauthorizedUser\",\r\n \"accountId\": \"XXXXXXXXXXXX\",\r\n \"accessKeyId\": \"ASIAXXXXXXXXXXXX\",\r\n \"sessionContext\": {\r\n \"sessionIssuer\": {\r\n \"type\": \"IAMUser\",\r\n \"principalId\": \"AIDAY7KV3F6F6NXQB6KUH\",\r\n \"arn\": \"arn:aws:iam::XXXXXXXXXXXX:user/compromised-iam-user\",\r\n \"accountId\": \"XXXXXXXXXXXX\",\r\n \"userName\": \"compromised-iam-user\"\r\n },\r\n \"webIdFederationData\": {},\r\n \"attributes\": {\r\n \"creationDate\": \"2023-01-04T19:43:13Z\",\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 7 of 13\n\n\"mfaAuthenticated\": \"false\"\r\n }\r\n }\r\n },\r\n \"eventTime\": \"2023-01-04T19:53:35Z\",\r\n \"eventSource\": \"iam.amazonaws.com\",\r\n \"eventName\": \"UpdateAccessKey\",\r\n \"awsRegion\": \"us-east-1\",\r\n \"sourceIPAddress\": \"AWS Internal\",\r\n \"userAgent\": \"AWS Internal\",\r\n \"requestParameters\": {\r\n \"userName\": \"compromised-iam-user\",\r\n \"accessKeyId\": \"AKIAXXXXXXXXX\",\r\n \"status\": \"Active\"\r\n },\r\n \"responseElements\": null,\r\n \"requestID\": \"eea9ee11-edb3-4de2-aa00-57a8ec37c9e1\",\r\n \"eventID\": \"beec4fb1-3947-485b-ba2b-12a2cf4353ac\",\r\n \"readOnly\": false,\r\n \"eventType\": \"AwsApiCall\",\r\n \"managementEvent\": true,\r\n \"recipientAccountId\": \"XXXXXXXXXXXX\",\r\n \"eventCategory\": \"Management\",\r\n \"sessionCredentialFromConsole\": \"true\"\r\n}\r\n7. If the IAM user has the AttachUserPolicy or PutUpdatePolicy IAM permissions assigned to it\r\n(essentially permitting privilege elevation by policy), the federated session can create, modify or\r\nattach additional IAM policies to the base IAM user, potentially escalating their privileges —\r\nsomething that is not possible when using the CLI or API.\r\nAdversaries could similarly use the federated session to escalate their privileges if the base user has the requisite\r\nIAM permissions ( AttachUserPolicy or UpdateUserPolicy ) assigned to it. (It should be noted that any\r\nprincipal with those unrestricted privileges is de facto a full administrator since they can add administrative\r\nprivileges to themselves at any time.). Once logged in via the console, the federated session could be used to\r\nattach a privileged policy (such as AdministratorAccess ) to the base IAM user, which would then elevate their\r\nown permissions to include AdministratorAccess .\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 8 of 13\n\nFigure 9. The minimum permissions set necessary for privilege escalation (click to enlarge)\r\nFigure 10. The federated session has added AdministratorAccess to the base IAM user (click to enlarge)\r\nNote that just as in the previous example, these actions cannot be performed via the AWS CLI.\r\nFigure 11. The same API call is blocked using the CLI (click to enlarge)\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 9 of 13\n\n8. The effective privileges of the federated session are only revoked when the base user’s\r\npermissions are detached, or an explicit deny-all IAM policy is applied.\r\nThe only ways to fully contain an adversary using an IAM user federated session are to fully remove or override\r\nthe permissions of the IAM user. CrowdStrike recommends overriding the base IAM user’s permissions with an\r\nexplicit deny-all IAM policy, or if the AWS account is a member of an AWS Organization, an SCP rather than\r\nremoving attached IAM policies. This would allow incident responders to more easily review the full scope of\r\ncapabilities an adversary had during an incident and makes it easier for operations teams to restore functionality\r\npost-remediation. The example below shows an explicit deny-all IAM policy attached to the compromised IAM\r\nuser, that results in the lingering federated session losing all permissions, even in the console.\r\nFigure 12. An explicit deny-all IAM policy is attached to the base IAM user (click to enlarge)\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 10 of 13\n\nFigure 13. Once the explicit deny-all IAM policy is attached, access is denied (click to enlarge)\r\nRecommendations\r\nCrowdStrike recommends that organizations take the following actions for prevention, detection, response and\r\nremediation to protect against this technique.\r\nPrevention\r\nCreate an SCP preventing the use of sts:GetFederationToken for all IAM users:\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": \u003c\r\n {\r\n \"Sid\": \"DenyGetFederationToken\",\r\n \"Effect\": \"Deny\",\r\n \"Principal\": \"*\",\r\n \"Action\": \"sts:GetFederationToken\",\r\n \"Resource\": \"*\"\r\n }\r\n \u003e\r\n}\r\nExercise good root user hygiene by never configuring API keys for the root user, which is a prerequisite for\r\ncreating federated sessions from the root user.\r\nTo the extent possible, CrowdStrike recommends avoiding the use of IAM users. Organizations should\r\nfavor using temporary credentials over long-lived credentials associated with IAM users, by instead using\r\nAWS Identity Center to manage access for all human users, and IAM instance profiles for EC2 instance-https://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 11 of 13\n\nbacked workloads. This will avoid the use of long-lived AWS API keys within the AWS environment,\r\nwhich is a prerequisite for creating federated sessions from IAM users.\r\nDetection\r\nDetect and alert on users calling the GetFederationToken API call. Here’s an example CloudTrail search:\r\neventName=”GetFederationToken” AND eventSource=”sts.amazonaws.com”\r\nIf federated sessions are not used widely in the AWS account or organization, the following CloudTrail\r\nsearch returning all actions taken using federated sessions will return high fidelity indicators of\r\ncompromise: userIdentity.type=”FederatedUser”\r\nResponse and Remediation\r\nAs shown in the above attack description, deactivating the access key of the compromised base IAM user\r\nwill not stop abuse using the federated session. Instead, CrowdStrike recommends using an SCP or explicit\r\ndeny-all IAM policy (described below) to override the permissions assigned to the compromised IAM user.\r\nAWS also recently released a detailed blog post on revoking role session tokens generated via an external\r\nidentity provider that can be referenced for additional remediation strategies.\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": \u003c\r\n {\r\n \"Sid\": \"DenyAll\",\r\n \"Effect\": \"Deny\",\r\n \"Action\": \"*\",\r\n \"Resource\": \"*\"\r\n }\r\n \u003e\r\n}\r\nSummary\r\nCrowdStrike has observed threat actors leveraging federated users in recent investigations, and has identified how\r\nthey can be used to establish persistence within AWS environments. The use of federated sessions is a method by\r\nwhich an adversary possessing persistent API credentials can generate temporary credentials that survive\r\nrevocation of the original persistent credentials. CrowdStrike found that these permissions endure until the pre-established session expiration time, even if the credentials associated with the base user are deactivated. The only\r\nway to revoke the permissions of an IAM user’s federated session is to reduce the scope of permissions assigned\r\nto the base user. This can be done by either detaching all policies assigned to the base user, or attaching an explicit\r\ndeny-all IAM policy or SCP to the base IAM user. Furthermore, federated sessions derived from the root user\r\ncannot be contained except through an SCP, and only for AWS accounts that are members of an AWS\r\norganization.\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 12 of 13\n\nEndnotes\r\n1. The default session duration when acting as an IAM user is 12 hours but can be set as high as 36 hours.\r\nWhen acting as a root user, the maximum duration is 1 hour. Learn more.\r\n2. The documentation pages in question are here and here. Both pages state “You cannot call any IAM\r\noperations using the AWS CLI or the AWS API.” Based on input from CrowdStrike, both pages have been\r\nupdated to add “This limitation does not apply to console sessions.”\r\n3. The CloudTrail events generated from this technique contain the userIdentity.type field of\r\nFederatedUser but it is important to understand that this is not a federated user in the sense of a user who\r\nwas authenticated in an external directory.\r\nAdditional Resources\r\nLearn more about how CrowdStrike Services can help your organization prepare to defend against\r\nsophisticated threats, respond and recover from incidents with speed and precision, and fortify your\r\ncybersecurity practices.\r\nRequest a free CrowdStrike Intelligence threat briefing and learn how to stop adversaries targeting your\r\norganization.\r\nWatch an introductory video on the CrowdStrike Falcon console and see an on-demand demo of the\r\nCrowdStrike Falcon platform in action.\r\nRequest a free trial of the industry-leading CrowdStrike Falcon platform.\r\nSource: https://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nhttps://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/"
	],
	"report_names": [
		"how-adversaries-persist-with-aws-user-federation"
	],
	"threat_actors": [],
	"ts_created_at": 1775438977,
	"ts_updated_at": 1775791288,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cac53126f03d2939cb06d70ed33b0baab12a68df.pdf",
		"text": "https://archive.orkl.eu/cac53126f03d2939cb06d70ed33b0baab12a68df.txt",
		"img": "https://archive.orkl.eu/cac53126f03d2939cb06d70ed33b0baab12a68df.jpg"
	}
}