Someone Used npm as Their Personal Attack Lab
Sixteen malicious npm packages hit the registry on April 3, 2026, all disguised as Strapi CMS plugins. But this wasn't your typical supply chain attack. Each package carried different payloads, eight distinct variants in total, like snapshots of an attacker refining their techniques in real-time.
The packages came from two throwaway accounts: umarbek1233 and kekylf12, both using @sharebot.net disposable emails. What makes this campaign unusual is the variety. Most malicious package campaigns deploy identical payloads across multiple fake packages to maximize infection chances. This one tells a different story.
Eight Payloads, One Development Session
The malicious packages weren't carbon copies. Security researchers identified eight distinct payload variants across the sixteen packages, suggesting the attacker was actively developing and testing their tools. Some focused on Redis remote code execution, others prioritized database theft, and several established persistent command-and-control channels.
This pattern indicates targeted development rather than opportunistic malware distribution. The attacker likely had a specific environment or victim in mind and was iterating their approach based on reconnaissance or failed attempts.
Package naming patterns followed Strapi conventions:
- strapi-plugin-[function-name]
- @strapi/plugin-[feature]
- strapi-[component]-plugin
The naming scheme suggests familiarity with the Strapi ecosystem. The attacker understood how developers search for and install Strapi plugins, crafting believable package names that would pass casual inspection.
Redis RCE Takes Center Stage
Several payload variants specifically targeted Redis instances, exploiting common misconfigurations to achieve remote code execution. Redis often runs with elevated privileges and minimal access controls in development environments, making it an attractive target for lateral movement.
The Redis-focused payloads attempted to:
- Execute system commands through Redis modules
- Extract database credentials and connection strings
- Establish reverse shells using Redis pub/sub channels
- Modify Redis configurations to enable persistence
This focus on Redis suggests the attacker had prior knowledge of their target's infrastructure stack. Blind attacks typically cast wider nets rather than betting everything on a specific technology.
Database Theft and Exfiltration Methods
Other payload variants concentrated on database access and data exfiltration. These packages scanned for common database configuration files, environment variables, and connection strings across multiple database systems including PostgreSQL, MySQL, and MongoDB.
The exfiltration methods varied between packages:
- Direct HTTP POST to attacker-controlled servers
- Base64-encoded data hidden in DNS queries
- Encrypted data pushed to public Git repositories
- Data chunked and sent through legitimate APIs
This variety suggests the attacker was testing different exfiltration channels to find what worked in their target environment. Network monitoring and data loss prevention tools often catch obvious exfiltration attempts, so having multiple methods increases success chances.
Command and Control Infrastructure
The persistent C2 capabilities revealed sophisticated planning. Rather than simple one-shot data theft, these packages established long-term access through multiple mechanisms:
Scheduled task persistence:
- Modified crontab entries on Linux systems
- Created Windows scheduled tasks
- Added systemd service files
Network persistence:
- Reverse SSH tunnels to attacker infrastructure
- WebSocket connections masquerading as legitimate traffic
- DNS tunneling for command transmission
The C2 infrastructure used a mix of compromised WordPress sites and bulletproof hosting providers, making takedowns more difficult. Command encoding used custom Base32 variants rather than standard encoding schemes, complicating detection.
Real-Time Attack Development
The timeline tells the real story. All sixteen packages were published within a four-hour window on April 3, 2026, with slight variations in functionality between uploads. This compressed timeline suggests active development and testing rather than a pre-planned campaign.
Security telemetry shows the attacker was responding to failed exploitation attempts by modifying payloads and re-uploading. Early packages focused on broad reconnaissance, while later versions targeted specific services and configurations discovered during initial access attempts.
This approach is risky but effective against specific targets. Instead of developing attacks in isolation, the attacker used npm as a live testing ground, refining their tools based on real-world feedback from their target environment.
Strapi Plugin Ecosystem Vulnerabilities
The choice of Strapi plugins as a delivery mechanism highlights weaknesses in headless CMS ecosystems. Strapi's rapid growth has outpaced security tooling, and developers often install plugins without thorough vetting.
Strapi installations typically run with database access and file system permissions, making them valuable targets for attackers. Plugin installation often requires npm packages with broad system access, creating perfect conditions for malicious code execution.
The fake plugins included convincing documentation and changelogs, suggesting significant preparation time. The attacker understood that well-documented packages receive less scrutiny during installation.
Detection Challenges
Traditional security tools struggled with this campaign because each package was technically unique. Signature-based detection failed due to payload variation, and behavioral analysis was complicated by the legitimate-looking Strapi integration code.
The packages used several evasion techniques:
- Delayed payload execution to avoid sandbox detection
- Environment checks to prevent analysis in virtual machines
- Legitimate functionality mixed with malicious code
- Dynamic payload downloading after installation
These techniques suggest the attacker had experience with security tool evasion and understood common analysis environments.
Supply Chain Attack Evolution
This campaign represents an evolution in supply chain attacks. Rather than hoping for widespread adoption of malicious packages, the attacker created a targeted delivery system for a specific victim. The variety in payloads suggests they were prepared for different defensive scenarios.
The use of npm as a development platform is particularly concerning. Package registries aren't designed to handle active attack development, and current security measures assume static malicious content rather than iterative payload refinement.
Red Sheep Assessment: This campaign signals a shift toward precision supply chain attacks where attackers use package registries as live testing platforms against specific targets. The real-time development approach suggests either exceptional confidence in target identification or desperation to breach a hardened environment. Organizations using Strapi should audit their plugin installations immediately and implement registry monitoring for packages matching their technology stack. Confidence level: High that this technique will be adopted by other threat actors targeting headless CMS environments.