SOP-75: Rogue Device / Unauthorized Asset on Network Response | CyberHawk Threat Intel

An empty MDE DeviceInfo result does NOT clear the device — that is the whole point of a rogue asset: it has no sensor. Absence from DeviceInfo while present in ASimNetworkSession is itself a positive signal, not a reason to close.

The defining test for a rogue device is simple: it is talking on the network but is not in the approved asset inventory. Joining live network sessions against a maintained AssetInventory watchlist (MAC / IP / hostname of every sanctioned device) surfaces exactly the endpoints that should not be there. First-seen timing tells you whether this just appeared.

• 1Confirm the AssetInventory watchlist exists under Sentinel → Configuration → Watchlists with columns for MacAddress, IPAddress, and Hostname. If none exists, build one from CMDB/Intune export first.
• 2Open Logs, paste the KQL below, set Time range to Last 24 hours and Run.
• 3For each result, note the SrcIpAddr, SrcMacAddr, VLAN/subnet, and the first-seen timestamp. Record the OUI (first 3 MAC octets) — a VM OUI (e.g. VMware / VirtualBox) on a physical VLAN, or an unregistered/locally-administered OUI, is a strong lead.
• 4Pivot each unknown IP into I2 (enrollment) and I3 (behaviour) — do not close on inventory absence alone.

Keep the AssetInventory watchlist fresh with an automated daily export from Intune + CMDB. A stale inventory turns this high-value query into an alert-fatigue machine — every re-imaged laptop looks "rogue." Inventory hygiene IS the detection.

Microsoft Defender for Endpoint's Device Discovery passively fingerprints every device onboarded sensors can see on the wire, including ones that carry no sensor of their own. A device that appears in DeviceInfo with OnboardingStatus = "Can be onboarded" or "Unsupported" — or is only visible via a neighbouring onboarded device — is an unmanaged asset. Correlate with I1: unknown-to-inventory and unmanaged is the confirmed rogue profile.

• 1In Assets → Devices, filter Onboarding status to "Can be onboarded" and "Unsupported". Sort by First seen.
• 2Open the device page for the suspect IP/MAC. Review the Device Discovery tab: which onboarded device observed it, on which network, and the inferred device type/OS.
• 3Cross-check Entra ID → Devices and Intune → Devices for any matching object. No object anywhere = truly unmanaged.
• 4Run the KQL below in Hunting → Advanced Hunting to list unmanaged assets seen in the last 24h with their observing device.

OnboardingStatus "Unsupported" is NOT benign. IoT sensors, printers, and single-board computers all report "Unsupported" — and so does an attacker's drop-box. The label describes MDE capability, not trustworthiness. Judge on VLAN and behaviour (I3/I4), never on the label alone.

A passive rogue client is a policy problem; a rogue device that is scanning is an active intrusion. The decisive behavioural tell is one source touching many distinct destinations and/or many distinct ports in a short window — a port sweep, SMB (445) enumeration, or RDP (3389) hunting for lateral targets. This is what separates a curious contractor's laptop from an attacker's foothold.

• 1Run the KQL below scoped to the suspect SrcIpAddr from I1.
• 2Interpret fan-out: DistinctDstHosts > 20 or DistinctDstPorts > 50 in under 10 minutes indicates active scanning (T1046).
• 3Note the target ports — a burst of 445 / 139 / 3389 / 22 / 5985 across many hosts is lateral-movement reconnaissance, not benign discovery.
• 4If scanning is confirmed, jump straight to Containment C2 — quarantine the port now, finish analysis afterward.

Legitimate vulnerability scanners and network-monitoring appliances (Nessus, Qualys, network discovery tools) fan out exactly like an attacker. Keep their source IPs in an allow-list watchlist and exclude them here — otherwise your scanner IS your top false positive on this query.

A rogue device that hands out DHCP leases (or a rogue AP advertising a gateway) is not just present — it is intercepting traffic. By offering itself as the default gateway/DNS it becomes an adversary-in-the-middle (T1557.003), reading and modifying every victim's traffic. The tell is DHCP OFFER/ACK traffic sourced from an IP/MAC that is not on the authorized DHCP-server list, or clients suddenly receiving a gateway/DNS that differs from the sanctioned scope.

• 1Identify your DHCP telemetry: Windows DHCP audit logs (custom text-log table via AMA), or firewall/appliance DHCP relay events in CommonSecurityLog (CEF). Confirm which is ingested before querying.
• 2Maintain an AuthorizedDhcpServers reference (watchlist or inline set) of every sanctioned DHCP-server IP/MAC.
• 3Run the KQL below to surface DHCP server-side traffic (source UDP 67) originating from any IP not on the authorized list.
• 4Corroborate on the wire: any host on the segment whose assigned gateway/DNS differs from the sanctioned scope has been poisoned — pivot those victims into account-compromise / AiTM response (SOP-18).

A rogue DHCP server is an active AiTM position — treat every client that received a lease from it as potentially intercepted. Do not merely block the rogue: identify the poisoned clients, force DHCP renewal from the legitimate scope, and review their sessions for credential theft.

Before containment you need the artifacts to act on and a defensible verdict. A rogue device's most useful "IOC" is its physical location — the switch port it is plugged into — because remediation is ultimately physical. The FP/TP gate stops you from either yanking a legitimate new asset off the wire or waving through an attacker's board.

• 1Take the SrcMacAddr and query the switch MAC table: show mac address-table address <MAC> to get the physical interface, then show cdp/lldp neighbors and port description for location.
• 2For wireless, query the WLC/controller for the client MAC to get AP name, SSID, and signal — a rogue AP will itself appear as unmanaged infrastructure.
• 3Record the IOC set (below) into the incident before any containment action.

"It's probably just someone's new laptop" is a hypothesis, not a verdict. Close as FP only when a change ticket, inventory record, or named owner actually confirms it — an assumed owner is exactly how a drop-box survives triage.

For a suspected drop-box or rogue AP, do NOT physically unplug it yet if you can quarantine at the switch instead — an attacker watching for link-loss may wipe or trigger a dead-man on disconnect. Contain at Layer 2 first, preserve for forensics.

• 1On the switch interface from I5, apply a quarantine: move the port to an isolated/blackhole VLAN, or shutdown the interface if forensic preservation is not required.
• 2In NAC (e.g. 802.1X/ISE-class), set the endpoint MAC to a quarantine authorization profile so it cannot re-authenticate onto a trusted VLAN if moved to another port.
• 3For wireless, disassociate and blocklist the client MAC / rogue AP BSSID on the wireless controller.
• 4Add the rogue IP + MAC as a block indicator on perimeter and internal enforcement points (firewall, MDE indicators) so it cannot reach sensitive services if it resurfaces.
• 5If a rogue DHCP server (I4) was confirmed, enable/verify DHCP snooping on the access switches to drop rogue OFFERs, and force DHCP renewal on poisoned clients from the legitimate scope.

If the switch supports it, capture a short SPAN/mirror of the port before quarantine — a few minutes of the rogue device's live traffic is often the single best piece of evidence about what it was doing and who controls it.

• Rogue device physically removed and its switch port secured (802.1X / port security)
• I1 / I3 / I4 re-run returns 0 hits for the rogue MAC and IP
• DHCP snooping + DAI verified enabled on the affected access segment
• All hosts/clients the device contacted or leased to reviewed and cleared (or escalated)
• AssetInventory watchlist and NAC policy updated; timeline documented

Physically planted hardware (drop-box, rogue AP, malicious cable) implies either an insider or a physical-premises breach. The moment hardware addition is confirmed malicious, loop in Physical Security and HR/Legal in parallel — this is not a purely technical incident.