Most developers read package.json. Almost none read .npmrc. That asymmetry is the entire attack.
A recent disclosure from OpenSourceMalware โ a small open-source supply-chain research outfit, not a tier-one threat intel shop โ laid out the mechanics with uncomfortable plainness. A fake recruiter on LinkedIn. An invitation to a "private code repository." A hidden configuration file sitting at the repo root, quietly pointing the dependency registry at a server the attacker controls. The developer runs npm install as part of a "technical interview." Every dependency resolves โ but from the wrong place. A postinstall script fires before any human reads a single line of code. Environment variables, SSH keys, browser credentials, wallet files: gone in seconds.
Follow the gas, not the hype. Here the gas is a text file with one line in it.
I have spent years auditing smart contracts. Fifty-plus ICO contracts in 2018 alone, hunting reentrancy bugs that everyone else waved through. I built Python pipelines to scrape raw Ethereum mainnet transactions and track liquidity-pool ratios across twenty DEXs. I have never once opened a .npmrc during an audit. Neither have you. That is not a personal failing. It is a structural one, and it is being farmed at scale right now.
Context: A Campaign That Is Old, Wearing a New Mask
"Contagious Interview" is not new. It has been tracked for years under different vendor codenames, and the broad narrative โ DPRK-linked actors posing as recruiters to reach crypto developers โ has appeared repeatedly since 2023. What is new, and this is the only real increment in the disclosure, is the specific delivery mechanism: abusing a project-level .npmrc to redirect the dependency source to an attacker-controlled private registry.
The npm workflow deserves precision, because the whole attack lives inside a detail most people skip. When you run npm install, npm reads configuration in a defined precedence order: command-line flags, then environment variables, then a project-level .npmrc, then a user-level file, then global settings. The project-level file wins over almost everything below it. It is plain text. It is frequently committed to repositories. It is almost never reviewed.
Once registry= is set to an external host, npm resolves every package name against that host. The package names are legitimate. lodash is still lodash. axios is still axios. But the tarball that arrives is whatever the attacker's server chooses to serve. There is no name mismatch to catch, no typosquat to flag. The victim installs "the right package" and receives the wrong bytes.
Then the install lifecycle runs. npm executes preinstall, install, and postinstall scripts by default. Those scripts are arbitrary code. They run as your user, with your permissions, before you have reviewed anything. That is the execution primitive. Everything downstream โ credential theft, wallet exfiltration, lateral movement into the employer's CI/CD โ hangs off it.
The reported attribution is to a DPRK-linked cluster. Treat that with calibrated confidence. The disclosure says "linked to North Korea" but does not publish the method โ no code-similarity analysis, no infrastructure overlap, no language fingerprinting. That is a real evidentiary gap, and I will return to it.
What the report does not give you is equally important: no IoCs. No domain. No package names. No hashes. No victim count. No dollar figure. For a defender, that means the report is a reminder, not a detection rule. You cannot configure a signature off a narrative.
Core: A Trust-Boundary Transfer, Not a Code Exploit
The .npmrc file is silent by design. Developers have a well-trained reflex to scan package.json and package-lock.json. They do not have a reflex for dotfiles at the repo root that configure tooling. The same blind spot covers .yarnrc.yml, pip.conf, .pypirc, settings.xml, and .cargo/config.toml. These files are configuration dark matter โ they shape everything and are read by almost no one. An attacker who understands this does not need a vulnerability. They need your inattention.
The lockfile does not save you, and the widespread belief that it does is actively dangerous. The integrity field in package-lock.json is a hash of the tarball the registry returned. If the attacker's registry returns a malicious tarball, the attacker simply generates a lockfile whose integrity hash matches that tarball. The lockfile is internally consistent. It is consistent with the wrong artifact. "We have a lockfile, so we are safe" is a category error โ it verifies that the bytes you received match the bytes you were served, not that the bytes you were served are the ones you wanted.
Default script execution is a structural design flaw, not a misconfiguration. preinstall and postinstall firing automatically means the npm ecosystem executes untrusted code as a matter of routine. This is not a bug you patch in your repository. It is the substrate the entire ecosystem sits on. Every mitigation โ ignore-scripts, containerized installs, npm ci โ is a workaround for a design decision made years ago and unlikely to change, because changing it would break a large fraction of published packages overnight.
Put those together and you get the real thesis: this attack is not a code exploit. It is a trust-boundary transfer. The developer believes they are trusting the package name plus the public registry's review. The .npmrc quietly substitutes the attacker's server as the trust anchor. Nothing in the visible workflow announces the swap. Code is law, but bugs are fatal โ and the deadliest bug here is not in your source. It is in your assumptions.
The primitive is ecosystem-agnostic. The disclosure only discusses npm. The same logic rewrites pip.conf with a new index-url or an --extra-index-url for dependency confusion. It rewrites a source line in a Gemfile. It plants a settings.xml. It redirects GOPROXY. It swaps a source replacement in .cargo/config.toml. One configuration file, any language. If you harden npm and leave pip.conf alone, you have closed one door in a hallway of identical doors.
This is also the Layer2 lesson in miniature, and it is worth stating plainly. The winner in a technical contest is rarely the most elegant cryptography โ it is whoever owns the deployment path first. Here the deployment path is npm install, and the attacker owns it for the duration of a single interview task. The sophistication of your dependency-review tooling is irrelevant if the config file underneath it points somewhere else.
Now the economics, because this is where the "shadow economy" framing earns its keep. I am not going to pretend there is a token model here โ there is not. But there is an attacker cost structure, and it is brutally asymmetric.
Attacker cost: a LinkedIn account, free or cheap. A domain plus a private registry, under a hundred dollars a year. Developer hours. That is the entire capital outlay. Attacker revenue: two channels. Direct โ wallet files, private keys, exchange sessions sitting on the victim's machine. Indirect โ cloud credentials, repository permissions, CI/CD secrets, which become lateral movement into the employer's production environment.
The funding source is a state, not a market. There is no token unlock schedule, no quarterly earnings pressure, no VC runway to protect. This attacker does not stop in a bear market. Every assumption that economic incentives will suppress the attack fails here. The ROI on compromising a single crypto developer โ who may hold hot wallet keys, a shard of a multisig, or deployment credentials โ dwarfs traditional financial crime by orders of magnitude.
This is where my on-chain work intersects the story, and it is the part the security report cannot see. The disclosure stops at "wallet files stolen." I care about what happens next, on the ledger.
A stolen keystore is not a headline. It is a transaction waiting to happen. When a developer's wallet file and its password leave the machine together โ which is common, because both often live in the same home directory or the same password manager โ the attacker holds a sign-ready key. The first on-chain signal is usually not a large transfer. It is a small test transaction: a few dollars moved to confirm the key works and the balance is real. Follow the gas. The test transaction often pays a fee disproportionate to its value, because the attacker is validating control, not moving value.
From there the pattern is familiar to anyone who has traced exploit outflows. Consolidation into a small number of addresses. A pass through a mixer or a cross-chain bridge. An OTC desk or a peer-to-peer intermediary. Fiat or commodity conversion. Repatriation. The on-chain footprint of a stolen developer wallet looks less like a hack and more like a routine treasury sweep โ which is exactly why it does not trigger alarms until it is too late. Whales don't panic; they reposition. The attacker behaves the same way: no drama, just quiet reallocation across dozens of hops before anyone notices the balance moved.
The reason crypto developers are the target โ and not, say, a random SaaS engineer โ is asset density. A crypto developer's laptop is more likely than almost any other machine to hold directly monetizable value: hot wallets, key material, exchange API keys with withdrawal permissions, deployment keys for contracts that custody user funds. The attacker is not selecting for salary. They are selecting for the density of immediately liquidatable secrets. That is portfolio-selection logic, and it is rational.
There is a second-order on-chain consequence worth flagging. When these campaigns succeed at the employer level โ not the individual level โ the stolen credentials can reach deployment keys. A compromised deploy key is a supply-chain attack on the contract itself. That is the scenario where an off-chain .npmrc incident becomes an on-chain solvency event. I have watched this movie before. In 2022 I traced over 500,000 UST redemption transactions and found a liquidity gap six weeks before the collapse. The failure was not in the stablecoin's code. It was in the assumptions around it. Same pattern here. The code is fine. The trust assumptions around the toolchain are not.
One more layer, and it is the one that should worry risk teams most. In September 2025 the npm ecosystem saw self-propagating worms โ the Shai-Hulud class of incidents โ that exposed systemic weaknesses in credential management and automated publishing. Combine a worm's propagation with a pre-established trust channel like a hijacked registry, and the blast radius compounds. A single compromised maintainer token becomes a fleet-wide event. The .npmrc primitive and the worm primitive are not the same attack, but they multiply.
The regulatory angle is thinner than the technical one, but it is not zero. DPRK-linked actors are sanctioned entities. Any exchange, custodian, or DeFi front-end that touches the stolen funds inherits secondary-sanctions exposure under OFAC. VASPs face AML and Travel Rule obligations to identify and freeze flows from these addresses โ and the laundering chain described above is designed specifically to defeat that. On the corporate side, EU entities under NIS2 and DORA can face penalties if a supply-chain compromise is judged a failure of "adequate security measures." There is a quieter exposure too: employment compliance. If the same campaign infrastructure doubles as a channel for DPRK IT workers to onboard remotely under false identities, the issue graduates from a security incident to a sanctions and labor-law problem. That transition changes the regulatory response entirely. But note what the disclosure does not contain โ no regulator, no statute, no enforcement action. This is evidence-chain material for future attribution, not a new compliance obligation today.
Contrarian: The Industry Is Reading This Wrong
The dominant reflex is to file "crypto got hacked" under "on-chain security demand rising." That reflex is wrong here, and it matters because it misallocates defense budget. This attack lives entirely off-chain. It touches the development environment, not the ledger. The beneficiaries are traditional software supply-chain security โ SCA tooling, behavioral package analysis, DevSecOps โ not smart contract auditors and not formal-verification shops. If you are a protocol allocating security spend after reading this, the money does not go to another audit. It goes to endpoint isolation, dependency governance, and install-time sandboxing.
Attribution deserves skepticism. "Linked to North Korea" without a published method is a medium-confidence claim dressed as a high-confidence one. The macro story โ DPRK-linked actors running fake-recruitment campaigns against developers โ is well-established across multiple vendors and years. That part I believe. The specific claim that .npmrc hijacking is this campaign's signature move rests on a single small research shop, relayed by a Korean crypto outlet, with no independent cross-verification in the material. Correlation is not causation, and a single-sourced technical detail is not a signature. Treat the mechanism as real and reproducible โ it is โ while treating the attribution of this specific instance as provisional.
The disclosure also misidentifies the victim. The framing centers the job seeker. The actual target is the job seeker's future employer. The individual loses a wallet. The employer loses cloud credentials, repository access, and potentially production deployment keys. That is a thousand-fold difference in loss magnitude, and it explains why the attacker is willing to invest weeks in a "low-value" individual. The individual is not the prize. The individual is the door. And the social layer is the weakest link in the whole chain: a recruitment conversation requires strangers to build trust, which is in direct conflict with security principle. You cannot patch that with a scanner.
Takeaway: What to Watch Next Week
The signal is not a price candle. It is whether a second independent vendor publishes IoCs โ registry domains, package names, hashes โ that let defenders build detection rules. If that does not appear within a couple of weeks, treat the mechanism as confirmed and the campaign specifics as unverified. Harden the config-file layer across every ecosystem you touch, not just npm. Audit the dotfiles nobody reads. Run unknown repositories in disposable containers with install scripts disabled. The .npmrc is not a footnote in the attack chain. It is the attack chain. Code is law, but bugs are fatal โ and the one that gets you will not be in the contract you audited. It will be in the file you never opened.