Listen to this Post
Introduction: A Silent Threat Hidden Inside Trusted Software
Software supply chain attacks have become one of the most dangerous cybersecurity challenges facing developers, enterprises, and open-source communities. Instead of attacking organizations directly, cybercriminals now compromise the software packages developers trust every day. Once a malicious package is installed, attackers gain access to thousands of downstream systems without exploiting a single vulnerability.
Security researchers have now uncovered another alarming campaign, codenamed SleeperGem, that specifically targets the Ruby ecosystem. Unlike ordinary malware campaigns, SleeperGem relies on dormant software packages, stolen maintainer accounts, and carefully crafted persistence mechanisms to quietly infect developer workstations while deliberately avoiding automated security systems. The discovery highlights how attackers continue to evolve their tactics, making software repositories one of today’s most attractive attack surfaces.
SleeperGem Targets RubyGems Through Malicious Package Updates
Cybersecurity researchers from StepSecurity have identified a sophisticated software supply chain attack involving three malicious RubyGems packages that were designed to download additional malware after installation.
The affected packages include:
git_credential_manager (versions 2.8.0 through 2.8.3)
Dendreo (versions 1.1.3 and 1.1.4)
fastlane-plugin-run_tests_firebase_testlab (version 0.3.2)
Each malicious release functions as an initial loader rather than carrying the complete malware itself. Once executed, it retrieves additional payloads from an attacker-controlled Forgejo server, verifies whether it is executing inside a Continuous Integration (CI) environment, and only proceeds when it detects an actual developer workstation.
This selective execution dramatically reduces the likelihood of discovery by automated security scanners.
Dormant Packages Became Perfect Targets
One of the most fascinating aspects of SleeperGem is how attackers weaponized abandoned software.
Two of the compromised packages had remained inactive for years before suddenly receiving malicious updates.
Dendreo had not been updated since 2020.
fastlane-plugin-run_tests_firebase_testlab had been dormant since 2019.
Dormant projects often receive less scrutiny because developers assume inactive repositories are stable and trustworthy. Attackers appear to have recognized this blind spot and exploited forgotten maintainer accounts rather than creating obviously malicious new projects.
This strategy gave the malicious updates an appearance of legitimacy.
Fake Microsoft Package Increased Trust
Perhaps the most deceptive package was git_credential_manager, which intentionally impersonated Microsoft’s legitimate Git Credential Manager.
By choosing a highly recognizable name, attackers significantly increased the probability that developers would install the package without verifying its origin.
Typosquatting and brand impersonation remain among the most effective software supply chain attack techniques because they exploit human trust rather than technical weaknesses.
No Matching Source Code Raised Immediate Red Flags
Researchers also noticed another unusual characteristic.
The malicious package releases appeared directly inside RubyGems without corresponding Git commits or repository tags.
Normally, package releases are tied to publicly visible source code updates. The absence of matching commits strongly suggests unauthorized publication or compromised maintainer credentials.
This disconnect between source repositories and published packages became one of the strongest indicators of malicious activity.
Dependency Chain Helped Spread the Malware
The attackers also abused package dependencies to increase infections.
The malicious git_credential_manager gem was quietly added as a dependency inside several other packages:
Dendreo
fastlane-plugin-run_tests_firebase_testlab
slackHtmlToMarkdown
seo_optimizer
array_fast_methods
As developers updated seemingly unrelated projects, the malicious dependency was automatically installed behind the scenes.
This illustrates how a single compromised package can quickly cascade across an entire software ecosystem.
Multiple Maintainer Accounts May Have Been Compromised
Researchers believe the campaign likely involved more than one compromised RubyGems account.
Most affected packages belonged to the LR-DEV maintainer account, while git_credential_manager originated from another maintainer named pinkroom.
The presence of multiple compromised publishers suggests attackers either stole several accounts or coordinated multiple unauthorized uploads.
Either scenario significantly increases the scale and sophistication of the operation.
Malware Specifically Avoided Security Researchers
Once installed, the malware immediately inspected approximately thirty environment variables.
These variables identified popular development and CI platforms including:
GitHub Actions
GitLab
CircleCI
Travis CI
Jenkins
Vercel
If any automated build environment was detected, execution immediately stopped.
This demonstrates a high level of operational security from the attackers, who intentionally avoided sandboxes, automated analysis systems, and temporary CI runners to remain undetected for as long as possible.
Developer Workstations Became the Primary Target
If no CI environment was detected, the malware downloaded two additional payloads from a public Forgejo instance.
These included:
A shell deployment script
A native executable disguised as Git Credential Manager
Windows systems executed the payload using PowerShell, while Linux systems relied on shell scripts for deployment.
This cross-platform approach dramatically increased the
Persistence Mechanisms Were Highly Sophisticated
Version 2.8.3 of the malicious package significantly escalated the attack.
Instead of merely downloading malware, it installed a persistent background daemon that survived system reboots.
Persistence techniques included:
Cron jobs
systemd user services
Background daemon installation
Privilege discovery
Enumeration of sudo and wheel groups
The malware actively searched for privilege escalation opportunities.
If passwordless sudo was available, it automatically re-executed itself with root privileges.
Root-Level Backdoors Made System Recovery Difficult
Once elevated to root access, the malware planted a setuid copy of the system shell disguised as a legitimate networking utility.
This effectively created a hidden administrative backdoor capable of surviving ordinary cleanup attempts.
Attackers could later regain privileged access even if portions of the malware were removed.
This persistence mechanism transforms an ordinary developer workstation compromise into a long-term system takeover.
Organizations Should Treat Affected Systems as Fully Compromised
Researchers strongly recommend treating any system that installed these packages as compromised.
Recommended remediation steps include:
Removing the daemon from ~/.local/share/gcm/
Deleting cron persistence
Removing malicious systemd services
Checking /usr/local/sbin/ping6 for unauthorized setuid binaries
Rotating every credential stored on the affected machine
Regenerating SSH keys
Rotating cloud credentials
Reviewing GitHub tokens
Resetting CI secrets
Simply uninstalling the malicious gem is not enough.
SleeperGem Highlights a Growing Trend
Security researcher Charlie Eriksen explained that dormant RubyGems accounts represent ideal takeover targets.
Inactive projects rarely receive active monitoring, making them attractive assets for attackers looking to distribute malware under trusted identities.
The name SleeperGem reflects this concept.
The packages themselves were not created maliciously years ago. Instead, legitimate projects quietly became dangerous after being abandoned and later compromised.
RubyGems Has Recently Faced Multiple Supply Chain Incidents
SleeperGem is not an isolated event.
Only months earlier, RubyGems temporarily suspended new account registrations after a coordinated spam campaign flooded the registry with malicious packages.
Researchers also identified approximately 150 Ruby packages abusing RubyGems as a covert data exfiltration platform.
These incidents demonstrate that attackers increasingly view package repositories as infrastructure rather than simply software distribution platforms.
RubyGems Was Also Used as a Secret Data Storage Platform
A separate investigation by Mend.io uncovered another alarming campaign involving fourteen Ruby packages.
Instead of delivering malware, attackers used RubyGems as a hidden storage location for stolen credentials.
A malicious browser extension collected sensitive information directly from victims’ local password managers through accessible APIs.
The stolen information was packaged into legitimate-looking .gem files using JavaScript and uploaded directly to RubyGems using a hard-coded API key.
Researchers discovered stolen data including:
Plaintext passwords
SSH private keys
AWS credentials
Cryptocurrency wallet seed phrases
Social Security numbers
Credit card information
Banking details
Rather than functioning as malware delivery infrastructure, RubyGems became an invisible “dead drop” where attackers quietly stored stolen information until retrieving it later.
What Undercode Say:
The SleeperGem campaign demonstrates that software supply chain security is no longer just about identifying malicious code. It is increasingly about verifying trust relationships across an entire development ecosystem.
Dormant projects are becoming high-value assets for attackers.
Inactive maintainer accounts often lack multi-factor authentication, active monitoring, and security reviews.
Dependency chains amplify risk exponentially.
One compromised package may silently reach thousands of downstream applications.
CI evasion indicates professional adversaries.
Attackers understand exactly how modern security pipelines work.
Developer endpoints have become primary targets.
Compromising one engineer frequently leads to cloud infrastructure compromise.
Organizations should continuously audit package ownership.
Package provenance should become mandatory.
SBOM generation should be integrated into every build pipeline.
Dependency updates require behavioral analysis, not only version comparison.
Unsigned package releases deserve additional scrutiny.
Release transparency must improve.
Maintainers should publish signed tags.
Cryptographic verification should become standard.
Long-abandoned repositories require periodic security reviews.
Repository inactivity should increase organizational risk scores.
Secrets should never remain permanently valid.
Short-lived credentials dramatically reduce attacker opportunities.
Least privilege remains essential.
Developer workstations deserve endpoint detection comparable to production servers.
Organizations should monitor outbound package downloads.
Unexpected Forgejo communications should trigger alerts.
Behavioral monitoring often detects attacks before signatures.
Open-source ecosystems remain attractive because trust scales faster than verification.
Software provenance initiatives will become increasingly important.
Supply chain attacks will continue growing.
Automation must include security validation.
Machine learning can help identify anomalous releases.
Maintainer account protection should require phishing-resistant MFA.
Repository takeover detection requires community participation.
Developers should verify package publishers before installation.
Organizations should maintain internal mirrors for approved dependencies.
Continuous package auditing should become routine.
Supply chain resilience depends on visibility.
Trust should always be verified.
Ignoring dormant projects creates unnecessary exposure.
SleeperGem is unlikely to be the last campaign of its kind.
Deep Analysis
Security teams investigating similar attacks can leverage the following Linux commands during incident response:
gem list
gem environment
gem sources
find ~/.local/share/gcm -type f
systemctl --user list-units
systemctl --user list-unit-files
crontab -l
sudo find / -perm -4000 -type f
ls -la /usr/local/sbin/
stat /usr/local/sbin/ping6
ps aux | grep gcm
netstat -tulpn
ss -tulpn
journalctl --user
grep -R "git.disroot" /
find / -name ".gem"
rpm -qa
dpkg -l
sha256sum suspicious_file
lsof -i
history
env
printenv
These commands help investigators locate persistence mechanisms, identify unauthorized privileged binaries, inspect running services, verify installed Ruby packages, examine network activity, and uncover indicators of compromise that may remain after the malicious gem has been removed.
✅ StepSecurity publicly disclosed the SleeperGem software supply chain attack involving malicious RubyGems packages that acted as malware loaders.
✅ The malicious packages were designed to evade CI environments, establish persistence on developer machines, and potentially escalate privileges, matching the technical behaviors described by researchers.
❌ There is currently no public evidence that every RubyGems package or the Ruby ecosystem as a whole has been compromised. The attack affects specific malicious packages and compromised maintainer accounts, not the entire RubyGems registry.
Prediction
(+1) Positive Prediction
Software repositories such as RubyGems will likely introduce stronger publisher verification, mandatory multi-factor authentication, and improved package provenance controls.
Security vendors are expected to expand behavioral detection capabilities that identify suspicious package updates before developers install them.
Organizations will increasingly adopt Software Bill of Materials (SBOM) generation, cryptographic package signing, and continuous dependency monitoring to reduce future software supply chain risks while strengthening trust across open-source ecosystems.
▶️ Related Video (74% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: thehackernews.com
Extra Source Hub (Possible Sources for article):
https://www.stackexchange.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
