Roles Anywhere explanation

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md

@@ -100,6 +100,10 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 
 AWS IAM RolesAnywhere allows workloads outside AWS to assume IAM roles using X.509 certificates. But when trust policies aren't properly scoped, they can be abused for privilege escalation.
 
+To understand this attack, it is necessary to explain what a trust anchor is. A trust anchor in AWS IAM Roles Anywhere is the root of trust entity, it contains the public certificate of a Certificate Authority (CA) that is registered in the account so that AWS can validate the presented X.509 certificates. In this way, if the client certificate was issued by that CA and the trust anchor is active, AWS recognizes it as valid.
+
+In addition, a profile is the configuration that defines which attributes of the X.509 certificate (such as CN, OU, or SAN) will be transformed into session tags, and these tags will later be compared against the conditions of the trust policy.
+
 This policy lacks restrictions on which trust anchor or certificate attributes are allowed. As a result, any certificate tied to any trust anchor in the account can be used to assume this role.
 
 ```json
@@ -135,11 +139,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 trust anchor validates that the client’s `readonly.pem` certificate comes from its authorized CA, and within this `readonly.pem` certificate is the public key that 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.
+The certificate also 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 have no use, and access is granted to anyone with a valid certificate.
 
-For this attack to be possible, both the trust anchor and the default profile must be active.
+For this attack to be possible, both the trust anchor and the `default` profile must be active.
 
 ### References