Overview
Beyond subdomains, asset discovery identifies the actual hosts (servers/systems) that make up the in-scope surface. This lesson covers host discovery.
Learning objectives
- Explain host discovery in asset discovery.
- Describe identifying live hosts and their services.
- Connect hosts to the broader asset picture.
Core concept
Hosts are the individual servers or systems behind the in-scope domains/subdomains — identified by IP address and the services they run. Host discovery determines which hosts are live, what services/ports they expose (building on the scanning concepts), and how they relate to the discovered names. It moves from "these subdomains exist" to "these are the actual systems, and here is what each runs" — a more concrete view of the attack surface. Multiple subdomains may map to one host, or one subdomain to multiple hosts, so host discovery clarifies the real systems in scope.
How it works
Using the validated, in-scope subdomains/domains, the researcher identifies the underlying hosts: resolving names to IPs, determining which hosts are live, and (with permitted techniques, within scope) identifying the services each exposes. This clarifies the real systems — for instance, revealing that several subdomains share a host, or that a host runs multiple services worth examining. Host discovery respects scope (only in-scope hosts) and pacing (as in the scanning lessons). The result enriches the asset picture with concrete systems and their services, guiding which to prioritize and test.
Practical example
From validated in-scope subdomains, the researcher discovers the underlying hosts: app and api subdomains resolve to distinct live hosts each running web services, while two other subdomains share a single host. Identifying each host and its exposed services (within scope) gives a concrete map of the real systems and what they run — more actionable than subdomain names alone. This host-level picture guides prioritization and testing toward the systems and services most worth examining.
Cybersecurity relevance
Host discovery grounds asset discovery in the actual systems and their services, which is where vulnerabilities are tested — clarifying the real attack surface behind the names. It builds on scanning/service-identification concepts and must respect scope and pacing. Understanding the host-to-name mapping also prevents confusion (shared hosts, multiple services) and informs prioritization. For defenders, it underscores maintaining an accurate host/service inventory. In bug bounty, a clear host picture, within scope, directs hunting toward the concrete systems and services most likely to yield findings.
Common mistakes
- Stopping at subdomain names without identifying the actual hosts/services.
- Ignoring scope/pacing when discovering hosts and services.
- Confusing name-to-host mapping (shared hosts, multiple services per host).
Key takeaways
- Hosts are the actual servers/systems behind in-scope names, identified by IP and the services they run.
- Host discovery moves from "subdomains exist" to "here are the real systems and what each runs," clarifying the concrete attack surface (building on scanning/service ID).
- It respects scope and pacing, clarifies name-to-host mapping, and guides prioritization toward the systems/services most worth testing.
Check your understanding
- How does host discovery add to the picture provided by subdomain enumeration?
- Why does clarifying the name-to-host mapping (e.g. shared hosts) matter for testing?