Attackers Use Thousands of GitHub Accounts to Steal Secrets
TL;DR: An attacker used nearly 5,000 hijacked GitHub accounts to inject secret-stealing code into over 1,800 repositories. The attack targets CI/CD pipelines to steal sensitive cloud credentials, creating a significant supply chain risk.
Key facts
- Category
- Cybersecurity
- Impact
- Critical
- Published
- Source
- The Hacker News
Full summary
An attacker used thousands of hijacked GitHub accounts to inject secret-stealing code into over 1,800 repositories, targeting sensitive cloud credentials.
A large-scale automated attack has compromised thousands of GitHub accounts to steal sensitive credentials from software development pipelines. According to a report from security firm Aikido Security, an attacker leveraged 4,837 hijacked developer accounts to gain write access to their associated repositories. The attacker then injected malicious code into the Continuous Integration (CI) workflows of at least 1,806 of these repositories. The goal of this code, described as a "secret stealer," was to capture and exfiltrate any secrets, API keys, and cloud credentials that the automated build and deployment processes had access to. This campaign represents a significant supply chain threat, turning trusted developer accounts and automated systems into a vector for widespread credential theft. The scale of the operation, targeting a vast number of unrelated projects simultaneously, highlights the attacker's sophisticated use of automation to exploit a common weakness in modern software development practices.
The attack's mechanism is both simple and effective, exploiting the inherent trust placed in CI/CD systems. After gaining access to a developer's account via stolen credentials, the attacker programmatically identifies repositories where the account has write permissions. They then commit a small change, typically to the project's CI configuration file (such as a YAML file in the `.github/workflows` directory). This change adds a new step to the workflow that executes a malicious script. When the CI pipeline runs—which often happens automatically on any new code change—the script executes within the trusted runner environment. From there, it can access all the environment variables and secrets configured for that job, including `GITHUB_TOKEN`, cloud provider keys (like AWS or Google Cloud credentials), and other API tokens. The script then sends these stolen secrets to a remote server controlled by the attacker, giving them the keys to potentially sensitive infrastructure.
This incident is part of a growing trend of supply chain attacks targeting the software development lifecycle itself, rather than just the final product. While previous major incidents like the Codecov breach involved compromising a single, widely used third-party tool, this attack demonstrates a different and arguably more scalable approach: compromising individual developer accounts. By targeting the developers themselves, attackers can bypass security measures focused on vetting third-party software. This "death by a thousand cuts" strategy is harder to detect, as the malicious activity is distributed across thousands of seemingly legitimate accounts. It underscores a fundamental shift in the threat landscape, where the security of every single developer account with write access to code is now a critical component of an organization's overall security posture. Attackers are moving further "left," embedding their malicious code at the earliest possible stage of development to ensure it gets executed by trusted, automated systems.
For engineering and security teams, this attack serves as a critical reminder to adopt a zero-trust mindset within their CI/CD environments. The immediate response should involve auditing commit histories for suspicious modifications to workflow files and rotating all credentials exposed to CI pipelines. However, long-term prevention requires a more fundamental shift in security practices. Enforcing mandatory multi-factor authentication (MFA) for all developer accounts is the most crucial first step. Beyond that, organizations should implement the principle of least privilege, ensuring that each CI job only has access to the specific secrets it absolutely needs. Adopting modern authentication methods like OpenID Connect (OIDC) allows for the use of short-lived, dynamically generated credentials instead of long-lived static secrets. As attackers continue to refine these techniques, we can expect to see more sophisticated variations, making proactive defense and continuous monitoring of CI/CD pipelines an essential practice for any organization developing software.
Why it matters
This attack demonstrates a critical vulnerability in the software supply chain. By compromising developer accounts, attackers can inject malicious code directly into CI/CD pipelines, bypassing traditional security checks and gaining access to production cloud environments. It highlights the risk of trusted but compromised developer credentials.
Business impact
A successful attack of this nature can lead to catastrophic data breaches, significant financial loss from stolen cloud resources, and severe reputational damage. It forces companies to re-evaluate their developer account security and the implicit trust placed in CI/CD systems, potentially increasing security overhead and costs.
⚡ Action needed
Organizations using GitHub should immediately review their CI/CD workflows and audit developer account access for suspicious activity.
Action checklist
- 1Review recent commits to your repositories for unexpected changes, especially in CI configuration files.
- 2Enforce multi-factor authentication (MFA) for all GitHub accounts with repository access.
- 3Rotate all secrets and credentials exposed to your CI/CD environment, including API keys and cloud access tokens.
- 4Audit GitHub account permissions, removing write access for any inactive or unnecessary accounts.
- 5Implement security scanning tools that can detect credential leaks and suspicious code in CI pipelines.
Tags
Related on Notifire
Related stories
Primary source: The Hacker News
