Over the 2022 holidays, an attacker used a small number of stolen Slack employee tokens to reach Slack's externally hosted GitHub account and download private code repositories. The download happened on 27 December 2022. Slack was alerted to suspicious activity on its GitHub account on 29 December, invalidated the stolen tokens and published a notice on 31 December. Slack says no downloaded repository contained customer data, means to access customer data or its primary codebase, and that the attacker did not reach its production environment. In an update on 9 January 2023, Slack added that the access "did not result from a vulnerability inherent to Slack": a third-party vendor had been compromised, and Slack worked with that vendor on credential rotation. Slack has not named the vendor.
Key takeaways
- A limited number of Slack employee tokens were stolen and used against Slack's externally hosted GitHub account, according to Slack.
- The attacker downloaded private code repositories on 27 December 2022, during the holiday period; Slack was notified on 29 December.
- Slack later said a third-party vendor had been compromised, which is where the tokens came from; it has not named the vendor.
- Slack reported no access to customer data, production systems or its primary codebase, and rotated all relevant credentials.
- The identity lesson: tokens you issue to vendors or store in vendor systems are your credentials held by someone else, and your exposure depends on their security.
At a glance
| Organisation | Slack (Salesforce); an unnamed third-party vendor |
|---|---|
| When | Repositories downloaded 27 December 2022; Slack notified 29 December 2022; notice published 31 December 2022; updated 9 January 2023 |
| Attacker | Unattributed |
| Entry point | Slack employee tokens stolen through a compromised third-party vendor |
| Identities abused | A limited number of Slack employee tokens with access to Slack's externally hosted GitHub repositories |
| Impact | Private code repositories downloaded; no customer data, production access or primary codebase affected, according to Slack |
| Category | NHI. Incident class: confirmed NHI breach (stolen access tokens used against source control) |
What happened
"On 29 December 2022, we were notified of suspicious activity on our GitHub account," Slack wrote. "Upon investigation, we discovered that a limited number of Slack employee tokens were stolen and misused to gain access to our externally hosted GitHub repository. Our investigation also revealed that the threat actor downloaded private code repositories on 27 December. No downloaded repositories contained customer data, means to access customer data or Slack's primary codebase."
Slack invalidated the stolen tokens immediately and said the attacker "did not access other areas of Slack's environment, including the production environment." It rotated all relevant credentials as a precaution and added alerting on its externally hosted GitHub. In its 9 January 2023 update, Slack said: "Our investigation has shown that a third-party vendor was compromised. We have worked with the vendor on credential rotation and are ensuring the security of tokens going forwards." It said it was working with vendors and security partners "to ensure that tokens used to access any Slack repositories are stored safely and securely."
BleepingComputer found the notice on 31 December and reported it on 5 January. It also noted that the notice was not listed on Slack's international news blog and, when viewed from some regions, carried a "noindex" tag that kept it out of search results, while the US version had been indexed by Google.
Timeline
| Date | Event |
|---|---|
| 27 December 2022 | The attacker downloads Slack private code repositories using stolen employee tokens. |
| 29 December 2022 | Slack is notified of suspicious activity on its GitHub account and invalidates the tokens. |
| 31 December 2022 | Slack publishes its security notice. |
| 5 January 2023 | BleepingComputer reports the incident. |
| 9 January 2023 | Slack updates its notice: a third-party vendor was compromised. |
How it happened: the identity attack path
- Vendor compromised. A third-party vendor that held or handled Slack tokens was breached, according to Slack.
- Tokens stolen. A limited number of Slack employee tokens with GitHub access were taken.
- Token replay against GitHub. The attacker used the tokens to reach Slack's externally hosted GitHub account.
- Private repositories downloaded. Repositories were cloned on 27 December, during the holiday period.
- Detection and revocation. Slack was alerted on 29 December, invalidated the tokens and rotated related credentials.
Impact
- Confirmed: some private Slack code repositories were downloaded.
- Not affected, according to Slack: customer data, means to access customer data, Slack's primary codebase and the production environment.
- Response: tokens invalidated, relevant credentials rotated, extra alerting added, and token storage reviewed with vendors.
What this means for NHI governance
Slack describes the credentials as "employee tokens", but they behaved like any other machine credential: they worked without the employee being present, they were stored outside Slack in a vendor's systems, and they opened source code to whoever held them. Slack's own conclusion was that the fix lay in how tokens are stored by vendors, not in Slack's code.
Holiday timing matters too. Attacks during low-staffing periods are common, and detection here depended on an alert that came two days later. Tokens scoped to what a vendor actually needs, short expiry and monitoring of unusual cloning give defenders a better chance. See our Third-Party Access Guide and CI/CD Pipeline Identity Security Guide.
Recommendations
- Know which vendors hold tokens to your code. Keep an inventory of tokens issued to or stored by third parties, with scopes and owners. See the Third-Party Access Guide.
- Issue vendors dedicated, narrowly scoped tokens. Avoid giving vendors tokens tied to individual employees or with organisation-wide reach.
- Set short lifetimes and rotate after vendor incidents. Rotate every token a vendor held as soon as it reports a compromise. See the Leaked Credential Response Playbook.
- Alert on bulk repository cloning. Unusual clone activity, especially outside working hours, should page someone.
- Keep secrets out of repositories. Even without customer data, private code can hold credentials. See our Secrets Management Guide.
Frequently asked questions
What happened in the Slack GitHub breach?
An attacker used a limited number of stolen Slack employee tokens to access Slack's externally hosted GitHub account and download private code repositories on 27 December 2022.
Was Slack customer data affected?
No. Slack said the downloaded repositories did not contain customer data, means to access customer data or its primary codebase, and that production was not accessed.
How were the Slack tokens stolen?
Slack said a third-party vendor was compromised. It has not named the vendor or explained exactly how the tokens were taken.
Related NHI Mgmt Group resources
CircleCI Breach 2023 · GitHub OAuth Token Breach 2022 · Third-Party Access Guide · CI/CD Pipeline Identity Security Guide · Leaked Credential Response Playbook
How NHI Mgmt Group can help
Tokens held by vendors are among the hardest credentials to see and govern. We help organisations build an inventory of third-party tokens, set scope and expiry rules and prepare fast rotation for vendor incidents. See our NHI and AI agent security training.
References
- BleepingComputer: Slack's private GitHub code repositories stolen over holidays (5 January 2023)
- Security Affairs: Threat actors stole Slack private source code repositories (5 January 2023)
- Slack: Slack security update, updated version (9 January 2023)