Back to Blog
July 26, 20269 min

Google Dorking for Investigators

Advanced search operators to find information hiding in plain sight.

Google processes over 8.5 billion searches per day. Most users never venture beyond the first page of results. For an OSINT investigator, that's where the real work begins. Google Dorking — using advanced search operators to surface indexed content not intended for public consumption — remains one of the highest-ROI techniques in open source intelligence, and in 2026 the landscape has shifted in some important ways.

What Actually Works in 2026

Between 2023 and 2025, Google tightened several operators. inurl: and intitle: still work reliably. filetype: is partially restricted — PDF and XLSX return results, but sql and dll are heavily filtered. The biggest change: cache: was retired entirely in late 2024. The replacement is before: and after: date-range operators, which give you far more precise temporal control than Google ever offered natively before.

The site: operator is still your most powerful ally. Combined with intext:, it lets you carve out exactly the corner of the web you care about. The difference between a novice and a proficient dorker is knowing not just the operators, but the right combinations.

Real-World Dork Strings

Exposed Credentials and Config Files

site:pastebin.com intext:password intext:@gmail.com -intext:example
site:github.com intext:\"DB_PASSWORD\" intext:\"DB_HOST\" language:sql
filetype:env intext:DB_PASSWORD -gitlab -github
intitle:\"index of\" intext:wp-config.php

The first string surfaces pastebin entries containing both a password and a Gmail address — classic credential dump material. The second finds exposed database credentials in SQL files on GitHub. The third hunts for .env files (still alarmingly common in 2026). The fourth looks for directory listings containing WordPress config files, which often include database credentials.

Internal Documents and Dashboards

intitle:\"grafana\" inurl:dashboard -demo -play
intitle:\"kibana\" inurl:app/discover -demo
filetype:xlsx intext:\"SSN\" OR intext:\"social security\" site:.gov
intitle:\"jenkins\" intext:\"build\" inurl:job

Internal dashboards indexed by Google are a goldmine. Grafana and Kibana instances with open authentication expose metrics, logs, and infrastructure topology. Jenkins dashboards reveal CI/CD pipeline details, environment variables, and occasionally hardcoded secrets. Excel files containing PII on .gov domains should not exist — but they do, and filetype:xlsx finds them.

Login Portals and Admin Panels

intitle:\"login\" intitle:\"admin\" inurl:admin -inurl:demo -inurl:test
inurl:cpanel intext:\"login\" -site:documentation.cpanel.net
intitle:\"confluence\" inurl:login intext:\"atlassian\"
site:targetcompany.com intitle:\"login\" OR intitle:\"sign in\" -inurl:blog

During a targeted investigation, discovering a login portal is often step one. The last string here targets a specific organization: site:targetcompany.com intitle:\"login\" -inurl:blog. This strips out blog subdomains and returns only login pages. Combine with inurl:vpn or inurl:portal for internal access points.

The Limitations (and Workarounds)

Google aggressively rate-limits automated dorking. Running more than a few dozen queries from the same IP in rapid succession triggers CAPTCHAs or temporary blocks. The workaround: use the Google Custom Search JSON API (100 free queries per day) or rotate residential proxies. Even then, the API doesn't support intitle: or inurl: — only the web UI does.

Another limitation: Google strips many query parameters from search URLs shared publicly. If you find a dork string in a blog post, test it yourself — the results you see will differ from what the author screenshotted two months ago. Google's index is updated constantly, and site: counts fluctuate daily.

Building a Repeatable Dorking Workflow

Don't run dorks manually. Build a curated spreadsheet organized by category (credentials, internal tools, misconfigured storage, PII, login portals, code repositories). Each row contains the dork string, the target domain or scope, the date last run, and a notes column. Run your top 20 dorks weekly against each scope. Track what changes. A dork that returns nothing for months that suddenly produces results is worth investigating immediately.

For bulk operations, tools like Dorks Eye or DorkSearch automate the process against Google Custom Search. For targeted investigations, manual dorking through a clean browser profile is still more reliable.

Ethical Boundaries

Publicly indexed content is accessible by anyone — that doesn't mean you should exploit it. If you find exposed credentials via a dork, do not attempt to use them. Report them through the organization's responsible disclosure channel or via Google's report form. Document what you found, take a screenshot, and move on. The goal of OSINT is intelligence gathering and threat assessment, not exploitation.

Google's Terms of Service explicitly prohibit automated querying. If you're running dorks at scale, use the Custom Search API and respect rate limits. This is a reconnaissance technique, not an attack vector — treat it as such.

Quick Reference: Essential Operators

OperatorExampleWhat It Does
site:site:example.comLimit results to a domain
intitle:intitle:\"index of\"Find pages with text in title
inurl:inurl:adminFind pages with term in URL
intext:intext:passwordSearch body text only
filetype:filetype:pdfLimit to specific file type
before:before:2025-01-01Results indexed before date
after:after:2026-01-01Results indexed after date
cache:[retired 2024]Use web.archive.org instead