Salesforce Data Exfiltration Defense: A Post-Qantas Audit Protocol

On October 12, 2025, when the news broke that 5.7 million of Qantas’s customer records had been stolen, the cybersecurity community felt a familiar dread. But as the details of the incident report emerged, that dread turned into a sharp, urgent realization for every CISO and security architect. The breach wasn’t caused by a sophisticated zero-day exploit in the Salesforce platform itself. It wasn’t a sprawling phishing campaign that tricked hundreds of employees. The attackers didn’t need to break down the front door, because Qantas had, for all intents and purposes, given them a master key.

The threat group, identified by the FBI as UNC6395, had executed the breach by compromising a third-party marketing application connected to Qantas’s Salesforce environment. By stealing the OAuth access token associated with this trusted integration, they gained persistent, API-based access to Salesforce and began to exfiltrate millions of customer records, completely bypassing MFA and other user-centric security controls that Qantas had in place.​

This is the new, uncomfortable reality for every enterprise that has built its business on the Salesforce platform. If your security strategy for Salesforce still focuses exclusively on user profiles, permission sets, and MFA enforcement, you are defending against yesterday’s threats. The new battleground—the soft, undefended underbelly of your SaaS environment—is your SaaS supply chain. It is the sprawling, often un-audited web of third-party applications from the AppExchange that you have connected to your org.​

As a Salesforce Security Architect who has spent the last decade architecting defenses for Fortune 500 companies and responding to these exact types of breaches, I can state this unequivocally: we have become experts at locking down our human users, but we have failed to apply that same level of scrutiny to the non-human identities of the applications we connect to our orgs. Each of those apps—from marketing automation tools to data enrichment services—represents a persistent, often overly-permissive, API-based connection directly to your most sensitive data. It is a backdoor that we installed ourselves.​

“Your Salesforce data is only as secure as the least secure application you have connected to it. Trust is not a default setting; it is a state that must be continuously verified, audited, and enforced.”

Phase A: Discovery & Enumeration – Mapping Your True Attack Surface

You cannot defend what you cannot see. Your first mission is to create a complete and accurate inventory of every single application that has been granted access to your Salesforce org. Many teams are shocked to find dozens or even hundreds of legacy, forgotten, or user-installed apps with active connections.

Table 1: Application Discovery & Inventory Methods

Discovery Method	Location in Salesforce	Key Information to Collect & Why It Matters
Connected Apps OAuth Usage	Setup > Apps > Connected Apps > Connected Apps OAuth Usage	User Count & Last Used Date: Identify “orphaned” apps that are still authorized but no longer in use. These are prime targets for hijacking. Refresh Token Policy: Note if the policy is set to “Refresh token is valid until revoked.” This creates a perpetual token an attacker can use indefinitely.
API Usage (via Event Monitoring)	Event Monitoring Analytics App > API Event Log File	User, Client IP, API Type, Queried Objects: This is your ground truth. It shows which apps (via their connected user) are actually accessing what data. Look for unexpected API clients or apps querying objects they shouldn’t be.
User Login History	Setup > Identity > Login History	Login Type & Application: Filter for “Remote Access Client” or “OAuth” login types. This can reveal API-only access that doesn’t show up in the standard user interface logs.
Manual Integration Review	Interview leaders in Marketing, Sales, and Support.	Vendor Name & Stated Purpose: Many integrations (e.g., Salesloft, Drift) are configured by business departments, not IT. You must manually inventory these and compare their stated purpose to the permissions they actually have​.

Phase B: Permission & Risk Analysis – Scrutinizing the “Keys to the Kingdom”

Once you have your inventory, you must analyze the permissions (OAuth scopes) that each application has been granted. The goal of an attacker is to find an application with overly broad scopes, which they can then abuse to access data far beyond the app’s intended function.

Table 2: High-Risk OAuth Scopes and Their Business Impact

OAuth Scope	Technical Permission Granted	Attacker’s Objective & Business Risk
full	“Full access on behalf of the user”	Total Account Takeover. The attacker can do anything the user can do via the UI or API, including impersonating them, deleting data, or changing settings. This is the most dangerous scope.
api	“Access user data via APIs”	Mass Data Exfiltration. The attacker can use tools like Data Loader or custom scripts to systematically download all customer, contact, opportunity, and custom object data the user has access to​.
web	“Access via the web interface”	Silent Web Session Hijacking. The attacker can use the token to maintain a web session, allowing them to browse Salesforce as the user, even if the user is not logged in.
refresh_token, offline_access	“Obtain a new access token without re-authentication”	Perpetual Persistence. This is the key to a long-term compromise. Even if the user’s password is changed, the attacker can use the refresh token to generate new access tokens and maintain their access indefinitely.

Phase C: Hardening & Remediation – Locking the Digital Gates

Discovery and analysis are useless without action. This phase focuses on systematically reducing the attack surface by revoking unnecessary access and enforcing stricter policies.

Table 3: The App-Centric Hardening Protocol

Control Category	Hardening Action	Implementation Steps & Rationale
Access Control	Enforce IP Range Restrictions	Setup > Manage Connected Apps > [App Name] > Edit Policies > IP Relaxation: Enforce IP restrictions. For apps that should only be accessing Salesforce from a known server (e.g., a marketing automation platform), this is a critical control. It prevents an attacker from using a stolen token from an arbitrary location.
	Revoke Unused & Orphaned Tokens	Setup > Connected Apps OAuth Usage > Revoke. Any application with a “User Count” of zero or a “Last Used Date” older than 90 days should have its tokens revoked immediately. This cleans up legacy risk. This can and should be scripted via the Salesforce API for automation.
Policy Enforcement	Block Unvetted Apps by Default	Setup > Connected Apps > Manage Connected Apps > Block. Change the org-wide setting to block all new applications by default. You can then explicitly “Install” or “Allow” specific, vetted applications. This moves you from a “default allow” to a “default deny” posture.
Session Management	Enforce Short-Lived Sessions for High-Privilege Users	Setup > Session Settings > Timeout Value. For profiles with high privileges (e.g., System Administrator), create a separate session profile with a much shorter timeout (e.g., 2 hours). This limits the window an attacker has to hijack a privileged session.
User Permissions	Restrict the “Manage Connected Apps” Permission	This permission allows a user to authorize new apps and modify their policies. It should be removed from all standard administrator profiles and restricted to a small, dedicated “SaaS Security” or “Integration Architect” profile.

From Reactive Audit to Continuous Defense

You have now walked through the core components of a modern, app-centric Salesforce security program. You’ve moved beyond simply trusting the AppExchange security review and have implemented a process to verify those trust assumptions yourself. You now have a repeatable methodology to enumerate every connected application, dissect its OAuth scopes to understand its true permissions, and identify and neutralize high-risk integrations before they can be weaponized.

By implementing this protocol, you have fundamentally shifted your defensive posture from a reactive, user-focused model to a proactive, app-focused one.

• You have mastered using the Setup Audit Trail to hunt for the subtle signs of defense evasion, such as a malicious actor enabling public sharing links to create an anonymous exfiltration path (Action: chatterFileLinkOffOn).​
• You have established a process for using Salesforce Shield’s Event Monitoring to create alerts for anomalous ReportExport events or high-volume ApiTotalUsage events, which are the key indicators of an active data exfiltration attempt.​
• Most importantly, you have learned to apply the Principle of Least Privilege not just to your human users, but to the non-human identities of your installed applications, ensuring they can only access the data they absolutely need to function.​

The Qantas breach, and the wider wave of Salesforce-related incidents in 2025, were a brutal but necessary wake-up call. They proved that a pre-authorized OAuth token in the hands of a determined attacker is infinitely more valuable—and more dangerous—than a single stolen user password. Your response, therefore, cannot be a one-time audit. It must become a core, continuous function of your security program.​

The End State: A Zero Trust Architecture for Your SaaS Supply Chain
Your ultimate goal is to build a “Zero Trust” model for your entire application ecosystem. Every new application that requests access to your Salesforce org must be treated as untrusted by default.

• Its permissions must be scrutinized: Does a simple calendar integration really need the “Modify All Data” permission?
• Its access must be restricted: Can you limit its API access to a specific set of known IP addresses owned by the vendor?
• Its activity must be monitored: Do you have a baseline of its normal API usage, and an alert in place to detect if it deviates from that baseline?

This is the only sustainable strategy for securing your data in an interconnected world where your most critical infrastructure is inextricably linked to dozens of external vendors. As a security leader, your role has evolved. You are no longer just the builder of fortress walls; you are the manager of a complex web of digital trust. Take control of your connected apps, and you take control of your data.

Salesforce Data Exfiltration Defense: The FAQ

1. What was the core attack vector in the recent Salesforce breaches (like at Qantas)?
   The attackers did not breach Salesforce’s core platform. Instead, they compromised a trusted, third-party application (like Salesloft Drift) and stole the OAuth access tokens that the app used to connect to its customers’ Salesforce orgs.valencesecurity​
2. Why is a stolen OAuth token so dangerous?
   Because it allows an attacker to access Salesforce via the API while completely bypassing user-centric defenses like Multi-Factor Authentication (MFA). The token itself is proof of authentication, so no password or MFA prompt is triggered.valencesecurity​
3. What is the “SaaS supply chain” and why is it a risk?
   Your SaaS supply chain is the entire ecosystem of third-party applications (e.g., from the AppExchange) that you have connected to your Salesforce org. Each app is a potential weak link; a breach at that third-party vendor can lead directly to a breach of your Salesforce data.blackfog​
4. What is the first step I should take to assess my risk?
   You must create a complete inventory of every application connected to your Salesforce org. Navigate to Setup > Connected Apps OAuth Usage to see a list of all authorized apps, how many users are using them, and when they were last used.varonis​
5. What is an “orphaned” or “stale” app assignment?
   This is an application that remains authorized in your org but is no longer actively used by any employees. These are prime targets for attackers because their API activity is not monitored, yet they may still have valid, powerful OAuth tokens.
6. What is the single most dangerous permission (OAuth scope) an app can have?
   The full scope. It grants the application the ability to do anything the connected user can do, effectively allowing for a full account takeover via the API. This scope should be scrutinized heavily and rarely granted.
7. What’s the difference between the api and web scopes?
   The api scope allows the app to access data programmatically (e.g., download reports). The web scope allows it to maintain a UI session, essentially browsing Salesforce as the user. Both are powerful and potentially risky.
8. What is a “refresh token” and why does it matter?
   An access token is typically short-lived. A refresh token is a special token that an application can use to obtain a new access token without requiring the user to log in again. If an attacker steals a refresh token, they can maintain persistent access to your org for a very long time.salesforceben​
9. How can I find out what data an application is actually accessing?
   Use Salesforce Shield’s Event Monitoring. The API Event or ApiTotalUsage event log files will show you which applications are making API calls, which objects they are querying, and the volume of data being accessed. Anomaly detection here is key.salesforce​
10. How do I stop an application from being used outside my corporate network?
    For any connected app, you can enforce IP Range Restrictions. Go to the app’s policy page and enter the known IP ranges of the vendor’s servers. This prevents an attacker from using a stolen token from an arbitrary IP address, like a Tor exit node.salesforce​
11. What is the best practice for managing new app installations?
    Implement a “default deny” posture. In Setup > Manage Connected Apps, you can block new, unvetted applications from being installed by users. This forces all new integrations to go through a formal security review.
12. Can attackers hide their tracks after exfiltrating data?
    Yes. In the recent breaches, threat group UNC6395 was observed deleting the query job records to try and hide which reports they had exported. However, the underlying Salesforce event logs were not impacted, so a thorough forensic investigation could still find them.cloud.google+1​
13. What is Salesforce Shield and do I need it?
    Salesforce Shield is a suite of premium security products that includes enhanced Event Monitoring, Platform Encryption, and Field Audit Trail. For any enterprise with sensitive data, the detailed logs provided by Event Monitoring are essential for detecting the kind of API-based exfiltration seen in recent attacks.salesforce​
14. My company uses sandboxes. Are they a risk?
    Yes, if not managed correctly. A common and dangerous misconfiguration is allowing production data to be copied into a developer sandbox. Sandboxes often have weaker security controls, creating a soft target for attackers to access sensitive data.varonis​
15. Besides apps, what’s another common way attackers exfiltrate data?
    By compromising a user with high privileges and using the native Data Loader tool. This is why monitoring for anomalous data exports (e.g., a user exporting millions of records at 3 AM) via Event Monitoring is so critical.mitiga​
16. How does social engineering play into these attacks?
    Threat actors like Scattered Spider often use social engineering to target IT help desks, convincing them to reset a user’s password and MFA device. They often target “frozen” but not deactivated admin accounts, which retain their full permissions upon reactivation.varonis​
17. What is the “Principle of Least Privilege” for apps?
    It means an application should only be granted the absolute minimum permissions (OAuth scopes) required for it to perform its stated business function. If a marketing app only needs to read Campaign and Lead objects, it should not have the “Modify All Data” permission.laconfianzatech​
18. How often should I audit my connected apps?
    A full audit should be conducted at least quarterly. You should also have a process to review any apps with high-risk permissions on a monthly basis. This should be a continuous process, not a one-time project.
19. What is the first thing I should do if I suspect an app has been compromised?
    Go to Setup > Connected Apps OAuth Usage and click “Revoke” for that application. This will immediately invalidate all its active tokens and block it from accessing your org. This is the critical first step in containment.
20. Is this a Salesforce vulnerability? Should we stop using Salesforce?
    No. In the major 2025 breaches, this was not a vulnerability in the core Salesforce platform. It was a failure in the SaaS supply chain—the trust relationship between a customer and a third-party app vendor. The solution is not to abandon the platform, but to adopt a Zero Trust mindset and rigorously manage the security of every single application you connect to it.valencesecurity​