Incident Response Playbook IAM credential exposure

https://cybr.com Christophe Limpalair

Cybr

High-level goals:

Identify -

Vulnerabilities exploited

Exploits & tools observed

Actor’s intent

Actor’s attribution

Damage inflicted to the environment & business

Recovery point - Returned to original configuration + hardened

Common IAM Roles used:

SecurityAnalystRole

For Athena queries
To perform analysis tasks

SecurityDeployRole

For resource deployment using CloudFormation/AWS CDK app/etc...

SecurityBreakGlassRole

To contain and eradicate without requiring root

Response Steps:

[ANALYSIS] Validation - Validate alert by checking ownership of exposed credential

1 aws sts get-access-key-info \
2     --access-key-id AKIAIOSFODNN7EXAMPLE \
3     --profile SecurityAnalystRole \
4     --region us-east-1
5 {
6     "Account": "777777777777"
7 }

Is it your account? If not, contact the AWS Trust and Safety Team

[ANALYSIS] Scope - Gather info about what’s happened, inventory resources involved, determine it’s not a false-positive

Using the SecurityAnalystRole, retrieve activity for past x days related to the affected IAM Access Key ID

Depending
on context

Depending on results, dig deeper ie: if S3 permissions were modified, retrieve and inventory them

[ANALYSIS] Impact - What’s the business impact?

Based on concrete data, determine the business disruption
Answer questions like:
1. What related alerts were triggered?
2. What is the classification of the data accessed?
3. What AWS services are not in the approved use list?
4. What AWS service configs were changed?
5. What guardrails were disabled or modified?
6. Was the actor an insider or outsider?
7. What evidence supports benign and malicious activity?
8. What’s the impact to business apps and processes?
9. Is there an indication of data exfiltration?

[Containment]

Containment steps depend on multiple factors, including:

Potential damage to and theft of resources
Need for evidence preservation
Service availability (network connectivity, services provided to external parties)
Time and resources needed to implement the strategy
Effectiveness of the strategy (partial or full containment)
Duration of the solution (emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution, etc...)

Categories of containment in AWS:

Source containment - Prevent access from a certain source w/ filtering & routing
Destination containment - Prevent access to a target resource w/ filtering & routing
Technique and access containment - Prevent unauthorized access

Examples:

1Disable IAM access keys:

1 aws iam update-access-key \
2     --access-key-id AKIAIOSFODNN7EXAMPLE \
3     --status Inactive \
4     --user-name RelatedUsername \
5     --profile SecurityBreakGlassRole

2Verify:

1 aws iam list-access-keys --user-name RelatedUsername
2 {
3     "AccessKeyMetadata": [
4         {
5             "UserName": "RelatedUsername",
6             "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
7             "Status": "Inactive",
8             "CreateDate": "2021-07-24T02:31:19+00:00"
9         }
10     ]
11 }

3Lock down access of affected IAM Users:

1 {
2     "Version": "2012-10-17",
3     "Statement": [
4         {
5             "Sid": "IamPolicyForContainment",
6             "Action": "*",
7             "Effect": "Deny",
8             "Resource": "*"
9         }
10     ]
11 }

4...

Whatever other containment steps are needed here depending on the incident

[Eradication]

Delete affected IAM Users, resources, etc... depending on what was affected.
Some resources may require backups first. Apply security updates and hardening

[Recovery]

If needed / as needed (re-create destroyed resources, restore data, etc...)

[Post-Incident Activity]

Recommendations:

Automate containment and eradication steps with AWS CLI or SDK
Save queries used for faster future use (Athena queries, for example)
Eliminate as many long-term credentials as possible and adopt short-term credentials
Enable alerts based on the creation of long-term access keys/credentials

More on that here: https://cybr.com/cloud-security/ditching-aws-access-keys/

Preparation

Detection &
Analysis

Containment
Eradication &
Recovery

Post-
Incident
Activity

Use this cheat sheet with AI

Copy a ready-to-use prompt into your preferred AI assistant.

Goal

Preview prompt

Prompt

Use this Cybr cheat sheet as reference: Incident Response Playbook — IAM credential exposure
Source: https://cybr.com/cheat-sheets/iam-credential-exposure/

My goal: Walk me through the playbook

Help me work through this IAM credential exposure playbook. Ask what is known about the exposed credential, affected account, timeline, and current impact. Organize evidence and next actions across analysis, containment, eradication, recovery, and follow-up. Explain the purpose, dependencies, and verification for each action, preserving the distinction between confirmed facts and hypotheses.

Use the included reference material even if you cannot open the source URL. Ask for missing context rather than inventing my environment. Explain assumptions. For version-sensitive service behavior or commands, consult current official documentation when available, cite it, and explain any differences from this reference. If you cannot verify something, say so.

Reference material from the cheat sheet (structured text or a curated summary):

The IAM credential exposure playbook follows analysis, containment, eradication, recovery, and post-incident activity. Validate credential ownership, scope activity by the affected access key, inventory changes, and assess business impact. Separate analyst, deployment, and break-glass roles. Containment options include source, destination, and access controls; disabling an IAM access key is one example. Preserve evidence and consider service dependencies when choosing containment. Remove persistence, restore and harden configuration, and validate recovery. Save useful queries, reduce long-term credentials, and monitor their creation. Example ownership lookup: aws sts get-access-key-info --access-key-id EXAMPLE_ACCESS_KEY_ID. This identifies the owning account, not whether the key was misused.

More cheat sheets