Uncovering the hidden identities within AWS access keys

The cloud has become an integral part of our everyday lives, offering unparalleled convenience and scalability. However, this vast virtual space also presents challenges in protecting security and trust, making it essential to uncover identity in the cloud to preserve the integrity of our digital environments.

One critical aspect of this is managing and securing AWS access keys as many organizations, including Adobe, use temporary session credentials to provide a secure and efficient way to interact with AWS services in their diverse, multi-account environments. At first glance, these keys may all look ordinary and harmless but hidden within each key is its identity: the AWS Account ID it belongs to. Decoding the key is crucial; only then can you determine its origin and uncover whether it belongs to your own account, a trusted ally, or an unknown threat actor with malicious intent.

Whether it’s a needle in a haystack or an AWS access key ID in a sea of logs, the key to discovery lies in digging deeper and finding the truth beneath the surface. In this blog, I will share a tool we developed at Adobe Security to trace the source of any AWS access key ID, helping security teams, developers, and cloud architects answer one critical question: “Do we trust this key?”

The problem: Tracing AWS credentials

An AWS access key ID is a unique identifier associated with an AWS account, used to authenticate and authorize API requests. In AWS environments, access key IDs can unintentionally appear in a variety of places – embedded in application logs, buried in CI/CD pipelines, or exposed through environment variables. Initially, they all appear as random strings of indistinguishable characters like  AKIAEXAMPLE123456.

However, these keys carry weight. Some might belong to your development environment, others to production, and some might not belong to your environment at all. Once the credentials expire or become detached from their context, identifying who a key belongs to becomes incredibly challenging.

When leveraging temporary session credentials, it becomes challenging because, by definition, these credentials expire at some point. Once expired, AWS provides no direct method to determine which account the expired temporary credentials belong to.

This poses several problems:

• A script or service fails because its temporary credentials (e.g., issued via aws sts assume-role) have expired. Now you’re stuck trying to debug and figure out which role issued those credentials.
• You accidentally expose your AWS access key ID, such as committing them to GitHub or having it appear in application logs. You know that you need to quickly revoke and rotate the compromised key. You try to run aws sts to get the account details for the key, but there is a “Deny” on STS. Now you’re racing to track down the account your key belongs to before an adversary can get to it.
• After a security incident, an access key ID is discovered in logs or on a compromised system. In this situation, you want to revoke that key and investigate what that key could access to determine the scope of the breach. Being unable to trace the access key ID back to the account it belongs to creates another hurdle in a high-stake situation.

Commands like  aws sts get-caller-identity return unhelpful errors when dealing with temporary AWS credentials:

If you’ve ever encountered these scenarios, you likely know the pain point of staring at logs or environment variables with no way to verify whether a key is legitimate, static or temporary, internal or external. Juggling temporary sessions across dozens of environments with these issues creates confusion, risk, and wasted time. Moreover, without clarity, you could risk making the wrong decisions about which credentials are safe to keep or revoke.

Our approach: Decoding AWS access key IDs

When you’re juggling multiple sessions, shared environments, or logs full of orphaned access keys, there’s no easy way to determine which AWS account the key belongs to. To address this problem, we developed a tool which efficiently traces the source of credentials, even after they have expired, decoding any AWS access key ID and revealing:

• The account ID it belongs to
• The resource type (e.g., user, role, EC2 instance profile) based on its IAM prefix
• Whether the key is static or a session credential
• Most importantly, if the key belongs to your organization.

Here’s how it works:

1. Decoding:  The process begins by stripping the prefix (e.g., AKIA, ASIA) from the access key ID. It then performs Base32 decoding and extracts the relevant bytes to isolate the AWS Account ID.
2. Identification:  It then matches the prefix to its corresponding resource type. Some common prefixes include:

• ABIA – AWS STS Service Bearer Token: A temporary badge issued by a security desk.
• ACCA – Context-Specific Credential: A special pass tailored for a specific purpose.
• AGPA – User Group: The collective access card—permissions shared across a group.
• AIDA – IAM User: The librarian responsible for managing AWS resources.
• AIPA – EC2 Instance Profile: A resource card that allows an EC2 instance to fetch credentials.
• AKIA – Access Key (long-term): The quintessential key to AWS resources—doesn’t expire.
• ANPA – Managed Policy: The rulebook maintained by administrators.
• ANVA – Policy Version: A specific edition of that policy—for auditing and tracking.
• APKA – Public Key: The lock on a secure resource; opened with the matching private key.
• AROA – Role: A temporary title granting permissions for specific tasks.
• ASCA – Certificate: A seal of authenticity for a high-value resource.
• ASIA – Temporary Access Key: A short-lived visitor pass—secure, time-bound access badge.

3. Output:  Finally, the tool returns the AWS Account ID as a 12-digit string, along with the resource type, providing actionable context.

Here is an example of a Python snippet:

Business impact and outcome

The AWS access key ID Decoder tool addresses a critical need for security, governance, and developer teams operating in multi-account AWS environments. At Adobe, this tool can be leveraged by engineers beyond Adobe Security in managing their credentials and expediting debugging processes.

Here are some of the ways the tool can be utilized today:

Incident response and forensics

• Quickly identify unknown access key IDs found in logs or during investigations
• Determine the environment (e.g., dev, staging, prod) from which the key originated
• Accelerate triage during security events

Credential hygiene & governance

• Identify and eliminate old or unused static credentials
• Audit credentials for compliance and verify its association with known accounts
• Detect credentials that were accidentally hardcoded or leaked

Developer and CI/CD support

• Prevent the use of production credentials in test environments
• Debug expired sessions and identify the source of credentials
• Confirm IAM session behavior across different environments

Multi-account visibility

• In AWS Organizations with hundreds or thousands of accounts, this tool maps keys to accounts for better inventory and visibility
• Integrates with auditing scripts or credential rotation tools
• When an AWS IAM role is deleted, any reference to that role identity will default to displaying the temporary a(AKIA/ASIA) associated with the last assumed role session, and you can determine the AWS Account ID by decoding the referenced access key.

Conclusion

Whether it’s a needle in a haystack or an access key ID in a sea of logs, identity matters. By decoding access key IDs and sharing this tool across Adobe, we can empower teams to act with more clarity and confidence to enhance their workflows. Ultimately, at Adobe, the AWS access key ID decoder helps bridge a critical gap in credential management by helping transform the unknowns into knowns, risks into insights, and confusion into real action.

If you are interested in learning about how the AWS access key ID decoder tool works in your own environment, you may consider installing it from PyPI or visiting the Documentation & Web UI to walk through examples to start uncovering the hidden identities inside your access keys.