Looking for details on the Salesloft Drift OAuth incident? That’s a separate campaign with different actors and TTPs—read our breach analysis here: Salesloft Drift Breach: What Happened and How to Protect Yourself.

Updated 09/02/2025: Added "Hardening Salesforce Now: Lock Down Data Loader OAuth" section.

A coordinated cyberattack campaign targeting Salesforce integrations has compromised data at several major global brands, including Google, Chanel, Qantas, Allianz, LVMH, and Cisco.

The breaches began in May 2025 and are still unfolding. According to Google Threat Intelligence Group (GTIG), the initial intrusions were carried out by a financially motivated group known as UNC6040, which used voice phishing (vishing) to trick employees into authorizing malicious OAuth applications that impersonated trusted Salesforce tools.

In the weeks that followed, a separate threat cluster, UNC6240, began contacting victims with extortion demands. This group consistently identified itself as ShinyHunters, a name previously associated with major data-theft campaigns. The two clusters are believed to be linked, either through shared operators or close coordination.

These attacks did not exploit a vulnerability in Salesforce. Instead, they highlight how attackers can abuse trusted integrations, impersonate legitimate apps, and exploit non-human identities to move silently through SaaS environments, often without triggering traditional security alerts.

“Most enterprises lack visibility into how data and access are managed across their interconnected SaaS ecosystems. The attackers are using valid credentials and sanctioned tools to do exactly what the system allows them to do. That’s what makes it so dangerous.”

Amir Khayat, CEO and co-founder, Vorlon

The Vorlon team has been actively monitoring ShinyHunters, working closely with our Salesforce customers to investigate potential signs of related activity and to implement alerts that can detect suspicious behavior tied to this threat and similar attacks. Now, we’re sharing our tips so you can detect and respond to ShinyHunters-style threats in your own SaaS environment.

How to know if you were impacted by the ShinyHunters Salesforce attacks

The ShinyHunters campaign relies on a blend of social engineering, OAuth impersonation, and API-based data exfiltration. The attackers often use a lookalike version of the Salesforce Data Loader tool, authorized through a deceptive but legitimate OAuth flow. Because these attacks do not exploit a traditional vulnerability, they can be difficult to detect without deep visibility into your Salesforce environment.

Here are signs your organization may have been impacted:

• Unfamiliar connected apps that appear as Salesforce Data Loader or “My Ticket Portal”
• Dormant OAuth apps with broad permissions (e.g., refresh_token full)
• Unusual or excessive API activity, especially involving large dataset exports
• Login attempts from unexpected IP addresses, geographies, or at unusual times
• Unauthorized package installations that bypassed Salesforce’s security review process

Start by reviewing logs from Salesforce Event Monitoring, if available. Look for Bulk API jobs, large volume data exports, and report generation by unexpected users, all of which may indicate compromise.

How to detect and respond if you’re at risk

Whether you’ve spotted suspicious behavior or want to proactively harden your environment, here are key steps to detect and prevent ShinyHunters-style attacks:

1. Audit and monitor OAuth applications

• Review all connected apps, especially those created in the last 12-18 months
• Look for unused, ambiguous, or overlapping app names
• Identify apps with elevated access scopes (refresh_token full)
• Remove unnecessary or high-risk OAuth apps

2. Alert on new OAuth app registrations

• Set up alerting whenever a new OAuth or connected app is created
• Treat apps that resemble trusted tools (like Data Loader) as high risk

3. Track OAuth scope elevation events

• Monitor for apps that escalate access scopes unexpectedly
• Flag any changes to full API access as potential indicators of compromise

4. Watch for unreviewed package installations

• Salesforce logs the URI nonSecurityReviewedManagedPackageInstalled when a package is installed without a security review
• Investigate any such event, especially when linked to admin accounts or tools like Data Loader

5. Implement proactive security controls

• Restrict login IP ranges to trusted enterprise or VPN networks
• Apply the principle of least privilege for app and user access
• Require and enforce multi-factor authentication (MFA). Even if imperfect, it raises the bar for attackers
• Regularly review third-party app access and monitor for anomalies

For Vorlon customers using Salesforce

If you’re already a Vorlon customer with Salesforce connected, the good news is you’re covered. Our platform has preconfigured detection and alerting for ShinyHunters-style activity, including:

• OAuth app drift and dormant app detection
• New connected app creation alerts
• Scope elevation tracking (e.g., refresh_token full)
• Unreviewed package installation alerts
• API behavior anomalies tied to impersonation, TOR traffic, and bulk exports

These detections are already live and actively monitored in your environment.

➡️ If you’d like to review your current coverage or investigate specific signs of risk, contact your Customer Success representative. We’re here to support your response and readiness efforts.

Worried about exposure? Get a free risk assessment

If you use Salesforce and want to understand your exposure to tactics used in the ShinyHunters campaign, we’re here to help.

Vorlon is offering a free assessment based on your available logs and metadata. No agents, no production impact. Just clear answers.

We’ll help you:

• Identify suspicious OAuth activity
• Surface signs of impersonated apps or scope escalations
• Map potential data access and exfiltration patterns

Request your free assessment and get expert guidance from our security team.

Hardening Salesforce now: Lock down data loader OAuth

A high-impact way to reduce OAuth impersonation risk is to stop using Salesforce’s generic Data Loader client IDs and use your own External Client App (ECA) instead. Then block the legacy keys.

Why this matters

• OAuth identifies desktop apps by client_id. Public desktop apps can’t keep secrets, so any impostor can reuse Salesforce’s generic Data Loader client IDs.
• Using your own client_id via an ECA and allow-listing it prevents lookalike apps from riding on trusted IDs.

5-minute setup

1. Create an External Client App

• Setup > App Manager > New External Client App, enable OAuth
• Callback: http://localhost:7171/OauthRedirect
• Require PKCE; do not require a client secret for web server flow
• Scopes: api, refresh_token (offline_access)

2. Copy the Consumer Key (client_id)

3. Point Data Loader to your key

• Data Loader > Settings > Enable OAuth login from browser
• Paste the Consumer Key into “External Client App Consumer Key” (Prod/Sandbox)

4. Block Salesforce’s legacy Data Loader apps

• Setup > Connected Apps OAuth Usage
• Block “Dataloader Partner” and “Dataloader Bulk”
• Note: Requires Data Loader v64.0.2+

Go further (recommended)

• Enable API Access Control and allow-list only trusted client_ids
• Minimize or eliminate the “Use Any API Client” permission
• Combine with connected app hardening (per Salesforce Ben/Tom Bassett), and standard controls:
  • Alert on new connected apps and scope changes (e.g., refresh_token full)
  • Restrict who can authorize high-impact tools
  • Monitor large API exports and off-hours activity

Credit: Salesforce MVP Francis Pindar shared this practical approach publicly; it aligns with Salesforce’s latest hardening guidance.

On-demand webinar with 451 Research

Watch a special executive webinar featuring S&P Global’s Justin Lam and Vorlon CEO Amir Khayat. We’ll discuss the ShinyHunters campaign, explore new research on SaaS and AI risk convergence, and share practical steps security teams can take to improve visibility and response.

Free webinar here

ShinyHunters Salesforce attack Tactics, Techniques, and Procedures (TTP)

The attacks targeting Salesforce environments follow a well-orchestrated and technically subtle progression. Rather than exploiting a software vulnerability, the attackers abuse OAuth trust, desktop application behavior, and user psychology to quietly gain and maintain access to sensitive CRM data.

Step 1: Social engineering via vishing

The attack typically begins with a phone-based social engineering (vishing) call, in which the attacker impersonates a company’s IT support team. The employee, often a Salesforce administrator or support staff, is told to perform an “urgent” troubleshooting or configuration task.

During the call, the attacker directs the victim to Salesforce’s Connected Apps authorization page and then asks the victim to enter a code to connect a desktop application that appears legitimate.

Step 2: Impersonation of a trusted app

The application being authorized is not what it seems. It is a lookalike version of Salesforce’s Data Loader, a legitimate admin tool used to bulk import and export CRM data. The attacker’s version mimics the interface and behavior of the real tool but is under their control.

Critically, the malicious app reuses the same OAuth client ID and redirect URI as the legitimate Data Loader. Because desktop apps use loopback redirect URIs (e.g., http://localhost) and cannot securely store secrets, any application on the device can impersonate a trusted one, as long as it knows the client ID and redirect URI.

This approach bypasses consent screens and avoids raising alerts, since the OAuth flow appears to be initiated from a known, pre-approved application.

Step 3: OAuth token issuance and silent access

Once the victim completes the login flow, Salesforce issues valid OAuth tokens to the attacker-controlled app. From an audit and monitoring perspective, this access appears routine:

• No new connected app is created
• No unusual IP address may be observed (if the app runs locally)
• No elevated permissions are requested

This makes the attack invisible to most traditional security controls.

Step 4: API-based data exfiltration

With valid tokens in hand, the attacker uses either a modified version of Data Loader or custom-built automation scripts to extract data from Salesforce. The process often starts with small queries to avoid detection, then escalates to bulk exports of:

• Contact lists
• Customer profiles
• Loyalty program data
• Internal business notes or sales records

The exfiltration is frequently routed through TOR or VPN-based infrastructure to further obscure the source of the access.

Step 5: Optional lateral movement

In some cases, the attacker uses harvested credentials or session data to pivot into other cloud environments, such as identity platforms or productivity suites. This lateral movement may target services like Okta or Microsoft 365, leveraging the trust and access already granted to the compromised user.

Key security gaps and lessons learned

This multi-stage attack takes advantage of the legitimate behavior of OAuth flows, combined with a high-trust application and a low-friction user experience. It highlights the urgent need for organizations to implement tighter controls around:

• Who can authorize high-privilege desktop applications
• What client IDs are trusted within their environment
• And how OAuth token behavior is monitored across users and non-human identities

Organizations affected by this campaign typically lack sufficient connected app governance, OAuth visibility, and non-human identity monitoring, which are common security gaps that enable these attacks to succeed.

A full set of indicators of compromise (IOCs), including IP addresses and behavioral patterns associated with this campaign, is available from Google Threat Intelligence Group.

Who’s behind the Salesforce vishing attacks?

Attributing cyberattacks is rarely straightforward, and the recent wave of Salesforce-related intrusions is no exception. In short, the Salesforce attacks are not the work of a single actor, but rather a fluid collaboration between skilled social engineers and data extortionists.

Based on public reporting from Google Threat Intelligence Group (GTIG), security researchers, and the attackers' direct claims, here’s what is known so far.

Threat Actor Quick Reference

UNC6040: The initial intrusion group

The campaign’s initial access activity has been attributed by Google to a financially motivated group tracked as UNC6040. This group is known for conducting highly targeted voice phishing (vishing) attacks, impersonating IT support staff to trick employees into authorizing malicious OAuth applications in Salesforce, often disguised versions of Salesforce Data Loader. These apps give the attackers API-level access, allowing them to export large volumes of data without triggering typical security alerts.

UNC6040’s tactics have evolved over time. Early intrusions relied on Salesforce trial accounts and basic phishing infrastructure. More recent attacks involve the use of compromised third-party accounts, custom-built automation scripts, and TOR-based exfiltration to evade detection (Google).

UNC6240 and the “ShinyHunters” brand

In many cases, extortion attempts have followed weeks or months after the initial breach. These activities, such as emails or calls demanding Bitcoin payments, have been attributed to a separate threat cluster, tracked as UNC6240 by Google. UNC6240 consistently claims to be ShinyHunters, a well-known cybercrime group previously linked to data theft and extortion campaigns involving Snowflake, AT&T, and others (BleepingComputer).

Google has not confirmed whether UNC6040 and UNC6240 are operated by the same individuals, but acknowledges the close coordination between them. The "ShinyHunters" name appears to function more like a brand, used to amplify pressure and draw from the group’s prior notoriety.

Scattered Spider and the emergence of “Sp1d3rHunters”

The tactics used, especially vishing, OAuth abuse, and help desk impersonation, initially led some researchers to suspect Scattered Spider (UNC3944), a threat actor known for high-profile social engineering attacks in sectors like aviation and hospitality. ShinyHunters has since claimed in interviews and Telegram posts that they are working directly with Scattered Spider to conduct these attacks, stating that Scattered Spider provides initial access, while ShinyHunters handles exfiltration and extortion.

The attackers now refer to themselves as “Sp1d3rHunters,” a name that blends both brands and reflects what appears to be a merged or collaborative effort. Whether this represents a formal partnership or simply overlapping members operating under different banners remains unclear.

A decentralized collective

The broader picture emerging is that of a decentralized, loosely affiliated network, possibly operating as an extortion-as-a-service collective. Members may include former affiliates of groups like Lapsus$, and are likely active in English-speaking cybercrime forums such as “The Com.” Infrastructure overlaps, shared toolkits, and consistent branding suggest close ties, even if the operational boundaries between these groups are blurry.

Official responses

• Salesforce released a customer advisory and confirmed the breaches were not due to a system vulnerability, but to the use of compromised credentials.
• Salesforce guidance: Customers are urged to review and secure all integrations, rotate credentials, and enable MFA.
• Chanel and other victims notified regulators, began customer outreach, and launched investigations with law enforcement and cybersecurity experts.
• Law enforcement is actively investigating, and regulatory authorities are monitoring the situation.
  
  

In direct response to this wave of attacks, Salesforce announced two major security enhancements to its platform, scheduled for implementation in early September 2025. One of the changes will be enforced automatically, while the other will be available as a customer opt‑in setting that requires administrative action.

These measures are intended to counter the exact attack methods exploited in recent breaches such as malicious OAuth app approvals and illicit consent grants. Salesforce customers should review these updates and ensure they are prepared to take the necessary steps ahead of rollout.

Salesforce Shared Responsibility Model

Ecommerce sites and platforms are attractive cyber attack targets. Cyber attackers look for locations where they can try to exfiltrate sensitive data, such as credit cards, personally identifiable information (PII), and credentials. The ordering workflow also offers an attractive attack surface for cybercriminals to try to enrich themselves. They can create fake orders, adjust coupons and promotions, and deny service to legitimate customers.

Salesforce takes security seriously and provides multiple security controls and settings that mitigate these risks. B2C Commerce uses a shared responsibility model in which the B2C Commerce platform and the customer have clearly defined roles and responsibilities.

As our customers’ trusted adviser in data security, we use and make available the following tools and practices to help strengthen their security.

Salesforce

Customers

Promote the secure design and implementation of Salesforce infrastructure, platform, and applications. Manage outbound and inbound firewall rules. Enforce two-factor authentication (2FA) on sensitive Salesforce assets. Enforce data isolation per tenant. Run proactive code scans and pen tests. Perform third-party security assessments and audits. Enforce controls to comply with industry standards. Ensure continuous monitoring and incident responses on Salesforce assets.

Enforce secure communication protocols such as HTTPS and SFTP. Restrict application-level access controls, for example, by using IP allowlisting and identity validation. Enforce 2FA on sensitive customer-managed interfaces. Assign proper roles and permissions along with robust user provisioning processes. Consume and analyze audit logs in a timely manner. Promote the secure design and implementation of custom code. Promote the secure sourcing, deployment, and maintenance of third-party integrations and extensions. Comply with relevant security standards and regulations. Ensure continuous monitoring and incident response on customer and custom third-party integration assets. Deploy anti-abuse, fraud detection, and prevention measures.

Credit: Salesforce Help Docs, B2C Commerce for Merchandisers and Administrators

FBI warning on active threat activity

The coordinated campaign against Salesforce customers has now drawn direct warnings from government agencies. On September 14, 2025, the FBI released a Flash Report alerting organizations to ongoing intrusions tied to UNC6040 (linked to the initial intrusions) and UNC6395 (another financially motivated group engaged in exfiltrating Salesforce data).

The FBI report included indicators of compromise (IOCs) such as malicious IP addresses, suspicious User Agent strings, and URLs observed during attacker activity. These IOCs highlight how attackers are abusing trusted Salesforce sessions and integrations to steal data without exploiting infrastructure flaws.

How to use the FBI’s IOCs

Vorlon recommends that organizations:

• For IP addresses:
  Add the flagged IPs to Salesforce identity IP restrictions where possible, and block them more broadly at the network or firewall layer. Review past logs for traffic from those IPs and rotate any identities, accounts, or secrets associated with that activity.
  
  
• For User Agent strings:
  Investigate any traffic that matches the flagged User Agents. While these cannot be safely blocked outright (they are widely used in legitimate traffic), they become high‑value signals when correlated with suspicious IPs or anomalous behavior. Revoke or rotate accounts if malicious usage is confirmed.
  
  
• For URLs/links:
  Block the flagged URLs on your firewall or WAF, but only at the full URL level, not at the root domain, to avoid disrupting legitimate traffic.
  
  

These IOCs provide useful checkpoints, but they are not sufficient on their own. Threat groups evolve quickly, and new infrastructure appears constantly. The best protection comes from continuous monitoring, anomaly detection, and rapid response across the entire SaaS ecosystem, whether activity is tied to known IOCs or brand‑new attacker infrastructure.

Lack of access to API activity in logs hinders detection efforts

Threat actors are collaborating, and we in the security community need to do the same.

ShinyHunters’ activity was evasive, but not invisible. Signs of abuse, like large data exports or suspicious app registrations, could have been spotted in the logs.

The problem is that many Salesforce customers couldn’t access those logs. Like many SaaS vendors, Salesforce charges extra for the type of logs that capture API calls, integration activity, and data exfiltration behavior. In some cases, customers must file a support ticket to request access. That process can take hours or even days, which is far too long when every minute counts.

This isn’t unique to Salesforce. According to Vorlon’s research, 50% of SaaS vendors either charge licensing fees or require manual steps to access critical security logs.

“This breach isn’t just about one attacker or one platform. SaaS providers are not living up to their role in a shared security model. If customers can’t access logs instantly and without barriers, they are powerless. That’s simply unacceptable.”

Amir Khayat, CEO and Co-Founder of Vorlon

As APIs and integrations become the primary attack surface in SaaS, the fact that this activity is often unlogged, gated, or delayed is a serious flaw in the SaaS shared responsibility model.

Security teams aren’t asking for a premium feature. They’re asking for basic visibility into what’s happening across their ecosystem, especially in the channels attackers now abuse most.

The bigger picture: This is a SaaS ecosystem security problem

The ShinyHunters campaign is not just a Salesforce issue. It brings to light a broader SaaS ecosystem security problem. These attackers exploited the interconnected nature of modern SaaS environments, where API keys, service accounts, and third-party apps often operate without oversight.

Traditional tools focused on endpoints or static misconfigurations are useless here. Security teams need continuous monitoring, identity-aware detection, and real-time visibility across all human and non-human actors in their SaaS stack, especially for platforms like Salesforce that serve as critical business infrastructure.

We’ll continue tracking this campaign and helping customers respond. But the best defense is visibility, and Vorlon gives you the map.

Vorlon: Built for SaaS threats like this

Vorlon gives security and GRC teams the visibility they need to detect and respond to attacks like the ShinyHunters campaign before damage is done. By continuously analyzing OAuth activity, non-human identities, and data flows across your SaaS stack, Vorlon helps uncover signs of compromise that traditional tools miss.

If you're already a Vorlon customer, these detections are live in your environment. If you're not, now is the time to close the gaps.

Timeline of the coordinated Salesforce data theft attacks

Last updated: September 21, 2025

We are actively tracking the unfolding campaign linked to ShinyHunters (UNC6040), which continues to impact organizations leveraging Salesforce and other connected SaaS platforms. Below is a running timeline of confirmed breaches and related incidents. This section will be updated as more disclosures surface.

May 2025

🔹 Adidas

• Details: One of the earliest known victims. Attackers gained access to Salesforce systems containing customer engagement data.
• Impact: Customer names and contact data believed to be accessed. Full scope under investigation.
• Source: BleepingComputer

🔹 Louis Vuitton, Dior, Tiffany & Co. (LVMH Group)

• Details: Initially reported as isolated regional incidents, these breaches were later confirmed to be linked and traced to the ShinyHunters campaign.
• Impact: Customer databases were accessed, exposing names, contact info, and other personal identifiers.
• Source: BleepingComputer
  
  

June 2025

🔹 Pandora

• Details: Attackers accessed Pandora’s Salesforce environment, extracting marketing and customer information.
• Impact: Customer contact details were exposed. Investigation into sensitive PII exposure is ongoing.
• Source: BleepingComputer
  
  

July 2025

🔹 Qantas

• Details: Attackers obtained access to Salesforce records containing passenger and loyalty data.
• Impact: Exposed information included names, travel itineraries, and loyalty program details.
• Source: BleepingComputer

🔹 Allianz Life

• Details: Salesforce environment compromised via hijacked sessions.
• Impact: Contact and policyholder data was accessed.
• Source: BleepingComputer

🔹 Chanel

• Details: A breach was first reported in June, with confirmation reported on August 4, 2025 that the breach appears to be related to its Salesforce platform and the recent ShinyHunters activity.
• Impact: Both customer and employee data was stolen.
• Source: BleepingComputer

🔹 Cisco 

• Details: Cisco disclosed a breach involving Cisco.com account credentials. While not explicitly attributed to Salesforce, only a “CRM system,” attackers used stolen session tokens which is very similar to methods used in the ShinyHunters campaign.
• Impact: Contact info and registration data were exposed.
• Source: BleepingComputer

August 2025

🔹 Google 

• Details: On August 6, 2025 Google confirmed that ShinyHunters were behind the unauthorized access to one of it’s own Salesforce systems used for SMB outreach.
• Impact: Limited to business contact info; no sensitive internal Google data was accessed.
• Source: BleepingComputer
  

🔹 Air France & KLM

• Details: Attackers accessed customer data for both airlines’ frequent flyer programs, Flying Blue, via a third-party service provider. The method was session hijacking and unauthorized access to integrated SaaS systems which is consistent with the Salesforce/ShinyHunters campaign.
• Impact: Names, contact info, loyalty program details, and account status may have been exposed.
• Source: BleepingComputer

🔹 Workday

• Details: On August 22, Workday disclosed that it had been targeted in a broader social engineering campaign affecting multiple large enterprises. Attackers contacted employees via phone or text, impersonating HR or IT personnel, and gained access to business contact details stored in a third-party CRM platform. BleepingComputer confirmed the breach is part of the ShinyHunters campaign targeting Salesforce environments using malicious OAuth apps.
• Impact: Exposed data included business contact information such as names, email addresses, and phone numbers. No Workday customer tenant data or core HR system records were accessed.

• Sources: Workday Blog, BleepingComputer
  

🔹 Farmers Insurance

• Details: On August 22, Farmers Insurance began notifying over 1.1 million individuals of a data breach involving a third-party vendor. While the company did not name the platform in its public advisory, BleepingComputer confirmed the breach was part of the broader ShinyHunters campaign targeting Salesforce environments through malicious OAuth apps and social engineering tactics.
• Impact: Stolen data includes names, addresses, dates of birth, driver’s license numbers, and the last four digits of Social Security numbers. The breach occurred on May 29, 2025, and was detected the following day by the vendor’s monitoring tools.
• Source: BleepingComputer

September 2025

🔹 Stellantis

• Details: September 22, 2025, Stellantis, one of the world’s largest automakers, confirmed a data breach following the coordinated Salesforce campaign. Attackers exploited malicious Salesforce integrations to gain access to customer and employee records.
• Impact: Breach included personal data linked to customers and staff. Stellantis is working with investigators to determine the full scope of exposure.
• Source: BleepingComputer
  

We’ll keep watching

This campaign continues to unfold and may impact additional organizations. Vorlon is actively monitoring for new breach disclosures and will update this timeline regularly.

Looking for details on the Salesloft Drift incidents? That’s a separate campaign with different actors and TTPs—read our breach analysis here: Salesloft Drift Breach: What Happened and How to Protect Yourself.

FAQ 

What security teams need to know about the Salesforce Breaches and ShinyHunters:

1. How did attackers get into Salesforce in the first place?

Attackers used vishing and phishing against Salesforce admins, tricking them into authorizing malicious OAuth apps (like fake DataLoaders) with broad access. Once approved, those apps looked “legitimate” to Salesforce.

2. What role did ShinyHunters play in the breach?

Multiple groups were involved. ShinyHunters are best known for turning unauthorized access into extortion, taking advantage of already‑established footholds to exfiltrate data at scale and pressure victims.

3. Why are OAuth apps such an attractive target?

Because Salesforce — like most SaaS platforms — often grants OAuth apps long‑lived, high‑scope access. Once an admin says “yes,” attackers can sit quietly with near‑admin permissions until they’re ready to exploit it.

4. Why weren’t these apps detected right away?

Most legacy SaaS security posture management (SSPM) tools focus on configurations, not live data flows or new app authorizations. They miss the moment when a rogue OAuth app is created. Without continuous monitoring, attackers hide in the noise.

5. What data can fake OAuth apps actually access?

Depending on the scopes granted, these apps can exfiltrate bulk Salesforce records: customer PII, deal pipelines, financial data, even sensitive files. Many were seen running bulk query jobs before exfiltration.

6. How long were attackers inside before anyone noticed?

In many cases, weeks or months passed with no detection. Groups like ShinyHunters rely on this dwell time, exploiting the SaaS trust model until suspicious activity finally triggers an external alert or breach report.

7. Would standard MFA or SSO have stopped this?

Not fully. MFA protects user login, but once the OAuth app is authorized by an admin, it can often bypass MFA and act like a trusted integration. Extra monitoring of non‑human identities is required.

8. How can Vorlon detect these rogue OAuth apps?

Vorlon continuously tracks all new OAuth apps and identities across your SaaS stack. If a new, high‑risk OAuth app pops up in Salesforce (or any app), Vorlon immediately alerts and maps its permissions, data flows, and origins.

9. Can Vorlon distinguish normal third‑party apps from suspicious ones?

Yes. Vorlon builds a baseline of “known good apps” (like Marketo or Slack integrations) and can quickly flag the unexpected ones (like a fake “DataLoader”) so teams don’t get stuck in alert fatigue.

10. What about unusual IP addresses or geolocation anomalies?

Vorlon correlates OAuth activity with IP intelligence. In these breaches, malicious apps were used from TOR nodes and overseas IPs. Vorlon flags those anomalies instantly, so it’s clear that “normal Salesforce traffic” isn’t what it seems.

11. How does Vorlon help in response?

With Vorlon, teams can revoke OAuth secrets in just two clicks. That cuts off attacker access immediately, without waiting for Salesforce or a vendor escalation. This shrinks response time from days or weeks to minutes.

12. Can Vorlon show what data was exposed?

Yes. Vorlon maps data flow over time including what fields, records, and objects the OAuth app touched, and when. That means you’re not guessing about breach scope; you have evidence at your fingertips.

13. Does this only affect Salesforce?

No. While this campaign made headlines for Salesforce, the same tactic works on Microsoft 365, Google Workspace, Workday, and other SaaS apps. Vorlon monitors across the entire SaaS ecosystem, not just one platform.

14. How do we stop admins from approving malicious apps in the future?

You can’t rely only on training. Vorlon enforces continuous SaaS governance by watching for new OAuth consents, flagging risky scopes, and surfacing abnormal access before damage is done.

15. What’s the key takeaway for CISOs and SOC teams?

The Salesforce incidents prove that SaaS is now a prime attack surface. One compromised OAuth app can open the door to extortion campaigns across industries. With Vorlon, you can detect suspicious SaaS identities the moment they appear, map the impact, and shut them down before they spread.