
Features 26.08.2025
What the Salesforce Campaign Tells CISOs About SaaS Risk
ShinyHunters has been on a tear, targeting Salesforce customers’ databases
Features 26.08.2025
ShinyHunters has been on a tear, targeting Salesforce customers’ databases
Generations of shopkeepers and waiters have held their respective tongues and reminded themselves that the customer is always right. While that might be doable when the customer orders jogging bottoms to attend a wedding or insists on a boiled steak, sometimes in cybersecurity circles you have to draw the line.
That’s what Salesforce did after multiple large-scale customers had their data pilfered from its systems. The company, whose SaaS products power some of the world’s largest businesses, spotted attackers gaining access to customer data on its servers as far back as March this year. It rapidly reached the conclusion that this was what IT folks call a PEBKAC (problem exists between keyboard and chair).
The Salesforce campaign was a textbook series of voice phishing (vishing) attacks on users of its software.
1) Reconnaissance: The attacker conducts careful reconnaissance to identify the target company’s IT infrastructure.
2) Infrastructure setup: The attacker sets up their own infrastructure – in this case, a malicious version of the Salesforce Data Loader app, which allows customers to download their Salesforce data. The modified version is reworked to look like a help desk ticketing app.
3) Access request: The attacker uses their Data Loader instance to send an eight-figure device code to Salesforce’s servers. This is supposed to be entered by a legitimate user.
4) Vishing attack: The attacker calls the victim, pretending to be from their company’s IT or help desk staff with an urgent query. They ask the victim to visit login.salesforce.com and enter the device code, which authorises the modified app. The employee does so, and then enters their Salesforce access credentials.
5) Salesforce authentication: This triggers an authentication for the device code that the attacker had entered. Their Data Loader is listening for that authentication, which enables it to act as the victim and gain access to the system.
6) Payoff: Once inside, the attacker can identify and download sensitive information, potentially waiting months until finally extorting the victim’s company.
A large number of Salesforce customers were targeted, in a campaign reminiscent of the one that nobbled data storage SaaS provider Snowflake last year. Pandora and Chanel have both been hit by the same attack, as was Google after it first wrote about the group, which it calls UNC6040. The incident that resulted in the breach of 5.7m records from Qantas earlier this year also targeted Salesforce, according to reports, while companies including Adidas and Allianz are also suspected to have been victimized by the same adversaries.
“This was what IT folks call a PEBKAC: problem exists between keyboard and chair.”
UNC6040 claims to be the ShinyHunters crew, which has a five-year history of data theft. However, the group itself has muddied the waters, apparently on purpose, starting online accounts seeming to claim the involvement of Scattered Spider and members of Lapsu$. While it seems to invoke these names to amplify its own reputation, there is some reported crossover between these gangs – notably their proficiency in native-English language vishing.
Salesforce has avoided taking responsibility for these raids.
“Salesforce has enterprise-grade security built into every part of our platform, and there’s no indication the issue described stems from any vulnerability inherent to our services,” it told Hacker News. “Attacks like voice phishing are targeted social engineering scams designed to exploit gaps in individual users’ cybersecurity awareness and best practices.”
It has also released statements reminding customers that they play a “critical role in keeping their data safe” – especially as phishing gets more sophisticated.
The reasoning here is that no one actually hacked Salesforce’s systems directly. Instead, they exploited weaknesses in customers’ authentication workflows to gain access by socially engineering the user. Salesforce’s servers did just what they were supposed to.
In cybersecurity circles, people call this concept “shared responsibility”, explain experts. “Under this model, vendors secure the platform infrastructure, applications, and underlying services, while customers bear responsibility for securing their data, configurations, and user access within that platform,” says Rehman Khan, chief information security architect at Netskope.
“Businesses need workable ‘out-of-band’ verification processes that provide mutual certainty.”Ian Porteous
However, this is often misunderstood, especially on the end-user side.
“Many organisations assume that vendor security controls extend to customer configurations and data handling practices,” Khan tells Assured Intelligence. “This misconception can lead to inadequate customer oversight of user permissions, API integrations, and data governance policies, precisely where most breaches occur.”
So while companies should always take steps to ensure their SaaS vendor’s security is optimised, that alone isn’t enough, warns Adam Marre, CISO at Arctic Wolf.
“You can have a very secure vendor,” he tells Assured Intelligence. “But if you don’t have the right processes and training to protect your staff from getting phished or IT help desk from getting socially engineered, then they can just side-step your security and the vendor’s security, get access to the employee’s account who has admin access, and do whatever they want.”
Thom Langford, EMEA CTO at Rapid7, explains that SaaS usage presents unique security issues for customers.
“Every single element of a SaaS deployment is a key area of risk, because in reality each is outside an organisation’s direct control,” he tells Assured Intelligence. “Organisations are reliant on the ‘trust but check’ model when it comes to using any SaaS provider, and even then, it comes down to the quality of the security function within the provider.”
“Every element of a SaaS deployment is a key area of risk, because is outside an organisation’s direct control”Thom Langford
Salesforce might be quick to draw a line between its area of responsibility and that of its users, but that doesn’t mean it has simply turned its back on the problem. It has issued its own guidance for users of its SaaS software to help them stay safe. In brief, these are:
Set login ranges: Setting allow-lists for IP ranges makes it harder for attackers halfway around the world to target users. While that might be difficult for multi-nationals to do en masse, when people access infrastructure from so many places, Salesforce also recommends setting ranges at a per-user level.
Least-privilege access: When someone gets into Salesforce using the canteen manager’s account, they shouldn’t be able to download the entire customer database.
Enable MFA: Just 41% of companies use multi-factor authentication (MFA), according to CompTIA, exposing them to account hijacking. Last year’s Snowflake-related breaches targeted users of the SaaS-based data storage company’s service, including big-hitters like AT&T, that hadn’t switched MFA on in the software.
Add an organisational security contact: This is the person who the SaaS vendor calls if they notice you’ve been pwned.
Explore Salesforce Shield: This is the company’s suite of security tools to help block external threats. It includes threat and event monitoring, along with data history features. This costs extra, though, begging the question: what constitutes table stakes in built-in SaaS security?
Experts outside Salesforce have more guidance for CISOs when dealing with SaaS companies, and a lot of it involves “soft” cybersecurity best practices that many might ignore.
“Organisations must treat human behaviour as a critical attack surface, not just a training checkbox,” warns Arctic Wolf’s Marre. After all, what UNC6040 is really hacking is human weakness.
Marre suggests effective security awareness training that focuses on emotional manipulation and impersonation. Businesses must also have a blame-free reporting culture so that employees can report suspicious interactions without fear of reprisal. It’s smart to include specific playbooks for social engineering detection and containment in incident response plan, he adds.
“User coaching in the moment of risk is incredibly powerful”Rehman Khan
“User coaching in the moment of risk is incredibly powerful,” adds Netskope’s Khan. “That means engineering systems to provide pop-up alerts and advisory notices at the moment that they’re about to do something risky. Netskope found that 57% of users altered their actions after receiving this ‘in-the-moment’ coaching.”
Workflow is also important here, says Ian Porteous, regional director of engineering for UK and Ireland at Check Point Software.
“In addition to technologies such as MFA, businesses need to plan ahead and devise workable ‘out-of-band’ verification processes that provide mutual certainty,” he tells Assured Intelligence. “This ensures that both the help desk and the employee seeking access are authorised and correctly identified.”
Thus, when someone claiming to be from the help desk comes calling, there’s a standard procedure for calling them back through a specific company channel.
Salesforce’s firm boundary-setting around shared responsibility is a fair acknowledgement that customers have some responsibility here too. Nevertheless, there might be a lot more that SaaS companies could do to enforce security at their end.
Mandating MFA for all customers springs to mind, as does being more stringent about how people register apps for their services. They could use their much-lauded AI capabilities as a matter of course to monitor customer behaviour for anomalies, and then be extra-paranoid about checking in.
These things are always a balance, though. The more you prioritise security as a SaaS company, the more friction you introduce for customers. But when you try to make things as smooth as possible for customers, to keep shareholders happy, that’s a commercially difficult line to walk.