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.
