Google Dorking: the OSINT recon technique that never gets old
Google has already indexed most of the internet, including the parts people forgot were public. Dorking is just asking Google better questions. Here is every operator that still works, a workflow you can reuse, and the line between research and something you'll regret.
What dorking actually is
Search engines index files, login pages, directory listings, error messages, everything. Most people type plain words into Google. Dorking means using the operators Google already supports to slice that index precisely: files on one domain, pages with a certain URL pattern, pages with a title like "index of /". Security researchers have used this for over twenty years, and the collection of known queries even has a name and a home: the Google Hacking Database at exploit-db.com.
Nothing here requires hacking tools. You type queries into a search box. That's the whole trick, and it's still one of the highest-value skills in OSINT because you're querying Google's index instead of the live web. It's fast, it's cached, and it doesn't touch the target's servers.
The operators that still work
| Operator | What it does | Example |
|---|---|---|
site: | Restrict results to one domain or TLD | site:cipherpoint.linkpc.net |
inurl: | Match text in the URL | inurl:admin login |
intitle: | Match text in the page title | intitle:"index of" backup |
intext: | Match text in the body | intext:"default password" |
filetype: | Filter by file type (or ext:) | site:acme.com filetype:xlsx |
"quotes" | Exact phrase | "john q. public" resume |
-minus | Exclude a term | site:acme.com -site:www.acme.com |
before:/after: | Date-range filter | osint report after:2025-01-01 |
OR | Either term (must be uppercase) | site:acme.com OR site:acme.net |
* | Wildcard in phrases | "password is * for user" |
cache: operator is gone. Google removed it in early 2024, so any tutorial telling you to pull cached pages with it is wasting your time. For archived copies use the Wayback Machine instead.Operators stack. The real power is in combinations, not single operators:
site:*.acme.com -www -support filetype:pdf
intitle:"index of" site:acme.com .env
site:linkedin.com/in "acme corp" "security researcher"
inurl:wp-content site:acme.com filetype:sql
A recon workflow you can reuse
When you're investigating a domain (your own company, a CTF target, a client who hired you), work through it in layers instead of firing random dorks:
- Map the surface.
site:acme.com -wwwshows subdomains Google knows about. Add-inurl:help -inurl:blogto cut noise. Repeat withsite:*.acme.com. - Hunt documents.
site:acme.com (filetype:pdf OR filetype:xlsx OR filetype:docx). Internal spreadsheets that got published are the classic find. Open them and check the author metadata too. - Find panels and portals.
site:acme.com inurl:(login OR admin OR portal). You're not trying to break in. You're building a picture of what exists, and noting anything that looks forgotten. - Look for leftovers.
site:acme.com intitle:"index of",site:acme.com "confidential" OR "internal use only". Directory listings and stale staging environments show up here. - Pivot off the domain. Employee names from LinkedIn become email addresses, which become usernames on other platforms. Dorking is usually one input in a bigger OSINT chain, not the whole chain.
Write down each query as you run it. Half of good OSINT is being able to reproduce what you did last Tuesday.
Where the legal line sits
Typing queries into Google is legal. Google published the pages; you're using a public service. What gets people in trouble is what they do next:
- Logging into an admin panel you found, even with a default password, is unauthorized access in most jurisdictions.
- Downloading databases full of other people's personal data and keeping them is its own problem, separate from how you found the file.
- Running these same queries against a company during an authorized pentest is fine because you have a contract saying so. Without that paper, your intent doesn't matter much to a lawyer.
The clean rule: find it, document it, report it to whoever owns it. Responsible disclosure of an exposed database will get you thanked. Downloading it will get you questioned.
Practice it for real
Reading about dorks is not the same as running them. CipherPoint's challenge set includes cases where a single well-chosen dork is the difference between stuck and solved, and the "Advanced Google Dorking Techniques" article in the Intel Vault goes deeper into investigation-specific patterns.
Try a challenge that rewards better questions.
Solve a CTF on CipherPoint