Npm campaign installs RedC2 4.0 when importing malicious packages

Cybersecurity researchers have found a malicious package campaign in the npm ecosystem that, at first sight, provide calendar and calculation utilities but actually serve as a vehicle to install a remote control Linux implant called RedC2 4.0 (with its beacon Linux RedShell). The finding was publicly disseminated by Trend Micro's research team and confirms that the execution of malware occurs simply by importing the package into a chain of dependencies, even transitory.

Confirmed facts: Trend Micro reported that a dozen packages published in npm contain a packaged binary (with names such as math-chore.bin, calc.bin or calp-mapping.bin located in dist / or dist / internal /) that is marked as executable and released in the background when the module is loaded. The identified packages include, among others, streak-metrics-math @ 1.0.0, kit-map-vim @ 1.0.0, streak-map-cache @ 1.0.0 and a complete list informed by the research. The input file that acts as a troian charger is dist / index.mjs: it is enough for any module in the chain of dependencies to import that package for the implant to run, without the need for installation hooks or explicit calls to exported functions.

Technically, the mechanism described is simple and effective in JavaScript / Node environments: the module exposes legitimate functionalities (e.g. date or metric functions) but in its initialization it performs operations on the included binary - changes permissions (chmod), launches it with spawn as a disassociated process and ends its own execution. Thus the package continues to fulfil its functional promise and goes unnoticed in surface reviews, while establishing a outgoing connection to a command and control server (C2) to receive orders.

On the payload: the binary deployed is the Linux variant of the RedC2 framework in its 4.0 version, which incorporates the RedShell beacon. According to the technical description disseminated, the implant offers interactive remote control (/ bin / sh), data exfiltration (including SSH keys and browser credentials), ELF and shellcode memory execution, Socks5 proxy and pitting and tunneling features between hosts. RedC2 also includes components for Windows and macOS with similar capabilities; the Windows version adds account control evation (UAC bypass), techniques to interfere with antivirus and more advanced lateral movement.

One aspect of particular concern to researchers is the integration of a layer assisted by language models: Red Agent, a LLM component that transforms instructions into natural language into beacon command and command sequences. Trend Micro and researcher Aliakbar Zahravi have noted that this abstraction reduces the technical expertise needed to operate the C2, facilitating complex intrusions to less experienced operators.

Who does this affect? Confirmed: any project that depends directly or indirectly on the listed packages and that runs code in Linux environments - especially servers, containers and continuous integration pipelines that install units automatically - risks running the implant. The vector is dangerous because a simple "import" or "require" in an active transient dependence of the binary. Therefore, not only users who install the malicious packages by hand are at risk; repositories, base images and production environments that update or rebuild unfiltered dependencies can also be compromised.

Practical consequences: in compromised systems, operators can obtain interactive shells, steal credentials, deploy additional loads, move laterally and establish persistence. At the supply chain level, the vector allows malware to spread to legitimate projects that include these dependencies in your tree. In addition, the presence of an integrated AI assistant can accelerate scale operations and make it more difficult to detect human activity patterns against automated.

The confirmed vs. the estimated: it is confirmed that the packages run a RedShell binary and that RedC2 4.0 has been publicly promoted; the list of affected packages has also been documented. It is an estimate, although plausibly founded, that these publications represent an intentional malware distribution campaign using npm packages. Attribution to actors or links to previous criminal attacks is maintained as a suspicion in related reports on other supply chain campaigns, but no conclusive public evidence has been submitted to allow it to be definitively attributed.

Concrete and immediate measures to be taken by developers and managers:

1) Identify immediate exposure. In repositories and servers, look for the presence of the specific bookstores and the names of the binaries reported. Examples of useful searches: list dependencies with npm lsstreak-metrics-mathor scan node _ modules by patterns such as "math-chore.bin" or "dist / index.mjs" (e.g., grep -R "math-chore.bin" node _ modules /). Check the locks (package-lock.json / yarn.lock) for these versions.

2) Contain and eliminate. If you detect the presence of the suspicious packages or binaries, isolate the machine from the network, preserve images and logs for forensic analysis and remove the packages from the affected environments. Replace artifacts by reconstructing images from clean and verified sources in isolated environments.

3) Review and harden pipelines. Avoid automatic facilities without revision in productive environments. Configure lock / allow list policies in internal records, use integrity check (hashes), enable 2FA for publication accounts and restrict CI privileges for package publication. Implement scanning of units with tools such as Snyk, Dependabot or Sonatype and valide artifacts before promoting production.

4) Monitor and attempt detection. Block suspicious outgoing communications on firewalls (especially to C2 servers) and monitor unexpected child processes that run binary from dist / in node _ modules. Update EDR / AV rules to detect RedShell / RedC2 and implementation patterns of packaged binaries.

5) Broken credentials and privileges. After possible intrusion, consider the rotation of keys and credentials (APIs, SSH), and check users and accesses. Evaluate the need to rebuild committed systems rather than warm cleaning them.

Medium-term strategic recommendations: use private records and package signatures for critical environments; adopt reproducible approaches to build (version and SLSA or signature blocking) and apply confidence controls to package holders. The security community also needs to improve the detection of binaries packed in modules that are promised as purely JavaScript bookstores.

Additional context: this intrusion fits into a greater trend of attacks on the software supply chain (in different ecosystems such as npm and crates.io). In recent months, incidents have been documented where legitimate packages were committed to insert malicious code that runs during compilations or automatic installations. For general reference on risks and good supply chain practices, see industry projects such as OWASP Software Supply Chain (https: / / owasp.org / www-project-supply-chain-security /) and official npm documentation (https: / / www.npmjs.com /). The original technical analysis report was published by Trend Micro; its research page provides additional details and updates (https: / / www.trendmicro.com / en _ us / research.html).

In short, the threat shows that apparently safe packages can carry powerful implants and that automatic execution - even by transient imports - facilitates large-scale commitments. Effective response requires proactive detection in repositories and pipelines, blocking of unverified units and clear procedures to contain and recover affected systems.