Remote access tools are increasingly popular attack vectors for adversaries. We’ve covered maliciously configured RMMs (delivered like malware), but another route is through physical IP-KVM (or Keyboard, Video ,Mouse-over-IP) devices. In the past year, security researchers have seen an uptick in IP-KVM attacks, including one that made the news involving North Korean IT workers using PiKVM (open source, Raspberry Pi-based IP-KVM) hardware to directly control systems in laptop farm environments.
With the increased adoption of this tactic, defenders are under pressure to address the threat. In this Hunt Mode, we’ll look at how threat hunters and security analysts can track malicious IP-KVM use through the hardware artifacts that remain from remote operators’ sessions.
Mostly legitimate, but sometimes malicious KVM devices enable the use of a single keyboard, monitor, and mouse to control several computers or servers. IP-KVMs add remote access by connecting directly to a computer's USB and display interfaces to give the operator control over a network connection. With this type of connection, the operator’s input is indistinguishable from that of someone physically using the computer’s keyboard, providing a level of cover for attackers.
IP-KVM devices are legitimate tools and highly useful options for performing a range of administration tasks. Unfortunately, they can also be used for malicious purposes. For defenders who rely on traditional security software, interactive sessions happen at the hardware layer, outside the host operating system. However, since the hardware still plugs into the machine, defenders can hunt the hardware artifacts remaining from remote operators’ sessions.
For threat hunters, a systematic approach that targets obvious artifacts first and works down from there offers the best chance of success.
IP-KVM threat hunting options KVM activity can be hunted a few ways. The option we’ll look at in this post uses hardware telemetry, which is what a managed corporate endpoint sees when the KVM is attached.
Another option is to look at network telemetry to see the device itself and the infrastructure used to reach it. Network telemetry can complement the hardware findings by helping validate a candidate and its remote-access path, but it is not a prerequisite for the endpoint-side hunt.
Identify IP-KVM hardware telemetry SANS demonstrated an endpoint-side approach in 2026 using USB enumeration for PiKVM and NanoKVM. With that in mind, here are some useful endpoint or device-control telemetry:
Device identity
Device behavior
Product / manufacturer
Connect / disconnect events
Vendor ID / Product ID
Device/interface class
Device description
Composite USB interfaces
Serial, where populated
Historical device presence
With different endpoint products populating these fields differently, it’s important to validate what a sensor actually records before attempting to interpret a hunt result. SANS also noted that the identifying strings can be modified, making this a consideration during identification.
Once you confirm you have the visibility required, we recommend you start with the easiest question: does an IP-KVM device simply tell us it is present and attached to our endpoints?
Search for the devices that identify themselves To identify and pick the low-hanging fruit, search USB or device telemetry for recognizable IP-KVM product names, manufacturers, and known VID/PID combinations. You can think of the product string as a name tag, so if the device is wearing it, use it.
Here are some IP-KVMs that have been tied to attacks:
PiKVM TinyPilot JetKVM NanoKVM / Sipeed BliKVM GL.iNet / GLKVM Openterface Raritan It’s also worth searching for other known IP-KVMs, even if they have not been tied to a published attack. A complete inventory of IP-KVMs will enable behavioral baselining for future hunts (more on that later).
We also recommend the inclusion of enterprise IP-KVM lines such as Raritan , Avocent and ATEN , but bear in mind when triaging matches that these products are commonly used for legitimate server and datacenter remote management.
Low-hanging fruit can have a big impact. In the 2026 North Korea investigations, Huntress identified a PiKVM V4 Mini attached to a newly onboarded employee system, while Nisos documented PiKVM devices controlling systems in a laptop farm. Finding a KVM doesn’t mean a bad actor is involved. It just means the hardware has been identified. The next task is to determine whether activity around that hardware supports its use for a legitimate purpose.
We’ve come to the first branch in the hunt:
Found a clear KVM? → Determine whether it belongs there.Found nothing obvious? → Move down to the Hunt by behavioral footprint sectionReview the behavior and context of IP-KVMs While a KVM on a server in a lab may be exactly what you expect, a PiKVM on a newly issued employee laptop with no hardware record is a different question. We recommend reviewing the surrounding behavior and context to test the likelihood of a suspicious KVM before looking at the rest of the workstation:
Pivot
What to review
Endpoint / hardware
Endpoint and user role; approved or inventoried hardware; first seen near onboarding; rarity across the fleet; persistent attachment; long stretches without restart, shutdown, or sleep
User / Identity (if available)
Expected sign-in geography; VPN/proxy usage; unusual working-hour patterns; other remote-access anomalies; whether the activity and role fit the employee
Additionally, you can incorporate identity data and network telemetry as supporting evidence in the hunt, but neither is a prerequisite.
Review IP-KVM legitimacy When looking at the device, check whether its history dovetails with a legitimate remote-work setup with docks, monitors, headset keyboard, mouse, phone, and other peripherals accumulated over time.
If the setup is unusually sparse, with one persistent KVM-like device, little peripheral history, attached around onboarding and rarely changing, then it may be cause for concern and creates a useful hunting question: Does this look like someone's sweet home-office setup, or like a machine whose primary job is to stay online and be controlled remotely?
This is a triage heuristic, not a known North Korean signature. Plenty of legitimate employees have bare-bones workstations, and a farm operator could theoretically add extra peripherals. The point is to ask whether the behavior associated with the endpoint makes sense.
Huntress's 2026 investigations demonstrate why correlation matters: PiKVM artifacts were evaluated alongside onboarding timing, VPN/proxy infrastructure, geographic access patterns, working hours, and other identity evidence rather than being treated as proof on their own.
In one case, that combined evidence led Huntress to assess the employee's identity as questionable. The organization later confirmed its suspicions after the employee refused to show the room they were working in and was reluctant to appear on camera.
Actively confirm legitimacy If a KVM is not approved or standard issue, particularly on a new employee system or when other behavioral or contextual indicators do not align, don’t take the risk of guessing – confirm legitimacy.
Check the asset record and ask IT to confirm whether the hardware is approved, who it belongs to, and whether its use makes sense for that endpoint and role. Where needed, ask the manager or employee to explain the setup and compare that explanation with the telemetry. If the device is still unexplained, physically inspect the hardware where appropriate.
A hunt is not about accusation, it is about determining which endpoints should be subject to further investigation.
Hunt malicious IP-KVMs by behavioral footprint Our hunt started by finding known IP-KVMs and evaluating whether the adjacent behavior adds up. However, the easy indicators are editable: a device can have its product name, manufacturer string or identifiers changed. To find those IP-KVMs, we’ll move from what the device calls itself to its behavioral footprint.
What to observe Look for KVM-like candidates and human interface devices (HIDs) such as composite USB devices that combine keyboard or mouse functionality, with capabilities including:
Storage or virtual media USB networking Video/audio functions Other unusual interface combinations Also consider rarity, as a composite device or manufacturer appearing on one endpoint may deserve more attention than a device or manufacturer deployed across thousands.
It is not: HID + network = KVM
It is: HID + unusual additional functionality = candidate worth understanding
Why it stands out A device can take off its name tag, but it still has to perform its job. PiKVM's own documentation shows that it can emulate keyboard, mouse, mass storage and, optionally, additional functions including USB Ethernet and other USB devices.
Looking at the interface mix gives you a way to find hardware that has been renamed or that was never in your list of known products to begin with.
Rule out IP-KVM lookalikes Behavioral hunting buys resilience, but it can also surface false positives. Common lookalikes include:
USB-C docks Monitor-integrated or local KVM switches Developer boards Test/lab equipment Other multifunction USB devices Run KVM-like candidates through the same behavioral-and-context pivots as a known KVM, and ask the same context questions as before:
Does it fit the user's role? Was it present from onboarding? Does the endpoint look like an ordinary workstation? Do the identity signals make sense? Is there a business reason for the hardware? The stronger candidate is not simply an unusual composite USB device .
It’s much closer to rare device + KVM-like USB footprint + persistent presence + no clear business reason + surrounding behavior and context that does not quite make sense .
Practical triage steps
Result
Example
Next step
Probably expected
Approved KVM on server/lab asset; documented hardware; context fits
Record/allowlist
Worth confirming
Known KVM or unusual composite device on employee endpoint; no clear inventory record
Validate with IT/user/asset records
Higher priority
KVM-like hardware on unexpected/new-hire endpoint plus persistence, onboarding timing, unusual peripheral history, or identity anomalies
Escalate and physically confirm
You are not proving attribution from USB telemetry, but deciding which candidate deserves the next phone call or physical check.
Hunt Flow for KVM Devices
Validate USB/device telemetry. If the KVM identity is known, skip the composite hunt. If not, hunt the composite or behavioral footprint and check for a known look-alike. Both paths continue to behavior and context pivots, then Expected, Confirm, or Escalate, then preserve detections.
Hunt Flow for KVM Devices
Validate USB/device telemetry
Known KVM identity?
Hunt composite /
behavioral footprint
Known look-alike?
Run behavior + context pivots
Expected / Confirm / Escalate
Preserve detections
YES
NO
YES
NO
known identity,
skip composite hunt
both paths continue
Dry hunts are still productive If you’ve validated the required visibility and searched the known product families, looked for KVM-like composite footprints, and resolved the resulting lookalikes without finding unexplained hardware, the dry result is meaningful within that validated endpoint coverage.
It’s not perfect proof, as hardware can be modified and sensors have blind spots, but validated visibility with no known-KVM matches and no unexplained behavioral footprints is useful evidence of absence. Knowing what’s normal now makes it easier to identify the abnormal in the future.
Hunt IP-KVMs to create durable detections IP-KVM hardware works because it can make a remote operator look local, but the device still has to plug in somewhere.
To recap the hunt:
Start with what the hardware calls itself. If the name tag is gone, look at what it actually presents to the endpoint. Then use the surrounding hardware, user, asset, and identity context to decide whether the story makes sense. Rule out IP-KVM lookalikes (docks, development boards, approved KVMs, or somebody's home-office setup). Once you have high-confidence observables, turn them into durable detections, so a device that appears next week doesn’t require another manual hunt cycle..
Happy hunting!
Reference guide
Step
What to look for
Pivot
Validate visibility
USB connect events, product/vendor data, VID/PID, device class/interface data
Confirm the hunt is possible before interpreting absence
Known KVM identity
Recognizable IP-KVM product or vendor information
Determine whether it belongs on that endpoint
Context
Role, asset records, onboarding timing, rarity, persistence, peripheral setup
Approve, confirm, or escalate
Behavioral footprint
Composite HID with unusual network/storage/video/virtual-media functionality
Rule out common multifunction-device look-alikes
Corroboration
Identity/location anomalies or other remote-worker signals
Raise priority; do not use as standalone attribution
Dry result
No unexplained identity or behavioral matches after validated coverage
Treat as meaningful absence within known visibility
.webp)
