Defender — Objective 2: Access the Target Account¶

The Concept: Cross-Account Role Assumption¶

In real AWS environments, you never give analysts direct IAM user access to every account. Instead:

Analysts have an IAM user in the Security account
Each target account has an IAM role with a trust policy that allows the Security account to assume it
Analysts assume that role to get temporary access to the target account

Why this is better than direct access: - The analyst's permanent identity lives only in the Security account - Access to target accounts is temporary (session-based, expires) - If a target account is compromised, the analyst's permanent credentials are unaffected - You can audit exactly when the analyst was in each account via CloudTrail

Setting Up the CLI Profile¶

Your ~/.aws/config file (which controls profiles, not credentials):

[profile security]
region=us-east-1
output=json

[profile target_security]
region=us-east-1
output=json
source_profile = security
role_arn = arn:aws:iam::653711331788:role/security

~/.aws/config vs ~/.aws/credentials — what each file contains:

File	Contents
`~/.aws/credentials`	Access Key IDs + Secret Keys + session tokens (the actual secrets)
`~/.aws/config`	Region, output format, profile references, role assumption config (no secrets)

[profile security] — defines a named profile called security. When you use --profile security, the CLI looks up this block for region/output settings and looks in ~/.aws/credentials for the keys.

[profile target_security] — this profile has no static credentials. Instead, two keys define it:

Key	What it does
`source_profile = security`	Use the `security` profile's credentials as the starting identity
`role_arn = arn:aws:iam::653711331788:role/security`	The IAM role in the Target account to assume

What happens under the hood when you use --profile target_security: 1. CLI reads the security profile to get your IAM user credentials 2. CLI automatically calls sts:AssumeRole with those credentials, targeting the role ARN 3. AWS returns temporary credentials (access key + secret + session token) for the security role in the Target account 4. CLI uses those temp credentials for the actual command you ran 5. You never have to manually handle the token — it's all automatic

Breaking Down the Role ARN¶

arn:aws:iam::653711331788:role/security
 ↑   ↑   ↑   ↑↑           ↑↑↑↑↑↑↑↑↑↑↑
 arn aws service           role name
         |   |
         IAM no-region
             (IAM is global — no region in the ARN)

Segment	Value	Meaning
`arn`	`arn`	Amazon Resource Name prefix
`aws`	`aws`	AWS partition (vs `aws-cn` China, `aws-us-gov` GovCloud)
`service`	`iam`	IAM service — global, no region
`region`	`` (empty)	IAM has no region — double colon `::` means empty
`account-id`	`653711331788`	The Target account that owns this role
`resource`	`role/security`	An IAM role named "security"

Verify the Assumption Worked¶

aws --profile target_security sts get-caller-identity

Output:

{
    "Account": "653711331788",
    "UserId": "AROAIKRY5GULQLYOGRMNS:botocore-session-1544126021",
    "Arn": "arn:aws:sts::653711331788:assumed-role/security/botocore-session-1544126021"
}

Account ID is now 653711331788 — the Target account. The Arn shows assumed-role/security/... — you're operating as the security role.

The session name: botocore-session-1544126021 — the AWS SDK (botocore is the Python SDK underneath the CLI) auto-generates a session name when assuming roles. It's just a label to identify this particular session in logs.

In production, you'd set a meaningful session name so auditors can see who was in the account and why:

aws sts assume-role \
  --role-arn arn:aws:iam::653711331788:role/security \
  --role-session-name mark-investigation-2026-03-11

With source_profile in config, the CLI handles this automatically but uses a generic name. You can override it with role_session_name in the config block.

How to Know Which Account You're In¶

Always run this before any enumeration command:

aws sts get-caller-identity --profile <profile>

Account ID	What it means
`322079859186`	Security account — your home base, permanent IAM user
`653711331788`	Target account — compromised environment, assumed role

Running commands against the wrong account is a common mistake. Running iam get-role against the Security account when you meant to query the Target account gives you wrong results without any error.

Confirm Access to the Target¶

aws --profile target_security s3 ls

Returns the S3 buckets from the Attacker path: level1.flaws2.cloud, level2.flaws2.cloud, etc. — you're in the Target account with read access.