Large Scale Campaign Created Fake GitHub Projects Clones with Fake Commit Added Malware

Today, as it was revealed by Stephen Lacy in his tweet, he shared his findings of a large-scale campaign targeting random GitHub repositories with project clones containing credential stealing malware and remote shell execution on top of the original code.

Quickly after this tweet was published, either GitHub or the attacker removed most of the public forked projects, hiding the evidence.

A couple of hours later, a tweet from a newly created user account, @Pl0xP, claims that he is behind the attack and it is part of a bug bounty.

Attack Flow

This attack vector is possibly trying to target what users type in search-engines-related code snippets and land into these malicious random GitHub repositories, as discovered by Stephen Lacy when accidentally browsing through one of the infected fake clones. Here is a possible scenario:

  1. The attacker forks a GitHub repository
  2. The attacker alters the latest original commit and adds malicious code using the original committer identity
  3. The malicious payload sends sensitive environment variables to the attacker’s infrastructure, and then waits for a command from the attacker to execute on the machine

It seems the attacker amended the most recent commit and modified it with malicious code. It is possible they planned to inject this code into the original forked project.

By amending or committing changes in the right manner, attackers can impersonate another GitHub user and make it look like the commit came from them. This is done by locally changing certain environment variables to obtain the username and email address of the user the attacker would like to impersonate. Read more about this technique.

Screenshot from one of the infected commits. Note the commit signature is unverified

Infecting GoLang Files

It appears that the attacker ran a program to “patch” each of the cloned project’s “.go” files with an init function, thus having the capabilities to exfiltrate environment variables and execute code on the victim’s machine. This malicious code will not run if the environment variable “e452d6ab=1” is defined as seen below:

Infecting NPM Project Files

It appears the attacker ran a program to “patch” each of the cloned project’s “package.json” files with “postinstall” statement, having a logic to exfiltrate environment variables and execute code on the victim’s machine as shown below:

Infecting YAML Files

YAML files, infrastructure configuration, and containers were modified with additional steps to execute a curl command to exfiltrate all environment variables to the custom service as shown below:

More file formats

We assume there are more file formats the attacker targeted in addition to the formats above.

Researcher’s work?

Although @Pl0xP responded a couple of hours later to the original tweet that this was done as part of a bug bounty, this is waiting to be proven. Nevertheless:

  1. The code exfiltrated sensitive environment variables. Let’s say you’re doing a POC, and sending your computer name is more than enough.
  2. After exfiltrating the data, the server sent commands to be executed on the victim’s machine.
  3. Twitter username @Pl0xP is a new user account on twitter.


We are seeing more and more large scale attacks on the open source ecosystem, for example, the research here:

Those attacks can easily fool an unsuspected developer (read more). If this is the work of an ethical hacker, we need to set clear boundaries for what is allowed/un-allowed (read more).

We will update this blog as needed...


Skip to content