Malicious Ruby Gems Go Modules CI Secret Theft Explained

An uncovered coordinated software supply chain campaign tied to the GitHub account BufferZoneCorp and the RubyGems profile knot-theory, targeting developers, CI runners, and build environments across the Ruby and Go ecosystems through credential theft, dependency poisoning, SSH persistence, and tampering with GitHub Actions.

The threat actor behind BufferZoneCorp did not immediately weaponize their packages. Instead, the campaign followed a deliberate sleeper-to-payload escalation: packages were initially published with plausible utility branding.

Clean README files, and minimal functionality, then silently updated to include active malicious payloads. This tactic mirrors an emerging pattern in software supply chain attacks, in which trust is established before exploitation begins.

Malicious Ruby Gems & Go Modules Campaign

Seven Ruby gems were published under the knot-* namespace names closely resembling legitimate Rails and ActiveSupport utilities, such as activesupport-logger, devise-jwt, and Rack session tools.

Nine Go modules were published under the github.com/BufferZoneCorp/ namespace, impersonating well-known libraries such as HashiCorp’s go-retryablehttp and Kelsey Hightower’s envconfig. Two Ruby gems and two Go modules remain as unweaponized sleeper packages, indicating the campaign was still expanding at the time of discovery.

Following disclosure, the Security team swiftly blocked the identified malicious Go modules. As of writing, the identified Ruby gems and the BufferZoneCorp GitHub account remain active.

The most technically aggressive Ruby component is knot-activesupport-logger, which masquerades as a helper for Rails logging. Its malicious execution begins not at runtime, but at install time via extconf.rb a file RubyGems automatically executes as part of the native extension build process.

The install-time payload filters environment variables for keywords such as token, key, secret, pass, aws, github, api, and auth. It then reads sensitive credential files from the developer’s home directory, including:

~/.ssh/id_rsa and ~/.ssh/id_ed25519 (SSH private keys)
~/.aws/credentials (AWS access keys)
~/.gem/credentials (RubyGems publishing tokens)
~/.npmrc, ~/.netrc, ~/.gitconfig
~/.config/gh/hosts.yml (GitHub CLI authentication data)

All harvested data is JSON-encoded and exfiltrated via HTTPS POST to an obfuscated Base64-encoded webhook endpoint. The gem decodes to hxxps://webhook[.]site/49c21843-c27c-4a1b-b1f6-037c3998055f.

A secondary runtime exfiltration path triggers on the first log write, spawning a background thread to send additional environment secrets to the same endpoint.

In controlled lab testing, installation alone was sufficient to trigger the outbound POST containing host metadata and staged test credentials, confirming that zero user interaction is required beyond running gem install.

The Go modules introduce a broader and more sophisticated range of attack techniques. Rather than a single payload, the cluster deploys distinct strategies across modules, all executing automatically through Go’s init() function on import.

github.com/BufferZoneCorp/go-metrics-sdk detects the presence of GITHUB_ENV a GitHub Actions environment indicator and rewrites workflow trust settings by appending poisoned environment variables: GOPROXY pointing to a threat-actor-controlled endpoint, GOSUMDB=off, GONOSUMDB=*, GOFLAGS=-mod=mod, and a redirected GOMODCACHE path.

It simultaneously removes checksum entries for logrus from go.sum to weaken dependency integrity verification. This allows later workflow steps to silently resolve dependencies from attacker-controlled sources.

github.com/BufferZoneCorp/go-retryablehttp takes a different approach: it plants a fake go wrapper in a cache directory. It prepends that directory to GITHUB_PATH, ensuring the wrapper is selected before the real Go binary.

The fake wrapper intercepts go command invocations before passing control to the legitimate binary, providing a persistent foothold without breaking the CI job. It also sets HTTP_PROXY and HTTPS_PROXY to redirect network traffic.

github.com/BufferZoneCorp/go-stdlib-ext combines credential theft with the establishment of persistent access. Beyond harvesting AWS credentials, SSH keys, npm tokens, Docker and Kubernetes configs, and GitHub CLI auth data, it appends a hardcoded SSH public key (deploy@buildserver) to ~/.ssh/authorized_keys.

If the threat actor controls the matching private key, this provides ongoing SSH access to the compromised host long after the malicious module has been removed.

A seventeenth repository, go-stdlog had not been pushed into the Go module ecosystem at the time of writing, but its public source already contained active reconnaissance logic.

Triggered on import, it inventories CI environment tokens, probes Docker socket, and AWS Instance Metadata Service (IMDS) endpoints. It writes runtime context to local diagnostic files, building a profile of the target environment for later exploitation.

MITRE ATT&CK Mapping

This campaign spans multiple MITRE ATT&CK techniques across initial access, execution, persistence, credential access, and exfiltration:

Technique ID	Description
T1195.001	Supply Chain Compromise: Software Dependencies
T1204.005	User Execution: Malicious Library
T1036.005	Masquerading: Match Legitimate Resource Name
T1552.001 / .004 / .005	Unsecured Credentials: Files, Private Keys, Cloud Metadata
T1098.004	Account Manipulation: SSH Authorized Keys
T1574.007	Path Interception by PATH Environment Variable
T1567.004	Exfiltration Over Webhook
T1082 / T1083 / T1526 / T1613	Discovery: System, File, Cloud, Container

GitHub account: BufferZoneCorp
RubyGems profile: knot-theory
Exfiltration endpoint: hxxps://webhook[.]site/49c21843-c27c-4a1b-b1f6-037c3998055f
SSH persistence key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBp9VZGMxqFpTwKbKJi7dS2mNrX3LqEoHcYsWfAkZvUt deploy@buildserver
Ruby gems: knot-activesupport-logger, knot-devise-jwt-helper, knot-rack-session-store, knot-rails-assets-pipeline, knot-rspec-formatter-json, knot-date-utils-rb, knot-simple-formatter
Go modules: go-metrics-sdk, go-weather-sdk, go-retryablehttp, go-stdlib-ext, grpc-client, net-helper, config-loader, log-core, go-envconfig

Mitigation

Organizations should take immediate steps if any BufferZoneCorp packages were installed in development or CI environments, as Socket reported:

Rotate all credentials potentially exposed: SSH keys, AWS access keys, RubyGems tokens, npm tokens, GitHub CLI tokens, and Docker credentials
Audit ~/.ssh/authorized_keys on affected developer machines and CI runners for the deploy@buildserver key
Review GitHub Actions workflow logs for unexpected writes to GITHUB_ENV, GOPROXY, GOSUMDB, GOFLAGS, or go.sum
Scan dependency manifests and build logs for any github.com/BufferZoneCorp/ module references
Restrict CI secret scope so build jobs only inherit credentials they explicitly require
Implement package review gates for all newly introduced developer utilities before they enter CI pipelines

FAQ

Q1: What is the BufferZoneCorp supply chain campaign?

It is an active software supply chain attack using malicious Ruby gems and Go modules published under the knot-theory and BufferZoneCorp identities to steal developer credentials, poison CI dependency resolution, and establish SSH persistence on affected systems.

Q2: How do the malicious Ruby gems steal credentials at install time?

They abuse extconf.rb a RubyGems native extension hook to automatically harvest secret-bearing environment variables and local credential files (SSH keys, AWS credentials, GitHub CLI tokens) and exfiltrate them via HTTPS POST before the developer ever runs the gem.

Q3: How does the Go module go-metrics-sdk tamper with GitHub Actions pipelines?

It rewrites GOPROXY to a threat-actor-controlled endpoint, turns off checksum verification via GOSUMDB=off, and removes go.sum integrity entries, enabling downstream workflow steps to resolve Go dependencies from attacker-controlled infrastructure silently.

Q4: What persistent access mechanism does this campaign plant on compromised hosts?

The go-stdlib-ext module appends a hardcoded SSH public key tagged deploy@buildserver to ~/.ssh/authorized_keys, granting the threat actor long-term SSH access to the host even after the malicious module has been removed from the dependency tree.

Site: thecybrdef.com

For more insights and updates, follow us on Google News, Twitter, and LinkedIn.