Google Dorking

Dorking is using a search engine’s own query language to find things its index already holds but nobody meant to publish: config files, backups, admin panels, stack traces, cloud buckets, private keys. No packet reaches the target — you are querying Google’s copy of the web, which is why it opens Stage 00 — Passive External Recon and why it survives every firewall, WAF and rate limit the target owns.

The technique is old and the operators are few. What separates a useful dork from noise is knowing which operators still work, how they combine, and where each one silently fails.

[!danger] Indexed is not authorised Every dork on this page returns links. Following one to retrieve a config file, enumerate a bucket, or log into a panel is access, and access needs written permission — a public URL is not consent, and “it was in Google” has never been a defence. Personal data you collect is regulated (GDPR and equivalents) whether or not the engagement covers it. Use this against your own estate, a scope you hold in writing, or a lab you are entitled to.

1. Why it works — you are searching the index, not the site

A crawler finds a URL, fetches it, and the indexer stores the text, title, URL and file type. Everything dorking does is filter that stored record. Three consequences matter:

The practical reading: the index is a historical record of what the target served, not a snapshot of what it serves now. Treat every hit as a lead with a timestamp, not a live finding.

2. Anatomy of a dork

site:example.com ext:sql intext:"CREATE TABLE" -site:docs.example.com
└──── scope ───┘ └─ type ┘ └───── content ────┘ └────── exclusion ─────┘

Four moving parts, and only the first is mandatory in practice:

• Scope — which hosts count (site:).
• Type — what kind of document (ext: / filetype:).
• Content — a literal that only the interesting version of the file contains (intext:, intitle:, inurl:).
• Exclusion — what to subtract once the first pass is noisy (-site:, -inurl:).

Terms and operators are AND-ed by default. There is no AND keyword — writing one searches for the word “and”.

[!tip] Build them in that order Scope first, then type, then narrow with content, then subtract noise. Starting from a long stacked dork you copied off a list gives you zero results and no idea which clause killed it. Start broad, add one operator at a time, and watch the result count move.

3. Operator reference

Scope

Content position

File type

One extension per operator — stack them with OR to cover a family:

site:$DOMAIN ext:sql OR ext:bak OR ext:old OR ext:backup

Google indexes a fixed set of document types (pdf, doc/docx, xls/xlsx, ppt/pptx, rtf, ps, kml, txt and a handful more). A ext:env dork works only because such files were served as plain text and indexed as text — which is precisely what makes a hit worth reporting.

Logic and grouping

site:$DOMAIN (ext:sql OR ext:bak) intext:password        # grouped correctly
site:$DOMAIN ext:sql OR ext:bak intext:password          # ambiguous — do not
password AROUND(3) database site:$DOMAIN                 # proximity
"confidential * report" site:$DOMAIN                     # token wildcard

Time and number

Retired — and what replaced them

[!warning] These appear in every dork list on the internet and none of them work

Operator	Status	Use instead
cache:	Removed by Google in September 2024, along with the cached-page links	web.archive.org, archive.today
link:	Deprecated 2017; now a silent no-op that degrades to a keyword search	Search Console (for sites you own) or a commercial backlink tool
info:	Retired; folded into ordinary search	Just search the bare URL
+term	Removed 2011	Quote the term instead: "term"
daterange:	Julian-date legacy syntax, unreliable	before: / after:

A retired operator does not error. Google drops it and searches the remaining words, so your dork returns plausible-looking garbage. This is the single most common reason a copied dork “stops working”.

4. The gotchas that actually break dorks

[!example] Read this section twice — it is most of the skill

Trap	What happens	Fix
Lowercase or	Treated as a stop word, dropped. Your disjunction became an AND.	Always uppercase OR.
allintitle: / allinurl: / allintext:	They consume the rest of the query — every operator after them is ignored, including site:. Your scoped dork quietly went global.	Stack the singular form instead: intitle:a intitle:b.
Space after the colon	site: example.com is parsed as a bare site: plus the keyword example.com.	Never put a space after an operator’s colon.
Unquoted multi-word value	intitle:index of means intitle:index AND the word of.	Quote it: intitle:"index of".
* outside quotes	Ignored entirely.	Only use it inside a quoted phrase.
site: is a suffix match	site:example.com also returns notexample.com-style matches on some engines and always includes every subdomain.	Add -site: exclusions, or use Yandex’s stricter host:.
Very long stacked dorks	Google historically truncated long queries, and still degrades them — the tail of a 15-operator dork may never be evaluated.	Split into two or three narrower dorks.
Personalised results	Signed in, Google reorders and filters results for you. Two operators can look broken because your profile suppressed the hits.	Search signed out, in a clean profile.
Result count is a lie	The “About N results” figure is an estimate and swings wildly.	Page to the end. The real count is where results stop.
Verbatim mode	Google rewrites and expands queries by default.	Append &tbs=li:1 to the results URL, or use Tools → All results → Verbatim.

[!tip] Two switches worth memorising &num=100 on the results URL returns 100 per page instead of 10. &filter=0 disables the “omitted similar results” collapse, which routinely hides the interesting duplicates on a large site.

5. Recipes by objective

Every dork below is written in the Google dialect with $DOMAIN, $ORG and $KEYWORD as placeholders. Section 6 covers translating them.

Exposed files and configs

The highest-yield category in the whole practice.

Login and admin panels

Open directory listings

Cloud storage

Credentials, keys and tokens

[!danger] A live key is a finding, not a login Do not authenticate with anything you find. Record the URL, report it immediately so it can be rotated, and treat your own notes as sensitive material for the rest of the engagement. See Credential Hunting, Gitleaks and TruffleHog for the systematic version of this.

Documents and metadata

# the half of this that isn't the dork: metadata gives you usernames and internal paths
exiftool -Author -Creator -Producer -Company *.pdf | sort -u
exiftool -a -G1 -s report.docx | grep -Ei 'author|company|template|lastmodifiedby'

Error messages and stack traces

Databases, backups and dumps

Injectable parameters

A target list for later, authorised testing. Nothing here is a finding by itself.

People, emails and usernames

[!warning] Personal data is regulated independently of your scope Collect the minimum that supports the finding, store it with the engagement material, and delete it when the engagement closes.

Subdomains and forgotten hosts

Dorking is the weakest of the subdomain sources — use it to catch what certificate transparency and DNS missed, not as the primary pass. See Amass and Stage 00 for the real enumeration.

Archived and removed pages

# the archive's own API beats dorking it — every captured URL, deduplicated
curl -s "http://web.archive.org/cdx/search/cdx?url=$DOMAIN*&output=text&fl=original&collapse=urlkey" \
  | sort -u > wayback-urls.txt
# pull the ones that look like config or secrets out of the pile
grep -Ei '\.(env|sql|bak|old|log|yml|ini|conf)($|\?)' wayback-urls.txt

6. Cross-engine translation

Google is the reference dialect, not the only one. Yandex and Bing routinely index hosts Google never crawled, so a subdomain dork is worth running through at least two engines.

Engine-native operators with no Google equivalent — worth the detour on their own:

[!note] Brave and DuckDuckGo are the low-friction options Neither requires an account and neither personalises results, which makes them the right place to start from a clean browser. Their operator support is genuinely narrower than Google’s and less documented — when a dork returns nothing there, re-run it on Google before concluding the target is clean.

7. Other dialects worth knowing

GitHub code search

A different language entirely, and the single richest source of leaked secrets. Requires being signed in — use a throwaway account.

org:$ORG path:.env
org:$ORG "BEGIN RSA PRIVATE KEY"
org:$ORG path:.github/workflows
"$DOMAIN" ("192.168." OR "10.0." OR ".local")
"$DOMAIN" "password" language:yaml

The last two are the interesting ones: they find other people’s repos that leak the target’s internal addressing and credentials — contractors, ex-employees, integration partners.

Shodan and Censys

These index service banners, not web pages, so the web operators do not apply at all. Covered properly in Shodan; the translation for a dorking reflex:

The origin-IP hunt behind a CDN is ssl.cert.subject.cn: — the origin still presents the real certificate.

8. The Google Hacking Database

The GHDB is Exploit-DB’s curated archive of dorks, started by Johnny Long, now thousands of entries across categories: files containing passwords, sensitive directories, vulnerable servers, error messages, footholds.

How to use it without wasting an afternoon:

• Filter by date. Most of the archive is a decade old and targets software nobody runs. Sort newest first.
• Read it as a pattern library, not a copy-paste list. The value of intitle:"index of" "service.pwd" is not that exact string — it is that vendor-default filenames are the way in. Adapt the shape to the stack you actually found.
• Scope everything. Almost every GHDB entry is unscoped and returns strangers’ infrastructure. Add site:$DOMAIN before you run it, every time.

9. OPSEC

[!danger] You are the one being logged Dorking sends nothing to the target — but it sends everything to the search engine, tied to your account, your IP and your browser fingerprint. The queries themselves describe your intent with unusual clarity.

10. Automation, rate limits and the ToS question

Scripted scraping of Google results violates its Terms of Service and fails in practice: the automation detection is good, the HTML changes, and the CAPTCHA is unsolvable at scale without paying someone to solve it. Every “google dork scanner” on GitHub has the same lifecycle — works for a week, then returns empty pages forever.

The options that actually work:

A tool that builds dorks and hands them to your browser has none of these problems, because you are still the one searching. That is what dorkforge does.

11. Blue team — defending your own estate

Dorking is trivially turned around: run it against yourself, on a schedule.

# a minimal self-audit, run monthly against your own domain
for d in 'ext:env' 'ext:sql' 'ext:bak' 'intitle:"index of"' 'intext:"BEGIN RSA PRIVATE KEY"'; do
  printf '%s\n' "site:$DOMAIN $d"
done
# feed them to the Programmable Search JSON API and diff the hit list against last month's

12. Practising safely

• Your own domains. The only fully unambiguous target, and the one where findings are actionable.
• google-gruyere.appspot.com, testphp.vulnweb.com, demo.testfire.net — deliberately vulnerable hosts published for training. Verify the terms on each before touching it.
• The GHDB, read but not run. Study the shapes; run them scoped to yourself.
• CTF and lab platforms with an OSINT category, where the scope is explicit.

[!warning] Unscoped dorks return strangers’ infrastructure A dork like intitle:"webcamXP" returns hardware belonging to people who never consented to anything. Looking at the result list is one thing; connecting to a device is unauthorised access in essentially every jurisdiction. Scope with site: or do not run it.

13. dorkforge — the companion script

dorkforge.py (SHA-256) is a single-file interactive workbench for everything on this page: it asks what you are hunting for, builds the dork, explains every operator it used, translates it for the engine you picked, and hands it to your clipboard, your browser, or an engagement log.

It ships the full library from section 5 — 14 objectives, 81 recipes, 32 operators — and it sends no traffic to any target. The searching still happens in your browser, under your account, from your IP, which is why it opens with the authorisation gate and records a scope reference in every session log.

Run it

It uses PEP 723 inline metadata, so uv resolves rich and questionary into a throwaway environment on first run. Nothing to install, nothing to clean up.

# download + verify
curl -sO https://cheatsheet.daemon-sec.xyz/downloads/enumeration/dorkforge.py
curl -sO https://cheatsheet.daemon-sec.xyz/downloads/enumeration/dorkforge.py.sha256
shasum -a 256 -c dorkforge.py.sha256     # expect: dorkforge.py: OK

# run it
uv run dorkforge.py

Expected SHA-256:

3173df88ab3102ebc4999985fcb881298f3f51374170592e5ac95d0674210193

Or make it executable and let the shebang do the work — #!/usr/bin/env -S uv run --script:

chmod +x dorkforge.py
./dorkforge.py
# keep it on PATH like the rest of your toolkit
install -m 755 dorkforge.py ~/.local/bin/dorkforge

[!note] Don’t have uv? curl -LsSf https://astral.sh/uv/install.sh | sh (or brew install uv). Failing that, pip install rich questionary and run it with plain python3 — the script degrades to that path and tells you so.

The flow

  ▪ DÆMON//SEC
  dorkforge v1.0.0    search-operator workbench
────────────────────────────────────────────────────────────

? What are you hunting for   Exposed files & configs
? Target domain: example.com
? Which engine? Google
? Which dork?  site:example.com ext:env OR ext:cfg OR ext:conf OR ext:ini

┌─   Google ─────────────────────────────────────────────────┐
│                                                            │
│  site:example.com ext:env OR ext:cfg OR ext:conf OR ext:ini│
│                                                            │
│  Application config. A served .env is credentials in       │
│  plaintext - database URI, mail password, cloud keys.      │
│                                                            │
└────────────────────────────────────────────────────────────┘

 OPERATOR   WHAT IT DOES                               GOOGLE
 ──────────────────────────────────────────────────────────────
 site:      Only return pages whose host matches.        ✓
 ext:       Synonym for filetype: on Google and Bing.    ✓
 OR         Match either side. Must be uppercase.        ✓

? Now what?  Copy to clipboard / Open in browser / Save to log

Pick a non-Google engine and it rewrites the dork and tells you what changed:

$ uv run dorkforge.py --objective listing --domain example.com --engine yandex

  site:example.com title:"index of"
    dialect notes
     ▪ intitle:  rewritten to title: for Yandex

Usage

Flags: --domain --org --keyword --ext pre-fill the scope prompts. --engine picks the dialect (google bing ddg yandex brave github shodan). --no-color for piping.

The session log

--session writes engagement-ready markdown as you work — the dork, why it was built, the live URL, and anything that did not survive translation:

# dorkforge session

- **Started:** 2026-09-26 14:21 BST
- **Authorised scope:** ACME-2026-114
- **Tool:** dorkforge 1.0.0

## 1. Google

Application config. A served .env is credentials in plaintext.

```text
site:example.com ext:env OR ext:cfg OR ext:conf OR ext:ini
```

<https://www.google.com/search?q=site%3Aexample.com+ext%3Aenv...>

Paste it straight into the recon section of a report — see Documentation and Reporting.

[!tip] The authorisation gate is once per machine The acknowledgement is stored in $XDG_STATE_HOME/dorkforge/ack.json (~/.local/state/dorkforge/ by default) along with the scope reference you gave, which is then stamped into every session log. --reset-ack clears it.