Merge pull request #287 from Hacking-the-Cloud/add_get_federation_tok…

…en_article

Added an article on using sts:GetFederationToken

content/aws/post_exploitation/iam_persistence.md

@@ -85,6 +85,18 @@ An adversary could invoke `iam:UpdateAssumeRolePolicy`, specifying that their ow
     For the defensive side; it is a good idea to regularly audit role trust policies that establish trust with AWS accounts outside of your organization. In most cases, this will likely identify SaaS and vendor [AWS accounts](https://github.com/fwdcloudsec/known_aws_accounts), however it may turn up something much more nefarious.
 
 
+## Survive Access Key Deletion with sts:GetFederationToken 
+
+<div class="grid cards" markdown>
+
+-   :material-link-box-outline:{ .lg .middle } __Technique Article__
+
+    ---
+
+    - [Survive Access Key Deletion with sts:GetFederationToken](https://hackingthe.cloud/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken/)
+
+</div>
+
 ## EC2 Instance Persistence
 
 EC2 instances which have an IAM role attached to them will have their own [instance metadata service](https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/) (IMDS) available. If an adversary has code execution on the EC2 instance, or is able to abuse [server side request forgery](https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/) in an application running on the host, they can steal IAM credentials from the IMDS.

content/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken.md

@@ -0,0 +1,56 @@
+---
+author_name: Nick Frichette
+title: Survive Access Key Deletion with sts:GetFederationToken
+description: Use sts:GetFederationToken to maintain access, even if the original IAM credentials are revoked.
+hide:
+    - toc
+---
+
+<div class="grid cards" markdown>
+
+-   :material-alert-decagram:{ .lg .middle } __Technique seen in the wild__
+
+    ---
+
+    - [How Adversaries Can Persist with AWS User Federation](https://www.crowdstrike.com/blog/how-adversaries-persist-with-aws-user-federation/)
+
+-   :material-file-document-alert:{ .lg .middle } __Required IAM Permission__
+
+    ---
+
+    - [sts:GetFederationToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-federation-token.html)
+
+</div>
+
+After identifying that [access keys](https://hackingthe.cloud/aws/general-knowledge/using_stolen_iam_credentials/) 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`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-federation-token.html), 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](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html):
+
+- 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](https://hackingthe.cloud/aws/post_exploitation/create_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](https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/), [maintaining persistence](https://hackingthe.cloud/aws/post_exploitation/iam_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:
+
+```shell
+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](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-federation-token.html#options), 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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) to prevent it.