al-ice.ai

The AI SDK Was the Dropper: CloudSEK NEBULA Campaign Hid a No-DLL Windows RAT in Seven Fake npm Packages

Agent & Supply Chain Security by al-ice.ai Editorial

In late September 2026, a single operator stood up a fake AI vendor — “NebulaAI” — and published seven malicious npm packages posing as its software development kit. CloudSEK, which tracks the activity as NEBULA in an 8 October 2026 report, ties all seven packages to one actor working through four sequential burner accounts (nebulallms through nebulallms4). The lure is aimed squarely at AI developers: a convincing client library pointing at api.nebulaai.dev. The payload is a customised KNTRAT Windows remote-access trojan engineered to dodge exactly the hooks defenders rely on — it issues syscalls directly and leaves an empty Import Address Table. Two packages, api-nebula and llm-nebula, were still downloadable from the registry at report time.

The facade imports clean; the hook does not

Each package couples two faces. The imported entry point, nebula.js, behaves like a legitimate AI client — the thing a hurried developer evaluates in a REPL and approves. The actual threat never waits for an import: it lives in preinstall.cjs, an obfuscated dropper that executes during npm install. CloudSEK found two delivery paths inside the hook — an embedded inline payload (base64- and zlib-encoded) and an install-time network fetch — either of which writes an executable to %LOCALAPPDATA%\Microsoft\Conhost\conhost.exe, masquerading as the legitimate Windows console host process. The package is the lure; the installation hook is the execution. Nobody has to require() anything, and no agent has to run.

The uncomfortable detail is dwell time in plain sight. CloudSEK notes api-nebula sat active and unflagged for days before its formal categorisation as MAL-2026-17531 on 5 October 2026 — and remained installable afterward. Feed entries that document these drops in isolation, the report argues, miss the operational link: a four-account burner sequence distributing one fake SDK. For defenders this is the same lesson as the MALFEX campaign’s fourteen unadvised months — registry presence is not a safety signal, and takedown lags are measured in victim installs.

A RAT built for the EDR era

The deployed implant is a customised variant of KNTRAT, the open-source Windows RAT, configured against 65.87.7.132 with the user-agent kntrat/0xB15B00B6. Its signature trait is how little it asks the operating system through normal channels: it operates exclusively through direct NT and win32k syscalls, bypassing standard DLL imports, which empties the IAT and starves import-table–based detection. The feature set is full surveillance — hidden-desktop remote control (HVNC), camera and microphone monitoring over Kernel Streaming, and Winlogon Shell persistence. Static analysis had to carry the investigation because the implant suppressed beaconing through a twelve-minute sandbox detonation, consistent with embedded anti-analysis provisions. Twelve minutes outlasts a meaningful share of automated detonation windows.

The operator’s repository hygiene is also worth noting: the RAT’s source stayed private for the whole campaign and went public only after it ended — renamed from kntrat-e to kntrat on 6 October 2026. Private-during, public-after is the pattern of an actor who understands that public code gets signatured.

AI tooling is now the watering hole

NEBULA lands the same week as the TensorLake SDK compromise, and the pairing matters: one campaign hijacked a real AI SDK, the other counterfeited one. Both bet that developers building with AI install fast and audit slowly — and both were right enough to ship. Combined with CloudSEK’s earlier Gentlemen/Azazel findings around MCP execution channels, the direction of travel is clear: the AI developer workstation, with its npm tokens, cloud credentials and agent configs, is the watering hole, and fake AI tooling is the bait that keeps working.

What to do

  • Block installs of api-nebula and llm-nebula and hunt manifests, lockfiles and build logs for all seven NebulaAI packages. Assume any host that ran the preinstall hook is fully compromised, not merely dirty.
  • Block egress to 65.87.7.132 and alert on the custom user-agent kntrat/0xB15B00B6, writes to a Conhost directory under %LOCALAPPDATA%, unexpected named-pipe constructions, and hidden-desktop artefacts.
  • Extend sandbox detonations past the twelve-minute mark for suspect installers where feasible, and treat a silent sample as suspicious rather than clean — this implant’s anti-analysis posture means absence of beaconing is the expected malicious behaviour.
  • Vet AI SDKs before install: check publisher history (four sequential burner accounts is the tell here), pin versions, and disable lifecycle scripts for unvetted packages. The facade file will always look fine — audit the hooks.

Verification note: the seven-package / four-account structure, the burner account names, the api-nebula / llm-nebula installable status, the MAL-2026-17531 categorisation date, the nebula.js facade and api.nebulaai.dev endpoint, the preinstall.cjs dropper with inline and network delivery paths, the Conhost masquerade path, the KNTRAT customisation, the 65.87.7.132 C2 address and kntrat/0xB15B00B6 user-agent, the syscall-only / empty-IAT design, the HVNC, Kernel Streaming and Winlogon Shell capabilities, the twelve-minute sandbox silence, and the 6 October kntrat-e to kntrat rename were all read directly from CloudSEK’s 8 October NEBULA report. We have not independently analysed any package or payload; secondary write-ups (Gridinsoft, The IT Nerd) corroborate the campaign shape but add no independently verified facts relied on here.

Sources: