Information Gathering

Before an attacker exploits a vulnerability, they need to know what they are dealing with.

A domain name can lead to an IP address. An IP address can reveal a reachable host. A web server can disclose its software and version. Public pages can expose email addresses and information about the people behind an organization.

None of these findings necessarily represents a vulnerability on its own. The problem is what happens when they are combined.

Information gathering, or reconnaissance, is the process of collecting those pieces before moving deeper into an attack. The more an attacker can learn without triggering a defense, the less uncertainty they have when deciding what to investigate next.

In this chapter, we will perform reconnaissance against scanme.nmap.org, a host intentionally provided by the Nmap project for security testing and experimentation. We will start with basic connectivity and DNS information, then move into domain registration data, technology fingerprinting, email discovery, and a custom email scraper.

The objective is simple:

See how much information can be assembled before exploiting anything.

Why Information Gathering Matters

An attacker rarely starts with an exploit. They start with questions:

What is this target?
Where is it hosted?
What addresses does it resolve to?
What technologies are running?
Who is associated with the organization?
What information is already exposed publicly?

Every answer reduces uncertainty. That matters because exploitation is rarely about blindly trying random attacks. The information collected during reconnaissance helps determine which systems, services, technologies, accounts, and people are worth investigating next.

Consider the difference between these two situations.

An attacker knows only:

nmap.org

After reconnaissance, they may know:

Domain
    ↓
DNS records
    ↓
IP addresses
    ↓
Web server
    ↓
Server software and version
    ↓
Operating system clues
    ↓
Public email addresses
    ↓
People and identities

The target has not necessarily become more vulnerable. But it has become less unknown. That is the value of reconnaissance.

How Reconnaissance Works

Reconnaissance can broadly be divided into two approaches:

Active reconnaissance

Active reconnaissance involves directly interacting with the target. The target may receive packets, DNS queries, HTTP requests, or other traffic generated by the investigation.

Examples include:

• ping
• nslookup
• service and port scanning
• web technology fingerprinting

The advantage is that active techniques can provide direct and current information. The tradeoff is visibility: the target or its monitoring systems may be able to see that someone is interacting with it.

Passive reconnaissance

Passive reconnaissance attempts to gather information without directly interacting with the target whenever possible.

This can include:

• public domain information
• search engines
• public databases
• third-party intelligence platforms
• information already published on websites
• publicly available documents and identities

The advantage is that much of the investigation happens outside the target's infrastructure. For an attacker, this can provide useful intelligence before sending a single packet to the target.

In practice, reconnaissance often combines both approaches.

Hands-on

For this investigation, we will use scanme.nmap.org. The Nmap project provides this host specifically for testing and experimentation, making it appropriate for demonstrations like this one.

We will start with the simplest question:

Is the host reachable?

01 — Looking at DNS

We can ask DNS what addresses are associated with the hostname.

Now we have two addresses:

IPv4
45.33.32.156

IPv6
2600:3c01::f03c:91ff:fe18:bb2f

DNS gives us our first view of the target's network presence. We now know which IPv4 and IPv6 addresses are associated with the hostname.

02 — Checking Reachability

Now that we know which addresses are associated with the hostname, we can check whether the host is reachable.

We immediately learned something useful. The host responded to all five ICMP requests with no packet loss, with an average round-trip time of approximately 197.6 ms.

At this point, we know that the hostname resolves to an IPv4 address and that the host responded to our ICMP requests. But there is already an important limitation:

A successful ping does not tell us what services are running. It only answers a much smaller question:

Can we reach this host using ICMP?

We need more information.

03 — Looking at Domain Registration Information

DNS tells us about name resolution. WHOIS can provide a different type of information: domain registration and administrative data.

There are several useful observations here. The domain has existed since 1999. The registration uses Dynadot as its registrar. Five Linode nameservers are listed, and DNSSEC is reported as unsigned.

None of this gives us an exploit. That is not the point. Reconnaissance is about building context.

The nameservers, registrar, registration dates, and other domain information can become useful when combined with other sources of intelligence.

Reconnaissance is about understanding what question each command can actually answer.

04 — Fingerprinting the Web Server

We now know where the target is and have some information about its domain infrastructure. The next question is:

What is actually running there?

For this, we can use WhatWeb.

The output identified:

The HTTP headers provided another important piece:

Server: Apache/2.4.7 (Ubuntu)

Now our reconnaissance has moved beyond network information. We have identified:

• Apache as the web server
• Apache version 2.4.7
• Ubuntu Linux as an operating-system clue
• HTML5
• Google Analytics
• HTTP response behavior

This is where information disclosure starts becoming more interesting from a security perspective. A server banner such as Apache/2.4.7 (Ubuntu) gives an attacker a technology and version to investigate.

That does not mean the server is vulnerable. A version number alone is not proof of vulnerability. Operating systems can contain backported security fixes, configurations can differ, and a detected version does not necessarily tell us everything about the software actually running.

But it gives an attacker a lead. And leads are exactly what reconnaissance is designed to produce.

05 — Discovering Public Email Addresses

So far, most of our intelligence has been about infrastructure. But infrastructure is not the entire attack surface. People can become part of it too.

One way to investigate publicly available email addresses is through third-party intelligence services such as the Hunter.io website.

The service also identified email addresses associated with the domain. We will not reproduce personal contact information here. The important finding is the category of information being exposed:

A public domain can be associated with people, identities, and email addresses.

That information can be useful for legitimate communication. It can also become useful to an attacker.

An email address can become a starting point for:

• phishing research
• social engineering
• credential attack targeting
• identity correlation
• further OSINT

Again, the email address itself is not a vulnerability. The risk comes from what an attacker can do when this information is combined with everything else they have learned.

06 — Crawling Public Pages for Emails

We can also perform the same type of discovery without relying entirely on a commercial intelligence database. For this investigation, we used a small Python scraper.

The starting URL was: https://nmap.org/

The script followed publicly accessible links and searched the returned HTML for email addresses.

Among the results were:

• announce-owner@nmap.org
• announce@nmap.org
• dev@nmap.org
• fyodor@nmap.org
• dev-owner@nmap.org

It also encountered addresses belonging to other domains while following external links.

• fyodor@insecure.org
• tcpdump-workers-request@lists.tcpdump.org
• sales@nmap.com

That distinction matters. A scraper returning an email address does not automatically mean that the address belongs to the original target. The tool found the address in the content it crawled; it is up to the investigator to determine whether the information is actually relevant.

Collected data is not automatically validated intelligence.

The scraper itself is available as part of the CPI project for readers who want to inspect how this discovery process works.

View the email scraper on GitHub →

What Can Go Wrong?

None of the steps above exploited a vulnerability. Yet look at what we were able to assemble.

Starting with a single hostname, we discovered:

Infrastructure

• IPv4 address
• IPv6 address
• DNS information
• nameservers
• registrar information

Technology

• Apache
• Apache version
• Ubuntu Linux
• HTTP server behavior
• HTML5
• Google Analytics identifier

Human information

• Public email addresses
• Public identities associated with the domain

Each individual finding may appear harmless. The problem is aggregation.

An attacker does not need one piece of information to compromise a system. They can combine many small pieces into a much clearer picture of the target.

For example:

Domain
   ↓
IP address
   ↓
Web server
   ↓
Software + version
   ↓
Public pages
   ↓
Email addresses
   ↓
People / identities

That picture can then inform the next phase of an attack. This is why information disclosure deserves attention even when no obvious vulnerability exists.

The attacker is reducing uncertainty.

Prevent

Reconnaissance cannot be completely eliminated. A public-facing organization will always expose some information. The goal is to control what is exposed and why.

Some practical measures include:

Minimize unnecessary server information

Review HTTP headers and service banners. If a server does not need to disclose its exact software version, consider reducing unnecessary version information.

Review public DNS exposure

Know which hosts and addresses are publicly resolvable. Remove obsolete records and systems that should no longer be exposed.

Review public email addresses

Know which addresses are publicly discoverable. Separate addresses intended for public communication from accounts used for sensitive administrative functions where appropriate.

Monitor your external attack surface

Do not assume that internal asset inventories tell you everything an outsider can see. Perform external reconnaissance against your own organization and domains.

Review third-party exposure

Search engines, public databases, code repositories, and intelligence platforms can all contain information about an organization. The information may have been published intentionally, but that does not mean its security implications have been considered.

Remediate

Finding exposed information is only useful if something happens afterward. If reconnaissance reveals unnecessary information, remediation should start by determining whether that information actually needs to be public.

For example:

Server version exposed? Review the web server configuration and determine whether version disclosure can be reduced.

Old DNS record exposed? Remove or update the record if the underlying system is no longer required.

Unexpected email address exposed? Determine where it came from, whether it is still required, and whether the associated account has an appropriate security posture.

Sensitive information appearing on a public page? Remove it from the source and verify that it is no longer accessible through the public site or other indexed locations.

Most importantly, remediation should be followed by verification. Make the change, run the reconnaissance again, and confirm that the information is actually gone or reduced. Otherwise, you are assuming the fix worked.

What We Learned

We started with scanme.nmap.org and ended with a much clearer picture of the target.

We identified addresses through DNS, confirmed reachability, gathered domain and nameserver information, fingerprinted the web server and identified Apache and Ubuntu, and discovered publicly available email and identity information. We also demonstrated how a simple crawler can extract additional information directly from public pages.

None of this required exploiting a vulnerability.

That is the point.

Reconnaissance is about turning an unknown target into a known target.

The more information an attacker can collect before exploitation, the more informed their decisions become. And the information does not need to be secret to be useful.

Sometimes the attack surface begins with information an organization never realized it was exposing.

Next Chapter

Information gathering gave us the first picture of the target. We know where it is, what some of its infrastructure looks like, have clues about the technologies running there, and have identified publicly available information associated with the organization.

But we still have a major unanswered question:

What services are actually exposed?

That is where reconnaissance ends and scanning begins. In Chapter 02, we will move from discovering what we can learn about the target to investigating what is actually reachable on it.

Next: Scanning.