Malik Haidar has spent years in the trenches of multinational cybersecurity, bridging the gap between high-level business strategy and the gritty reality of threat intelligence. With a keen eye for how hackers weaponize legitimate tools, he has closely monitored the rise of identity-based supply chain attacks that bypass traditional defenses. Today, we delve into the “Gheist” campaign, a sophisticated operation that turned GitHub’s own automation features against its users. We will explore how attackers leveraged stolen tokens to infiltrate over 850 accounts, the clever use of workflow logs to exfiltrate secrets, and why private enterprise environments remain the most vulnerable link in this chain.
Attackers are increasingly using stolen access tokens to create malicious branches and commit workflows that print secrets; how is this changing the way we perceive internal security?
This campaign represents a surgical approach where the attacker doesn’t need to break down the front door because they simply walk in with a valid key. In the Gheist operation, we saw over 13,500 malicious branches created across a staggering variety of repositories, ranging from hobbyist projects to sensitive corporate assets. By committing a GitHub Actions workflow that prints repository secrets directly into the logs, attackers bypass traditional Command-and-Control detection because everything happens within the legitimate ecosystem. They download these logs via the API and scrub the evidence within seconds, leaving security teams chasing shadows. It forces us to stop looking for external malware and start looking for behavioral anomalies within our own automated pipelines.
GitHub introduced a protection hold for public repositories that requires collaborator approval for certain workflows. In your view, how effective has this been in disrupting these types of campaigns?
It is a significant hurdle, but it is certainly not a silver bullet. During the Gheist campaign, which was tracked since September 15, every single public workflow run examined by researchers was caught in that “action_required” state, effectively paralyzing the malicious execution. It is heartening to see a platform control introduced on July 28 actually stop an attack in its tracks by preventing the secret-stealing code from ever running in a public context. However, we have to remember that this control only targets public repositories, leaving the crown jewels of private enterprises largely untouched. It is a bit like having a high-tech biometric lock on your front gate while the back door to the mansion is still using a simple deadbolt.
Why do private repositories and Enterprise Servers remain so much more exposed to this specific tactic, and what are the real-world consequences for a business?
The protection hold simply does not extend to these environments yet, which creates a massive blind spot for security teams who assume their internal tools are safe. In corporate settings, we observed attackers cycling through a mix of user and automation account tokens to clone private repositories at an alarming rate. Once they gain access, the consequences are immediate and devastating; hours after a GitHub breach, those same stolen credentials were often used to enumerate AWS Secrets Manager. This isn’t just about losing some source code; it’s about losing the keys to the entire cloud kingdom, potentially exposing production databases and sensitive customer data.
We have seen the Gheist tool evolve into different variants, even targeting self-hosted runners. What does this tell us about the persistence and sophistication of the threat actors behind this?
The evolution of these tools shows a relentless drive to maximize the return on investment for every stolen token. One variant specifically targeted environment-scoped secrets, which are almost always high-value production credentials, while another attempted to scrape self-hosted runners for sensitive files. Even though some of these features were described as “buggy,” the intent is clear: they are refining their craft to dig deeper into the underlying infrastructure. Even after GitHub took down roughly two-thirds of the implicated accounts following the October reports, the campaign has continued to mutate and find new targets. It’s a cat-and-mouse game where the “mouse” is getting much smarter at using our own automation tools against us.
What is your forecast for the future of supply chain security?
I believe we are entering an era where the identity of the developer and the integrity of the token are the new perimeters. As we move through 2026 and beyond, we will see a surge in identity-aware security tools that go beyond simple validation to analyze the intent behind every branch creation and workflow modification. Organizations will be forced to implement much stricter least-privilege models for automation tokens, treating them with the same level of paranoia as administrative passwords. The battle won’t be fought with firewalls, but with real-time behavioral analytics that can spot a malicious workflow the millisecond it is committed to a repository.
