The Attack in 90 Seconds

The attack exploited a structural property of Go's module system: import paths are URLs, not names. golang.org/x/crypto and github.com/xinfeisoft/crypto are completely different modules. One is maintained by the Go team; the other was a trap.

The malicious package cloned the structure of the legitimate golang.org/x/crypto repository and made one surgical modification: it replaced the ReadPassword() function inside ssh/terminal/terminal.go. The replacement function did everything the original did — but before passing the credential to the caller, it sent it to an attacker-controlled endpoint.

From the victim's perspective: SSH authentication appeared to work normally. Under the hood, every password typed into a terminal using this modified function was being exfiltrated.

That was step one.

Step two: a curl-piped shell stager was downloaded and executed. It performed three operations:

1. Added an attacker-controlled SSH public key to ~/.ssh/authorized_keys — establishing persistent SSH access independent of any credentials
2. Loosened iptables rules to permit inbound connections on attacker-specified ports
3. Downloaded and executed Rekoobe — a C++ Linux backdoor with a decade-long operational history

Rekoobe: The APT31 Fingerprint

Rekoobe is not a commodity RAT picked up from a dark web forum. It is a purpose-built Linux backdoor attributed to APT31 (also tracked as Zirconium, Judgment Panda, and Bronze Vinewood) — a Chinese state-sponsored threat actor with a specific focus on government, defence, and high-technology targets.

First documented in 2015, Rekoobe has remained in continuous operational use across multiple campaigns. Its characteristics:

• Architecture: C++ native binary, x32 and x64 variants
• Anti-analysis: Anti-VM checks, obfuscated strings
• Persistence: Multiple persistence mechanisms (varies by variant and dropper)
• C2: Encrypted command channel, typically TLS or custom protocol over standard ports
• Capability: Remote shell access, file transfer, credential harvesting

The presence of Rekoobe in a Go supply chain attack is a significant indicator of targeting intent. This is not a script kiddie operation. APT31 doesn't distribute commodity malware through package registries by accident.

Why Go Modules Are an Attack Surface

The Go module system has a fundamental property that makes it susceptible to namespace confusion attacks: module identity is an import path, and import paths are arbitrary strings. The go toolchain will happily download github.com/xinfeisoft/crypto if that's what's in your go.mod — it doesn't know or care that the string is designed to look like a standard library extension.

This is the same class of attack that has repeatedly targeted npm (event-stream, ua-parser-js, colors), PyPI (requests vs request), and Rust (crates.io name squatting). Go's explicit module paths should make this harder — they're fully qualified, not just short names. But the attack succeeded by exploiting the fact that many Go developers trust Github-hosted packages with familiar-sounding paths without verifying the upstream source.

The Go security team has now blocked github.com/xinfeisoft/crypto from the module proxy and sum database. If you attempt to resolve this module today, you will get an error. But:

• Projects that already fetched the module before the block have it in their module cache
• Projects using GONOSUMCHECK or GONOSUMDB bypass checksum verification
• Private Go module proxies (common in enterprise environments) may have cached the package
• The attack pattern is published and documented — another package using the same technique is trivial to create

Detection: What to Look For

In Your Codebase

Scan your go.mod and go.sum files for suspicious imports — particularly anything that:

• Closely resembles a golang.org/x/* path but is hosted on GitHub or another third-party host
• Has a maintainer name that doesn't match the expected open source project (e.g., Chinese-named repos replacing standard library packages)
• Has low star/fork counts relative to the package's apparent purpose
• Was added to go.mod without a corresponding PR or commit explanation

Run go mod verify to check that all module checksums match the Go module mirror. Any mismatch is a hard stop for investigation.

At Runtime / on the Host

If you suspect a host has been compromised via this vector:

# Check for unauthorised SSH keys
cat ~/.ssh/authorized_keys
# Also check system-wide
grep -r "authorized_keys" /etc/ssh/sshd_config

# Check for unusual outbound connections (Rekoobe C2)
ss -tulnp | grep -v "LISTEN"
netstat -tupn | grep ESTABLISHED

# Look for modified iptables rules
iptables -L INPUT -n -v | grep -v "ACCEPT.*lo\|ESTABLISHED\|RELATED"

# Check for curl-executed dropper artifacts
ls -la /tmp/ | grep -v "snap\|systemd"
find /tmp -name "*.sh" -newer /var/log/auth.log

# Search for Rekoobe binary signatures
find / -name ".*" -type f -newer /etc/passwd 2>/dev/null | head -20

Network-Level Detection

During the build/CI stage, watch for:

• Outbound HTTP/HTTPS requests from your Go build environment to unexpected hosts
• curl | sh or wget | bash patterns in build logs
• DNS queries to domains that don't match your expected dependency set

Network egress filtering on your CI runners is the single highest-value control here. A Go build should only need to reach proxy.golang.org, sum.golang.org, and your known VCS hosts. Everything else should be blocked by default.

The Role of Supply Chain Scanners

TruffleHog — now part of SecurityClaw's skill set — is primarily known for secrets detection, but the same principle of scanning dependency files applies to supply chain security. A scanner integrated into your CI pipeline can flag:

• Known-malicious package hashes against threat databases
• Module import paths that match known typosquatting patterns
• Changes to go.sum that don't match the official Go sum database
• New dependencies added to go.mod without corresponding audit trails

For enterprise Go shops, tools like govulncheck and Syft with a vulnerability database scan provide coverage at the dependency graph level. The combination of dependency pinning + checksum verification + egress filtering + supply chain scanning closes most of the attack surface for this class of attack.

Who Is at Risk

Projects most exposed to this technique:

• Go projects that added github.com/xinfeisoft/crypto before the block — audit go.mod immediately
• Projects using GONOSUMCHECK or running with a private module proxy that cached the package
• Developer workstations that ran a build using the malicious module (credentials may have been exfiltrated)
• CI/CD pipelines running on Linux systems (Rekoobe targets Linux; Windows is not affected)

Mitigation Checklist

The Pattern Will Repeat

The Go security team blocked github.com/xinfeisoft/crypto quickly. That's good. But the more important takeaway is that the pattern is documented, simple, and highly effective: clone a widely-used standard library extension. Modify one commonly-called function. Publish it with a plausible name. Wait.

Go's ecosystem is particularly attractive for this because:

• The standard library extensions (golang.org/x/*) are de facto standard but not actually part of the core go tool — they're fetched like any other dependency
• Go developers are less conditioned than npm developers to scrutinise dependency provenance (the npm ecosystem has been burned by this repeatedly; the Go community less so)
• The go.sum checksum system is strong once it's running, but it's opt-out-able and many enterprise setups have exceptions

Expect this technique to resurface. Verify your import paths. Run supply chain scans. Filter your build environment's network egress. Treat every dependency as potentially adversarial until verified.