Systems Vulnerability Scanning

A company deploys a new web server, opens it to the internet, and moves on to the next task. Three weeks later an attacker finds an outdated FTP daemon running on port 21 with a known remote code execution bug, and they never had to guess. All they did was ask the server a series of simple questions: which ports are open, what's listening on them, and what version is it running. Vulnerability scanning is the automated process of asking a system or network exactly those questions, systematically, and comparing the answers against known lists of weaknesses.

Security teams run the same scans defensively, before an attacker gets the chance, so the sequence of steps matters as much as the tools that execute them.

The Scanning Pipeline

A scan is not one action. It's a pipeline where each stage feeds the next one.

• Open port and service identification: find what's reachable and what's running on it
• Banner or version check: pull the exact software name and version
• Traffic probe: send crafted requests to confirm behavior when a banner is missing or lying
• Vulnerability probe: actively test whether a known flaw is exploitable on this specific target

Skip a stage and the scan degrades. No open port means no service to identify. No service identity means you have nothing to check against a vulnerability database.

flowchart LR
    A["Open Port and Service Identification"] --> B["Banner and Version Check"]
    B --> C["Traffic Probe"]
    C --> D["Vulnerability Probe"]
    D --> E["Vulnerability Report"]

Open Port and Service Identification

You can't attack, or defend, a door that you don't know exists. Port scanning is the reconnaissance stage where a scanner sends probes to a range of ports on a target and classifies each one as open, closed, or filtered.

• Open: something is actively listening and will complete a handshake
• Closed: the host responds, but nothing is listening on that port
• Filtered: a firewall or ACL drops or blocks the probe, so no clear answer comes back

The most common technique is the TCP connect scan, where the scanner attempts a full three-way handshake (SYN, SYN-ACK, ACK). If the handshake completes, the port is open. Once open ports are known, the scanner hands that list to the next stage, since the list of open ports is the direct input for the service scanning module and there is no service to identify without an open port.

[!NOTE]
Port scanning by itself does not confirm a vulnerability. It only confirms that a conversation is possible.

Banner/Version Check

An open port tells you a door exists. It doesn't tell you who's behind it. Banner grabbing is the technique of connecting to an open port and reading whatever text the service volunteers back, since many services like FTP, SSH, SMTP, and some HTTP servers announce themselves with a banner that includes their name and version.

Connect to a mail server on port 25 with a basic TCP client and it will often introduce itself unprompted.

nc mailserver.example.com 25

If the connection succeeds, the first line printed back is usually the banner, something like 220 mailserver ESMTP Postfix. That single line names the software and the version, which is exactly what you need to check it against a vulnerability database.

• Without banner grabbing: you know port 22 is open, but not whether it's an ancient, exploitable SSH build or a fully patched one
• With banner grabbing: you know it's OpenSSH 7.2, and you can look up exactly which CVEs apply to that version

Traffic Probe

Not every service is polite enough to announce itself. Some stay silent until spoken to in their own protocol. A traffic probe is an active method where the scanner sends a specific, protocol-aware request and studies the response, rather than waiting passively for a banner.

The clearest example is an HTTP probe against a web port.

curl -I http://target.example.com:8080

Sending HEAD / HTTP/1.1 to a port and reading back a Server: header or a 200 OK status line tells the scanner this is a web service, even if the banner itself is vague or has been deliberately stripped. This matters because relying on port number alone is unreliable. Nmap's version detection flag automates this exact behavior at scale, since Nmap can perform banner grabbing with its version detection feature using the -sV flag, which not only confirms the service's identity but also provides additional details like SSL support or custom configurations.

Vulnerability Probe

Knowing a service's name and version is still just information. A vulnerability probe takes the next step: it sends a controlled, often malicious-looking request designed to trigger or confirm a specific known flaw. As one description puts it, a vulnerability probe is a method of actively testing a system by sending specific packets or requests to identify potential weaknesses, essentially a controlled attempt to poke at a system to discover potential security flaws that a malicious actor could exploit.

[!WARNING]
Running vulnerability probes against systems you don't own or have written permission to test is illegal in most jurisdictions, even if the intent is educational. Always work in an isolated lab or an authorized environment.

Vulnerability Examples

Real vulnerabilities that scanners commonly surface fall into a few recurring patterns.

• Outdated software versions: an old Apache or OpenSSH build with a public CVE and no patch applied
• Default or weak credentials: admin panels, databases, or routers left on factory-set logins
• Misconfigured services: an FTP server allowing anonymous login, or a database bound to 0.0.0.0 instead of localhost
• Unpatched protocol flaws: issues like Heartbleed in older OpenSSL versions, discoverable purely from the version banner

Once a scanner finds a match between a discovered version and a known CVE, tools like Metasploit are frequently used afterward to validate whether the flaw is truly exploitable in that environment, rather than just theoretically present.

MCQ

Networks Vulnerability Scanning

You've seen the four stages a scan moves through conceptually. Now it's time to see them executed with real tools, starting with the simplest one available on almost every system.

Netcat: The Manual Building Block

Every automated scanner is ultimately built from the same primitive: open a socket, send bytes, read what comes back. Netcat (nc) is a command-line utility that does exactly this and nothing more, which is precisely why it's so useful for understanding scanning by hand before trusting a tool's summary output. As one guide describes it, Netcat is a network utility that establishes TCP or UDP connections, enabling bidirectional data transfer between two endpoints, and unlike specialized tools it works at the transport layer, making it flexible for any network task involving sending or receiving data.

Scanning a Port Range with Netcat

You want to know which ports are open on a host without sending any real data, just testing for a response.

nc -zv 10.1.1.1 1-100

The -z flag enables zero-I/O mode, meaning Netcat probes each port without sending a payload, and -v prints verbose output as it goes. This scans ports 1 through 100 on the IP address, and the -z flag tells Netcat to scan the ports without establishing a full connection while -v enables verbose output.

Grabbing a Banner with Netcat

You want to see exactly what a specific service says the moment you connect.

nc -v target.example.com 22

Connecting directly to port 22 like this and waiting a second is often enough for the SSH daemon to print its own version string unprompted, since this command connects to a service and retrieves its banner information, revealing service type and version details useful for vulnerability assessment.

• Automated scanner: runs the full pipeline, cross-references a CVE database, and hands you a report
• Netcat: runs one step at a time, by hand, so you see exactly what the automated tool is inferring underneath

[!TIP]
When a scanner's report looks wrong or ambiguous, dropping down to Netcat and connecting to the port yourself is often the fastest way to confirm what's actually happening on the wire.

Understanding Port and Service Tools

Ports alone are just numbers. What turns a number into useful information is a consistent mapping between ports and the services conventionally run on them.

Scanners use this mapping as a starting hint, never as proof. A service can be moved to a non-standard port deliberately, so tools always confirm the guess with a banner check or a traffic probe rather than trusting the port number alone. This is also why UDP-based services like DNS and SNMP are handled differently in tooling. Unlike TCP, UDP has no handshake to confirm a connection, so the absence of a handshake mechanism means UDP scans sometimes generate ambiguous responses from closed ports and might be ignored by open ports, and many UDP services only respond to probes customised to their target.

Network Reconnaissance: Nmap

Netcat tests one port at a time by hand. Nmap (Network Mapper) automates the entire discovery pipeline, port scanning, service identification, version detection, and even OS fingerprinting, across an entire network in one command. It remains the standard tool for network reconnaissance, since Nmap is a free, open source and cross-platform tool used for network discovery and audits, supporting scanning options and automated scripts to perform network reconnaissance and discover vulnerabilities.

Step 1: Discover Live Hosts

Before scanning individual ports, you first need to know which machines on a subnet are actually alive.

sudo nmap -sn 192.168.1.0/24

This is a ping sweep. It skips port scanning entirely and just reports which hosts respond, giving you a target list for the next step.

Step 2: Run a SYN Scan for Open Ports

For each live host, you now want a fast, low-noise picture of open ports.

sudo nmap -sS -F 192.168.1.10

A SYN scan sends a TCP packet with only the SYN flag set and never completes the handshake, since Nmap sends a TCP packet to a port with the SYN flag set, and if the target responds with an RST packet, that signifies the port is closed. The -F flag limits the scan to the most common 1000 ports for speed.

Step 3: Identify Service Versions

Open ports are only half the picture. You now want to know exactly what's running on each one.

sudo nmap -sV 192.168.1.10

This sends service-specific probes to identify what is actually running on each open port, effectively automating the manual banner grabbing you did earlier with Netcat, but across every open port at once.

Step 4: Fingerprint the Operating System

Knowing the OS underneath a host helps narrow down which vulnerabilities are even plausible.

sudo nmap -O 192.168.1.10

Adding -O tells Nmap to send a series of probes designed to fingerprint the TCP/IP stack of the target, since different operating systems implement TCP/IP slightly differently, and these implementation details create a fingerprint that Nmap matches against a database.

Combining Everything: Aggressive Scan

Running four separate commands works, but for a single well-understood lab target, Nmap can combine them.

sudo nmap -A 192.168.1.10

The aggressive scan option, denoted by -A, combines various scanning techniques such as TCP SYN scanning, version detection, OS detection, and script scanning into a single command, providing comprehensive insights into target hosts but potentially increasing the risk of detection.

[!IMPORTANT]
Only run -sS, -O, or -A scans against hosts and ranges you own or are explicitly authorized to test. Unauthorized scans can trigger legal issues and be treated as hostile reconnaissance, so scope and permission should always be documented before scanning.

• Netcat: you drive, one port at a time, full manual control
• Nmap: the pipeline drives, one command sweeps a whole subnet and cross-references OS and service databases automatically

MCQ

Network Sniffers and Injection Tools: Wireshark

Port scanners like Nmap ask questions and wait for direct answers. A different class of tool takes a completely different approach: it doesn't ask anything at all, it just listens to everything already flowing past.

Why Sniffing Is a Different Kind of Reconnaissance

Network sniffing is the practice of capturing packets as they travel across a network segment, whether or not they were addressed to your machine. Where Nmap generates its own traffic to provoke a response, a sniffer stays passive and simply observes, which makes it useful for spotting things a scan would never trigger: leaked credentials in plaintext protocols, unusual traffic patterns, or an active attack already in progress on the wire.

• Active scanning (Nmap): send a probe, get a direct answer, repeat across many ports
• Passive sniffing (Wireshark): capture what's already there, then filter and interpret it after the fact

Wireshark: Capturing and Filtering Traffic

Wireshark is the standard open-source tool for this job. It is an open-source packet analyzer that enables real-time data inspection, supports many network protocols, and can transform network packets into human-readable data.

Step 1: Choose an Interface and Start Capturing

You first need to tell Wireshark which network interface to listen on.

Open Wireshark, choose the network interface, then start capturing by clicking the interface and selecting "Start."

Step 2: Narrow the Capture with a Capture Filter

Capturing everything on a busy network produces an overwhelming amount of data before you've even started analyzing.

tcp port 80

Applying this in the capture options before you even start listening means Wireshark only records HTTP traffic from the outset, since Wireshark's capture filters provide a way to capture only the desired traffic, and you can click on Capture Options and use capture filters before selecting the interface.

Step 3: Narrow an Existing Capture with a Display Filter

Sometimes you've already captured broadly and now need to isolate something specific within that capture.

arp

Typing this into the display filter bar hides every packet except ARP traffic, since applying the ARP filter in the display filter bar focuses the view on ARP packets so you can observe normal ARP traffic, devices asking for and receiving MAC addresses.

Detecting Injection: ARP Spoofing

Injection tools don't just listen, they actively insert forged traffic onto the network to manipulate it. The most common example taught alongside Wireshark is ARP spoofing, where an attacker sends forged ARP replies so that other devices update their ARP tables to point at the attacker's machine instead of the real gateway.

• MAC spoofing: the practice of changing a network interface's Media Access Control address to imitate another device on the network
• IP spoofing: the practice of forging a packet's originating IP address to make it appear to come from a trusted source
• DNS spoofing: manipulation of the Domain Name System to redirect a user to a fake website

[!CAUTION]
ARP spoofing only works within the same local network segment, since it operates at OSI Layer 2. This attack is specifically targeted towards Layer 2, the data link layer, so it can be executed only from within your network, and cannot be used from outside the local network to sniff traffic between a computer and a remote server. Only ever perform this in a lab you own or have written authorization to test.

Wireshark doesn't perform the spoofing itself, but it's the primary tool for detecting it after the fact. The signal to look for is unsolicited or duplicate ARP replies claiming the same IP address maps to two different MAC addresses, since Wireshark allows inspection of packets at various layers of the network stack including Ethernet, ARP, and IP, and helps identify abnormal ARP activity to detect potential ARP spoofing attacks.

MCQ