This article explores the basics and core aspects of OSINT from a reconnaissance perspective. Mainly, the core basic passive methodology of reconnaissance, in which we map out the entire public facing infrastructure of any company to further carry on our testing on the target, or discover some low hanging fruits in the process, if we stay highly attentive to what we discover during our analysis.

Why go passive?

The quieter you become, the more you are able to hear

Because Active testing is always somewhat noisy and often the client's service whom we maybe testing for, may go down, if say, researcher X decides to automate and hyper-thread his Scan with a large bandwidth at his disposal. Furthermore, that leads to say, a few hundreds of concurrent connections to the client's web server at any given time. Now, let's say, this makes the web server reach the maximum amount of requests that it can handle, making it crash or, go down, thus causing an unintentionally caused period of server downtime, that may put us at risk, and even behind the bars for the worst. Thus, it might be clear to one that Passive recon wins over Active recon in such cases when we might unintentionally cause DoS due to it's rigorous activity.

Also, at times, Active recon misses out a few things, which passive utilities might pick up, making the Passive-style impactful and effective. For example, we may miss files which had been earlier indexed by Google, and in the process of forced browsing still missed them somehow – Using Google Advanced Search techniques we may discover such things at ease, or maybe just take a look at the latest SnapChat $15,000 Report on Hackerone.  Just think of it, passive recon techniques can land you into situations where you come across a wealth of sensitive information lying around in some corner of the web, untouched, or not yet discovered, such as Token leaks. Which in the SnapChat reporter's case, he found them indexed almost 7 hours ago by Google, and finding them alone fetched him $15,000.

Cons

It might seem quite obvious here, though Passive recon can be done faster, and hence we save time, but there is nothing better than direct interaction with the target, and establishing connection with the target server. But with this great power we gain over the target, comes a huge responsibility of throttling our network requests and testing in a good manner. For example, at times, a full port scan is the most feasible option when external sources like Censys don't capture our targets ports/services.

Some thoughts on Passive Reconnaissance Methodology

Our utmost priority would be to map out our target as usual, and leave no stone unturned to see if any service that runs on our target's end is vulnerable to some sort of publicly known attack vector. Once we do that, we maybe in a comfortable position to decide the next course of action to follow i.e. to  -

Explore the service by yourself by intercepting each and every network request and maybe send it to Burp (save it in a state file to further perform analysis at a later date/time), analysing the endpoints available in the service or, frontend application on top of the service, to see if something is mal-configured, can we associate this methodology in reality? Yes, Rojan Rijal, a security researcher got a big payout of $5000 from Shopify after reporting such a vulnerability, which enabled him to leak (arbitrary) internal data when he hit across such an endpoint during his recon activity - all he did was, statically analyse the endpoints revealed in the HTTP response body, or, the HTML document itself along with its client-side scripts( use Linkfinder to get hold of endpoints inside client-side scripts, which was recommended by Prateek Tiwari as well who consistently stayed at the Top of Zomato Bug Bounty Program on Hackerone)

So, what, how and why recon? Here are some key takeaways -

Ways in which you can gain the most out of a Passive Recon -

• Just try to grab as much information you can get about your target. Not only the hostname, try to figure out if similar domains exist, For example, let's take the case of an F500 company X, whose internal infrastructure (mainly subdomains) I was trying to discover. Almost every public facing service having a frontend appeared to be firewalled aggressively and hence it returned a 503 error status code following each request I sent to them. What I did uptil now was simply use Knockpy which in turn used the Virustotal API, and also tried to perform zone transfer to figure out subdomains(if possible). Hence, I used crt.sh, using a simple query of  "target-org-name" I enumerated all domains directly/indirectly related to them. After querying through crt.sh, I finally hit across a particular domain - jenkins-(target-org-name).us which was particularly interesting and presto! It returned 200 status code as well. The Jenkins Dashboard opened up next, I was able to Sign Up/Sign In as well as run groovy scripts. Hence, I achieved my target by merely enumerating some domains through crt.sh.

So, we know now how to enumerate public facing infrastructure which is out of our glance but still not properly firewalled and sometimes vulnerable. It covers one of the first and foremost objectives of System Penetration Testing -  Enumeration.

Let's dive deeper into how we can further exploit upon the attack surface that we have just discovered.

• Static Analysis of HTML document retrieved from Internal Dashboard(s) on our Target's service's frontend application to understand it's internals/to simply figure out how it functions atleast. This is a key aspect from the Blackbox testing perspective. This helps you better understand the general flow of the application.
• Using LinkFinder( a tool made by a friend and security researcher, Gerben Javado) that uses regexp to dig out endpoints from client-side scripts. These endpoints can be a goldmine of goldmine of Vulnerabilities since, usually many sensitive administrative functionalities may not have protection against privilege escalation flaws, hence any authenticated user can perform an administrative action using an endpoint like say, /delete/{user} which may have been revealed from the client-side scripts. Suppose the researcher finds out that any average authenticated user with no extra privileges like that of a moderator or, admin can thus delete any user by simply sending a POST request to this endpoint /delete/{user}, this would be a serious case of a privilege escalation vulnerability that would require immediate attention and fix. Many such cases have been found in real life in companies like Zomato, refer to their Public Disclosures on Hackerone.- Using external services like   crt.sh, which mainly tries to search or, establish related hostnames by correlation between Server Certificates.  
• Findsubdomains.com is an excellent solution to find subdomains for the target domain which you are scanning, even if something's out of scope maybe, you hit across an entire subdomain takeover, or, some critical information disclosure which maybe hard for the target company to not reward. Plenty of possibilities in short.   censys.io can help you further discover services running at your target's end. For example, a mis-configured or, an insecure/unsecured public Jenkins instance, the impact ranges between an RCE(using terminal plugins, or, groovy script) and Source Code disclosure. Censys is one of the best search engines for hackers. Because it indexes almost every IP range here on the WWW, so it becomes easy to map out the services which are part of the infrastructure if your target. It also provides an API to query data using your scripts.  
• Censys.io can help you further discover services running at your target's end. For example, a mis-configured or, an insecure/unsecured public Jenkins instance, the impact ranges between an RCE(using terminal plugins, or, groovy script) and Source Code disclosure. Censys is one of the best search engines for hackers. Because it indexes almost every IP range here on the WWW, so it becomes easy to map out the services which are part of the infrastructure if your target. It also provides an API to query data using your scripts.

Some other useful tools for domain and sub-domain enumeration, and gain information about our target

• Google (Using Advanced Search techniques commonly referred to as dorking, for example - site:target.com)
• http://searchdns.netcraft.com/
• https://censys.io/ (Extremely useful if you know some tricks)
• https://dnsdumpster.com/
• https://virustotal.com/ (It also helps you find some sensitive data leaks as well related to the target)

PART TWO COMING SOON!