Out-of-Band, Part 1: The new generation of IP KVMs and how to find them

Introducing Out-of-Band #

Welcome to the first post in Out-of-Band, a series exploring the security risks of out-of-band (OoB) management devices like baseboard management controllers, serial console servers, and IP-enabled KVMs. These tools often have weaker security than the systems they control, offering attackers a path to bypass monitoring and safeguards.

In this installment, we focus on the latest wave of open-source, network-connected KVMs. We’ll cover where to find them in the wild, how to detect them via network and host signals (plus SIEM), and what their source code reveals about their security posture.

Bonus: These devices have been used by North Korean threat actors to spoof in-country access. So if that’s a concern, read on.

runZero users: To find these on your network, search your asset inventory for type:BMC.

PS. While working on the final drafts of this post, we ran across two excellent articles at GrumpyGoose Labs. If you would like to dig deeper on PiKVM and TinyPilot detection, these are great resources: Hold Me Closer, TinyPilot & Unemployfuscation.

The Next Generation of IP KVMs #

A few months ago, Brian Wilson reached out to ask whether runZero could detect devices like the TinyPilot, PiKVM, JetKVM, GLKVM, BliKVM, and NanoKVM. These Linux-based, open-source-powered KVMs provide full remote control over PCs and servers, including power management, virtual storage, serial access, and even mouse-jiggling. They’re inexpensive compared to enterprise KVMs and increasingly common in home labs and small businesses.

Unfortunately, threat actors are also taking notice. Notably, North Korea’s Famous Chollima group used devices like these to remotely operate overseas laptop farms. They’re a perfect tool for this kind of operation: they require no software install and can keep a system unlocked.

And that’s the problem. It doesn’t matter how hardened your server is if the attached KVM can reboot to a recovery disk, exfiltrate data, and drop a backdoor. A weak KVM offers attackers easy access into an otherwise secure system. In a publicly disclosed instance last year, a US DoD workstation was exposed to the internet without authentication, via a TinyPilot IP KVM in it's default configuration.

How We Detect Them On The Network

These devices typically expose web services — and often mDNS and SSH — which make them fingerprintable. We use a combination of techniques:

• Web content matching: HTML titles, HTML comments, HTTP headers, and favicon.ico hashes. If the hostname is embedded in the title, runZero extracts and stores that as well.

• TLS certificate matching: When TLS is enabled, many devices use static or predictable x509 Subject and Issuer fields.

• Hostname analysis: Many default hostnames include the device type and ID. These can be extracted via mDNS or by querying local DNS (PTR records from DHCP leases) — a technique we call hostname reflection.

To widen detection:

• Look for MAC address vendor matches (e.g., Sispeed, Raspberry Pi Foundation, GL.iNET).

• Monitor outbound traffic to the known cloud endpoints these devices typically connect to.

We aim to build multiple fingerprints per device, improving detection resilience for future software updates and user customization.

Real-World Deployments #

Once we had reliable fingerprints, we went hunting for these devices across the internet, home labs, and corporate environments.

Public Internet Exposure

To estimate public-facing exposure, we translated some of our fingerprints into SHODAN queries. While these don’t represent every detection method we use, they provide a good directional snapshot.The result count is our estimate of unique devices after reviewing all of the matches for each keyword of a given device. These results are based on queries from June 23rd, 2025.

Good news: relatively few of these devices are exposed to the open internet. That’s likely due to:

• Their relative newness (many were released within the past year).

• Native integration with Tailscale and WireGuard tunnels for private remote access.

• JetKVM’s cloud-based management model.

Internal Network Visibility

To estimate internal use, we sampled environments of various sizes. Here’s what we found:

• Only PiKVM and JetKVM showed up within networks with more than 2,000 assets.

• The vast majority of devices live in home labs as single instances.

• runZero's outlier scoring also flagged these devices based on rarity.

Device-by-device breakdown:

• PiKVM & JetKVM: Most frequently seen; JetKVM is showing surprising early adoption given its December 2024 release.

• TinyPilot, GLKVM, NanoKVM: Found almost exclusively in home networks, at about half the rate of PiKVM and JetKVM.

• TinyPilot: Occasionally seen in small businesses (≤2,000 assets).

• BliKVM: No results.

Interestingly, JetKVM appears far more often in internal environments than it does on the public internet, likely thanks to its cloud-centric architecture. PiKVM, by contrast, is more commonly exposed externally despite similar internal adoption and a longer history.

Enterprise KVM Trends

Legacy enterprise gear still dominates internal deployments:

• Avocent and Raritan KVMs are ~10x more common than PiKVM and JetKVM combined.

• These skew toward larger, more traditional enterprise environments.

TLDR: These next-generation IP KVMs are relatively easy to find — once you know what to look for — but they’re still rare in corporate settings. That said, JetKVM is gaining traction fast. If its current growth continues, it may soon rival traditional enterprise options.

Security Review #

All of these products use a mix of open source operating systems and open source application stacks. This makes security analysis straightforward; we can pull the source code from GitHub, look for common issues, and try to get a sense of the security risks posed by each device. Instead of an exhaustive analysis of every issue, we’re going to present some footnotes from our code review, and give each device a score ranging from F to A in terms of whether we think you should allow these on your network. These scores are just our opinion and are based on the state of the code as of June 2025.

If you work on one of these products, disagree with the score, would like to tell us why we are wrong, or what has improved since we wrote this, please drop us a line via research[at]runZero.com. We’ve found that being wrong on the internet is the fastest way to make friends!

PiKVM #

Created in 2017, the PiKVM is the OG of DIY open-source KVMs. The PiKVM OS can run on a Raspberry Pi W2, a Raspberry Pi 4, and on various dedicated devices for sale by the company with prices ranging from $230 to over $400. On top of the base OS (they use arch btw), the important software is the kvmd application. This is written in Python and released under the viral-but-in-the-itchy-pants-way GPL v3 license. It also looks pretty reasonable from the security side at a first glance. After a little bit of digging, we wanted to share a few notes.

1. Nearly every web endpoint requires authentication by default, including the prometheus exporter. This is great!

2. Excellent test coverage and active development!

3. No web interface for configuring VPN options like Tailscale.

We're giving this a solid A- in terms of security ratings. It's a mature product, but could be more user-friendly for things like remote access.

TinyPilot #

Next up in terms of internet exposure is TinyPilot. This platform started off as a software install for the Raspberry Pi platform and evolved into a successful commercial product line. $399 gets you a fancy box that offers IP KVM capabilities with little hassle; a step up from raw hardware costs, but still drastically cheaper than enterprise options. We’ve been following Michael Lynch’s blog for years and appreciate all of the details he shared while building(and eventually selling) the business. The application stack is mostly written in Python and available under permissive and human-friendly MIT license. Again, a pretty solid stack, and there isn’t too much concerning at first glance, except for the apparently intentional total lack of authentication controls:

1. The default install has no password. This seems like a silly thing to nitpick, but the DoD may disagree.

2. The open source version doesn't support authentication, at all. This is a Splunk-level move of charging for basic security.

3. There's no password unless you buy the Pro version or configure basic auth via nginx on your own. Good luck!

We're giving this product a C on the security side for leaving casual users wide open. Also getting the DoD hacked (benignly).

JetKVM #

A newer competitor in the small IP KVM market is JetKVM. This device has an open source application stack written in Go and provided under an only mildly insulting GPL-2 license. JetKVM sells their product via Kickstarter for $69 plus shipping. The platform appears to be based on the Rockchip RV1106 SOC (ARM). Digging into the source code (released in December 2024), there are a few things worth noting. First-off, this is meant to be a cloud-managed product first, and a local device second. Whether this is a plus or a minus may depend on your level of paranoia. It does seem to help with internet-wide exposures. Overall, the following things stood out:

1. The out-of-box setup allows the initial password (or no password mode) to be configured through the web interface. This is totally reasonable, but it's worth keeping an eye out for factory-reset JetKVM or newly installed systems. The /device/status page will return whether the system is already setup.

2. An unauthenticated user can learn quite a bit about a JetKVM from the web interface. The /device/ui-config.js endpoint returns the device hostname and/or cloud API endpoint, as well as the software version. The /metrics endpoint is a prometheus exporter that provides detailed data about the running system

While the JetJVM leaks a bit of data by default, the application stack is pretty reasonable, and we're confident that it will improve over time. The combination of cloud management and VPN support seems to be reducing the public exposure of these devices. The Go code doesn't smell bad. We're giving this a B for now.

GL.iNet Comet #

GL.iNet is mostly known for making cute travel routers based on OpenWRT. Their first product in the IP KVM space, the GL.iNet Comet (RL-RM1) is built on the PiKVM source code and sells for about $90. The base OS is still Arch Linux and the base stack is still the PiKVM kvmd, but with some notable differences in exposures:

1. The kvmd API supports a few more things, including the AstroWarp cloud service, fingerbot, and firmware upgrades. These are all post-auth, but it is additional attack surface. The zip handling for upgrades might not be resistant to zip-slip-style traversal attacks.

2. A brand new device can be initialized through the web interface using the /api/init/init?password=[val] request. This only works for the first configuration, but it's a difference from the PiKVM set. The /api/init/is_inited endpoint can also return the country code where the device was configured.

3. An unauthorized user can determine if 2FA is enabled by requesting /api/2fa/is_enabled.

All told, this is basically a PiKVM, and we're comfortable giving this device a matching A- score.

BliKVM #

Originally built on the Raspberry Pi hardware, the newer BliKVM models use an AllWinner SOC that is most likely a MangoPi board. Prices vary on model, with the Raspberry Pi-based devices starting around $110, while the BliKVM v4 retails for about $300. The vendor offers two separate OS images; one based on the PiKVM image, and a separate OS for the AllWinner-based devices. The application side can also switch between the PiKVM interface (with patches) or a new, node.js + C thing built by Blicube. This could explain why we found so few BliKVM systems; they could be identifying as the PiKVM application stack instead.

1. The source code trees include various compiled object files where the source doesn't appear to be readily available. We don't particularly like unknown binaries in our open source installations.

2. Secrets are scattered all through the source. It's not clear if these are default settings, or actually used, but the references to the "janusoverlord" password for the admin API don't give us warm fuzzies about defense in depth.

We're going to give this one an A- for PiKVM OS and application variant and a C for the newer AllWinner and node.js stack. If you own the BliKVM hardware, you should consider using the PiKVM OS and application stack instead of the BliKVM option.

NanoKVM #

Finally, let's discuss the Sispeed NanoKVM. This product was introduced in December 2024 and is built on the LicheeRV RISC-V board, a rarity in an embedded Linux world dominated by ARM systems. The NanoKVM comes in a few form factors, including a Lite, Desktop, and PCIe variants, with a Pro version now available for pre-order. Pricing is incredibly cheap relative to other KVM devices in this post, with the Lite starting at $25 and the maxed-out Pro still going for less than $100. 

On the software side, these devices run a customized Linux OS image and a recently mostly-open-sourced, Go-based software stack (GPL-3). We happened to have a NanoKVM PCI-e (with POE & WiFi) on hand and decided to poke around a bit. The PCIe device we purchased has four power options — USB-C, internal USB headers, PoE, and PCIe. This makes deployment super flexible, even though we were disappointed that the PCIe connector is only used as a power source. As a result, it will run equally fine plugged into the motherboard, glued to the side of the case, or sitting on your desk with Dupont cables running to your system. It's the only PCIe card we have that is arguably more useful when not plugged into a host machine.

As a RISC-V-based device with a Go stack, we wanted to love it, but the software still needs a lot of work, and we were disappointed from a security perspective:

1. Open security issues remain unresolved, and the repo lacks a SECURITY.md file, so there’s no clear disclosure or patching process.

2. Issue #270 documents a fix for a critical bug: changing the web UI password doesn’t update the system (SSH) password. 

3. A classic shell metacharacter command injection flaw in the serial terminal was recently patched. 

4. Sketchy binaries are downloaded on startup using a request that leaks the device ID.

5. The device ships with a working microphone by default.

6. Other indicators that security wasn’t top of mind:

   • JWT tokens fall back to using time.UnixNano() if rand.Read() fails.

   • If the bcrypt password check fails, the fallback logic uses a non–time-constant string comparison in order to support older hash formats.

The system we received is running application 2.1.1 and while the "Check for Updates" option shows that version 2.2.8 is available, applying this update doesn't work, and the only way to patch the device is to manually overwrite files using SSH. We don't expect casual users to go this effort and can't recommend that anyone use this device until the base image has significantly improved.  Some of these issues were reported as far back as August 2024 (before devices shipped en-masse) and the developers claimed to be working on a PiKVM port, but that clearly hasn't happened and may not be in progress.

We're giving this a rating of F for now. We also recommend watching apalrd's deep dive video: NanoKVM: The S stands for Security.

Host Detection #

So far, we’ve focused on network detection — but many of these devices also leave fingerprints on the host. With the right rules, this data can feed into your XDR or SIEM to flag dodgy behavior. If you are concerned that one of your employees is dialing in from Pyongyang through an in-country laptop farm, this section might help confirm your suspicions.

All six of these KVMs rely on the Linux USB Gadget API to emulate USB hubs, keyboards, mice, and network adapters. These show up in system logs and registry entries with static identifies — like device names, serial numbers, vendor IDs, and product IDs — making detection straightforward unless the user customizes the settings.

Detection Resources

• PiKVM & GL.iNet Comet: Identifying PiKVM on the target host

• TinyPilot: Can anyone detect when I'm using TinyPilot?

• JetKVM: Offers UI-based device profile changes and seems less interested in supporting detection. See Jeff Geerling’s “Not an Apple Watch” post for lsusb output.

The Hold Me Closer, Tiny Pilot article at Grumpy Goose includes the default USB Vendor and Product IDs for PiKVM and TinyPilot. The PiKVM IDs may also apply to BliKVM and the GL.iNet Comet due to their use of the PiKVM code. In both cases, the default settings identify the KVM product in the manufacturer string. A sample CrowdStrike Falcon query for identifying these devices in their default state is:

#event_simpleName=/^DcUsbDevice(Connected|Disconnected)$/ /kvm/i

While some devices let you spoof vendor/product IDs, the USB hub identifiers are hardcoded by the Linux Gadget implementation, which is much more work to mask.

This is a great tip for threat hunters: if you see a Linux Foundation vendor ID for a newly attached USB hub on a Windows laptop, it’s worth a closer look.

The Grumpy Goose Unemployfuscation post suggests some other clever ideas, like looking at the number of devices hanging off the hub and the advertised power draw.

EDID & Display Fingerprinting

Many KVMs present to the host as a HDMI display, which in turn supports something called an EDID (Extended Display Identification Data). While editable, these values often default to useful identifiers for KVM products. Changes are usually done for compatibility reasons, not evasion, and its common to see KVMs return EDID codes assigned to oddly outdated monitors — like old Toshiba LCDs.

On Microsoft Windows, the event log named Microsoft-Windows-DeviceSetupManager/Admin with Event 112 provides information on connected devices, including USB, but also HDMI displays. As a result, it makes sense to review all Event 112 events, not just USB device connections. The Unemployfuscation article suggests using WMI queries to obtain the display identifiers, and gives an example of matching the "LNX777X" IDs used by default in both PiKVM and TinyPilot.

Summary #

We hope this post gave you a solid foundation for identifying modern IP KVMs both on the network and at the host level. While most of the software stacks aren’t terrible, there’s plenty of room for improvement. We’d love to see more of these projects move to a full Go userland to reduce their attack surface. (Also: we like Go.)

Our only clear “do not deploy” recommendation goes to NanoKVM — promising hardware, but the security concerns are significant enough that it's worth waiting for the application side to to mature before deploying these anywhere important.

If you’re using one of these devices:

• Set strong, non-default passwords for both the web UI and underlying OS

• Use firewall rules, Tailscale, or your own VPN to limit exposure

• Watch for mouse jigglers — many KVMs keep the screen awake by design. That may violate org-wide screen lock policies. It also lets an attacker who hijacks the KVM access the connected device without additional authentication.

If you’re looking at purchasing one of these devices:

• The PiKVM, GLKVM, and JetKVM are all decent choices.
• The BliKVM is great if you install PiKVM, otherwise avoid.
• The TinyPilot charges for basic authentication.
• The NanoKVM is still a trainwreck :(

Want to detect them with runZero?

The query "type:BMC" is all it takes to accurately find all six of these devices in addition to more common enterprise KVMs.

New to runZero? Grab a free 21-day trial that converts to the Community Edition (up to 100 devices). Great for home labs and curious pros.

Until next time — happy scanning!