Shai-Hulud Attack Nips Cyber-Firm CrowdSec's GitHub Data

A supply chain attack led by the TanStack worm resulted in the theft of 170 private GitHub repositories from the French security firm CrowdSec. The breach stemmed from a former employee’s compromised account, leveraging a stolen GitHub OAuth token. Investigators traced the attack back to the ex-employee’s account, highlighting a critical security lapse – leaving an employee’s GitHub access open after their departure. CrowdSec implemented several security measures, but the incident underscores the ongoing risk of supply chain attacks and the importance of proactive security practices like immediately revoking access for departing employees and utilizing endpoint detection and response.

CrowdSec acknowledged the breach, which happened in May, last week in a blog post outlining the attack and how it happened. Attackers stole a GitHub API token from the former employee’s machine that retained permission to read CrowdSec’s private repositories, and then downloaded the contents of those repositories over the course of just several minutes, according to the post.

CrowdSec traced the attack as occurring on May 22, between 5:52 am and 6:01 am UTC, when one of the founders of BreachForum and a member who goes by the online name "diencracked" downloaded the GitHub repository data from an IP address in Toronto. The company's investigation eventually led them to a URL that contained a GitHub OAuth token, which investigators realized had been used to obtain access to the private repositories. However, that token no longer existed in its own GitHub audit records, so CrowdSec enlisted the help of GitHub to determine how the access happened.

Eventually, investigators traced the attacker’s repository operations back to the account that had performed them, identifying that it belonged to the former CrowdSec developer "who had just left the company, but that was still part of the GitHub organization for legitimate reasons, and his account was used to dump the repositories," Humeau wrote. “The ex-employee got compromised by the TanStack supply chain attack, matching the methodology.” The company removed the account from GitHub on May 25, three days after the incident.

Denis Calderone, co-founder and chief operating officer at Suzu Labs, says the incident could have been avoided with basic security hygiene. “Revoking access the moment someone leaves is about as fundamental as security gets,” he says. “It’s day-one stuff. CrowdSec didn't do it. They kept a departed employee’s GitHub access open so he could wrap up some outstanding work, and that lingering account is what attackers used to clone 170 private repositories.”

CrowdSec did not immediately return a request for comment. But Humeau noted in the blog post that CrowdSec already had numerous security mechanisms in place, including but not limited to: strict privilege separation, two-factor authentication, password wallets, and extensive logging, pen testing, and audits. Other Key Takeaways for Defenders: If a company as locked-down as CrowdSec can get breached by a supply chain attack via one basic security faux pas, it certainly puts a typical organization at an even greater risk of a breach, observes John Strand, owner of security firm Black Hills Information Security. “The obvious question is how many other companies have been compromised that don’t have that same level of security rigor?” he tells Dark Reading. One protection that CrowdSec lacked at the time of the incident was endpoint detection and response (EDR), which was not enforced on developers’ machines, Humeau acknowledged. “We’ve since started using endpoint protection that actively focuses on malicious packages, extensions, etc.,” he wrote. “As supply chain attacks become the new plague and virtually anyone can get caught in them, we should have done this earlier.” Indeed, in addition to making sure organizations shut down accounts of any employees the day they are out of the door, putting “EDR on any workstation that touches code or infrastructure” is a good practice to follow when it comes to poisoned package attacks because “that developer laptop is part of your attack surface now,” Calderone says. Organizations also should treat their own source code as sensitive data to protect it from similar attacks, Calderone adds. “Scan it for hardcoded secrets before an attacker does,” he advises, “and assume anything ever committed to it is one bad day from being public.”