SleeperGem targeted developer machines by publishing malicious versions of git_credential_manager Dendreo and fastlane gems that skip CI environments fetch a native backdoor from a Forgejo C2 at git.disroot.org and install dual persistence through systemd and cron with optional setuid root escalation.

Imagine a Ruby gem which has not pushed out a single release since 2020, then suddenly drops two new releases in the same afternoon. No announcement in the github repo. There is no release tag anywhere in the history of the project.

Only two new version numbers on RubyGems.org while the underlying source project is completely unchanged. The same pattern repeated itself on July 18 and 19, 2026 on three different Ruby packages, and they all had the same aim. quietly backdoor the laptop of whoever happened to run bundle install or require the gem next.

SleeperGem Malware Attack Chain Explained

StepSecurity researchers named this coordinated campaign SleeperGem after originally reported by Aikido Security and published a full technical walkthrough on July 19 2026 after running every compromised version inside their Harden-Runner tooling to capture the complete kill chain in a controlled environment.

Three gem packages carried malicious releases. The first was git underscore credential underscore manager at versions 2.8.0 through 2.8.3 which impersonates the official Microsoft Git Credential Manager that Ruby developers frequently install alongside their Git tooling.

The second was Dendreo at versions 1.1.3 and 1.1.4 both published on July 18 despite the gem sitting completely dormant since October 2020 meaning nearly six full years passed between the last legitimate release and these two malicious ones appearing on the same day.

The third was the fastlane plugin run underscore tests underscore firebase underscore testlab at version 0.3.2 published July 19 with no matching GitHub tag since the upstream project’s own tags stop at v0.3.1.

The attack architecture consists of a loader stage embedded in the gem and a native daemon stage delivered from an attacker controlled server. The loader contains very little malicious logic on its own.

Starting from version 2.8.2 of the git credential manager gem the malicious code executes not only at install time through a postinstall hook but at require time as well meaning anyone who simply imported the library in their Ruby code triggered the loader without running gem install at all.

That design decision deliberately bypasses the practice of using the ignore scripts flag during installation since that flag only blocks lifecycle hooks and has no effect on code that runs when a library loads normally.

When the loader fires it checks approximately thirty environment variables that CI platforms set including GITHUB ACTIONS GITLAB CI and CIRCLECI. If it detects any of them it exits immediately and does nothing.

This CI evasion logic reveals the attackers primary target and primary concern simultaneously. Developer laptops hold credentials secrets and sessions that persist across months and years. Ephemeral CI runners get destroyed after each job and hold only the credentials scoped to that specific build.

An attacker who drops a backdoor on a developer machine gains a foothold that survives indefinitely while a CI runner foothold disappears within minutes. StepSecurity confirmed this behavior by stripping the CI environment variables from their test runner to force the malware to believe it ran on a developer machine before capturing the subsequent activity.

After passing the CI check the loader spawns a child Ruby process that runs the gem’s bundled install script. That script downloads two files from the command and control host at git.disroot.org which hosts a public Forgejo instance where the attacker registered a username styled to resemble an official Git ecosystem account.

The download uses Ruby’s built in HTTP client with SSL certificate verification explicitly disabled and sets the User-Agent header to the single word Git so the outbound traffic pattern blends visually with normal Git operations during any casual network log review.

The two downloaded files consist of a shell script named deploy.sh and a native binary carrying the same name as whatever legitimate tool the gem impersonated.

The comparison between version 2.8.2 and version 2.8.3 of the git credential manager gem reveals the attacker iterating in real time. In 2.8.2 the line that actually executes the downloaded shell script sits commented out meaning that version downloads the payload to disk and stops there.

It stages the attack without detonating it. Version 2.8.3 published shortly after removes the comment and runs the full chain making it the version that achieves complete compromise on victim machines.

When deploy.sh runs it copies the native binary into a hidden directory at home .local share gcm and marks it executable before launching it as a background daemon. Persistence then gets installed twice through a systemd user service and a cron entry both named git credential manager so the daemon restarts even if the victim discovers and removes only one persistence mechanism.

The script then checks the sudo and wheel groups. If the current user can execute sudo without a password the script re-runs itself as root and at root privilege it plants a setuid root copy of the system shell at usr local sbin ping6 with permissions 6777 which provides permanent root access through a path chosen to resemble a legitimate networking utility.

StepSecuritys test runner did not have passwordless sudo so that branch checked the groups and stopped but the complete code path sits present and active in every affected release.

SleeperGem Malware Detection Guide

The command and control domain git.disroot.org belongs to a legitimate public service with genuine uses across the open source community making domain reputation blocking ineffective as a primary defense since the domain itself carries no inherent malicious classification.

What matters for detection sits in the behavior pattern rather than the destination. A Ruby process that spawns a child process to run a shell script immediately after a gem gets required represents a strong anomaly signal especially when that child process then makes outbound HTTPS connections with certificate verification disabled and a single word User-Agent string.

StepSecuritys Harden-Runner tooling captured the complete process tree during their controlled detonation which shows the steps in exact order. The gem path install script fires first followed by sh executing deploy.sh followed by the cp command moving the binary into the hidden home directory followed by chmod making it executable followed by the daemon launch followed by systemd and cron persistence installation followed by getent checking the sudo and wheel groups.

This sequence provides a reliable behavioral signature that runtime monitoring tools looking at process trees rather than file signatures can detect with high confidence regardless of what name the dropped binary carries.

For any developer or team that installed or required any of the compromised versions the appropriate response treats the affected machine as fully compromised rather than partially exposed. The specific remediation steps involve uninstalling the malicious gem and pinning to a confirmed safe version.

Disabling and removing the systemd user service named git credential manager and removing the matching cron entry. Deleting the home .local share gcm directory and everything inside it. Inspecting usr local sbin ping6 and removing it if it shows permissions of 6777 or contains a shell rather than the legitimate networking utility.

Rotating every credential accessible from that machine including SSH keys cloud provider access keys and secrets stored in environment files and password managers since the dropped daemon’s full network behavior and exfiltration capabilities require separate binary analysis of the native payload to fully characterize.

Network log review provides the most reliable retrospective signal for teams that lack runtime monitoring. Any connection to git.disroot.org originating from a Ruby process during the July 18 through July 19 2026 window confirms the loader executed and the payload downloaded to that machine. That connection represents a definitive indicator of compromise regardless of whether the daemon subsequently communicated with any additional infrastructure.

The broader pattern SleeperGem exemplifies deserves equal attention alongside its specific indicators. Dormant packages that suddenly ship new releases represent one of the clearest warning signals available in any package ecosystem and one that automated tooling can detect reliably by comparing publish timestamps against repository release tag histories.

A version appearing on a package registry with no corresponding source control tag in the originating project provides equally strong evidence that a release did not come through the project’s normal development and review process.

Package managers do not yet ship these signals to developers as first class warnings during installation and until they do the burden falls on individual developers and security teams to build the monitoring that catches these patterns before malicious packages reach production machines.