Passive Reconnaissance on google.com — What I Found Using Shodan, WHOIS, and DNS Tools

Passive Reconnaissance on google.com — What I Found Using Shodan, WHOIS, and DNS Tools



Tópico: Passive Reconnaissance on google.com — What I Found Using Shodan, WHOIS, and DNS Tools
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
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:

Field
Value

ASN
AS15169

Organization
Google LLC

CIDR Range
142.250.0.0/15

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:

Field
Value

Registrar
MarkMonitor Inc.

Registry Domain ID
2138514_DOMAIN_COM-VRSN

Creation Date
1997-09-15

Expiry Date
2028-09-14

Registrant Country
US

DNSSEC
unsigned

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:

Subdomain
Why It Is Interesting

actionscenter.google.com
Admin/developer portal for Google Actions — not a well-known endpoint

actualities.google.com
Internal news or content service — not publicly documented

admanager.google.com
Google's advertising management platform

admin.google.com
Google Workspace admin console — high-value target if accessible

admob.google.com
Google's mobile advertising platform

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:

Host
IP Address

1.google.com
142.250.202.78

about.google.com
142.250.200.174

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:

Field
Value

Grade
B

Certificate Type
EC 256 bits (SHA256withECDSA)

Issued by
WE2 (Intermediate) → Google Trust Services LLC

Valid from
Mon, 23 Feb 2026 18:19:56 UTC

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:

Recon Layer
What I Found

Network layer
ASN AS15169, CIDR 142.250.0.0/15, 52,636+ hosts

Server fingerprinting
876 hosts running Microsoft IIS 10.0 within Google's range

Registration data
Registered 1997, MarkMonitor registrar, 4 self-managed name servers

DNS surface
2,610 unique subdomains including admin portals and internal services

Certificate surface
50+ domains and wildcards on a single certificate

Time infrastructure
NTP server at 34.102.13.166

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


Mistake
What to Do Instead

Stopping at the first IP address
Look up the full ASN and CIDR range — there may be thousands of hosts

Ignoring IIS on non-Microsoft organizations
Acquired infrastructure leaves unexpected server fingerprints

Treating WHOIS privacy as complete opacity
Organization name, country, name servers, and dates are usually still visible

Using only one subdomain enumeration tool
Sublist3r, DNS Dumpster, and Fierce return different results — use all three

Skipping SSL certificate inspection
SAN lists reveal the full domain scope of an organization's certificate

Searching CIDR range for NTP directly
Some protocols require searching by org name instead of IP range in Shodan



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.