---
title: "The TrashCash | Turning Deleted Files Into Bounties"
description: "TrashCash: restoring deleted files from Git history to recover the secrets developers thought they wiped. The biggest payouts aren't always payloads."
canonical_url: "https://amrelsagaei.com/the-trashcash-turning-deleted-files-into-bounties"
last_updated: "2025-10-28"
---

<post-media video="PX88QTgE1GY">



</post-media>

Most hunters are stuck chasing the usual suspects: XSS, SQLi, SSRF, IDOR. But here’s a reality check, the biggest payouts don’t always come from payloads.

Sometimes, they come from history.

This article is about a technique I call **TrashCash**: digging into Git repositories to restore deleted files that still contain sensitive information. Secrets developers thought they wiped clean often stay buried in commits, and if you know how to bring them back, you can turn “trash” into critical findings.

## The Idea Behind TrashCash

Every developer slips up. Maybe they accidentally commit an API key, a private cert, or a config file with passwords. They notice, panic, and delete the file.

But in Git, nothing is ever truly gone. The file might vanish from the repo’s surface, but the commit history keeps a copy.

That’s the **trash** part.<br />


Your job is to dig it back out and turn it into **cash**: by reporting valid, high-impact leaks.

## What’s the Goal?

The goal here isn’t just to “find a secret.” It’s about showing:

- **How to restore deleted files** from Git history.
- **How to triage them** for sensitive data.
- **Why this matters** for bug bounty hunters.

Think of it like digital dumpster-diving. Only difference? This dumpster can contain AWS keys, auth tokens, internal certs, or CI/CD configs.

## Hands-On Demo: Step by Step

This is all done on a real **YesWeHack-authorized program**. Nothing here goes outside scope.

### 1. Clone the Repository

```bash
git clone <target-repo-url> target-repo
cd target-repo
```

Bring the repo local. Always isolate your work.

### 2. Find Deleted Files

```bash
git log --diff-filter=D --summary | grep delete
```

This command lists every file that’s been deleted in the repo’s history. These are your candidates.

### 3. Inspect the History of a File

```bash
git log --oneline --all -- <path>
```

This shows the commit hashes and messages related to that file. You’ll see *who deleted it, when, and why*.

### 4. Look at Commit Context

```bash
git log --diff-filter=D --stat -- <path>
```

Now you’re checking the bigger picture: what else changed in that commit? Was it a rushed “fix typo” commit that also deleted a config? That’s suspicious.

### 5. Restore the File

```bash
git checkout <commit-hash>^ -- <path>
```

This brings back the deleted file locally. Remember, never push this upstream. You’re only restoring it for analysis.

### 6. Peek Inside

```bash
grep -nE "AKIA|-----BEGIN PRIVATE KEY-----|password|secret|token" <path> || true
```

This lets you preview the file for patterns like AWS keys, private keys, or hardcoded credentials.

### 7. Cross-Check for Context

```bash
git grep -n "partial_key_prefix_or_domain" || true
```

Search the repo for references. Maybe that AWS key is tied into a CI script, or the cert connects to staging servers. This boosts the severity of your finding.

## Scale and Automation

Doing this manually across hundreds of repos takes time. You could be digging through commits all week.

That’s why I scripted it. Just a simple Bash loop that runs in the background on a VPS and alerts me via Discord when it finds matches.

The point isn’t the script. It’s the idea. If you can script, automate it. If not, learn how. Either way, the technique stays the same.

## Quick Recap

- **Deleted doesn’t mean gone**: Git keeps history.
- You can restore deleted files and analyze them.
- Secrets often hide in configs, certs, or keys devs thought they removed.
- With proper triage, these findings can lead to **high-severity bounties**.

That’s why TrashCash matters. What looks like garbage can be your biggest report.

## Final Words

Hunting isn’t always about flashy payloads or new zero-days. Sometimes, it’s about thinking differently, looking where others don’t, and using the tools we already have in smarter ways.

**TrashCash** is one of those methods, simple, overlooked, and extremely powerful when applied right.

So next time you’re in a repo, don’t just look at the code that’s there. Look at the ghosts of the files that came before.

Because in Git… the trash never really leaves.

## Sitemap

See the full [sitemap](/sitemap.md) for all pages.