Google Dorking for OSINT

Google Dorking is the practice of using advanced search operators in Google Search to find specific strings, file types, or configurations in the index that often expose sensitive information. The term was popularized by Johnny Long in his book 'Google Hacking for Penetration Testers.' The underlying mechanism relies on Google's crawler indexing the content of web pages, including metadata, URLs, and file contents, and then allowing users to query that index with operators that go beyond simple keyword matching.

Google's web crawler (Googlebot) systematically downloads web pages, follows links, and stores the content in a massive index. For each page, it records:

When you perform a search, Google's algorithms match your query against this index. Normal searches use keyword matching across the full text. Advanced operators, however, query specific fields of the index. For example: - intitle: restricts results to pages where the search term appears in the title. - inurl: restricts results to pages where the term appears in the URL. - filetype: restricts results to a specific file type (e.g., pdf, xls, doc). - site: restricts results to a specific domain or subdomain. - intext: restricts results to pages where the term appears in the body text. - cache: shows the cached version of a page. - link: (deprecated but still works in some contexts) shows pages that link to a given URL.

The exam expects you to know the following operators and their typical use cases:

A typical Google dork combines multiple operators to narrow down results. For example:

intitle:"index of" inurl:admin site:example.com

This dork looks for directory listings (pages with 'index of' in the title) that contain 'admin' in the URL, restricted to example.com.

Common dork patterns for penetration testing include:

The GHDB is a repository of tested dorks maintained by Offensive Security (exploit-db.com). It categorizes dorks by type, such as:

The exam may ask you to identify dorks from the GHDB or to choose the correct operator for a given scenario.

As a penetration tester, you may also need to recommend mitigations. Defenses include:

Google Dorking is a passive reconnaissance technique because you are only querying Google's public index, not directly interacting with the target. However, using dorks to access sensitive information (e.g., passwords) without authorization may violate laws like the Computer Fraud and Abuse Act (CFAA) in the US. On the PT0-002 exam, you should understand that Google Dorking is legal as long as you do not attempt to access or use the discovered data without permission. The exam focuses on the technical aspects, but ethical boundaries are implied.

Google Dorking is often combined with other OSINT tools like Shodan (for internet-connected devices), Censys, and theHarvester. For example, you might use Google Dorking to find exposed admin panels and then use Shodan to find open ports on those servers. The exam may present scenarios where you need to choose the appropriate OSINT technique.

In an enterprise environment, Google Dorking is often used during the reconnaissance phase of a penetration test. For example, a pentester targeting a large financial institution might start by enumerating all subdomains using site:*.bank.com and then look for exposed admin panels with inurl:admin. They might find a test server at test.bank.com/admin that uses default credentials. In another scenario, a manufacturer might have exposed a .xls file containing employee names and salaries. The pentester would use filetype:xls site:manufacturer.com to find such files.

A common misconfiguration is leaving backup files (e.g., .bak, .old) in the web root. For instance, a PHP application might have a backup of config.php named config.php.bak. Google may index this file, revealing database credentials. The pentester would use filetype:bak site:target.com to find these.

Defenders can protect against Google Dorking by implementing proper access controls, using robots.txt to disallow indexing of sensitive directories, and regularly scanning the GHDB for dorks that expose their data. For example, a company might add the following to robots.txt:

User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /backup/

However, robots.txt is only a suggestion; malicious crawlers ignore it. Therefore, it's better to use authentication and to avoid storing sensitive files in web-accessible directories.

Performance considerations: Google Dorking is rate-limited by Google. If you run too many queries in a short time, Google may block your IP or require CAPTCHA. Pentesters often use proxies or API keys to avoid this. Also, the results are only as current as Google's last crawl. A file might have been removed but still appear in the index for days or weeks.

What goes wrong: A common mistake is using the wrong operator. For example, using inurl: when intitle: is needed, or forgetting to use quotes for exact phrases. Another mistake is not scoping the search with site:, resulting in irrelevant results. Also, pentesters might overlook the fact that Google's operators are case-insensitive, but the terms themselves are case-insensitive as well. Finally, relying solely on Google Dorking without combining it with other OSINT techniques can miss a lot of information.