The fake employee: inside DPRK's IT-worker supply chain

The scariest supply-chain attacker doesn't break in. They get hired. They pass the interview, sign the offer, get a laptop and a real GitHub account — and then every commit they push is, technically, legitimate.

The scale is not a rounding error

Alongside the insider track, the same ecosystem runs an industrial malicious-package operation — 1,700+ poisoned packages across npm, PyPI, Go, Rust, and PHP since 2024 (Socket). The fake recruiter and the fake employee are two ends of the same machine.

Why this breaks the usual playbook

Walk it through your defenses and watch each one shrug:

• Prevention? Passkeys, MFA, branch protection, SHA-pinning — all assume the threat is an outsider trying to get access. This person was granted access. Through the front door. With HR's blessing.
• Identity verification? It happened once, at hiring — and it was defeated by AI-generated résumés, deepfaked video interviews, and laundered identities. After onboarding, the account is simply a valid employee. Impossible-travel and session-anomaly tooling sees a normal worker doing normal work (often via a US-based "laptop farm" proxy).
• Pipeline scanning? Their commits are real code, often genuinely useful. Their workflow edits are made by a trusted account with legitimate permissions. There's no flaw to flag.

When the insider holds a real badge and a real commit history, every credential is legitimately theirs and every action is permitted. The compromise isn't in who they are — it's in what they eventually do.

So what's actually left to detect?

If you can't reliably catch the identity (it's real) and you can't catch the credential (it's valid), the only thing left is the behavior — the moment a legitimate account does something that lines up into an attack shape, regardless of how clean the account looks:

• mass repository access or cloning well outside the account's normal pattern,
• an unreviewed workflow change that reaches secrets,
• egress from a build to infrastructure no prior job ever contacted,
• a credential the account holds suddenly used from a new context.

Any one of these, from a "trusted" account, is invisible to a tool watching its own domain. Stitched together, they're the kill chain — the same shape whether the hands on the keyboard belong to a hijacked maintainer, a coerced contractor, or a state operative on payroll.

An honest caveat: this is the hardest case in the field. Cross-domain correlation doesn't magically unmask a fraudulent hire — but it does catch the action even when the identity is clean, which is the part prevention and identity checks structurally can't.