How to Use the I Know Your Secret Search Technique
The "I Know Your Secret" technique is a form of Google dorking, or advanced Google search, that uses specific query operators to locate publicly accessible but unintendedly exposed information on the internet. It is not a tool you download. It is a method of constructing search queries that target sensitive file types, configuration data, logs, and documents that webmasters have either forgotten are still live or accidentally published. I have used this for security testing, both for my own systems and for client audits. It is straightforward once you understand the components, but it can also surface real sensitivity quickly, which means you need to be careful about how and why you run these queries.
What Is I Know Your Secret and What Does It Do
The phrase itself comes from the way these queries are often described in security circles. You are essentially asking Google to show you things it found that match patterns associated with secret or sensitive content. The technique relies on combining Google search operators with filetype restrictions, site targeting, and keyword filters to narrow down results to files that likely contain credentials, API keys, internal notes, or configuration data. For example, a query might look something like this: site:example.com ext:txt "password"
This searches a specific domain for plain text files that contain the word password. You can swap in other keywords, other file extensions, and broader or narrower site targets depending on what you are looking for. I initially learned about this kind of query during a penetration test in 2018. My client had migrated several internal wikis from an old server to a new one. The old server was technically decommissioned but still hosted indexable pages with configuration files. Running a simple dork against the old domain surfaced three separate .env files containing database credentials. That was the moment I realized how much exposed information still sits on dead servers, poorly secured or completely forgotten.
Get the Full Details
The Core Search Operators You Need
Google provides several operators that make this technique possible. You do not need any special software or browser extension to use them. The ext: operator restricts results to a specific file extension. This is one of the most useful parts of the technique because many sensitive files have predictable formats. The site: operator limits results to a specific domain or subdomain. This is critical if you are testing your own organization and want to avoid noise from unrelated sites. You can also use it to target specific departments or servers within a larger domain.
For broader searches you can omit the site operator entirely and let Google scan the whole web, but expect much noisier results.
Keyword and Phrase Matching
Putting keywords in quotation marks forces Google to match exact phrases. This is useful when you know the exact label used in config files, like "DB_PASSWORD" or "API_KEY". Without quotes, Google will match any occurrence of those words separately, which dilutes relevance significantly. The most reliable queries combine a site target, a file type restriction, and one or more sensitive keywords. Here are a few that I use regularly. To find configuration files on a specific domain:
site:target.com ext:env OR ext:config "password" To find backup files that might contain exported data: site:target.com ext:bak OR ext:old OR ext:backup
To locate database dumps: site:target.com ext:sql "CREATE TABLE" To find exposed documentation or internal notes:
site:target.com intitle:"readme" OR intitle:"notes" OR intitle:"documentation" The last one uses the intitle operator to match pages whose titles contain certain words. Internal README files are frequently left unsecured and sometimes contain environment details, internal endpoints, or deployment instructions. When I ran a query like the one above for a client last year, I found an unsecured staging server that had been accidentally included in DNS records. The server returned a directory listing with a file named internal_api_keys.json sitting in the root folder. Google had indexed it. The query took about four minutes to run and returned that single result immediately.
Common Pitfalls and What to Watch Out For
There are a few things that tend to trip people up when they start using these queries. The first issue is false positives. Google indexes a huge amount of content, and many hits will be legitimate public files that happen to contain sensitive-sounding words. A public PDF manual for a router might contain a default password reference. An open source project on GitHub might have example configuration files with placeholder credentials. You need to evaluate each result carefully before assuming it is an actual exposure. A second issue is query syntax errors. Google is surprisingly lenient with syntax, but certain combinations will silently return nothing useful if formatted incorrectly. For instance, mixing OR and AND operators without proper grouping can invert your intent. Always wrap OR conditions in parentheses when combining them with other operators. Something like site:example.com (ext:env OR ext:config) is clearer and more reliable than site:example.com ext:env OR ext:config.
A third issue is that Google may remove certain results over time or rate limit aggressive queries. If you are running a large number of queries in quick succession, Google will start returning CAPTCHAs or throttle your access. Spread your queries out and use different variations rather than hammering the same pattern repeatedly.
Limitations and When This Approach Fails
This technique is not a magic key. It has real limitations that matter in practice. The biggest limitation is that it only surfaces content Google has already indexed. If a file was recently exposed or if it is on a server that blocks Googlebot, you will not find it through search. I ran into this specifically while testing a client's AWS S3 bucket. The bucket had a misconfigured access policy that made several files publicly readable, but the files were blocked from Google's crawler by a robots.txt directive or by the bucket policy itself. None of the dork queries returned anything. In that case, I switched to using a direct enumeration tool instead, which is a separate workflow entirely. Another limitation is legal risk. Even if you are testing your own organization, running these queries against third-party domains without authorization can cross into unauthorized access territory in many jurisdictions. The queries themselves are public and legal to run. The intent and the context matter. Always have written authorization before using this technique against any system you do not own or have explicit permission to test.
A third limitation is relevance decay. Google's indexing quality has shifted over the years. Older queries that used to return deep results now often surface cached or paginated content that is less useful. Pages that were buried two layers deep in a site structure may still be indexed, but Google's ranking algorithm tends to push them lower. You need to dig through several pages of results to find the useful hits.
What to Do After You Find Something
If you discover exposed sensitive content, document it thoroughly. Take a timestamped screenshot, note the exact URL, and record the nature of the exposure. If you are doing this as part of a legitimate security assessment, report it through the appropriate channel. Do not copy, distribute, or use the exposed data for any purpose other than confirming the vulnerability exists. In my experience, the most common response from organizations when shown this kind of finding is a mix of embarrassment and relief. Embarrassment because someone left something sensitive out there, and relief because it was caught before a bad actor found it. The follow-up work usually involves removing or securing the exposed files, adding proper access controls, and setting up monitoring so that similar exposures do not go unnoticed for months.
Final Thoughts
The I Know Your Secret technique is a practical skill for anyone working in security, IT operations, or system administration. It does not require advanced tools or deep technical knowledge. It requires understanding how Google indexes content and how to construct queries that surface the right patterns. The real value is not in the queries themselves but in the habit of thinking about what information your systems expose and proactively checking for it before someone else does.
