Skip to content
Lesson 5 of 8

Advanced Search and Google Dorking

6 min read

The Power of Advanced Search

Search engines are probably the most underrated OSINT tool. Most people just type loose words, but search engines offer a language of operators that turns a generic search into a surgical query. Mastering these operators lets you find exactly what you are looking for and discard the noise, multiplying the investigator's effectiveness.

The set of techniques that combines these operators to discover specific information is known as Google Dorking (or Google Hacking, a term coined by Johnny Long). Despite the name, the technique applies to almost any engine — Bing, DuckDuckGo, or Yandex have their own operators. The core idea is the same: instruct the engine to return only pages that meet very precise conditions.

It is essential to understand that Google Dorking does not access anything that is not already indexed and publicly accessible. It finds what is exposed, not what is protected. That is why it is such a valuable tool for defensive audits: it reveals what sensitive information of an organization has unintentionally ended up within reach of any search engine.

Fundamental Operators

A few operators form the basis of all dorking. site: limits results to a specific domain; filetype: (or ext:) searches for specific file types; intitle: and inurl: search for terms in the page title or in the URL respectively. Quotation marks force an exact phrase match, the hyphen - excludes terms, and the OR operator (in uppercase) broadens the search to alternatives.

# Map everything indexed about a domain (ideal for auditing your own exposure)
site:example.com

# Documents that often contain internal information and metadata
site:example.com filetype:pdf

# Open directory listings from a misconfiguration
intitle:"index of" site:example.com

# Combine operators: PDFs marked confidential on a specific domain
site:example.com filetype:pdf "confidential"

The real power appears when you combine them. In an audit, this kind of query can reveal real leaks: internal documents, exposed backups, or credentials in configuration files indexed by mistake. An operating principle: start broad (site:) and narrow with each operator until you isolate exactly what you are looking for.

Responsible Dorking and the Google Hacking Database

There is a public repository, the Google Hacking Database (GHDB) maintained by Exploit-DB, that catalogs thousands of known dorks: queries that reveal exposed configuration files, accessible cameras, revealing error messages, or leaked credentials. It is an excellent learning resource for understanding what kinds of exposure exist and how to formulate effective queries.

The responsible use of these dorks is key. Searching for exposed information about your own organization, or about a target within the scope of an authorized pentest, is legitimate and very useful OSINT. However, using the information found — for example, leaked credentials or exposed panels — to access third-party systems without permission is illegal, regardless of how easy it was to find.

Dorking is, in this sense, a double-edged tool that the ethical investigator uses primarily to defend. Finding that a sensitive document is indexed allows requesting its removal; discovering an exposed panel allows closing it before an attacker finds it. The value lies in prevention, not exploitation.

Mini-case: Auditing Your Own Exposure

A typical defensive flow over example.com, run with judgment and only against your own assets:

  1. site:example.com filetype:xlsx → a spreadsheet with a supplier list appears. Finding: remove it and block indexing.
  2. site:example.com inurl:admin → an indexed admin panel. Finding: restrict by IP/VPN and add noindex.
  3. site:example.com "-----BEGIN" → a file with a private key published by mistake. Finding: rotate the key immediately and delete the file.

In each case the value lies not in exploiting, but in closing the door before the adversary. That is the quintessential legitimate use of dorking: turning the attacker's visibility into the defender's advantage.

Secret Hunting in Repositories

Public code is a frequent source of accidental leaks. GitHub and GitLab have their own search engines, where it is common to find secrets leaked in commits (API keys, passwords in configuration files). Searching for your own leaked secrets is an essential defensive hygiene practice:

# In GitHub code search (auditing your own organization)
org:my-organization "AKIA"            # possible AWS access keys
org:my-organization filename:.env     # environment files uploaded by mistake
org:my-organization "BEGIN RSA PRIVATE KEY"

# Automate scanning your own repo's history for secrets
trufflehog git https://github.com/my-organization/my-repo.git
gitleaks detect --source . --report-format json

If you find one of your own secrets exposed, the correct response is always the same: rotate it immediately. Purging the file from history is not enough if the key was already public; you must assume it was compromised.

Specialized Engines and Sources

Beyond Google, there is an ecosystem of specialized search engines covering specific niches. We already mentioned Shodan, Censys, and crt.sh for infrastructure. For people and professional data, platforms like LinkedIn or email finders like Hunter.io provide different angles.

Time machines like the Wayback Machine (archive.org) are indispensable: they let you view old versions of a web page, recovering content the target has already deleted but that remains of interest. A contact email, a directory structure, or a document that no longer exists on the current site is often still accessible in the historical archive:

# List all archived URLs of a domain (useful for finding old paths)
curl -s "http://web.archive.org/cdx/search/cdx?url=example.com*&output=text&fl=original&collapse=urlkey"

Finally, metasearch engines and aggregators combine multiple sources into a single query. The key to success is not knowing a single magic tool, but knowing which engine is right for each type of data and combining several to corroborate findings.

Investigator OPSEC

  • Dorking is passive by nature: queries hit the search engine's index, not the target's site. It is quiet.
  • Beware: clicking a result does visit the target's site and leaves your IP in its logs. If stealth matters, check the cached or Wayback Machine version first.
  • A high volume of automated dorks can trigger the engine's CAPTCHAs; spread them out and use official APIs where they exist.
  • Perform dorking from an identity and network separated from your personal life.

Advanced Search Checklist

  • [ ] Query scoped with site: and refined with operators until the target is isolated.
  • [ ] Dorks applied only to your own assets or within the authorized scope.
  • [ ] Own repositories reviewed for secrets (GitHub, trufflehog, gitleaks).
  • [ ] Any exposed secret of your own: rotated, not just deleted.
  • [ ] Historical content reviewed on the Wayback Machine before assuming it is gone.
  • [ ] No finding used to access third-party systems: prevention, not exploitation.