More and more incidents linked to UNC6040 and ShinyHunters are being uncovered. As outlined in previous blogs, these attacks often begin with vishing, where a threat actor impersonates IT support and tricks an employee into action.
But how exactly do attackers gain access to the organization’s Salesforce environment?
Let’s walk through the process step by step.
The role of OAuth 2.0 device flow
Attackers are leveraging the OAuth 2.0 Device Flow. According to Salesforce documentation, this flow is designed for applications running on devices with limited input or display capabilities, such as Smart TVs. It is also commonly used by command-line apps like Salesforce Data Loader.
For a connected app to use Device Flow, it must be explicitly configured in the app’s OAuth settings.
Step 1. Initiating the authorization flow
To initiate the authorization flow, the connected app (for example, Salesforce Data Loader) sends a POST request to the Salesforce token endpoint:
https://login.salesforce.com/services/oauth2/token
The token endpoint is where apps request for access tokens that are required to authenticate and interact with Salesforce APIs on behalf of the user.
Payload:
data = {
"response_type": "device_code",
"client_id": "<consumer key of the connected app>",
"scope": "api refresh_token"
}
- response_type: must be device_code for this specific flow
- scope: defines the access where api is for standard Salesforce APIs and refresh_token is for persistent access
Step 2. Receiving the authorization response
Once Salesforce verifies the initial request, the token endpoint responds with:
{
"user_code": "aKA9SSDF",
"device_code": "<verification code>",
"interval": 5,
"verification_uri": "https://login.salesforce.com/setup/connect"
}- user_code: code the user must enter to the verification URL
- device_code: unique identifier for the device
- verification_uri: where the user enters the code to authorize the app
- interval: polling wait time
Step 3. User verification and login
At this stage, attackers use social engineering to convince the user to open a browser and visit the Salesforce verification URL:
https://login.salesforce.com/setup/connect
The user is asked to enter the user_code previously generated by the token request.
Once the user enters the code, they are redirected to the Salesforce login page.
After successfully logging in, the user is presented with a screen asking them to approve the connected app’s requested permission scopes (as defined earlier in the flow).
Step 4. Attacker polls for access token
Once the user authorizes the connected app by entering the user_code and clicking Allow, the attacker begins polling the Salesforce token endpoint to check whether the authorization has been granted by sending this payload:
data = {
"grant_type": "device",
"client_id": "<consumer key>",
"code": "<device_code>"
} - grant_type: must be set to device
- client_id: unique identifier of the connected app
- code: previously returned device_code
Step 5. Access and refresh tokens issued
Following successful user authorization, the app begins polling the token endpoint. When the request is validated, Salesforce responds by issuing an access token and a refresh token.
{
"access_token": "OAuth token",
"refresh_token": "refresh token",
"signature": "encoded signature",
"scope": "refresh_token api",
"instance_url": "<user’s Salesforce org>",
"id": "<Identity URL>",
"token_type": "Bearer",
"issued_at": "<timestamp>"
}
What this means:
- access_token: OAuth token that grants API access on behalf of the user
- refresh_token: used to obtain new access tokens without re-authenticating
- scope: permission scope that was granted earlier (e.g., api, refresh_token)
- instance_url: base URL of the user’s Salesforce org to be used for subsequent API calls
- id: the Identity URL, typically in the format: https://login.salesforce.com/id/<org_id>/<user_id>
Using this Identity URL, the attacker can programmatically obtain user details such as:
- Username
- First/last name
- Timezone
- User type
- API endpoints
With access to this token and identity information, the attacker now has authenticated access to the user’s Salesforce org. This enables them further data access, reconnaissance, or privilege escalation depending on the user’s role and granted permissions.
The real risk of connected apps
Connected apps have become a hidden entry point in many Salesforce environments. As seen in recent UNC6040 campaigns, attackers abuse the OAuth Device Flow to trick users into granting API access with nothing more than a code and a click. These attacks don’t exploit a Salesforce vulnerability – they exploit trust, familiarity and a well-disguised prompt.
What organizations can do
To protect against OAuth Device Flow abuse in Salesforce, organizations should strengthen their connected app security and reduce unnecessary permissions. A focused approach to Salesforce security means auditing connected apps, limiting scopes, and monitoring API events for unusual activity. Combined with user training and disabling Device Flow where it’s not required, these steps help close one of the most common entry points attackers now exploit.
- Audit connected apps and investigate unfamiliar ones
- Revoke unused or unknown approvals
- Restrict scopes to the minimum necessary
- Monitor suspicious API events with Event Monitoring
- Train employees on vishing/authorization scams
- Disable Device Flow if not needed
What Salesforce is doing in response to the attacks
To address the risks of OAuth Device Flow abuse, Salesforce is rolling out two major changes: Blocking Uninstalled Connected Apps and Removing Device Flow from Data Loader.
Blocking uninstalled connected apps
Starting August 28, 2025 for new orgs and early September 2025 for existing orgs, users will need the new “Approve Uninstalled Connected Apps” permission to use any connected app that aren’t installed in the org.
Removing Device Flow from Data Loader
On September 2, 2025, Salesforce will remove support for OAuth 2.0 Device Flow from the auto-installed Data Loader Connected App. Users must switch to:
- Password authentication, or
- OAuth Web Server Flow
Salesforce will release an updated version of Data Loader before that date with Device Flow support removed.
Staying ahead of OAuth-based threats and malicious connected apps
The abuse of Salesforce’s OAuth Device Flow shows how attackers are shifting from technical exploits to identity and authorization scams. Organizations that treat connected apps as an afterthought are leaving doors wide open for compromise.