He Made $64K Searching GitHub With A GENIUS Trick
(using open source only)

This, is the story of how one individual, "Mr. B," leveraged a deep understanding of Git's less-explored features to uncover secrets in public repositories, earning over $64,000 💰.

His "genius trick" wasn't about finding new tools, but about using existing Git functionalities in ways most developers and even many security professionals overlook.

The real goldmine often lies beneath the surface

We're used to interacting with Git through commands on our current working directory and recent history.

However, Git is designed to never lose data easily.

Mr. B's approach highlights that secrets committed, even to branches that are later deleted, or files removed from history via commands like git commit --amend or git rebase, don't just vanish.

The files that are harder to find, can persist as "dangling" or "unreachable" objects within Git's internal object database (.git/objects) for a period before potential garbage collection (usually 14 days).

These are invisible to standard git log or file browsing but are recoverable if you know where and how to look.

To put these learnings into action, especially in today's environment where AI can empower even junior attackers, requires a shift in mindset.

The big problem is the persistent risk of sensitive data: API keys, cloud credentials, private tokens being committed to Git repositories.

Once committed, even if "deleted" from the main branch or recent history, these secrets can become ticking time bombs.

What most people do

Most people, and many automated tools, try to solve this by scanning the current version of the code or perhaps the visible commit history.

They might assume that if a secret isn't in the latest commit or if a branch containing it was deleted, the risk is mitigated.

This approach often doesn't work because Git's architecture is (WAY) more complex.

Git stores all file versions and directory structures as objects.

When history is rewritten or branches are deleted, the old objects aren't immediately purged!

They become "loose" or "dangling" objects.

Eventually, Git might "pack" these objects into compressed packfiles, still within the .git directory, before they are eventually garbage collected, but this process isn't instantaneous.

Standard scanning methods miss these orphaned artifacts.

A new approach

Mr. B's successful strategy, was to dig into Git's internals.

This involves:

Exploring the Object Database: Using Git plumbing commands like

​Unpacking Archives:

Full History Traversal: Systematically going through every commit in the repository's history using

and examining the diff for each commit against its parent.

This can uncover files that were added and then quickly removed, a common pattern for accidental secret exposure.

• All scripts and commands are available in the author's blog post: https://medium.com/@sharon.brizinov/how-i-made-64k-from-deleted-files-a-bug-bounty-story-c5bd3a6f5f9b

Targeted Scanning:

Once these potentially sensitive historical artifacts and dangling objects are recovered (even if they are just raw blobs without filenames), use a robust open-source scanner like TruffleHog, configured to scan the raw file content for various secret patterns. Mr. B turned it on with switches to run on the file system with all detectors:

This methodical deep dive into the repository's underlying metadata, rather than just its surface, is what allowed Mr. B to find secrets that thousands of others, using conventional methods, missed.

It’s a reminder that understanding the fundamental workings of our tools is paramount for robust security.

Our hero also mentioned he:

1. Only "attacked" organizations with official bug bounty programs that allow it
2. How he built a home lab and a bunch of cloud servers to run his scans
3. A "vibe coded" cool UI to look into the files found
4. A list of bounties amounting to $64K USD!

Personally, I applied the same process, scripting it, and looking for my own target.

So I cloned and scanned and cloned and scanned, until one repo POPPED.

I found a few admin keys in a Kubernetes open source used by thousands of people and I was excited!

My advice to you: learn the methods, at least be familiar with Git's strange metadata (and actual content) processes, and build a similar process embedded into the release process to avoid future storms!

​The full blog post is here.

​
Thank you for reading.
Feel free to reply directly with any question or feedback.
Have a great weekend!