From e153dc47b0b30daa22e89383183cc9beac31a837 Mon Sep 17 00:00:00 2001 From: JaimePolop Date: Mon, 29 Sep 2025 17:14:00 +0200 Subject: [PATCH 1/3] stsgetfederatedtoken --- .../aws-sts-post-exploitation.md | 12 ++++++++++ .../aws-sts-privesc.md | 23 ------------------- 2 files changed, 12 insertions(+), 23 deletions(-) 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 204c20c1a..e8e8b0079 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 +``` + +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 console (IAM 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 b602cfeea..86f7ebb2b 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 -``` - -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` From 590e54ea9e5ba9fbb9046940a6b4e38179256421 Mon Sep 17 00:00:00 2001 From: JaimePolop Date: Mon, 29 Sep 2025 17:15:59 +0200 Subject: [PATCH 2/3] stsgetfederatedtoken --- .../aws-post-exploitation/aws-sts-post-exploitation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 e8e8b0079..1456ccb65 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 @@ -110,7 +110,7 @@ aws sts get-federation-token --name 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 console (IAM portal), it can only be observed through CloudTrail logs or monitoring tools. +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}} From f3afa739ad4930b406b333ca5bc85824eb0aec83 Mon Sep 17 00:00:00 2001 From: JaimePolop Date: Mon, 29 Sep 2025 22:53:29 +0200 Subject: [PATCH 3/3] Roles Anywhere explanation --- .../aws-security/aws-privilege-escalation/aws-sts-privesc.md | 5 +++++ 1 file changed, 5 insertions(+) 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 86f7ebb2b..0b2093cb5 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 @@ -135,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