Do you actually know every device on your network right now? In most environments I've inherited, the honest answer is no. Unauthorized devices creep in through forgotten switches, shadow IT, or someone plugging a personal laptop into a wall port. Here's a 10-minute method I use to build a quick network inventory and detect rogue devices before they turn into a real problem.
The goal isn't a full CMDB rollout. You just need a snapshot of what's alive on your subnet, what IPs they hold, and whether you can account for each MAC address. If you can't match a device to a known hostname, asset tag, or user — that's your queue to investigate.
What You Need Before You Start
You need one machine on the target subnet with nmap and arp-scan installed. On Debian/Ubuntu:
sudo apt install nmap arp-scan
I also keep a text file called known-macs.txt on my admin workstation. Every time I deploy a server, switch, or AP, I append its MAC and a short note. This file is your baseline. Without it, you're just staring at a list of hex strings guessing what's what.
If you have access to your core switch or firewall, grab the DHCP lease table too. Cross-referencing nmap results with DHCP logs is what separates a real audit from a guess.
Quick Scan with arp-scan (Layer 2 First)
Start with arp-scan because it's fast and hits Layer 2 directly. It doesn't care about host firewalls blocking ICMP — if the NIC is alive and on the VLAN, it answers the ARP.
sudo arp-scan --interface=eth0 --localnet
Output looks like this:
192.168.10.15 00:1a:2b:3c:4d:5e Cisco Systems, Inc
192.168.10.22 00:11:22:33:44:55 Dell Inc.
192.168.10.45 ac:de:48:00:11:22 Unknown vendor
That "Unknown vendor" line — or any MAC you can't match to your inventory — is where you dig in. I sort the output by vendor to spot anomalies faster:
sudo arp-scan --interface=eth0 --localnet | sort -k3
Deeper Discovery with nmap
arp-scan tells you who's alive. nmap tells you what they're running. I run a quick service scan against the full subnet to catch devices that might be running unexpected services:
sudo nmap -sn 192.168.10.0/24
sudo nmap -sV --top-ports 20 192.168.10.0/24
The -sn flag is a ping scan — no port scanning, just host discovery. The second command grabs the 20 most common ports and tries to identify service versions. This catches things like a rogue web server someone spun up on a desktop.
For a more thorough pass on a single suspicious host:
sudo nmap -A -T4 192.168.10.45
-A enables OS detection, version detection, script scanning, and traceroute. It's noisy, so don't run it during a sensitive window if you're worried about tipping someone off.
Cross-Reference with DHCP and Switch Tables
This is where the 10-minute audit becomes actually useful. Pull your DHCP leases:
cat /var/lib/dhcp/dhcpd.leases | grep "lease" -A 5
Or on a Windows DHCP server, export from PowerShell:
Get-DhcpServerv4Scope | Get-DhcpServerv4Lease | Export-Csv leases.csv
Now match your nmap/arp-scan output against the lease table. Every IP that appears in your scan but has no DHCP lease? That's a statically configured device — which could be a server, a printer, or something someone didn't want showing up in DHCP.
Next, check your switch MAC address tables. On a Cisco switch:
show mac address-table | include 001a.2b3c
This tells you which physical port that MAC lives behind. If you trace a rogue device to port Gi1/0/24 and that port goes to a conference room — you found your problem.
Build a Repeatable Process
I run this audit monthly on critical subnets. Here's the workflow I follow:
- Run
arp-scanon each VLAN and save raw output - Run
nmap -snand merge with the ARP results - Diff against last month's
known-macs.txt - Investigate every new or unmatched MAC
- Update the baseline file once confirmed
- Check switch port mappings for anything suspicious
If you want to automate it, a simple bash script that dumps arp-scan output to a dated file and emails you the diff works fine. No need for a fancy tool if your network is under a few hundred hosts.
As I mentioned before in my post about what hackers do after breaching a Linux server (https://furkanikkan.com/urun/linux-sunucunuza-sizdiktan-sonra-hacker-larin-ilk-hamlesi-ne-26), persistence often starts with a foothold device you didn't notice. A rogue box on your LAN is exactly that kind of foothold.
Common Things You'll Find
In my experience, these are the usual suspects when you run this audit for the first time:
- Forgotten test VMs that someone spun up six months ago and never decommissioned
- Personal phones connected to the corporate Wi-Fi because someone shared the PSK
- Shadow switches — a cheap unmanaged switch someone daisy-chained under their desk
- Old printers or IP cameras with default credentials still active
- Rogue access points that extend your network into places it shouldn't go
None of these are catastrophic on their own. But each one is an unmanaged attack surface. A printer with a web admin panel on port 80 and default admin password is a foothold. A personal phone on the corporate VLAN is a pivot point if that phone gets compromised.
Don't Skip the Basics
You don't need expensive NAC or 802.1X to get started. Those are good long-term goals, but a 10-minute manual audit with arp-scan and nmap will catch 90% of the issues in a typical small-to-medium network. The hard part isn't the tooling — it's keeping your MAC baseline current and actually investigating the unknowns.
Warning: If you find a device you truly can't identify and it's running services on unexpected ports, don't just shut the port and move on. Capture its traffic with tcpdump for a few minutes first. You want to understand what it was doing before you cut it off — otherwise you might destroy evidence of something bigger.
Run this audit today. It takes 10 minutes and the results usually surprise people.
Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line
