Before a penetration tester runs a single exploit, they spend a significant amount of time just watching. Collecting. Mapping. This phase is called reconnaissance — and the passive version of it is particularly interesting because you gather real intelligence about a target without sending a single packet to it.

I spent a session doing exactly that, targeting google.com using five different reconnaissance techniques: autonomous system lookup, Shodan searches, WHOIS queries, DNS enumeration with Sublist3r and Fierce, and SSL certificate inspection.

What came back was more than I expected. This article walks through everything I did and what each tool revealed.

What Is Passive Reconnaissance?

Passive reconnaissance means gathering information about a target using publicly available data sources — without directly interacting with the target's infrastructure. You are not scanning their servers, not sending probes, not triggering their IDS.

You are reading what they have already exposed to the internet.

This matters because:

• It leaves no logs on the target's systems
• It is fully legal when using public data sources
• It often reveals more than active scanning does
• It is how real threat actors build target profiles before an attack

The tools I used: HackerTarget, Shodan, whois (Kali Linux), Sublist3r, DNS Dumpster, Fierce, and SSLLabs.

Task 1: Finding the Autonomous System Number

Every large organization that controls its own internet routing has an Autonomous System (AS) — a collection of IP prefixes under unified routing control, identified by an ASN (Autonomous System Number).

Finding a target's ASN tells you exactly which IP ranges belong to them — which is the foundation for every subsequent search.

I started by pinging google.com to get an IP address:

ping google.com

This returned 142.250.202.110. I then fed that IP into HackerTarget's ASN lookup.

Result:

Google's AS15169 is one of the largest autonomous systems on the internet. The /15 CIDR range covers over 130,000 IP addresses — all belonging to Google's infrastructure.

Everything that follows uses this ASN and CIDR range to narrow searches specifically to Google-owned resources.

Task 2: Shodan — Finding Exposed Hosts

Shodan is a search engine for internet-connected devices. Instead of indexing web content, it indexes banners — the information that servers and devices return when you connect to them. It tells you what is running, what version it is, where it is, and sometimes what is misconfigured.

Search 1 — Hostname Filter

hostname:google.com

Result: 37,734 hosts matched the hostname:google.com filter. These are publicly reachable devices that identify themselves as part of Google's domain. Top countries: United States (12,722), United Kingdom (1,985), Canada (1,700). Top ports: 443 (25,024), 80 (5,165).

Search 2 — CIDR Subnet Filter

net:142.250.0.0/15

Result: 52,636 hosts within Google's allocated IP range. This is broader than the hostname search because it catches hosts that do not necessarily have a google.com hostname but are on Google's IP space.

Search 3 — Drilling Down to Microsoft IIS

This was an interesting finding. Within Google's own IP range, there are hosts running Microsoft IIS — Google's servers running Microsoft's web server. These are likely from acquired companies or partner infrastructure absorbed into Google's address space.

net:142.250.0.0/15 product:"Microsoft IIS httpd"

Result: 876 hosts running Microsoft IIS within Google's CIDR range.

Search 4 — Narrowing to IIS Version 10.0

net:142.250.0.0/15 product:"Microsoft IIS httpd" version:"10.0"

Result: 869 of the 876 IIS hosts are running version 10.0 specifically. Version 10.0 corresponds to Windows Server 2016/2019. The fact that 99% of the IIS hosts are on the same version suggests this is managed, consistent infrastructure — not random.

Search 5 — SSL Certificates on IIS 10.0 Hosts

hostname:google.com product:"Microsoft IIS httpd" version:"10.0" port:443

Result: 4 hosts with HTTPS certificates. The SSL certificates revealed common names (domain names) those certificates were issued for — including *.powiatmyszkowski.pl and wchop.org — third-party domains whose SSL certificates are cached in Shodan's index from Google's infrastructure. This is how Shodan's SSL indexing works: it captures certificate data regardless of which organization issued the cert.

NTP Server Search

NTP (Network Time Protocol) runs on port 123. Searching for Google's NTP infrastructure:

org:"Google" port:123

NTP Server Found: 34.102.13.166

Note: Searching within the CIDR range directly (net:142.250.0.0/15 port:123) returned no results — Shodan's free tier does not index NTP within that specific range. Searching by organization name instead returned 7,834 results including the NTP server detail.

Task 3: WHOIS — Reading the Domain Registry

WHOIS records store registration details for every domain name. In Kali Linux:

whois google.com

Key findings:

Technical Contact Email: Google uses MarkMonitor as their registrar with privacy protection enabled. The technical contact email is not publicly visible — it can only be requested through:

https://domains.markmonitor.com/whois/google.com

Authoritative Name Servers:

NS1.GOOGLE.COM
NS2.GOOGLE.COM
NS3.GOOGLE.COM
NS4.GOOGLE.COM

Google runs its own authoritative DNS — which means they have full control over all DNS resolution for google.com. No third-party DNS provider is involved.

Task 4: DNS Enumeration — Finding Subdomains

A domain like google.com has hundreds of subdomains, each potentially representing a different service, portal, or internal system. DNS enumeration tools find them without brute force — by querying search engines, certificate transparency logs, and public DNS data.

Sublist3r

Sublist3r queries multiple sources simultaneously: Google, Bing, Yahoo, Baidu, VirusTotal, and SSL certificate databases.

Installation and setup on Kali:

# Install Sublist3r
sudo apt install sublist3r

# Apply the VirusTotal API patch (required post-2023)
wget https://raw.githubusercontent.com/aboul3la/Sublist3r/3cb826c2f36f4972dfd286c704efc07de3a7f94c/sublist3r.py
sudo mv sublist3r.py /usr/lib/python3/dist-packages/sublist3r.py

# Set your VirusTotal API key
export VT_APIKEY="your-api-key-from-virustotal"

# Run the enumeration
sublist3r -d google.com -e google,yahoo,bing,virustotal,baidu,ask,ssl

Result: 2610 unique subdomains found.

5 particularly interesting subdomains I did not know existed:

From a penetration testing perspective, admin.google.com is immediately interesting — admin portals are always worth noting. actionscenter.google.com was genuinely unknown to me before running the scan.

DNS Dumpster — Domain Map

DNS Dumpster provides a visual map of a domain's DNS infrastructure: MX records, name servers, host records, and their IP addresses.

The map visualized dozens of hosts, name servers, and IP addresses branching out from google.com — making the scale of Google's DNS infrastructure immediately visible in a way that a raw list cannot.

Fierce — DNS Scanner

Fierce finds both subdomains and nearby IP space — hosts that share adjacent IP addresses with discovered subdomains, even if they have different hostnames.

fierce --domain google.com

Fierce identified the name servers first:

NS: ns2.google.com. ns3.google.com. ns4.google.com. ns1.google.com.
SOA: ns1.google.com. (216.239.32.10)

Wildcard: failure — Google does not use wildcard DNS entries, which means every subdomain that resolves actually exists as a real host.

Two hosts discovered with IP addresses:

Fierce also listed dozens of nearby IP addresses in the same /24 range — these are hosts at adjacent IPs that may or may not be Google infrastructure but are worth noting.

Task 5: SSL Certificate Inspection

SSL certificates are often overlooked as a reconnaissance source. But a single certificate can reveal dozens of hostnames that share the same certificate — effectively giving you a subdomain list without running any enumeration tools.

I used SSLLabs to inspect google.com's certificate:

https://www.ssllabs.com/ssltest/analyze.html?d=google.com

Certificate Details:

SSL Provider: Google Trust Services (Google runs its own Certificate Authority)

Alternative Names (DNS Names) in the Certificate — Selected highlights:

google.com
*.google.com
*.android.com
*.appengine.google.com
*.bdn.dev
*.cloud.google.com
*.crowdsource.google.com
*.datacompute.google.com
*.google.ca / *.google.cl / *.google.co.in / *.google.co.jp
*.google.co.uk / *.google.de / *.google.es / *.google.fr
*.googleapis.cn
*.googlevideo.com
*.gstatic.cn / *.gstatic-cn.com
*.recaptcha.net
*.widevine.com
*.ampproject.org / *.ampproject.net
*.google-analytics.com / *.googleadservices-cn.com
*.googleads-cn.com / *.googleapps-cn.com
*.doubleclick.net / *.doubleclick.cn / *.g.doubleclick.cn
*.dartsearch.net / *.googletraveladservices-cn.com
*.googletravelelabservices-cn.com / *.googletagservices-cn.com
*.googlesyndication-cn.com / *.googlesyndication.com
*.safeframe.googlesyndication-cn.com / *.app-measurement-cn.com
*.gvt1.com / *.gvt2-cn.com / *.googleflights-cn.net
*.admob-cn.com / *.gemini.cloud.google.com / *.googlesandbox-cn.com
*.safesvg.googlesandbox-cn.com / *.gstatic.com / *.metric.gstatic.com
*.grp.gvt2.com / *.url.google.com / *.youtube-nocookie.com
*.stmg.com.ai / *.android.com / *.flash-android.com
*.google-analytics.com
youtube.be / youtube.com / *.youtube.com
youtu.be / music.youtube.com
youtubeeducation.com / *.youtubeeducation.com / *.youtubekids.com
android.com / chrome.google.cn / developers.google.cn / aistudio.google.com

One certificate. Dozens of domains. *.widevine.com, *.ampproject.org, *.recaptcha.net, *.doubleclick.net — all secured by the same certificate that google.com uses. This is a wildcard multi-SAN certificate covering Google's entire product ecosystem.

From a reconnaissance standpoint, this is gold: one certificate inspection just revealed the scope of Google's entire internet-facing surface.

Putting It All Together — The Reconnaissance Picture

After running all five tasks, here is what I know about google.com without having sent a single probe to their servers:

A real attacker would use this picture to decide which entry point to prioritize. admin.google.com and actionscenter.google.com would be noted. The IIS hosts within Google's range would be checked for version-specific vulnerabilities. The certificate's SAN list would be cross-referenced against the subdomain list for gaps.

How to Run This Yourself

All tools used here are free and available in Kali Linux or as online services:

# ASN lookup — use your target's IP
# HackerTarget: https://hackertarget.com/as-ip-lookup/

# Shodan searches (free account required)
# hostname:target.com
# net:a.b.c.d/n
# net:a.b.c.d/n product:"Microsoft IIS httpd"
# org:"Target" port:123

# WHOIS
whois target.com

# Sublist3r
sudo apt install sublist3r
export VT_APIKEY="your-virustotal-key"
sublist3r -d target.com -e google,yahoo,bing,virustotal,baidu,ask,ssl

# Fierce
fierce --domain target.com

# SSL certificate inspection
# https://www.ssllabs.com/ssltest/

What I Learned

The surface is larger than it looks — Before this exercise, I thought of google.com as a single domain. After it, I see a network of thousands of hosts, 2,610 subdomains, and 50+ domains on one certificate. The attack surface of even a well-defended organization is enormous.

Shodan sees things you would not expect — Finding Microsoft IIS servers inside Google's own IP range was unexpected. Acquired companies and absorbed infrastructure leave traces that Shodan captures.

WHOIS privacy is not total — Even with privacy protection on the registrar side, you still get name servers, creation dates, registrant country, and DNSSEC status. Enough to profile the registration history.

SSL certificates are an underrated recon source — Most people inspect certificates to check for expiry or misconfiguration. But the SAN (Subject Alternative Name) list is a reconnaissance gift — it maps the scope of the organization's certificate infrastructure in one lookup.

Wildcard failures are meaningful — When Fierce reported Wildcard: failure for google.com, that is actually useful information. Google does not use wildcard DNS, which means every subdomain that resolves is a real, intentionally deployed host.

Common Mistakes in Passive Reconnaissance

Conclusion

Passive reconnaissance is one of the most information-rich phases of a penetration test, and it requires no special access, no exploits, and no risk of detection. Everything in this article came from public data sources that anyone can query.

The five-tool approach I used — ASN lookup, Shodan, WHOIS, DNS enumeration, and SSL inspection — gives you a layered picture of a target: their network boundaries, what they are running, how they manage DNS, where their subdomains live, and what their certificate covers.

Before you run a single scan, know what you are looking at.