The DPRK Developer on Your Payroll Runs Over a KVM Dongle and an RMM Tool. The Interview Never Caught It; Your Endpoint and Connection Logs Can

Eight US-based “laptop farmers” sentenced in five months, cases that span more than 100 US companies in one prosecution and nearly 70 in others, and the through-line across the major US laptop-farm prosecutions and incident-response investigations reads the same way: a corporate laptop that shipped to a US residential address is being driven from somewhere else — over a KVM-over-IP dongle or a commercial remote-desktop tool — by a developer drawing a US salary that funnels back to a sanctioned weapons program. That is the state of the DPRK IT worker scheme in mid-2026, and the uncomfortable part for defenders is that by the time you can see it in telemetry, HR has already lost. The operator cleared the video interview, passed a background check keyed to a stolen or synthetic identity, and is sitting in your IdP as a legitimate employee. What actually resolves the case is a correlation in your SIEM between the unauthorized remote-access tooling on the endpoint and the connection and network telemetry it throws off — enriched with shipping-address anomalies and the abnormal rhythm of a seat handed around the clock. Sign-in geography helps at the edges, but a properly run laptop farm makes the identity’s ordinary logins look domestic: the tell is the endpoint and the connection, not the sign-in country.

TL;DR

  • DPRK IT workers pass the video interview and background check on stolen or synthetic identities, so the reliable signal isn’t HR vetting — it’s correlating the unauthorized remote-access tooling on the endpoint with the connection and network telemetry it generates, plus shipping and behavioral anomalies. Sign-in geography is supporting evidence, not the second half: the laptop farm makes ordinary logins look domestic.
  • The scheme runs a US laptop farm where employer-issued devices are driven from overseas either via RMM/remote-desktop tools (AnyDesk, RustDesk, Chrome Remote Desktop, TeamViewer, plus mouse-jiggler utilities) that generate process events, or via a KVM-over-IP dongle (TinyPilot/PiKVM) that looks like a local human typing and leaves no RMM process or conventional remote-desktop session on the corporate laptop (though the dongle can surface through USB/device telemetry and management-plane network activity).
  • Detection that works correlates RMM/KVM indicators with the remote-access connection telemetry — where the operator’s overseas/Astrill IP actually lands (Mandiant tied it to the RMM connections, not the corporate sign-in) — plus endpoint network activity and multi-day sessions with no clean logoff and 3-a.m.-local productivity no single person could sustain. Enrich whatever source IP you get by ASN/hosting category (hosting ASNs like Sharktech/Cogent beat plain foreign-country-code logic).
  • First-week tuning: allowlist sanctioned RMM tools by team, carve out legitimately-overseas staff (a data-quality problem in the HR feed), and switch geo logic from country to hosting-ASN category so the intersection alert collapses to a handful of real cases.
  • No software control fully closes the KVM-dongle gap, but it isn’t invisible: USB enumeration, composite-device descriptors, default TinyPilot naming, and SSH/web-interface traffic to the dongle expose sloppy deployments. Default-deny RMM and phishing-resistant MFA raise the cost; the rest is device-inventory hygiene, shipping-address discipline, and onboarding checks that don’t assume a serial read proves physical location.

The May 2026 sentencings of Matthew Knoot and Erick Prince, reported by Help Net Security, are worth reading not for the 18-month sentences but for the mechanics buried in the plea documents. Prince enabled at least three North Korean IT workers to land remote US jobs through his Taggcar front, spread across dozens of companies; the victim companies paid those workers over $943,000 in salary, most of it routed overseas. Knoot ran company laptops out of a Nashville house and, with his co-conspirators, cost the victim companies more than $500,000 combined in auditing and remediation. Both did the same boring thing: received the employer-issued device, installed remote desktop software, and handed the session to an operator overseas. That’s the whole trick. No zero-day, no EDR bypass.

Why the interview is the wrong place to fight this

Every vendor writeup leads with the HR red flags — AI-generated profile photos, reluctance to turn the camera on, VoIP callback numbers, universities with implausible enrollment dates. Fine. Those help a recruiter who’s paying attention. But the identity work has gotten good enough that treating the interview as your control point is a losing bet, especially when the candidate arrives through a staffing agency and your team never runs the vetting directly. CSIS’s analysis of the scheme’s global expansion makes the point that the pipeline has industrialized past the point where face-value screening catches it reliably.

So assume the operator gets hired. The question a SOC lead should actually be asking is: what does this look like in the index once the badge is issued?

Two things, mostly. The endpoint runs remote-access tooling it has no business running and reaches out to infrastructure it shouldn’t, and the identity’s session rhythm — and, in the direct-auth cases, its geography — doesn’t match a person living where the W-2 says they live.

The mechanism: laptop farm, KVM-over-IP, and a mesh you can’t see

The physical setup is a laptop farm — one US-based facilitator hosting a rack of employer laptops, each one a different fake employee at a different company. Nisos, in its teardown of an actual farm, described roughly 40 devices on the network with about 20 active, stitched together with a Tailscale mesh and reached from overseas through Astrill VPN, a service popular in China. They traced the whole thing partly with canary tokens, which tells you how thin the OS-level evidence was.

Two access methods matter, and they leave very different telemetry.

The software path is the easy one to catch. Chrome Remote Desktop, AnyDesk, RustDesk, TeamViewer, Splashtop, LogMeIn — Google’s Mandiant team, tracking the cluster as UNC5267, lists the usual suspects and notes that multiple remote-admin tools on one system is itself the high-value indicator. They also flag Caffeine and similar mouse-jiggler utilities used to keep several laptops awake across several jobs at once. All of it leaves conventional endpoint artifacts — process execution, service creation, software inventory, installers, persistence, outbound connections — so it surfaces somewhere in the endpoint stack. Just don’t lean on a bare process-creation hunt alone: an install that predates your retention window, a renamed binary, a persistent service, or an MSI push can all sit in inventory without a recent process event.

The hardware path is the problem. A TinyPilot or PiKVM dongle sits between the laptop and the network as a keyboard/video/mouse device, presenting to the operator as if they’re physically at the keyboard — it works before the OS even boots. DTEX’s i3 threat advisory says a KVM-over-IP device was confirmed in the majority of the incidents they examined. From the operating system’s point of view there is a human typing — no RMM process, no remote-desktop port, nothing in DeviceProcessEvents that screams remote. But “no obvious RMM signal” isn’t “invisible.” DTEX reports catching these with high recall and precision: the USB device-insertion and composite-device descriptors when the dongle is plugged in, the default TinyPilot device name that farm operators often never rename, and the SSH sessions and web-interface traffic to the dongle’s management interface. Those tells lean on the operator being sloppy — which, in the farms actually torn down, they frequently are. The gap is real: a KVM dongle defeats the host-level RMM process and connection detections most strategies lean on, and anyone selling you “we detect DPRK workers” should still have to explain what they do about it before you sign anything. But it’s a gap you narrow with device and USB telemetry, not one you throw up your hands at.

What the detection actually looks like in the SIEM

Start with the software path because it pays off fastest. If you’re on Defender for Endpoint, hunt DeviceProcessEvents for the RMM binary set; Palo Alto published a Cortex XDR hunting query covering 20-plus RMM tools if that’s your stack. In Splunk against Sysmon EventCode 1, a process_name match list for anydesk.exe, rustdesk.exe, chrome_remote_desktop*, teamviewer.exe, and caffeine.exe is a ten-minute search. The trick isn’t writing it — it’s that the raw hit count is worthless on its own. Your help desk uses ScreenConnect. Your sales engineers use TeamViewer. A flat “AnyDesk was installed” alert will bury you.

The tuning that makes it usable is correlation — but be precise about which telemetry carries the overseas signal. The remote-access connection logs are where the operator’s real origin surfaces: Mandiant found the connections to those remote-management tools came primarily from Astrill VPN IPs in China or North Korea. That’s the RMM session terminating at the US laptop — not the corporate sign-in, which egresses from the laptop’s US network and looks entirely domestic. So the join that resolves it is RMM/KVM presence on the endpoint against the connection and endpoint-network telemetry that tooling generates, layered with shipping-address anomalies and the session-rhythm signals below. Sign-in geography is a supporting input — it earns its keep mainly in the variants where the operator authenticates directly (VDI, SaaS from an unmanaged device, or an opsec slip), not in a cleanly run farm.

For those identity signals, pull sign-in logs from your IdP — and get the field names right. In Entra’s SigninLogs (Sentinel/Log Analytics), the columns are IPAddress, LocationDetails, and AutonomousSystemNumber, plus the risk fields RiskEventTypes_V2 (the unversioned riskEventTypes is deprecated), RiskLevelDuringSignIn, and RiskDetail (the disposition/remediation state). Detailed risk detections take Entra ID P2: without it, RiskLevelDuringSignIn comes back hidden, and the premium detections collapse to a generic “Additional risk detected” (riskEventType = generic) instead of naming the underlying type. Watch the value names too: the native travel detection surfaces as unlikelyTravel (Microsoft’s “Atypical travel,” itself a P2 detection), while mcasImpossibleTravel is a separate Defender-for-Cloud-Apps-derived detection that needs Entra ID P2 plus Defender for Cloud Apps, or a Microsoft 365 E5 / EMS E5 entitlement; anonymizedIPAddress is the anonymous-proxy value. Both are behavioral, not raw-distance, detections — Microsoft says the atypical-travel algorithm ignores obvious false positives such as VPNs and locations regularly used across the org — so a farm proxying through a consistent US endpoint may never trip either travel signal. In Okta’s System Log it’s client.geographicalContext.country and securityContext.isProxy — but isProxy only flags a known proxy from IP-reputation enrichment, so corporate gateways, SASE, and consumer VPNs set it too; treat it as corroboration, not proof. The naive version — alert on any non-US login for a US-based employee — drowns instantly on travel and consumer VPNs. The version that works enriches the source IP by ASN and hosting category. Astrill and the residential-proxy fronts these operators favor terminate on datacenter ASNs; the documented Astrill exit IPs sit in Sharktech, Cogent, Peg Tech, and similar hosting ranges, not on a Comcast residential block. A hosting-ASN source for an account that’s supposed to be someone’s home office in Ohio — and in the farm model that source is more often the remote-access connection log than the sign-in — is worth ten times a plain foreign country code. Spur or a comparable proxy-context feed does this enrichment; Palo Alto points at Spur’s context tool specifically. Don’t publish the static IP list to a blocklist and call it done — those addresses rotate, and treating a two-month-old IOC set as coverage is how you end up with a green dashboard and a live operator.

The behavioral layer is where DTEX’s numbers help. They observed session intervals running 1 to 23 days without a logout — an operator hands the seat off around the clock, so the session never ends the way a normal 9-to-5 does. They configured alerts for multiple unique identities logging into the same web portals from the monitored employee’s endpoint context, and reported confirmed DPRK cases frequently exceeding that threshold, plus banking/crypto account-creation velocity above five new accounts in under 60 days. Those last two you mostly won’t have visibility into unless you’re a financial platform, but the session-duration one is yours: query your VDI or IdP for accounts whose active session spans multiple calendar days with no clean logoff, then cross-reference against off-hours activity relative to the employee’s stated timezone. An account that’s productive at 3 a.m. local every night, with minimal Slack or email to match the commit volume, is a concrete example of the kind of prolonged, erratic pattern worth investigating; in its confirmed cases DTEX measured total activity volumes it judged “impossible for a single individual.”

How much noise this throws is entirely environment-specific — it rides on your endpoint mix, contractor population, help-desk model, EDR retention, VDI footprint, sanctioned-RMM estate, travel population, and whether you’re counting installs, executions, or mere presence. Don’t anchor on a number you read in a blog, this one included; validate the intersection against 30 to 90 days of your own telemetry before you assign severity or staff to it. What you’re hunting is the collapse: RMM or KVM indicators on an endpoint, the connection or network telemetry pointing at hosting/Astrill infrastructure, and a multi-day session that never logs off cleanly — that intersection should reduce to a small, high-fidelity queue. If it doesn’t collapse, inspect the ASN enrichment, the RMM allowlist, connection directionality (inbound RMM session vs ordinary outbound vendor-cloud traffic), HR and timezone context, the VDI estate, and event deduplication before you call the rule production-ready.

Where the false positives come from, and the first week of tuning

Much of the expected noise is legitimate remote administration and remote work — though the same tooling also turns up in shadow IT, help-desk software left behind after a support call, outsourced administration, red-team activity, and unrelated intrusions that abuse legitimate RMM. IT admins with a dozen remote-support tools. Contractors who genuinely live abroad and are supposed to. Digital nomads on a corporate VPN that egresses through a datacenter. VDI power users whose Citrix sessions stay open for days by design — which, incidentally, is why a VDI-heavy environment changes this whole analysis: if nobody gets a physical employer laptop, the KVM-attached-to-that-laptop vector evaporates. But that doesn’t make the problem disappear, it moves it. DTEX has documented DPRK operators pivoting to VDI specifically to dodge KVM and RMM indicators, including using privileged access at one company to reach another; the operator still remotely controls whatever device reaches the VDI. You lose the shipping-address and device-serial checks that catch the fraud at onboarding and inherit a harder identity-and-session problem, not an easier one.

First-week tuning, in order: build an allowlist of sanctioned RMM tools mapped to the teams permitted to run them (help desk, IT, specific vendors) and suppress those pairings. Then carve out the roles and named individuals who are legitimately overseas — HR knows who they are even if your SIEM doesn’t, so this is a data-quality problem before it’s a detection problem. Then flip the geo logic from country-based to ASN-category-based, because residential-proxy adoption has made “foreign country code” nearly useless as a standalone signal; hosting-ASN and commercial-VPN context are more useful for the infrastructure documented in these cases, but neither survives an operator who shifts to well-run residential proxies. Expect the intersection alert to be quiet and high-fidelity once those three are done. If it’s still loud, it’s rarely one thing — check the HR timezone data, RMM ownership mapping, SASE and VDI egress, connection directionality, and event deduplication before you touch the threshold.

Control mapping

Signal / control gap NIST SP 800-53
Screening keyed to a synthetic identity; identifier issuance; staffing-agency subcontracting chain PS-3, PS-7, IA-4, SA-9, SR-6
Unauthorized RMM / remote-desktop on managed endpoints; nonlocal maintenance tooling CM-7 (least functionality), CM-8, SI-4, MA-4
Remote-access connection origins in proxy/hosting ASNs; telemetry correlation AC-17, AU-6, SI-4, CA-7
Multi-day sessions, concurrent identities, off-hours mismatch AU-6, AC-2(12)
Weak binding of person to credential; MFA and separate-device authentication IA-2, IA-2(1), IA-2(2), IA-2(6), IA-5
Weak device identity and attestation IA-3, CM-8

The IA family is where you can structurally raise the cost. Phishing-resistant, hardware-bound MFA (IA-2 with a FIDO2 authenticator) shuts down credential replay and passwordless sign-in from an unmanaged device — the direct-auth variants. It does less against the farm than it looks: a token left plugged into or sitting beside the hosted laptop can still be exercised remotely over the KVM or RMM session, and if the authenticator’s user verification is a PIN rather than a biometric, it proves possession of the key, not presence of the claimed employee. Real assurance needs controlled, supervised issuance and enrollment, user-verifying authenticators, and policies that keep the token from living permanently in the laptop farm. CM-7 software restriction that denies RMM by default turns your loudest, noisiest signal into an enforcement boundary instead of an alert. Neither fully closes the KVM-dongle gap; that one comes down to device- and USB-inventory hygiene and onboarding controls — and be honest about what those prove. Reading an asset tag or serial over a video call shows someone can see the device, not that the employee is at the claimed address; a facilitator can hold the laptop up to the camera. The controls that actually bite are verified delivery to a photo-ID’d recipient, investigating shipping-address divergence, flagging multiple “employees” that resolve to one address, live challenge-response at onboarding with periodic re-verification, and correlating payroll, tax, HR, and device-location anomalies.

Treat this as an insider-access problem with a nation-state on the other end of the session, and instrument the telemetry that actually carries the operator’s origin — the endpoint’s remote-access tooling and the connection and network activity it generates — so it can be correlated with shipping, device, and behavioral anomalies. Sign-in geography rides along for the direct-auth variants; it isn’t the load-bearing half. The interview was never going to hold. The correlation will, once the connection and ASN enrichment is real and the RMM allowlist is honest about who’s supposed to be there.

Sources


This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.

Leave a comment