Malicious Go package removed from GitHub, but credential threat persists

A malicious Go module was discovered that poses as a fast SSH brute forcer, but covertly exfiltrates credentials to its source.

In an Aug. 21 blog post, Socket researchers explained that the Go package continuously scans random IPv4 addresses for exposed SSH services on TCP port 22, authenticates using a local username-password wordlist, and then exfiltrates any successful credentials via Telegram.

The result: Anyone who runs the Go package hands over their initial access wins to the Russian-speaking threat actor IllDieAnyway on GitHub and within the Go Module ecosystem.

Nic Adams, co-founder and CEO at 0rucs, explained that the malicious module works as advertised as a brute-force tool while secretly exfiltrating credentials. Adams said this makes it difficult for a developer to spot just by looking at the module's primary function.

“While Go's module system is generally a security advantage due to its immutability, once a version is published to a proxy, its contents can't be changed, this also means a malicious module can remain available indefinitely,” said Adams. “Even if the original GitHub repository is taken down, which it was in this case, the module continues to exist on the pkg.go.dev proxy where it was originally downloaded and cached. This makes it a persistent threat.” 

Jason Soroko, senior fellow at Sectigo, added that the real danger is that a tool posing as researchware silently converts curiosity into compromise by stealing working SSH credentials the moment it lands a hit and sends them to the attacker. Soroko said because it disables host key checks and tries weak root and admin passwords, a single success can grant privileged access on an internet facing host, enable lateral movement, and create persistent footholds that look like normal admin activity.

“Security teams should treat unvetted offensive tools as hostile, read and build Go modules from source only after review, pin, and vendor dependencies, and run any testing in isolated sandboxes with egress restrictions and no real secrets,” said Soroko. “Enforce key based SSH and disable password logins, rotate any credentials exposed during testing, monitor for bursts of SSH attempts and for outbound connections to Telegram and similar messaging APIs, and add detections for programs that set InsecureIgnoreHostKey.

Above all: Soroko said teams should treat this case as a software supply chain exposure and use signed releases, SBOMs, least privilege, and strict egress controls to reduce blast radius