Finding shadow devices on the network: minimal tasks and reports

What are “shadow” devices and why catch them regularly

A “shadow” device is any equipment that appears on the network without being recorded and without a clear owner. It might have been plugged in "for an hour" but remain connected for weeks. The issue isn't how "smart" it is — it's that nobody knows about it and nobody maintains it.

Most often these are ordinary items: a printer, a home Wi‑Fi access point, a mini‑PC for a display or accounting, an IP camera, a "smart" TV, a VoIP gateway. Temporary routers "to get internet" and test laptops left in a meeting room also fall into this category and are often forgotten.

The problem is that such devices often run unknown services and settings. They frequently have simple passwords, unnecessary management protocols enabled, and haven't received updates for years. Sometimes a shadow device breaks segmentation: an access point may hand out Wi‑Fi directly into the office VLAN, or a dual‑interface mini‑PC may effectively bridge two networks.

A one‑off search is almost always useless. Networks change every day: a contractor brings a camera, a department buys a printer, an admin installs a temporary "patch" during a failure. A month later the same issue resurfaces with a different MAC and a different room. Therefore you need a regular process: detect, confirm, document or remove.

Usually four roles take part. Security defines the rules (what counts as unknown, which zones are critical, response times). Operations verifies via ports and diagrams where and how the device is connected. Helpdesk contacts users and records the owner or a legalization request. Service owners (IT, office, security) decide whether to add the device to records, isolate it, or remove it.

Regularly searching for shadow devices is not a witch hunt but network hygiene: fewer surprises, simpler investigations, and a lower chance that a "small box" becomes an entry point to a larger problem.

Minimal target outcome for security and operations

The minimal outcome is not a "perfect" network map but manageability. Be able to answer three questions quickly: which device appeared, where it's connected, and who is responsible. If that takes hours rather than days, the risk drops significantly.

It's useful to consistently produce a small set of artifacts:

• a list of discovered devices (IP, MAC, hostname, vendor by MAC OUI, time of first appearance)
• mapping to location (switch, port, VLAN, office/floor or other location)
• status "known/unknown" and an owner (service owner or unit)
• a short risk note from security (for example: "router", "access point", "printer", "unknown")

Divide responsibilities in advance. Security logs the appearance and assesses risk: is the device appropriate for this zone, are there signs of rule bypass. Operations performs the "field" work: finds the port, checks whether the addressing is an error, contacts the owner, and if necessary disconnects or moves the device into the correct segment. In organizations where IT and security overlap on procurement and support (for example, in projects with system integrators like GSE.kz), this separation is especially important so incidents do not stall between teams.

Control frequency depends on signals:

• daily: new MACs and MAC‑IP changes
• weekly: list of "new and unresolved" with owners and deadlines
• monthly: reconcile inventory with what is actually visible on the network

Decide where the "source of truth" is. Best is a CMDB or an inventory database. If none exists, start with a simple registry table: device, owner, location, approval date. Without a single source of truth, shadow device tracking quickly turns into endless disputes like "it was always here."

What data and accesses are needed before launching tools

Without core data the tools quickly hit a ceiling: you'll see "something on the network" but won't know where it's plugged in or who owns it. Before starting, agree which segments you control and which data sources are considered authoritative.

Access to network infrastructure

The absolute minimum for Netdisco is SNMP read access on switches. Without SNMP you lose the most valuable information: binding a MAC address to a switch and port, and thus the ability to quickly get to the socket or access point.

Make sure you have:

• a list of switches (management addresses, model, site) and SNMP read‑only access
• a map of VLANs and subnets in scope (office, Wi‑Fi, guest, server)
• permissions to view port configurations (at least via operations) to check port mode, trunk/access and descriptions
• an understanding of "where not to touch": segments and devices that must not be actively scanned

Service data to link IP, MAC and owner

DHCP lease logs often give the fastest answer about who got an IP and when. If you see a new MAC in arpwatch, the next step is to link it with IP and lease time in DHCP.

Agree on exceptions in advance. For example, printers, terminals, medical equipment and some OT are often off‑limits for active Nmap scanning. In such cases record which networks are scanned only passively (SNMP, DHCP, ARP) and who authorizes exceptions.

To prevent reports becoming a bare "list of MACs," enforce a simple naming and recording rule (CMDB, spreadsheet, ticketing): site, room or rack, VLAN, device role and owner contact. Then a found "unknown" router in the guest network becomes a ticket with a clear address and responsible person, not a mystery.

Netdisco: quick device inventory and port mapping

Netdisco helps answer two quick questions: what is connected to the network and to which port. For finding shadow devices this is especially useful because it relies on switch data: MAC tables, port information, and LLDP/CDP (if enabled). You can see not only the presence of a device but also its moves across sockets and racks.

Basic setup is usually simple: add managed switches (SNMP read), enable regular collection of MAC tables and LLDP/CDP where possible. It's important to have at least one stable source of truth for VLAN names and site/rack names, otherwise reports will be "about IPs" but not "about places."

Usually three reports cover most routine needs:

• new devices (MAC seen for the first time on the network)
• device changed port (was in one place yesterday, another today)
• unknown vendor by OUI (suspicious or "nameless" MACs)

Important limitation: if a device sits behind an unmanaged switch, Netdisco will only see the uplink port and a "mixed" MAC picture. The same applies to Wi‑Fi if you collect only from switches and not from the wireless controller.

To prevent this becoming "yet another report," specify responses in advance. For example: for critical VLANs (finance, domain, medical equipment) the operations duty checks a new MAC within 4 hours and security classifies the risk by the end of the business day. In practice it looks like this: Netdisco shows a new MAC on a port in a meeting room, operations checks requests and the wiring, security looks at the OUI and VLAN context, and they decide to shut down the port, move it to guest VLAN, or legalize the device.

arpwatch: simple "new device" events

arpwatch produces a simple event: a new MAC appeared in a segment, or a known MAC changed IP. This is not an inventory but an early sensor that complements regular shadow device searches.

Where to place it

arpwatch only sees ARP traffic, so install it where ARP is observable: at the segment gateway (router, L3 switch), on a server in the same VLAN, or behind a port mirror (SPAN) on a switch. Start with the most important VLANs: server, office user and guest.

Typical notifications and logs to include:

• new MAC in a segment (new station)
• IP change for a known MAC (changed address)
• duplicate IP or MAC (flip‑flop, duplicate)
• frequent changes by the same MAC in a short time

How to reduce noise and what counts as an incident

arpwatch quickly becomes noisy unless you distinguish normal behavior from anomalies. Give operations the ability to maintain a whitelist for infrastructure (gateways, access points, printers, IP phones) and mark zones with many temporary clients (meeting rooms, guest Wi‑Fi) separately.

To ensure security and operations respond consistently, record rules. Commonly considered incidents are:

• a new MAC in the server VLAN or management segment
• duplicate IP (often a sign of misconfiguration or interception attempts)
• a MAC flapping across different ports (could indicate a loop, moved switch, or spoofing)
• frequent IP changes by the same MAC without a clear reason

Example: a new MAC appears in the server VLAN and gets an address not from the static list. Even if services did not fail, this is a reason to check the switch port, identify the device owner and purpose, and then log the result in the change journal.

Nmap: confirmation and a quick device profile

Nmap is useful when Netdisco or arpwatch have already indicated "something appeared" and you need to confirm presence and understand what the device is. For security this separates noise from real threats; for operations it quickly points to the next steps. Often Nmap resolves the question in 5–10 minutes.

There are two modes and it is important not to mix them. First is soft discovery: check whether the IP is alive and (in the same L2 segment) get the MAC via ARP. Second is a limited port scan under rules: only a short list of ports, without aggressive options and without sweeping everything.

Examples of commands that are usually safe to start with:

# Soft host check
nmap -sn 192.168.10.25

# Limited scan on a short port list
nmap -sS -Pn -p 22,80,443,445,3389 192.168.10.25

The minimal data to record in a ticket or log:

• IP address and subnet
• MAC address (if visible in your segment)
• hostname (if it resolves)
• open ports from the short list and their services

Run scans in quiet windows and limit speed to avoid false incidents. Exclude sensitive subnets (medical equipment, ICS, critical services) unless you have an agreed window and an owner.

What to consider suspicious in an initial profile:

• a web management interface on 80/443 for a device not in inventory
• SMB (445) or RDP (3389) where normally only office PCs or printers exist
• unusual open ports that don't match the segment's typical profile
• a "silent" host: responds to ARP but does not ping or show services

Small example: arpwatch reports a new MAC in an office VLAN. Nmap shows 80/443 and a web admin header. This is a reason to isolate the port rather than argue about who installed it, and then follow procedure.

Step‑by‑step procedure: how to organize regular detection

Regularity depends on a short repeatable cycle: what is normal, how to detect new devices, who decides and how to record the result.

1) Record the "known base"

Start with a simple registry. Enough details per device: MAC, IP (or subnet), owner (unit or person), location (office, rack, floor), criticality (normal, important, forbidden). Without this any "new" device is disputed: you can't tell who installed it and why.

2) Set up continuous alerts for new devices

For key segments (office, Wi‑Fi, server, contractor zones) enable arpwatch to get events about new MACs and IP changes. Decide in advance where events go (email, tickets) and who is on duty.

A practical cycle can be:

• daily: triage arpwatch events (new MAC, IP change, flapping)
• on event: use Netdisco to find the switch/port and movement history
• weekly: Nmap on approved subnets and comparison with the previous week
• for each finding: identification, agreement, action (isolate/block or legalize)
• closure: update the registry so the device is no longer treated as new

Example: arpwatch reports a new MAC in the accounting subnet. Netdisco shows the port in a meeting room and Nmap identifies a home router with a web interface. Then the steps are clear: isolate the port, find the room owner, then either ban the device or register it and record it in the registry.

Minimal set of reports people will actually read

Reports should answer one question: what should security and operations do today? If a report doesn't lead to an action (check, confirm, disconnect, create a ticket), it's better not to publish it.

Keep 4–5 reports and include two columns in each: "triage status" and "triage owner" (security or operations). Without this the report becomes dead.

• Weekly "New devices": MAC, IP, VLAN, port (switch/interface), first seen time, detection method (Netdisco/arpwatch/Nmap), triage status.
• "Devices without owner": items found but not linked to a unit, ticket or owner.
• "Port or location changes": what moved, where, when, who confirmed.
• "Unexpected services": a short list of open ports and where they appeared (e.g., 22/3389/445), marked as "expected/unexpected".
• Monthly "Registry vs reality": number of discrepancies, main causes and month‑over‑month dynamics.

Example: in "New devices" a MAC appears with an IP from the office subnet, and in "Unexpected services" it has port 53 open. Operations checks the switch port and physical point, security marks it as "suspected router/access point" and records the decision: legalize via a request or disconnect.

Common mistakes and traps when hunting shadow devices

The most frequent problem is turning the task into a one‑off action. Findings don't become a process: someone scans, posts in chat, and that's it.

Failures usually happen in a few areas:

• Running an overly broad Nmap without a maintenance window and speed limits. Network and services start to behave oddly, users complain, and trust in checks declines.
• No single registry of known devices (even a simple one). The same device is "discovered" repeatedly.
• No escalation path. Security sees a new MAC, but operations doesn't check the port, no owner is assigned, so nothing changes.
• Ignoring unmanaged switches and Wi‑Fi. A port looks "clean" on diagrams, but the actual device is hidden behind an access point or a small switch.
• Ignoring duplicate IPs or MACs. Conflicts, device moves and possible spoofing are missed.

Three pre‑agreed items help: when scanning is allowed, where the registry lives, and who decides on unknown findings. Even if a tool only shows "suspicious," a ticket must have an owner and a deadline.

Example: a new printer name appears in DHCP, but it's actually a home router providing Wi‑Fi. Without checking duplicates and mapping to a port it will keep reappearing. With a rule like "new MAC + unknown vendor + atypical open ports = escalate," operations will seek the access point and resolve it quickly.

Short weekly checklist

The weekly check should be short and end with a clear result: what to accept as normal and what to investigate.

Keep a list of VLANs where a new device is most dangerous: typically user office networks, employee Wi‑Fi, segments with access to critical services and any transitional zones between departments.

Then go through that week's new MAC events:

• Is the MAC seen in a VLAN and is that VLAN critical? If critical, triage is same day.
• Is there a binding to a switch and port? If not, record the reason (NAT, unmanaged switch, no SNMP/LLDP) and create a task to remove the blind spot.
• Assign an owner and record the reason for appearance: request, replacement, test bench, project. "Unknown" is an open incident.
• Create a minimal profile: how the device responds on the network and whether it matches its claimed role (addresses, name, typical ports, web UI, RDP/SSH, printer services).
• After triage update the registry: add the asset or add an exception with date and reason.

If more than 5–10 unresolved MACs without owners remain at week's end, you likely lack data access or discipline in recording changes.

Example scenario: an unknown router found in the office network

In the morning someone plugs a small router or access point into a free socket near a meeting room. Within minutes it gets a DHCP IP and begins offering Wi‑Fi. IT wasn't informed and the device isn't in the allowed list.

arpwatch triggers first: a new station entry with MAC, first seen time and assigned IP. That alone indicates this is not a transient guest laptop but a device that established itself on the network.

Netdisco helps next. By IP or MAC you quickly find the switch and port. The history may show this MAC has appeared before and moved between rooms, turning a guess into a clear incident for operations.

Run Nmap on the IP to understand the device. If ports 80/443 are open with a web admin panel and maybe port 22, you can confidently label it a router or access point rather than a printer.

Actions should be short:

• temporarily isolate the port (shutdown or move to a quarantine VLAN)
• find the device owner via office or security services
• decide: legalize (register and configure) or remove
• update rules: where Wi‑Fi can be installed, who approves it, and how devices are labeled

The report records the outcome: what was found (MAC/IP/port), why it appeared, what measures were taken and what changed in the procedure so similar cases are detected and resolved faster.

Next steps: formalize the process and prepare infrastructure

The process should live in a clear place: where it's kept, who is responsible for triage and what a finished result looks like.

One‑page minimal regulation

Create a short document anyone can open and quickly understand what to do:

• roles: who views reports (security), who checks the network (operations), who decides (segment owner)
• response times: e.g., "critical segments — within 4 hours", "office — by end of day"
• list of reports: 2–3 concise summaries without long dumps
• escalation rules: when to immediately block a port and when to first ask the unit
• exceptions: printers, meeting room panels, test benches — who approves them and how they are marked

Start small and expand coverage

Don't try to cover the entire network in a week. Start with 1–2 segments where risk and benefit are obvious: office network and server room. Office networks quickly reveal rogue access points and home routers; server rooms show unexpected devices in racks and management VLANs.

Decide where monitoring will run and where data is stored: a small dedicated server, a VM in an existing cluster, or a dedicated node in the data center. Plan backups for configurations, log retention (at least 30–90 days) and access following the principle of least privilege.

If the bottleneck is not just tools but infrastructure and support (server, workstations, inventory, maintenance), consider engaging a system integrator. For example, GSE.kz as a vendor and integrator can help build the foundation for monitoring and inventory (including locally provided servers and workstations) and formalize the process so it doesn't rely on a single person.