Google Dorks: Operators, OSINT and Red Team Use

Google Dorks are search queries built with Google's advanced operators to locate sensitive information exposed on the indexed web that a regular user would never find with normal searches. The technique is also known as Google Hacking, has been in use since the early 2000s, and is still one of the fastest and cheapest ways to discover confidential documents, admin panels, configuration files, credentials and exposed devices belonging to an organisation. It is a neutral tool used by security auditors, OSINT teams, investigative journalists and attackers alike.

This guide explains what Google Dorks are, which operators deliver real value, defensive and offensive use cases, examples by category, alternatives (Bing dorks, Shodan, Censys), legal aspects and how to protect an organisation against malicious use.

What Google Dorks are

A Google Dork is a query that combines advanced operators (site:, inurl:, intitle:, filetype:, intext: and others) to filter Google's index down to a very specific subset. The technique exploits two facts: Google indexes more things than most organisations imagine, and administrators make recurring mistakes (uploading backups to public directories, leaving panels unprotected, exposing logs with sensitive data).

The term Google Hacking was popularised by Johnny Long in the book of the same name and gave rise to the Google Hacking Database (GHDB), currently maintained by Offensive Security inside Exploit-DB. The GHDB is the public catalogue of thousands of dorks classified by type of finding: documents, vulnerabilities, credentials, devices.

The key point: the dork doesn't break anything. It only finds what is already exposed. Responsibility for the visible data lies with whoever exposed it, not with the search engine.

Main operators

The operators that deliver 90% of the real value:

• site: restricts the search to a domain or subdomain. site:secra.es returns only Secra pages. site:*.gov.es returns results from any gov.es subdomain.
• inurl: filters by words in the URL. inurl:admin finds paths containing "admin".
• intitle: searches for words in the HTML <title>. intitle:"index of" locates indexed directory listings.
• intext: searches in the body of the page. intext:"password" finds pages with that word in the content.
• filetype: or ext: filters by file extension. filetype:pdf, filetype:xlsx, filetype:env, filetype:sql.
• cache: shows Google's cached version of a URL. Useful when the content has been removed but is still in cache.
• -term excludes results with that word. Combined with other operators, refines searches.
• "exact phrase" in quotes literally searches for that string.
• OR and | logical, combines terms.
• * wildcard, replaces words in phrases.

Operators get combined. A serious query never uses just one: it chains three or four to cut the noise.

Use cases

The technique is used in two directions, with opposite motivations but identical methodology.

Defensive: digital exposure auditing

A security team runs dorks against its own organisation's domains to discover what Google is showing that it shouldn't. It is the first step of any footprinting exercise and appears in the standard scope of Red Team audits and external pentesting. It lets you find:

• PDF, Excel or Office documents with metadata or internal information uploaded to the website without review.
• Database backups (.sql, .bak) mistakenly accessible over the web.
• Exposed .git repositories, .env files, configurations with credentials.
• Forgotten subdomains with unmaintained services.
• Admin panels (CMS, routers, IoT) without authentication.
• Application logs with error traces leaking sensitive information.

Offensive: reconnaissance before an attack

The attacker builds a profile of the organisation before touching anything. They use the same dorks to find weak points to attack later (an admin panel with default credentials, a configuration file with an AWS key, an exposed repository with secrets). This is where Google Dorks share methodology with broader OSINT: public, silent intelligence work without touching the target's infrastructure.

The dual use justifies why any serious organisation should include a periodic dork sweep over its own domains. What your team finds is what an attacker can find too.

Practical examples by category

Real queries that show up in audits. The examples are framed for an organisation to use against its own domains.

Sensitive documents exposed

site:yourdomain.com filetype:pdf intext:"confidential"
site:yourdomain.com filetype:xlsx OR filetype:xls
site:yourdomain.com filetype:docx intext:"internal"
site:yourdomain.com filetype:pptx intext:"draft"

Usually surfaces internal presentations, spreadsheets with personal data, templates with test credentials.

Configuration files and credentials

site:yourdomain.com filetype:env
site:yourdomain.com filetype:config OR filetype:conf
site:yourdomain.com filetype:sql intext:"INSERT INTO"
site:yourdomain.com inurl:wp-config intext:"DB_PASSWORD"
site:yourdomain.com filetype:log intext:"password"

These findings are usually critical. An indexed .env can contain AWS keys, payment gateway tokens, JWT secrets. If it shows up, it's an immediate incident.

Directory listings

site:yourdomain.com intitle:"index of"
site:yourdomain.com intitle:"index of" "parent directory"
site:yourdomain.com intitle:"index of /backup"

Misconfigured web servers showing the full file tree. A classic that still shows up in 2026.

Admin panels

site:yourdomain.com inurl:admin OR inurl:login
site:yourdomain.com intitle:"admin login"
site:yourdomain.com inurl:phpmyadmin
site:yourdomain.com inurl:wp-admin

Lets you locate login pages worth reviewing (2FA, lockout on retries, unnecessary exposure).

Logs and errors

site:yourdomain.com filetype:log
site:yourdomain.com "error" "stack trace"
site:yourdomain.com intext:"sql syntax"
site:yourdomain.com intext:"ORA-00942"

Public logs expose internal paths, software versions with known CVE vulnerabilities, table and field names.

Exposed repositories and source code

site:yourdomain.com inurl:.git
site:yourdomain.com filetype:sql OR filetype:bak
site:yourdomain.com inurl:.svn OR inurl:.hg

Finding .git indexed is equivalent to being able to rebuild the entire repository, including change history and possibly committed-then-"deleted" secrets.

IoT devices and cameras

Although GHDB has hundreds of dorks specific to IP cameras, routers, printers and OT devices with web interfaces, this category is typically Shodan territory, not Google. More on that under alternatives.

Google Hacking Database (GHDB)

The Offensive Security GHDB is the public catalogue with thousands of classified dorks. Main categories:

• Footholds: configurations that allow establishing presence.
• Files containing usernames / passwords: exposed files with credentials.
• Sensitive Directories: directories that shouldn't be accessible.
• Web Server Detection: web server version identification.
• Vulnerable Files: files with known vulnerabilities.
• Vulnerable Servers: servers with specific vulnerabilities.
• Error Messages: errors that leak information.
• Network or Vulnerability Data: sensitive network information.
• Pages containing login portals: interesting login pages.
• Various Online Devices: exposed IoT devices.
• Advisories and Vulnerabilities: advisories affecting specific products.

The GHDB is constantly updated. The reasonable move is to review the categories relevant to your sector and test the applicable dorks against your own domains.

How to protect yourself

What every organisation should review to reduce exposure via dorks.

1. Inventory of subdomains and secondary domains. What you don't know you have, you don't protect. Tools like Amass, Subfinder or Certificate Transparency lookups reveal forgotten subdomains.
2. Periodic audit with your own dorks. Run the relevant categories monthly (filetype, intitle:"index of", inurl:admin, .env, .git) across all your domains. If anything surfaces, remove it from the index and fix the root cause.
3. robots.txt with care. Block what shouldn't be indexed, but remember robots.txt itself maps the path for a curious attacker. Combine it with noindex HTTP or <meta name="robots" content="noindex">.
4. Removal management. When something sensitive shows up indexed, remove the content from the server, wait a few days, and force removal from Google with the URL removal tool in Search Console. Without explicit removal, cache can survive weeks.
5. Web server configuration. Disable Indexes in Apache (Options -Indexes), autoindex off in Nginx. List directories only for public assets, never for the whole document root.
6. File upload policy. Before publishing PDF, Excel or Office on the site, remove metadata (Title, Author, Comments usually leak names and paths). Tools like exiftool automate this.
7. Repositories and secrets. Pre-commit hooks that detect secrets (gitleaks, trufflehog) and an effective ban on uploading .env, .git, .svn, .bak to production.
8. Continuous monitoring. Services that alert when something new affecting your domains appears on Google. More efficient than manual monthly auditing.

Limitations and alternatives

Google Dorks have three important limits:

• Only sees what Google has indexed. Plenty of legitimate content doesn't make it into the index (intranets, backends without a public link, resources behind auth).
• Google penalises heavy use. Mass searches from the same IP trigger CAPTCHA. Serious investigations combine it with paid APIs or rotating proxies.
• The dynamic catalogue changes. What surfaces today may not surface tomorrow. Audits have to be periodic.

That is why serious OSINT combines dorks with several complementary sources and consolidates them in a graph analysis tool. A recent trend (2024-2026): LLM-based tools generate dork variants from natural-language prompts.

Bing Dorks

Bing accepts similar operators (site:, filetype:, inurl:, intitle:) and sometimes indexes things Google doesn't, especially lower-authority domains. A useful second source. Syntax is almost identical.

Shodan

A search engine for devices connected to the internet (not for web pages). It indexes service banners (ports, software versions), which makes it the tool of choice for finding IP cameras, routers, printers, ICS/OT, exposed databases, admin panels without auth. Operators like org:, country:, port:, product:, vuln: allow very specific queries.

Censys

Similar to Shodan but with strong focus on TLS certificates, continuous scanning and research-oriented APIs. Especially useful for correlating certificates, discovering subdomains and mapping an organisation's infrastructure.

GitHub Dorks

GitHub also responds to operator-based searches. org:yourcompany filename:.env or "AWS_SECRET_ACCESS_KEY" org:yourcompany helps detect secrets committed to the organisation's public repository.

LLM-assisted tools

Tools appear that automatically generate dorks from a natural-language objective. The concept is new and quality varies a lot, but worth tracking as an evolution of the discipline.

Legal and ethical aspects

Using Google Dorks is legal in itself: you're running searches on a public service. What changes the legal framework is how you use the information you find.

• On your own systems: no restrictions. Preventive auditing is advisable and required under frameworks like NIS2 and ISO 27001.
• On a client's systems with written authorisation: standard part of the scope of an external audit or Red Team engagement.
• On third parties without authorisation: a legal gray area. Merely finding exposed information is not intrusion, but accessing, downloading or exploiting what you find can fall under unauthorised access or data protection violations depending on the case. The line between legal OSINT and unlawful discovery is poorly defined and depends heavily on context and data type.

Operational recommendation: if you find exposed information from a third party (clients, providers, peers in your sector) that looks like an incident, don't download or explore it. Notify the responsible party through the official channel (security.txt if they have one, or a documented contact channel) and document the finding in writing.

Frequently asked questions

Is using Google Dorks illegal?

No, not in itself. It's a search technique. What laws regulate is what you do with the information. Searching is legal; accessing or exploiting what you find may not be, depending on context and jurisdiction.

What are Google Dorks useful for in a company?

For auditing your own exposure. Running dorks against the organisation's domains is the cheapest and fastest way to discover what Google shows that it shouldn't: documents, panels, configuration files, repositories. Standard part of footprinting in external pentesting and Red Team.

How do I prevent my files from appearing on Google?

By combining several layers: noindex in HTTP headers or meta tags, mandatory authentication for sensitive content, robots.txt for what shouldn't be indexed (with care: the file is also public), review of X-Robots-Tag headers, metadata removal in public documents, and continuous monitoring.

Is Google Dorks still effective in 2026?

Yes. The basic techniques are the same as 20 years ago, configuration mistakes too, and relevant discoveries still surface daily. What has changed is that there are more alternatives now (Shodan, Censys, GitHub) and that modern platforms (Cloudflare, AWS, Vercel) reduce default exposure.

What is the difference between Google Dorks and OSINT?

Google Dorks is one specific technique within OSINT (Open Source Intelligence). OSINT is the broad discipline of intelligence from open sources: social media, public records, TLS certificates, dorks, Shodan, leaks. Dorks are one tool in the box.

Are there tools that automate dorks?

Yes. Pagodo, GooGonk, theHarvester (partially), recon-ng (with Google Search modules) and various scripts. For intensive professional use, Google offers the Custom Search JSON API with reasonable quota. Free options run into CAPTCHA quickly.

Related resources

• What is OSINT: cycle, sources, tools: the broader discipline that includes Google Dorks as one technique among many.
• What is a penetration test: the technical methodology that follows footprinting when dorking detects an attackable surface.
• What is a CVE: vulnerabilities explained: how vulnerabilities a dork can help locate in exposed versions get identified.
• What is threat hunting and how it works: the defensive discipline that uses exposure information to build hypotheses.
• What is MITRE ATT&CK: tactics, techniques: where dork-based reconnaissance maps to the T1593 Search Open Websites/Domains technique.

Google Dorks at Secra

At Secra, Google Dorks are part of the standard footprinting in any Red Team and external pentest exercise. What an attacker can see of your organisation on Google is our starting point: forgotten documents, open panels, configuration files, exposed repositories, neglected subdomains. If you want to know what your public surface is showing or need a full exposure sweep (Google, Bing, Shodan, Censys, GitHub), get in touch through contact or check our Red Team service.