TransUnion 2025: Third-Party App Abuse, OAuth Access, and 4.46M Affected

Casmer Labs is the internal threat research team within Cloud Storage Security. We track significant activity in cybersecurity, cloud security, and cloud data security. Our goal is to document what occurred, how it occurred, and which controls are relevant.

The Breakdown

On July 28 2025 TransUnion experienced unauthorized access to personal data through a third party application used in its United States consumer support operations. The activity was identified on July 30 2025.

TransUnion stated that approximately four million four hundred sixty one thousand five hundred eleven United States individuals were affected. TransUnion stated that its core credit database and consumer credit reports were not accessed. TransUnion also stated that affected individuals are being offered twenty four months of credit monitoring and identity protection.

Samples of data shared by the threat actor and described in public reporting indicate that the exposed data included full name billing address phone number email address date of birth and Social Security number in some cases not redacted. Some reporting stated that portions of customer support interaction history were also present. That material was described as ticket or message content from consumer support systems. TransUnion did not confirm every individual field but the data set has been widely described as containing identity level information.

This is not basic marketing contact data. It includes data points that are routinely used to verify identity.

The How

Public reporting links this incident to a broader activity pattern seen in 2025. This pattern targets customer service and support systems that sit on top of software as a service platforms such as customer relationship management and case management systems.

In this pattern the attacker does not exploit the vendor platform directly. Instead the attacker gains access that appears to be a legitimate integration and then uses that access to export customer records in bulk.

Two techniques have been repeatedly described by incident responders and industry analysts.

One social engineering also called voice phishing or vishing. An attacker poses as internal information technology and convinces an employee to authorize a connected application. That application is granted OAuth scoped access. The attacker then uses that access to pull large volumes of data through normal interfaces. The application is often presented as a routine export or loader utility.

Two use of existing third party integrations. Many support teams rely on external chatbots engagement tools analytics tools or ticket assistants that are already connected to support data. If an attacker gains the tokens or keys for one of those integrations the attacker can query and export customer data without performing a normal interactive login. In logs this activity can appear to be an approved system to system sync.

Response teams have referred to related activity clusters with labels such as UNC six zero four zero and UNC six three nine five. Some public reporting has also associated related extortion activity with financially motivated groups such as ShinyHunters. Statements from Salesforce have emphasized that these campaigns are not based on a direct exploit of the Salesforce platform. They rely on social engineering and on integrations that have broad access.

TransUnion publicly described this incident as involving a third party application tied to consumer support. That description aligns with the techniques above. TransUnion stated that core credit systems were not directly compromised.

The Main Problem

The primary weakness in this class of incident is access governance for third party and software as a service integrations.

In these cases the attacker is able to

• Obtain or convince approval for an application with broad export scopes

• Use OAuth tokens or other integration credentials to pull high volumes of data through allowed interfaces

• Operate in a way that resembles routine export or sync traffic

There are two direct results

1. The export traffic is technically permitted at the time it occurs. An application with valid scopes is making an approved call. Basic alerting that focuses on unusual human logins or password failures will not always detect this.

2. The exported data is high value. It includes full name address date of birth Social Security number and recent support context. That data can be used to impersonate a lender a collections agent a financial institution or the company itself. It supports targeted fraud and identity theft even if core credit files were not accessed.

What Organizations Should Do Now

No single control guarantees prevention. The following controls are widely recommended to reduce exposure and limit dwell time.

1. Restrict connected applications
   

   Maintain an allow list of connected applications that are permitted to access customer data. Limit which employees are able to approve or expand scopes for new applications. Remove unused applications. Revoke tokens for integrations that are not required.

2. Apply least privilege to export access
   

   Do not grant bulk export rights to routine support accounts. Only a small number of controlled service identities should be able to run large exports or pull full customer records. Where possible make those permissions time bound.

3. Use network and session restrictions
   

   Require access to sensitive software as a service systems from known network locations or approved egress ranges. Enforce controls so that authorizing a new connected application or expanding scopes cannot be performed from arbitrary locations.

4. Monitor export activity
   

   Enable logging and alerting for large exports outside normal hours newly approved connected applications and fast sequence queries that sweep entire customer records. Capabilities such as Event Monitoring Transaction Security and Salesforce Shield can provide useful signal. The objective is to identify export patterns that are unusual in volume timing or source.

5. Harden user verification against voice phishing
   

   Adopt a do not act on inbound contact rule for support and operations staff. Require a call back on a known internal number or a ticket based verification step before approving any request to enable a new integration expand scopes or provide a code.

Why Storage Still Matters After a SaaS Breach

In incidents of this type the initial access occurs in a software as a service system such as a customer relationship management platform or support system. The attacker exports data from that system.

In most organizations exported data does not stay only in that platform. Copies are often staged in cloud storage for reporting analytics investigation discovery legal hold or data lake ingestion.

That staging commonly happens in Amazon S3 EBS snapshots EFS file systems FSx file systems and Glacier vaults. At that point the risk profile changes. The question is no longer only who accessed the software as a service platform. The questions become

• Where is that exported data now

• Who can access it

• How is that storage configured

• Is anyone listing or downloading it in bulk

This is the point where data security posture management for cloud storage also called DSPM for cloud storage becomes relevant. DSPM for cloud storage focuses on locating sensitive data in storage identifying who can reach it confirming storage posture and detecting unusual access behavior such as large transfers or mass reads.

How DataDefender Helps

It is designed to help security and compliance teams control what happens after sensitive data leaves a software as a service system and lands in cloud storage.

1. Inventory and ownership
   

   DataDefender maintains a live inventory of storage resources across connected AWS accounts. This includes Amazon S3, EBS snapshots, EFS file systems, FSx file systems, and Glacier vaults. The inventory includes owner business purpose exposure status encryption state recent activity and other context that is difficult to maintain manually. This shortens the time it takes to answer where the exported data went.

2. Classification of sensitive data
   

   This DSPM platform identifies storage locations that contain high risk personal data such as Social Security numbers and dates of birth. This allows teams to prioritize those locations for immediate review tighter access and additional logging.

3. Activity monitoring
   

   It records which identities accessed which objects and when. It highlights unusual or bulk access patterns such as large transfers or access from unfamiliar identities. This helps security teams assess possible data exfiltration insider misuse or ransomware style staging activity in storage.

4. Continuous posture checks
   

   DataDefender continuously evaluates storage posture. It checks for publicly accessible S3 buckets permissive access control lists broad cross account access insecure snapshots missing encryption weak retention settings and lack of immutability. The goal is to surface misconfigurations before they become a second incident.

5. Evidence for audit and notification
   

   This DSPM tool links actor time and object level access. During incident response this supports creation of a timeline that shows when a bucket or file system became exposed which identities accessed which objects and when access was removed. That timeline supports internal legal and regulatory obligations.

About Cloud Storage Security

Cloud Storage Security protects the storage layer in the cloud. DataDefender is a storage focused data security posture management and activity monitoring platform. It is designed to help organizations limit ransomware spread identify signs of data exfiltration and detect insider misuse by giving security teams continuous visibility into who is accessing what in cloud storage and how that storage is configured.

Cloud Storage Security also provides Antivirus for Cloud Storage. Antivirus for Cloud Storage is an in tenant multi engine malware scanning capability for object storage. It is designed to identify known malicious files including ransomware tooling before those files are widely distributed.

Key Takeaway

In this incident attackers did not gain direct access to a core credit database. They used access to a third party support application to obtain personal data including contact information date of birth and Social Security number for more than four million individuals.

The first control point is at the software as a service layer. Organizations must limit which applications can export data and must detect suspicious export behavior. The second control point is at the cloud storage layer. Once data leaves the support system and is staged in storage organizations need continuous visibility classification activity monitoring and storage posture checks. This is the role of DSPM for cloud storage and it is the focus of DataDefender.