# They Waited Six Years. Then They Struck Your Developer Machine.
Three Ruby gems sat quiet on RubyGems for years — some since 2017. Last week, they woke up.
Researchers from StepSecurity and Aikido Security have pulled apart a supply chain campaign they're calling SleeperGem, and the name earns its place. Two of the three malicious packages had been completely dormant — no updates, no activity — for between six and nine years before suddenly receiving new versions loaded with a multi-stage payload. The third impersonates Microsoft's own Git Credential Manager, down to the name. All three were designed with one specific target in mind: the developer sitting at a real machine, not the CI runner scanning packages in the cloud.
## The Packages, The Prey, The Plan
The three weapons in this campaign are:
Each functions as a loader — not the final payload. Upon installation, it reaches out to an attacker-controlled Forgejo instance (git.disroot[.]org/git-ecosystem) and pulls down a shell script called deploy.sh along with a native binary disguised under whatever name the gem was impersonating. On Windows machines, the retrieved payload executes through PowerShell.
Before doing anything else, the malware runs a quick environmental survey: it checks roughly 30 environment variables associated with GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins, and Vercel. If it finds any trace of a build pipeline, it exits cleanly. No payload. No noise. No evidence.
That's not a bug — it's the whole design. The attackers don't want ephemeral CI containers that get torn down every run. They want persistent access to the machines where developers live: their personal workstations, their home directories, their SSH keys and API tokens and browser sessions.
## From Loader to Root
Version 2.8.2 of git_credential_manager just staged the payloads. Version 2.8.3 went further.
The install script launches the binary as a background daemon, then plants persistence through two mechanisms simultaneously: a cron job and a systemd user service. After that, it checks whether the current user belongs to the sudo or wheel groups. If the user can run sudo without a password — and plenty of developer workstations are configured exactly that way — the script re-runs itself as root.
Running as root, it does one particularly nasty thing: it copies a setuid root shell to /usr/local/sbin/ping6. That path mimics a legitimate networking utility. The binary sitting there hands any user on the system a root shell on demand. A persistent backdoor, disguised as a network diagnostic tool, tucked in a directory most defenders never monitor.
Users of any of these packages are advised by StepSecurity to treat both the machine and any secrets that were ever on it as fully compromised — rotate credentials, check for the dropped daemon at ~/.local/share/gcm/, kill the systemd service, and inspect /usr/local/sbin/ping6 for a setuid binary that shouldn't be there.
## The Zombie Account Problem
The git_credential_manager typosquatting is straightforward to understand. But the dormant package angle is more insidious, and it's the part defenders are least equipped to handle.
Dendreo's last legitimate release was in 2020. fastlane-plugin-run_tests_firebase_testlab had been silent since early 2019. Accounts that go years without activity don't generate alerts. Nobody's watching them. Nobody's treating them as high-risk targets for credential compromise. As Aikido researcher Charlie Eriksen put it: "A RubyGems account that has gone quiet for six or seven years doesn't look risky to anyone. That's exactly the profile worth taking over."
The attacker's method of spreading the payload adds another layer. The malicious git_credential_manager package was added as a dependency to five other packages — including Dendreo and the fastlane plugin themselves. That dependency relationship means anyone already running those packages could receive the poisoned update through a routine bundle update. The infection path isn't install-from-scratch; it's the daily update cycle that every developer runs without a second thought.
There's also a forensic gap worth noting: none of the malicious releases had corresponding commits or tags in the source repositories. The packages were pushed directly to RubyGems registry without touching the code on GitHub or wherever the source lives. That discrepancy is detectable — source-registry divergence is something automated tools can flag — but only if you're actively looking for it.
## HackWire Analysis
SleeperGem isn't particularly novel in its mechanics. Second-stage loaders, CI evasion, cron persistence, setuid shell drops — this is well-traveled territory in supply chain tradecraft. What makes it worth studying is the combination of attack vectors: dormant account compromise layered over dependency injection, specifically tuned to bypass the security tooling that most organizations have actually deployed.
The industry spent considerable energy after the 2021 Log4Shell crisis hardening CI/CD pipelines. Software composition analysis is now table stakes at any serious development shop. The response was rational — but it created a predictable blind spot. When attackers see that CI environments are instrumented and hardened, they route around them and hit the developer endpoint instead. SleeperGem is an early data point in what looks like a deliberate shift: stop trying to poison the pipeline, poison the person who runs the pipeline.
The dormant account strategy compounds this. Most package registries, including RubyGems, lack meaningful controls over account reactivation. A maintainer who abandons a project in 2018 isn't required to enable MFA, transfer ownership to a trusted successor, or mark the package as unmaintained. The account just sits there — accessible to whoever eventually phishes or credential-stuffs their way in. The fix isn't complicated in theory: registries should require MFA reactivation and flag multi-year dormant accounts publishing new versions. PyPI has moved toward mandatory MFA for top package maintainers. RubyGems has lagged.
For defenders, the immediate question isn't whether your CI pipeline caught this — it almost certainly didn't run on CI. The question is whether any of your engineers installed these gems on a development machine in the last week. Given that git_credential_manager names itself after a Microsoft tool that many Ruby developers legitimately use, the install vector is credible. Audit your Gemfiles and Gemfile.lock files for any of the five affected packages, check for the persistence indicators StepSecurity documented, and treat any hit as a full workstation compromise requiring credential rotation across every service that machine could reach.
The setuid shell at /usr/local/sbin/ping6 is the tell. If that file exists and it's not the real ping6 binary, your attacker is already root.
— HackWire Editorial
## Related Coverage