diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
index 204c20c1a1..1456ccb65f 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -100,6 +100,18 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
 response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
 ```
 
+### **`sts:GetFederationToken`**
+
+With this permission it's possible to create a federated identity for the user executing it, limited to the permissions that this user has.
+
+```bash
+aws sts get-federation-token --name <username>
+```
+
+The token returned by sts:GetFederationToken belongs to the federated identity of the calling user, but with restricted permissions. Even if the user has administrator rights, certain actions such as listing IAM users or attaching policies cannot be performed through the federated token.
+
+Additionally, this method is somewhat more stealthy, since the federated user does not appear in the AWS Portal, it can only be observed through CloudTrail logs or monitoring tools.
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
index b602cfeea3..0b2093cb5f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -37,29 +37,6 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 > Note that in this case the permission `sts:AssumeRole` needs to be **indicated in the role to abuse** and not in a policy belonging to the attacker.\
 > With one exception, in order to **assume a role from a different account** the attacker account **also needs** to have the **`sts:AssumeRole`** over the role.
 
-### **`sts:GetFederationToken`**
-
-With this permission it's possible to generate credentials to impersonate any user:
-
-```bash
-aws sts get-federation-token --name <username>
-```
-
-This is how this permission can be given securely without giving access to impersonate other users:
-
-```json
-{
-  "Version": "2012-10-17",
-  "Statement": [
-    {
-      "Sid": "VisualEditor0",
-      "Effect": "Allow",
-      "Action": "sts:GetFederationToken",
-      "Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
-    }
-  ]
-}
-```
 
 ### `sts:AssumeRoleWithSAML`
 
@@ -158,6 +135,11 @@ aws_signing_helper credential-process \
   --role-arn arn:aws:iam::123456789012:role/Admin
 ```
 
+The trust anchor validates that the client certificate `readonly.pem` comes from its authorized CA, when the trust anchor was created the CA’s public certificate was included (and now used to validate `readonly.pem`). Inside `readonly.pem` is the public key, which AWS uses to verify that the signature was made with its corresponding private key `readonly.key`.
+
+The certificate also proves identity and provides attributes (such as CN or OU) that the `default` profile transforms into tags, which the role’s trust policy can use to decide whether to authorize access, if there are no conditions in the trust policy, those tags are ignored and anyone with a valid certificate is allowed through.
+
+For this attack to be possible, both the trust anchor and the default profile must be active.
 
 ### References