Post cover image
From network reconnaissance to evidence-based security findings: a hands-on assessment using Kali Linux, Ubuntu and Nmap.

October 19, 2026

Beyond Open Ports: My Practical Nmap Lab and Risk-Based Vulnerability Assessment

How I used Nmap, Kali Linux and Ubuntu to move from network reconnaissance to evidence-based security findings.

By Ajibade Michael

9 min read

By Ajibade Michael | Cybersecurity Researcher and Penetration Testing Enthusiast

Introduction

When I started this project, my objective was not simply to run Nmap and identify open ports. I wanted to understand what those results actually meant from a security perspective.

Finding an open port is useful, but it does not necessarily mean a system is vulnerable. A service might be intentionally exposed, its software might already be patched, or its configuration might introduce risks that a basic scan cannot identify.

That distinction became an important part of this practical assessment.

I built an isolated virtual laboratory using Kali Linux and Ubuntu, conducted network reconnaissance, examined the services running on the target machine and validated selected findings directly on the host.

The purpose was to demonstrate how network scanning results can support a broader, risk-based vulnerability assessment.

This article documents my methodology, technical observations, challenges and key lessons.

1. Setting Up the Laboratory

Before conducting any scanning, I established a controlled environment using VMware.

The laboratory consisted of two virtual machines:

ComponentConfigurationAttacking/assessment machineKali Linux 2025.1aTarget machineUbuntu 22.04.5 LTSNetwork scanning toolNmap 7.95Virtualisation platformVMwareNetwork192.168.249.0/24Kali IP address192.168.249.132Ubuntu IP address192.168.249.131

Both machines were under my control, and the network was deliberately isolated from the public internet.

The Ubuntu machine also contained a synthetic MedTechCare database environment configured for an earlier MSc proof of concept. This provided an opportunity to examine database service exposure and account permissions.

Ethical scope: All testing was performed within my authorised personal laboratory. No external targets, real patient records, exploitation or credential attacks were involved.

None

2. Network Discovery: Identifying Active Hosts

My first task was to identify the network configuration of the Kali Linux machine.

I used:

ip addr
nmap --version

These commands helped me establish the local IP address, subnet and installed Nmap version.

After confirming that the Ubuntu machine was reachable, I performed host discovery:

sudo nmap -sn 192.168.249.0/24

The -sn option performs host discovery without carrying out a port scan.

Observation: Four hosts responded within the isolated subnet.

Although multiple addresses responded, I restricted further service enumeration to the authorised Ubuntu target at 192.168.249.131.

This stage reinforced an important principle: discovering a device does not automatically mean that it is within the scope of a detailed security assessment.

None

3. TCP Port Scanning: Identifying Exposed Services

Once I had confirmed the target, I began examining its TCP ports.

I started with a default Nmap scan:

sudo nmap 192.168.249.131

The scan identified two open ports:

PortService22/tcpSSH3306/tcpMySQL

SSH provides remote administration functionality, while MySQL is a relational database management system.

Both services can be legitimate, but their security implications depend on factors such as network exposure, authentication, privileges and configuration.

To extend the assessment beyond Nmap's default selection of common ports, I conducted a full TCP scan:

sudo nmap -p- 192.168.249.131

The -p- option instructs Nmap to scan all 65,535 TCP ports.

Results:

  • 2 TCP ports open.
  • 65,533 TCP ports closed.

The results confirmed that SSH and MySQL were the only TCP services identified as open during this scan.

This did not establish whether either service was vulnerable. It provided the starting point for more targeted investigation.

None

4. Service Version Detection

Identifying open ports tells us which services are accessible. The next step is to establish more information about the software behind those services.

I used Nmap's service version detection:

sudo nmap -sV -p 22,3306 192.168.249.131

The -sV option probes open ports to identify service versions.

The scan identified:

ServiceReported versionOpenSSH8.9p1, Ubuntu packageMySQL8.0.46

At this point, it would have been easy to search for vulnerabilities affecting the reported software versions and classify the target as vulnerable.

However, doing so without further verification could lead to an inaccurate conclusion.

Linux distributions such as Ubuntu may backport security patches while retaining an older upstream version number.

Consequently, the version reported remotely by Nmap may not provide enough information to determine whether a particular vulnerability affects the installed package.

This was particularly relevant when reviewing OpenSSH.

None

5. Operating System Detection

I also attempted operating system fingerprinting using:

sudo nmap -O 192.168.249.131

The -O option uses network responses to estimate a target's operating system.

In this case, Nmap returned ambiguous Linux and router-related fingerprints rather than an exact operating system match.

Because I controlled the target, I could verify the operating system locally using:

lsb_release -a

The result confirmed Ubuntu 22.04.5 LTS.

This highlighted a limitation of remote fingerprinting: scanning tools make inferences from observed network behaviour, and those inferences are not always definitive.

Where authorised host access is available, local verification can improve the accuracy of an assessment.

6. SSH Security Assessment

With SSH identified on TCP port 22, I examined the algorithms advertised by the service.

I used Nmap's scripting engine:

sudo nmap -p 22 --script ssh2-enum-algos 192.168.249.131

The ssh2-enum-algos script enumerates cryptographic algorithms supported by the SSH server.

The results showed a mixture of modern algorithms and some SHA-1-based message authentication code (MAC) compatibility options.

This was treated as a configuration-hardening observation rather than evidence of an exploitable weakness.

Whether particular algorithms should be disabled depends on an organisation's cryptographic policy, compatibility requirements and accepted security baseline.

Checking CVE-2024–6387

I also reviewed the potential relevance of CVE-2024–6387, commonly known as regreSSHion, which affects certain versions of OpenSSH.

The remotely reported OpenSSH version initially made this worth investigating.

However, I verified the installed Ubuntu package using:

dpkg-query -W openssh-server

The installed package was:

1:8.9p1-3ubuntu0.16

Ubuntu's fixed package revision for CVE-2024–6387 was 1:8.9p1-3ubuntu0.10.

Because the installed package revision was newer than the vendor's fixed revision, I did not classify the target as unpatched for that vulnerability.

This was an important lesson for me.

A reported software version is not sufficient evidence that a vulnerability exists. Vendor patches and distribution-specific package revisions must also be considered.

None

7. MySQL Enumeration and Configuration Assessment

The next part of the assessment focused on MySQL, which was accessible over TCP port 3306.

I began by collecting information about the service's initial protocol response:

sudo nmap -p 3306 --script mysql-info 192.168.249.131

The mysql-info script provided information such as the server version and advertised authentication plugin.

I also performed a limited empty-password check:

sudo nmap -p 3306 --script mysql-empty-password 192.168.249.131

The script did not produce a positive finding.

However, I did not interpret this as proof that all database accounts had secure passwords. The check was limited in scope and did not constitute a full authentication audit.

Investigating Network Exposure

To understand how MySQL was configured, I examined its listening interface directly on Ubuntu.

sudo ss -lntp | grep ':3306'

The result showed that MySQL was listening on:

0.0.0.0:3306

This meant the service was bound to all IPv4 interfaces rather than only the local loopback interface.

I then checked the Ubuntu firewall:

sudo ufw status verbose

UFW was inactive.

Within this isolated laboratory, the configuration was intentional. However, in a production environment, a similar configuration could increase risk if untrusted systems were able to reach the database service.

None None

Reviewing Database Accounts and Privileges

I continued by examining the configured MySQL accounts:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

The assessment identified a deliberately configured account:

dbadmin@'%'

In MySQL, the % host pattern can allow an account to authenticate from multiple source hosts, subject to network reachability and other security controls.

I also reviewed the account's privileges:

sudo mysql -e "SHOW GRANTS FOR 'dbadmin'@'%';"

The account had extensive privileges on two synthetic laboratory databases.

These were database-scoped permissions, not unrestricted global privileges across the entire MySQL server.

The configuration had been created for an earlier educational proof of concept, so it was not an unexpected vulnerability or evidence of compromise.

Nevertheless, it provided a useful example of why network exposure and access privileges should be assessed together.

The potential risk: If a similarly configured account existed in a production environment and an attacker obtained valid credentials, broad database permissions could increase the impact of unauthorised access.

Appropriate security measures would include restricting approved source hosts, limiting network accessibility and applying the principle of least privilege.

None None

8. Moving From Technical Findings to Risk-Based Assessment

One of my main objectives was to understand how technical security observations could support vulnerability prioritisation.

Rather than treating every open port or unusual configuration as a critical vulnerability, I considered the surrounding context.

For example:

ObservationRisk-based interpretationSSH accessible on port 22Expected administrative service; exposure and security configuration require reviewOpenSSH 8.9p1 identifiedInstalled Ubuntu package was checked against the relevant security advisorySHA-1-based SSH MAC optionsPotential hardening consideration depending on security policyMySQL listening on all IPv4 interfacesBroader network accessibility than a loopback-only configurationBroad-host MySQL accountPotentially increases exposure if deployed without appropriate restrictionsExtensive database-scoped privilegesCould increase the impact of account compromise in a production-like environment

The most significant configuration concern in this laboratory was the combination of MySQL network accessibility and the deliberately broad database account permissions.

However, this was still a controlled configuration within an isolated educational environment, not an exploited production vulnerability.

A risk-based assessment should consider the affected asset, exposure, likelihood of misuse, potential impact, compensating controls and confidence in the evidence.

This makes prioritisation more meaningful than relying only on a scan result or software version.

9. Challenges and Limitations

The project also highlighted several practical limitations.

Operating system fingerprinting: Nmap could not reliably identify the exact operating system remotely, requiring host-side verification.

Patch verification: The isolated Ubuntu environment could not reach package repositories to refresh its package indexes. I could verify the installed OpenSSH revision against the relevant Ubuntu advisory, but I could not establish that every installed package was fully up to date.

Scope: The assessment covered TCP scanning of one authorised Ubuntu host. It did not include UDP scanning, exploitation, password attacks or application-layer security testing.

Scanner interpretation: A negative result from a limited script, such as mysql-empty-password, did not justify a broad claim that authentication was secure.

These limitations reinforced why technical findings should be documented with appropriate confidence levels and clear boundaries.

10. Key Lessons Learned

Looking back at the project, five lessons stood out.

1. Reconnaissance is the beginning, not the conclusion.

Identifying hosts and open ports provides valuable information, but those observations require further investigation before drawing security conclusions.

2. Tool output needs interpretation.

Nmap is powerful, but understanding the significance of its findings requires knowledge of protocols, operating systems and system configuration.

3. Verification improves assessment quality.

Checking the Ubuntu package revision helped me avoid incorrectly reporting CVE-2024–6387 as an unpatched vulnerability.

4. Security risk depends on context.

The significance of an exposed service depends on how it is configured, who can reach it and what an attacker could potentially achieve.

5. Evidence matters.

Documenting commands, scan outputs, configuration checks and limitations made the findings more transparent and easier to review.

Conclusion

This project gave me a practical opportunity to develop my network reconnaissance and vulnerability assessment skills while applying a more evidence-driven approach to security testing.

Using Nmap, I identified active hosts, enumerated TCP services, collected service information and examined selected SSH and MySQL security configurations.

More importantly, I learned why vulnerability assessment should go beyond automated scanner output.

The assessment demonstrated how direct verification and an understanding of system context can help distinguish confirmed configurations, potential security concerns and unsupported vulnerability claims.

As I continue developing my skills in penetration testing and cybersecurity risk assessment, I intend to build on this approach through further practical labs and documented security research.

Project Repository and Technical Evidence

The full project, including my methodology, Nmap scan results, 15 supporting screenshots and chronological assessment report, is available on GitHub:

Nmap Network Scanning & Risk-Based Vulnerability Assessment.

References and Further Reading

All scanning was performed in an isolated, authorised educational environment using systems under my control. The project is intended for cybersecurity learning, technical documentation and responsible security research.

All scanning was performed in an isolated, authorised educational environment using systems under my control. The project is intended for cybersecurity learning, technical documentation and responsible security research.