Full Report
Dive into the complexities of AWS IAM credentials and uncover how defenders can stay ahead with in-depth knowledge of SDK behaviors and service-specific mechanisms.
Analysis Summary
# Tool/Technique: AWS IAM Role Credential Access Methods
## Overview
This summary details the various mechanisms and locations within the Amazon Web Services (AWS) environment that applications and services use to obtain AWS Identity and Access Management (IAM) role credentials, which are prime targets for attackers with cloud knowledge.
## Technical Details
- Type: Technique (Credential Access)
- Platform: AWS (EC2, Lambda, ECS/EKS, SageMaker, CodeBuild, Batch, CloudShell, IoT Greengrass, Cognito, DataSync)
- Capabilities: Describes multiple methods (SDK configuration, environment variables, metadata services, API calls) for deriving temporary or permanent IAM credentials.
- First Seen: Varies by feature (e.g., IAM Roles for EC2 instances in 2012, IMDSv2 in 2019, IAM Roles Anywhere in 2022).
## MITRE ATT&CK Mapping
- TA0006 - Credential Access
- T1552 - Unsecured Credentials
- T1552.006 - Cloud Instance Metadata Service API
- T1552.007 - Cloud Instance Metadata Service Credentials
## Functionality
### Core Capabilities
The AWS SDK and various services prioritize credentials based on the following order/sources:
1. **Explicitly Set Code:** Credentials hardcoded in application logic take highest precedence.
2. **Environment Variables:** Standard variables like `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN`. Lambda environments populate these from the assigned IAM role.
3. **Configuration Files:** Credentials located in `~/.aws/credentials` and `~/.aws/config`, or older paths like `/etc/boto.cfg` and `~/.boto`.
4. **Instance Metadata Service (IMDS):** Accessed via `http://169.254.169.254/latest/meta-data/iam/security-credentials/` (IMDSv1) or alternatives for IMDSv2 requiring session tokens. Also accessible via IPv6 at `[fd00:ec2::254]`.
### Advanced Features
- **Container Credentials:** ECS/EKS use `http://169.254.170.2/v2/credentials/<URI>` via the `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` environment variable.
- **EKS Pod Identities:** Uses IP `169.254.170.23` (`[fd00:ec2::23]`) and the `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` variable holding a token for the `Authorization` header.
- **IRSA (IAM Roles for Service Accounts):** Utilizes OIDC tokens via environment variables (`AWS_WEB_IDENTITY_TOKEN_FILE`, `AWS_ROLE_ARN`) to call `sts:AssumeRoleWithWebIdentity`.
- **IAM Roles Anywhere:** Allows non-AWS resources to assume IAM roles using X.509 certificates, potentially using a `credential_process` if PKCS#11 cryptographic modules are involved.
- **Cognito:** Applications can retrieve temporary session credentials by calling the `GetCredentialsForIdentity` API with an Identity ID.
- **DataSync:** Uses local files (`cert.pem` and `keypair.pem` in `/usr/local/aws-storage-gateway/var/`) for authenticating to S3.
- **Default Host Management Configuration:** Allows a compute resource (like EC2) to have a secondary IAM role specifically for SSM Agent management purposes, separate from the primary instance profile.
## Indicators of Compromise
- File Hashes: N/A (Focus is on methods, not specific malware samples)
- File Names: `~/.aws/credentials`, `~/.aws/config`, `/etc/boto.cfg`, `~/.boto`, `cert.pem`, `keypair.pem`
- Registry Keys: N/A
- Network Indicators:
- `169.254.169.254` (IMDS endpoint)
- `[fd00:ec2::254]` (IMDS IPv6 endpoint)
- `169.254.170.2` (Container credential endpoint)
- `169.254.170.23` (EKS Pod Identity endpoint)
- `sts:AssumeRoleWithWebIdentity` (API call target)
- Behavioral Indicators: Discovery attempts targeting metadata services, enumeration of environment variables containing AWS prefixes, reading standard AWS configuration files.
## Associated Threat Actors
The document implies any actor with knowledge of AWS infrastructure and credential management methodologies would employ these techniques for privilege escalation and persistence within compromised cloud environments. Specific actors are not named, but this covers general cloud intrusion tradecraft.
## Detection Methods
- Signature-based detection: Less effective as these are standard AWS access mechanisms.
- Behavioral detection: Monitoring for unusual process execution attempting to read metadata services, standard config/credential files, or executing specific API calls like `sts:AssumeRoleWithWebIdentity`.
- YARA rules: N/A
## Mitigation Strategies
- **IMDSv2 Adoption:** Mandate the use of IMDSv2 on EC2 instances to require token retrieval via PUT requests, limiting SSRF impact.
- **Restrict Network Access:** Implement Security Groups and Network ACLs to restrict access to metadata IP addresses (`169.254.169.254`, `169.254.170.2`, etc.) from unauthorized internal network segments.
- **Least Privilege:** Ensure IAM roles assigned to services (EC2, Lambda, Containers) have only the minimum necessary permissions.
- **Code Scanning:** Regularly audit source code and configuration files for hardcoded IAM access keys.
- **IAM Roles Anywhere:** If used, ensure strong controls around the management and storage of X.509 certificates and cryptographic modules.
## Related Tools/Techniques
- AWS CLI/SDK: The software frameworks that implement these credential-seeking procedures.
- SSRF (Server-Side Request Forgery): A common exploitation technique used to query metadata services like `169.254.169.254`.