OAuth Forensics After ShinyHunters: When Consent Becomes the Breach
21.07.2026 oauthsaas-forensicssalesforcecloud-identity
A Year of Invisible Access: The ShinyHunters Campaign Against Salesforce
On July 13, 2026, Microsoft published an analysis that should give every SaaS security team pause: the data-extortion group ShinyHunters had spent a full year compromising Salesforce environments without exploiting a single flaw in the platform. The way in was the trust the organization had already extended, usually through the OAuth connections that tie Salesforce to the apps and third-party vendors around it. For DFIR practitioners, this is a wake-up call: when an attack looks identical to legitimate usage, classical detection fails — and forensic reconstruction has to start from artifacts nobody was watching.
Microsoft mapped three parallel intrusion paths. The first path, which kicked off the entire campaign in mid-2025, involved vishing calls in which attackers posed as IT support and talked employees through Salesforce’s OAuth consent screen to authorize an attacker-controlled connected app disguised as the Data Loader tool. Once consent was granted, the app could make API calls as that user, enumerate the org’s Salesforce data, hold persistent access, and hunt for credentials to other SaaS platforms. No malware, no stolen password replay — just a phone call and a consent click.
The second path targeted the supply chain: Salesloft traced the root cause to the attacker’s access to its GitHub account as early as March 2025, used to reach Drift’s AWS environment and harvest tokens. The operators were there for secrets, running SOQL queries to sift through support cases for AWS keys, Snowflake tokens, and passwords, then deleting their query jobs to slow down anyone investigating. That deletion of job metadata is the crux of the forensic problem: it strips responders of precisely the artifacts needed to reconstruct exfiltration in the first place.
Why Classic Log Analysis Falls Short
This is what makes it hard to catch: when access comes from a real user who approved a connected app, or from an integration the company already trusts, the traffic reads as ordinary use, and sign-in and authentication monitoring barely registers it. One threat-intel profile sums up the forensic reality bluntly: forensic artifacts are limited to OAuth token audit logs, Salesforce connected app records, and API access histories.
The scale of the cascade shows this is far more than a Salesforce problem: Google estimated the Drift token theft potentially exposed more than 700 organizations, among them Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, PagerDuty, and Tanium; Google tracks the cluster as UNC6395, Cloudflare’s Cloudforce One calls it GRUB1. A second wave hit the Gainsight integration in November 2025: Salesforce pulled Gainsight-published apps after spotting unusual API activity, and GTIG tied the campaign to ShinyHunters affiliates across more than 200 affected Salesforce instances. By June 2026, the Klue case followed, in which attackers got in through a long-disused but still-active legacy credential from a test integration that was never deployed, pushed a code update that harvested customers’ OAuth tokens, and used those to reach Salesforce and Gong data belonging to Klue customers, including Huntress and Recorded Future. Microsoft tracks the Klue actor as Storm-3138.
Forensic Implications and Recommendations
For incident responders, this represents a paradigm shift: instead of hunting login anomalies, the focus must move to connected-app inventories, token scopes, and API usage patterns. Microsoft and Salesforce responded with expanded telemetry — working together to roll out new detection and governance tooling aimed at addressing the activity authentication logs miss. Concrete guidance includes implementing robust identity verification procedures for IT support interactions, considering additional controls such as OAuth app whitelisting and step-up authentication for sensitive operations, and ensuring logs are retained and analyzed for signs of compromise.
In practice, this means documenting connected-app permissions before any incident occurs, archiving API event logs well beyond the statutory minimum retention window, and building token revocation into every containment playbook as a first-hour action — because when the attacker’s very first move is to erase the evidence, every minute before the incident counts more than the ones after it.
← Back to overview