Compromised credentials

Exam tasks: 2.2.2 (search and correlate logs across services), 2.2.3 (validate findings to assess scope), 2.2.4 (contain, eradicate and recover), 2.2.5 (root cause)

The decision: which kind of credential leaked (long-term key, role session, instance credentials, federated user, root), what is the fastest control that invalidates that credential without breaking everything else, and what did the attacker create while they had it?

Pick the containment for the credential typeCopy Anchor Link

Where the alert comes fromCopy Anchor Link

• GuardDuty findings such as UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (instance credentials used from outside AWS), .InsideAWS (used from another AWS account), anomalous API behaviour findings, and attack sequence findings such as AttackSequence:IAM/CompromisedCredentials, which chain several signals into one critical finding.
• AWS Health event AWS_RISK_CREDENTIALS_EXPOSED when AWS finds your key in a public place, such as a public code repository. AWS also opens a support case and may attach the AWSCompromisedKeyQuarantineV3 managed policy to the user.
• Trusted Advisor has an Exposed Access Keys check that surfaces the same kind of event.
• An abuse report from AWS (see below).

Exposed IAM user access keysCopy Anchor Link

1. Deactivate the exposed key. Don't delete it yet: an inactive key can be re-enabled if you picked the wrong one, and its ID stays useful for searching logs.
2. Attach an inline deny-all policy to the user. Temporary credentials minted from that user are evaluated against the user's own policies, so this also shuts down GetSessionToken and GetFederationToken sessions the attacker created. The AWS managed policy AWSDenyAll does this.
3. Create a replacement key, update the application (better: move it to a role and delete keys entirely), then delete the old key.
4. Hunt for persistence (next section), and review the IAM credential report and last accessed data for the user.
5. Review charges and Regions you don't use. Attackers like launching expensive instances in forgotten Regions.

Stolen role and instance credentialsCopy Anchor Link

• Revoke active sessions in the IAM console attaches an inline policy named AWSRevokeOlderSessions to the role. It denies everything when aws:TokenIssueTime is earlier than the revoke time (plus about 30 seconds for propagation).
• Anyone who assumes the role afterwards is unaffected. If the attacker can still assume the role (for example because they hold a user key that is allowed to), fix that path too.
• You need iam:PutRolePolicy on the role to do it. Service-linked roles can't be revoked this way.
• For EC2 instance credentials used from outside the instance:
  • Revoke sessions on the instance role. Healthy instances pick up new credentials from IMDS on their next refresh.
  • Treat the instance as compromised: the credentials came from somewhere. Isolate it (see Compromised workloads).
  • Prevent a repeat with IMDSv2 required and policies that use aws:EC2InstanceSourceVPC and aws:EC2InstanceSourcePrivateIPv4 so instance credentials only work from where they were issued.

Identity Center and federated usersCopy Anchor Link

• Roles created from permission sets (AWSReservedSSO_...) can't be edited in IAM, so the IAM Revoke sessions button isn't available for them.
• Disable or delete the user in the identity source (the external IdP, or the Identity Center directory), remove their account assignments, and revoke active sessions in Identity Center. Existing role sessions end when their session duration expires, so keep permission set session durations short.
• For SAML or OIDC federation straight into IAM roles, disable the user at the IdP and revoke sessions on the roles.

Root credential compromiseCopy Anchor Link

• Standalone account: sign in with the root recovery flow, reset the password, replace the MFA device, delete any root access keys, confirm the account email and alternate contacts, then contact AWS Support.
• Member accounts in Organizations: turn on centralized root access. The management account or a delegated admin can then delete a member account's root credentials entirely and perform the few root-only tasks through short-lived privileged sessions (sts:AssumeRoot), such as unlocking an S3 bucket policy that denies everyone.
• SCPs apply to the root user of member accounts, so a deny-by-default SCP limits what a stolen member root credential can do. They never apply to the management account.

Tracing what the attacker didCopy Anchor Link

Search by the credential, then follow every credential it created.

• Filter on userIdentity.accessKeyId, then pivot on sourceIPAddress and userAgent to find other credentials used from the same place.
• When the key called AssumeRole, the responseElements hold the new session's access key ID. Search for that too, or you'll miss everything done in other accounts.
• Look for persistence: CreateUser, CreateAccessKey, CreateLoginProfile, UpdateAssumeRolePolicy, AttachRolePolicy, new SAML or OIDC providers, CreateFunction, RunInstances in unusual Regions, PutBucketPolicy, ScheduleKeyDeletion, and StopLogging or DeleteTrail.
• errorCode: AccessDenied bursts are the attacker enumerating permissions. They tell you what they tried as well as what they got.

More log-query technique lives in Log analysis.

AWS abuse reportsCopy Anchor Link

• AWS Trust and Safety emails the account's contacts when your resources are reported for spam, port scanning, DoS, intrusion attempts, malware distribution or hosting prohibited content.
• An abuse report is often the first sign of compromise: a leaked key used to launch scanning instances, or a vulnerable server turned into a spam relay.
• Reply to the report with what you found and did. If you don't respond, AWS may restrict or suspend the offending resources.
• To report abuse coming from AWS resources you don't own, use the AWS abuse reporting form.
• Keep the security alternate contact current on every account (you can set it centrally through Organizations) so these notices reach the security team.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Revoke IAM role temporary security credentials
• Disabling permissions for temporary security credentials
• Centralize root access for member accounts
• Remediating potentially compromised AWS credentials (GuardDuty)