Article by Nick Frichette

Survive Access Key Deletion with sts:GetFederationToken

After identifying that access keys have been compromised by an adversary, defenders will often immediately deactivate or delete those credentials. This is a good practice as it theoretically disables an adversary's access to the environment. However, it is important to know that an adversary can still use credentials generated from sts:GetFederationToken, even if the original access keys have been deleted.

sts:GetFederationToken is an API that can be invoked by IAM users and returns a set of temporary (ASIA...) IAM credentials. These credentials can be used normally through the CLI with 2 exceptions. From the documentation:

  • You cannot call any IAM operations using the AWS CLI or the AWS API.
  • You cannot call any AWS STS operations except sts:GetCallerIdentity.

However, it is important to note that these limitations do not apply if an attacker generates a console session from IAM credentials. By using the AWS console you could interact with the IAM service and perform actions such as privilege escalation, maintaining persistence, etc.

Tip

If you are attempting to avoid detection, generating a console session from IAM credentials is NOT advised. There are numerous IoCs which may trigger alerts, such as a suspicious user-agent and the ConsoleLogin CloudTrail event. If at all possible, only use the IAM credentials generated from sts:GetFederationToken in the CLI.

To create temporary IAM credentials using sts:GetFederationToken, you can use the following CLI command:

aws sts get-federation-token \
--name your_choice \
--policy-arns arn=arn:aws:iam::aws:policy/AdministratorAccess \
--duration-seconds 129600

Warning

While all 3 parameters are configurable by the attacker, keep in mind the potential for detection based on this. For instance, in a highly monitored environment, would the use of the AdministratorAccess policy raise suspicions? What about an extremely long lived session?

It is important to note that the provided policy-arns will use the intersection of the permissions that were passed. Meaning that if the user has no permissions, passing the AdministratorAccess policy will not provide it admin access to the account. This can, however, be helpful if you don't know what level of privilege you've compromised. By passing a highly privileged policy, you will ensure you will get the full access afforded to the identity.

Tip

In addition to passing a policy ARN, you can also pass an inline policy, which may be helpful to avoid suspicious use of certain policies.

For defenders, in addition to deactivating or deleting IAM user access keys, it may be worthwhile to attach a "DenyAll" policy to the compromised user. This would ensure that even if an adversary was using this technique, they would not be able to use their generated credentials.

It is also advisable to determine how common the use of sts:GetFederationToken is in your environments and alert on its use, or implement a Service Control Policy to prevent it.