- Joined
- 22 May 2026
- Messages
- 9
- Reaction score
- 6
- Points
- 3
Passive reconnaissance plays an important role in the approach of a target. In comparison to the active reconnaissance, passive reconnaissance is the silent, stealthy one, where the attacker doesn’t interact with the target. Instead, they obtain target information based on external, third party soucres. Such a source are search engines.
In the following article, I list two of the most popular ones, namely Google Search and Shodan, as well as some techniques I use to discover more attack surface. I would love to also include Github Search but my limited experience with it doesn’t allow me that. Maybe in a future article? I hope.
With using Google search as a passive recon tool comes also Google dorking. Google dorking is the technique of making more specific queries to Google Search based on filters and restrictions defined by the user, so that the search engine returns more concrete results. It includes filters of the form
filter:value
and logical operators between the filters
filter:value [OPERATOR] filter:value
or
[OPERATOR]value
site:example.com -www
will ask Google to return results from every subdomain of example.com known to it, except for www.example.com. This is a good query to use for additional subdomain discovery, in case your automation missed any subdomains.
site:example.com inurl:src
returns results with the parameter src in the url, like e.g. https://example.com/css_src.php?src=. Then later, the endpoint can be analyzed for possible vulnerabilities, especially if the parameter has a name that points to specic vulnerabilities like e.g. the parameter return points to Open Redirections.
intitle:"Dashboard [Jenkins]" site:example.com
will return a public Jenkins instance belonging to example.com, if there is any.
"-----BEGIN RSA PRIVATE KEY-----" inurl:id_rsa
To be more creative, we can construct or own query for targeting files with sensitive inormation. Combining some of the above mentioned filters, we can come up with
site:*.target.com ( filetype:TYPE1 | filetype:TYPE2 ) intext:SECRET
where SECRET is the target secret we want to test/uncover, e.g. password and TYPE1/TYPE2 the filetype that is possible to contain such a secret, e.g. pdf or txt or ppt. Of course, both SECRET and TYPE1/TYPE2 may be depending on the target. For a company that has a billing process, SECRET may be invoice or receipt and for a, let’s say, contract reviewing company, the pdf and docx TYPE may be more possible to return any results.
Note that google dorking may return false negatives. That means that even if there is no result yielded from a query, that doesn’t mean that it doesn’t exist. Google’s search engine takes some time to update it’s search results, if the website is new or developers prevent google from crawling their website by including a noindex meta tag in the page’s HTML code, or by returning a ‘noindex’ header in the HTTP request.
There are a lot of filters and operators to use for google dorks, so here is also some other lists with the available options:
site:subdomain.target.com
Google provided me links and relative paths of that subdomain that my wordlists missed. That led me to a web application deployed on that server, where I found an endpoint, which was vulnerable to XSS and another endpoint vulnerable to frame injection. Note that the endpoints that Google yielded weren’t included in the gau and waybackurls results.
site:subdomain.target.com inurl:rt
I found an endpoint, vulnerable to open redirection, which I then escalated to XSS.
In the following article, I list two of the most popular ones, namely Google Search and Shodan, as well as some techniques I use to discover more attack surface. I would love to also include Github Search but my limited experience with it doesn’t allow me that. Maybe in a future article? I hope.
Google Search
The use of Google Search has been increased with the time, as it is a very easy way to discover not only hidden information lying around the web but also a quicker way to identify possible vulnerable domains and endpoints.With using Google search as a passive recon tool comes also Google dorking. Google dorking is the technique of making more specific queries to Google Search based on filters and restrictions defined by the user, so that the search engine returns more concrete results. It includes filters of the form
filter:value
and logical operators between the filters
filter:value [OPERATOR] filter:value
or
[OPERATOR]value
Filters and Operators
There are many filters that one can use with Google dorks. Some filters and operators that come handy when hunting for bugs:- site
Yields results from the specified site/domain, e.g. site:example.com - inurl and allinurl
Yields results that have the specified string in their URL, e.g. inurl:cmd and allinurl:cmd execute - related
Yields results related to the specified site/domain. It’s useful for finding an organization’s aquisitions. E.g. related:randstad.com returns results from companies’ domains, like monster.com, which belongs to Randstad. - filetype
Yields results and endpoints from the specified filetype, e.g. filetype:pdf - intitle and allintitle
Yields results with the specified title, e.g. intitle:Organisation intitle:Internal or allintitle:Organisation Internal - intext
Yields results where the specified string was found within the text of a result, e.g. intext:password - AND
Logical AND operator to combine filters, e.g. site:example.com AND filetype:pdf - OR, |
Logical OR operator to combine filters, e.g. site:example.com OR site:target.com or site:example.com | site:target.com - -
Exception operator that is to be used before a filter, e.g. site:example.com -site:www.example.com will yield results from subdomains of example.com except for www.example.com. Also -inurl:www and -www can be used. - *
Used as a wildcard, e.g. site:www.example.*
Subdomain discovery
The simple querysite:example.com -www
will ask Google to return results from every subdomain of example.com known to it, except for www.example.com. This is a good query to use for additional subdomain discovery, in case your automation missed any subdomains.
Content discovery
The querysite:example.com inurl:src
returns results with the parameter src in the url, like e.g. https://example.com/css_src.php?src=. Then later, the endpoint can be analyzed for possible vulnerabilities, especially if the parameter has a name that points to specic vulnerabilities like e.g. the parameter return points to Open Redirections.
Discovering technologies open to the public
Targeting specific technologies can be done through the intitle filter. The queryintitle:"Dashboard [Jenkins]" site:example.com
will return a public Jenkins instance belonging to example.com, if there is any.
Secret discovery
In the exploit-db.com collection there is a large number of Google dorks queries for uncovering secrets and information on a target, like e.g. discovering private keys with the query"-----BEGIN RSA PRIVATE KEY-----" inurl:id_rsa
To be more creative, we can construct or own query for targeting files with sensitive inormation. Combining some of the above mentioned filters, we can come up with
site:*.target.com ( filetype:TYPE1 | filetype:TYPE2 ) intext:SECRET
where SECRET is the target secret we want to test/uncover, e.g. password and TYPE1/TYPE2 the filetype that is possible to contain such a secret, e.g. pdf or txt or ppt. Of course, both SECRET and TYPE1/TYPE2 may be depending on the target. For a company that has a billing process, SECRET may be invoice or receipt and for a, let’s say, contract reviewing company, the pdf and docx TYPE may be more possible to return any results.
Note that google dorking may return false negatives. That means that even if there is no result yielded from a query, that doesn’t mean that it doesn’t exist. Google’s search engine takes some time to update it’s search results, if the website is new or developers prevent google from crawling their website by including a noindex meta tag in the page’s HTML code, or by returning a ‘noindex’ header in the HTTP request.
There are a lot of filters and operators to use for google dorks, so here is also some other lists with the available options:
| Google dorks resources |
|---|
| Google dork cheatsheet |
| Google Search Operators: The Complete List (42 Advanced Operators) |
| google-dorks |
| Listing of a number of useful Google dorks. |
Case study: Content discovery
As mentioned before, you can use Google dorks to identify possible vulnerablities. While I was hunting for bugs in a target, I came across a vanilla Apache server in subdomain.target.com, where I first thought that there was no content at all. By using the very simple querysite:subdomain.target.com
Google provided me links and relative paths of that subdomain that my wordlists missed. That led me to a web application deployed on that server, where I found an endpoint, which was vulnerable to XSS and another endpoint vulnerable to frame injection. Note that the endpoints that Google yielded weren’t included in the gau and waybackurls results.
Case study: Vulnerable parameter
While this requires a lot of time, one can search for possible vulnerable parameters in web applications with the inrul filter. With a list of parameters one can test the existance of those parameters, which may be possible to be vulnerable to some kind of an attack. In this case, using a list of common open redirection parameters and with the querysite:subdomain.target.com inurl:rt
I found an endpoint, vulnerable to open redirection, which I then escalated to XSS.
