Identity recon is Phase 5 of --godeep. It answers the fundamental pentesting question: who am I, what can I do, and where can I escalate?

The identity recon chain (chain_iam_self) builds a complete map of the current principal's permissions. This is the most critical phase for planning your next move.

awsault --godeep

• Type: User or Role (determined from STS caller identity ARN)
• Principal name: The IAM user or role name
• Account ID: The AWS account number
• Full ARN: Complete Amazon Resource Name
• Groups: Group memberships (for users)

Every policy attached to your identity, with the actual JSON statements:

• Inline policies — policies embedded directly on the user (list_user_policies → get_user_policy)
• Attached managed policies — customer or AWS managed policies (list_attached_user_policies → get_policy → get_policy_version)
• Group-inherited policies — for each group membership:
  • Group inline policies (list_group_policies → get_group_policy)
  • Group attached managed policies (list_attached_group_policies → get_policy → get_policy_version)

• Inline policies (list_role_policies → get_role_policy)
• Attached managed policies (list_attached_role_policies → get_policy → get_policy_version)

Each policy is broken down into its individual statements showing:

• Effect: Allow or Deny
• Actions: The IAM actions permitted or denied (e.g., s3:GetObject, iam:*)
• Resources: The resource ARNs the statement applies to (e.g., arn:aws:s3:::*, *)
• Conditions: Any conditional constraints (flagged in output)

For each managed policy, AWSault enumerates all versions (not just the default):

PolicyName: my-custom-policy
  Default: v3 (current)
  v1: Allow s3:*, iam:* on *     ← more permissive!
  v2: Allow s3:GetObject on *

This is critical for the SetDefaultPolicyVersion privilege escalation technique. If an older version has more permissions, and you can call iam:SetDefaultPolicyVersion, you can switch to it.

AWSault discovers roles you can assume through two methods:

Scans your effective policies for sts:AssumeRole actions and extracts the target role ARNs from the Resource field.

For every role discovered during the surface scan, checks if the role's trust policy allows your identity (user, role, or account) to assume it.

For each assumable role, AWSault then enumerates:

• Role description
• All inline policies with documents
• All attached managed policies with documents
• Why you can assume it (policy grant or trust policy match)

Scans all discovered policies (direct and via assumable roles) for 14 known IAM escalation techniques. See Privilege Escalation for the full list.

Based on discovered permissions, AWSault generates concrete AWS CLI commands you can copy-paste:

# if you can assume a role
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/admin-role --role-session-name awsault

# if privesc via SetDefaultPolicyVersion
aws iam set-default-policy-version --policy-arn arn:aws:iam::123456789012:policy/my-policy --version-id v1

# if you have S3 access
aws s3 ls

# if you can read secrets
aws secretsmanager list-secrets
aws ssm describe-parameters

# if you can access DynamoDB
aws dynamodb list-tables
aws dynamodb scan --table-name <table>

# if you can invoke Lambda
aws lambda list-functions
aws lambda invoke --function-name <name> output.json

The recon section displays:

1. Identity box — who you are
2. Effective Policies — each policy as a collapsible section with color-coded Allow/Deny statements
3. Alternate Policy Versions — shown under each managed policy when non-default versions exist
4. Assumable Roles — each role with its full policy breakdown
5. PRIVILEGE ESCALATION PATHS — prominently highlighted with severity badges
6. Suggested Next Steps — actionable commands

All recon data is included in every export format:

• HTML — dedicated Recon tab with collapsible policy cards, role cards, and privesc section
• CSV — identity info, policy statements as flat rows, assumable roles with policies, privesc paths
• JSON — full structured data under the recon key

AWSault parses the ARN from sts:GetCallerIdentity:

The enumeration path differs based on identity type — users have groups and login profiles; roles have trust policies.

The surface scan fires broad parameterless calls like iam:ListUsers and iam:ListRoles which require broad IAM permissions. However, the identity recon chain uses targeted calls scoped to your own principal:

list_attached_user_policies --user-name YOUR_NAME    ← works with scoped permissions
list_users                                            ← requires broad IAM read access

So even if the surface scan shows IAM as 0/15, the identity recon can still successfully map your complete permission set.