What Happened? 

• In July 2023, our scanners detected nontypical commits to hundreds of GitHub repositories appear to be contributed by Dependabot and carrying malicious code. 
• Those commit messages were fabricated by threat actors to appear as a Dependabot automated contribution in the commit history, an attempt to disguise the malicious activity  
• After reaching out and talking to some of the victims who got compromised, we can confirm that the victims’ GitHub personal access token was stolen and used by the attackers to contribute those malicious code contributions. 
• The malicious code exfiltrates the GitHub project’s defined secrets to a malicious C2 server and modify any existing javascript files in the attacked project with a web-form password-stealer malware code effecting any end-user submitting its password in a web form. 
• This attack also impacted private GitHub organizations repositories as some of the victim’s GitHub tokens also had access to. 
• It is unclear how the victims’ personal access tokens were stolen - it may be due to a maliciousopen-source package installed on their PC. 
• We will elaborate in this blog on the malicious payload and how using GitHub personal access tokens is currently undetectable to most GitHub users.  

About Dependabot 

Dependabot is GitHub’s free automated dependency management tool for software projects. It continuously monitors a project's dependencies (like libraries and packages) for security vulnerabilities and outdated versions. When it detects issues, it automatically generates pull requests with updates, helping developers keep their software secure and up to date.  

A screenshot of dependabot’s automatic pull-request from the Flask project 

The Fake Dependabot Commits 

Between July 8-11 a threat actor started compromising hundreds of GitHub repositories, both public and private. Most victims are Indonesian user accounts. The attackers used a technique to fake commit messages (read more about how it’s done here) to trick developers thinking this was contributed by the real dependabot and to ignore this activity. 

The attackers created a commit message “fix” appear to be contributed by user account “dependabot[bot]” 

A screenshot of the fake commit, taken from highpolar-softwares/I-help-privacy-policy repository 

Malicious Code 

In the various repositories we analyzed (full list remains internal but it was hundreds of repositories) we saw two groups of repeated code changes, most likely done with an automated script. 

A New GitHub Action to Steal Secrets 

New GitHub Action file named “hook.yml” was added as a new workflow file, triggers a code push event. It sends GitHub secrets and variables to URL hxxps://send[.]wagateway.pro/webhook. This action is triggered on every push event 

A screenshot of the malicious commit contributed to highpolar-softwares/I-help-privacy-policy 

Patching *.js Files to Steal Passwords 

In addition to the added GitHub Action, the attackers modified every existing project file having the “*.js“ extension and append an obfuscated line at the end of the file. 

This new line is designed to create a new script tag as the code is executed on a browser environment and load an additional script from this URL: hxxps://send[.]wagateway.pro/client.js?cache=ignore. 

A screenshot of the malicious commit contributed to juniorriau/kejaribiak 

The code loaded from hxxps://send[.]wagateway.pro/client.js?cache=ignore is attempting to intercept any web-based password form and send the user-credentials to the same exfiltration endpoint as before; URL hxxps://send[.]wagateway.pro/webhook 

A screenshot of the malicious code; designed to steal user-form credentials. 

How Was It Done? 

At first it was unclear to us how the attacker’s got access to those accounts, especially earlier this year when GitHub raised the bar for mandatory 2FA.   

To get a better understanding of how this happened, we approached some of the victims by sending an email notifying them of the breach and asking for help understanding the full picture.  

Luckily, some victims agreed to share information with us, and surprisingly when inspecting the accounts activity we realized that the attackers accessed the accounts using compromised PATs (Personal Access Token) -- most likely exfiltrated silently from the victim’s development environment. 

Step 1 – Workspace Initialization 

The victim must set up their development environment with a personal access token (or SSH/GPG key) identifying their account whenever they make git operations. This token is stored locally on the developer’s machine and can be extracted easily. 

Such access tokens do not require 2FA and can be used to access the account by any computer with internet access. 

Step 2 – Stealing the Developer’s Credentials 

We can only guess how the attackers got the developers credentials but seeing many cases of malicious packages aiming to perform that task suggest that it is one potential way that the attackers could have gotten their hands on those precious GitHub tokens. 

We believe the most likely scenario is that the victims were infected with such a malicious package, which exfiltrated the token to the attacker’s C2 server. 

Step 3 – Poisoning the Victim’s Code Projects 

In this step the attackers used the stolen victim’s personal access tokens to authenticate to GitHub and make the malicious code changes described above.  

Analysis of the scale of the attack reveals that it appears to be automated. 

This whole situation teaches us to be careful about where we get our code, even from trusted places like GitHub. It shows that even big platforms can have problems, so we need to always watch out and protect ourselves online.

This is the first incident we witnessed a threat actor using fake git commits to disguise activity, knowing that many developers do not check the actual changes of dependabot when they see it.

To make things safer, consider switching to GitHub’s fine-grained personal access tokens . These tokens allow you to reduce the risk of compromised tokens. So, if someone bad gets one of these keys, they can't do a lot of damage.

Sadly, the GitHub’s personal access tokens access log activity is only visible for the enterprise accounts. If your token was compromised, you can’t know for sure since this information is not visible for non-enterprise users in the audit log section.

The attacker's Tactics, Techniques, and Procedures (TTPs) involve the use of fake commits, stealing user credentials, and impersonating Dependabot to avoid detection show us supply chain attacks are getting more sophisticated as attackers realize it doesn’t take much to move silently.

IOCs:

• wagateway[.]pro
• hxxps://send[.]wagateway[.]pro/webhook
• hxxps://send[.]wagateway[.]pro/client.js

Timeline

• During 2023 - Attacker attacked victims and harvested personal access tokens (we don’t know how it was done and guessing malicious packages were involved) 
• 2023-07-08 – Attacker used stolen GitHub token in an automated attack, poisoning multiple repositories.
• 2023-07-24 – We first noticed this anomaly and began investigating.
• 2023-07-24 – Contacted the GitHub accounts infected by this attack + reported to GitHub.
• 2023-09-20 – Meeting with one of the victims, reviewed his access logs which helped us understand the attack flow.