My First Passive Reconnaissance Using Shodan | My Application Security Journey

Introduction

As I continue my application security journey, I'm learning that securing an application involves more than just looking at its code. It also means understanding the environment in which it runs and the information it exposes to the internet.

As part of my hands-on learning, I decided to explore Shodan, a search engine that helps users discover internet-connected systems and learn about the services they expose.

For this exercise, I used Shodan to carry out passive reconnaissance.

My goal was to understand how to gather information about a target using publicly available records without directly scanning or interfering with its systems.

In this article, I'll share my approach, some of the findings I observed, and the lessons I'm taking away as I grow in application security.

What Is Passive Reconnaissance?

Before starting the practical exercise, I wanted to understand the concept behind the task.

Passive reconnaissance is the process of collecting information about a target from existing sources without directly testing or probing its systems.

For application security, this can help build an initial understanding of the infrastructure and services connected to an application before an authorized assessment begins.

For this exercise, I used information already available through Shodan. I did not attempt to exploit vulnerabilities, access private systems, or run direct scans against Google's infrastructure.

The Tool I Used: Shodan

Shodan is a search engine for internet-connected devices and services.

Depending on the information available, it can display IP addresses, hostnames, open ports, server responses, and details about security certificates.

These details can help security professionals understand how systems appear from the outside.

I accessed Shodan through its website and used the search query:

hostname:google.com

This allowed me to review records associated with Google's domain.

I then opened some of the returned results to examine the information they contained.

What I Found

1. Multiple IP Addresses and Hostnames

One of the first things I noticed was that the results contained multiple IP addresses.

Some of the addresses shown in my results included:

• 142.251.179.101
• 172.253.63.121
• 216.239.35.4

I also noticed hostnames ending in 1e100.net and other names associated with Google services.

This helped me understand that a large online service can have many IP addresses and hostnames associated with its infrastructure.

From an application security perspective, this is useful context. Applications depend on infrastructure and supporting services, so understanding how they are exposed can help security professionals build a clearer picture of the environment surrounding an application.

2. Organization Information

Several of the records identified Google LLC, while another listed Google Ireland Limited.

This showed me that Shodan can provide information about organizations associated with internet-facing systems.

However, I also learned not to assume that every result belongs directly to the main website or serves the same purpose.

In application security, careful identification of the target is important. Before making claims about an application or its infrastructure, the available evidence needs to be understood and verified.

3. Understanding the 404 Error

Several records displayed the response:

HTTP/1.1 404 Not Found

A 404 response generally means that the requested resource was not found.

At first, an error message like this might seem like a problem, but it does not automatically mean that a website is broken or vulnerable.

This was a useful lesson because application security involves understanding how applications respond to requests, including normal responses and errors.

The meaning of an error depends on the context in which it occurs.

4. Exploring Security Certificates

Some of the results contained security certificate information for Google-related domain names, including *.google.com and *.googleusercontent.com.

Several records listed Google Trust Services as the certificate issuer.

Security certificates help websites establish their identity and support encrypted connections between clients and servers.

I also noticed an unusual record associated with the IP address 156.252.125.216. Although the record is listed google.com as a hostname, its certificate information names Apextech LLC as the organization.

Rather than treating this as proof of a vulnerability or security incident, I considered it an observation that would require further verification.

This reminded me that application security is not about jumping to conclusions. It is about collecting evidence, understanding what it means, and verifying potential concerns before reporting them.

5. Discovering a Supporting Network Service

Another result associated the IP address 216.239.35.4 with time2.google.com and displayed information about NTP, a service used for network time synchronization.

This was interesting because my initial focus was on a website, yet the results also showed information about a supporting network service.

It helped me appreciate that understanding an application's surrounding environment can be useful when learning how applications operate and how their exposure can be assessed.

What This Means for My Application Security Journey

This exercise helped me connect reconnaissance with the broader process of securing applications.

Here are some of the lessons I learned:

• Understand the environment: Applications depend on servers, network services, and other supporting infrastructure.
• Learn to read technical information: IP addresses, hostnames, server responses, and certificate details can provide useful context.
• Do not confuse observations with vulnerabilities: An open service or an error message is not automatically a security weakness.
• Verify unusual findings: Unexpected information needs further investigation before conclusions can be made.
• Respect the scope: Discovering a publicly visible system does not automatically give anyone permission to test it.

Although this exercise focused on passive reconnaissance rather than testing application code, it gave me a useful foundation for understanding the information that may be available before an application security assessment.

Challenges and Limitations

One challenge was understanding what the returned information actually meant.

Some records contained multiple hostnames, while others displayed error messages or certificate details that required careful interpretation.

I also learned that Shodan's results may not represent the current state of a system or include every asset associated with a domain.

Because of these limitations, my observations should not be treated as a complete security assessment of Google or as evidence of confirmed vulnerabilities.

What's Next?

This exercise is one step in my application security journey.

As I continue learning, I want to build on these foundations by exploring how applications handle requests, manage authentication, validate user input, and protect sensitive information.

I also plan to practice application security testing in deliberately vulnerable labs where I can safely learn how to identify and understand common web application vulnerabilities.

My goal is to move from simply discovering information to understanding how applications can be assessed, secured, and improved.

Conclusion

My first passive reconnaissance exercise using Shodan was a valuable learning experience.

I learned how to search for hostnames, review IP addresses, interpret server responses, and examine security certificate information.

More importantly, I learned that application security begins with understanding the system being assessed and interpreting evidence carefully.

I'm documenting these practical exercises as I progress, one concept at a time.

This is another step in my application security journey, and I'm looking forward to building on what I've learned.

Disclaimer: This article documents an educational exercise based on information displayed by Shodan. It does not claim to identify confirmed vulnerabilities in Google or provide a complete assessment of Google's security.