We reach the last lesson of Module 3. In 03-01 we opened the ports and in 03-02 we turned them into an inventory of services with versions: Apache 2.4.29 with PHP 7.2.24 on the store, MySQL 5.5.62 exposed on dev, a Werkzeug development server on 54321, SMB with a null session, SNMP public... We have concrete software with concrete versions. Now comes the question that connects it all to exploitation: which of these services are vulnerable, how severe, and where is it best to start?

Detecting vulnerabilities means cross-referencing each service/version against the known-vulnerability databases (CVE, CPE, NVD, exploit-db) and against automated scanners (Nessus/OpenVAS, nmap --script vuln, nuclei), and then critically validating them —separating the false positive from the real finding—. The deliverable is a prioritized list of candidate vulnerabilities that feeds directly into Module 4. The usual framing: vulnerability scanners are noisy and sometimes intrusive (they can restart fragile services), so they're run within scope, in the agreed window, and with notice; and detecting is not exploiting: here we identify and prioritize, we don't launch the exploit.

1. What a vulnerability is and the CVE lifecycle
2. The common language: CVE, CPE, NVD, and CVSS
3. Manual search: searchsploit and exploit-db
4. Scanning with Nmap: --script vuln
5. Vulnerability scanners: Nessus and OpenVAS/GVM
6. nuclei: fast templates
7. Critical reading: false positives and validation
8. TechNova's prioritized vulnerability list
9. Defensive counterpart
10. Common mistakes and tips
11. Exercises
12. Conclusion

A vulnerability is a flaw (in software, configuration, or design) that an attacker can leverage to breach the system's security. In this phase we focus mainly on known vulnerabilities: the published ones, with an identifier and often with an exploit available. Their lifecycle:

The pentester works at the tail end: there are systems that haven't applied the patch and remain exposed. Our job is to detect those cases by cross-referencing what's running (03-02) with what's known to be vulnerable.

To talk about vulnerabilities precisely there's a standard vocabulary:

The key bridge is the CPE: the product+version identifier Nmap already gave us in 03-02 (cpe:/a:apache:http_server:2.4.29). With that CPE you query the NVD and out come all the CVEs affecting that version. The CVSS gives a quick sense of severity; we'll use the score only as guidance for prioritizing —the detail of how it's calculated (vectors, metrics) belongs to 06-02—.

Before the scanners, the most direct and controlled route is to search by hand. searchsploit is the local copy of exploit-db in Kali:

Reading: Werkzeug - Debug Shell Command Execution stands out. If the development server on port 54321 has debug mode enabled (the infamous Werkzeug PIN), it could allow command execution. It's a strong candidate for Module 4. To check the detail or the CPE, the NVD website also works, filtering by product and version.

The NSE includes a vuln category that checks for known vulnerabilities against the detected services. It's the natural step after enumeration:

Line-by-line analysis:

• http-slowloris-check ... LIKELY VULNERABLE (CVE-2007-6750): a possible Slowloris denial of service. Careful: DoS scripts can take the service down; many only check for it without launching it, but they must be used with permission.
• http-csrf: a possible lack of CSRF protection on /login.php.
• http-sql-injection: Possible sqli for query: /producto.php?id=1': a possible SQL injection in the id parameter of producto.php —exactly the parameter recon flagged on the store—. A very promising candidate.

Notice the wording: "Possible", "LIKELY". Nmap flags candidates, it doesn't confirm. Validation is section 7.

For broad coverage, dedicated scanners are used; they run thousands of checks and produce reports with severity. The two most common:

Conceptual example of the result of an authenticated scan against dev:

Each line brings a CVE, severity, and an indicative CVSS score. Very powerful, but with two important caveats: they're noisy (an IDS spots them instantly) and they produce false positives (hence the next section). Authenticated scans (with credentials provided by the client) are far more reliable than unauthenticated ones, because they see the real versions instead of guessing.

nuclei checks for vulnerabilities and exposures through community-maintained templates (YAML). It's fast, precise, and widely used for web surface:

It detects the phpinfo.php, confirms PHP out of support, and —a new finding— an exposed .git/config, which could allow downloading the source code. nuclei shines for its relatively low noise and its up-to-date template base.

This is the section that separates a professional from someone who pastes a scanner's output into the report. Scanners get it wrong, in two directions:

• False positive: it reports a vulnerability that doesn't exist (e.g. it flags something as vulnerable by version number even though there's a patch backported by the distribution —very common in Debian/Ubuntu—).
• False negative: it misses a real vulnerability (custom configuration, unrecognized service).

That's why every candidate is validated. Ways to do it without going as far as exploiting:

• Confirm the exact version and the patching. Ubuntu usually backports fixes without changing the visible version number; a CVE "detected" by version may already be fixed.
• Cross several sources. If Nessus, --script vuln, and searchsploit agree, confidence rises.
• Light manual check. A controlled request (e.g. producto.php?id=1' and seeing whether the error reveals SQL) confirms the suspicion without yet launching a full exploit.
• Discard what doesn't apply. A CVE for a feature the service doesn't use isn't exploitable in this context.

Each candidate is tagged with a confidence level (confirmed / probable / to be validated). Without this filter, a report fills with noise and loses credibility.

We consolidate everything into the module's final deliverable: the prioritized list of candidate vulnerabilities. It combines severity (indicative CVSS), exposure, and confidence after validation:

How to read it:

• The critical items combine high severity, exposure, and a plausible access route: the SQLi on the store (primary target, on the Internet) and the Werkzeug debug console (possible command execution).
• MySQL 5.5 shows a sky-high CVSS but stays "to validate" because of Ubuntu's possible backport: it's checked before taking it as good.
• The confirmed configuration findings (SMB null session, .bak/.git, SNMP public) are solid even though their CVSS is lower, because they don't depend on a version and are already verified.

This table is exactly what Module 4 needs: where to try to get in first, with associated evidence and confidence.

Against vulnerability detection, the defense is played out in vulnerability management:

• Patch and keep support. The bulk of this list evaporates by updating: supported PHP and MySQL, dependencies up to date. Don't run end-of-life software.
• Regular self-scanning. The defender should run Nessus/OpenVAS before the attacker does and prioritize by CVSS and exposure.
• Fix configurations. Remove .bak, phpinfo.php, and .git from production; close the null session; change the SNMP community; disable Werkzeug's debug mode.
• Detection: vulnerability scanners are very noisy; an IDS/IPS and log monitoring detect the flood of requests and probes. Having the client see your scan in their alerts is, in fact, a good sign for their SOC.

• Copying the scanner's output as-is. Without validation, the report fills with false positives and loses credibility. Always validate before reporting.
• Ignoring the distribution's backports. A CVE "detected" by version may already be patched in Ubuntu/Debian. Check the real patch status.
• Launching scanners without notice. They're intrusive; some scripts (DoS, brute force) can take services down. An agreed window and notice to the technical contact, always.
• Confusing detecting with exploiting. Here you produce prioritized candidates; launching the exploit is Module 4 and requires scope to authorize it.
• Obsessing over the CVSS. A SQLi on the public web weighs more than a CVSS 9.8 on an unreachable service. Cross severity with exposure and confidence.
• Forgetting the configuration findings. A null session, an exposed .git, or SNMP public have no CVE but are often the most reliable routes. Don't underrate them.
• Tip: always combine scanner + manual search + validation. Automation covers volume; human judgment decides what's real and what matters.

Exercise 1. A Nessus scan flags MySQL 5.5.62 as CRITICAL (CVSS 9.8) on dev. Describe the steps you'd take to validate whether it's a real finding or a false positive, without going as far as exploiting it, and mention at least one common cause of false positive on Ubuntu.

Exercise 2. From TechNova's inventory you have two candidates: (a) a possible SQLi at tienda.technova.lab/producto.php?id= (Internet, primary target) and (b) an OpenSSH 7.6 user-enumeration CVE on dev (internal). Both "detected" by a scanner. Prioritize for Module 4 and justify by crossing severity, exposure, and confidence.

Exercise 3. Explain why a finding without a CVE like the SMB null session with the accessible RRHH share can be more valuable for Module 4 than a CVE with CVSS 9.8 detected only by version number.

Solution 1. Validation steps: (1) confirm the exact version with nmap --script mysql-info and the banner, don't rely on the scanner alone; (2) check the patch status: on Ubuntu the packages keep the version number (5.5.62-0ubuntu…) even when security fixes have been backported —a common cause of false positive—, so you have to look at the package changelog and Ubuntu's security advisories (USN); (3) cross sources: see whether searchsploit and the NVD confirm that the CVE applies to that specific build and that the affected functionality is in use; (4) tag the candidate as "confirmed" or "discarded" per the result. All of it without launching the exploit: we only verify applicability.

Solution 2. Priority: 1st (a) the store's SQLi. Even though a scanner flags both, the SQLi combines very high severity (potential access to the database), maximum exposure (Internet, the scope's primary target), and a direct access route; it's validated with a light manual check (id=1') that quickly raises confidence. 2nd (b) the OpenSSH user enumeration: medium severity, low exposure (internal host), and it only yields usernames, not access; it's useful as support (feeds password attacks), not as a primary route. The criterion: at equal "detected by scanner", exposure and real impact rule.

Solution 3. Because the SMB null session is confirmed and directly actionable: we already know it gives access to real users and to RRHH documents without credentials, it's a real, verified route. By contrast, a CVSS 9.8 CVE "detected only by version number" is an unvalidated suspicion: it may be a false positive (backported patch), it may require conditions that aren't met, or it may lack a reliable exploit. In pentesting, a modest confirmed route is worth more than an uncertain critical one: the first is an entry point; the second, still a hypothesis.

We close Module 3. We started with a list of live hosts and, step by step, turned it into something actionable: first the open ports (03-01), then the services with versions (03-02), and now a prioritized list of candidate vulnerabilities (03-03), each with its reference, its indicative severity, and —most importantly— its confidence level after validation. We learned the common language (CVE, CPE, NVD, CVSS), to search by hand (searchsploit/exploit-db) and with scanners (--script vuln, Nessus, OpenVAS, nuclei), and to read their results critically so as not to drown in false positives.

Recapping the whole module: reconnaissance told us where to look; scanning and enumeration have told us what's exactly there and what of it is weak. TechNova is no longer a black box: we know its store exposes a probable SQL injection and sensitive files, that dev runs a debug console and an outdated exposed database, and that the internal network gives away information over SMB and SNMP. All documented, validated, and ordered by priority.

And here the work of "identifying" ends. So far we haven't exploited anything: we've drawn the map of weak doors. In Module 4: Vulnerability Exploitation, we'll take the number-one candidate from this list and move —always within scope, with explicit permission and impact control— from "this looks vulnerable" to "this is exploitable and this is what an attacker would get". The first lesson, 04-01 Introduction to Exploitation, starts right here: with our prioritized list of candidate vulnerabilities in hand.