Detecting DPRK IT Worker Infiltration: What the Signal Actually Looks Like

By 2026 the DPRK remote-worker placement scheme — variously tracked as Famous Chollima, Nickel Tapestry, WageMole, UNC5267 — has graduated from a curiosity into a recurring HR and SOC problem. The shape of it is well-established: operators in the DPRK, China, or Russia route their identities through US-based facilitators, land salaried engineering roles at Western companies, route the corporate laptop through a residential laptop farm, and exfiltrate either wages, source code, or both. Mandiant, CrowdStrike, and the FBI advisories have all said roughly the same thing. The interesting question for defenders is not whether the threat exists. It is what the detection looks like the morning after you turn it on, which fields you actually pivot through, and which assumptions silently break the rules someone copied off a blog.

This piece is for the SOC lead and the ISSO sitting on the same call, trying to decide whether to spend the quarter on this. The short version: yes, but the detections you build will overlap heavily with insider-threat and remote-access work you should already own, and the first week of alerts will mostly be your contractors in Bangalore and a sales engineer working from a hotel in Lisbon. That’s fine. That’s the job.

What the scheme actually does on the wire

The operator never touches the corporate laptop from the DPRK directly. The laptop ships to a facilitator’s address — a residential US or EU address that resolves cleanly against the offer letter — and lives in a closet or rack with a USB KVM or remote-access tool bolted on. The operator drives it from overseas through a residential proxy (Astrill is the long-standing favorite, but by 2026 the proxy ecosystem has fragmented enough that ASN-based blocking is a losing game), or through a remote-control utility such as AnyDesk, Chrome Remote Desktop, RustDesk, or in some clusters a PiKVM-style hardware bridge that presents only as a USB HID and a monitor to the corporate endpoint.

The hardware-bridge variant is the one that breaks naive detections. From the EDR’s perspective the laptop is sitting in Phoenix, the user is typing on a keyboard, the mouse is moving, no remote-access binary is installed. There is no AnyDesk process to alert on. The only signals are network-side and behavioral.

The network side is the easier of the two, and where I would put the first round of detection budget.

The actual detections, in actual fields

For an Entra ID / Okta shop with EDR (CrowdStrike or Defender for Endpoint) and a SIEM ingesting sign-in logs, the high-value pivots are mostly join-and-count work, not single-event rules.

Sign-in geography vs payroll address. In Entra’s SigninLogs, the field is Location.countryOrRegion plus IPAddress and the derived NetworkLocationDetails.networkType. The detection most teams reach for first is “sign-ins from outside the country listed in Workday.” It works, but the false positive rate is brutal — travel, VPN, family visits. The version that actually pays for itself adds two conditions: the sign-in country differs from payroll and the IP’s ASN is on a residential-proxy or hosting-provider list and the user has not filed a travel ticket in ServiceNow in the last 14 days. That third clause is the one nobody implements until the second tuning pass, and it cuts volume by something like an order of magnitude. (Numbers are illustrative — depends entirely on your contractor footprint.)

Impossible-travel that doesn’t look like impossible-travel. Microsoft’s built-in Risky sign-in detection catches Lagos-to-Lisbon in twenty minutes. It does not catch Phoenix-to-Phoenix where the Phoenix sign-in is a residential IP and the corporate device just happens to be checked in from an Astrill exit node six hours earlier in a different session. You want a custom KQL rule that groups by UserId over a 24-hour window and flags sessions where IPAddress resolves to distinct ASNs and one of them is on a residential-proxy enrichment list. The enrichment list is the load-bearing piece. Spur, GreyNoise, and IPQS all sell this data; the open-source residential-proxy lists are stale enough by 2026 that I would not build a production rule on them alone.

EDR keyboard/mouse cadence. Both CrowdStrike Falcon and Defender expose enough process telemetry to write a behavioral rule for KVM-over-IP indicators, but the cleanest signal is the absence of expected signal: a developer machine with no Teams.exe, no Outlook.exe, no chrome.exe browsing to internal SharePoint, but consistent git.exe and code.exe activity for eight hours a day. The laptop is being used like a build box, not a workstation. That alert will fire on your CI/CD bastions too, so the rule needs an exclusion list — or, better, restrict it to assets in the HR-owned “issued laptop” cohort. Tying that cohort to a CMDB field rather than an OU is the part teams put off and regret.

RMM and remote-access binaries on developer endpoints. AnyDesk, RustDesk, TeamViewer, Chrome Remote Desktop, Parsec, Splashtop. A standing CrowdStrike custom IOA for any of these executing on an engineering-fleet device is cheap and worth running. Expect noise from anyone who used to do IT support on the side. Expect a fight with the one principal engineer who insists on RustDesk for their home lab. The right answer is still to alert.

Authentication device fingerprint reuse across identities. This is the strongest single signal and the hardest to build. In Okta the field is client.device plus userAgent.rawUserAgent; in Entra it’s DeviceDetail.deviceId and DeviceDetail.browser. If two distinct “new hire” identities have ever authenticated from the same device fingerprint within their first 30 days of employment, that is almost never benign. It is either a laptop farm, a shared kiosk that should not exist, or an IT tech imaging boxes — and the third case is easy to whitelist by user. The query is a self-join on sign-in logs over the new-hire window. It is not expensive. Most teams do not write it because nobody owns the new-hire cohort definition.

What the first week of alerts actually contains

If you stand up the geography rule and the RMM-binary rule on Monday, by Friday you will have:

• A pile of legitimate-traveler false positives, most of which trace back to one of three sales engineers and a CFO.
• Two or three contractors whose laptops are in a country the contract says they shouldn’t be in — which is a real finding but usually not DPRK.
• One genuinely weird case where a developer’s laptop is authenticating from a residential IP in a state they don’t live in, and HR has no travel record. This is the one that matters. Nine times out of ten the explanation turns out to be a family situation or a quiet relocation nobody told HR about. The tenth time is the one that pays for the program.
• A fair amount of EDR noise from IT staff using LogMeIn or ScreenConnect for legitimate support, which you will end up scoping to a service-account exclusion. Don’t scope it to user accounts — that’s the hole the operator walks through.

The tuning work in week two is mostly building the exclusion logic for the travel/contractor cases without building it so loosely that the actual signal disappears. The pattern that breaks down here is the one where someone defines “trusted countries” as a static list. Two months later a legitimate hire moves to Portugal, gets added to the list, and the list now contains a country the operator can route through. The exclusion has to be per-user and time-bounded, not global.

Where it goes sideways

A few specific failure modes worth naming.

The hardware-KVM variant defeats every network-side detection that depends on remote-access binaries. If your program is built entirely on “alert when AnyDesk runs,” you will catch the lazy operators and miss the careful ones. The compensating control is shipping the laptop with a tamper-evident seal on the chassis and requiring a video onboarding call where the new hire holds the device up to the camera with the seal visible. Cheap, low-tech, surprisingly effective. Several of the public Famous Chollima writeups have noted operators refusing or stalling on video calls — that refusal is itself a signal HR should be trained to escalate.

Git telemetry is underused. A developer who clones the entire monorepo in their first week, from a residential IP, at 0300 local time relative to their stated location, is doing something that should at least generate a ticket. GitHub Enterprise and GitLab both expose this in audit logs; the field in GHE is actor_ip on git.clone events. Most SOCs aren’t ingesting these because the volume is high and the value per event is low — but for the new-hire cohort, in the first 30 days, the volume is manageable and the signal is good.

Payroll and crypto are the other side. The wages route through US banks to prepaid cards and eventually to mixers. Your SOC will never see that. Treasury and finance might, if anyone has built the relationship. Usually nobody has.

Control mapping

For the ISSO writing this into the SSP, the relevant families are less exotic than the threat sounds.

The PS-3 / IA-12 pairing is where the program either works or doesn’t. Every detection downstream is compensating for a weak identity-proofing process at hire. If HR is doing live video interviews with government-ID verification through a vendor like Persona or Onfido, and the verification is bound to the eventual MFA enrollment, the SOC’s job gets dramatically smaller. If HR is doing phone screens and emailing offer letters, the SOC is the only line of defense and the detections above are load-bearing.

The part most teams get wrong

The single most common failure I would expect: treating this as a SOC problem instead of a joint HR–IT–Security program. The detections cannot work without the HR data feed — the payroll address, the travel records, the contractor flag, the staffing-vendor identifier. If your SIEM cannot join sign-in logs against a current employee record keyed on userPrincipalName, you cannot build the rules that matter, and you will spend the quarter writing geography alerts that fire on legitimate travelers and get muted by the analyst on shift.

Get the HR join working first. The detections are easy after that.