What happens when your AWS keys leak and how AWS minimises account damage

4 min readApr 9, 2023

This blog covers the detailed process when AWS keys are leaked on GitHub and remedies to prevent them from leaking.

For this blog, I have created a free trial AWS account and created a random user called DevOps-test.

Creation of User and attaching limited policy:
I created a IAM user in my AWS account named DevOps-test and generated an access key and secret access key for this user and attached a very limited policy to this user.

{
 "Version": "2023–04–09",
 "Statement": [
 {
 "Sid": "ListBucket",
 "Effect": "Allow",
 "Action": "s3:ListBucket",
 "Resource": "arn:aws:s3:::aws-leaked-credentials"
 }
 ]
}

Commiting access keys to GitHub:
Create a repository on GitHub and push your access keys onto that GitHub repository.
Things happens as soon as access keys exposed to GitHub:
12:33 — Pushed the credentials to GitHub
12:34 — The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user DevOps-test by AWS
12:34 — Various List and Describe calls are made using the leaked credentials
12:35 — Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account ********’
As you can see 2 minute after leaking the credentials AWS added the AWSCompromisedKeyQuarantineV2 policy. Because AWS IAM is eventually consistent the malicious actor was able to perform various API calls even after the AWSCompromisedKeyQuarantineV2 policy has been added. Luckily this was short-lived because IAM has little delay for changes to take effect. 2 minutes after leaking the credentials I received an email from AWS informing me of the event and providing instructions on how to secure the account.
Action taken by AWS:
The AWSCompromisedKeyQuarantineV2 is attached to the IAM user DevOps-test. This policy denies the most important actions. But if the leaked credentials have a lot of permissions the malicious actor could still do damage to systems running in the AWS account.
Example: If the user has root privileges, then a hacker or malicious actor can damage the account to the ultimate level.

{
  "Version": "2023-04-09",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:LookupEvents",
        "ec2:RequestSpotInstances",
        "ec2:RunInstances",
        "ec2:StartInstances",
        "iam:AddUserToGroup",
        "iam:AttachGroupPolicy",
        "iam:AttachRolePolicy",
        "iam:AttachUserPolicy",
        "iam:ChangePassword",
        "iam:CreateAccessKey",
        "iam:CreateInstanceProfile",
        "iam:CreateLoginProfile",
        "iam:CreatePolicyVersion",
        "iam:CreateRole",
        "iam:CreateUser",
        "iam:DetachUserPolicy",
        "iam:PassRole",
        "iam:PutGroupPolicy",
        "iam:PutRolePolicy",
        "iam:PutUserPermissionsBoundary",
        "iam:PutUserPolicy",
        "iam:SetDefaultPolicyVersion",
        "iam:UpdateAccessKey",
        "iam:UpdateAccountPasswordPolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateLoginProfile",
        "iam:UpdateUser",
        "lambda:AddLayerVersionPermission",
        "lambda:AddPermission",
        "lambda:CreateFunction",
        "lambda:GetPolicy",
        "lambda:ListTags",
        "lambda:PutProvisionedConcurrencyConfig",
        "lambda:TagResource",
        "lambda:UntagResource",
        "lambda:UpdateFunctionCode",
        "lightsail:Create*",
        "lightsail:Delete*",
        "lightsail:DownloadDefaultKeyPair",
        "lightsail:GetInstanceAccessDetails",
        "lightsail:Start*",
        "lightsail:Update*",
        "organizations:CreateAccount",
        "organizations:CreateOrganization",
        "organizations:InviteAccountToOrganization",
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration",
        "s3:PutBucketAcl",
        "s3:PutBucketOwnershipControls",
        "s3:DeleteBucketPolicy",
        "s3:ObjectOwnerOverrideToBucketOwner",
        "s3:PutAccountPublicAccessBlock",
        "s3:PutBucketPolicy",
        "s3:ListAllMyBuckets",
        "ec2:PurchaseReservedInstancesOffering",
        "ec2:AcceptReservedInstancesExchangeQuote",
        "ec2:CreateReservedInstancesListing",
        "savingsplans:CreateSavingsPlan"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Email received from AWS after leaking access keys:

Within two minutes of leaking the credentials I received an email from AWS informing me that the credentials have been leaked.

Hello,
We have become aware that the AWS Access Key ************* , belonging to IAM User DevOps-test , along with the corresponding Secret Key is publicly available online at https://github.com/********/credentials.txt.
Your security is important to us and this exposure of your account’s IAM credentials poses a security risk to your AWS account, could lead to excessive charges from unauthorized activity, and violates the AWS Customer Agreement or other agreement with us governing your use of our Services.
To protect your account from excessive charges and unauthorized activity, we have applied the “AWSCompromisedKeyQuarantineV2” AWS Managed Policy (“Quarantine Policy”) to the IAM User listed above. The Quarantine Policy applied to the User protects your account by denying access to high risk actions like iam:CreateAccessKey and ec2:RunInstances. You can view all the actions denied by the policy by going here: https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCompromisedKeyQuarantineV2$jsonEditor?section=permissions.
What to do after leaking access keys?
1. Rotate and delete the exposed AWS Access Keys.
2. Check your CloudTrail log for unsanctioned activity.
3. Review your AWS account for any unauthorized AWS usage.
4. You must respond to the existing Support Case or create a new one to confirm completion of the steps above in order to restore access to your account, prevent suspension, and apply for a billing adjustment, if applicable.
How does AWS achieve this ?
How does AWS respond this fast when credentials are leaked is something I am not 100% sure about, because I do not have confirmation from AWS itself.
How they could achieve this is by using GitHub ‘Secrets Scanning’ service and using the ‘Secret scanning alerts for partners’. GitHub will then report leaked secrets to these partners, when receiving this report AWS has some automated system that adds the AWSCompromisedKeyQuarantineV2 policy, sends the email and opens a support ticket.

Conclusion:
AWS and the malicious actors act impressively fast on the leaked credentials both taking action immediately. AWS informs the root user and adds a Deny policy to the IAM user. The malicious actor starts to scan the account for resources they can exploit.
It is very nice that AWS protects its users in this way, but we could better prevent the leaking of the credentials. There are various ways of preventing leaking the credentials.

You could run a pre commit locally scanning for secrets before pushing to GitHub
Add a secret scanner in your CI/CD pipeline
The GitHub Secrets Scanning for users Configuring secret scanning for your repositories

What happens when your AWS keys leak and how AWS minimises account damage

Written by Vijay Gawte