An unknown box behind a desk, an unexpected access point or a MAC address nobody can explain may be a forgotten lab device, or a planted implant that has been sniffing traffic for weeks. This playbook template covers rogue hardware found on a wired or wireless LAN: small single-board computers, network taps, unauthorised access points and switches, keystroke injectors and unmanaged IoT devices. It joins physical triage (who touched it, how to bag it) with network triage (which port, which VLAN, what it talked to), so that evidence is kept and the device is not simply unplugged and thrown in a drawer. It follows the incident response lifecycle in NIST SP 800-61 Rev. 3 and is written for network, security operations and facilities teams. Adapt the bracketed text before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [Network Owner] and [NAC], with your own names. "Must" is mandatory; "should" is recommended.
- Decision points are marked D1 to D5. Record each decision, who made it and when.
- Switch and NAC feature names are generic (port security, DHCP snooping, 802.1X); map each to the exact commands on your platform in a tested runbook.
- For background on device admission controls, read the Network Access Control (NAC) Guide. For unknown devices on smart metering or OT networks, also follow the Smart Meter Security Guide and the OT Incident Response Guide.
1. Scope and triggers
1.1 This playbook applies when a device that is not in [Organisation]'s asset inventory is physically found on premises, or is seen on a network [Organisation] operates, and its owner cannot be confirmed within [30] minutes.
| Trigger | Typical source | First question |
|---|---|---|
| Physical find: unknown box, dongle or cable in a comms room, under a desk or in a meeting room | Staff, cleaners, facilities, a walk-round audit | Has anyone touched it since it was found? |
| New or unknown MAC address on a switch port, or a port that should be empty showing link | NAC, switch logs, network discovery | Which port, which VLAN, since when? |
| Unknown access point or SSID broadcasting from your site, or an AP wired into the LAN | Wireless intrusion detection (WIDS) | Is it connected to our wired network or only nearby? |
| DHCP lease for an unknown hostname or vendor, or a rogue DHCP server answering clients | DHCP server logs, DHCP snooping alerts | Is it issuing addresses or only taking one? |
| 802.1X failures followed by MAC authentication bypass (MAB) success from one port | RADIUS accounting (for example NPS logs) | Is a device cloning a printer or phone MAC? |
| Scanning, ARP anomalies or new outbound tunnels from an unmanaged address | IDS, NDR, firewall | Is it already active against our hosts? |
1.2 Relevant ATT&CK techniques: T1200 Hardware Additions (the device itself; MITRE notes capabilities such as passive tapping, traffic modification, keystroke injection and adding wireless access points), T1557.002 ARP Cache Poisoning, T1040 Network Sniffing, T1046 Network Service Discovery and T1599 Network Boundary Bridging (a device that links a segmented network to another path, such as a cellular modem).
2. Roles and contacts
| Role | Responsibility | Named contact |
|---|---|---|
| [Incident Manager] | Owns the incident, decisions D1 to D5 and the timeline | [Name, phone] |
| [Network Owner] | Locates the port, applies port and VLAN actions, pulls switch, DHCP and NAC data | [Rota] |
| [SOC Analyst] | Traffic and log analysis for the device's addresses, threat hunting on contacted hosts | [Rota] |
| [Physical Security] | Secures the location, badge and CCTV review, visitor and contractor records | [Name] |
| [Forensics Lead] | Photographs, collects and bags the device; chain of custody; storage and flash imaging | [Name or retainer] |
| [Legal and HR] | Insider involvement, law enforcement referral, notification | [Name] |
2.1 Keep the contact list in the Incident Response Contact and Call Tree Template. The finder must not be asked to investigate; their job is to leave it alone and report.
3. Detection and triage
- Freeze the scene. Tell the finder not to unplug, power off or move the device. [Physical Security] restricts access to the area and records who has been near it.
- Photograph in place: overall location, labels, ports used, cable runs to the wall socket or switch, any SIM slot, antenna or power source (USB from a PC, PoE, mains). Note LED activity.
- Trace it on the network. From the wall socket or the switch MAC address table, find the switch, port, VLAN and MAC address. Pull the DHCP lease (hostname, vendor class, lease times), the DHCP snooping binding if enabled, LLDP or CDP neighbour data, and NAC or RADIUS accounting showing how the port was authorised.
- Look up the MAC organisationally unique identifier (OUI) to suggest a vendor, remembering that MAC addresses are easily changed. A MAC that matches a printer or IP phone already in inventory but on a different port suggests cloning.
- Review its traffic from the first-seen time: flows, DNS queries, outbound connections (especially tunnels, VPN or remote access services matching T1133 External Remote Services), and internal scanning. Capture packets on the port with a mirror (SPAN) before any change, if it is safe to wait.
- Check for wireless and cellular paths. A device with its own 4G or 5G modem keeps a remote path even after the switch port is shut. Note the antenna and any SIM.
- Check the ownership trail: change tickets, project teams, IT lab, facilities contractors (building management, CCTV, AV), vendor support visits.
D1: Severity. Critical: device in a restricted area, with its own cellular path, showing scanning or interception, or found on a network holding regulated data or OT. High: unexplained device with network activity but no attack traffic yet. Medium: unexplained but inert, or traced to a likely internal owner pending confirmation. Low: confirmed internal shadow IT. Any device whose placement required bypassing physical access controls is at least High.
4. Containment
D2: Watch or cut? The default is to isolate the port once packet capture has started and evidence is photographed. Watching a device for longer, to learn its controller, is only allowed with [Incident Manager] and [Legal] approval, a capture running, and the device in a quarantine VLAN that cannot reach production.
| Situation | Containment action | Caution |
|---|---|---|
| Wired device on an access port | Move the port to a quarantine VLAN or shut it administratively; block the MAC in [NAC] | Shutting the port loses live traffic; start capture first |
| Rogue access point wired to the LAN | Shut the upstream switch port; use the wireless controller's rogue containment only where local law and policy allow | Over-the-air containment can affect neighbours' networks |
| Rogue DHCP server | Shut its port; confirm DHCP snooping marks only uplinks and real servers as trusted | Clients may hold bad leases, gateways or DNS servers |
| Inline device between a host and the wall socket | Remove the host from the network and isolate the host too | The host may be the real target; preserve it |
| Device with its own cellular modem | Power off only after [Forensics Lead] has recorded state; place in a signal-blocking bag | Remote wipe is possible while it stays powered and connected |
| USB device in a workstation (keystroke injector, network adapter) | Isolate the workstation with EDR network containment | Treat the workstation as compromised until checked |
4.1 Collect the device with gloves, record serials, bag and label it, and start the Chain of Custody Form Template. Follow the Evidence Handling and Chain of Custody Guide for storage cards and flash media.
5. Eradication
- Hunt across the estate for the same MAC vendor prefix, hostname pattern, DHCP vendor class or traffic profile. Check other sites the same contractor or visitor accessed.
- Treat every host it talked to as suspect. Review authentication logs for credentials seen in cleartext protocols on that segment, and for accounts used from the device's address.
- Rotate exposed secrets: network device credentials, SNMP community strings, Wi-Fi pre-shared keys, RADIUS shared secrets and any service account passwords that crossed the segment unencrypted.
- Clear poisoned state: ARP caches and DHCP leases on affected clients, and any rogue DNS settings.
- Have the device examined by [Forensics Lead]: storage image, configuration, stored captures, controller addresses. Indicators feed the hunt in step 1.
D3: Insider or external? If badge, CCTV or ticket evidence points to an employee or contractor, [Legal and HR] take over the people track; the technical response continues.
6. Recovery
- Restore the port to its intended profile with 802.1X or MAB plus profiling, not open access. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
- Unused ports in the same room should be shut or placed in a dead VLAN.
- Register or remove: if the device was legitimate shadow IT, it is either onboarded to the inventory with an owner or removed.
- Monitor the segment for [30] days for the device's MAC, its controller addresses and the traffic profile.
D4: Close containment? The [Network Owner] and [SOC Analyst] confirm no further devices or connections match the indicators before the [Incident Manager] closes.
7. Communication and notification
- Internal: brief site management and facilities; avoid all-staff messages until D3 is settled, so a possible insider is not alerted.
- Law enforcement: [Legal] decides on referral where planting is likely; keep the device sealed until they advise.
- Regulators and customers: if interception of personal data is likely, [Legal and Privacy] applies the [Regulatory Register], for example GDPR Article 33 (72 hours from awareness).
- Landlord and contractors: where the device was in shared space or linked to a supplier's visit, notify them in writing and request their access records.
8. Post-incident review
8.1 Within [10] working days, using the Post-Incident Review and Root Cause Analysis Template. D5: decide whether open ports, MAB exceptions or a site's physical controls must change.
8.2 Record: first-seen time on the network against discovery time; how the port was authorised; whether the device would have been caught by NAC, WIDS or inventory reconciliation; how physical access was gained; and what data could have been seen.
Implementation guidance
Controls that shorten this playbook.
| Control | What it gives the responder |
|---|---|
| 802.1X with certificate-based device authentication; MAB only for listed exceptions | Unknown devices fail admission; the exception list is the short list to check |
| Port security limits and violation actions on access ports | Alerts or err-disabled ports when a second MAC appears behind a socket |
| DHCP snooping with logging, and dynamic ARP inspection | Rogue DHCP blocked; MAC, IP, VLAN and port binding ready for triage |
| RADIUS accounting kept centrally (for example NPS logging to SQL Server or text files) | Who or what authorised the port, and when |
| Wireless intrusion detection | Rogue AP and SSID detection, as NIST SP 800-53 SI-4(14) requires where selected |
| Inventory reconciliation against DHCP, NAC and discovery data | Unauthorised assets surface before someone trips over them |
Rollout. Phase 1: confirm you can trace any MAC to a switch port within 15 minutes, and practise on a test device in each site. Phase 2: turn on DHCP snooping and port security in monitor or restrict mode on a pilot floor, review alerts for two weeks, then move to enforcement; rollback is a single interface template change. Phase 3: move access ports to 802.1X with MAB exceptions reviewed quarterly. Small offices without NAC should start with shutting unused ports, locking comms rooms and weekly DHCP lease review against inventory. Run the scenario from the Tabletop Exercise Scenario Pack with facilities in the room.
Framework mapping.
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Hardware inventory and unauthorised component detection | ID.AM-01 | CM-8, CM-8(3) |
| Device identification before connection | PR.AA-01 | IA-3 |
| Network and physical monitoring | DE.CM-01, DE.CM-02 | SI-4, SI-4(14), PE-6 |
| Containment, eradication, recovery | RS.MI-01, RS.MI-02, RC.RP-01 | IR-4 |
CIS Controls v8.1 Control 1 (Inventory and Control of Enterprise Assets) covers finding and removing unauthorised assets; D3FEND D3-HCI Hardware Component Inventory is the matching defensive technique.
Metrics. Time from first network appearance to detection; time from detection to port isolation; percentage of access ports under 802.1X or MAB; number of MAB exceptions and their age; unknown DHCP leases per week; percentage of rogue AP alerts closed within [24] hours.
Common failure patterns.
- The finder unplugs the device and hands it to the help desk, losing state, network history and chain of custody.
- Shutting the switch port and assuming containment, while a built-in cellular modem keeps the device reachable.
- Treating MAB as authentication: a cloned printer MAC gets the printer's VLAN.
- Investigating the device but not the hosts and credentials it could see.
- Closing the case as shadow IT without onboarding or removing the device.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: Cybersecurity Framework 2.0
- CIS: Control 1, Inventory and Control of Enterprise Assets
- MITRE ATT&CK: Hardware Additions
- MITRE ATT&CK: ARP Cache Poisoning
- MITRE D3FEND: Hardware Component Inventory
- Microsoft: Network Policy Server (NPS)
Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · Physical Security Guide for Security Teams · Asset Inventory and CMDB Security Guide · Smart Meter Security Guide · Incident Response Guide