Use Device Code FIRESALEZ at Checkout
Introduction
On the 2nd of July 2025, an Australian Airline reported (https://www.qantasnewsroom.com.au/media-releases/qantas-cyber-incident/) that it had been the victim of a cyber security incident affecting one of its contact centres. In their media release they described how a cyber criminal targeted a call centre and gained access to a "third party servicing platform", resulting in the breach of customer data.
Just days before Qantas' announcement the FBI had published an alert about a group known as Scattered Spider which was actively targeting the airline sector. As the Tactics, Techniques and Procedures (TTP) historically used by Scattered Spider had similarities with Qantas' breach notification, the media (https://www.abc.net.au/news/2025-07-02/qantas-cyber-attack-significant-data-stolen/105484720) started to join dots and draw conclusions.
On the 30th of July, Bleeping Computer published an article (https://www.bleepingcomputer.com/news/security/shinyhunters-behind-salesforce-data-theft-attacks-at-qantas-allianz-life-and-lvmh/), "ShinyHunters behind Salesforce data theft attacks at Qantas, Allianz Life, and LVMH" which suggested that the TTP of the ShinyHunter's group may more closely align with the incident described in the Qantas' breach notification.
In their article, Bleeping Computer reference a report (https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion) by Google's Threat Intelligence Group (GTIG) which documents how a group (ShinyHunters) they track as UNC6240 were using the Salesforce Data Loader application (https://developer.salesforce.com/tools/data-loader) during their vishing attacks. GTIG describe that UNC6240 were socially engineering targets to browse to a "Salesforce connect setup page" and enter a "connection code". It also included a screenshot of the setup page.
The description of the Data Loader application vishing in the GTIG report had similarities with Device Code phishing, which we have previously covered in a blog (https://blog.silentgrid.com/ghost-in-the-pipeline/):
Device Code phishing abuses the Device Authorization Flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) which is typically used by applications when it is difficult to authenticate with a username, password and second factor of authentication (2FA). Rather than prompt the user for credentials, the application will request a device code, user code and verification URL from the "/oauth/device/code" endpoint of an Identity Provider (IdP). The application will then provide the user with instructions to enter their user code to the page hosted at the verification URL. If the user already has a session for the IdP, they are not prompted for credentials and simply enter the user code and click a prompt to authorise the code. In the background the application will periodically poll the "/oauth/token" endpoint for the life time (15 minutes) of the device code to determine whether the user has authorised it. If the user has authorised the device code, the response from the "/oauth/token" endpoint will include tokens for the application to use, which have a much larger life time.
Hello Device Code My Old Friend
Given that we had significant interest from our clients in replicating the TTP of Scattered Spider and those potentially used during the Qantas attack, we decided to explore how the Salesforce Data Loader application was being abused.
To determine if the Data Loader application did support the Device Authorisation Flow (DAF), the application was downloaded and installed. The application was then configured to use Burp Suite as the HTTP proxy and details of the target Salesforce instance were configured.
The application initially attempted to perform authentication using the OAuth authorisation code flow with dummy values. However, an error response from the server indicated the default client provided by the application was not valid.
As suspected, the next authentication attempt used DAF, which was successful. The application also opened the default browser with the user code pre-populated from the URL parameter "user_code". It was noted that some time after we developed our initial proof of concept at the start of August, Salesforce added a warning banner to the setup page to warn users against entering codes provided to them over the phone or by email.
If the user was already logged into Salesforce, they would get a final prompt with the access requested in the initial DAF request scopes. If they were not logged on, they would be prompted to authenticate. At the time of writing this blog, the application logo for the Data Loader application was not loading correctly from the referenced S3 bucket.
After clicking allow, the user received a success message indicating they've completed the DAF.
With the authentication complete, it was possible to download the data the compromised user's account had access to with the Data Loader application.
By default the Data Loader application uses the Salesforce SOAP API, but provides the option to use Salesforce's Bulk API and Bulk API 2.0. According to the Salesforce documentation, the access token would also have access to the REST API and Connect REST API, due to the "api" scope defined in the initial DAF request. If you wanted access to a specific API, you could modify the scope in the initial DAF request. Additionally, you could access functionality not available in the Data Loader application by using any of the APIs directly.
Leveling Up
When it came time to draft this blog, we noted that Google had updated their report on the abuse of the Data Loader application. Their update described that ShinyHunters had moved away from the use of the Data Loader application and had started using their own connected applications. It is fair to assume that this adaptation was due to Google issuing advice to look for rogue registrations of the Data Loader application.
The information in the update seemed to indicate there was a method to create a new application in Salesforce and then use it to perform the device code phishing instead of the Data Loader application.
After reading documentation and some trial and error testing with two Salesforce instances (attacker and a target), we determined this was possible using "Connected Applications". Once a Connected Application is configured in the attacker instance, its corresponding unique client id can be used in the DAF for other Salesforce instances (targets).
When the Connected Application is created, the name of the application and also URL of a logo can be specified.
So that the application can use the DAF, "OAuth Settings" need to be enabled in addition to the "Device Flow".
The client id of the resulting application can then be substituted into the initial DAF request to the target Salesforce instance.
Received responses include the code and URL which can then be provided to end users to complete the DAF.
If the user navigates to the URL, they get the same initial connection page seen for the Data Loader application. If they were to submit the code, they would then get taken to the final prompt, which includes the Connected Application name and the logo specified during creation.
If the user selects "Allow", the DAF is complete and the Connected Application (attacker) will now have an access token which can be used to access Salesforce API.
Mitigation and Prevention
If you need to ensure you have appropriate controls implemented to prevent Device Code phishing attacks, Google's report includes excellent advice:
Salesforce's Security documentation can also be found here:
Salesforce have also stated they will be preventing users from connecting uninstalled applications starting from early September:
Conclusion
Salesforce Connected Application functionality can be abused to perform device code phishing. As the connection page for Salesforce instances immediately populates the code specified in the "user_code" URL parameter, attackers could craft links (only valid for 15 minutes) to use in Device Code phishing without a complex pretext. This characteristic could also allow the delivery of the URL via QR codes. The ability for the attacker to control the application name and the logo displayed to target users also makes the connection process seem more legitimate.
Internally, we've modified our Device Code phishing tool kit to support the use of the Data Loader application and custom Connected Applications.
