The source of the compromised data, Salesloft explained, was a stolen GitHub account, which gave hackers an entry point to the company’s Drift platform, a chat bot and marketing automation product used by some of the largest companies in the world.Authorities were called, “and we were assured that based on the investigation to date, the data was not accessed,” he told me.
What Salesloft says happened
Per Mandiant, the company’s incident response (IR) partner, unauthorized access was obtained in Salesloft’s GitHub environment and reconnaissance occurred over an extended period of time. During that time, the attackers took downloaded code and configuration content from several repositories, added a guest user, and set up new workflows — changes that are in line with an initial compromise with the flow-on effects of broader access and persistence.

Salesloft calls the incident contained. The extended activity window does bring some very uncomfortable questions around monitoring coverage, alert fidelity, and the response time for odd identity-based activity (think new guest additions, work flow modifications), that are triaged inside modern DevOps pipelines.
From GitHub to Drift: bunk tokens as attack surface
Researchers believe GitHub access was used to pivot onto the Amazon Web Services environment that operates Drift. Attackers then used that access to steal customer OAuth tokens that Drift customers use to link Drift to other systems, such as Salesforce and other business platforms. Since OAuth gives scoped access without the need to provide a password for each call, the owner of stolen tokens can replay them for the period until revoked, or expired – quite a stick to wield in a supply‑chain use case.
That trend is in line with both an industry-wide move: rather than brute force the front door, adversaries are increasingly working to harvest cloud and integration credentials. In at least these high-profile cases, abused OAuth tokens served as the fulcrum that converted a single-vendor compromise into a multi-customer problem.
Who was affected, and what was taken
Salesloft said that attackers had used the stolen tokens to log in to some customers’ Salesforce instances and that they had extracted data contained in support tickets. Not all organizations experienced the same impact, but the company said that the actors were looking for credentials and other high‑value secrets such as AWS access keys, passwords, and Snowflake related tokens.
“Appear to have been targeted” organizations listed include Bugcrowd, Cloudflare, Google, Proofpoint, Palo Alto Networks, and Tenable, among others, with additional names potentially to be added as more is learned in ongoing investigations. Salesloft said its integration with Salesforce is back online after containment and revocation of affected tokens.

Attribution and extortion claims
The broader campaign was attributed by Google’s threat intelligence team to a group whom it tracks as UNC6395. Separately, cybersecurity outlets DataBreaches. net and Bleeping Computer reported connections to the ShinyHunters collective, which has engaged in data theft and extortion. Victims are said to have are being privately contacted by the attackers in extortion attempts, a trend which has come to the fore as perpetrators mix intrusion, data theft and pressure into a cocktail of ransom demands.
Why the timeline matters
Increased time within a code hosting environment multiplies risk: there are repositories with secrets embedded in them, or CI/CD tokens, or workflow definitions with open doors in other places. The Cost of a Data Breach report from IBM Security has been warning for years that companies, on average, spend the better part of nine months to identify and contain breaches — plenty of time for patient attackers to move laterally and obfuscate their tracks.
GitHub has upped its baseline defenses — including requiring two_factor authentication for offering push access, fine grained personal access tokens, and alerts when it detects your keys in secrets scanning —but these controls only pay off when organizations implement them opaquely, continuously watch audit logs for anomalies, and restrict token scopes, and lifetimes of their tokens.
What organizations should be doing now
For customers using Drift or any connected service, immediate action should be to rotate all OAuth tokens and connected app credentials, review Salesforce audit logs for any suspiciously active APIs, and clean support tickets of any accidentally stored secrets. apply least‑privilege ranges, short lifetimes, and auto‑revocation to all tokens.
On the engineering front, mandate SSO and phishing‑resistant MFA for GitHub, limit guest access, and monitor continuously for new users, workflow changes and repository exfiltration. Turn on organization-level secret scanning, scan CI/CD pipelines for embedded credentials, and never put environment variables or cloud keys into your code. In cloud, rotate your IAM keys, implement anomaly detection for token usage, and quarantine credentials impacted from tickets or logs.
The Salesloft–Drift episode is a stark warning: when a vendor’s dev environment is the first domino to fall, the blast radius can quickly extend into customers’ core business systems. Hardening identity, reducing token lifetimes, and monitoring the seams between code, cloud, and SaaS are no longer nice‑to‑haves — they’re the control points that determine whether a single compromise will lead to an ecosystem wide breach.