14 Trojanized npm Packages Deploy RedC2 4.0 Linux Backdoor

Security researchers have uncovered a new npm supply-chain attack involving 14 trojanized packages that appear to provide legitimate calendar, streak-tracking and utility functionality but secretly deliver RedC2 4.0, a Linux backdoor.

The campaign is notable because the malicious payload executes when the package is imported, meaning an application does not necessarily need to directly install or explicitly execute a malicious installation script. A transitive dependency can be sufficient to trigger the payload.

Key Highlights

• 14 malicious npm packages identified.
• Malware family: RedC2 4.0
• Primary target: Linux systems.
• Packages masquerade as calendar and streak utilities.
• Payload executes during module import.
• No npm install hook is required.
• A transitive dependency can trigger execution.
• Bundled Linux binary is launched as a detached background process.
• RedC2 provides shell access and payload execution.
• Malware supports credential theft and surveillance functionality.
• RedC2 4.0 is marketed as a cross-platform C2 toolkit.
• The toolkit was reportedly promoted by a threat actor known as MarlboroMan.
• Campaign activity demonstrates the risk of malicious open-source dependencies.

Trojanized npm Packages

The packages were designed to appear legitimate by using names associated with calendar, streak and mapping utilities.

Identified packages include:

streak-metrics-math@1.0.0
streak-metrics-math@1.0.1
kit-map-vim@1.0.0
streak-map-cache@1.0.0
streak-map-kit@1.0.0
map-streak-kit@1.0.0
streak-cache-map@1.0.0
streak-calc-metrics@1.0.0
streak-calc-math@1.0.0
streak-math-abz@1.0.0
streak-metricsaz@1.0.0
streak-math-metrics@1.0.0
streak-metrica...

The packages were crafted to blend into legitimate npm dependency ecosystems rather than appearing as obviously malicious software.

Import-Time Execution

One of the most important characteristics of the campaign is its execution mechanism.

When the malicious module is loaded, it:

1. Locates the bundled binary.
2. Changes its permissions to make it executable.
3. Launches the binary as a detached background process.
4. Continues normal module functionality.

This means the malicious code can execute simply because an application imports the affected dependency.

No traditional npm installation lifecycle hook is required.

Transitive Dependency Risk

The attack is particularly concerning for organizations that rely heavily on dependency chains.

An application may directly depend on a trusted package while indirectly importing one of the malicious packages.

The resulting execution path can therefore be:

Application → Trusted Dependency → Transitive Dependency → Trojanized npm Package → RedC2

Developers may never knowingly install the malicious package themselves.

RedC2 4.0

The payload is identified as RedC2 4.0, a Linux backdoor and command-and-control toolkit.

The toolkit is reportedly marketed as a cross-platform framework capable of operating against:

• Windows
• macOS
• Linux

Its advertised capabilities include:

• Remote shell access
• Credential theft
• Payload delivery
• Surveillance
• Remote command execution
• C2 communication
• Large-scale operations

The version was reportedly promoted on underground forums by a threat actor using the alias MarlboroMan.

AI-Assisted C2

A notable characteristic of RedC2 4.0 is its AI-assisted command-and-control functionality.

This illustrates an emerging trend where malware operators integrate AI capabilities into existing offensive infrastructure.

AI-assisted functionality can potentially help operators:

• Generate commands
• Automate operational workflows
• Interpret system information
• Modify attack behavior
• Scale campaigns

The presence of AI functionality does not necessarily make the malware autonomous, but it can reduce the amount of manual interaction required by an operator.

Linux Targeting

The identified packages specifically deliver a Linux implant.

This is particularly relevant for:

• CI/CD servers
• Development environments
• Cloud workloads
• Build servers
• Container hosts
• Linux-based application servers

Developer environments are especially attractive because they commonly contain:

• npm credentials
• GitHub tokens
• SSH keys
• Cloud credentials
• Environment variables
• API keys
• Deployment secrets

A compromised developer system can therefore become a stepping stone into the broader software supply chain.

Supply-Chain Attack

This campaign demonstrates why dependency security cannot focus solely on vulnerabilities.

A package can contain no known CVE and still be malicious.

The threat model includes:

• Maintainer compromise
• Malicious package publication
• Typosquatting
• Dependency confusion
• Malicious transitive dependencies
• Package takeover
• Build-pipeline compromise

The affected packages demonstrate how attackers can abuse developer trust in public package repositories.

Detection and Hunting Opportunities

Security teams should monitor for:

• Installation of the affected npm packages.
• Imports of suspicious npm dependencies.
• Node.js processes spawning unexpected binaries.
• Node.js processes launching detached background processes.
• Unexpected chmod activity from Node.js.
• Linux executable files appearing inside npm package directories.
• Network connections initiated immediately after package import.
• Unexpected outbound C2 connections from development systems.
• npm package changes between builds.
• Newly introduced transitive dependencies.
• Access to .npmrc files.
• Access to Git credentials.
• SSH-key access from Node.js processes.
• Environment-variable collection.
• Unexpected shell commands originating from Node.js.

Recommended Hunting Logic

A high-confidence behavioral detection could correlate:

Node.js Process
        +
Execution of Newly Extracted Binary
        +
chmod / Executable Permission Change
        +
Detached Background Process
        +
Outbound Network Connection

Additional priority should be given when the execution occurs inside:

node_modules/

or a CI/CD workspace.

Recommended Mitigations

1. Identify whether any affected npm packages exist in development or production environments.
2. Remove affected package versions immediately.
3. Rebuild applications from known-clean dependency sources.
4. Review lockfiles for unexpected transitive dependencies.
5. Pin dependencies to verified versions.
6. Use private npm registries where appropriate.
7. Scan packages before allowing them into production builds.
8. Monitor npm package integrity between builds.
9. Restrict outbound network access from CI/CD environments.
10. Protect npm publishing credentials with MFA.
11. Rotate credentials exposed on compromised developer systems.
12. Audit GitHub, npm, cloud and SSH credentials after suspected compromise.
13. Monitor Node.js processes for unexpected child-process execution.
14. Maintain SBOMs for applications and container images.
15. Perform retrospective hunting across developer and CI/CD systems.

Threat Assessment

This campaign represents a Critical software supply-chain threat because malicious code can execute simply when a compromised dependency is imported.

The absence of an npm installation hook makes the attack particularly important: traditional monitoring focused exclusively on package installation events may miss the execution.

The targeting of Linux development and cloud environments further increases the potential impact because these systems often contain valuable credentials and deployment secrets.

Conclusion

The RedC2 npm campaign demonstrates that organizations must treat open-source dependencies as executable supply-chain components, not merely libraries.

Security teams should combine dependency scanning with runtime monitoring, transitive-dependency analysis, package integrity validation and credential protection.

Particular attention should be given to Node.js processes that unexpectedly launch Linux binaries or establish outbound connections immediately after importing an npm dependency.