Ethical Hacking & Penetration Testing

Chapter 6
Network Discovery, Scanning and Enumeration

Diploma in Cybersecurity
Ethical Hacking & Penetration Testing   •   Diploma

Network Discovery, Scanning and Enumeration

Introduction

Network discovery, scanning and enumeration are foundational activities in ethical hacking and penetration testing. They help an authorised assessor determine which systems exist, which communication paths are reachable, which services are exposed, and what information those services disclose. These activities are not interchangeable. Discovery identifies hosts and network paths; scanning tests ports, protocols, and service behaviour; enumeration extracts structured information from identified services.

The central professional challenge is to obtain reliable evidence without unnecessarily disrupting systems or violating the agreed scope. A scan result is an observation, not automatically a fact. Firewalls, intrusion-prevention systems, load balancers, network address translation, virtualisation, rate limiting, and unstable services can all produce false positives or false negatives.

All practical activities described in this chapter must be conducted against systems for which the tester has explicit written authorisation. The engagement rules should specify permitted addresses, testing windows, prohibited techniques, data-handling requirements, emergency contacts, and reporting obligations.

Learning Objectives

By the end of this chapter, a learner should be able to:

  • explain how TCP/IP addressing, ports, protocols, and network architectures affect discovery;
  • distinguish host discovery, port scanning, service fingerprinting, and enumeration;
  • select appropriate discovery and scanning methods for an authorised engagement;
  • interpret TCP and UDP scan results, including uncertainty and filtering;
  • identify causes of false positives, false negatives, and incomplete visibility;
  • apply safe enumeration practices and document evidence;
  • explain how segmentation and defensive controls influence scan results; and
  • evaluate findings in ethical, legal, and operational terms.

1. TCP/IP Foundations for Discovery

1.1 Addresses, interfaces, and routes

An IP address identifies a logical interface within an IP network. IPv4 addresses contain 32 bits and are commonly written in dotted-decimal form, such as 192.0.2.25. IPv6 addresses contain 128 bits and are written in hexadecimal groups, such as 2001:db8::25. The address alone does not reveal whether a system is physically separate, virtualised, behind a load balancer, or shared by several applications.

A network prefix describes the portion of an address used for routing. In CIDR notation, 192.0.2.0/24 contains 24 network bits and 8 host bits. The number of address values in an IPv4 prefix of length n is:

N = 232-n

Here, N is the total number of address values and n is the prefix length. This is a counting relationship, not necessarily the number of usable hosts. Some environments reserve addresses for network identification, broadcast, gateways, infrastructure, or special functions. IPv6 planning and allocation use different operational conventions, so an assessor must not assume that IPv4 host-count rules apply directly.

A host may have several interfaces and addresses. Conversely, one public address may represent many internal systems through network address translation or a reverse proxy. Therefore, “one IP address” does not always equal “one host.”

1.2 Ports and sockets

A transport-layer port is a 16-bit logical endpoint identifier, with values from 0 through 65,535. TCP and UDP maintain separate port spaces: TCP port 443 and UDP port 443 refer to different transport endpoints. A socket is commonly understood as an address and transport endpoint, such as an IP address combined with TCP port 443.

Ports are often classified as:

RangeCommon descriptionInterpretation
0–1,023Well-known portsTraditionally associated with core services; not proof of service identity
1,024–49,151Registered portsUsed by many applications and vendors
49,152–65,535Dynamic/private portsOften used for temporary client connections, but practices vary

Port numbers are hints, not evidence. An administrator may run HTTPS on port 8443, SSH on a non-standard port, or a custom service on port 443. Service identification should therefore examine protocol behaviour and, where authorised, application responses.

1.3 TCP and UDP behaviour

TCP is connection-oriented. A typical connection begins with a three-step handshake: the initiator sends SYN, the responder sends SYN-ACK, and the initiator sends ACK. A scanner can use responses to infer whether a TCP port is reachable and whether a filtering device is intervening.

UDP is connectionless. A service may respond only to correctly formed application requests, and an unused port may generate an ICMP “destination unreachable—port unreachable” message. No response is ambiguous: it may indicate an open service, packet loss, filtering, or rate limiting. UDP scanning is consequently slower and more difficult to interpret than many TCP scans.

2. Network Architecture and Visibility

Discovery results depend strongly on architecture. Important structures include flat networks, routed enterprise networks, VLANs, screened subnets, cloud virtual networks, wireless segments, remote-access networks, container networks, and zero-trust environments.

A tester located on the same local segment may observe ARP or IPv6 Neighbor Discovery behaviour, while a remote tester cannot rely on those mechanisms across routers. A firewall may allow web traffic from the Internet but deny administrative protocols. A cloud security group may silently discard packets, whereas a traditional firewall may return an explicit rejection. These differences affect both visibility and interpretation.

Network discovery across segmented network zones Authorised testerDiscovery probes Firewall / routerPolicy, NAT, ACLsLogging and filtering Public-service zoneWeb proxy / mail gateway Internal zoneDirectory / databases
Network discovery across segmented network zones
Figure: Network discovery across segmented network zones

Figure: Segmentation changes which systems and services an authorised tester can observe.

A scan from one location should not be treated as a complete map of the organisation. Good assessments document the scan vantage point, routing path, source address, authentication context, and network controls encountered.

3. A Structured Discovery and Scanning Process

A defensible workflow proceeds from low-impact actions to more specific tests.

3.1 Define scope and rules

Before sending probes, confirm the authorised IP ranges, domains, cloud accounts, test windows, exclusions, rate limits, and incident contacts. Identify production systems, safety-critical devices, fragile embedded systems, and services where automated testing is prohibited.

3.2 Passive and contextual discovery

Passive discovery uses existing authorised information rather than sending probes. Sources may include asset inventories, DNS records, certificate transparency data, routing documentation, cloud management consoles, vulnerability-management records, and packet captures supplied by the client. Passive results can be stale or incomplete, but they help reduce unnecessary traffic.

3.3 Host discovery

Host discovery asks whether an address appears reachable. Common methods include:

  • ARP or IPv6 Neighbor Discovery on a local segment;
  • ICMP echo or timestamp requests where permitted;
  • TCP probes to selected ports;
  • UDP probes to selected services; and
  • observation of authorised network telemetry.

No single method is universally reliable. A host may block ICMP while accepting TCP 443. A firewall may make every address appear unreachable, or a proxy may make many addresses appear identical. Host discovery should therefore use multiple carefully selected indicators and should record the exact probe type.

3.4 Port scanning

Port scanning tests whether specific transport endpoints appear open, closed, or filtered. A compact result vocabulary is:

ResultTypical meaningImportant limitation
OpenAn application accepted or answered the probeThe application may be restricted after connection
ClosedThe host responded but no service is listening on that portA later configuration change may alter the result
FilteredA filter prevented a conclusive responseIt does not prove that no service exists
Open/filteredNo response distinguishes an open UDP service from filteringRequires protocol-aware follow-up

A TCP connect scan completes the operating system’s connection process and is generally straightforward but more visible in logs. A SYN-based test uses partial handshake behaviour and may generate different evidence. The appropriate method depends on permission, platform, stability, and engagement rules—not on a desire to evade defenders.

3.5 Service fingerprinting

Service fingerprinting identifies the application behind an open port. Evidence may include protocol banners, TLS certificate attributes, HTTP headers, negotiated protocol versions, response structure, timing, and application-specific exchanges. Banner values can be deliberately altered, generic, or misleading. Fingerprinting should report confidence and evidence rather than claiming certainty from a port number alone.

Operating-system fingerprinting infers characteristics from packet fields and response behaviour. It is probabilistic and can be distorted by firewalls, virtual machines, proxies, NAT, and network stacks that imitate another system. Results should be validated against authorised asset records whenever possible.

3.6 Enumeration

Enumeration is a deeper, service-specific process. Examples include identifying DNS records and transfer permissions, discovering HTTP virtual hosts and application paths, identifying SMB shares and domain information, examining LDAP naming contexts, reviewing SNMP system data, or determining database listener capabilities. Enumeration must be constrained by scope and data sensitivity. Reading a public service description is different from downloading confidential records.

4. Interpreting Accuracy and False Results

A scan is an inference from network observations. Four outcomes are useful for assessing accuracy:

Actual conditionScanner reports presentScanner reports absent
Service is presentTrue positiveFalse negative
Service is absentFalse positiveTrue negative

A false negative may result from filtering, packet loss, rate limiting, an incorrect protocol probe, an unavailable service, or a scan performed from the wrong network segment. A false positive may result from a proxy, honeypot, stale DNS record, shared hosting, a port reused by another application, or an IDS response.

Accuracy should be improved through triangulation:

  1. repeat an observation at a safe interval;
  2. compare results from appropriate network vantage points;
  3. use a protocol-aware probe rather than relying only on port state;
  4. compare with asset inventories, service owners, and logs;
  5. distinguish “not observed” from “not present”; and
  6. record timestamps, tool versions, configurations, and response evidence.

Timing also matters. A service that is open at 09:00 may be closed at 18:00 because of maintenance, autoscaling, or policy changes. Dynamic cloud infrastructure makes point-in-time results especially perishable.

5. Defensive Controls and Their Effects

Defenders use several controls that influence discovery:

  • Firewalls and access-control lists: permit, reject, or silently drop traffic according to source, destination, protocol, and state.
  • Intrusion-prevention systems: detect scan patterns, rate-limit probes, reset connections, or block sources.
  • Host firewalls: provide controls that differ between local, domain, and public profiles.
  • Network address translation and proxies: conceal internal addresses and make several services appear behind one endpoint.
  • Segmentation: limits lateral reach and creates different observations from different zones.
  • Rate limiting and tarpits: slow or distort scans.
  • Honeypots and deception systems: intentionally present plausible but monitored services.
  • Logging and monitoring: record connection attempts, unusual protocols, authentication failures, and enumeration patterns.

A defensive control that hides a service from an unauthorised Internet scan does not necessarily remove the service from internal risk. Conversely, a service visible internally may be unreachable from an external assessment. Security conclusions must state the tested perspective.

6. Practical Methodology and Evidence Handling

A professional scan plan should identify the objective, source location, target list, protocol set, expected traffic, safety limits, and stopping conditions. Begin with a small representative sample before expanding to the full authorised range. Exclude broadcast addresses and infrastructure devices unless explicitly included. Schedule intensive work during an agreed window and monitor service health.

Record at least:

  • target and source address or segment;
  • date, time zone, and test duration;
  • tool and version, including relevant options;
  • observed port state and service evidence;
  • packet loss, retries, and rate limits;
  • defensive responses or blocks;
  • validation steps; and
  • confidence, limitations, and recommended follow-up.

Evidence should be protected because banners, certificates, directory names, usernames, and service metadata can reveal sensitive information. Store only what is necessary, restrict access, encrypt exported reports, and follow the client’s retention and destruction requirements.

Worked example: interpreting a mixed result

An authorised assessment records the following for a server:

  • TCP 443: open; TLS negotiation succeeds; certificate names include portal.example.test.
  • TCP 22: filtered from the external vantage point.
  • UDP 161: open/filtered; no response to a generic probe.
  • Internal asset inventory: the server is documented as running SSH and monitoring software.

A weak conclusion would state that SSH and SNMP are absent. A stronger conclusion is that HTTPS was confirmed externally, TCP 22 could not be distinguished from filtering, and UDP 161 requires an authorised, protocol-aware validation from an appropriate network segment. The inventory increases suspicion but is not a substitute for current network evidence.

7. Illustrative Case Study: Segmented Hospital Network

This is a fictional illustrative case.

Background

A hospital commissions an authorised assessment of its patient-portal environment. The agreement permits external testing of the portal’s public addresses and internal testing from a controlled assessment VLAN. Medical devices and clinical-control networks are explicitly excluded from active scanning.

Problem

An external discovery exercise identifies two public addresses and one HTTPS service. Management initially assumes that the result represents the entire portal infrastructure. The assessor must determine whether the limited result reflects a small architecture or effective segmentation.

Analysis

From the external vantage point, ICMP is blocked, TCP 443 is open, and TCP 22 is filtered. Certificate names reveal a portal hostname, while HTTP responses indicate a reverse proxy. From the assessment VLAN, authorised discovery identifies separate web, application, and database segments. The database addresses do not respond from the VLAN because an internal firewall permits access only from the application tier. Asset records confirm that several backend instances are created dynamically.

Approach and outcome

The assessor documents the public reverse proxy as the externally visible asset rather than counting it as the entire application estate. Internal testing is limited to approved segments and uses low-rate, protocol-aware checks. The final report distinguishes confirmed services, filtered paths, and untested clinical networks. The hospital then improves asset synchronisation, adds monitoring for unusual enumeration, and reviews firewall rules between application and database tiers.

Learning points

The case demonstrates that address discovery is not the same as asset discovery. Proxies can conceal backend systems, segmentation creates perspective-dependent results, and exclusions are essential in safety-critical environments. A technically successful scan can still produce a poor assessment if its limitations are not communicated.

8. Ethical, Legal, and Governance Considerations

Unauthorised scanning may violate computer misuse laws, contracts, acceptable-use policies, or privacy obligations, even when no login is attempted. A professional tester should obtain written permission, minimise traffic, avoid collecting unnecessary personal data, protect credentials and evidence, and report urgent exposures through the agreed escalation route.

The principle of least impact applies throughout the engagement. Do not exploit a discovered service merely to prove that it is vulnerable unless exploitation is explicitly authorised and necessary. Do not bypass controls simply to obtain a more dramatic result. If a scan causes instability, stop according to the rules of engagement, preserve evidence, notify the contact, and document the event accurately.

9. Contemporary Developments

Modern discovery increasingly involves cloud APIs, infrastructure-as-code repositories, container orchestrators, service meshes, IPv6, software-defined networks, and ephemeral workloads. Traditional perimeter scanning can miss assets that exist only briefly or are reachable through identity-based policies rather than fixed IP rules.

AI-assisted security tools can cluster banners, prioritise likely services, correlate asset records, and identify anomalous scan results. However, generated classifications may be incorrect, and sensitive data may be exposed if evidence is sent to an unapproved service. Human validation, reproducibility, access controls, and clear provenance remain necessary. AI should support analysis, not replace authorisation, technical judgement, or accountability.

Best-Practice Checklist

  • Obtain explicit written authorisation and define scope.
  • Start with passive information and low-impact discovery.
  • Use more than one suitable discovery method where feasible.
  • Treat port numbers and banners as evidence, not proof.
  • Record the scan vantage point and defensive controls encountered.
  • Rate-limit activity and protect fragile or excluded systems.
  • Validate important findings with protocol-aware tests and client records.
  • Distinguish filtered, unknown, and absent results.
  • Protect collected metadata and minimise sensitive content.
  • Report uncertainty, timestamps, tool versions, and limitations.

Chapter Summary

Network discovery identifies potentially reachable systems; scanning examines transport endpoints; service fingerprinting identifies application behaviour; and enumeration extracts structured service information. TCP and UDP differ substantially in how results should be interpreted. Network architecture, routing, segmentation, NAT, proxies, firewalls, rate limiting, and deception systems all affect visibility. Scan outcomes are observations with uncertainty, and false positives and false negatives are normal risks. Reliable assessment requires multiple appropriate methods, documented vantage points, protocol-aware validation, and comparison with authorised asset information. Ethical and legal practice requires explicit permission, minimal impact, careful evidence handling, and transparent reporting. Contemporary cloud, container, IPv6, and AI-supported environments make asset discovery more dynamic, but they do not remove the need for human judgement.

Key Terms

Asset discovery: Identification of systems, interfaces, services, and other technology resources.

CIDR: Classless Inter-Domain Routing notation used to express an address and network prefix length.

Enumeration: Structured collection of information from an identified service.

False negative: A condition in which a present host or service is reported as absent or is not observed.

False positive: A condition in which an absent service is reported as present.

Filtered: A scan state indicating that a control prevented a conclusive response.

Fingerprinting: Inferring service or operating-system characteristics from responses and behaviour.

Host discovery: The process of identifying apparently reachable hosts.

ICMP: Internet Control Message Protocol, used for control, error, and diagnostic messages.

NAT: Network Address Translation, which maps addresses between network contexts.

Open port: A port at which an application appears to accept or answer traffic.

Port: A transport-layer endpoint number associated with TCP or UDP communication.

Protocol-aware probe: A request formed according to the expected application protocol.

Segmentation: Division of a network into zones with controlled communication paths.

Service banner: Text or metadata returned by a service that may assist identification.

Socket: A logical communication endpoint combining an address, transport protocol, and port.

TCP: Connection-oriented transport protocol using sequence, acknowledgement, and state mechanisms.

UDP: Connectionless transport protocol that does not establish a general-purpose handshake.

Vantage point: The network location and privileges from which an assessment is conducted.

Review Questions

Short Answer Questions

  1. Distinguish host discovery, port scanning, fingerprinting, and enumeration.
  2. Why is a port number not sufficient evidence of service identity?
  3. What does a “filtered” result usually indicate?
  4. Give two causes of false negatives in network scanning.
  5. Why must a scan report identify its network vantage point?

Long Answer Questions

  1. Explain how TCP and UDP behaviour affects scan design and interpretation.
  2. Discuss how NAT, reverse proxies, and segmentation can cause an assessor to underestimate an organisation’s assets.
  3. Describe a professional workflow for conducting an authorised discovery and enumeration exercise.
  4. Explain how firewalls, intrusion-prevention systems, and rate limiting influence scan accuracy.
  5. Discuss the ethical, legal, and governance responsibilities associated with active scanning.

Analytical / Application Questions

  1. An external scan reports only TCP 443 as open, while an internal inventory lists SSH, DNS, and monitoring services. Develop a validation plan that distinguishes filtering from service absence without exceeding scope.
  2. A UDP port is reported as open/filtered, and repeated generic probes receive no reply. Explain at least three plausible interpretations and identify appropriate evidence for resolving the uncertainty.
  3. A cloud application uses short-lived instances behind a load balancer. Design a discovery and reporting approach that accounts for dynamic assets, multiple vantage points, and limitations of point-in-time scanning.

Multiple Choice Questions with Answers

Question 1

Which activity primarily identifies whether an IP address appears reachable?

A. Host discovery

B. Service enumeration

C. Credential auditing

D. Vulnerability remediation

Correct Answer: A. Host discovery

Question 2

What is the most accurate interpretation of a filtered TCP port?

A. The host definitely has no service on that port

B. A service has definitely accepted the connection

C. A control prevented a conclusive result

D. The port is necessarily running UDP

Correct Answer: C. A control prevented a conclusive result

Question 3

Why are UDP scan results often more ambiguous than TCP results?

A. UDP has no port numbers

B. UDP is connectionless and may produce no response

C. UDP can only operate on local networks

D. UDP encrypts all application data

Correct Answer: B. UDP is connectionless and may produce no response

Question 4

Which statement about port numbers is correct?

A. A port number proves the application identity

B. TCP and UDP share one identical port space

C. A non-standard port cannot host a standard service

D. A port number is a clue that should be validated by protocol behaviour

Correct Answer: D. A port number is a clue that should be validated by protocol behaviour

Question 5

Which situation is a likely false negative?

A. A proxy returns a response for several backend systems

B. A scanner reports a closed port after receiving a reset

C. A firewall silently drops probes to an active service

D. A certificate identifies the expected hostname

Correct Answer: C. A firewall silently drops probes to an active service

Question 6

What does enumeration generally add beyond basic port scanning?

A. Structured information obtained from an identified service

B. Physical destruction of the target system

C. Automatic removal of firewall rules

D. Replacement of the organisation’s asset inventory

Correct Answer: A. Structured information obtained from an identified service

Question 7

Why should an assessment report state the scanner’s vantage point?

A. The vantage point determines the tester’s job title

B. Network location and controls affect what can be observed

C. It proves that every address in the organisation was tested

D. It eliminates all false positives

Correct Answer: B. Network location and controls affect what can be observed

Question 8

Which practice best supports reliable interpretation of scan results?

A. Relying only on well-known port numbers

B. Ignoring timestamps because services are static

C. Triangulating observations with protocol tests and authorised records

D. Treating no response as proof that a service is absent

Correct Answer: C. Triangulating observations with protocol tests and authorised records

Question 9

An IPv4 prefix has length /24. Using N = 232-n, how many total address values does it contain?

A. 24

B. 128

C. 256

D. 512

Correct Answer: C. 256

Question 10

Which action best reflects least-impact ethical testing?

A. Scanning excluded medical devices to improve completeness

B. Using the highest possible rate against production systems

C. Collecting all returned personal data for convenience

D. Following scope, rate limits, evidence controls, and stopping conditions

Correct Answer: D. Following scope, rate limits, evidence controls, and stopping conditions

Ethical Hacking & Penetration Testing
Chapter 6 of 15