GDE-016 |
Google dorking | |||||||
Digital infrastructure | ||||||||
August 2026 | ||||||||
01
What it is
Google dorking is the use of advanced search operators to surface indexed content that standard keyword search misses, including exposed documents, login portals, misconfigured directories and specific file types on a target's domain. It answers what a search engine has indexed about a target that the target never intended to be publicly discoverable.
Search engines index far more than a website's homepage. Operators such as site:, filetype: and intitle: let an investigator query that index directly, surfacing PDFs, spreadsheets, configuration files and login pages that a general search would bury or never return at all. Because dorking works entirely through a search engine's public interface, it requires no special access and leaves no trace on the target's own systems.
Investigators use dorking to find exposed documents before a target notices and removes them, identify subdomains and infrastructure not linked from a target's main site, and locate specific file types such as spreadsheets or internal presentations that frequently contain sensitive detail.
|
When to use this guide
|
02
How do you use Google dorking for OSINT?
Combine search operators to narrow the index to exactly the content type and scope you need.
Free before paid. Dorking itself requires nothing beyond a search engine; the tools below help scale and organise the technique.
Google Advanced Search: Free. The core tool; supports site:, filetype:, intitle:, inurl:, and intext: operators alongside date-range and language filters. No account required for basic use.
Google Hacking Database (GHDB): Free. Maintained by Exploit-DB, a curated library of proven dork queries organised by category (exposed files, login portals, vulnerable servers), useful as a starting point rather than building every query from scratch.
Pagodo: Free and open source. Automates running a batch of GHDB-style dorks against a target domain and logs the results, useful when checking a large number of query patterns systematically.
Bing Advanced Search: Free. Bing's index differs from Google's and occasionally surfaces content Google has not indexed or has since removed; running the same dorks against both engines catches more.
|
Before you begin Stop at the login. No login is required for any tool in this guide. Search engines rate-limit automated or unusually rapid manual querying, so space out large batches of dork queries, particularly when using Pagodo, to avoid a temporary block. Legal considerations. Dorking only surfaces content a search engine has already indexed from the public web; it does not bypass any access control. Finding an exposed document through a dork is not authorisation to use its contents for any purpose beyond the investigation, and responsible disclosure to the affected organisation is good practice when a serious exposure is found. |
Start every dork with site:targetdomain.com to restrict results to the target's own indexed pages, including subdomains unless further restricted. This is the foundation every subsequent operator builds on.
Combine the site: operator with filetype: for pdf, xlsx, docx, pptx and csv. Internal presentations, spreadsheets and PDFs are the most common accidental exposures and frequently reveal organisational structure or internal terminology.
Use intitle:"login" or inurl:admin combined with the site: operator to find authentication pages indexed by the search engine. Recording that a portal exists and is indexed is itself a useful finding; do not attempt to log in.
Use site:*.targetdomain.com -site:www.targetdomain.com to surface subdomains excluding the main site. Development, staging and internal tool subdomains frequently turn up this way despite never being linked publicly.
Filter the Google Hacking Database by category relevant to your investigation (exposed documents, vulnerable servers, login pages) and adapt the site-restricted versions of relevant entries to the target domain.
Repeat key queries against Bing, since the two engines index and retain content differently. A document removed from Google's cache may still appear in Bing's, or vice versa.
|
03
What false positives affect Google dorking?
Search engine indexing behaviour creates specific traps for dorking results.
Indexed does not mean current: A search result can point to a page the search engine indexed months or years ago that no longer exists or has changed significantly. Verifying check: Click through to the live page and compare against the cached snippet; use the Wayback Machine to check the historical state if the live page has changed or returns an error.
site: scope can miss content on parked or migrated domains: If a target has changed domains or the content sits on a third-party subdomain (such as a cloud storage bucket), a site: search restricted to the primary domain will miss it entirely. Verifying check: Search separately for the organisation's name alongside common third-party hosting patterns (amazonaws.com, blob.core.windows.net) rather than relying solely on the primary domain scope.
A GHDB entry designed for vulnerability scanning is not automatically relevant to OSINT: Many database entries target technical vulnerabilities rather than informational exposure, and running them without understanding the category can waste time or, in some jurisdictions, cross into unauthorised scanning. Verifying check: Filter by the GHDB's own category labels and stick to "files containing" and "sensitive directories" categories for pure information-gathering work.
Removed content can still show in the snippet: A search result snippet is generated from the cached version and can display sensitive text even after the live page has removed it. Verifying check: Note that the snippet itself may be the only surviving copy; capture it directly rather than assuming the live page will confirm the same content.
Chain of custody: Search-indexed content is often the first thing a target removes once an exposure is noticed, and search engine caches themselves expire and refresh on no fixed schedule.
Screenshot the search results page showing the query used and the result snippet.
Save a copy of the exposed document itself where accessible, not only a reference to its URL.
Submit the live URL to the Wayback Machine's Save Page Now tool immediately upon discovery.
Record the exact dork query string used, so the finding is reproducible.
Note the search engine and date queried, since results differ between engines and change over time.
04
Go deeper
Reference cards, structured tutorials and tools for practitioners who want to build on this guide.
CARD · DIG-001
WHOIS investigation: domain name to attribution chain.
ViewDNS, SecurityTrails and crt.sh. Registrant email pivots that map infrastructure and hosting networks.
CARD · DIG-002 · SIGNAL TIER
IP infrastructure: geolocation to attribution.
IPinfo, Shodan and BGP.tools. ASN mapping and passive DNS pivots from a single IP to a documented case file.
CARD · OPS-001
OPSEC for investigators: eight-step baseline.
Signal, Mullvad and ProtonMail. Device separation and session documentation to chain-of-custody standard.
TRAINING · C04
Dorking for journalists: search operators and filetype queries.
Half to full day workshop covering search operators, filetype queries and AI-assisted discovery, led by Derek Bowler.
Evidentiary standard
Signal & Shadow operates to the LST-001 evidentiary standard. All claims are graded against the LST-001 v1.0.3 confidence tiers (Confirmed, Corroborated, Reported, Alleged) per the canonical voice and structural specification.
About Signal & Shadow
Signal & Shadow is an independent forensic investigation and methodology practice publishing tutorials, reference cards, and forensic dossiers for working practitioners. Founded by Derek Bowler.