Migrate to using mdbook

src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md

@@ -0,0 +1,100 @@
+# AWS - STS Enum
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## STS
+
+**AWS Security Token Service (STS)** is primarily designed to issue **temporary, limited-privilege credentials**. These credentials can be requested for **AWS Identity and Access Management (IAM)** users or for authenticated users (federated users).
+
+Given that STS's purpose is to **issue credentials for identity impersonation**, the service is immensely valuable for **escalating privileges and maintaining persistence**, even though it might not have a wide array of options.
+
+### Assume Role Impersonation
+
+The action [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) provided by AWS STS is crucial as it permits a principal to acquire credentials for another principal, essentially impersonating them. Upon invocation, it responds with an access key ID, a secret key, and a session token corresponding to the specified ARN.
+
+For Penetration Testers or Red Team members, this technique is instrumental for privilege escalation (as elaborated [**here**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). However, it's worth noting that this technique is quite conspicuous and may not catch an attacker off guard.
+
+#### Assume Role Logic
+
+In order to assume a role in the same account if the **role to assume is allowing specifically a role ARN** like in:
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Principal": {
+        "AWS": "arn:aws:iam::<acc_id>:role/priv-role"
+      },
+      "Action": "sts:AssumeRole",
+      "Condition": {}
+    }
+  ]
+}
+```
+
+The role **`priv-role`** in this case, **doesn't need to be specifically allowed** to assume that role (with that allowance is enough).
+
+However, if a role is allowing an account to assume it, like in:
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Principal": {
+        "AWS": "arn:aws:iam::<acc_id>:root"
+      },
+      "Action": "sts:AssumeRole",
+      "Condition": {}
+    }
+  ]
+}
+```
+
+The role trying to assume it will need a **specific `sts:AssumeRole` permission** over that role **to assume it**.
+
+If you try to assume a **role** **from a different account**, the **assumed role must allow it** (indicating the role **ARN** or the **external account**), and the **role trying to assume** the other one **MUST** to h**ave permissions to assume it** (in this case this isn't optional even if the assumed role is specifying an ARN).
+
+### Enumeration
+
+```bash
+# Get basic info of the creds
+aws sts get-caller-identity
+aws sts get-access-key-info --access-key-id <AccessKeyID>
+
+# Get CLI a session token with current creds
+## Using CLI creds
+## You cannot get session creds using session creds
+aws sts get-session-token
+## MFA
+aws sts get-session-token --serial-number <arn_device> --token-code <otp_code>
+```
+
+### Privesc
+
+In the following page you can check how to **abuse STS permissions to escalate privileges**:
+
+{{#ref}}
+../aws-privilege-escalation/aws-sts-privesc.md
+{{#endref}}
+
+### Post Exploitation
+
+{{#ref}}
+../aws-post-exploitation/aws-sts-post-exploitation.md
+{{#endref}}
+
+### Persistence
+
+{{#ref}}
+../aws-persistence/aws-sts-persistence.md
+{{#endref}}
+
+## References
+
+- [https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist](https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist)
+
+{{#include ../../../banners/hacktricks-training.md}}