Credential Cleanup Procedure

If a user's credentials have been acquired by an attacker, we recommend the following:

1. First, attach a policy that denies access to credential management actions. Once it takes effect it will block the user's ability to manage their credentials, such as access keys, login profiles, MFA devices, and service-specific credentials. Note: typically users that manage their own password do so via iam:ChangePassword and not iam:UpdateLoginProfile (see the credential self-management documentation) The additional LoginProfile actions are blocked here as a nod to thoroughness and any novel user-defined permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
 
                "iam:ChangePassword",
                "iam:CreateLoginProfile",
                "iam:UpdateLoginProfile",
                "iam:DeleteLoginProfile",
 
                "iam:CreateVirtualMFADevice",
                "iam:DeactivateMFADevice",
                "iam:DeleteVirtrualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice",
 
                "iam:CreateServiceSpecificCredential",
                "iam:DeleteServiceSpecificCredential",
                "iam:ResetServiceSpecificCredential",
                "iam:UpdateServiceSpecificCredential",
 
                "iam:DeleteSigningCertificate",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate",
 
                "iam:DeleteSSHPublicKey",
                "iam:GetSSHPublicKey",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey",
                
                "iam:PassRole",
                
                "sts:AssumeRole",
                "sts:GetFederationToken"
            ],
            "Resource": "*"
        }
    ]
}

2. Additionally, if the attacker has generated any sessions via sts:GetSessionToken, also attach this policy, mentioned below, to nullify any live sessions (Replace [now] with the current time):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "DateLessThan": {
                    "aws:TokenIssueTime": "[now]" 
                }
            }
        }
    ]
}

See revoking sessions

Once the policy takes effect, it will deactivate any sessions that are currently associated with the user.

1. Wait for the policies to be updated across all regions. Confirm that CloudTrail does not show any unexpected activity from the user in question.
2. Rotate any compromised or recently-created credentials.
3. Remove the policy denying IAM actions.
4. Remove the session nullification policy 36 hours after applying it. Be sure to wait the full period; if the policy is removed before that time, it's possible an old session under the control of the attacker will regain the ability to take action in the account.

If the user has permission to modify permissions, assume roles, or modify credentials of other users in the system, it's especially important to check for any recent changes to the account to find any other suspicious behavior.