Executive Summary
The supplied CyberRakshak Labs post describes 14 malicious npm packages masquerading as legitimate calendar, streak and utility libraries. According to the post, the packages contain a hidden payload designed to deploy RedShell, the Linux beacon associated with RedC2 4.0.
The key security lesson is that the malicious behavior does not depend on a conventional npm install hook. The post says the loader is embedded in the package entry file and can execute when the module is imported.
Identified Packages
- streak-metrics-math@1.0.0, 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-metricazbd@1.0.0
- streak-metricsazb@1.0.0
- streak-kit-map@1.0.0
What Makes This Attack Different?
The post contrasts this campaign with the common pattern of a malicious npm install script. Here, the malicious loader is described as being embedded in the package's entry file.
The supplied post says that even a transitive dependency can trigger the payload when imported, without an install hook or explicit exported-function call.
What Does RedShell Do?
According to the post, the Linux beacon can provide attackers with capabilities including:
- Interactive shell access
- System discovery
- File operations and data collection
- SSH key theft
- Browser credential theft
- Command execution and persistence
- In-memory ELF execution
- SOCKS5 proxying and network pivoting
- Command-and-control communication
The post describes the malware as checking in with attacker C2 infrastructure, receiving commands and returning results, potentially turning a compromised developer system or server into a remotely controlled asset.
The AI Angle
The supplied post says the RedC2 framework reportedly includes an LLM-powered component called Red Agent. According to the post, operators can provide natural-language instructions that are translated into framework commands.
Why Developers & DevOps Teams Should Care
Modern applications can contain hundreds or thousands of dependencies. A project can depend on Package A, which depends on Package B, which depends on Package C, which eventually brings in a malicious package.
The post summarizes the broader attack surface as:
What Organizations Should Do
1. Audit dependencies
Review package.json, package-lock.json, npm-shrinkwrap.json, SBOMs and CI/CD dependency trees.
2. Search for the identified packages
Look across developer endpoints, CI/CD systems, build servers and production systems.
3. Don't rely only on install-script monitoring
Because the described campaign can execute during module import, monitoring only npm lifecycle scripts may not be sufficient.
4. Review recently executed Node.js processes
Investigate unexpected child processes, shell execution, binary execution from node_modules, network connections from build environments and unexpected persistence mechanisms.
5. Protect developer secrets
If compromise is suspected, investigate exposure of SSH keys, cloud credentials, npm tokens, Git credentials, API keys, browser credentials and environment variables.
6. Rebuild from trusted sources
If compromise is confirmed, the post recommends: Remove malicious packages → Rotate credentials → Rebuild → Validate → Monitor.
Threat Intelligence Snapshot
- Malware: RedShell Linux Beacon
- Framework: RedC2 4.0
- Delivery: Trojanized npm packages
- Execution: Import-time execution
- Target: Linux developer/server environments
- Capabilities: Shell, credential theft, file access, persistence, C2 and network pivoting
- Packages: 14 identified packages
CyberRakshak Labs Insight
The most important lesson isn't “Don't use npm.”
It is: Don't blindly trust your dependencies.
Software supply-chain security starts before the code reaches production. Know your dependencies. Verify your packages. Monitor your build pipeline. Protect your developers.