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.

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

October 2025


2. Who am I

Gianluca Varisco

<[email protected]>



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?