Passive Recon using Google Dorks and Shodan - Bug Hunting

Passive Recon using Google Dorks and Shodan - Bug Hunting

  April 17, 2022    Davinder

---

During bug bounty or hacking.. I always try to find more and more tricks to enumerate for my target domain. So most of the times I love to find free information on google using dorks and Shodan. So I will tell you how we can find very juicy information which I use to broaden my attack surface by finding more (potentially vulnerable) assets and uncovering secrets. 

Google Search

Google already have lots of information but to get information about our target we need to follow some tricks. So we use google dorking which is a 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

Some easy to use filters are

site:example.com

nurl:cmd and allinurl:cmd execute

related:randstad.com returns results from companies’ domains, like monster.com, which belongs to Randstad.

filetype:pdf

intitle:Organisation intitle:Internal or allintitle:Organisation Internal

intext:password

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.

Lets try some practical approach

site:example.com inurl:src

returns result with the parameter src in the url, like e.g. https://example.com/css_src.php?src=. Then later, the endpoint can be analysed for possible vulnerabilities, especially if the parameter has a name that points to specific vulnerabilities like e.g. the parameter return points to Open Redirections.

Now if we try to find Dashboard for Jenkins . We can do that like

intitle:"Dashboard [Jenkins]" site:example.com

This will return a public Jenkins instance belonging to example.com, if there is any.

Many more info about google dorkings can be found at exploit-db.com which contains large number of Google dorks queries for uncovering secrets and information on a target, like e.g. discovering private keys with the query

Now lets talk about SHODAN and how we can use it to find relevant information about our target

This project  collects information about web servers such as open ports, services running on those ports and their banners. 

To use Shodan , we need paid account then only you can explore to the highest level. To use it we also need to use tricks as we use google dorks. So below are some of the ways how we can use this search engine.

http.status

Returns the servers with the specified http status code, e.g. http.status:200.

http.title

Queries for the specified http title that can be found in the banners. A distinctive example is the shodan dork used to find BIG IP vulnerable components: http.title:"BIG-IP®- Redirect".

http.component

Returns servers with the specified web technology that is used on the website, e.g. http.component:"jenkins".

ssl

Finds servers with the specified string included in the SSL certificate, e.g. ssl:"Microsoft". This Filter can be further specified with ssl.expired, ssl.version (more on the resources).

org

Finds servers with IP belonging to the specified organization’s netblock, e.g., org:"Microsoft"

port

The port filter returns components with the specified port open, e.g. port:8080.

os

Using this filter shodan returns servers running the specified operating system, e.g. os:Windows.

product

Using this filter shodan returns devices running this specific product, e.g. product:"Apache Tomcat" or product:"IIS Windows Server"

version

The version filter is to be combined with the product filter. It specifies the version of the specified product, e.g. product:"Apache Tomcat" version:"7.0.82"

vuln

This filter is only available to academic users or Small Business API subscriptions and higher. It’s used to to return components vulnerable to the specified CVE identifier, e.g. vuln:cve-2010-2730.

Conclusion

Using search engines for passive reconnaissance, either that is endpoint or secret or subdomain discovery, requires a lot of digging and can take some time. But when it comes to bug hunting, the more digging a bug requires the more probable it is to not be a dupe. Testing out the filters and creating unique and creative queries is the key.