Study Guide
Service Discovery and Vulnerability Research
What ports and services are, what Nmap service and version detection shows, and how to research whether a known vulnerability really applies, without confusing discovery, research and exploitation.
Lesson 4.5 Network & Infrastructure Security
Before anyone can judge whether a system is weak, they need to know what it is running. This lesson works out how a scan turns an address into a list of ports, services and versions, why those results need interpreting, and how to research known vulnerabilities carefully enough to decide whether they really apply. Throughout, it keeps three activities apart: discovery, research and exploitation.
Stage: Think
What is it running?
Think it through
You are asked whether a server is affected by a known weakness in some web software. What do you need to find out about the server before you can even start to answer?
- Hint 1: Could you judge the weakness without knowing the software?
Show what happens
What it is running: which services answer on the network, and which products and versions they are. Only then can you look up whether a known weakness applies, and even that needs checking.
Think it through
Show the answer
Answer: A. By a port number for each.
Each service listens on its own port, and the port in the incoming traffic says which one it is for.
Stage: Explain
Ports and services
A computer can offer many network services at once: a web server, a file-transfer server and a remote-login service can all share one IP address. Something has to tell incoming traffic which of them it is for. That is the job of the port.
Definition
Port
A numbered logical endpoint used by the transport-layer protocols TCP and UDP to tell apart the services and applications on one device. A connection to a service goes to an address and a port.
A network service, defined under Key terms, is what listens on a port and answers requests. Ports and services are related but not the same. Port 80 is conventionally used for web traffic, but a web server can listen on any port, and any service can listen on port 80. A port number is a strong hint about what is running, not proof. TCP, UDP, Ports and Sockets explains ports, port ranges and sockets in more detail.
Check your understanding
Show the answer
Answer: C. No: it is only a strong hint.
No. Port 80 is conventionally used for the web, but any service can listen on it; the number is a hint, not proof.
From a security point of view, every service that answers on the network is something that can be reached, and so something that could contain a weakness. That connects directly to exposure.
Stage: Predict
Discovery, research and exploitation
These three activities are often mentioned together, but they are different in what they do and in what they risk.
Think it through
Finding which services a server runs, reading about known weaknesses in them, and trying to use a weakness: which of these sends traffic to the target, and which tries to change what it does?
- Hint 1: Which of them could you do in a library?
Show what happens
Finding services sends traffic; reading about weaknesses does not touch the target at all; trying to use one sends traffic and tries to change what the target does. The table names the three.
| Activity | What it involves | Examples |
|---|---|---|
| Discovery (reconnaissance) | Finding out what exists and what it exposes | Finding which hosts respond; identifying open ports; identifying services; attempting service and version fingerprinting |
| Vulnerability research | Reading about known weaknesses and working out whether they apply | Checking CVE records, the NVD and vendor advisories; reading affected-version and configuration details |
| Exploitation | Actively trying to use a vulnerability to access, change or affect a target | Anything that tries to make a weakness do something |
Research happens away from the target: it reads published information. Active discovery and exploitation both send traffic to the target, and both need authorisation. Exploitation goes further, because it deliberately tries to change what the target does. Finding a possible vulnerability never, on its own, justifies trying to exploit it.
Check your understanding
Show the answer
Answer: C. Research.
Research, which reads published information and sends nothing to the target. Discovery and exploitation both need authorisation.
Stage: Predict
Service and version detection with Nmap
Nmap is a widely used tool for network exploration and security auditing. It can discover which hosts respond, which ports they have open and which services are behind those ports.
Take this command, run from a Kali Linux VM against a deliberately vulnerable Metasploitable VM in an isolated lab:
nmap -sV <metasploitable-ip>nmapruns the scan.-sVasks Nmap to attempt service and version detection on the ports it finds open.<metasploitable-ip>is a placeholder for the target VM’s address on the lab network, found by inspecting its interfaces. No real addresses or results are shown here.
Reading the results
For each open port it finds, a version scan typically reports four things. These are the column headings to look for, not results from any real scan:
| Column | What it means |
|---|---|
| PORT | The port number and transport protocol, such as a TCP port |
| STATE | Whether the port is open, closed or filtered, as far as Nmap can tell |
| SERVICE | The service Nmap believes is listening |
| VERSION | The product and version Nmap identified, where it could |
Here is what such a result looks like. It is invented for this lesson: the host, the products and the versions do not exist, and it is not the output of any scan.
PORT STATE SERVICE VERSION
22/tcp open ssh Exampleshell 7.1
80/tcp open http Examplesrv 2.3
8080/tcp open unknownThink it through
Look at the invented result. Which rows give you something to research, and what should you write down for port 8080?
- Hint 1: Which rows name a product and a version?
Show what happens
Ports 22 and 80 name a product and version, so they can be researched. Port 8080 is open but unidentified, so the honest note is “open; service not identified”, not a guess.
Read it one row at a time.
- Port 22. Open, and Nmap recognised both the kind of service (
ssh, used for remote sign-in) and a product and version, Exampleshell 7.1. - Port 80. Open, a web service (
http), identified as Examplesrv 2.3. A product and a version together are what make research possible. - Port 8080. Open, and that is all. Something is listening, but it gave nothing away, so the SERVICE column says
unknownand VERSION is empty.
What the three rows give you: two leads to research, and one honest gap. The right note for port 8080 is “open; service not identified”, not a guess. The worked example later in this lesson takes the Examplesrv 2.3 row and researches it.
Think it through
Nmap reports “Examplesrv 2.3”. How could that be wrong?
- Hint 1: Where does Nmap get the version from?
Show what happens
The service might announce a changed version in its greeting, behave unusually, or match more than one product’s fingerprint. The result is evidence to check, not a fact.
Nmap connects to each open port, sends probes and compares the responses with a database of known service fingerprints. Many services also announce themselves in a banner, a greeting that may name the product and version. Nmap combines what it sees into its best identification.
That means a result can be:
- useful evidence of what is running;
- incomplete, when a service reveals little or nothing about itself;
- wrong or misleading, when a banner has been changed, a service behaves unusually or the fingerprint matches more than one product.
Treat the VERSION column as a starting point for investigation, not as a verified fact.
Stage: Predict
From version to vulnerability: a research workflow
The service and version information from a scan can be researched online for known vulnerabilities. Doing that well means working through a sequence and not skipping steps.
Think it through
Put these in order: research the version, find the open ports, test (if authorised), identify the service, check the vulnerability really applies.
- Hint 1: Which step needs the result of every other?
Show what happens
Find the open ports, identify the service and its version, research it, check that what you found really applies, and only then test, if the scope allows it.
A supplementary workflow, one step at a time. Each step narrows the question; only the last involves any active testing, and only within authorised scope.
Asset or target
Step 1 of 7: Start with authority
Which system are you examining, and are you authorised to examine it?
Port
Step 2 of 7: Find what answers
Which ports answer? Each open port is a point of exposure to understand.
Service
Step 3 of 7: Identify what listens
What is listening on each port? Do not assume from the number alone.
Observed version or fingerprint
Step 4 of 7: Note what it revealed
What did the service reveal about its product and version, and how confident is that result?
Vulnerability research
Step 5 of 7: Read the records
What do CVE records, the NVD and the vendor’s advisories say about that product and version?
Applicability validation
Step 6 of 7: Check that it applies
Do the affected versions, platform and configuration actually match what you observed? Record confirmed, rejected or uncertain.
Authorised testing
Step 7 of 7: Test only within scope
Only if the scope explicitly allows it. Otherwise report the finding as a lead for the system owner.
Check your understanding
Show the answer
Answer: A. A guess is reported as a claim.
A guess is reported as a fact: the match has not been checked against the version, platform and configuration you observed.
Each step matters because the next one depends on it. A wrong service identification sends the research in the wrong direction; a vague version produces a long list of possible CVEs; and skipping validation turns a guess into a claim.
Stage: Predict
Where to research
Think it through
Show the answer
Answer: C. The vendor’s own advisory.
The vendor’s security advisory, which often states affected and fixed versions and configurations most precisely.
- CVE records (cve.org) give each publicly disclosed vulnerability a unique identifier and a description. A CVE ID names a flaw; it does not rate it or say where it applies.
- The NVD adds analysis to CVE records, which can include affected products and version ranges, a CVSS severity score and links to fixes. Analysis is not always immediate. Vulnerabilities and Exposure introduces it.
- Vendor security advisories are often the most precise source about which versions and configurations are affected and which fixed versions or patches resolve the issue.
- Exploit databases, such as Exploit-DB, catalogue publicly released exploit code. They can show that a flaw is well known, but an entry is not proof that a particular system is vulnerable, and using exploit code is exploitation, which needs explicit authorisation.
Stage: Predict
Why a match is not confirmation
A CVE that mentions the product you found is the start of the work, not the end. The Study Guide’s rule of thumb: a detected version is a lead, and a matching CVE is a hypothesis.
Think it through
A CVE record mentions the product your scan found. List what you would still need to check before saying the system is affected.
- Hint 1: Is the name enough?
- Hint 2: Could the vendor have fixed it quietly?
Show what happens
That it is exactly the same product and edition, that the version falls in the affected range, that any required feature or setting is enabled, and that the vendor has not already patched it without changing the version number.
- Product names can be similar. Two different products, or two editions of one product, can share a name. Check that the CVE is about exactly what you observed.
- Version ranges matter. Records usually say which versions are affected, for example “before” or “up to” a particular release. The observed version has to fall inside that range.
- Configuration matters. Many vulnerabilities apply only when a particular feature, module or setting is enabled.
- Backported patches complicate version numbers. Some operating-system vendors fix a vulnerability in their own package without changing the upstream version number the service reports. A version that looks vulnerable may already be patched.
- Vendor advisories can settle the question. They often state affected and fixed versions and configurations more precisely than a general database.
- Exploit availability is not proof. Public exploit code shows that someone has written an exploit, not that this system is affected by it.
Check your understanding
Show the answer
Answer: A. No: only that it is known.
No. It shows the flaw is known and an exploit has been written, not that this system is affected.
A fictional authorised lab scan reports a service identified as Examplesrv 2.3. The product, version and record below are invented for teaching; they are not real.
- Observation. Port and service as reported; version 2.3, identified from the service’s banner.
- Research. A fictional advisory describes a flaw affecting Examplesrv versions before 2.5, but only when its optional remote-administration module is enabled.
- Compare. The version falls inside the affected range. Whether the module is enabled is unknown, and the banner could have been changed.
- Decide. Applicability is uncertain, not confirmed. The note records what would settle it, such as checking the configuration with the system owner or the vendor’s guidance.
- Stop there. Unless the agreed scope explicitly covers further testing, the result is a lead to report, not something to try out.
Stage: Predict
Authorisation still applies
Think it through
Show the answer
Answer: B. No: you lack permission.
No. Nobody entitled to give permission has given it; being easy to reach changes nothing.
Every step that sends traffic to a target, including a simple scan, needs permission from someone entitled to give it, within an agreed scope. A deliberately vulnerable VM in your own isolated lab is a suitable target for practice; other people’s systems are not, however easy they are to reach. Ethics, Authorisation and Responsible Disclosure explains why discovering a weakness does not give permission to exploit it.
In professional work, a scan’s findings are usually passed to the people responsible for the systems, with the evidence and the level of confidence stated. “Examplesrv 2.3 reported; affected range matches; configuration unconfirmed” is far more useful than “server is vulnerable”.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: C. “In range; module status unknown.”
State what was found and how confident it is: the version is in range, but the configuration is unconfirmed, so applicability is uncertain.
Apply it
Show the answer
Answer: B. It records a guess as a finding.
It turns a guess into a finding. The honest record is “open; service not identified”, perhaps with a note of what the port often carries.
Stage: Check
Check your understanding
These questions come from the approved revision bank. None reproduces real scan output.
Show answer
Answer: Attempt to identify the services and versions associated with the ports it discovers.
-sV is service and version detection: Nmap attempts to identify which service is behind each port it discovers and, where it can, its version. That identification is inferred from probes and banners, so it is additional evidence rather than a guaranteed exact result. Looking up CVEs is research and trying exploits is exploitation: separate activities that -sV does not perform.
Revision sources: Session 6: Networking Fundamentals — Part 2 (Classroom session record) · Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Show answer
Answer: It is evidence for further investigation, not proof that the service is vulnerable.
nmap -sV attempts service and version detection. Version detection infers the service and version from probes and banners, so a result can be useful, incomplete or wrong, and discovery, vulnerability research and exploitation are different activities. A detected service and version can guide vulnerability research, but whether a vulnerability applies still has to be checked: the result is neither proof of a vulnerability nor worthless.
Revision sources: Session 6: Networking Fundamentals — Part 2 (Classroom session record) · Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Show answer
Answer: Discovery gathers information; exploitation attempts to make use of a weakness.
Discovery, vulnerability research and exploitation are different activities. Discovery finds out what exists and what it exposes, such as open ports, services and versions; exploitation actively tries to use a weakness to access, change or affect a target. Active discovery and exploitation can both interact with the target and both need authorisation, but their purposes and authorised scope differ, and finding a possible weakness does not on its own justify exploiting it.
Revision sources: Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Show answer
Answer: Only against systems you are explicitly authorised to test
Written permission must be obtained before security testing, and authorisation defines what is allowed. An active scan sends traffic to a target, so scope and permission apply to scanning as well as to any later testing activity. Being able to reach a system, or being connected to the same network, does not authorise testing it, and scanning is not something to reserve until a vulnerability has been found.
Revision sources: Session 1: Cyber Fundamentals Part 1 (Classroom session record)
Show answer
Answer: False
False. A detected version is a lead and a matching CVE is a hypothesis. The exact product, the affected version range, the configuration the flaw needs and any backported patches must still be checked, and vendor security advisories often state affected and fixed versions more precisely than a general database. Only then can the vulnerability be recorded as confirmed, rejected or uncertain.
Revision sources: Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Show answer
Answer: Security fixes may have been backported without changing the displayed upstream version.
Backported patches complicate version numbers: some operating-system vendors fix a vulnerability in their own package without changing the upstream version number the service reports. A version that looks vulnerable may already be patched, or may not be, so the string alone can mislead. Vulnerability records do state affected version ranges, so the number still matters, and vendor security advisories are often the place to settle whether a fix has been applied.
Revision sources: Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Show answer
Answer: Validate whether it actually applies to that product, version and configuration
The services and versions identified by a scan can be researched online for known vulnerabilities, but a search result or matching CVE is a lead for investigation rather than confirmation: the product, affected version range, configuration and any backported patches must be checked, using CVE records, the NVD and vendor advisories, before recording it as confirmed, rejected or uncertain. Rescanning only repeats discovery, and testing a weakness is a separate activity.
Revision sources: Session 6: Networking Fundamentals — Part 2 (Classroom session record) · Service Discovery and Vulnerability Research (Supplementary Study Guide explanation)
Study and revision
Practise through the Information Gathering & Reconnaissance topic and the Vulnerabilities topic. Questions cover what -sV does, why a detected version is evidence rather than proof, how active discovery differs from exploitation, why a CVE match or a version string is not enough, and what should follow a possible finding; two flashcards recall -sV and why a matching CVE is not proof. The scanning-authorisation question draws on the teaching on written permission in Ethics, Authorisation and Responsible Disclosure and is also practised through the Security Assessment topic. Items that use this lesson’s supplementary explanation say so. They are learning-only, and the lesson does not establish exam alignment or practical completion.
Stage: Consolidate
What to remember
- A port tells traffic which service it is for; the number is a hint about the service, not proof.
- Discovery, research and exploitation are different: research reads published information; discovery and exploitation send traffic and need authorisation.
- nmap -sV attempts service and version detection; its result is evidence to check, not a verified fact.
- A detected version is a lead, and a matching CVE is a hypothesis: check product, version range, configuration and backported patches.
- Every scan needs permission within an agreed scope, and a finding is reported with its level of confidence.
Key terms
- Port number
A 16-bit logical number that identifies a service or endpoint for TCP or UDP. It is different from a physical switch port.
- Network service
A program or function that can be reached over the network, listening for and responding to requests on an address and port.
- Nmap
A network scanning tool used for network exploration and security auditing: finding which hosts respond, which ports are open and which services are behind them.
- CVE (Common Vulnerabilities and Exposures)
A system of unique identifiers for publicly disclosed vulnerabilities, written as CVE-year-number, so everyone can refer to the same flaw.
- NVD (National Vulnerability Database)
A database maintained by NIST that provides information about publicly disclosed vulnerabilities.
Common misunderstandings
Version detection is inference from how a service responds. Banners can be changed and fingerprints can be ambiguous, so treat the result as evidence to check.
The CVE may need a particular configuration, a different edition or an unpatched package. Applicability has to be validated.
Exploit code shows a flaw can be exploited somewhere, not that this system has it. Using the code is exploitation, which needs explicit authorisation.
Scanning sends traffic to someone else’s systems and can affect them. It needs authorisation and must stay within scope, like any other testing.
Further reading
- Nmap Reference Guide: Service and Version Detection
- CVE Program
- NIST National Vulnerability Database
Lesson sources and acknowledgements
Sources and scope
- Taught in Session 6 (see the Session 6 Learning Log): the tutor’s demonstration of
nmap -sV <metasploitable-ip>from Kali Linux against the Metasploitable VM’s lab address;nmapfor network and service discovery and-sVfor service and version detection; Kali described as the attacking machine and Metasploitable as the victim; and the explanation that detected versions can be researched online for known vulnerabilities. - Supplementary explanation: the port and service definitions, the discovery, research and exploitation comparison, reading the result columns, the invented three-row scan result and its reading, how version detection works and its limits, the research workflow, the research sources including Exploit-DB, why a match is not confirmation, the fictional example, the authorisation section, the practical note and the misunderstandings. These are my explanations, not the tutor’s words.
- Not recorded: the addresses, ports, services and versions shown in the demonstration, and any vulnerability found. No scan output is reproduced.
- Fictional example: Examplesrv, Exampleshell, the three-row result and the advisory are invented for teaching. No scan produced them.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the opening questions about what a server is running, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. I have not scanned a system, researched a real finding or tested a vulnerability as part of this lesson.
The security objective of keeping systems, services and information accessible to authorised users when required.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
A system of unique identifiers for publicly disclosed vulnerabilities, written as CVE-year-number, so everyone can refer to the same flaw.
A standard for rating the technical severity of vulnerabilities. The same base score can carry different business risk depending on context.
An endpoint that sends or receives data on a network. Hosts are nodes, but not every node is an end host.
A logical network-layer address identifying an interface for delivery across networks. IPv4 addresses are 32 bits; IPv6 addresses are 128 bits.
The principle that a person should access particular information only where their role gives a legitimate requirement for it.
A program or function that can be reached over the network, listening for and responding to requests on an address and port.
A network scanning tool used for network exploration and security auditing: finding which hosts respond, which ports are open and which services are behind them.
A database maintained by NIST that provides information about publicly disclosed vulnerabilities.
A 16-bit logical number that identifies a service or endpoint for TCP or UDP. It is different from a physical switch port.
An agreed set of rules for how data is formatted, transmitted and interpreted so that devices can communicate.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
A software endpoint for network communication, managed by the operating system.
A connection-oriented transport protocol that starts connections with a SYN, SYN-ACK, ACK handshake and provides reliable, ordered delivery.
A software-defined computer with virtual hardware and its own guest operating system, running on resources supplied by a physical host.
A weakness that a threat may exploit.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.