tl;dr  TruffleHog Analyze assesses the risk of a leaked credential by enumerating the resources and permissions granted to it. Run trufflehog analyze to get started.

For the last 8 months, our engineering team has been working on a top-secret project: TruffleHog Analyze. 

This is the first tool that discovers the permissions and accessible resources associated with an API key, without requiring access to the provider’s UI.

How? It interrogates itself through a series of API calls.

In the weeks since our official launch on BlackHat’s Arsenal stage, the TruffleHog community has provided loads of positive feedback and surfaced several useful applications for this new type of credential analysis.

In this blog post, we share some of our user’s stories as well as how you can use TruffleHog Analyze to answer the following questions about leaked credentials:

• Who’s API key is this?

• What resources can this API key access?

• What permissions does this API key have?

TruffleHog Analyze: Practical Examples

A Security Engineer Uncovers an Ex-Employee’s Key Permissions.

One of the TruffleHog community’s security teams had to deal with a leaked Slack token, but the developer who leaked the token left a while ago. No one knew who’s token it was, what permissions it had, or what Slack workspaces it could access.

After running TruffleHog Analyze, their team immediately knew which employee to ask to revoke the key, as well as which Slack Application logs to review for signs of compromise. 

A Bug Bounty Hunter Demonstrates Impact of a Leaked Secret.

In July, I submitted a Bug Bounty (BB) report to HackerOne and received this response.

Someone previously reported the exact same leaked tokens that I found hidden in a public GitHub repository, but it was “closed due to the lack of demonstrated impact…after confirmation from the internal team."

Reading between the lines, the security analyst received a report about leaked credentials, pinged the developer who leaked the key and asked about risk to the organization. The developer replied that there was no risk and the security analyst (understandably) closed out the report. What else could the analyst do?

I was confident the exposed key provided some risk to the organization, so (with permission) I ran TruffleHog Analyze against the exposed token and discovered that it provided access to the organization's internal Slack Workspace. 

The triager immediately revoked the key and assigned the report a Medium severity level, despite the developer’s insistence that the credential was worthless.

A Security Analyst Prioritizes Vulnerability Reports.

One of the most common questions our Enterprise clients and open-source users ask is: how do I prioritize which keys to rotate?

If you’re looking at 15 vulnerability reports for different types of exposed Cloud and SaaS credentials, how do you prioritize which one to rotate first?

Do you start with cloud keys? What if the exposed AWS key can only access a test S3 bucket? What about starting with GitHub credentials? Sure, if they have access to corporate repositories. How do you even identify all of the different access levels and permissions? It’s not a straightforward process.

Consider an exposed database connection string: can you easily tell what (and how much) data could be accessed? What about data that can be altered? Or deleted? Assessing the risk associated with a leaked database connection string requires identifying the:

• Database Server Owner

• Accessible Databases, Tables, Rows, etc. 

• User Permissions (both server-wide and on specific database and tables)

In the video below, we demonstrate how TruffleHog Analyze can answer all three of those questions for a hardcoded Postgres connection string.

With this knowledge, internal security teams can layer on threat model data to quickly assign a risk level to the key.

An IT Admin Discovers the Permissions of an API Key.

Part of our goal with TruffleHog Analyze is to make our open-source secret scanning and analysis toolset accessible to different types of users, users like Doug.

Doug is our IT administrator. He’s awesome. He makes sure all of our systems and devices are running at full speed. About a year ago, a key for one of our internal systems expired. Even though he could see the API key and could access the system that created it, he didn’t know which employee account created the key, nor the exact permissions scoped to the key. 

After lots of trial-and-error and tracking down a former employee, he finally figured it out. But that’s less than ideal.

One of the coolest things about TruffleHog Analyze is you can analyze the permissions of an API key without needing to log into that account. 

Sure, if it’s your own API key, you could log in and see which permissions are scoped to the account. But some users only have access to an API key and not the username/password/MFA required to access details about that API key.

For users that can’t login to the provider’s GUI, TruffleHog Analyze provides important permission information that would otherwise take hours of digging through API documentation to uncover.

–

If you’ve tested TruffleHog Analyze and have feedback (or another use case), we’d love to hear it and will consider updating this post with your thoughts.