Malicious Go Module Mimics Trusted Library to Steal Credentials and Deploy Rekoobe Backdoor
A recently uncovered supply chain attack has placed Go developers at significant risk. A threat actor has published a malicious Go module that closely resembles the widely trusted cryptographic library, `golang.org/x/crypto`. This counterfeit module is designed to steal passwords and covertly install a Linux backdoor on compromised systems.
This incident underscores the growing threat of dependency name impersonation, where even well-established libraries can be weaponized against unsuspecting developers.
The Malicious Module:
The deceptive module, `github[.]com/xinfeisoft/crypto`, was publicly listed on `pkg.go.dev` as version `v0.15.0`, with a publication date of February 20, 2025. It replicates the entire structure of the legitimate `golang.org/x/crypto` repository, including familiar subpackages like `bcrypt`, `argon2`, `acme`, and `ssh`. This meticulous duplication allows the malicious module to seamlessly integrate into dependency graphs, evading immediate detection.
The attacker exploited Go’s ecosystem, which uses GitHub as a mirror for the canonical `go.googlesource.com/crypto` repository. This strategy made the similarly named malicious module appear routine during code reviews.
Discovery and Analysis:
Researchers at Socket.dev identified the malicious module after their AI Scanner flagged a backdoor embedded within `ssh/terminal/terminal.go`. The modification specifically targeted the `ReadPassword` helper function, commonly used by tools handling SSH passphrases, database logins, and interactively entered API keys.
Notably, the backdoor activates only during live interactive use, remaining dormant during automated test runs. This behavior significantly reduces the likelihood of accidental discovery.
Credential Theft Mechanism:
When a developer’s application invokes `ReadPassword`, the compromised function captures the credential in plaintext and writes it to `/usr/share/nano/.lock`, a path chosen to avoid detection. Subsequently, it fetches a staging pointer from the threat actor’s GitHub-hosted repository, posts the stolen password to a dynamically resolved endpoint, retrieves a shell script, and executes it via `/bin/sh`.
This design allows the attacker to rotate infrastructure URLs without republishing the module. In response, the Go security team has blocked the module at the public proxy, returning a 403 SECURITY ERROR response.
Broader Implications:
The impact is particularly significant for teams operating in Go-based Linux environments, especially those running cloud virtual machines, CI/CD runners, or administrative bastion hosts. Any application importing this module and invoking `ReadPassword` becomes a live credential harvesting point, exposing SSH passphrases, database passwords, and API keys before any hashing or encryption can protect them.
Multi-Stage Backdoor Delivery Chain:
Following the initial script execution, a five-stage Linux dropper chain is initiated:
1. Initial Fetch: The backdoored `ReadPassword` function retrieves `update.html` from the attacker’s GitHub repository, which redirects to `seed.php` at `img[.]spoolsv[.]cc`.
2. Launcher Execution: The endpoint returns a `curl | sh` launcher that fetches and executes `snn50.txt`, the primary Linux stager that prepares the host and delivers the final payloads.
3. Stager Actions: The `snn50.txt` stager performs three critical actions:
– Appends a threat actor-controlled SSH key to `/home/ubuntu/.ssh/authorized_keys`, creating persistent remote access that survives password resets.
– Sets `iptables` default policies to ACCEPT, weakening the host firewall.
– Downloads `sss.mp5` and `555.mp5` from `img[.]spoolsv[.]cc`, disguised with media-like extensions to bypass basic file inspection, executes them, and deletes them from disk to reduce forensic evidence.
Rekoobe Backdoor Deployment:
Researchers confirmed that `555.mp5` is a Rekoobe Linux backdoor, a tool with documented ties to APT31 (Zirconium) and partial lineage from the Tiny SHell codebase. The binary communicates with `154[.]84[.]63[.]184` over TCP port 443 without a standard TLS handshake, suggesting custom encrypted traffic designed to pass as HTTPS.
The `sss.mp5` sample functions separately as a loader and reconnaissance component during the same stage.
Defensive Measures:
To mitigate the risk posed by this attack, developers and security teams should:
– Audit Dependencies: Review `go.mod` and `go.sum` files for unexpected module root changes. Treat any new dependency addition as a security review item.
– Monitor Endpoints: Keep an eye on writes to `/usr/share/nano/.lock`, unauthorized modifications to `authorized_keys`, and `iptables` policy resets to ACCEPT.
– Block Malicious Domains: Prevent access to `img[.]spoolsv[.]cc` and `img[.]spoolsv[.]net`.
– Alert on Suspicious Activity: Set up alerts for processes that chain GitHub Raw fetches with outbound HTTP POST calls to detect this pattern early, before backdoor delivery completes.
By implementing these measures, organizations can enhance their defenses against sophisticated supply chain attacks targeting Go development environments.
