Protect against OAuth Attacks in Salesforce with Microsoft Defender

An ongoing campaign of security incidents has been observed across multiple large enterprises, involving unauthorized access to the organizational Salesforce CRM systems using OAuth applications - resulting in data breaches and exfiltration - underscore both the escalating pace of cloud-based attacks and the importance of addressing SaaS application security. In response, Salesforce has started to enforce improved OAuth app blocking policies.  

The activity has been partially attributed to a threat actor publicly dubbed and known as ShinyHunters, which led to breaches at multiple global firms. These incidents demonstrate how OAuth trusts can be weaponized: attackers use OAuth-based attacks because they can bypass traditional security controls focused on devices, are difficult to detect, and provide direct access to business-critical systems such as CRM and Support systems which often may enable attackers to extract additional tokens for other SaaS applications for further lateral movements. 

Based on the information and intel observed so far, there are two recent campaigns both focused to target Salesforce instances of multiple large organizations in different ways and with different intrusion techniques. The first wave of attacks (disclosed earlier in June 2025) seems to be based on social engineering and vishing to abuse permissions through a modified version of Salesforce Data Loader application; the second, more recent campaign surfaced during end of August 2025, instead seems to originate from a separate security incident reported by Salesloft Drift vendor and affecting their cloud application integrated with Salesforce. 

In this blog post, we will delve only into the earlier Salesforce OAuth attack campaign and provide guidance on how organizations can use Microsoft Defender to protect against this and similar SaaS attack campaigns. Specifically, we will:  

1. Break down the earlier Salesforce OAuth attacks abusing a modified Data Loader application 
2. Demonstrate how Defender capabilities can detect and discover intrusions 
3. Provide an overview of analyst investigation tools in Defender 
4. Highlight response actions available to contain the threat and harden your organizational security posture 

Attack overview – OAuth consent phishing 

This attack combined social engineering tactics with OAuth abuse to steal data and extort victims. Unlike malware-based intrusions, this campaign relied on exploiting the OAuth authorization flow of a trusted SaaS service. Below is an overview of how the attack unfolded and its high impact: 

Figure 1: Attack chain illustration

Phase 1: Initial vishing contact 

The attack began with a phone call. Posing as IT support—sometimes even claiming to be from Salesforce—threat actors contacted company employees under the guise of resolving a “support ticket” or other urgent issue. The goal was simple: build trust and prepare the victim to follow instructions.

Phase 2: Malicious OAuth app consent 

Once trust was established, the caller guided the victim to Salesforce’s Connected Apps page and instructed them to enter a special “connection code.” Unbeknownst to the user, this code corresponded to a malicious OAuth app-controlled registration by the attackers—a malicious version of the Salesforce Data Loader tool. By granting consent, the victim unknowingly gave the attackers OAuth access to their Salesforce data.  

Fig. Registering new OAuth app, Salesforce

Fig. Registering new OAuth app, Salesforce

Figure 2: OAuth registered apps, Salesforce, admin page

Phase 3: Data exfiltration and lateral movement 

After obtaining the OAuth refresh token from the connected app, the attackers exploited it to query and download large amounts of Salesforce CRM data such as customer information, support tickets and sales records. In some cases, the exfiltration began during or right after the call—so quickly that security teams initially didn’t realize an attack had occurred. All data requests appeared as legitimate API calls from an authorized app, helping the attackers blend in.  

Additionally, the attackers often collected the user’s login credentials and MFA codes during the call under the guise of ‘verification.’ Using the stolen credentials (for providers like Okta), the threat actors demonstrated a form of “lateral movement” to other SaaS apps—like accessing Office 365 mailboxes, file storage services, or Slack—to steal additional data and expand their foothold. 

Figure 3: How the malicious OAuth was used in this attack, Illustration

Phase 4: Extortion and threats

With the valuable data in hand, the threat actor moved to extortion. They contacted the company, demanding ransom payments (often in cryptocurrency) under threat of leaking the stolen data publicly. In some cases, they falsely claimed ties to other notable extortion groups to pressure victims. If a victim refused to pay, the group would follow through by posting the data online or in dark web marketplaces. This double-pronged impact—data breach and public leak—put organizations in a vulnerable position. According to reports, the attackers primarily relied on email-based extortion rather than immediate data dumps, but the constant risk of a large-scale leak kept victims on edge. OAuth application supply chain attack  

Recent (August 2025) attacks

While organizations responded to the above-mentioned consent attacks involving Data Loader application, major firms reported later another wave of OAuth app-based attacks targeting Salesforce instances of the victims. In this second campaign, the threat actors leveraged compromised OAuth tokens potentially captured from the Salesloft Drift app, a third-party Salesforce integration for automating sales workflows, to gain unauthorized access to hundreds of Salesforce environments. As the investigation on these attacks continue and it’s evolving, the key insight is the unusual spike in Salesforce API activities and access anomalies in the victim organizations during the attack. 

Protect with Defender  

Defender provides the visibility, detection, and remediation capabilities needed to protect your environment against these stealthy, high-impact OAuth-based attacks.  

Discovery of OAuth applications   

Early detection is essential in defending against OAuth-based attacks. Defender can discover suspicious activities such as registration of OAuth applications that could be easily missed. In this scenario described, there were several subtle red flags that Defender is equipped to unveil. 

To allow visibility, first connect the Salesforce app in Defender by navigating to Settings → Cloud Apps → App connectors and confirming prerequisites (API enabled, Event Monitoring). See detailed instruction in the Defender public documentation. This step is required for all subsequent steps.  

Defender provides visibility into third-party OAuth apps that have been granted access in your environment. This unified view allows security administrators to see, for example, that a new app called “My Ticket Portal” or “Data Loader” (with publisher “Unknown”) was authorized by users and request read/write access to data.  

Figure 4: Application assets page, Salesforce tab, Defender portal

By proactively using Defender, organizations can be alerted within minutes of the malicious consent, or as soon as the attacker starts pulling unusual amounts of data, rather than discovering a breach days later after significant data loss has already occurred. 

Investigation: Understanding the full scope of the attack  

Once a suspicious OAuth is detected, Defender provides a rich toolset to investigate the full scope of the incident. Below is an example of how security analysts can use Defender to investigate the attack in-depth: 

• Advanced hunting: To get more visibility and to investigate ongoing events in-depth, security teams can use advanced hunting queries to explore organization-wide data and identify ongoing malicious activity. 

• • Audit Salesforce connected applications to ensure that only trusted and approved applications are in use. The following query will shed light on Salesforce Oauth apps with suspicious API usage, suggesting malicious behavior. 

  • CloudAppEvents  
    | where Application == "Salesforce"  
    | where ActionType == "ApiTotalUsage" // Event for REST/SOAP/Bulk API query  
    | extend ConnectedAppName = tostring(RawEventData.CONNECTED_APP_NAME), ConnectedAppId = tostring(RawEventData.CONNECTED_APP_ID), UserName = tostring(RawEventData.USER_NAME)  
    | where isnotempty(ConnectedAppName)  
    | summarize RequestCount=count(), UniqueUsers=dcount(UserName), Users=make_set(UserName) by ConnectedAppName, ConnectedAppId 

     

• • Salesforce activity records are pulled for that user around the time of the incident. A surge of API calls like Query or Data Export operations initiated by the OAuth app. For example, Defender’s log might show dozens of queries executed by “My Ticket Portal (OAuth App)” on Salesforce objects (Accounts, Contacts, Opportunities) within a short timeframe.  

  • CloudAppEvents 
    | where Application == "Salesforce" 
    | where ActionType == "ApiTotalUsage" 
    | extend 
        ConnectedAppName = tostring(RawEventData.CONNECTED_APP_NAME), 
        ObjectType = tostring(RawEventData.ENTITY_NAME) 
    | where isnotempty(ConnectedAppName) 
    | summarize RequestCount=count() by bin(Timestamp, 30m), ConnectedAppName, ObjectType 
    | render timechart 

• • Hunt for IOCs like malicious IPs, UserAgents etc. used by threat actors to look for malicious activity. For instance, here is a list of IOCs shared by Salesloft recently. The following query can be used in Advanced Hunting to search for any activity based on the provided IPs on the IOC list.

    • CloudAppEvents 
      | where Application == “Salesforce” 
      | where IPAddress in ("154.41.95.2","176.65.149.100","179.43.159.198","185.130.47.58","185.207.107.130","185.220.101.133","185.220.101.143","185.220.101.164","185.220.101.167","185","220.101.169","185.220.101.180","185.220.101.185","185.220.101.33","192.42.116.179","192.42.116.20","194.15.36.117","195.47.238.178","195.47.238.83","208.68.36.90","44.215.108.109") 

    • In addition to that list, the following indicators have been observed performing malicious activity:
      

      Value	Type	Description
      193[.]36[.]132[.]21	IPv4	Tor exit node

       
  • If the attackers also used Okta credentials to log into Microsoft 365, the analyst can check the Microsoft Entra ID sign-in logs or Defender logs for unusual sign-ins. Analysts will be able to see if the same user account had successful logins to Microsoft 365 from a specific IP shortly after the Salesforce breach.  
• Review alerts relevant to Salesforce activity: 
  • Look for any alerts with the title “Possible Salesforce scraping activity” in the Alerts and/or Incidents pages. This alert is triggered when a large number of Salesforce API requests from the same account are observed in a short period of time. This might also indicate an automated scraping activity. It's important to investigate this activity to determine whether a threat actor might be monitoring or launching an attack so you can mitigate it, or if it has something to do with an internal audit. Note that this alert is not targeted at the attacks referenced earlier, but may detect the activity involved - as this pattern matches the signature of the attack described in the blog post. 

• Security admins also have the option to create ad-hoc custom detection rules for specific behaviors they want to track to detect OAuth apps attacks in the future. 

Response and remediation 

When attackers exploit OAuth app consent, speed is critical. Defender helps security teams move fast by revoking malicious apps, containing compromised accounts, and guiding admins through remediation steps in Salesforce. 

• Remove app access: With Defender, security teams can proactively identify OAuth Figure 5: Revoke app and ban options in Defender Figure 6: Revoke app option, Salesforce admin pageapps in the Applications page and either ban them or fully revoke their permissions. See more in our documentation. 
• Contain the user: Require user to sign in again (session invalidation) and, if needed, Suspend user in Salesforce via governance actions. In case the consenting user was also compromised.
• Manual remediation in Salesforce: Application owners and security teams may also reach the registered OAuth application in Salesforce admin page via Home → Administration → Users → Users → OAuth Apps → Revoke; to manually revoke them, if preferred. 
• Harden Salesforce: Security teams or application owners can require admin approval for critical connected apps in Salesforce; and regularly audit connected apps. Additionally, Salesforce has introduced new permissions such as:
  • “Approve Uninstalled Connected Apps” user permission which must be assigned to users with careful consideration as this will allow them to authorize to uninstalled apps in the organization.Figure 6: Revoke app option, Salesforce admin page
    
  • API Access Control which can be used to manage access to Salesforce APIs through a connected app in your organization.   

• This Salesforce article can help you prepare for these upcoming changes. In case of supply chain attacks, track updates and follow vendor remediations in timely and careful manner. For instance, refer to Salesloft's latest security update here.
• Focus on internal education: Security teams are encouraged to raise awareness within their organization on the importance of not giving authorization keys over any medium (inc. via phone calls), and assimilate the understanding that OAuth registration is equivalent, in its harming potential, to giving away their personal password.

This attack demonstrated a sophisticated SaaS OAuth-based technique. With no malware deployed and no vulnerability exploited, traditional security tools focused on endpoint threats or network signatures offered little defense. It also highlights a growing trend in recent SaaS attacks, where adversaries use new methods for lateral movement, persistence, defense evasion, and data exfiltration across SaaS environments, all without direct interaction with physical devices. 

Defender address this challenge by monitoring signals across SaaS services, detecting anomalies such as unusual OAuth activities, and enabling security teams to quickly investigate and stop such threats. Defender protects both human and non-human identities, while giving customers full visibility into their SaaS applications landscape with capabilities like app-to-app protection, SaaS security posture management, continuous threat protection, and more. 

Learn more: 

• Learn more about SaaS security with Microsoft Defender 

• Integrate the Salesforce app 

• Learn more about governance actions for oAuth applications 

• Salesloft security response: https://trust.salesloft.com/?uid=Drift%2FSalesforce+Security+Notification 

• Salesforce security response: Ongoing Security Response to Third-Party App Incident