Audit the Blast Radius of KMS Keys with Finders Keypers-Walkthrough

Lab Walkthrough

Once we start the lab, we are provided with credentials to log in both via the AWS Console and the AWS CLI:

AWS Console

AWS CLI

Overview

The lab introduces us to an excellent tool for auditing our KMS keys, which is extremely important. Let me give you an example: when working in enterprise or production environments, AWS KMS keys are commonly used. However, auditing or identifying them can become challenging if there isn’t an internal inventory or control in place to track where these keys are being used.

In several audits, I’ve encountered this situation — I see multiple KMS keys, but development teams or sysadmins often don’t know in how many services those keys are being used. Identifying them can be complex, but it’s critical. During audits, policy implementations, or security incidents, we must be able to identify and track our KMS keys.

Here are the links:

[embed]GitHub - FogSecurity/finders-keypers: Finders Keypers: AWS KMS Encryption Key Usage and Blast… Finders Keypers: AWS KMS Encryption Key Usage and Blast Radius Finder - FogSecurity/finders-keypersgithub.com

[embed]Fog Security Edit descriptionwww.fogsecurity.io

The lab outlines the following key points that you need to keep in mind in order to complete it successfully:

Learning Objectives

• Learn how to audit KMS key usage across AWS services
• Understand encryption dependencies in AWS resources
• Document resources for compliance and security purposes
• Gain experience with the Finders Keypers tool

Prerequisites

• Basic understanding of AWS services and encryption concepts
• Familiarity with AWS CLI and overall terminal or command line

Lab Architecture

This lab contains:

• A Customer Managed KMS key
• Multiple AWS resources encrypted with this key:
• S3 bucket
• Secrets Manager secret
• DynamoDB table
• IAM user with appropriate permissions for CLI commands

Lab Tasks

1. Install and configure the Finders Keypers tool
2. Use the tool to discover resources encrypted with the KMS key
3. Analyze and document the findings

Step 1:

The lab explains that the steps can be done either locally or using CloudShell. However, as mentioned, both approaches are very similar, and I believe we can easily follow the process locally and install the tool for future audits:

1. We will install the tool locally.
2. We will install the necessary requirements for the tool.

git clone https://github.com/FogSecurity/finders-keypers.git

cd finders-keypers

If you don’t encounter any errors when running the tool for the first time, you can skip the installation of requirements.txt for now — assuming you're running it locally like I am.

Some of the commands you’ll see me use may differ slightly from those in the original lab, as I’m using an Arch Linux system. If you’re using Kali or Ubuntu, the commands provided in the lab should work as-is, though there might be minor differences.

It is recommended to use a Python virtual environment to keep the installation clean and avoid errors when installing packages — or to prevent breaking existing ones — using the following command:

#Arch linux
python3 -m venv venv && source venv/bin/activate
or
#Non-Arch Linux distros
mkvenv

install -r requirements.txt

In my case, I installed the packages while having a virtual environment activated to avoid any errors:

Step 2:

Now we need to configure our credentials using the AWS CLI in order to get started:

aws configure --profile finders-keypers

In my case, I set an environment variable (which I delete at the end of the lab) to simplify the commands and variable references later on:

export AWS_PROFILE=finders-keypers

Do NOT forget to unset this environment variable after you’re done with the lab or your AWS CLI commands will go through the wrong account! (unset AWS_PROFILE)

To run the tool, we need to know the ARN in order to execute it. For that, we have the necessary permissions to describe the KMS keys using the following command:

aws kms describe-key --key-id alias/kms-key-audit-lab --profile finders-keypers --query "KeyMetadata.Arn" --output text

Most likely, your ARN will be different from mine since this is a lab environment that gets generated dynamically. So you just need to replace your own ARN in the following command:

python finders_keypers.py --keyarn YOUR_KMS_KEY_ARN_HERE

#In my case:
python finders_keypers.py --keyarn arn:aws:kms:us-east-1:666332090997:key/9f7a086c-c2d7-4fa5-910d-74b023c85245

Once we run the command, we review the output and analyze how many resources are associated with the keys:

The lab notes that it’s normal to see errors in the output:

Note: Errors with Glue/SQS/etc… are perfectly fine and just reflect limitations we’ve set on the lab account. You can ignore those.

Now we can run the tool in verbose mode to see more detailed information:

python finders_keypers.py --keyarn arn:aws:kms:us-east-1:666332090997:key/9f7a086c-c2d7-4fa5-910d-74b023c85245 --verbose

In the output, we can identify important information such as the following:

• Total count of resources linked to the key
• Categories of services involved (e.g., S3, DynamoDB, Secrets Manager, etc.)
• Encryption context details specific to each service

With these results, we’ve identified 3 resources encrypted with this KMS key:

• As we can see, we’ve identified an S3 bucket, a DynamoDB table encrypted at rest, and a Secrets Manager secret also encrypted at rest.

Step 4:

The tool also allows us to save the output for auditing purposes and analyze it later:

python finders_keypers.py --keyarn arn:aws:kms:us-east-1:666332090997:key/9f7a086c-c2d7-4fa5-910d-74b023c85245 --verbose > kms_key_inventory.txt

We can see how the output is saved in our kms_key_inventory.txt file:

Open the console just to understand the head ache for the Cloud Engineers

Now, as part of my personal analysis, I’d like to explain the common headache that cloud security engineers face when it comes to identifying resources using a given number of KMS keys:

For example, in the case of our bucket, we would have to go into each one individually and check the ARN of the KMS key associated with it — and maybe even write it down in a document or Excel sheet. In this lab it’s simple because it uses the same key we saw earlier, but imagine having 20 or 30 buckets, and within those, using 2 or 3 different keys each! It quickly becomes a complex and time-consuming task.

S3 bucket:

With the ARN and key name, we can see which key a resource belongs to. It might not seem difficult or tedious at first glance — but trust me, identifying an ARN quickly in the console isn’t easy, especially since you don’t get a clear list of all the resources associated with it.

So keep in mind: if you’re using different keys for different services, it can become quite complex. And even if you’re using the same key across multiple services, figuring out exactly how many services are tied to it can still be a challenge.

Customer Managed Key Lab

If you look at the configuration and details of a Customer Managed Key, you’ll notice that it doesn’t show which specific resources are associated with it. You’ll only see the key policy (if applicable), encryption type, assigned tags (if any), rotation status, and aliases. While both aliases and tags help identify keys, they are not the same: aliases are user-friendly names used to reference keys in operations, whereas tags are metadata used for organization, automation, or access control:

KMS-Customer managed keys:

Same case for our Secrets Manager secret — if we go into its configuration, we’ll see the following:

Secret manager:

And the same applies to DynamoDB — we’ll see exactly the same KMS-related details in its configuration:

DynamoDB:

Final considerations:

1. The tool is useful for identifying which resources would be affected if a key were to be disabled — helping us make informed decisions during audits or incident response.
2. It also assists when the goal is to disable a key, ensuring you understand the potential impact before taking action.

A final thought — and one you probably asked yourself at the end of the lab — is whether it’s better to use a single KMS key to avoid identification issues, or to use separate keys per service. That’s a great question, and the answer is: it depends.

✅ General recommendation based on best practices:

• Use multiple KMS keys to separate responsibilities, isolate sensitive resources (such as secrets, snapshots, databases), and apply more granular access policies. This enhances security and control.
• Avoid using a single key for everything, as it can make audits, impact analysis, and incident response more difficult — and increases risk if that key is ever compromised.
• Strike a balance in the number of keys: don’t overprovision unnecessarily, as each Customer Managed Key (especially with rotation enabled) may incur monthly charges (around $1 USD per active key).

In my experience, it’s common to use different keys for specific services like databases, snapshots, or secrets. This approach can be helpful for separating responsibilities and segmenting security. In the end, it’s better to encrypt your resources using a shared key than not encrypt them at all — but creating and managing too many keys can also lead to higher monthly costs, which may be a concern for some organizations.

Don’t forget to unset the environment variable before finishing the lab to avoid potential issues in future labs:

Thanks for making it this far! I’d love to hear from you in the comments — has something similar happened to you? Do you think it’s better to use a single key for everything or separate ones for each use case?

Let me know your thoughts, and come back soon! 😊