- CloudSEK found seven npm packages posing as a NebulaAI SDK that install a Windows remote-access trojan through a hidden install script.
- The AI client in each package looks legitimate, so a review of the code people import would miss the dropper.
- CloudSEK says api-nebula and llm-nebula remain downloadable. Teams should block them, block 65.87.7.132 and check for the conhost.exe drop path.
When a developer wants to try a new AI service, the first step is usually a package install. The name sounds right, the code looks plausible, and the work goes on. The NEBULA campaign shows how little stands between that habit and a compromised machine.
CloudSEK, a threat-intelligence firm, reports that a single actor published a fake "NebulaAI" software development kit (SDK) to npm, the public registry for JavaScript packages. The lesson here is that in AI tooling, the name does the persuading and the install step does the damage. Both happen before anyone has reviewed a line of code.
What CloudSEK found
In late September 2026, the actor published seven packages across four sequential burner accounts, according to CloudSEK. The accounts are named nebulallms, nebulallms2, nebulallms3 and nebulallms4. CloudSEK tracks the activity as NEBULA.
Two of the packages, api-nebula and llm-nebula, can still be downloaded, the report says. For several days nothing flagged api-nebula as malicious. The registry logged it as MAL-2026-17531 on 5 October 2026, and CloudSEK says it can nonetheless still be installed.
The lure and the weapon are separate files
Each package has two faces. The entry point, nebula.js, is a believable client that points to api.nebulaai.dev. Anyone who reads it sees an ordinary AI client.
The danger sits in a second file, preinstall.cjs. It is an obfuscated script that runs during the npm install itself. It writes a program to %LOCALAPPDATA%\Microsoft\Conhost\conhost.exe, a name chosen to look like the genuine Windows console host.
CloudSEK describes two ways the payload arrives. It is either embedded in the package, encoded in base64 and zlib, or fetched over the network at install time.
That split matters for review. A code review of what the application imports would pass. The install hook is where the decision is made, and install hooks are easy to overlook in review.
Why the payload is hard to spot
The file that gets written is a modified version of KNTRAT, a remote-access tool whose code is openly published. CloudSEK says it is set to contact 65.87.7.132 with the user-agent kntrat/0xB15B00B6.
The researchers say it calls the Windows kernel directly, through NT and win32k syscalls. Normal programs list the system functions they need in an import table, and security tools read that list for clues. This one leaves the table empty.
Its features are broad. It offers hidden-desktop remote control, known as HVNC, which lets an operator work on a desktop the user cannot see. It can monitor the camera and microphone through Kernel Streaming. It persists by changing the Winlogon shell, so it starts at login.
The findings come from static analysis of the package. In a twelve-minute sandbox run, the implant sent no beacons, which CloudSEK says fits anti-analysis behaviour built into it. That means live behaviour was not observed in the report.
The pattern is in the sequence, not the entries
CloudSEK says individual registry feed entries describe each drop in isolation: the install script, the fake console executable, the payload. They miss the link. One actor moved through four accounts to distribute a single fake AI SDK.
One more detail stands out. CloudSEK reports that the RAT's source repository stayed private while the campaign ran. The author made it public afterwards, changing its name from kntrat-e to kntrat on 6 October 2026. That timing is consistent with planning, though CloudSEK does not say so.
This is one campaign, so it proves no wider trend. It does show the weak point it used. A listing that says "AI SDK" earns trust it has not earned.
What leaders should ask their teams
CloudSEK recommends specific steps. Block installs of api-nebula and llm-nebula. Restrict network traffic to 65.87.7.132. Build detection rules for the folder where conhost.exe is dropped, the custom user-agent string, named-pipe use and signs of a hidden desktop.
Beyond that, put these questions to your security and engineering leads:
Has anyone on our developer machines or build servers installed either package? Do lockfiles and install logs show it? Is a conhost.exe in a user profile folder flagged by our endpoint tools?
Who approves a new package that wraps an AI service? Can install scripts be switched off by default, and enabled only where a team has a reason? Do developer laptops hold cloud keys or code access that a remote operator could reach?
A package name costs an attacker nothing, and a four-account burner sequence adds little more. The control that matters is the decision to let a stranger's script run on a machine that holds your credentials.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: CloudSEK.
