近年、UNC6040（「ShinyHunters」とも呼ばれる脅威クラスター）による、企業のSalesforce環境を標的にしたデータ窃盗や恐喝の被害が次々と明らかになっています。前回のブログで解説したように、これらの攻撃は多くの場合、ITサポートになりすました攻撃者からの「ヴィッシング（音声フィッシング）」電話から始まります。
しかし、攻撃者は具体的にどのような仕組みで組織のSalesforce環境に侵入するのでしょうか？
その裏で悪用されている「OAuth 2.0 デバイスフロー」のプロセスを、ステップ・バイ・ステップで詳しく解説します。
OAuth 2.0 デバイスフローの役割
攻撃者が悪用するのは、OAuth 2.0 デバイスフローと呼ばれる認証プロセスです。Salesforceの公式ドキュメントによると、このフローはスマートTVなど、入力機能や画面表示が制限されたデバイス上で動作するアプリケーション向けに設計されています。また、Salesforceの「Data Loader」のようなコマンドラインアプリでも一般的に利用されていました。
通常、接続アプリでデバイスフローを使用するには、そのアプリのOAuth設定であらかじめ明示的に有効化されている必要があります。
Step 1. 認可フローの開始
認可フローを開始する際、接続アプリケーション（例：Salesforce Data Loader）は、Salesforceのトークンエンドポイントに対してPOSTリクエストを送信します。
https://login.salesforce.com/services/oauth2/token
トークンエンドポイントは、アプリケーションがユーザーに代わって認証を行い、Salesforce APIと連携するために必要となるアクセストークンを要求するための窓口です。
Payload:
data = {
"response_type": "device_code",
"client_id": "<consumer key of the connected app>",
"scope": "api refresh_token"
}
response_type: この特定のフローにおいては、必ずdevice_codeと指定する必要があります。- 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.