Your Business Identity Extends Beyond Your Own Systems

A total of 42 breach events were found and analysed resulting in 60,002,192 exposed accounts containing a total of 50 different data types of personal datum. The breaches found publicly and freely available included ZoomInfo, ULP Alien Txt File - Episode 44, Exact Sciences, RingCentral and Stripe [Part 1]. Sign in to view the full library of breach events which includes, where available, reference articles relating to each breach.

The sample spans commercial intelligence, healthcare diagnostics, business communications, financial infrastructure and credential-focused material. These are very different environments, but they share an important characteristic: each can hold information that connects people to organisations, services and business processes.

For B2B security teams, the lesson is that organisational identity no longer exists entirely inside the corporate network. It is distributed across external platforms that support how businesses communicate, sell, recruit, provide services and receive payments.

What the sample tells us about interconnected business identity

The named examples represent several parts of the modern business ecosystem. ZoomInfo describes its services as go-to-market software, data and intelligence used by sales, marketing, operations and recruitment teams. RingCentral provides business communications across voice, messaging, video and contact-centre services. Stripe supplies infrastructure for payments and other financial services. Exact Sciences operates in cancer screening and diagnostics. [ZoomInfo’s regulatory filing describes its business platform](https://www.sec.gov/Archives/edgar/data/1794515/000179451525000075/zoominfo10k2024printvf.pdf), while [RingCentral](https://ir.ringcentral.com/home/), [Stripe](https://stripe.com/) and [Exact Sciences](https://www.exactsciences.com/about) explain their respective services on their official websites.

This context does not establish which data types were present in each event. It should not be used to infer that financial, medical, communications or customer data was necessarily included in any specific example.

What it does show is the variety of third-party environments in which business identities can be represented. An employee might be listed as a commercial contact, registered as a communications user, associated with a payment account or connected to a healthcare service.

Exposure in one of these environments can therefore have relevance beyond the platform where the information originated.

The BreachAware team has recorded and reviewed the provenance of this material. The descriptions shared here are intentionally limited, providing defenders with useful context without publishing source locations, detailed contents or information that could encourage misuse.

External platforms can reveal internal relationships

Many business platforms need to understand relationships in order to provide their services. They may connect an individual to an employer, department, customer, account, transaction, communication channel or administrative role.

Those relationships can become important security context when exposed.

For example, knowing that somebody works in sales is relatively general information. Connecting that person to particular organisations, responsibilities or communication tools can make the information more useful. The value comes from the relationship between the fields rather than from any single field viewed alone.

The same principle applies across business functions:
- Commercial information can connect employees with customers and prospects.
- Communications information can identify channels used for business conversations.
- Platform account information can associate individuals with particular services.
- Professional details can indicate seniority or decision-making responsibility.
- Contact information can provide a route for approaching the individual.
- Authentication data can potentially connect an identity with an access attempt.

These are general examples of how business information can be used. They are not claims about the contents or subsequent use of the named events.

Credential collections add another layer

ULP Alien Txt File – Episode 44 is structured and labelled as a URL, login and password collection. Its presence alongside named organisations highlights the difference between an event associated with a particular service and a collection organised around credentials.

The episode number is a packaging or cataloguing label. It should not be treated as the date on which every underlying account was compromised.

Credential collections may contain historical information, duplicate records, inactive accounts and material previously circulated elsewhere. They can also contain information associated with many unrelated services. This makes their headline volume difficult to translate directly into a count of newly affected people or organisations.

Their defensive relevance comes from the possibility that some credentials remain current or have been reused. A credential associated with an external service may also be tested against workplace email, remote-access systems or other business applications.

This is one reason organisations should not assess exposure solely according to whether their own domain or systems were identified as the original source.

Labels such as “Part 1” require careful interpretation

Stripe [Part 1] provides another example of why collection names should not be treated as conclusions. A “Part 1” label indicates how material has been divided or released. It does not, by itself, establish the complete size of an event, the existence or contents of further parts, the date of the underlying exposure or which Stripe products and relationships may be represented.

Similarly, the presence of a company name does not automatically mean that every record belongs to a direct customer of that organisation. Modern platforms may involve users, administrators, merchants, employees, partners, contractors or other connected parties.

For defenders, labels are useful starting points for classification. Impact decisions should be based on verified records, relevant data types, current organisational relationships and the privileges associated with matched identities.

Why the 50 data types deserve attention

The 50 different data types were identified across all 42 events. They were not necessarily present in every event or every account. Equally, the 60,002,192 exposed accounts should not be interpreted as 60 million unique or newly affected people. The total may include duplicates, historical records, multiple accounts belonging to one person and overlap between collections.

Even with those qualifications, data diversity is an important consideration. Different fields can reinforce one another. Contact information, employment details, service associations and authentication data may each have limited value in isolation, but together they can create a more complete and credible representation of an individual.

Security teams should therefore look beyond record counts and ask:
- Which identities match our current workforce or trusted partners?
- Which matched individuals hold sensitive roles or privileges?
- Which exposed fields could support impersonation or account recovery?
- Is the information current enough to influence a business process?
- Does it reveal a relationship that is not otherwise obvious?

This produces a more useful assessment than treating every record as equally significant.

Three defensive checks for B2B organisations

1. Map where business identities exist outside the company
Maintain an inventory of important external platforms used for communications, payments, sales, recruitment, customer management and specialist services.

The inventory should identify who administers each platform, how users authenticate, what organisational information it contains and how access is removed when somebody changes role or leaves.

This is not only a supplier list. It is a map of where employee and business identities are represented beyond systems directly controlled by the organisation.

2. Prioritise identities according to consequence
An exposed record linked to a general marketing contact does not necessarily create the same risk as one linked to a finance approver, platform administrator or executive.

Monitoring and response should account for role, privilege and process authority. Higher-consequence identities may justify stronger authentication, additional alerting and more frequent reviews of recovery methods, connected applications and active sessions.

Compromised-password screening and phishing-resistant authentication can also reduce dependence on passwords that may have been reused across external services.

3. Protect business decisions as well as accounts
Strong authentication is important, but many identity-based attacks attempt to influence a person rather than directly access a system.

Requests involving payments, bank-detail changes, sensitive records, account recovery or new administrative access should require independent verification. The confirmation method should use trusted contact details or an established workflow rather than information supplied within the request itself.

This makes accurate names, job titles and platform associations less effective as substitutes for genuine authority.

The wider lesson

This week’s findings should not be interpreted as evidence of a single common cause or a coordinated campaign across the named organisations. The sample covers different sectors, services and forms of exposed material.

The common defensive theme is dependency.

Businesses depend on external platforms to maintain relationships and complete important work. Those platforms can hold pieces of organisational identity that remain relevant even when exposure occurs beyond the company’s own technical perimeter.

A mature response begins by recognising that identity is distributed. It then determines which external accounts, relationships and data fields could affect access or decision-making inside the business.

The aim is not to withdraw from useful platforms or treat every external record as an emergency. It is to make sure that no single exposed detail, reused credential or convincing business relationship is sufficient to bypass the organisation’s controls.