
Reputation Radar #16: The Employee Who Was Never Home
The FBI raided more than 40 homes in Texas running laptop farms for North Korean IT workers. Every signal a company checks said 'American employee working from home', because the laptop really was in an American home. Here is what that looks like from the reputation column, and the remote access tools we started labelling properly this week.
Most of the attacks we write about try to look like something they're not. This week's didn't have to. The laptop was the company's own. It sat in a house in Texas, on a normal home internet connection, in the right time zone. The person typing on it was in North Korea.
Forty houses in Texas
On October 13th the US Justice Department announced a coordinated set of actions against North Korea's remote IT worker schemes. Between September 21st and 25th, the FBI searched more than 40 suspected laptop farms in Texas under an operation called Lonestar Roundup and seized around 187 laptops and KVM devices. A separate indictment in Ohio charged 14 people over a scheme that ran from 2019 to July 2025, reached more than 70 US companies and raised roughly $3 million for the regime.
The model is simple, and that's what makes it work. A North Korean worker gets hired for a remote job using a stolen or fabricated identity. The employer ships a company laptop to the address on file. That address belongs to a facilitator, often an American recruited for the job, who plugs the laptop in at home and keeps it running. From then on the worker drives it from abroad.
The FBI's public service announcement that went out the same day is unusually specific about the "drives it" part. It names the remote access software: AnyDesk, TeamViewer, RustDesk, Chrome Remote Desktop and Splashtop. And it names the hardware: KVM-over-IP devices such as TinyPilot, PiKVM and GL.iNet, small boxes that plug into the laptop's video output and USB port and let someone control it over the network without installing anything on it at all.
Every check passes
Think about what a company actually looks at when it decides a remote employee is who they say they are.
The login comes from a residential US IP address, because the laptop really is in a US home. The device is the company's own, managed and patched, because it is. The time zone is right. The FBI even lists OBS Studio with the VDO.Ninja plugin among the software it sees abused in these schemes. And the remote control runs through mainstream remote access vendors that half of all IT teams use every day, or through a KVM box that leaves no software trace on the laptop.
That's the part that gets us. Nothing here is borrowed in the usual sense. The reputation is genuine. The IP is a real household's connection, the laptop is real, the vendors are real. The only fake thing is the person, and none of those checks look at the person.
What the reputation column shows
We ran both layers of this through our own API.
The connection itself comes back empty, and correctly so. A home broadband address hosting one of these laptops looks exactly like the house next door: no feed history, low confidence, just the ISP and the city. We made the same point in Radar #15 about phones turned into residential proxies. Reputation can't tell you who is sitting behind a clean home connection, and it shouldn't pretend to.
The remote control layer is where we had work to do. When we ran the FBI's list of tools, the domains for AnyDesk, TeamViewer, RustDesk and Splashtop already carried the right tags underneath (remote access, dual use), but the label on top was a generic "high-traffic domain" with a hint about popularity. Worse, Chrome Remote Desktop came back as likely benign, simply because it lives on a Google hostname. Several remote access relay and agent hosts came back likely benign too.
We fixed that this week. These services now read as "Remote Access / RMM Tool", with the verdict at investigate, and Chrome Remote Desktop is treated the same as the others rather than as ordinary Google traffic. We deliberately kept the recommended action at "allow with logging" rather than "block", because plenty of IT teams and managed service providers rely on exactly these tools. The new hint asks the questions that matter in a case like this: did your IT team deploy this agent, was it installed recently, are sessions unattended or happening at odd hours, and is there a KVM-over-IP device in the picture?
So the honest summary for a SOC is this. Reputation won't find the laptop farm for you. What it can do is make sure the remote access tool on that laptop shows up as a remote access tool, not as background noise from a popular website. The FBI's own advice is to layer weak signals together, and it calls that "identity in depth". A remote access agent IT didn't install is one of those signals. A KVM device showing up as an unexpected USB keyboard and capture card is another.
Also on the radar
- BeyondTrust Remote Support zero-day. Mandiant tied exploitation of CVE-2026-102764, an arbitrary file upload in BeyondTrust Remote Support appliances, to a suspected China-nexus group it tracks as ARMORY CASTLE, starting in late August, about six weeks before the October 15th disclosure (Google Threat Intelligence). The attackers dropped a PHP web shell and a SOCKS tunneller, then edited the appliance's own reverse proxy so their traffic rode in on a legitimate-looking path. Another remote access product, this time as the way in rather than the way around.
- Eight trusted certificates went bad. Cloudflare found that the private keys behind eight eMudhra intermediate certificates, trusted by browsers and operating systems, were weak enough to be compromised (Cloudflare). In their words, "an attacker can create a forged certificate for any domain." Browsers pushed revocations quickly. Their plea to developers is worth repeating: don't make the new errors go away by turning verification off.
- A genuine Siemens binary, malicious DLLs. Siemens ProductCERT warned that attackers are distributing a real, validly signed copy of Siemens Software Center alongside malicious DLL files that the vulnerable version loads at startup, tracked as CVE-2026-110936 (Siemens ProductCERT). Both distribution IPs in the advisory come back malicious in our API today: they sit in a hosting network that a widely used list of criminal-run networks already flags.
If you want the longer read on why a trusted name in the reputation column is where the question starts, not where it ends, we walked through it in Borrowed reputation: when attackers hide behind trusted infrastructure.
See you next week.
Sources are linked inline, with credit to the US Department of Justice and the FBI for the laptop farm details and to the original researchers and vendors. If we got a detail wrong, tell us and we'll fix it.
About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.
Ready to Try Reput.io?
Start reducing false positives today with our free plan.