Topic starter
19/10/2026 5:39 pm
TL;DR: Truffle Security reports that AWS access key IDs can be base-32 decoded and bit-shifted to recover the corresponding account number, even for live or revoked keys. The practical issue is not that the account number is secret, but that key structure can widen discovery and enumeration risk across NHI workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Research Uncovers AWS Account Numbers Hidden in Access Keys”.
Key questions
Q: What should security teams do first when an AWS access key is found exposed online?
A: The first move is immediate containment, not analysis delay.
Q: Why do exposed AWS access key IDs create additional risk beyond the secret value itself?
A: An exposed AWS access key ID can reveal the associated account number, which helps attackers identify the target account faster and validate their next steps.
Q: How should security teams inventory cloud credentials across accounts?
A: Use a single inventory that tracks key state, ownership, account mapping, last use, and exposure history.
Practitioner guidance
- Audit where access key IDs are exposed Search source control, CI logs, tickets, chat archives, and support exports for AWS access key IDs and treat them as sensitive identity artefacts, not harmless identifiers.
- Separate quarantine from revocation Define a response path that revokes exposed keys immediately and does not rely on quarantine alone when a credential or its identifier appears outside approved systems.
- Tighten access key inventory controls Maintain an authoritative inventory of active, revoked, and observed keys so that security teams can correlate exposure events with the correct AWS account quickly.
Bottom line: AWS access key IDs can disclose account context, so credential exposure is also an identity metadata problem.
What's in the full article
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The reverse-engineering method used to decode AWS account numbers from access key IDs
- The TruffleHog update that returns account IDs for both live and revoked keys
- The research interview details on bit manipulation and verification against AWS endpoints
- The implementation context behind the small update to TruffleHog and what it changes for users
👉 Read Truffle Security's analysis of AWS account numbers hidden in access keys →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:39 pm
Account-number leakage turns an access key into a discovery artefact: The security issue is not limited to authentication. When the identifier itself can be reversed into account context, a leaked key becomes useful even before it is used for login. That shifts the control problem from pure secret protection to identity metadata exposure, and practitioners should treat exposed access key IDs as part of the NHI attack surface.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between quarantining and revoking an AWS key?
A: Quarantine is a temporary containment state that limits use or flags the credential for review, while revocation removes the credential’s ability to authenticate. For cloud credentials, only revocation ends the authentication path. Quarantine can buy time, but it is not a substitute for lifecycle closure.
👉 Read our full editorial: AWS access key IDs expose account numbers and widen NHI risk