Seven malicious packages posing as AI developer tools have been used to distribute a Windows remote-access trojan (RAT), exposing the risks of software supply-chain attacks targeting developers, according to cybersecurity researchers at CloudSEK.
The packages, published through four accounts on the npm software registry, masquerade as a software development kit for a service called NebulaAI. Two packages, api-nebula and llm-nebula, remained downloadable on 8th October despite being identified as malicious, CloudSEK said.
The campaign, which the researchers named NEBULA, was traced to a single operator distributing packages through a sequence of disposable accounts in late September. The packages combine plausible AI client code with an obfuscated installation script that secretly deploys a modified version of KNTRAT, a Windows remote-access trojan.
“The package serves as the lure; the execution rests within the installation hook,” CloudSEK said in its report.
The malware can enable attackers to control a victim’s desktop remotely, execute commands and access camera and microphone functions. It can also establish persistence through Windows logon settings, allowing it to run again when a user signs in.
The findings highlight how attackers can exploit demand for AI development tools to introduce malicious code into trusted software workflows, potentially exposing developer workstations and corporate networks.
CloudSEK’s analysis found that the packages’ main JavaScript entry point, nebula.js, presents itself as a client for an AI service hosted at api.nebulaai.dev. The actual threat resides in preinstall.cjs, an obfuscated script automatically triggered during installation.
The script writes an executable to %LOCALAPPDATA%\Microsoft\Conhost\conhost.exe, using a filename that mimics the legitimate Windows Console Host. The payload can be delivered either as an embedded, encoded file or through a network request made during installation.
The deployed malware is a customised version of KNTRAT, configured to communicate with the IP address 65.87.7.132, according to CloudSEK.
The researchers identified techniques intended to make the malware harder to detect using conventional security tools. Rather than relying on standard Windows dynamic-link library (DLL) imports, the implant uses direct NT and win32k system calls, leaving its Import Address Table (IAT) empty. This can undermine detection mechanisms that look for suspicious imported functions, although it does not make the malware inherently undetectable.
“The underlying RAT operates exclusively through direct NT and win32k syscalls, bypassing standard DLL imports and leaving an empty Import Address Table (IAT),” the report said.
The malware’s capabilities include hidden virtual network computing (HVNC), which can provide remote desktop access through a concealed session, and the use of Windows Kernel Streaming functionality to access camera and microphone feeds. It also uses Winlogon Shell persistence to maintain access across user logons.
CloudSEK said the KNTRAT source repository remained private during the campaign and became public on 6th October, after being renamed from kntrat-e to kntrat. The researchers used the subsequently published source code alongside analysis of the recovered binary to assess the implant’s capabilities.
The campaign involved four sequential publisher accounts: nebulallms, nebulallms2, nebulallms3 and nebulallms4. CloudSEK linked seven packages to the same operator through common code and installation behaviour.
The api-nebula package was active for several days before being formally categorised under malware advisory MAL-2026-17531 on 5th October. It nevertheless remained installable when the report was published, alongside llm-nebula.
CloudSEK scanned 162,464 available npm package archives using YARA detection rules between 25th and 27th September. The scan identified the known packages associated with the campaign and produced no false positives within the dataset examined.
The investigation did not confirm a successful victim compromise. During more than 12 minutes of controlled sandbox testing, the recovered implant did not attempt to contact its command-and-control infrastructure.
“The implant suppressed beaconing during a twelve-minute sandbox detonation, consistent with embedded anti-analysis provisions,” the report said.
CloudSEK said its assessment of the malware’s capabilities was based on analysis of the recovered binary and the subsequently published KNTRAT source code. The lack of observed network activity during testing therefore does not establish that the malware was harmless or that it had not affected users.
The researchers urged security teams to block the remaining malicious packages, restrict communications with the identified IP address and monitor for the disguised executable’s installation path and other indicators of compromise.
“Security teams should immediately restrict the active packages and block infrastructure associated with the campaign,” CloudSEK said.
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by commenting below or visiting our LinkedIn page.
