The invisible key: Securing the new attack vector of OAuth tokens

OAuth tokens are the new crown jewels. Once issued, they bypass MFA and give API-level access that is hard to monitor. The opaque nature of their use and the difficulty in monitoring their activity create a dangerous blind spot for security teams, making them a primary target for attackers. This presentation will delve into the lifecycle of OAuth tokens, explore real-world attack vectors, and provide actionable strategies for protecting these high-value assets. We will also review the tactics, techniques, and procedures (TTPs) of notorious gangs like ShinyHunters and Scattered Spider, as demonstrated in the 2025 Salesforce attacks.

Transcript

1. The invisible key: Securing the new attack vector of OAuth tokens
 October 2025

2. Who am I
 Gianluca Varisco
 <gianluca@netsec.it>
 
 Currently: 
 CEO, Netsec 
 
 Former:
 • Security & OCISO @ Google Cloud
 • CISO @ Arduino
 • CISO @ Digital Transformation Team (Italian Government)
 • CISO @ Rocket Internet
 • Engineer @ Red Hat
 • Engineer @ Lastminute.com Group
 

3. “Hackers don’t break in, they log in.”
 
 Corey Nachreiner | CSO, WatchGuard Technologies

4. Agenda (45 mins)
 1. OAuth (2.0) 101
 2. The blind spot: Why tokens are a perfect target
 3. Threat Actor TTPs: How gangs like Scattered Spider and ShinyHunters steal data
 4. Actionable defense: Strategies for visibility, control, and response
 5. Q&A

5. OAuth (2.0)
 101

6. What is OAuth 2.0?
 OAuth (Open Authorization) is an authorization framework used to delegate the user authentication to third party applications.
 
 

7. How does OAuth 2.0 works
 Four roles
 
 • Resource owner
 • Client
 • Resource server
 • Authorization server

8. An efficient (and very powerful) architecture
 Source: AppOmni
9. How does OAuth 2.0 works
 To generate trust between the authorization/resource server and the client, you must register your application first.
 Once you register your app in the authorization server, this gives a pair of OAuth keys:
 - Client ID
 - Client Secret

10. OAuth 2.0 - Grant Types
 Four flows to get an access token (grant types):
 
 1. Authorization Code Flow
 2. Implicit Flow with Form Post (e.g. SPAs)
 3. Resource Owner Password Flow
 4. Client Credentials Flow (M2M comms)

11. OAuth 2.0 vs OpenID Connect (OIDC)
 OAuth 2.0 is not an authentication protocol.
 
 It’s a framework designed to support the development of authentication and authorization protocols. 
 It provides a variety of standardized message flows based on JSON and HTTP;
 OpenID Connect uses these to provide authentication (it utilizes an additional token, called the ID token; it also adds structure to the scopes and claims).

12. OAuth 2.0 Playground

13. AuthPlay.io

14. The blind spot: Why tokens are a perfect target

15. “OAuth tokens and third-party integrations have become the backbone of productivity and connectivity as SaaS apps become the operating system of modern business. Yet behind this convenience, OAuth tokens often introduce hidden security risks that can compromise sensitive company data, expose critical systems, and increase the risk of data breaches.”
 Source: AppOmni
16. The security blind spot: Why is this so hard?
 You can’t secure what you can’t see.
 
 • Opaqueness: Tokens are often opaque strings. Without introspection, you don’t know the user, scopes, or expiry.
 • Monitoring gap: Traditional tools (FWs, WAFs, etc.) see API calls, but they lack the context of the token’s identity and permissions. Is this a legitimate script or an attacker?
 • Decentralization: Tokens are issued by one service (e.g. Okta, Google) and consumed by hundreds of others.
 • Hard to contain/restrict: Conditional access or zero-trust network controls don’t apply cleanly to tokens once issued — they bypass network and device context.

17. The attacker’s value proposition
 • Direct API access: No need to navigate a clunky UI. Attackers can use scripts for mass data exfiltration (e.g., download all emails, files, or contacts).
 • Persistence: A stolen refresh token can provide access for months or even years if not detected. 
 • Stealth: API activity can look like legitimate application traffic, making it incredibly difficult to detect among millions of legitimate calls.

18. The star of the show: the token lifecycle
 • Access Token: Short-lived, used to access the API. Like a ticket for one movie.
 • Refresh Token: Long-lived, used to get new access tokens. Like a subscription pass to the whole cinema.
 • Crucial Point: The refresh token is the ultimate prize for an attacker.
 Source: Stateful.com
19. The hidden risks lurking in OAuth workflows

20. The hidden risks lurking in OAuth workflows
 Token longevity and forgotten access
 Token leakage
 Overbroad scopes and privilege creep
 Revocation gaps and offboarding failure
 Supply chain risk: the domino effect

21. Examples of attacks
 Silent email takeover
 Mass data exfiltration
 Privilege escalation and shadow admins

22. How tokens are stolen - Common vectors
 1. Illicit consent grants: Tricking users into authorizing a malicious third-party OAuth app.
 2. Phishing for sessions: Stealing session cookies which can then be used to access tokens.
 3. Token leakage in source code (the biggest leaker): Tokens accidentally committed to public or private repositories (e.g. GitHub). 
 4. Malware / Infostealers: Exfiltrating tokens stored insecurely in browser local storage, config files, or developer environments.
 5. Redirect URI hijacking: Exploiting misconfigured applications to intercept the authorization code.
 6. Forged tokens: If an attacker compromises an Identity Provider or its signing certificate, they can mint new tokens that appear fully valid, effectively bypassing all token checks.

23. UNC6395 stolen OAuth tokens abused for SaaS-to-SaaS compromise
 Source: AppOmni
24. Commvault supply‑chain breach
 Source: AppOmni
25. GitHub OAuth consent phishing

26. GitHub OAuth consent phishing

27. How 30+ popular Chrome extensions got hacked through a clever OAuth phish
 Source: Cyberhaven
28. Double-clickjacking: Bypassing browser defenses with two deceptive clicks
 Source: Paulos Yibelo
29. Threat Actor Spotlight
 Scattered Spider 
 and 
 ShinyHunters

30. Scattered Spider (UNC3944)
 A financially-motivated threat actor characterized by its persistent use of social engineering and brazen communications with victims. Known for social engineering, SIM swapping, and identity-focused attacks. Their goal is initial access and persistence.
 
 
 
 Source: Mandiant
31. ShinyHunters (UNC6040 and UNC6240)
 A prominent cybercriminal group, also linked to Scattered Spider, specializing in large-scale data breaches and the exfiltration of sensitive data for financial gain. 
 The UNC6395 campaign resulted in the largest SaaS compromise in history, affecting over 700 organizations. Using the stolen tokens, ShinyHunters exfiltrated approximately 1.5 billion data records from 760 companies, including major tech firms like Cloudflare, Zscaler, and Palo Alto Networks.
 Attack Vector #1: Social Engineering 
 Attack Vector #2: Stolen 3rd-party Tokens
 Record-Breaking Impact

32. UNC6240 Salesforce vishing (voice phishing) campaign

33. UNC6240 Salesforce vishing campaign
 Source: Cloudprotection
34. UNC6240 Salesforce vishing campaign
 Source: Cloudprotection
35. UNC6240 Salesforce vishing campaign
 Source: Cloudprotection
36. UNC6240 Salesforce vishing campaign
 Source: Cloudprotection
37. Case Study: The 2025 Salesforce Attack (08/2025)
 What would this attack have looked like in the logs?
 
 
 
 
 
 • Massive API query volume from a single token. 
 • Access to endpoints or data unusual for the associated user/application.
 • Anomalous refresh token usage (e.g., from a new/suspicious IP address, ASN, or User-Agent). 
 • Rapid succession of token issuances.
 Identity Provider Logs 
 (e.g. Azure AD, Okta)
 API / Application Logs 
 (e.g. Salesforce Event Monitoring)

38. Salesloft Drift breach - August 2025
 How a simple social engineering attack led to a catastrophic data breach. It unfolded in several layers:
 Initial compromise of Drift OAuth tokens
 Mass querying of Salesforce objects (Account, Case, User, Opportunity)
 Harvesting of embedded secrets (AWS keys, Snowflake tokens, VPN URLs)
 Lateral expansion into Drift Email → Google Workspace accounts. 

39. Salesloft Drift breach - Attack Flow
 1. Compromise trusted third‑party (Drift) and harvest OAuth tokens. 
 2. Authenticate to Salesforce via valid tokens; enumerate and bulk‑query core objects. 
 3. Mine embedded secrets from exports; operationalize access to cloud/data platforms. 
 4. Pivot via Drift Email into scoped Google Workspace accounts; expand blast radius.
 Source: SlashID
40. Salesloft Drift breach - Timeline
 Initial compromise of Salesloft GitHub repo
 Earliest Drift Token Abuse
 Last confirmed data theft activity
 GTIG publishes analysis
 March - June
 August 8
 August 18
 August 26
 Source: SlashID
41. Salesloft Drift breach - App scopes
 Source: SlashID
42. Salesloft Drift breach - Initial access
 Mandiant’s investigation has since clarified that between March and June 2025, the threat actor accessed Salesloft’s GitHub account, where they downloaded repositories, added a guest user, and established workflows. 
 This activity led to Drift’s AWS environment being accessed, which ultimately gave the attackers OAuth tokens for Drift customers’ integrations. So, this was how the Drift OAuth tokens were compromised.
 Source: SlashID
43. Salesloft Drift breach - Salesforce access & data harvesting
 Attackers then started to perform recon in the environment. Based on Cloudflare’s public write-up, we know that attackers would perform the following actions:
 
 
 Source: SlashID, Mandiant, Cloudflare Send a GET request for a list of objects in the Salesforce tenant: 
 /services/data/v58.0/sobjects/ 
 Send a GET request for metadata information for case objects in the Salesforce tenant: 
 /services/data/v58.0/sobjects/Case/d escribe/

44. Salesloft Drift breach - Salesforce access & data harvesting
 Source: SlashID, Mandiant SELECT COUNT() FROM Account; 
 SELECT COUNT() FROM Opportunity; SELECT COUNT() FROM User; 
 SELECT COUNT() FROM Case;
 A series of systematic SOQL queries
 SELECT Id, Username, Email, FirstName, LastName, Name, Title, CompanyName, Department, Division, Phone, MobilePhone, IsActive, LastLoginDate, CreatedDate, LastModifiedDate, TimeZoneSidKey, LocaleSidKey, LanguageLocaleKey, EmailEncodingKey FROM User WHERE IsActive = true ORDER BY LastLoginDate DESC NULLS LAST LIMIT 20;
 They pulled full User tables, complete with emails, names, phone numbers, and login timestamps

45. Salesloft Drift breach - Secret mining & covering tricks
 After exfiltrating the bulk Salesforce data, they hunted for secrets, tokens, etc. to extend their compromise beyond Salesforce. Likely techniques:
 
 
 
 
 
 Common patterns:
 Source: SlashID, Mandiant Regex scrapers for known credential formats.
 TruffleHog / Gitleaks‑style scans for entropy‑heavy strings, AWS patterns, API key regexes.
 AKIA[0-9A-Z]{16} # AWS Access Key 
 snowflakecomputing\.com # Snowflake domain references 
 (password|secret|key)\s*[:=] # Generic key-value credential markers

46. Salesloft Drift breach - Drift Email -> Google Workspace
 UNC6395 didn’t stop at Salesforce. They realized that OAuth trust relationships through Drift could extend into other ecosystems — and the Drift Email integration was the next pivot.
 • Aug 9, 2025: Using compromised Drift OAuth tokens tied to Drift Email, attackers gained scoped access to a subset of Google Workspace accounts integrated with Drift (not domain‑wide; only explicitly connected accounts). 
 • Aug 28, 2025: Google revoked affected OAuth tokens and disabled the Drift Email integration, cutting off this pivot.
 Source: SlashID, Mandiant
47. Salesloft Drift breach - Covering tracks, but..
 • Deleting jobs: Attackers deleted query jobs after exfiltration to make it harder for incident responders to quickly see “large export jobs” or unusual query activity.
 
 • Leaving footprints: Even though the job objects were removed, the underlying event logs persisted.Salesforce logs record the fact that queries were run, including timestamps, User-Agent strings, and IP addresses.
 Source: SlashID
48. Actionable Strategies for visibility, control, and response

49. Pillar 1 - Gaining visibility
 Audit OAuth Apps
 Centralize logs
 Detection rules
 Regularly review all third-party apps in your env. What permissions do they have? Are they verified? Remove unused or over-privileged apps.
 Ingest logs from your IdP, cloud providers, and key SaaS applications into your SIEM.
 Build alerts for the IoCs discussed earlier

50. Pillar 1 - Deception: early, high-fidelity visibility
 What
 Where
 Detect
 Plant believable, fake OAuth artifacts that look real but are never used by production (canary tokens, fake redirect URIs, dummy client secrets, decoy config files).
 Public/private repos, CI/CD logs, artifact registries, developer VMs, partner app listings.
 Build alerts for the IoCs discussed earlier

51. Canarytokens.org

52. Pillar 1 - Deception: early, high-fidelity visibility
 Detection signals
 Automation playbook
 Example alert flow
 Auth header use of canary token; callback / authorization code exchange to honey redirect; introspection or mint attempts; git/blob access.
 Send high-priority to SIEM/SOAR with artifact context; revoke client/rotate secrets, block IPs, isolate hosts, snapshot for forensics; run attack path graph, rotate downstream credentials, notify affected teams
 Canary token used in Authorization header → SIEM alert → automation fetches repo commit metadata → auto-revoke OAuth client + block source IP → create incident ticket with owner and snapshot.

53. Pillar 2 - Proactive controls
 • Principle of Least Privilege: Enforce strict scopes. If an app only needs to read user profiles, don't grant it Mail.ReadWrite.All.
 
 • Token Configuration: 
 ◦ Use short-lived access tokens (e.g., 1 hour). 
 ◦ Enforce refresh token rotation and set sensible expiration policies. 

54. Pillar 2 - Proactive controls
 • Conditional Access: Bind token issuance to device state, location, and risk signals. A token should not be issued to an unmanaged device in a risky location.
 
 • Attack Path Graph: Visualize how a seemingly low-privilege or benign token can lead to privilege escalation, mapping the chain from a basic token to a high-value or admin token.

55. Conditional Access - Token protection
 Source: Microsoft
56. Microsoft’s Linkable token identifiers (now GA!)
 Source: Microsoft
57. Microsoft’s Linkable token identifiers - Flow diagram
 Source: Microsoft
58. How they are implemented using a Session ID across the logs.
 Source: Microsoft
59. How they are implemented using a Session ID across the logs.
 Source: Microsoft
60. Pillar 2 - Proactive controls - Okta’s response
 Source: Okta
61. Pillar 2 - Proactive controls - Okta’s response
 Source: Okta
62. Pillar 2 - Proactive controls - mTLS

63. Pillar 2 - Proactive controls - DPoP

64. Pillar 2 - Reducing the blast radius - IPSIE
 Two of the fundamental controls that are part of the IPSIE framework are particularly relevant to the Salesloft Drift incident:
 • Shared signals: This allows for real-time communication of security events between applications. For example, if a user's account is compromised in one application, that information can be instantly shared with all other connected applications, which can then take action to protect the user's data.
 • Token revocation: This provides a standardized way to revoke access tokens. In the case of the Salesloft Drift incident, if a token was known to be compromised, it could be instantly revoked across all integrated applications, severing the attacker's access.
 

65. Pillar 2 - Reducing the blast radius - CAEP
 Advanced: Continuous Access Evaluation Protocol (CAEP)
 • CAEP is a IETF standard developed to enable continuous evaluation of user access in identity and access management (IAM) systems. 
 • It ensures that access decisions are updated in real time based on changing risk signals, such as user location, device status, or security context. CAEP enables real-time access checks that adapt to potential threats as they emerge, which dramatically reduces an organization’s risk exposure.
 • CAEP plays a critical role in supporting Zero Trust principles by continuously reassessing a user’s access rights within a dynamic security framework.

66. Pillar 2 - Reducing the blast radius - Token Binding
 Advanced: Token Binding
 • Token binding is a technique where tokens are tied to specific client attributes or communication sessions. This prevents tokens from being used in contexts where they weren’t originally issued. 
 • For example, tokens could be bound to a particular client instance (e.g., a specific device or IP address). If the token is replayed by a different device or client, the authorization server can recognize this inconsistency and reject the request.
 

67. Pillar 3 - Incident response playbook
 When the alarm rings…
 • Step 1: Revoke! Immediately revoke the refresh token in the IdP. This invalidates all downstream access tokens. 
 • Step 2: Terminate Sessions: Force a global sign-out for the affected user. 
 • Step 3: Investigate: Analyze logs to determine the scope of the token's access. What APIs were called? What data was accessed?
 • Step 4: Remediate: Address the root cause (e.g., remove the malicious OAuth app, patch the vulnerable client).

68. Key takeaways
 • Treat OAuth Tokens as crown jewels: They are powerful, persistent credentials. 
 • Attackers are targeting them: They actively bypass MFA and live off the land using stolen tokens. 
 • Defense requires a new mindset: Shift from perimeter defense to identity-centric monitoring. 
 • Start now: Audit your applications, tighten your token policies, and build your detection rules today.

69. PortSwigger - Web Security Academy (Free!)

70. Credits 
 • Auth0 / Okta
 • AppOmni
 • SlashID
 • Google Threat Intelligence / Mandiant
 • WithSecure 

71. /in/gvarisco
 Thank You! Questions?