Google Is Your Free APT: How I Find API Keys Without Hacking Anything

You don't need a 0-day. You don't need a C2. You don't even need to know how to code.

You need a browser and the pathological inability of developers to read documentation.

Last Tuesday, I was bored. Which in our industry is a more dangerous starting condition than "motivated by nation-state funding."

I opened Google. Typed three lines. Found 17 live .env files, 4 exposed Postman collections with production Stripe keys, and one startup's entire infrastructure diagrammed in a public Docker Hub README. Total time: 4 minutes and 38 seconds. Total CVEs exploited: zero.

This isn't hacking. This is archaeology. We're just digging up what people voluntarily buried in public.

Welcome to the laziest APT you'll ever run.

The 5-Minute Breach That Shouldn't Exist

Let me set the scene.

It's 11:47 PM. I'm on my third coffee, trying to audit my own infra because paranoia is a lifestyle choice. I type this into Google:

site: [REDACTED — MY TEST DOMAIN] filetype:env

Nothing. Good. I'm not an idiot.

Then I get curious. I remove the site: filter. For science. For research. For the purely academic understanding of how broken everything is.

filetype:env "DB_PASSWORD"

Google: About 2,340 results.

First result: Laravel app. Full database creds. Second result: WordPress staging env with WP_JWT_AUTH_SECRET_KEY=. Third result: Someone's personal portfolio site with their Mailgun API key, SendGrid key, and what appears to be a love letter to his cluster.

I didn't hack them. I Googled them. Google did the hacking. I'm just the guy who knows how to ask.

That's the dirty secret of OSINT: The most effective initial access vector in 2026 isn't phishing or RCE. It's inurl:.

And we keep pretending GHDB is still relevant.

The Dorks Everyone Knows (And Why You're Still Using Them Like It's 2014)

If your Google dork list looks like it was copy-pasted from a 2014 HackForums thread, it probably was. Let's get the classics out of the way so we can kill them.

The Boomer Dork: filetype:env

Yes, it works. Yes, it's still finding live secrets in 2026. But it's also the first thing every WAF, every bug bounty hunter, and every intern who just finished a TryHackMe room is searching. It's noisy, it's burned, and half the results are now honeypots set up by security vendors to sell you something. It's the password123 of dorks.

2. The Script Kiddie Special: intitle:"index of" .env

Classic Apache directory listing. You feel like when it hits. You are not Mr. Robot. You're looking at a directory listing that Google indexed in 2019 and the dev forgot to disable after moving to Nginx. 90% of these are dead links now.

3. The Bug Bounty Bingo: ext:json "api_key"

This finds 40,000 results of people arguing about api_key on StackOverflow and 3 results of actual exposed config files from a Firebase project that someone deployed at 2 AM and never took down. Signal-to-noise ratio: catastrophic.

These work. That's the problem. They work just enough to keep you lazy.

If you stop here, you're not an OSINT researcher. You're a tourist. You're using the same 10 dorks that are in every "Ultimate Google Hacking Listicle" that ranks on page one of Google. Which is ironic, because Google has already de-indexed half of them.

Which brings us to why your bible is outdated.

Why GHDB is Dead (And What Temporal Decay Actually Means)

The Google Hacking Database is a beautiful historical artifact. Like MySpace.

It was built for a web that doesn't exist anymore. In 2012, a .env file stayed indexed for years. In 2026, the average lifespan of an exposed secret on the open web is 11 days before it gets rotated, removed, or exploited by a crypto miner and then removed anyway.

This is Temporal Decay. Google isn't an archive. It's a river.

GHDB dorks assume persistence. Real secrets are ephemeral. You need to search for freshness, not just existence.

The pros don't use filetype:. The pros use time operators.

after:2026–10–20 before:2026–10–30 is more powerful than any clever filetype combo. Combine that with dorking and you aren't searching the internet. You're searching this week's mistakes.

GHDB also assumes Google is dumb. Google in 2026 is terrifyingly smart. It autocorrects your dorks. It filters "sensitive" filetypes. It actively suppresses results it thinks are secrets. If you type filetype:env DB_PASSWORD raw, Google will try to be helpful and show you docs about environment variables. You have to lie to it.

You have to speak Google-ese.

Which leads me to the dorks no one talks about because they require more than two brain cells.

The 3 Dorks Nobody Talks About (This Is Where It Gets Fun)

Stop searching for files. Start searching for systems that create files.

1. The GraphQL Autopsy

Devs love GraphQL because it's flexible. Attackers love GraphQL because devs leave introspection on in production and push the playground to /graphql with a sticky note that says "pls don't hack."

Try this mindset, not just a string: Search for GraphQL schema artifacts that leak.

Instead of hunting api_key, hunt the thing that serves the api_key.

Conceptually, you want to look for: sites that expose a GraphQL endpoint + have introspection enabled + were indexed in the last 7 days.

In dork-speak: You're combining inurl:/graphql with in-text clues like __schema or IntrospectionQuery and then filtering by after:. Add site:*.your-target-TLD.com when you're auditing your own assets. Suddenly you're not finding keys. You're finding entire API maps with getUser(apiKey: String) just sitting there.

I once found a fintech's internal admin mutation revealSecret(keyId:) exposed this way. They had auth. The playground didn't. Google had indexed the playground.

2. The Certificate Transparency Time Machine

This is evil. And it's completely public.

Every time someone creates a dev subdomain like api-staging-v2-dev.company.com, a Certificate Transparency log records it. Google indexes those logs via third-party CT search engines, and Google also indexes the subdomains when they go live.

The dork here isn't a Google dork. It's a meta-dork. You use CT logs to get the subdomain list, then you use Google to search inside it.

Example flow: Find a new subdomain in crt.sh from 48 hours ago -> Google site:new-subdomain.company.com ext:json OR ext:env OR ext:log -> Watch as the dev who spun it up yesterday to "test something quickly" left a .log file with bearer tokens.

You're not hacking the main domain. You're hacking the developer's to-do list. CT logs are their diary. Google is just reading it out loud.

3. The Docker Hub Confessional

Developers treat Docker Hub like a private hard drive. It is not.

They push images with names like mycompany/backend-test-do-not-use-final-v2 with full ENV vars baked into the Dockerfile history. And because Docker Hub has excellent SEO, Google indexes every single README and layer description.

Search conceptually for: Docker Hub registry pages that contain env-like strings in their auto-generated documentation.

Think site:hub.docker.com "DATABASE_URL". Think site:hub.docker.com "AWS_SECRET_ACCESS_KEY" after:2026–09–01.

You will find startups who literally pasted their production .env into the Docker Hub description field "so the team can find it." I found one company whose Docker Hub image description was just a dump of 34 secrets. The image hadn't been updated in 2 years. The secrets still worked.

Again: You didn't hack Docker. You Googled a public registry that Google had already indexed.

So, Are We Hackers Now?

No. We're librarians with bad intentions.

The point isn't that Google is a hacking tool. The point is that Google is the infrastructure. Your attack surface isn't your code. It's Google's memory of your code.

Every env.example you commit, every Postman collection you publish to the public workspace, every Swagger UI you leave at /api-docs with "Try it out" enabled — Google is taking a screenshot. And it remembers longer than your incident response team does.

The real APT isn't in your logs. It's in your search results.

This is why I stopped collecting dorks and started collecting operator combinations. A single dork is a key. A combination is a lockpick set.

filetype:env is a key.

site:*.io after:2026–10–24 inurl:api "OPENAI_KEY" is a lockpick set that opens a very specific, very expensive door that was installed this week.

GHDB gave you 500 keys. The modern web needs 200 combinations that account for decay, suppression, and system-level leaks.

Yes, there is a loadout for this.

Look, I could keep giving you dorks on Twitter like every other infosec influencer farming engagement with screenshots of .env files they "responsibly disclosed" (after posting them for clout).

Or you could stop using the same 10 dorks from 2014.

I put everything into The Google Dork Bible — not another list of intitle:index.of variations. It's 200+ operator combos built for 2026: temporal dorks, GraphQL & OpenAPI introspection hunters, CT log chaining, Docker registry + GitHub Gist cross-pollination, and a whole section on how to bypass Google's "helpful" filtering when it tries to hide secrets from you.

It has a novel techniques section because I'm tired of seeing the same PDF from 2007 re-uploaded with a new cover.

If you're still manually typing ext:env and hoping for the best, you're not doing OSINT. You're doing nostalgia.

Your next breach report is already indexed. You just didn't google it right.

Stop using the same 10 dorks from 2014. Get the Bible.

The Google Dork Bible: Finding Secrets in Plain Sight Paid field manual in the OSINT / investigation route. A field map for finding signal without drowning in tabs. What this…

P.S. All examples above were found on assets I own or during authorized audits. If you go hunting on live targets without permission, you're not a researcher. You're just the next breach report someone else is Googling. Audit yourself first. Then get a bug bounty program. Then be smart about it.