A Thousand Masks: Where the DPRK IT-Worker Threat Meets Your Data

In Mexican lucha libre, the mask is sacred. A luchador can wrestle for decades and never show his face, and to be unmasked in the ring is the ultimate defeat. The legendary Mil Máscaras, whose name means “a thousand masks,” was known for wearing a different one for every opponent.

North Korea’s fake IT-worker program fights the same way. Not one attacker but thousands of fabricated identities applying for remote engineering jobs, each a different mask for a different company, all worn by the same state-run operation behind them. The personas have names, résumés, and faces, and none of them are real. As in the ring, it comes down to a single question: who is behind the mask, and can you pull it off before the match is decided?

A suspicious applicant can be caught at the first email, during an interview, or at a background check. Each catch matters. But when someone reaches onboarding, another question becomes urgent: what is inside the environment they are about to enter?

That is what makes this an insider-threat problem as much as a hiring one. A DPRK hire is an insider who arrives through the front door, already trusted and provisioned, hostile from the first day rather than an employee who turns later.

So we hunted them across the organizations we monitor, tracing every possible DPRK persona through the hiring funnel and measuring the sensitive data and system access waiting at the companies where they reached onboarding. The two halves of that picture, the threat (how far they progress) and the risk (what is exposed if they succeed), tell a sharper story together than either does alone.

A steady stream through the hiring funnel

Here is what we observed in three different windows:

In the one-year window, 2,429 distinct suspected DPRK personas made contact. Of those, 1,100 reached an interview or a later stage, and 27 reached onboarding activity, including offer letters, background checks, equipment requests, or first-day IT setup.

Even in the one-day window, 22 personas made contact, two reached an interview or later, and one reached onboarding.

Each of these is a mask to be pulled off before it reaches the ring, and the further one gets, the fewer chances remain to do it. That makes early identification valuable. But the 27 that reached onboarding call for a second line of inquiry: whether credentials were issued, what access was granted, and what happened next. By that stage, a hiring investigation and an access investigation may be converging.

One persona, several hiring pipelines

The same persona can appear at more than one company. That gives defenders a pattern that an individual organization may have trouble seeing.

One luchador, a different mask in every ring. Over the year, 41% of personas appeared at more than one organization. Fifteen appeared at ten or more, and one appeared at nineteen. One identity can surface again and again across companies that each see only their own hiring process.

At the sharp end, 18 of the 27 personas that reached onboarding were also in process at other organizations. One was completing onboarding paperwork at one company while pursuing opportunities at seven others. An organization may see one applicant; a wider view can reveal the same identity moving through several hiring pipelines.

Reused personas, résumés, and infrastructure can connect cases that look ordinary in isolation. Those connections give investigators more to test while the person is still in the hiring pipeline.

Meet your new insider threat

If a mask gets through, the question is no longer who it is but what it could reach. This is the insider-threat problem in its hardest form: most programs watch for a trusted employee who might one day go wrong, but here the trust is misplaced from the start, so the control that matters most is how little any one account can reach. The danger of a fraudulent hire is not only the sensitive data an organization holds. It is how much of that data a single new account can reach, and how far beyond its owners that data has already been shared. A new engineer who can open repositories and financial folders on day one is a very different risk from one whose access is narrow and whose sensitive files are tightly held.

To understand the stakes, we inventoried the sensitive files at each organization where a persona reached onboarding.

Volume is only half the picture. The question that decides the risk is access: who can reach each of these files, how widely they are shared, and how much a newly provisioned account could open without anyone approving it. That is the difference between a hire who sees only their own team's work and one who can quietly read the company's source code or export its financial records. Mapping which files hold what, who can reach them, and where sharing has drifted wider than intended is what turns a suspicious hire from an unknown into a contained problem.

Four onboarding cases in one month

In the last 30 days, 232 suspected DPRK personas made contact with 99 organizations. At 42 of those, at least one moved beyond contact to an interview or offer, and at four, a mask reached onboarding.

Here is what each of those four environments held.

Our telemetry identified the following in each one. In the profiles below, each percentage is the share of that data type shared company-wide or by public link.

Organization 1: roughly 15 million files flagged as source code and about 130,000 flagged with bank or routing numbers. Access here was comparatively tight: these files were held closely, shared with almost no one beyond their owners, which is the posture the other environments should be measured against. The first access question is which repositories and files the new role would receive.

Organization 2: around 400,000 files flagged as containing Social Security numbers, 345,000 with bank or routing numbers, and several million source-code files. And the exposure was not hypothetical: 68% of those Social Security files, about 277,000, and 71% of the bank and routing files, about 248,000, were shared company-wide or by public link, reachable by any account inside the organization with no special permission. An insider would not have to reach for this data; it was already open.

Organization 3: about 14 million source-code files, of which roughly 1,900 were shared by public link, readable by anyone with the URL. At that scale, even a tiny fraction left openly shared is a meaningful amount of code.

Organization 4: roughly 1.5 million source-code files and files flagged as containing private cryptographic keys. Even here the sharing had drifted: about 21% of its financial files and 17% of its credit-card files were shared beyond their owners. The smallest of the four environments still held material worth investigating closely.

The four environments could hardly have differed more in how exposed that data was. At one, almost nothing sensitive reached beyond its owners; at another, most of the identity and financial records were open to the entire company. Same adversary, very different blast radius, decided largely by how each organization had managed sharing and access.

Four personas, four organizations, one month. Each reached onboarding. For each case, the next step is to identify the account, the permissions it received, and any activity in the environment. That is where the inventory becomes useful: it tells investigators what to examine first.

Defend the applicant stage and the environment inside

A DPRK hire is an insider threat with valid credentials, so the response pairs hiring controls with the access controls that limit what any one account can reach.

• Identify suspicious personas as early as possible. Recruiting and onboarding produce signals worth connecting with threat intelligence. Early detection can prevent an identity from getting credentials in the first place.
• Treat the stage of the case as part of triage. A watchlist hit at first contact and the same hit during onboarding call for very different urgency. Confirm the identity and the evidence, then check whether an account or equipment has already been issued.
•  Verify identities carefully and investigate inconsistencies. Background checks and hiring controls are opportunities to catch a fabricated persona before credentials are issued.
• Continue the investigation after onboarding. If an account was provisioned, review its permissions, app grants, and activity. A suspicious identity with legitimate access changes the questions defenders need to answer.
• Map sensitive data and limit access before a case arises. Know which files, messages, credentials, and connected apps each role can reach. If a suspicious person is onboarded, that map helps responders focus immediately.

For most luchadores, losing the mask is the end; unmasked once, they never wear one again. That was never the point of Mil Máscaras. Lose one of his masks and he simply wore another, because there were always a thousand more. It is the same here: expose one mask, and the operation puts on another. Unmasking a single applicant is a real win, but the supply never runs out. The only lasting defense runs on both fronts at once: pull off the masks you can at the door, and make sure the ones you miss walk into an environment where very little is theirs to reach.