Compromised IAM Credentials

Compromised IAM Credentials: A Complete Guide for the AWS Security Specialty Exam

Why Compromised IAM Credentials Matter

Compromised IAM credentials represent one of the most critical and frequently tested security threats in the AWS ecosystem. When an attacker gains access to IAM access keys, secret keys, or temporary session tokens, they can impersonate legitimate users or services, exfiltrate data, launch resources for cryptomining, or pivot deeper into your AWS environment. According to numerous breach reports, credential compromise remains the number one attack vector in cloud environments. Understanding how to detect, respond to, and remediate compromised IAM credentials is essential not only for passing the AWS Security Specialty exam but also for real-world cloud security operations.

What Are Compromised IAM Credentials?

Compromised IAM credentials refer to any situation where AWS Identity and Access Management credentials — including long-term access keys, passwords, MFA devices, or temporary security tokens issued by AWS STS — fall into the hands of an unauthorized party. This can occur through:

• Accidental exposure: Developers accidentally committing access keys to public GitHub repositories
• Phishing attacks: Social engineering that tricks users into revealing their console passwords or access keys
• Malware or keyloggers: Software on a compromised workstation that captures credentials
• Insider threats: Disgruntled employees misusing their legitimate credentials
• Metadata service exploitation: Attackers exploiting EC2 instance metadata (IMDS) to steal temporary role credentials via SSRF vulnerabilities
• Third-party breaches: Credentials stored in third-party services that get compromised

How Detection of Compromised IAM Credentials Works

AWS provides several services and mechanisms that work together to detect potentially compromised credentials:

1. Amazon GuardDuty
GuardDuty is the primary service for detecting compromised credentials. It analyzes CloudTrail management events, CloudTrail S3 data events, VPC Flow Logs, and DNS logs to identify suspicious activity. Key finding types related to compromised credentials include:

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS — Detects when EC2 instance role credentials are being used from an external IP address outside AWS
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS — Detects when EC2 instance role credentials are being used from a different AWS account
• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — Detects anomalous console logins
• UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom — API calls from known malicious IPs
• Discovery:IAMUser/AnomalousBehavior — Unusual reconnaissance API calls
• Persistence:IAMUser/AnomalousBehavior — Attempts to maintain persistent access

2. AWS CloudTrail
CloudTrail logs all API calls made in your AWS account. When credentials are compromised, the attacker's activities are recorded. You can analyze CloudTrail logs for:

• API calls from unusual IP addresses or geographic locations
• API calls at unusual times
• Calls to sensitive APIs (e.g., creating new IAM users, attaching admin policies)
• Failed authorization attempts indicating privilege escalation attempts

3. Amazon CloudWatch and EventBridge
CloudWatch Alarms and EventBridge rules can be configured to trigger on specific CloudTrail events, such as:

• Root account usage
• IAM policy changes
• Console sign-in failures
• Access key creation for the root account

4. AWS IAM Access Analyzer
Helps identify resources shared with external entities and can flag overly permissive policies that increase the blast radius of compromised credentials.

5. IAM Credential Reports
IAM credential reports provide an audit of all IAM users in your account, showing when access keys were last rotated, whether MFA is enabled, and when passwords were last used. This helps identify stale credentials that are more likely targets for compromise.

6. AWS Security Hub
Aggregates findings from GuardDuty, IAM Access Analyzer, and other services into a single dashboard, enabling centralized visibility into credential compromise indicators.

How to Respond to Compromised IAM Credentials

The incident response process for compromised IAM credentials follows a structured approach. This is heavily tested on the exam:

Step 1: Identify the Scope
• Determine which credentials are compromised (IAM user access keys, console password, role temporary credentials)
• Use CloudTrail to identify all actions performed by the compromised credentials
• Determine the timeframe of compromise
• Identify any resources created, modified, or accessed by the attacker

Step 2: Contain the Incident — For Compromised IAM User Credentials

The recommended containment steps for a compromised IAM user are:

1. Deactivate the exposed access keys — Do NOT delete them yet, as you need them for forensic investigation to trace attacker activity in CloudTrail
2. Attach an explicit deny IAM policy to the user — This is important because deactivating keys only affects future API calls with those keys; if the attacker created additional keys or assumed roles, an explicit deny policy blocks all access
3. Revoke any active session tokens — If the user had temporary credentials from STS, add a condition to the deny policy using aws:TokenIssueTime to invalidate sessions issued before a certain time
4. Rotate or delete access keys — Create new access keys for the legitimate user if needed, then delete the compromised keys
5. Change the console password and enable or reset MFA
6. Review and potentially revoke permissions on any IAM policies attached to the user

Step 2 (Alternative): Contain the Incident — For Compromised EC2 Instance Role Credentials

For compromised instance role (temporary) credentials:

1. Revoke the role's temporary credentials by setting a revoke session policy on the IAM role (using the "Revoke active sessions" feature in the console, which adds an inline policy with an aws:TokenIssueTime condition)
2. Alternatively, detach the instance profile from the EC2 instance to prevent new temporary credentials from being issued
3. Isolate the EC2 instance by changing its security group to a restrictive forensic security group that denies all inbound and outbound traffic (except what's needed for investigation)
4. Enable termination protection on the instance to preserve evidence
5. Take an EBS snapshot for forensic analysis
6. Consider the IMDS configuration — enforce IMDSv2 (which requires session tokens and mitigates SSRF attacks) to prevent future exploitation

Step 3: Eradicate
• Remove any backdoors the attacker may have created (new IAM users, access keys, roles, policies, or Lambda functions)
• Remove any unauthorized resources (EC2 instances, S3 buckets, etc.)
• Review all IAM entities for unauthorized changes
• Check for modified trust policies on IAM roles
• Look for unauthorized cross-account access

Step 4: Recover
• Restore any modified resources to their known good state
• Re-enable services with proper security controls
• Verify that the legitimate user can access what they need with new credentials

Step 5: Post-Incident Analysis (Lessons Learned)
• Document the incident timeline and root cause
• Implement preventive measures (key rotation policies, enforced MFA, SCPs, etc.)
• Improve detection capabilities

Preventive Best Practices

• Use IAM roles instead of long-term access keys wherever possible
• Enable MFA for all IAM users, especially those with console access
• Enforce IMDSv2 on EC2 instances to prevent SSRF-based credential theft
• Rotate access keys regularly and use IAM credential reports to track rotation
• Use AWS Organizations SCPs to restrict sensitive actions at the organizational level
• Enable GuardDuty across all accounts and regions
• Use VPC Endpoints with endpoint policies to limit credential usage to within your VPC
• Implement least privilege — use IAM Access Analyzer to right-size permissions
• Use AWS Secrets Manager for automatic rotation of credentials
• Enable S3 Block Public Access and use git-secrets or similar tools to prevent accidental key commits
• Use condition keys like aws:SourceIp, aws:SourceVpc, and aws:SourceVpce in IAM policies to restrict where credentials can be used from

Key AWS Services and Features to Remember

• GuardDuty: Primary threat detection — knows about credential exfiltration patterns
• CloudTrail: Audit trail — required for forensic investigation of what the attacker did
• EventBridge: Automation trigger — can invoke Lambda functions automatically in response to GuardDuty findings or specific CloudTrail events
• AWS Lambda: Automate incident response (e.g., automatically disable access keys, isolate instances)
• AWS Step Functions: Orchestrate complex incident response workflows
• IAM: Deactivate keys, apply deny policies, revoke sessions
• AWS Config: Detect configuration drift and non-compliant IAM settings
• Security Hub: Centralized findings and compliance checks
• Detective: Deep investigation and visualization of security findings

Common Automated Incident Response Architecture

A frequently tested pattern involves automating the response to compromised credentials:

1. GuardDuty detects a credential compromise finding
2. EventBridge rule matches the GuardDuty finding type
3. EventBridge triggers a Lambda function
4. Lambda function automatically: deactivates the access key, applies a deny-all policy to the IAM user, sends a notification via SNS, and creates a forensic snapshot if an EC2 instance is involved

This is a high-priority architecture pattern for the exam.

---

Exam Tips: Answering Questions on Compromised IAM Credentials

Tip 1: Know the difference between IAM user credentials and role temporary credentials. The response procedures differ significantly. For IAM users, you deactivate/delete access keys and change passwords. For roles, you revoke active sessions (using the aws:TokenIssueTime condition) and potentially detach the instance profile. Exam questions will test whether you understand this distinction.

Tip 2: Deactivate first, delete later. When access keys are compromised, the correct first step is to deactivate them, not delete them. Deleting the keys removes the ability to trace attacker actions in CloudTrail that were performed using those specific keys. This is a common exam distractor.

Tip 3: GuardDuty is almost always the answer for detection. If a question asks about how to detect compromised credentials or credential exfiltration, the answer is almost always Amazon GuardDuty. Specifically remember the InstanceCredentialExfiltration finding types.

Tip 4: Remember IMDSv2 for prevention of SSRF-based credential theft. If a question describes an EC2 instance whose role credentials were stolen via a web application vulnerability (SSRF), the preventive control is to enforce IMDSv2, which requires a PUT request with a hop limit, making SSRF attacks significantly harder.

Tip 5: Understand explicit deny policies. An explicit deny in IAM always overrides any allow. When containing a compromised identity, attaching an explicit deny policy is more reliable than simply removing allow policies, because the attacker may have attached additional policies or assumed other roles.

Tip 6: Recognize the automated response pattern. Many exam questions describe a scenario requiring automatic remediation. The standard pattern is: GuardDuty → EventBridge → Lambda → remediation action. Know this flow cold.

Tip 7: VPC Endpoints with restrictive policies prevent credential exfiltration. If a question asks how to prevent stolen EC2 role credentials from being used outside your VPC, the answer often involves VPC endpoints combined with IAM policy conditions like aws:SourceVpce or aws:SourceVpc.

Tip 8: Don't confuse containment with prevention. Questions may ask about the first thing to do or the most important step. During an active incident, containment (disabling credentials, applying deny policies) takes priority over prevention (enabling MFA, enforcing key rotation). Read the question carefully to determine if it's asking about incident response or preventive controls.

Tip 9: Revoking temporary credentials requires the aws:TokenIssueTime condition. Simply changing the role's trust policy or permissions policy does not immediately invalidate existing temporary credentials, which are valid for their remaining TTL. You must use a session revocation policy with the aws:TokenIssueTime condition key to deny sessions issued before a certain time.

Tip 10: Watch for multi-service integration questions. The exam often asks about combining services: CloudTrail for investigation, GuardDuty for detection, EventBridge for automation, Lambda for remediation, SNS for notification, and Security Hub for centralized visibility. Understand how these services work together in a compromised credential scenario.

Tip 11: Credential reports and access advisor data are for proactive security. If a question asks how to identify unused or stale credentials that could be targets for compromise, IAM credential reports (for users) and access advisor data (for last-accessed services) are the correct answers.

Tip 12: Know the scope of STS tokens. Temporary credentials from AssumeRole have a default and maximum duration. If a question asks about limiting the blast radius of compromised temporary credentials, reducing the session duration and using session policies are valid approaches.