As a bug bounty hunter, you'll succeed by spotting stuff everyone else misses. Sure, complex exploits are flashy, but honestly? Simple stuff like exposed config files or forgotten backups can pay just as well. Here's the thing, you don't need some expensive scanner to find this stuff. Google works just fine.

Google dorking, also known as Google hacking is basically getting really good at search queries to find sensitive information inadvertently exposed to the public internet. It's a cornerstone technique for reconnaissance and vulnerability discovery.

Alright, let me share some Google dorks I've found useful over the years. I'll break these down by category and explain why each one matters and how to use it. Use these dorks responsibly to identify and report issues.

Phase 1: Broad Reconnaissance — Mapping the Attack Surface

Subdomains often host forgotten or vulnerable services, making them a great starting point for reconnaissance.

Goal: Discover every possible domain, subdomain, and associated asset belonging to your target. Think breadth, not depth.

1. Find Sub Domains & Sub-Subdomains

site:*.example.com site:*.*.example.com

2. Search Certificate Transparency Logs: Discover subdomains by finding every SSL certificate issued for your target.

site:crt.sh "example.com"

3. Discover Associated Code (GitHub): Find code, configs, and secrets developers might have accidentally made public.

site:github.com "example.com" API_KEY site:github.com "example.com" password site:github.com "example.com" .env

4. Historical Analysis (Web Archive): Uncover old versions of sites that may have exposed pages, files, or endpoints no longer available.

site:archive.org example.com site:archive.org example.com/admin site:archive.org org example.com/config

5. Search Other Search Engines (via Google): Let Google index results from Shodan and Censys to find infrastructure details.

site:shodan.io "example.com" site:censys.io "example.com"

Phase 2: Content Discovery — Finding Hidden Entry Points

Goal: On the domains and subdomains you found, locate specific applications, login portals, and administrative interfaces.

1. Identify Technologies: What is the site built with? This dictates your next steps.

site:example.com "WordPress" // Look for plugins/themes site:example.com intitle:"phpinfo()" // Find PHP info pages site:example.com ext:action | ext:struts // Find Apache Struts apps

2. Find Login Portals: Every login page is a potential target for weak credentials, brute-force, or MFA bypass attacks. site:example.com intitle:"login" site:example.com inurl:/admin/login site:example.com inurl:/drupal/user/login site:example.com inurl:/joomla/administrator

3. Locate Administrative Interfaces: Broaden your search for any administrative backend.

site:example.com intitle:"admin" site:example.com inurl:/admin/ site:example.com inurl:/administrator/ site:example.com inurl:/wp-admin/

4. Find Install & Setup Pages: These pages, if left accessible, can be a goldmine. site:example.com inurl:install site:example.com inurl:setup site:example.com inurl:/install/install.php

Phase 3: Vulnerability Hunting — The "Juicy Info"

Goal: Now that you have a map, hunt for the low-hanging fruit: exposed sensitive data and common misconfigurations. This is where you find quick wins.

1. Directory Listing Vulnerabilities: Open directories provide a direct map to all other juicy files.

site:example.com intitle:"index of" site:example.com intitle:"index of" "parent directory"

2. Exposed Sensitive Files: This is the motherlode. Hunt for configs, backups, databases, and logs.

Configuration Files site:example.com ext:env | ext:config | ext:conf | ext:cnf | ext:cfg site:example.com "DB_PASSWORD" ext:env

Backup & Old Files site:example.com ext:bak | ext:backup | ext:old | ext:bkf site:example.com "index.php.bak"

Database Dumps site:example.com ext:sql | ext:dbf | ext:mdb site:example.com "# mysql dump" ext:sql

Log Files site:example.com ext:log site:example.com ext:log "username"

Source Code & Project Files site:example.com ext:yml "main.yml" site:example.com filetype:yml "docker-compose" site:example.com inurl:/.git/config

3. Error Messages: Error pages can reveal SQL Injection vulnerabilities and internal system details.

site:example.com intext:"sql syntax near" site:example.com intext:"warning" "include_path"

4. Specific High-Value Targets: Check for these paths directly. They are often a direct path to a critical bug.

API & Auth Files site:example.com inurl:/api.json site:example.com inurl:/.well-known/jwks.json

WordPress Specific site:example.com inurl:/wp-config.php.bak site:example.com inurl:/wp-content/debug.log site:example.com inurl:/wp-content/backup-*

File Uploads & Redirects site:example.com inurl:upload site:example.com inurl:redirect?url= // Open Redirects

Phase 4: Advanced & Obscure Hunting

Goal: Look for very specific, often overlooked vulnerabilities and backdoors.

1. Finding Backdoors: Evidence of compromised systems. site:example.com inurl:"shell.php" | intitle:"c99shell"

2. Publicly Exposed Documents: Find internal documents, spreadsheets, and presentations.

site:example.com ext:doc | ext:docx | ext:pdf | ext:xls | ext:xlsx site:example.com filetype:xls "password"

Conclusion: The Hunter's Mindset

The difference between a novice and an expert is process. Don't just run commands; follow a strategy.

Map Everything: You can't test what you can't see. (Phase 1) Find the Doors: Locate all points of interaction. (Phase 2) Check for Unlocks: Look for the easiest way in — exposed data. (Phase 3) Inspect the Locks: Finally, move on to testing the functionality of the doors themselves (e.g., SQLi on login forms), which often requires tools beyond Google. By following this workflow, you ensure comprehensive coverage and dramatically increase your chances of finding valid, high-impact bugs.

Happy Hunting!