Accounts compromised on GitHub collected secrets

The attacker placed a secret-stealing script in the repositories that the 4837 GitHub accounts he hijacked had permission to write. According to Aikido Security, the script ran in at least 1,806 repositories. SafeDep's analysis gave a much higher figure: 8093 warehouses.

SafeDep's count includes all repositories that received malicious commits, including those that did not have the opportunity to work. The actual number may be higher because the crawl only looks at majors of public projects. The changes were made between 12.46 UTC on Tuesday and 04.36 UTC on 12 November.

How to use GitHub accounts

It all started with a test pull request opened from the wfx-docs branch with the title «docs: dependency audit notes». The attacker was thus testing whether the compromised account could change the contents of the repository. Such requests were seen in 61,764 projects. In some parts, a secret-stealing script was added.

SafeDep found that the script was added to existing GitHub Actions workflows in 7,309 incidents. It spread via npm postinstall in another 771 cases. This is a mechanism that allows code to run automatically when a package is installed. This way, the code could run not only on the project's cloud infrastructure but also on the developer's own computer.

The attacker would usually revert the changes after a few minutes. The script's execution records were also deleted along with the executions. Just because there is no visible trace does not mean that the data was not stolen. In this way, compromised GitHub accounts may go undetected for a long time.

What was the script collecting?

GitHub Actions secrets, GITHUB_TOKEN, temporary OIDC and Actions Runtime tokens

Keys to artificial intelligence services

Information in AWS, Azure, Google Cloud, Kubernetes, npm, PyPI and SSH configuration files

Repository contents, last 100 commits and recent workflow outputs

In self-hosted runners on companies' own servers, the script could also extend to additional cloud credentials. These included virtual machine metadata, Docker container information, and systemd configuration. Data was sent via HTTP POST to remote servers or Telegram. Of the 200 malicious commits examined, approximately 20% used Telegram alone.

Cloud persistence risk

The attacker who obtained GitHub OIDC tokens could exchange them for AWS, Google Cloud and Azure sessions. It could create persistent AWS keys and change the trust policies of cloud roles. Could add federation credentials with wfx-ci- prefix in Azure; these allow password-free authorization of workflows. These methods can continue to work even if the initial tokens are canceled and the keys are renewed.

Aikido also found overlap with the GhostAction attack in October. At that time, affected GitHub accounts participated in the new campaign approximately 1,000 times more frequently. The company still doesn't attribute the two attacks to the same person; The tools and infrastructure were different.