Slack December 2022: GitHub Tokens, Private Repos, and a Quiet Disclosure
Threat Intelligence
Slack disclosed on December 31, 2022 that an attacker had used stolen employee GitHub tokens to clone private repositories. A look at how the tokens were obtained, what they granted, and why the detection took as long as it did.
By Arjun Raghavan, Security & Systems Lead, BIPI · April 12, 2024 · 7 min read
Slack chose a quiet day for the disclosure: December 31, 2022. The post was short. A limited number of Slack employee tokens had been stolen and used to access the Slack-hosted GitHub organization. Private code was downloaded. Production was not touched. The dates in the small print matter: the access began on December 27 and was detected on December 29. Two days of attacker time is the more interesting part of the story.
Timeline
- On or before December 27, 2022: employee GitHub tokens are stolen. The vector was not detailed publicly. Most analyses point to either a developer machine compromise or a token leaked to a third-party service that was itself breached.
- December 27: the tokens are used to authenticate to Slack's GitHub organization and begin cloning private repositories.
- December 29: Slack detects suspicious activity in the GitHub organization. Tokens are revoked and the investigation begins.
- December 29 through 31: scope is established. Some private repositories were cloned. No customer data, no production code in the customer-facing sense, and no Slack downloads were affected per the company's statement.
- December 31, 2022: public disclosure published on the Slack blog.
Root cause
Long-lived personal access tokens with broad repository scope, used outside hardware-bound authentication contexts. PATs are bearer tokens. If they leak, they grant whatever they were granted at issuance until they are revoked. The exact leak path was not published, but the structural cause is the token model itself.
A GitHub PAT with org access is a domain admin credential with a friendlier name.
Attacker actions
Targeted cloning of a subset of repositories. There was no commit, no fork, no GitHub Action manipulation visible in the disclosure. The activity profile matches an actor optimizing for quiet exfiltration of intellectual property: clone, leave, sell or use the source later. The two-day detection window is consistent with that quietness.
Detection signals
- GitHub audit log: repo.clone events from a token where the source IP differs sharply from the token's normal usage. GitHub Enterprise Cloud has the IP in the audit feed.
- Volume anomalies: a token that normally pulls two or three repos a day cloning fifty in an hour.
- Tokens authenticating from cloud provider IP ranges they have not used before. Attackers often run from VPS infrastructure.
- Workflow audit: tokens used outside their associated CI runners or developer machines.
Lessons
- Inventory every PAT in your GitHub organization. Most companies have more than they think, and most have at least one with admin scope that nobody remembers creating.
- Move CI authentication to OIDC. GitHub Actions to AWS, GCP, and Azure has been OIDC-native for a while; the migration is mostly paperwork.
- Set max token lifetimes at the org level. If a PAT cannot live longer than 90 days, the worst leak has a 90-day half-life.
- Stream GitHub audit logs to your SIEM. Detection of this incident class is straightforward once the logs are in front of an analyst.
The Slack disclosure is small in stated impact and large in implication. Source code theft does not always become a public exploit chain, but it always becomes leverage. The next time a Slack-shaped CVE is filed, the attacker who held that code has a head start. The defensive lift is unglamorous: kill the PAT, install the app, rotate the secret.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.