Morton v. Salesforce and TransUnion puts SaaS trust on trial

Why Morton v. Salesforce matters

A new class action complaint filed this month, Morton v. Salesforce Inc. and TransUnion LLC, crystallizes the 2025 wave of social engineering hub-and-spoke attack methods that targeted Salesforce tenants through voice phishing (“vishing”). The filing accuses Salesforce of being the platform “hub” that enabled multiple “spoke” breaches and ties a TransUnion incident to the same pattern. These are allegations, not findings of liability.  

Historical context: Recent SaaS breaches to learn from

The alleged technique used in the Morton case sits alongside a run of cloud-adjacent incidents where routine support or development workflows became data-loss events.

Slack token theft, 2022

Threat actors used stolen employee tokens to access Slack’s external GitHub and download private code repositories. Slack reported that no customer data was exposed. The company disclosed the incident publicly and independent outlets corroborated the core details.

Okta support breach, 2023

Attackers accessed Okta’s customer support case management system and obtained files from a set of customers that included session tokens. Okta later said the incident ultimately exposed data about all customer support users. These facts were acknowledged by the company and widely reported.

Developer and support systems can become a front door for attacks. In Morton v. Salesforce and TransUnion, SaaS-based tools created the access path between the two organizations after the former was allegedly compromised by voice phishing over the phone. Security teams should treat any access path that can move sensitive data at scale, or that can mint access tokens as a protected interface, not a convenience.

What TransUnion has confirmed as fact

What is not in dispute: TransUnion has reported that attackers accessed personal data for roughly 4.46 million people in a breach discovered around July 30, 2025, involving a third-party application. That reporting came on August 26, 2025. The complaint also states that the defendants have acknowledged that personal data was accessed by unauthorized parties.  

The attack pattern at the center of the case

Alleged voice phishing technique

The complaint describes a voice phishing flow where an attacker impersonates IT support and persuades an employee to link an attacker-controlled Salesforce Data Loader to the company’s Salesforce environment by entering a connection code. Once linked, the actor exports Salesforce records and pivots into other connected cloud platforms belonging to enterprise client customers, such as TransUnion, to collect tokens, documents, and messages.  

Spread across multiple brands

The filing cites public reporting that “numerous data breaches” in 2025 were tied to this social-engineering method. The list includes several well-known brands. These references appear in the complaint as context for the plaintiff’s theory and should be treated as allegations.  

Timeline and scope of the TransUnion breach

The complaint alleges that attackers accessed data on or about July 28, 2025, that the exfiltrated data related to approximately 4.46 million individuals, and that notification understated the severity by calling the personal information “limited.” These are the plaintiff’s allegations.  

What the defendants have acknowledged as fact

TransUnion has stated that personal data for 4,461,511 people was accessed in a breach involving a third-party application and discovered around July 30, 2025. This is presented as fact based on the defendant’s own notice referenced in the complaint.  

The complaint also asserts that defendants have acknowledged that personal data was accessed by unauthorized parties. Because this is framed as a defendant admission within the complaint, this is presented as fact here as well.  

Everything else in the filing, including the “hub-and-spoke” theory of platform liability and claims about under-notification, is alleged and not adjudicated.  

What CISOs should take away

Whether or not the court accepts the plaintiff’s theory, the attack chain described in the complaint is painfully familiar. A motivated caller can still dupe a busy employee into authorizing a legitimate tool that then becomes a high-bandwidth exfiltration pipe. The lessons are blunt.

1. Voice-led approvals are still approvals. If your controls only look for malware, you are blind to a legitimate data-movement client that an employee just allowed.
2. SaaS-to-SaaS lateral movement is real. Once the client drains CRM records, the actor goes after connected identity and productivity systems. The complaint’s description of pivots into Okta or Microsoft 365 is exactly how modern cloud intrusions expand their blast radius.  
3. Logging, notification, and audit readiness. The injunctive relief requested by the plaintiff emphasizes logging, monitoring, and third-party audits such as SOC 2 Type 2. That is a forecast of discovery battles and post-incident obligations for any enterprise that suffers a similar pattern. These are requested remedies, not court orders.  

Controls that blunt this type of breach

Below are practical control moves that map to the attack steps described above. Each capability is available in the ThreatLocker® Zero Trust Endpoint Protection Platform.  

Deny by default at the endpoint

Application Allowlisting

Only software you explicitly trust should run. A deny-by-default policy blocks unapproved applications, scripts, and DLLs, which may include malicious or disguised data exfiltration tools. Application Allowlisting catalogs known and unknown apps in a Learning Mode, then lets you approve what you trust and block the rest. This directly limits abuse because malicious tools cannot run unless those tools’ file properties and hash digests are explicitly permitted by policy.  

Ringfencing^™  

Even trusted apps should only interact with what they must. Ringfencing constrains applications so they can only read or write to approved files, change certain registry keys, execute certain processes, or connect to specific network resources. That means even a permitted application cannot reach local data stores or launch processes that it does not need, or connect to unknown network destinations, constraining exfiltration paths created by social engineering.  

Network paths to limit egress

Network Control

Host-based, policy-driven firewalling lets you decide who can talk to what by port, source, and identity. Dynamic access control lists ensure that an endpoint port opens only when a known, authorized device is on the other end. For a data exfiltration scenario, the endpoint will not accept unexpected egress or lateral connections that are outside policy specifications. When the authorized session ends, the port closes.  

Least privilege that elevates software, not people

Elevation Control  

If an attacker convinces a user to “just run this application as an admin,” your day gets worse. Elevation Control grants administrative rights to specific applications for specific tasks rather than to whole user accounts. For instance, a user can request elevation for a known application installer, and you can approve it in one click, but generic local admin does not exist on that box anymore. That removes a common rung in the social engineering ladder.  

Data pathways that are explicit and reversible

Storage Control  

Policy-based access to local folders, network shares, removable media, and cloud storage closes off exfiltration routes and enforces least privilege.  Strict access means less attack surface, which means less opportunity for attack.

Web access that reduces phishing exposure

Web Control and Cloud Control

Blocking known phishing and policy-violating websites and allowing cloud tenant access only to known devices and trusted IPs, reduces the chance that a convincing voice phisher can steer an employee into a malicious setup page or token-stealing trap. The complaint’s technique depends on getting a user to a login screen and entering credentials. Limiting website access and permitting only trusted devices to CSP portals make that harder to accomplish.  

Detect what policy misses and respond quickly

Detect and Cyber Hero MDR  

Policy-driven endpoint detection that can isolate devices fast is the difference between a thousand event logs and a million. ThreatLocker Detect analyzes telemetry and indicators of compromise in real time, while the MDR team acts against validated threats based on your policies. Dwell time before taking mitigating action is shortened, and incident blast radius is reduced..  

Harden the identity and collaboration core

Cloud Detect for Microsoft 365

The complaint’s narrative describes malicious lateral movement into identity and productivity platforms.  Cloud Detect lets you craft policies to monitor Microsoft 365 and Graph log fields, enabling continuous visibility against anomalies, such as sign-ins from suspicious locations.  

Configuration that enforces the boring but vital

Configuration Manager and Patch Management  

The requested injunctions in the complaint read like a checklist of basic security controls that courts expect you to have nailed, such as training, monitoring, and regular secure configuration monitoring. Centralized, enforceable endpoint image baselines and automated patch coverage reduce the odds that an attacker finds an easy foothold or that you are criticized for lax security hygiene. The complaint’s requested remedies are allegations about what should change, but they mirror those included in almost every common security framework.  

Legal exposure in plain language

Alleged duties and failures  

The complaint frames duties around common law, Section 5 of the FTC Act, contracts, and industry standards. It argues defendants failed to implement reasonable measures to protect personal data, failed to detect and prevent dissemination, and failed to disclose the breach adequately and promptly. These are allegations, not findings.  

Causes of action and requested relief

Causes of action include negligence, negligence per se under the FTC Act, breach of implied contract, breach of fiduciary duty, and unjust enrichment. The plaintiff seeks damages and extensive injunctive relief, including logging, monitoring, education, and annual SOC 2 Type 2 assessments for ten years. These are requested remedies, not court-orders.  

Courts ask whether controls are designed and operating effectively, not just whether policies exist. A SOC 2 Type 2 attestation is an independent evaluation of security control operational success over time, which is why plaintiffs often request it and why regulators push for third-party assessments. If your logs, baselines, and reviews are solid today, these requests are routine. If they are not, they become years of expensive tech debt placed under an audit microscope.

Harm theory and claimed damages

The filing asserts present and future risk of identity theft, time and out-of-pocket costs, invasion of privacy, and diminution of personal data value. These are allegations that would need to be proven.  

SaaS access review checklist

IT operations

• Inventory all active SaaS applications and associated user accounts at least quarterly, disabling unused accounts and subscriptions.
• Enable MFA or SSO on every SaaS platform that supports it, prioritizing those with sensitive data or privileged functions.
• Use your identity provider (IdP) to ensure that onboarding, role changes, and offboarding automatically add or revoke SaaS access via integration.
• Audit external sharing and access permissions (e.g., guest users, public file links) regularly and revoke those not explicitly required.

GRC and compliance staff

• Establish a documented SaaS access review schedule, requiring application owners or department heads to verify user access and permissions quarterly.
• Map SaaS access requirements to compliance mandates (e.g., HIPAA, GDPR, PCI DSS), ensuring sensitive apps enforce additional authentication factors and stricter session policies.
• Maintain a centralized record of SaaS application security settings, including MFA status, session timeouts, tokens, password policies, and audit log retention periods.
• Add a voice phishing scenario to your next tabletop exercise draft.

Security architects

• If not done already, integrate SaaS authentication with your IdP to enable consistent access policies, single sign-on, and centralized revocation.
• Implement conditional access policies where supported. Restrict SaaS logins by device compliance, geolocation, or other risk signals.
• Enable continuous monitoring and anomaly detection for SaaS logins, particularly for privileged roles, to flag unusual access patterns or potential compromise.

CISOs and security leaders

• Adopt a policy requiring all new SaaS subscriptions to be reviewed for access control and authentication features before purchase.se.
• Include SaaS access metrics in security reporting, such as MFA adoption rates, number of apps integrated with SSO, and frequency of completed access reviews.

Next step: Protect your SaaS trust chain

In this case, attackers exploited human error to gain tokens and pivot between SaaS platforms. ThreatLocker® Cloud Control continuously monitors Microsoft 365 and SaaS connections to flag suspicious sign-ins, impossible travel, and risky behaviors. Use it to cut off token theft paths and strengthen the trust chain before it becomes a breach.  

Learn more about Cloud Control