Postinstall Was the Labubu

A labubu is what everyone rushes to buy right as it stops being the thing worth having. postinstall had the same arc. For three years it was the threat model — the lifecycle hook that runs the instant you type npm install, before a single line of the package has been read. So we fortified that one door: install-script sandboxes, static analysis that trips on preinstall and postinstall, CI that strips lifecycle scripts before they can execute. We got exceptional at guarding it — precisely as the attackers stopped using it. Postinstall attacks haven’t vanished; but every eye is on that door now, so the real action moved to the one nobody bothered to lock.

Last week, an attacker published more than 700 packages to npm in 48 hours and walked straight past all of it — because they never touched the install step at all.

There is no postinstall in these packages. There is no preinstall. There’s a README that says, in effect: load this library with require(). And that’s it. That single, ordinary call — the one you type a hundred times a day without a second thought — starts the infection. The README isn’t documentation. The README is the exploit.

‍

‍

This is the part worth sitting with. The novelty isn’t the malware. It’s where the malware chose to live. Execution moved from install-time to runtime, from a hook you scan to an import you trust. Everything we built to watch the install moment is now looking at an empty doorway.

A sleeper in a hollow SDK

The package OpenSourceMalware pulled apart, checkout-mobile-bnpl, presents itself as a tidy little mobile checkout SDK. It exposes a class with init(), version(), configure() — all the furniture of a legitimate library. None of it does anything. The real behavior is one line at the bottom of index.js, quietly loading a helper file that runs itself on import. You don’t have to call a suspicious method. You just have to require() it once, anywhere in your tree, in dev or test or a production cold-start.

From there it’s a professional’s kill chain, and every stage is built to look like something boring:

• It fingerprints your OS and CPU, then pulls a native payload over HTTPS from rotating Cloudflare Workers hosts. No signature check, no hash, no pinning — whatever the server returns gets executed.
• If you block those hosts, it reconstructs the same binary out of DNS TXT records — one lookup for the chunk count, then numbered lookups, Base64-decoded and stitched back into an executable. Block the obvious HTTPS route and the payload still arrives, in pieces, through the one protocol nobody thinks to firewall.
• It writes the payload somewhere forgettable — /var/tmp/.cache_… on Unix, %TEMP%\dotnet_diag_….exe on Windows — and launches it detached. Kill npm, kill Node: the malware is already gone, running on its own.
• It even ships an 80 KB telemetry.js — a plausible analytics SDK with the same downloader logic buried inside, sitting there for no reason except to survive a rushed code review.

‍

‍

On Windows, Sonatype found the next stage patches ETW and AMSI to blind your monitoring, checks for VMs and debuggers, persists through a Run key and a scheduled task, and reflectively loads its final payload in memory — never touching disk where your EDR is watching. On macOS, it hunts for frida and lldb, hides its config behind a single-byte XOR, and installs a LaunchAgent masquerading as an Apple window-server helper. On Linux, it’s a UPX-packed ELF that fetches what one researcher believes is a Sliver implant. The strings point to Russian fintech, and the tradecraft links it to the earlier “Moika” campaign.

Read that list again and notice what it’s a list of: defeating the name check, the hook scan, the signature, the hash, the DNS filter, the disk-based EDR, the sandbox, the code review. Nine disguises, one for each checkpoint we inspect. Every artifact was poisoned on purpose.

Every artifact — except one.

The one thing you can’t fake

Here is the observation that reframes the whole campaign: malicious code has to do something. And doing is the one thing you cannot disguise.

You can randomize the package name. You can strip the install hook. You can polymorph the source so every one of 800 variants is byte-different but behaviorally identical — which is exactly what Sonatype watched this actor do, precisely to break signature matching. You can pack the binary, XOR the config, patch the logging, load reflectively. You can make the artifact lie at every layer we’ve built a checkpoint for.

What you cannot do is make a “mobile checkout SDK” spawn /bin/sh to execute a freshly-dropped binary — and have that look normal. You cannot reconstruct an executable from DNS TXT records without producing a call sequence no legitimate library on earth produces. The payload is disguisable. The behavior is not, because the behavior is the point.

‍

‍

And notice: there is no CVE anywhere in this story. No vulnerability, no CVSS score, nothing for a scanner to match. This isn’t an exploit of broken code — it’s malicious code delivered as a dependency and executed by trust. A security program organized around the CVE has, structurally, nothing to say about checkout-mobile-bnpl. This is the post-CVE threat, and it is going to be the majority of what hits developer and CI/CD environments from here.

The template, not the incident

The economics just flipped, permanently. For years, defense won by cataloging — known-bad names, known-bad hashes, known-bad publishers. That worked when producing a malicious package was expensive and cataloging it was cheap. Automation and AI inverted that. This actor spun up disposable accounts, published a handful of packages from each, and generated endless behaviorally-identical variants faster than any registry can review or any blocklist can grow. npm now accounts for 96.6% of the malicious packages Sonatype logs — not because npm is uniquely broken, but because it’s where the automation points.

So here’s the near future, and none of it is speculative:

• Names become noise. AI-generated slopsquatting means the package identifier carries no signal. “Is this name known-bad?” stops being a useful question.
• Execution keeps retreating from your checkpoints. If install hooks are watched, it moves to require(). If import is watched, it’ll move to first real use, to a config load, to a dependency three layers deep — legitimate at every point you inspect, malicious only at the point you don’t.
• Legitimate infrastructure becomes the delivery network. Cloudflare Workers, DNS TXT, public CDNs — the payload rides rails you can’t block without breaking your own stack.
• AI ends up on both sides. Attackers generate and mutate at scale; defenders answer with behavioral analysis at runtime — kept local and cheap, with AI reserved for the investigation layer, not the detection loop.

The uncomfortable truth this campaign hands us is that the artifact can no longer be trusted to tell you what it is. The name lies. The hooks are gone. The signature shifts every build. Peel away every disguise and you’re left with exactly one honest signal: what the code does when it runs.

‍

So point a camera at it.

The one signal the attacker couldn’t fake is behavior at runtime — so that’s where Raven ADR watches. We put a camera on every library in your running app and analyze exactly what it does: the precise call sequence, at the CPU level, in production, with no instrumentation. Our patented Library Call-Chain™ learns what each library legitimately does — so when a “checkout SDK” reaches for a shell or rebuilds a binary from DNS TXT, it doesn’t matter that the payload is packed or the name is brand new. It’s a library doing something it has never done, and Raven stops it the instant it happens.

‍

No CVE. No signature. Just the one thing the attacker couldn’t disguise. That’s the category Gartner just named ADR — and this campaign is exactly why it exists.

Raven ADR is the camera in every room — watching your code behave, frame by frame, and shutting it down the moment it makes its move.

See Raven ADR in action →