Network Recon with Kali Linux

Discover hosts, scan ports, and find hidden web directories on your local network.

Introduction

30 Second Summary

Every time you connect to a Wi-Fi network, dozens of devices surround you. Printers, smart TVs, other laptops, and servers are all quietly listening on open ports. A penetration tester's first job is to figure out exactly what is out there before trying anything else.

In this project, you will use professional reconnaissance and enumeration tools inside Kali Linux to discover live hosts, map open ports, identify running services, and uncover hidden web directories on a safe, local practice target.

What You'll Build

By the end, you will run a scan against your own lab server and watch the terminal reveal hidden admin panels and backup directories that no one would find by clicking around the website.

By the end of this project, you'll have:

A host discovery workflow that identifies every live device on your network segment using ARP-based scanning.
A detailed service enumeration report showing exactly which ports are open and what software versions are running behind them.
Proof that directory brute-forcing can uncover hidden web content in seconds, even when nothing links to it from the homepage.
Secret Mission: a bash script that automates the entire recon pipeline into a single command you can reuse on future engagements.

Are there any prerequisites?

This project assumes you already have Kali Linux installed and running inside Oracle VirtualBox. You should be comfortable opening a terminal and typing basic commands.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

In this project, you'll work through the same reconnaissance-to-enumeration pipeline that professional penetration testers follow on every engagement. You'll scan your own local lab environment to discover hosts, map open ports, identify service versions, and uncover hidden web directories.

Prepare Your Kali Lab Environment

Every penetration test starts with the same challenge: you need something to scan. Scanning random machines on the internet is illegal without written authorization.

In this step, you'll set up a safe, local practice target by starting a web server on your own Kali Linux VM. You'll also confirm your scanning tools are ready and plant some hidden content for later discovery.

In this step, get ready to:

Update your Kali system and confirm your scanning tools are installed.
Start Apache2 as a safe local target to scan.
Create hidden web directories that you'll discover later with enumeration tools.

Update Kali and verify your network interface

Before scanning anything, you need your tools to be current. An outdated tool set can miss vulnerabilities or produce unreliable results.

Update all system packages by running this command:

sudo apt update && sudo apt full-upgrade -y

What does this command do?

This is actually two commands joined by &&. The first (apt update) refreshes your list of available packages. The second (apt full-upgrade) installs the latest versions of all packages on your system.

The -y flag automatically confirms prompts so you don't have to type 'yes' repeatedly.

Seeing a 'Could not resolve' error?

This means your VM cannot reach the internet. Check that your VirtualBox network adapter is set to NAT or Bridged mode in the VM settings.

help me fix my Kali Linux internet connection in VirtualBox

This upgrade may take a few minutes depending on your internet speed. Once it finishes, you'll see a command prompt again.

Identify your network interface and IP address by running:

ip a

You'll see a list of network interfaces. Look for one named eth0 or enp0s3 with an inet address (something like 10.0.2.15). Write this IP address down. You'll need it later.

Confirm Nmap is installed by running:

nmap --version

You should see version information printed to your terminal, confirming Nmap is ready to use.

Command not found?

Nmap comes pre-installed on Kali Linux. If you see 'command not found', install it by running sudo apt install nmap.

help me install Nmap on Kali Linux

Start Apache2 as your practice target

Kali Linux includes Apache2 (a web server) by default, but it's disabled. You'll start it now to create a real HTTP service listening on port 80. This is your safe, legal scan target.

Start the Apache2 web server by running:

sudo systemctl start apache2

Before you check the result, what do you think the status will show? Active or inactive?

Check that Apache2 is running by running:

sudo systemctl status apache2

You should see active (running) in green text. This confirms the web server is listening and ready to serve pages.

What is systemctl?

The systemctl command manages system services on Linux. You use start to launch a service, stop to shut it down, and status to check whether it's currently running.

Open the web browser inside your Kali VM (click the browser icon in the taskbar or search for Firefox).
Navigate to http://127.0.0.1 in the address bar.

You should see the Apache2 Debian Default Page. This is proof that your web server is up and serving content on port 80.

Seeing 'Unable to connect'?

Go back to your terminal and run sudo systemctl status apache2 again. If it shows 'inactive' or 'failed', try starting it again with sudo systemctl start apache2.

help me troubleshoot Apache2 not starting on Kali Linux

Create hidden directories for later enumeration

Real web servers often have directories that aren't linked from the homepage. Admin panels, backup folders, and config pages sit at paths you'd never find by clicking around. You'll plant two of these now so you can discover them with a scanning tool later.

Create the hidden directories and their content by running these commands:

sudo mkdir -p /var/www/html/admin
echo "<h1>Admin Panel</h1>" | sudo tee /var/www/html/admin/index.html
sudo mkdir -p /var/www/html/backup
echo "<h1>Backup Files</h1>" | sudo tee /var/www/html/backup/index.html

What does this code do?

You're creating two directories (/admin/ and /backup/) inside Apache's document root at /var/www/html/. Each gets an index.html file so Apache can serve a page when someone visits that path.

The tee command writes text to a file while also printing it to your screen. The -p flag on mkdir means 'create parent directories if they don't exist'.

You should see each <h1> line echoed back to your terminal as the files are created.

Confirm the directories exist by running:

ls /var/www/html/

You should see admin, backup, and index.html listed in the output.

What do you think you'll see if you visit one of these hidden paths in the browser?

Open http://127.0.0.1/admin/ in your Kali browser to verify the hidden page is served.

You should see a page that says Admin Panel. This directory is now live on the server, but nobody visiting the homepage would know it exists. That's exactly what enumeration tools are designed to find.

Seeing a 404 Not Found?

Make sure you included the trailing slash in the URL (/admin/ not /admin). Also confirm the tee commands completed without errors by running cat /var/www/html/admin/index.html to check the file contents.

help me fix my Apache2 hidden directories not loading

Your lab is ready. You have a live web server with hidden content that no one would find by simply browsing. Next up, you'll use real scanning tools to discover what's alive on your network.

Discover Live Hosts on Your Network

Your lab environment is locked and loaded. Apache is serving content on port 80, and hidden directories are waiting to be found later.

A penetration test starts by mapping what exists on the network. You cannot attack what you cannot see. In this step, you'll use ARP-based scanning to discover every live host on your local network segment.

In this step, get ready to:

Run an ARP scan to discover all live hosts on your local network.
Verify your findings with a second host-discovery tool.

Discover hosts using ARP scanning

The ARP (Address Resolution Protocol) maps IP addresses to physical MAC addresses on a local network. By sending ARP requests to every possible address on your subnet, you can find out which hosts are alive and responding.

Before you run this, how many devices do you think are on your network? Think about it: your Kali machine, the VirtualBox gateway, and potentially other devices.

Discover all live hosts on your local subnet by running this command:

sudo arp-scan --localnet

What does this command do?

sudo runs the command with root privileges, which is required for sending raw ARP packets.
arp-scan is a command-line tool that uses the ARP protocol to discover and fingerprint IP hosts on the local network.
--localnet generates addresses from your interface configuration, covering your entire local subnet including network and broadcast addresses.

You should see a table of results with three columns: IP addresses, MAC addresses, and vendor names for each responding host.

Look for your own Kali machine's IP address (the one you noted from ip a in Step 1).
Look for the VirtualBox gateway address (typically the .1 or .2 address on your subnet, such as 10.0.2.1 or 10.0.2.2).
Note how many hosts responded at the bottom of the output.

Not seeing any results?

Make sure you included sudo at the start of the command. ARP scanning requires root privileges to send raw packets.
Confirm your network interface is active by running ip a and checking that your interface shows an IP address.
help me troubleshoot why arp-scan is not finding any hosts on my network

Understand what you found

You now have a list of live hosts, but confirming results with a second tool is good practice. Different tools use different techniques, and comparing their output catches anything one tool might miss.

Compare your arp-scan results with the IP address you noted from ip a in Step 1. Your own machine should appear in the scan results.
Identify the VirtualBox gateway. It is typically the lowest-numbered address on your subnet (.1 or .2). The vendor column may show "PCS Systemtechnik GmbH" or "Oracle" for VirtualBox-managed addresses.

Now run a second host-discovery tool to cross-check your results. netdiscover is an active/passive ARP reconnaissance tool that presents results in a different format.

Why use two tools?

Professional penetration testers never rely on a single tool's output. Each tool has its own detection method and presentation style. If both tools agree on the host list, you can be confident in your findings.

Note that netdiscover runs continuously and does not exit on its own. You will need to press Ctrl+C to stop it after results appear.
Run a second host-discovery scan by running this command (replace the subnet with your own network from Step 1, e.g. 10.0.2.0):

sudo netdiscover -r [[SUBNET="your subnet, e.g. 10.0.2.0"]]/24 -c 3

What does this command do?

netdiscover is an active/passive ARP reconnaissance tool built for network discovery.
-r tells it to scan a given range instead of using auto scan.
-c 3 sends each ARP request 3 times, which improves reliability on networks with packet loss.
/24 specifies the subnet mask (256 addresses).

Wait a few seconds for hosts to appear in the table, then press Ctrl+C to stop the scan.
Compare these results with your arp-scan output. Both tools should have found the same live hosts on your network.

Netdiscover not showing results?

Double-check that you replaced the subnet placeholder with your actual network address from Step 1 (the first three octets of your IP followed by .0).
Wait at least 5-10 seconds before pressing Ctrl+C. The tool needs time to receive ARP replies.
help me troubleshoot netdiscover not finding hosts on my Kali VM network

You now have a confirmed list of live hosts on your network, discovered by two independent tools. This is the foundation of every penetration test.

You know which hosts are alive, but you have no idea which services are running on them. Next up, you'll use Nmap to scan for open ports and find out which doors are open on your target.

Port Scan with Nmap

You have mapped out which hosts are alive on your network using ARP scanning. Now comes the next question: what services are those hosts actually running?

Ports are like doors into a machine. Each open port means a service is listening and potentially accessible to anyone on the network. In this step, you will use Nmap to discover which ports are open on your Apache target and then sweep your entire subnet.

In this step, get ready to:

Run a default Nmap scan against your Apache target to see which ports are open.
Perform a ping sweep of your entire subnet to compare Nmap's host discovery with arp-scan.

Run a default Nmap scan against your Apache target

You know Apache is running on 127.0.0.1 because you started it in Step 1. A basic Nmap scan will tell you which ports are open and what service names Nmap guesses are behind them.

Before you run it, think about what you expect to see. You started Apache on port 80. Do you think Nmap will tell you the exact Apache version, or just that port 80 is open?

Run a default port scan against your local machine by running this command:

nmap 127.0.0.1

You will see a table with columns for PORT, STATE, and SERVICE. Port 80 shows as 80/tcp open http. Notice what is missing: there is no version number. You cannot tell whether this is Apache, Nginx, or any other web server.

What does this output tell you?

Nmap's default scan checks the 1,000 most common ports and reports their state (open, closed, or filtered). It uses its built-in nmap-services database to guess the service name from the port number. Port 80 is almost always HTTP, so Nmap labels it http.

This is a guess based on convention, not a probe of the actual software. An attacker needs to know the exact software and version to find exploitable vulnerabilities. The basic scan alone is not enough.

Not seeing port 80 as open?

Confirm Apache is still running by executing sudo systemctl status apache2. If it shows inactive, start it again with sudo systemctl start apache2.

If you see a different port open instead, your system may have other services running. Port 80 is the one we care about for this project.

help me troubleshoot why Nmap is not showing port 80 as open on my Kali VM

Try scanning the full network you discovered

In Step 2 you used arp-scan to find live hosts on your subnet. Nmap has its own host discovery mode called a ping sweep. It sends probes to every address in a range and reports which ones respond.

Run an Nmap ping sweep against your subnet by running this command (replace the subnet with the one you noted from Step 1):

nmap -sn [[SUBNET="your subnet, e.g. 10.0.2.0"]]/24

What does -sn do?

The -sn flag means "Ping Scan - disable port scan." Nmap sends discovery probes (ICMP echo, TCP SYN to port 443, TCP ACK to port 80, and ICMP timestamp) but does not follow up with a port scan on each host. This makes it fast for simply listing which hosts are alive.

Compare the results with your arp-scan output from Step 2.
Note which hosts appear in both scans, and whether any appear in one but not the other.

Nmap's ping sweep and arp-scan may find different hosts depending on firewall rules. This is normal. ARP operates at Layer 2 (data link) and cannot be blocked by IP firewalls, while Nmap's ping probes operate at Layer 3/4 and can be filtered.

Two tools, two perspectives

Professional pen-testers run multiple discovery tools because no single tool sees everything. ARP scanning is reliable on a local subnet but cannot reach beyond routers. Nmap ping sweeps can reach remote subnets but may be blocked by firewalls. Using both gives you the most complete picture.

Ping sweep showing no hosts?

Double-check that you replaced the subnet placeholder with your actual network address from ip a (e.g. 10.0.2.0). The /24 must come immediately after the base address with no space.

If you are using VirtualBox NAT mode, you should see at least your own Kali IP and the gateway (typically 10.0.2.2 or 10.0.2.3).

help me troubleshoot why my Nmap ping sweep is not finding any hosts

Your basic scan confirmed that port 80 is open and something called http is running behind it. But you still have no idea what version of web server software is there, or what content it serves. In the next step, you will unlock Nmap's version detection to pull those details out of the target.

Service Version Detection and Script Scanning

In the previous step, you ran a basic Nmap scan and confirmed that port 80 is open on your target. The scan told you the service is "http" but nothing more.

An attacker needs the exact software version to search for known vulnerabilities. Knowing that port 80 runs "http" is like knowing a building has a front door. You need to know the lock model. This step is where your reconnaissance becomes true enumeration.

In this step, get ready to:

Run an advanced Nmap scan with version detection and script scanning.
Interpret the enriched results and save them to a report file.
Attempt OS fingerprinting with Nmap's OS detection feature.

Run an advanced Nmap scan with version detection

Your basic scan from the previous step only showed port 80 as "open" with the generic label "http". That is not enough to find vulnerabilities. Version detection probes the open port to identify the exact software and version behind it.

Before you run this next command, think about what additional information you expect to see compared to the basic scan. Do you think Nmap will be able to tell you the specific web server software and its version number?

Run this advanced scan against your Apache target. It combines version detection, default scripts, and file output all in one command:

nmap -sV -sC -oN scan_results.txt 127.0.0.1

What do these flags do?

-sV probes open ports to determine service/version info. This is what reveals the exact Apache version.
-sC runs default safe scripts for additional enumeration. These scripts gather extra intelligence like page titles and server headers.
-oN scan_results.txt saves output in normal format to a file. Professional pen-testers always save their scan results for reporting.

You should now see significantly more detail than the basic scan. The output shows the Apache version number next to port 80, and script output lines starting with | that include the page title extracted by the http-title script.

Not seeing version details?

Make sure Apache2 is still running. Run sudo systemctl status apache2 to confirm it shows "active (running)". If it stopped, start it again with sudo systemctl start apache2.

help me troubleshoot why Nmap version detection is not showing Apache details on 127.0.0.1

Interpret the enriched results

The scan output is also saved to a file. This is how professional penetration testers work. They keep records of every scan for documentation and later analysis.

View your saved report by running:

cat scan_results.txt

What should I see in the results?

Compare this output with your basic scan from the previous step. The basic scan showed only "80/tcp open http" with no further detail.

The enriched scan reveals far more actionable intelligence. You should see the Apache httpd version number (e.g. Apache httpd 2.4.x), and a line like |_http-title: showing the page title of the default web page. This is the kind of detail an attacker uses to search for known vulnerabilities in a specific software version.

Why does version information matter so much?

Without a version number, an attacker is limited to generic checks. With a specific version, they can search vulnerability databases for exact exploits that affect that release. The difference between "http" and "Apache httpd 2.4.62" is the difference between guessing and targeted research.

Run an OS detection scan

Beyond identifying services, Nmap can also attempt to determine the operating system by analyzing how the target responds to specially crafted network packets. This technique is called OS fingerprinting.

Run an OS detection scan against your target by running:

sudo nmap -O 127.0.0.1

What does the -O flag do?

The -O flag enables OS detection. Nmap sends a series of TCP and UDP probes and compares the responses against a database of known OS fingerprints.

When scanning localhost, OS detection may not produce a clean match because loopback traffic bypasses the normal network stack behavior that Nmap relies on for fingerprinting. You may see an approximate guess or a message indicating no exact match was found. This is expected behavior for a localhost scan.

Observe the output. If Nmap identifies the OS, you will see it listed under "OS details". If not, you may see approximate guesses or a note that it could not determine an exact match.

Seeing a warning about needing root?

OS detection requires raw packet access, which means you need root privileges. Make sure you included sudo at the start of the command. Without it, Nmap cannot send the specially crafted probes needed for OS fingerprinting.

help me understand why nmap -O requires sudo and what to do if OS detection fails on localhost

You have now extracted detailed service information and attempted OS identification on your target. Your scan_results.txt file contains a professional-grade report showing the exact Apache version and script output. In the next step, you will use this knowledge to dig deeper into the web server content with directory enumeration.

Web Directory Enumeration with Gobuster

In the last step, you enriched your scan with version detection and default scripts. You now know Apache's exact version number and the page title running on port 80.

That tells you what software is running, but you still have no idea what content lives on the web server beyond the default page. Hidden admin panels, backup directories, and unlinked pages are common attack surfaces that basic scanning never reveals. In this step, you will brute-force directory names using Gobuster to uncover content that is not linked from the homepage.

In this step, get ready to:

Run Gobuster directory enumeration against your Apache target.
Save enumeration results and verify hidden directories in the browser.

Run Gobuster directory enumeration

Gobuster works by testing thousands of directory and file names from a wordlist against a web server. For each name, it sends an HTTP request and reports back any paths that return a valid response code.

Before you run this, what do you think Gobuster will find on your web server? You only see the Apache default page in your browser. Do you think there is hidden content lurking behind other paths?

Run Gobuster against your Apache server using the common.txt wordlist:

gobuster dir -u http://127.0.0.1 -w /usr/share/wordlists/dirb/common.txt

What does this command do?

gobuster dir tells Gobuster to use directory/file enumeration mode.
-u http://127.0.0.1 sets the target URL to scan.
-w /usr/share/wordlists/dirb/common.txt provides the wordlist of directory names to test. This file contains thousands of common directory and file names that web servers often host.

Watch the terminal as Gobuster tests each word from the list. After a few seconds, you should see results appearing with paths like /admin/ and /backup/ alongside their HTTP status codes (200 or 301).

What do the status codes mean?

A status code of 200 means the path exists and the server returned content directly. A status code of 301 means the path exists but the server is redirecting to a slightly different URL (often adding a trailing slash).

Both codes confirm the directory is real. These are the hidden directories you created in Step 1, discovered purely through wordlist brute-forcing.

Not seeing any results?

Confirm Apache is still running by executing sudo systemctl status apache2. If it shows inactive, restart it with sudo systemctl start apache2.
Check that the wordlist path is correct. Run ls /usr/share/wordlists/dirb/common.txt to confirm it exists.
If you see a connection refused error, port 80 is not listening. Restart Apache and try again.

help me troubleshoot why Gobuster is not finding directories on my local Apache server

Save results and verify in the browser

Professional pen-testers always save their scan output to files. This creates documentation for their report and lets them reference findings later without re-running scans.

Run Gobuster again with the -o flag to save the results to a file:

gobuster dir -u http://127.0.0.1 -w /usr/share/wordlists/dirb/common.txt -o gobuster_results.txt

Why run the scan again?

The -o flag tells Gobuster to write all discovered paths to gobuster_results.txt. You ran without it first so you could watch results stream in real-time. Now you are capturing them permanently for your reconnaissance report.

Open the Kali browser and navigate to http://127.0.0.1/admin/ to confirm the hidden content exists.

You should see a page displaying "Admin Panel" in large text. This directory was never linked from the Apache default homepage. The only way to find it was through brute-force enumeration.

Return to your terminal and review the saved results by running:

cat gobuster_results.txt

You should see a list of discovered paths including /admin/ and /backup/ with their status codes. This file is now part of your reconnaissance documentation.

Why is web enumeration critical?

These directories were completely invisible from the homepage. A normal user browsing the site would never know they exist. A wordlist attack found them in seconds.

In real engagements, hidden directories often contain admin interfaces, configuration backups, test files, or sensitive data that developers forgot to remove. Finding them is one of the highest-value steps in web application testing.

Browser shows a 404 or blank page?

Make sure you typed the URL with the trailing slash: http://127.0.0.1/admin/ not http://127.0.0.1/admin.
Verify the directory and file still exist by running ls /var/www/html/admin/index.html.
If the file is missing, recreate it with echo "<h1>Admin Panel</h1>" | sudo tee /var/www/html/admin/index.html.

help me fix my hidden directory setup so Gobuster results match what I see in the browser

Secret mission

Automate Your Recon Pipeline

Professional pen-testers do not type every command manually for each engagement. They script their workflows to save time and ensure consistency. Can you combine all the tools from this project into a single bash script that runs the full recon pipeline with one command?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally inside your Kali VM, so there are no ongoing costs.

Resources you used:

Apache2 web server running on port 80 inside your Kali VM.
Hidden directories at /var/www/html/admin/ and /var/www/html/backup/
Scan output files: scan_results.txt and gobuster_results.txt.
Recon script (recon.sh) and timestamped output directory.

Keep everything running

No action needed. Choose this if you plan to keep practising reconnaissance and enumeration techniques.

Apache2 stays active on port 80 for future scanning practice. It only runs inside your VM and is not accessible from the internet.
Your scan output files and recon script remain in place, ready for you to reference or rerun.
The hidden directories stay available as enumeration targets.

Pause - I'll come back to this later

Stop the running service to free up port 80, but keep all files and directories so you can restart later.

Stop Apache2 by running:

sudo systemctl stop apache2

Your scan files, recon script, and hidden directories all remain on disk.
When you want to resume, run sudo systemctl start apache2 to bring the web server back up.

Delete - I don't want to use this again

Remove all project resources and return your Kali VM to its pre-project state.

Stop the Apache2 service by running:

sudo systemctl stop apache2

Remove the hidden directories you created by running:

sudo rm -rf /var/www/html/admin /var/www/html/backup

Remove the scan output files by running:

rm scan_results.txt gobuster_results.txt

Remove the recon script and its output directory by running:

rm -rf recon.sh recon_127.0.0.1_*

Confirm everything is cleaned up by running ls in your working directory. You should no longer see the scan files, script, or output directories.

Nice Work!

You just completed a full network reconnaissance and enumeration workflow using the same tools that professional penetration testers rely on every day.

You've learned how to:

Discover live hosts on a network using ARP-based scanning tools (arp-scan and netdiscover), then map open ports and detect exact service versions with Nmap.
Brute-force hidden web directories with Gobuster to uncover content like /admin/ and /backup/ that are invisible from the homepage.
Save and organize scan output files (scan_results.txt, gobuster_results.txt) following the same documentation practices professional pen-testers use for reporting.
Secret Mission: Automated the entire recon pipeline into a reusable bash script (recon.sh) that runs host discovery, version scanning, and directory enumeration with a single command.

Ready to quiz yourself?