Fake AI SDKs on npm Installed a Windows RAT: Inside CloudSEK's NEBULA Report

We previously broke down slopsquatting — a new AI-era supply-chain attack — and gave a defensive playbook in our guide Vibe Project Dependency Supply Chain Security Guide. That piece was about "how to defend"; this one is about "what actually happened." In late September 2026, a single threat actor pushed seven malicious npm packages disguised as the official SDK of a company called "NebulaAI," aimed squarely at developers rushing to wire AI capabilities into their projects. On October 8, CloudSEK published the full teardown under the moniker NEBULA.

If you're a vibe coder, this one concerns you directly: attackers are no longer harvesting typos — they're riding the "AI SDK" hype itself. And your AI agent runs npm install without ever hesitating the way a human would.

The incident in one paragraph

One actor used four sequential burner accounts (nebulallms, nebulallms2, nebulallms3, nebulallms4) to publish seven fake "NebulaAI" SDK packages on npm in late September 2026. Anyone who ran npm install on any of them — on a Windows machine — got a Windows remote-access trojan at install time, without executing a single line of the package's code.

• Still downloadable: api-nebula and llm-nebula remained on the npm registry, installable, at the time of the report.
• Detection lagged badly: api-nebula was "active and unflagged for days" before its formal categorization as MAL-2026-17531 (an OSV malicious-package ID) on October 5, 2026 — the attack window was measured in days, the classification came after the fact.
• The final payload: a customized variant of KNTRAT, an open-source RAT, configured to phone home to 65.87.7.132 with the user-agent kntrat/0xB15B00B6.

Anatomy: the SDK is the facade, the install hook is the weapon

The most instructive part of NEBULA is how convincing the facade was. Each malicious package shipped an entry point, nebula.js, that looked like a perfectly legitimate AI client pointing at the domain api.nebulaai.dev — a name, a domain, a plausible API wrapper. CloudSEK's point is blunt: a security review that only inspects the package's "front door" would very likely wave it through.

The real threat lived in preinstall.cjs: an obfuscated dropper riding npm's preinstall lifecycle hook, which executes automatically during npm install — before the victim ever requires or imports anything. Install scripts are one of npm's oldest wounds, but NEBULA combined it with the AI hype, and the blast radius is entirely different.

Figure 1: The NEBULA attack chain. From npm install to a resident trojan, no user code execution is required — the install hook is the entry point. (Diagram labels in Chinese; flow matches the English text.)

The dropper had two delivery paths:

1. Embedded payload: base64- and zlib-encoded, decoded and written out at install time;
2. Install-time network fetch: a network request during installation pulls down the real executable.

The drop location was chosen with malice aforethought: %LOCALAPPDATA%\Microsoft\Conhost\conhost.exe. conhost.exe is Windows' legitimate console host — it's always in Task Manager. Drop a same-named binary into a plausible-looking system path and most users will never give it a second glance. Hiding in plain sight, done right.

KNTRAT: a trojan that "needs no DLL"

The dropped binary is a customized variant of KNTRAT, an open-source remote-access tool — and the report's headline names its strangest trait: it "Needs No DLL." It operates exclusively through direct NT and win32k syscalls, bypassing standard DLL imports and leaving an empty Import Address Table (IAT). Much EDR and behavioral detection leans on user-mode API hooks; a binary that never takes the normal import path is half-invisible to those probes.

The feature set is a standard spyware bundle: HVNC (hidden virtual desktop — the attacker drives a desktop you can't see), camera and microphone monitoring via Kernel Streaming, and Winlogon Shell persistence. The anti-analysis design is the part worth noting: during CloudSEK's sandbox detonation, the implant suppressed all beaconing across a twelve-minute window — the classic "outwait the sandbox" play that fools automated analysis pipelines.

One detail reads like project management: KNTRAT's source repository stayed private for the entire campaign and only went public after the operation concluded — on October 6, 2026, renamed from kntrat-e to kntrat. Treating an open-source project as a private weapons locker, then open-sourcing it when done, signals an actor with a full operational cycle, not a script kiddie.

Opinion: the lure moved from typos to "AI" itself

For years the dominant supply-chain playbook was typosquatting: register reqeusts, harvest the developers who fat-finger requests. That playbook has a natural ceiling — it only catches the small slice of people who mistype. NEBULA runs a different script: it no longer bets on your typos; it bets on your search for AI capabilities.

Picture npm's search box in 2026: countless developers — and their AI agents — typing "AI SDK," "LLM client," "nebula" to wire model capabilities into projects. "NebulaAI" sounds exactly like another AI infra startup; the api.nebulaai.dev domain and the polished client wrapper exist to answer the one question in the developer's mind: "does this look legit?" It looked legit. That was the problem.

My read: "AI tooling" has itself become phishing language. Like "crypto giveaway" and "free VPN" before it, every mass-FOMO tech wave eventually becomes social-engineering ammunition. The twist here is that the victims are precisely the most active, most experiment-happy developers — the vibe coders.

The vibe coder's risk chain: agents don't hesitate

This chain deserves a section-by-section audit from everyone who codes with AI:

1. You — or your agent — want a promising-looking AI SDK for the project;
2. You find api-nebula on npm; respectable name, plausible README;
3. npm install api-nebula — at this point preinstall.cjs has already run, and the trojan is sitting in the Conhost folder masquerading as a system process;
4. You haven't written a single line calling it, and you're already compromised — HVNC remote control plus camera and microphone surveillance.

The critical variable is who executes step 2. A human might — might — glance at the publish date, download counts, and repo links, though NEBULA's facade work makes even that a long shot. An AI agent won't hesitate, won't get suspicious, won't read the preinstall script: it sees "install package," it installs the package. An agent loop can fire off dozens of npm install commands in one session — industrializing the phishing on the attacker's behalf. Where attackers once had to trick a thousand humans into individual typos, now a thousand agents each run one unattended install.

The real lesson isn't "stop coding with AI." It's this: treat npm install as arbitrary code execution — because technically, it is. preinstall/postinstall hooks run with your user privileges; they can write files and hit the network. In the agent era, the sane posture is guardrails around agent-driven installs: inspect package.json scripts before installing, use --ignore-scripts by default and allowlist deliberately, or run agents inside sandboxes and containers. Giving an agent unrestricted npm install is roughly equivalent to hiring an insider who never sleeps and never asks questions.

"It's on npm" is not a security signal

NEBULA also punctures a comforting illusion: the registry as trust. Many developers subconsciously assume a package installable from the official npm registry has passed some review. The reality: api-nebula was "active and unflagged for days" before its MAL-2026-17531 categorization — and it was still installable when the report went out. OSV IDs are posthumous labels, not preemptive blocks.

Supply-chain security has always been a probability game: registry-side detection is lagging and sampled; attacker deployment is real-time and batched. Trusting "it's on npm" to mean "it's safe" is like trusting an app store to have no malware — history keeps refuting it. The more honest posture for vibe coders: every npm install is a small trust decision, worth at least 30 seconds of review — package age, maintainer history, install hooks. Thirty seconds for a machine that isn't remotely controlled. Not a bad trade.

Side by side: malicious package vs. a normal SDK at install time

A common first reaction to this kind of attack is: normal SDK installs also download things and write files — so what's the difference? The comparison below lays NEBULA's malicious package and a normal SDK side by side, install-phase behavior only. There are three differences, and every one is a red line:

Figure 2: Malicious package vs. normal SDK install behavior. The three-step self-check at the bottom: preinstall hook, network access during install, writes to system directories — stop and investigate on any hit. (Diagram labels in Chinese; flow matches the English text.)

Note the first row: a normal SDK should not execute any code at install time. npm install's job is "download and unpack into node_modules." An SDK package declaring a preinstall script in package.json has already stepped outside an SDK's job description. Granted, some legitimate packages use install scripts for native compilation (the node-gyp crowd) — but an "AI API client" has zero reason for an install hook. A pure-JS HTTP wrapper has nothing to compile. That was NEBULA's most visible tell, and the easiest rule for anyone to internalize: pure-JS utility package + install hook = blocklist it, no hearing required.

If you already installed it: incident-response checklist

CloudSEK's report includes remediation guidance for security teams. Adapted from its IoCs, here's a checklist an ordinary developer can actually execute, in order:

1. Check whether you're hit: search your projects for api-nebula and llm-nebula (don't forget package-lock.json); on Windows, inspect %LOCALAPPDATA%\Microsoft\Conhost\ for a suspicious conhost.exe — the real one lives in System32; a folder named Conhost shouldn't exist at all.
2. Cut the C2: block outbound connections to 65.87.7.132 at the firewall/gateway, and search historical traffic for hits on that IP or the user-agent kntrat/0xB15B00B6.
3. Hunt persistence: check Winlogon Shell registry entries for tampering, and sweep for the named-pipe constructions and hidden-desktop artifacts CloudSEK flagged as detection directions.
4. Treat it as a breach: if the drop is confirmed, don't just delete the file. HVNC plus camera/microphone monitoring means the attacker may already have seen your screen and heard your mic. Run the full playbook: isolate the machine, rotate credentials, reconstruct the timeline.

Three durable actions for teams: make --ignore-scripts the default for dependency installs (allowlist deliberately), audit install hooks on newly added dependencies in CI, and bound what your AI agents are allowed to execute. None of it is complicated. The complicated part is deciding to start.

Closing: phishing language follows the hype

NEBULA's tradecraft isn't top-shelf — install hooks, system-process masquerading, direct syscalls are all familiar moves in security circles. What it got right was the targeting: it placed the lure exactly where developer attention was concentrated in 2026. When everyone's wiring AI into their projects, an SDK called "NebulaAI" is the perfect camouflage.

That pattern is worth memorizing: phishing language always follows the hype. Today it's "AI SDK"; tomorrow it'll be something else. Next time you — or your agent — are about to npm install a shiny new package, ask one question first: does this package exist to solve a problem, or to be installed?