The DPRK Worker’s KVM Is Plugged Into Your Laptop, Not the Internet. Hunt the Sign-In Log Instead

The thing that makes the DPRK IT worker problem hard isn’t tradecraft. It’s that there’s no intrusion to detect at initial access. Nobody phished a credential, nobody dropped a beacon, nobody escalated anything. A person overseas — operating from China, Russia, or another DPRK staging location — applied for a remote engineering job under a stolen or rented American identity, passed your interview loop, signed the offer, and received a corporate laptop at an address in Ohio that belongs to a facilitator paid to plug it into a rack and leave it on. Every session after that is an authorized session. Valid credentials, MFA satisfied, a real managed endpoint with your EDR agent reporting in green. The control that should have caught this — PS-3, personnel screening — already failed before a single packet crossed your wire.

So you’re left trying to catch it downstream, with monitoring controls that were built for a different threat model. That’s the whole shape of the problem, and it’s worth being honest that you’re playing defense from behind. The quiet front door is only the start, though: once the access is live, the documented endgame includes source-code and sensitive-data theft, cryptocurrency drain, and post-discovery extortion. The hire is the part your detections miss; the abuse that follows is ordinary insider risk, and it’s real.

The numbers are not small. In the June 2025 coordinated action, DOJ and the FBI searched 29 known or suspected laptop farms across 16 states; per The Record’s writeup, a subset of that — 21 premises across 14 states between June 10 and 17 — yielded roughly 137 seized laptops. The Wang indictment out of New Jersey alone described a scheme using 80-plus compromised identities to place workers at more than 100 U.S. firms, generating over $5 million. Mandiant’s tracking of the cluster it calls UNC5267 put a single facilitator at 300-plus affected companies and $6.8 million over three years. This is a revenue program with the scale of an APT and the access posture of your own staff.

The KVM is the artifact everyone reaches for, and it’s the wrong layer first

Walk into this cold and the first instinct is to hunt the device. The operator can’t physically touch the laptop, so they bridge it: an IP-KVM sits between their keyboard and the corporate machine, presenting itself over USB as a keyboard, mouse, and sometimes a virtual optical drive, while streaming the screen back over the network. TinyPilot is among the most commonly observed; PiKVM and the Sipeed NanoKVM turn up too. These leave real fingerprints. The SANS Internet Storm Center diary on detecting them is the cleanest reference I’ve seen: the NanoKVM enumerates as USB ID 3346:1009, PiKVM as the Linux Foundation multifunction composite gadget 1d6b:0104, TinyPilot ships with a default serial of 6b65796d696d6570690 and answers to tinypilot.local, PiKVM’s default unit serial is the unforgettable CAFEBABE. There’s even an EDID angle — get-edid | parse-edid against the presented monitor reveals vendor strings like VCS or PiKVM V3, which almost nothing monitors today.

Here’s the problem with making that your primary detection. The laptop is sitting behind the facilitator’s home router, NATed, on a residential cable line. You will never Shodan it. The KVM’s web interface isn’t exposed to you; it’s exposed to the operator’s Tailscale tailnet — Nisos documented one farm running roughly 40 devices, about 20 actively bridged, stitched together with a Tailscale mesh so there’s no listening port facing the internet at all. External scanning finds only the misconfigured KVMs with a port forwarded. It does not find the disciplined ones running behind a mesh VPN.

That pushes you onto the endpoint, where your EDR can in principle see the USB device enumerate. CrowdStrike’s DcUsbDeviceConnected telemetry, the equivalent device-control events in Defender, plain old Windows PnP event logs — they’ll record a HID keyboard and a mass-storage device appearing. And the default descriptors above are greppable. For about a week.

Then somebody on the other end reads the same SANS diary you did. PiKVM ships a config file specifically for overriding the USB vendor, product, and serial strings; the operator sets them to mimic a Logitech receiver and your VID/PID hunt goes dark. The descriptor is attacker-controlled metadata. Building a durable detection on a field the adversary can rewrite in a text editor is how you end up with a rule that looked great in the lab and finds nothing in month two.

And the false positives are brutal before you even get there. Every server with a BMC — iDRAC, iLO, the Supermicro IPMI in the corner — is an IP-KVM by definition. Every datacenter has hundreds. Every developer with a KVM switch on their desk to share one keyboard across a work and personal machine trips it. In a BYOD-heavy shop the baseline of weird USB composite devices is already high. You can scope the USB rule to corporate-issued endpoint asset tags and exclude your server VLANs, and you should, but understand what you’ve built: a low-coverage, high-maintenance signal that catches the lazy operators and misses the competent ones. Keep it. Don’t lead with it.

The signal that survives tuning is in the identity provider

The detection that actually holds up is behavioral, and it lives in your sign-in logs: it’s strongest when several unrelated employee identities — from your own tenant, or from a provider’s cross-customer telemetry — authenticate from the same physical wire. That shared-IP cluster is the hardest thing for the farm topology to hide, with one caveat about whose laptops are sharing the wire.

A laptop farm is, by construction, many corporate laptops in one room on one internet connection. When ten of them phone home to Entra ID or Okta, they share an egress IP. Ten distinct UserPrincipalName values authenticating from one residential or fixed-line IP address, none of whom are supposed to know each other, is not a thing that happens by accident — the ASN is what tells you whether that IP is residential, hosting, or VPN, but the cluster is the IP itself. The catch is whose laptops they are: a single farm often hosts machines for several different employers, so your own tenant may see only one suspect identity from that IP while a cross-customer vantage sees the whole cluster. The signal is cleanest when several of those identities land in your tenant — otherwise you’re leaning on a provider’s cross-environment view to connect them. ReliaQuest’s reporting describes exactly this — multiple insiders at a single victim from the same fixed-line IP, in one case up to ten distinct personas inside one organization within six months. This holds while the farm shares one connection; an operator who fronts each laptop with its own residential proxy breaks the shared-IP tell, at a cost in money and discipline that not all of them pay.

The query shape is mundane. In Sentinel:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where UserPrincipalName !endswith "#EXT#"
| summarize users = dcount(tolower(UserPrincipalName)),
          names = make_set(tolower(UserPrincipalName), 20),
          firstSeen = min(TimeGenerated),
          lastSeen = max(TimeGenerated)
  by IPAddress, AutonomousSystemNumber
| where users >= 3

Three distinct successful principals from one IP in a rolling week is a reasonable starting threshold. It is also, on day one, going to bury you. Your own VPN concentrators and egress NAT will each show hundreds of users behind a single IP — exclude your corporate ASNs first, that’s non-negotiable, and if your traffic egresses through a SASE provider like Zscaler or Netskope, the ASN you’re drowning in is theirs and not yours, so allowlist those egress ranges by name rather than assuming “your ASN” covers it. Coffee shops, coworking spaces, university dorms, and apartment-building shared NAT all produce legitimate multi-user clusters. Commercial VPN exit nodes do too, and plenty of real employees run NordVPN on the company laptop because they always have. Your first tuning pass is almost entirely allowlisting: known-good shared egress, service and automation accounts, residential ranges with a plausible family-of-employees explanation, the VPN ASNs your acceptable-use policy actually tolerates.

What’s left after that scoping is genuinely interesting. A residential or small-business IP — its ASN neither a hosting provider nor a VPN — with three or more unrelated employee identities, where those identities were all hired remotely in the last year, is about as clean a laptop-farm signature as this problem offers. Enrich the surviving IPs against the hosting and VPN ASNs the public reporting keeps naming: Astrill VPN is the workhorse, and Mandiant published a working list of Astrill-associated egress sitting on Sharktech, Peg Tech, GorillaServers, Eonix, and similar bulletproof-adjacent providers. Russian TTK ranges out of the Khabarovsk region and China Unicom blocks show up when the operator connects to the KVM directly instead of through the corporate tunnel.

The richest tell is the leak. Astrill drops connection more than the operators would like, and when it does, the next authentication arrives from the real upstream — a Khabarovsk fixed line, a Chinese mobile ASN — before the tunnel re-establishes. That’s a geovelocity hit your impossible-travel rule should already fire on: a sign-in from a U.S. residential IP and one from a Russian Far East ISP for the same principal, minutes apart. Okta surfaces this in client.geographicalContext; Entra’s risk detections will usually flag it as atypical travel. The catch is that legitimate globally-distributed contractors and outsourcers who quietly subcontract their work generate the identical pattern, so impossible-travel alone is a lead, not a verdict. Correlate it with the shared-IP cluster and the RMM stack covered in the next section before you escalate to anyone’s manager.

The supporting stack, and where it maps

Don’t expect the IdP signal to stand alone. Pair it with what the operators install on the endpoint within hours of receiving it, because they need remote control and they need to look busy across several jobs at once. The recurring stack: AnyDesk, RustDesk, Chrome Remote Desktop, VS Code tunnels, TeamViewer, often two or three layered for redundancy — and a mouse-jiggler, frequently Caffeine, to keep multiple laptops awake and “active” while one human cycles between them. Multiple distinct RMM agents installed on a single corporate endpoint inside the first week is a strong corroborating signal, and it’s one your existing software-inventory or EDR process telemetry already collects. Hunt for parallel RMM installs and tie them back to the device’s assigned user.

Where this lands in NIST 800-53 Rev 5 is unusual, because the center of gravity is personnel, not technology.

The instinct on an audit is to file this under SI-4 and call it a monitoring gap. It isn’t, mostly. It’s a PS-3 failure that you are paying to detect after the fact with SI and AU controls, and the detection is expensive, noisy, and incomplete by design. The shared-residential-IP cluster is the best signal you’ve got, but it only catches the farm topology — the lone operator running one laptop out of an apartment with a clean residential IP and a spoofed KVM descriptor produces almost nothing for you to alert on. For that one, the camera-on interview, the device-serial check at onboarding — does the laptop’s hardware serial match the unit you shipped to the claimed address — and the device that never geolocates to the claimed address are doing the work, and those aren’t SOC controls at all.

Most teams build the USB-descriptor rule first because it feels concrete, watch it rot, and conclude the problem is unsolvable in the SIEM. The order is backwards. Build the IdP correlation, spend the first two weeks allowlisting your own egress until the residential clusters are all that’s left, and treat the KVM fingerprint as confirmation you collect after a principal is already suspect — never as the thing that makes them suspect.

Sources

• Justice Department Announces Coordinated, Nationwide Actions to Combat North Korean Remote IT Workers’ Illicit Revenue Generation Schemes (U.S. Department of Justice)
• DOJ raids 29 ‘laptop farms’ in operation against North Korean IT worker scheme (The Record)
• Staying a Step Ahead: Mitigating the DPRK IT Worker Threat (Google Cloud / Mandiant)
• Threat Spotlight: Red Flags for Red Star Hackers — Hunting for North Korean Insiders (ReliaQuest)
• Detecting IP KVMs (SANS Internet Storm Center)
• DPRK IT Worker Fraud: Inside a Laptop Farm Operation (Nisos)
• American duo sentenced for hosting laptop farms for North Korean IT workers (CyberScoop)