// OSINT WALKTHROUGH

Google Dorking for OSINT.

Google Dorking — also called Google hacking — uses advanced search operators to pull unintentionally exposed assets out of the public web index. This room walks you through the operators, a recipe book of high-signal queries, and the ethical guardrails every OSINT operator follows.

OSINTBEGINNER45 MIN

The core operators

Every dork is a combination of these primitives. Chain them with parentheses and boolean keywords (AND, OR, -) to narrow results to the signal you care about.

site:

Restrict results to a single domain or subdomain.

site:example.com
filetype:

Match files by extension. Great for surfacing exposed configs.

site:example.com filetype:env
intitle:

Match a word in the page title — useful for admin pages.

intitle:"index of" "backup"
inurl:

Match a word in the URL path or query.

inurl:/admin/login
intext:

Match text inside the page body.

intext:"BEGIN RSA PRIVATE KEY"
cache:

Pull Google's cached copy of a page.

cache:example.com
ext:

Alias for filetype: — accepts same extensions.

site:gov ext:xls
-keyword

Exclude results matching the keyword.

site:example.com -www

Recipe book

Replace target.tld with your in-scope domain. Run each query, document what's exposed, then write a short remediation note for the owning team.

Exposed environment files

site:target.tld (ext:env OR ext:ini OR ext:cfg) intext:"DB_PASSWORD"

Surfaces .env / config files accidentally deployed to public web roots.

Open directory listings

intitle:"index of /" site:target.tld

Misconfigured Apache/Nginx servers leak entire directory trees this way.

Login portals & admin panels

site:target.tld (inurl:admin OR inurl:login OR inurl:portal)

Maps attack surface for credential-stuffing or default-creds checks.

Public S3 / cloud buckets

site:s3.amazonaws.com "target"

Finds buckets indexed by Google — frequently contain backups and PII.

Leaked API keys on code hosts

site:github.com "target.tld" "api_key"

Public repos sometimes commit production keys; rotate on discovery.

Hands-on tasks

  1. Pick a public bug bounty program with a wide scope (HackerOne, Bugcrowd). Confirm Google Dorking is in scope before you start.
  2. Use site: + filetype: to enumerate exposed documents (pdf, xls, doc). Note any internal naming patterns you find.
  3. Map the org's login surface with inurl: + intitle:. Do not attempt logins.
  4. Write a 1-page report: queries used, assets surfaced, severity, suggested fix.

Stay legal

  • Only dork assets that are in scope of a written authorization or a public bounty program.
  • Finding exposed data via Google is passive; using credentials you discover is not — stop at discovery.
  • Report findings to the owning team via the program's disclosure channel before publishing anywhere.
  • The Google Hacking Database (GHDB) is a great reference but cross-reference current laws (CFAA, UK CMA, etc.).

Ready to pivot from passive to active?

Spin up a Kali VM and chain Google Dorking with active recon.

Deploy Range