A Supply-Chain Loader Aimed at Developer Machines
Security teams that pull RubyGems into internal tooling should study a campaign that researchers at Aikido Security named SleeperGem, with a full kill-chain breakdown published by StepSecurity on July 19. Between July 18 and July 19, attackers shipped malicious versions of three gems to RubyGems.org, and the packaging reveals the intent. Each release behaves as a loader, reaching out to an attacker-controlled Forgejo host to pull a second stage only after confirming it runs on a real developer workstation. We read this as a deliberate climb up the software supply chain toward the engineers who hold cloud keys, signing material, and production access. The design steps around the ephemeral build agents most defenders instrument first.
The three packages were git_credential_manager, which impersonates Microsoft's official Git Credential Manager, alongside Dendreo and a fastlane testing plugin. Two of them had gone quiet for years, with Dendreo last shipping in 2017 and the fastlane plugin in 2018, then suddenly publishing fresh versions within minutes of each other. That pattern matters for defenders. Dormant projects that wake up and push releases without a matching tag in their source repository give teams a concrete, high-signal detection opportunity. The malicious git_credential_manager alone cycled through versions 2.8.0 through 2.8.3 across two days, a churn rate that reads as attackers iterating on their loader in production.
How the Loader Evades Automated Pipelines
The evasion logic is what elevates this campaign above routine typosquatting. Before doing anything hostile, the loader scans roughly thirty environment variables tied to continuous integration platforms, checking for markers such as GITHUB_ACTIONS, GITLAB_CI, CIRCLECI, Travis, Jenkins, and Vercel. When it finds any of them, it exits quietly and leaves no trace. That single check inverts a common assumption. Many organizations concentrate their supply-chain monitoring inside CI, precisely the environment SleeperGem refuses to detonate in. The payload wants a human at a keyboard with a populated credential store, a configured cloud CLI, and live browser sessions, all of which turn one compromised laptop into a doorway to the wider estate.
When the loader decides it has found a developer, it fetches deploy.sh and a native binary that mimics the Git Credential Manager from a public Forgejo instance at git.disroot.org. The download requests carry a User-Agent of Git to blend with normal traffic, and certificate verification is disabled so a swapped host or self-signed endpoint raises no errors. StepSecurity reconstructed the full sequence by executing the malicious versions inside its Harden-Runner sandbox, watching Ruby spawn the install script, pull the payload, and stage the binary in a hidden home directory. Seeing the process tree unfold in order gave analysts the confidence that a static review of the gem source would have missed.
Persistence, Privilege Escalation, and Blast Radius
Once resident, the binary settles into the user's local share directory under gcm as git-credential-manager, reads a hidden environment file, and launches as a background daemon. It then bolts itself down with two independent persistence methods, a systemd user service also named git-credential-manager and a cron entry that relaunches the dropped daemon. Redundant persistence signals an operator who expects to be noticed and wants to survive a single cleanup pass. For blue teams, the naming choice is a gift and a trap at once. The daemon borrows a legitimate-sounding identity, so grepping process lists for git-credential-manager surfaces both the real tool and the imposter, and analysts have to confirm paths carefully.
The campaign also probes for privilege escalation. When the loader runs with sudo or root, it drops a setuid root shell at /usr/local/sbin/ping6 with permissions 6777, giving any local user an instant path to root on that host. That detail should reframe how teams triage an infected laptop. A developer who ran a gem install under sudo, a habit that remains far too common, hands the attacker durable root and a clean escalation primitive for later. We treat any machine that required or installed these gems as fully compromised, along with every secret reachable from it, and we would rotate credentials before restoring the box to service.
Detection Signals Static Scanners Miss
SleeperGem is a clean case study in the limits of source-level scanning. A static read of the gem contents flags suspicious code, yet the real intent becomes obvious only when the process tree runs and each stage fires in sequence. That gap explains why signature and heuristic scanners keep losing ground to loaders that pull their teeth from a remote host at runtime. Defenders who rely solely on scanning a package's published files will keep seeing yellow warnings they cannot fully resolve. Behavioral execution in a disposable sandbox, watching for outbound fetches, setuid drops, and systemd registration, gives a far more decisive verdict on whether a release is malicious.
The highest-value detection here needs no sandbox at all. Provenance mismatches, a published gem version with no corresponding tag or commit in the upstream repository, cleanly separated the SleeperGem releases from legitimate ones. Teams that enforce source-to-artifact provenance, through signed builds and repository attestations, would have caught these packages before installation. Long-dormant dependencies that suddenly publish are a second free signal worth alerting on. We would wire both checks into the dependency review gate, block installs that fail provenance, and treat any wake-from-hibernation release as guilty until an engineer verifies it against the project's own commit history and maintainer activity.
What Security and Engineering Leaders Should Do Now
This incident lands squarely on the developer endpoint, a surface many security programs still undergovern. We would start by hunting for the specific artifacts: the daemon under the local gcm directory, the git-credential-manager systemd user service, the cron persistence, and the setuid shell at /usr/local/sbin/ping6. Any hit means credential rotation and a rebuild, because harvested cloud keys and tokens outlive the malware. Beyond cleanup, the lesson for CTOs is that developer laptops deserve the same EDR coverage, egress monitoring, and least-privilege posture as production servers. An engineer's machine with standing access to cloud consoles and signing keys is a production asset by any honest definition.
For vendor and dependency risk, SleeperGem argues for tightening the gate between a package appearing in a registry and it entering your build. We favor pinning gem versions with hashes, requiring provenance attestations, and disallowing sudo during dependency installation as a default policy. Registries move faster than review teams, so a short quarantine window on brand-new versions of critical dependencies buys time for the community to spot poisoned releases. The attackers here bet that a familiar name and a plausible version bump would sail through unattended installs. Closing that window, and instrumenting the developer endpoint, removes the easy path this campaign depended on.
