ShinyHunters Targets Hundreds of Websites in New Salesforce Campaign

A wave of data breaches impacting companies like Qantas, Allianz Life, LVMH, and Adidas has been linked to the ShinyHunters extortion group, which has been using voice phishing attacks to steal data from Salesforce CRM instances. In June, Google's Threat Intelligence Group (GTIG) warned that threat actors tracked as UNC6040 were targeting Salesforce customers in social engineering attacks. In these attacks, the threat actors impersonated IT support staff in phone calls to targeted employees, attempting to persuade them into visiting Salesforce's connected app setup page. On this page, they were told to enter a "connection code", which linked a malicious version of Salesforce's Data Loader OAuth app to the target's Salesforce environment. In some cases, the Data Loader component was renamed to "My Ticket Portal," to make it more convincing in the attacks. GTIG says that these attacks were usually conducted through vishing (voice phishing), but credentials and MFA tokens were also stolen through phishing pages that impersonated Okta login pages. Around the time of this report, multiple companies reported data breaches involving third-party customer service or cloud-based CRM systems. LVMH subsidiaries Louis Vuitton, Dior, and Tiffany & Co. each disclosed unauthorized access to a customer information database, with Tiffany Korea notifying customers the attackers breached a "vendor platform used for managing customer data." Adidas, Qantas, and Allianz Life also reported breaches involving third-party systems, with Allianz confirming it was a third-party customer relationship management platform. "On July 16, 2025, a malicious threat actor gained access to a third-party, cloud-based CRM system used by Allianz Life Insurance Company of North America (Allianz Life)," an Allianz Life spokesperson told BleepingComputer. While BleepingComputer has learned that the Qantas data breach also involved a third-party customer relationship management platform, the company will not confirm it is Salesforce. However, previous reporting from local media claims the data was stolen from Qantas' Salesforce instance. Furthermore, court documents state that the threat actors targeted "Accounts" and "Contacts" database tables, both of which are Salesforce objects. While none of these companies have publicly named Salesforce, BleepingComputer has since confirmed that all were targeted in the same campaign detailed by Google. The attacks have not led to public extortion or data leaks yet, with BleepingComputer learning that the threat actors are attempting to privately extort companies over email, where they name themselves as ShinyHunters. It is believed that when these extortion attempts fail, the threat actors will release stolen information in a long wave of leaks, similar to ShinyHunter's previous Snowflake attacks. "We have not identified any data leak sites associated with this activity," Genevieve Stark, Head of Cybercrime, and Information Operations Intelligence Analysis at GTIG, told BleepingComputer. "It is plausible that the threat actor intends to sell the data instead of sharing it publicly. This approach would align with prior ShinyHunters Group activity." Google say they are now tracking Salesforce data-theft attacks under multiple threat group designations. "GTIG attributes multiple incidents impacting Salesforce instances to UNC6040. In at least some cases, the follow-on extortion activity, which we attribute to the distinct threat cluster UNC6240, has used the ShinyHunters brand," Stark told BleepingComputer. "The extortion activity is attributed to UNC6240 instead of UNC6040 due to a significant time gap between the initial data theft activity and the subsequent extortion activity. We have not confirmed the nature of the relationship between these intrusions and the prior use of this handle on underground forums." Who is ShinyHunters The breaches have caused confusion among the cybersecurity community and the media, including BleepingComputer, with the attacks attributed to Scattered Spider (tracked by Mandiant as UNC3944), as those threat actors were also targeting the aviation, retail, and insurance sectors around the same time and demonstrated similar tactics. However, threat actors associated with Scattered Spider tend to perform full-blown network breaches, culminating with data theft and, sometimes, ransomware. ShinyHunters, tracked as UNC6040, on the other hand, tends to focus more on data-theft extortion attacks targeting a particular cloud platform or web application. It is BleepingComputer's and some security researchers' belief that both UNC6040/UNC6240 and UNC3944 consist of overlapping members that communicate within the same online communities. The threat group is also believed to overlap with "The Com," a network of experienced English-speaking cybercriminals. "According to Recorded Future intelligence, the overlapping TTPs between known Scattered Spider and ShinyHunters attacks indicate likely some crossover between the two groups," Allan Liska, an Intelligence Analyst for Recorded Future, told BleepingComputer. Other researchers have told BleepingComputer that ShinyHunters and Scattered Spider appear to be operating in lockstep, targeting the same industries at the same time, making it harder to attribute attacks. Some also believe that both groups have ties to threat actors from the now-defunct Lapsus$ hacking group, with reports indicating that one of the recently arrested Scattered Spider hackers was also in Lapsus$. Another theory is that ShinyHunters is acting as an extortion-as-a-service, where they extort companies on behalf of other threat actors in exchange for a revenue share, similar to how ransomware-as-a-service gangs operate. This theory is supported by previous conversations BleepingComputer has had with ShinyHunters, where they claimed not to be behind a breach, but just acting as the seller of the stolen data. These breaches include PowerSchool, Oracle Cloud, the Snowflake data-theft attacks, AT&T, NitroPDF, Wattpad, MathWay, and many more. To muddy the waters further, there have been numerous arrests of people linked to the name "ShinyHunters," including those who have been arrested for the Snowflake data-theft attacks, breaches at PowerSchool, and the operation of the Breached v2 hacking forum. Yet even after these arrests, new attacks occur with companies receiving extortion emails stating, "We are ShinyHunters," referring to themselves as a "collective." Protecting Salesforce instances from attacks In a statement to BleepingComputer, Salesforce emphasized that the platform itself was not compromised, but rather, customers' accounts are being breached via social engineering. "Salesforce has not been compromised, and the issues described are not due to any known vulnerability in our platform. While Salesforce builds enterprise-grade security into everything we do, customers also play a critical role in keeping their data safe — especially amid a rise in sophisticated phishing and social engineering attacks," Salesforce told BleepingComputer. "We continue to encourage all customers to follow security best practices, including enabling multi-factor authentication (MFA), enforcing the principle of least privilege, and carefully managing connected applications. For more information, please visit: https://www.salesforce.com/blog/protect-against-social-engineering/." Salesforce is urging customers to strengthen their security posture by: Enforcing trusted IP ranges for logins Following the principle of least privilege for app permissions Enabling multi-factor authentication (MFA) Restricting use of connected apps and managing access policies Using Salesforce Shield for advanced threat detection, event monitoring, and transaction policies Adding a designated Security Contact for incident communication Further details on these mitigations can be found in Salesforce's guidance linked above. Update 8/1/25: Added information from GTIG. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

The notorious Scattered Spider group seems to have been rattled and its cybercriminal activity stalled following the arrest of four individuals linked to the group and suspected of orchestrating cyber-attacks. The arrests took place in the UK on July 10, with the four individuals suspected of Computer Misuse Act offences relating to cyber-attacks on three British retailers in April 2025. They were later bailed pending further enquiries. Since then, cybersecurity firm Mandiant, which tracks The Com-affiliated group as UNC3944, said it has not observed any new intrusions directly attributable to this specific threat actor. The Com is a loosely organized online criminal network involving thousands of English-speaking individuals. Commenting on the four individuals arrested, Charles Carmakal, CTO, Mandiant Consulting – Google Cloud, told Infosecurity, “They aren't the only members who are involved in Scattered Spider intrusions. But the arrests have spooked other members.” Anthony Freed, director of research at ransomware prevention firm Halcyon, concurred that since the arrests Scattered Spider activity has “gone quiet.” He noted that the last confirmed attack linked to UNC3944 hit in May 2025 when Darktrace observed the group’s hallmark social engineering tactics in action. Since then, several airlines, including Hawaiian Airlines in late June and WestJet in mid-June, were targeted with some suspecting links to Scattered Spider due to familiar tradecraft. These events have not been definitively attributed to Scattered Spider. “That said, the Scattered Spider threat has not diminished, it is likely they are being more cautious in light of the arrests,” Freed said. Christiaan Beek, senior director, threat analytics at Rapid7, told Infosecurity that the firm’s researchers had observed some aggressive phishing email and social engineering campaigns in the past two weeks. However, Beek said it was too early to determine if these were linked to Scattered Spider. Other Threat Actors Persist with Similar Tradecraft Other groups, like ShinyHunters (UNC6040), also affiliated to The Com, employ the same type of social engineering tactics as Scattered Spider, such as targeting IT help desks to gain initial access. “While one group may be temporarily dormant, others won't relent," said Carmakal. In June 2025, the Google Threat Intelligence Group (GTIG) highlighted ShinyHunters’ specialist vishing campaigns designed to compromise organizations' Salesforce instances for large-scale data theft and subsequent extortion. In recent months, the group has demonstrated repeated success in impersonating IT support personnel in telephone-based social-engineering engagements. It has been reported that the data breach that affected Qantas Airlines in June, which was linked by some cybersecurity professionals to Scattered Spider, is likely linked to ShinyHunter. The outfit has also been linked to a data breach that impacted Allianz Life in July. The insurer revealed that the attackers exfiltrated sensitive data after gaining access to a third-party, cloud-based CRM system. CISA Updates Scattered Spider Advisory The US Cybersecurity and Infrastructure Security Agency (CISA) updated it advisory on Scattered Spider on July 29. CISA and international partners said they had identified new tactics, techniques and procedures (TTPs) associated with the cybercriminal group. These included more sophisticated social engineering techniques. While Scattered Spider initially began their activity relying on broad phishing campaigns, the threat actors are now employing more targeted and multilayered spearphishing and vishing operations. One hallmark of their activity is targeting IT help desks via spearphishing calls which aim to convince personnel to reset passwords and/or transfer MFA tokens. The update also highlighted new legitimate remote access tools that are exploited by Scattered Spider including Teleport.sh and AnyDesk. Additional malware and ransomware variants have also been identified that have been used to exfiltrate data and encrypt target organizations’ systems. CISA confirmed the group deployed DragonForce ransomware alongside its usual TTPs. Deployment of this ransomware encrypts a target organization’s VMware Elastic Sky X integrated (ESXi) servers. Earlier in 2025, it is understood that DragonForce encryptors were used as part of a cyber-attack against UK retailer Marks & Spencer which disrupted the company’s operations and online retail arm. CISA also identified RattyRAT as another malware used by the hackers. This is a Java-based remote access trojan used for persistent, stealth access and initial reconnaissance. CISA’s latest advisory recommends that organizations employ enhanced monitoring against unauthorized account misuse and look for risky logins within environments where sign-in attempts have been flagged as potentially compromised due to suspicious activity or unusual behavior.

On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits. Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture. While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there. Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes. In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates. The exploit Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers. We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play. CVE-2025-49706 This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison. The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed. On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer. The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed. CVE-2025-53771 We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path. On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer. This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator. While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed. CVE-2025-49704 CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri” is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML. While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter. Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll. Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list. Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable. CVE-2025-53770 On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet. CVE-2020-1147 Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147. Conclusions Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server. To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference. At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed. Kaspersky Next with its Behaviour detection component proactively protects against exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity. Kaspersky products detect the exploits and malware used in these attacks with the following verdicts: UDS:DangerousObject.Multi.Generic PDM:Exploit.Win32.Generic PDM:Trojan.Win32.Generic HEUR:Trojan.MSIL.Agent.gen ASP.Agent.* PowerShell.Agent.*

Salesforce is warning customers that hackers are targeting websites with misconfigured Experience Cloud platforms that give guest users access to more data than intended. However, the ShinyHunters extortion gang claims to be actively exploiting a new bug to steal data from instances. Salesforce has shared guidance for its customers to defend against hackers actively targeting the /s/sfsites/aura API endpoint on misconfigured Experience Cloud instances that gives guest users access to more data than intended. The company states that attackers are deploying a modified version of AuraInspector, an open-source auditing tool developed by Mandiant, which can help administrators identify access control misconfigurations within the Salesforce Aura framework. "It is important to note that Salesforce remains secure, and this issue is not due to any vulnerability inherent to our platform. Our investigation to date confirms that this activity relates to a customer-configured guest user setting, not a platform security flaw," Salesforce says in the advisory. The company explains that a publicly exposed Salesforce Experience site accepts a "guest user profile" to provide anonymous, unauthenticated visitors with access to data intended to be public. If the profile is misconfigured and has excessive permissions, visitors can "directly query Salesforce CRM objects without logging in." Salesforce says an organization can improve its defenses against such attacks by auditing guest user permissions and adopting the principle of least privilege. The vendor says the highest-impact change customers can make to mitigate the risk is to disable guest access to public APIs and remove the API Enabled setting from the guest profile. The company recommends customers take the following set of immediate actions: Audit guest user permissions and reduce them to the minimum required. Set org-wide defaults to Private for external access. Turn off Portal User Visibility and Site User Visibility so guest users cannot enumerate internal users. Disable self-registration unless it is truly needed, because exposed guest data could be used to create portal accounts and expand access. System administrators should also review Aura Event Monitoring logs for unusual access patterns, unfamiliar IP addresses, or queries against objects that should not be public, and designate a Security Contact so Salesforce can notify the right person quickly. ShinyHunters takes responsibility In a post on their data leak site, the ShinyHunters threat actor has claimed responsibility for the Salesforce Aura/Experience Cloud data theft attacks. Mandiant Consulting confirmed in a statement for BleepingComputer that hackers are using AuraInspector in attempts to breach companies. "We are aware of a threat actor attempting to facilitate intrusions by misusing the AuraInspector open-source tool to automate vulnerability scans across Salesforce environments," said Charles Carmakal, Mandiant chief technology officer. "We are working closely with Salesforce and our customers to provide the necessary telemetry and detection rules to mitigate potential risk. It is important to note that detecting scanning activity in an organization’s logs does not indicate a compromise," the CTO said. ShinyHunters says that they compromised around 100 high-profile companies, many of them in the cybersecurity sector. The total count of breached organizations is somewhere between 300 and 400, the hackers told BleepingComputer. The hackers told BleepingComputer that in September 2025, they started to compromise companies with insecure Experience Cloud access control configurations for guest users. They were also identifying Aura instances by scanning the internet for the /s/sfsites/ endpoint. Due to a limitation from Salesforce, the threat actor said that they could only query 2,000 records at a time through the company's GraphQL API, which slowed the data theft process. However, the hacker found the sortBy parameter, which they claim bypassed the restriction. When AuraInspector was released in January to help admins find misconfigured instances, ShinyHunters says they modified the code for additional reconnaissance. Salesforce's advisory confirms that the threat actor's variant of Mandiant's tool was used "to perform mass scanning of public-facing Experience Cloud sites." The threat actors then created their own tool to steal data, which BleepingComputer has learned uses the following string as part of its user agent: Anthropic/RapeForceV2.01.39 (AGENTIC) This tool has a similar name to the "RapeFlake" tool used during the SnowFlake data theft attacks. ShinyHunters claims that after Salesforce fixed the sortBy trick previously noted by Mandiant, they discovered a new method to bypass the 2,000 record query restriction, "and have been exploiting it since discreetly." The threat actor claims that Salesforce fixed the method used to bypass the 2,000-record limit over the weekend before releasing the advisory, but says they have since discovered a vulnerability that allows data theft from Aura instances even when they are properly configured. BleepingComputer has not been able to independently confirm if this is true. We contacted Salesforce about this allegedly new attack, but the company continues to state that there is no vulnerability in its platform. The threat actor told BleepingComputer that they believe disabling "Public Access" to an instance will protect Salesforce customers against this new attack. However, doing so will also disable guest access and turn the website into a private portal. The threat actor told BleepingComputer that the new attacks are using the following user agent, which looks like a normal browser user agent. Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36 Surprisingly, the threat actor told BleepingComputer that they believe that Salesforce customers can protect themselves from these attacks by disabling "Public Access" to an instance. However, doing so will also disable guest access and turn the website into a private portal. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report