Ethical Hacking
Whois & Network Enumeration
Every organisation that connects to the internet has to register something — a domain name, an IP block, a company address. That registration data lives in public databases anyone can read. Knowing how to read it efficiently is one of the fastest ways to build an accurate picture of a target before active scanning begins.
Registration records exist because the internet requires accountability
The internet was not built with anonymity in mind. From the beginning, every domain name registration and every IP address allocation came with a requirement to provide contact information — so that if something went wrong, there was a way to reach the responsible party. That information sits in public WHOIS databases maintained by organisations like ICANN, ARIN, RIPE, and APNIC depending on the geographic region.
For a pen tester, this accountability infrastructure is genuinely useful. It tells you who owns a domain, when it was registered, who their registrar is, and often which organisation owns the IP address blocks associated with it. None of this requires any interaction with the target's systems. It is reading a public record — the digital equivalent of checking the land registry to see who owns a property.
The real skill is not running the lookup — that takes seconds. The skill is knowing what to look for in the output and how to connect what you find in WHOIS to what you already know from DNS enumeration.
Domain WHOIS — reading beyond the obvious fields
Most people who run a WHOIS query look at the registrant name and move on. That misses the more interesting parts of the record. A domain's creation date tells you how old the infrastructure is likely to be. The registrar tells you which company manages the domain — relevant if you ever need to consider social engineering angles. The nameservers confirm which DNS provider is in use. And the expiry date occasionally reveals something unexpected: a domain about to expire is a domain whose owner may have lost track of their infrastructure.
Privacy protection services like WhoisGuard are increasingly common and will replace the registrant's real contact details with proxy information. When you see that, it limits what you can learn about the individual but often still reveals the registrar, nameservers, and technical contact details that remain useful.
Network WHOIS — mapping who owns what IP space
Domain WHOIS is one thing. Network WHOIS is different — it tells you who owns a block of IP addresses rather than a domain name. This matters in a pen test for a specific reason: companies rarely own just one IP address. They often have entire network ranges allocated to them, and if you find one IP associated with the target, a network WHOIS lookup can reveal the full range of IP addresses that belong to the same organisation.
That range becomes your potential scanning target — subject to your scope agreement. A company might list five specific IPs in your scope, but network WHOIS reveals they own a /24 block of 256 addresses. The conversation about whether those additional IPs fall within scope is one you have before the active phase begins, not during it.
You rarely need to think about which registry to query manually — the whois command on Linux automatically routes your query to the appropriate registry based on the IP address or domain. The table above is more useful for understanding why an IP lookup sometimes returns information from an unexpected source.
Running WHOIS and reading what comes back
The scenario: You have just completed DNS enumeration for a manufacturing company. The zone transfer returned several internal hostnames, and one of the IP addresses — 89.44.12.201 — appeared on the VPN gateway subdomain. Before scanning that IP directly, you run WHOIS to confirm the organisation that owns it, understand what network range it sits in, and check whether there are other IPs in the same block that could be in scope for the engagement.
# whois queries the public registration database for a domain or IP address
# When given an IP, it returns network block ownership and contact information
# This is completely passive — your query goes to a public registry server
# No packets reach 89.44.12.201 during this step
# Query the domain registration record first
whois targetmanufacturing.com
# Then query the IP address found on the VPN gateway subdomain
# This reveals who owns that IP block and what range it belongs to
whois 89.44.12.201Breaking it down:
A 17-year-old domain. That gap between creation and now represents years of accumulated infrastructure — legacy servers, forgotten subdomains, software that has not seen a major update since the early cloud era. Flag it and keep it in mind when interpreting scan results later.
The company owns the entire /24 block — 256 IP addresses from .0 to .255. Your scope document listed one IP. Now you know that IP sits inside a 256-address range the company controls. Before scanning anything beyond what is explicitly in scope, go back to the client and clarify whether the full block is included. Never assume.
This appeared in the DNS enumeration lesson too — worth restating here because seeing it confirmed in both DNS records and WHOIS data reinforces it as a real finding rather than a data anomaly. Two independent sources saying the same thing is stronger evidence than one.
The IP block is registered with RIPE NCC — confirming European infrastructure. The whois command routed the IP query to RIPE automatically. This is useful context: RIPE records tend to be more detailed about network ranges than some other registries, and they often include the technical contact name which occasionally turns up in other searches.
Network enumeration — discovering live hosts across a range
Once you have a network range confirmed — whether from WHOIS, DNS enumeration, or the client's own scope document — the next step is finding out which hosts in that range are actually alive and responding. This is called host discovery or live host enumeration, and it is the bridge between reconnaissance and scanning.
The most widely used tool for this is Nmap. While most people associate Nmap with port scanning, it has a dedicated host discovery mode that sends lightweight probes across a network range and reports back which addresses are live — without doing a full port scan. This keeps the initial noise low and lets you build a confirmed target list before committing to heavier scanning.
The scenario: Your scope has been confirmed. The client has authorised you to enumerate their internal lab network — the 192.168.56.0/24 range your lab sits on. Before scanning individual ports on specific hosts, you run a host discovery sweep to confirm which addresses are alive and responding. This is active reconnaissance and requires the testing window to be open.
# Nmap host discovery sweep across the full lab subnet
# This is active recon — packets are sent to every address in the range
# Only run this inside your authorised scope and testing window
# -sn means "scan network" but skip port scanning entirely
# It only checks which hosts are alive, nothing more
# This is significantly quieter than a full port scan
# -PE sends an ICMP echo request (like ping) to each host
# -PS80,443 also sends TCP SYN probes to ports 80 and 443
# Some hosts block ICMP but still respond to TCP — combining both
# catches hosts that a plain ping sweep would miss entirely
# The /24 notation means scan all 256 addresses in this range (.0 to .255)
nmap -sn -PE -PS80,443 192.168.56.0/24Breaking it down:
This flag is what makes the command a host discovery sweep rather than a port scan. Without it, Nmap would scan the most common 1,000 ports on every address in the range — generating far more traffic and taking considerably longer. Use -sn first to confirm which hosts exist, then run targeted port scans only against those live addresses.
Using both probe types is deliberate. Firewalls and host-based security tools often block ICMP echo requests — so a plain ping sweep returns nothing even when a host is live. The TCP SYN probes on ports 80 and 443 give you a second path to detect those hosts. Using both together catches things that either approach alone would miss.
The speed difference between a host discovery sweep and a full port scan is dramatic. Scanning 256 addresses for live hosts took just over two seconds. Running a full port scan across all 65,535 ports on all 256 addresses would take hours. Always do host discovery first — it narrows the work to only the addresses worth scanning in detail.
Three live hosts returned — 192.168.56.1 (the VirtualBox gateway), .101 (Metasploitable), and .102 (a second service on Metasploitable). In a real engagement, this list would be your confirmed target list for the port scanning phase. Everything from here is focused on those three addresses, not the other 253 that came back silent.
Connecting WHOIS findings to the bigger picture
By this point in a real engagement — after DNS enumeration and WHOIS and network discovery — you have a structured intelligence picture that looks something like this.
That summary took roughly two to three hours to build from public sources and a small number of active queries. The scanning phase that follows will be faster and more focused because this groundwork was done properly. Every scan you run from here is targeted rather than exploratory — and targeted scans generate less noise, take less time, and produce more actionable results.
Teacher's Note: The transition from recon to scanning is one of the most important decisions in an engagement. Going into scanning without a clear target list is how people spend three days port scanning things that are not relevant. The WHOIS and host discovery work in this lesson is what makes that transition clean.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 13
Google Dorking
Using search engine operators to surface sensitive files, exposed login pages, and configuration data that organisations never intended to be publicly indexed.