KeyHacks: The Bug Bounty Hunter's Cookbook for Validating Leaked API Credentials

Hook

You just found an AWS access key in a public GitHub repo. You have 60 seconds before the security team rotates it. What do you run?

Context

In the bug bounty and penetration testing world, finding credentials is only half the battle. A leaked API key might be expired, sandboxed, or have read-only permissions—or it could provide full administrative access worth tens of thousands of dollars in bounty payouts. The difference between a $50 informational report and a $10,000 critical finding often comes down to one question: can you prove impact?

Before KeyHacks, security researchers maintained personal notes, searched Stack Overflow, or reverse-engineered SDKs to figure out how to validate discovered credentials. This created massive inefficiency: the same researcher might spend 30 minutes figuring out how to test a Slack token, only for another researcher across the world to do the identical research the next day. KeyHacks emerged as a community-driven solution to this knowledge fragmentation problem, providing battle-tested curl commands that instantly validate whether a leaked credential is active and what permissions it grants. Created by streaak and maintained through community contributions, it's become the de facto reference guide that's open in every bug bounty hunter's browser.

Technical Insight

KeyHacks is architecturally simple but strategically brilliant: it's a single README.md file organized by service provider, with each entry containing the exact API call needed to validate a credential. The power lies not in complex code but in curated knowledge that would take hours to research independently. Let's examine how this works in practice.

Consider the AWS access key scenario. A typical KeyHacks entry provides the precise AWS CLI command with minimal permissions required:

# Test if AWS credentials are valid
aws sts get-caller-identity --profile test

# Alternative using curl
curl -X POST https://sts.amazonaws.com/ \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "Action=GetCallerIdentity&Version=2011-06-15"

This simple command returns the account ID, user ARN, and user ID if the credentials are valid. The response tells you not just that the key works, but whose key it is—critical intelligence for impact assessment. The repository doesn't stop at validation; it often includes escalation paths. For AWS, it suggests following up with aws s3 ls to enumerate buckets or aws iam list-users to check for administrative access.

The Slack token validation demonstrates another pattern—testing for both validity and scope:

# Validate Slack token and check permissions
curl -X POST https://slack.com/api/auth.test \
  -H "Authorization: Bearer xoxp-your-token-here"

# Check what the token can access
curl -X GET https://slack.com/api/users.list \
  -H "Authorization: Bearer xoxp-your-token-here"

The first call confirms the token is valid and returns the workspace and user it belongs to. The second tests a common permission (listing users) that indicates broader access. This two-step pattern—validate then scope—appears throughout KeyHacks and reflects real-world security research methodology.

For database credentials like PostgreSQL, the entries provide connection strings rather than API calls:

# Test PostgreSQL connection
psql -h hostname -U username -d database_name

# Or using environment variable
export PGPASSWORD='leaked_password'
psql -h hostname -U username -d database_name -c "SELECT version();"

The beauty of KeyHacks lies in its heterogeneity. It doesn't force every credential type into a single testing framework. Instead, it provides the natural, idiomatic way to test each service—curl for REST APIs, CLI tools for cloud providers, connection strings for databases. This makes it immediately usable without translation layers or wrapper scripts.

The repository has also inspired automation. Security researcher Gwen001 created keyhacks.sh, which parses the KeyHacks README and converts it into an executable script. This bridges the gap between manual reference and automated tooling, though it requires maintenance as the upstream repository changes. The existence of such automation validates the structured knowledge approach—the README is consistent enough that it can be machine-parsed despite being written for human consumption.

One underappreciated aspect is how KeyHacks teaches API authentication patterns. By studying the entries, you learn that some services use Bearer tokens, others use API keys in headers, some require HMAC signatures, and others use basic authentication. For junior security researchers, it's an informal education in how modern APIs handle authentication, delivered through practical examples rather than abstract documentation.

Gotcha

KeyHacks has limitations that become apparent when you rely on it extensively. The most significant issue is drift: API providers change their authentication flows, deprecate endpoints, and modify permission models without warning. An entry that worked perfectly six months ago might now return 404 errors or require additional headers. The repository depends on community contributions to stay current, and with 80+ providers, comprehensive maintenance is nearly impossible. I've encountered several outdated entries for services that have migrated to OAuth 2.0 or changed their API versioning schemes.

The OpSec considerations are also completely absent. Running these validation commands generates logs on the target service, potentially alerting security teams to the compromised credential before you've finished your assessment. Some APIs have aggressive rate limiting that will block your IP after just a few requests. The repository doesn't warn you that testing certain credentials (like Stripe production keys) against live endpoints could trigger fraud alerts or compliance violations. For responsible disclosure, you need to understand the impact of your testing, which KeyHacks doesn't address.

Finally, the format itself is a constraint. As a markdown file, KeyHacks requires manual copying and pasting of commands. There's no standardized machine-readable format (like JSON or YAML) that would enable seamless integration into custom workflows or automated scanning pipelines. While this simplicity makes it accessible, it also means you're always one step removed from automation. If you're processing hundreds of leaked credentials, you'll need to build your own parsing and execution layer.

Verdict

Use KeyHacks if you're a bug bounty hunter or penetration tester who regularly discovers API credentials and needs to quickly triage their validity and impact. It's invaluable when you find a credential for a service you've never tested before and need immediate validation commands without digging through API documentation. The repository shines in time-sensitive scenarios where you need to prove impact before credentials are rotated. Skip KeyHacks if you need automated, production-grade secret scanning integrated into CI/CD pipelines—tools like TruffleHog or GitGuardian offer better automation and maintenance. Also skip it if you're focused on prevention rather than post-discovery validation; KeyHacks helps you understand what you've found, not prevent the leak in the first place. Finally, avoid treating it as gospel—always verify that the commands still work with current API versions, and understand the OpSec implications of your testing before executing commands against production services.