Why the Source of Exposed Credentials Changes the Response

A total of 35 breach events were found and analysed resulting in 35,167,061 exposed accounts containing a total of 42 different data types of personal datum. The breaches found publicly and freely available included ULP Alien Txt File - Episode 45, Carharrt, Free-Crypto, Stealer Log 0572 and Enroll-Blog. Sign in to view the full library of breach events which includes, where available, reference articles relating to each breach.

The inclusion of both a ULP collection and a stealer log makes the origin of exposed credentials this week’s most useful theme. A password republished in a compiled collection and a credential captured from an infected device may look similar when reduced to a database field, but they can require very different investigations.

For security teams, finding an exposed credential is only the beginning. Understanding how it was obtained helps determine what else could be at risk and what needs to happen next.

Not every credential exposure represents the same problem

ULP collections are organised around URL, login and password fields. They may bring together credentials associated with numerous services and can contain a mixture of recent, historical, duplicated and republished material.

An episode number describes how a collection has been packaged or catalogued. It should not be treated as the date on which every underlying credential was captured.

A stealer log has a different context. It is associated with information-stealing malware operating on a device. Depending on the malware and captured material, the exposure may extend beyond a single username and password to browser data, authentication cookies, device information or other locally accessible records.

This does not mean that every stealer log contains every possible artefact. It means that defenders should investigate the affected device and its sessions rather than treating the finding solely as a password problem.

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.

The sample crosses personal and professional account use

At title level, the named examples span retail, cryptocurrency-themed and enrolment or publishing contexts, alongside the credential collections.

Carharrt has been retained exactly as recorded in the source title rather than silently normalised to a similarly named organisation. This distinction matters because breach labels should not be altered solely to fit an assumed company or service.

The variety of account contexts is still useful for B2B defenders. Employees do not maintain completely separate digital lives. The same phone, laptop, browser, email address or password habit may be used across work accounts and external services.

A retail account may have no direct connection to an employer. A crypto-themed service may be entirely personal. An enrolment or blogging account may relate to education, publishing or an individual interest. Yet exposure can become organisationally relevant if credentials are reused, sessions are captured from a work device or the account helps build a more complete picture of the employee.

The issue is not that every personal breach creates a corporate incident. It is that the boundary between personal and professional identity is often thinner than the boundary between their respective systems.

Why a stealer log requires a broader investigation

When a credential is found in a compiled collection, the immediate questions usually concern whether the password is current, where it was reused and whether there has been suspicious authentication activity.

When a credential is connected to a stealer log, additional questions become necessary:
- Which device was involved?
- Was the device personally owned or managed by the organisation?
- Which accounts were accessed through that device?
- Were browser sessions or authentication cookies potentially exposed?
- Did the device have access to corporate email, cloud applications or administration portals?
- Has the original infection or unwanted software been removed?
- Were passwords changed before or after the device was made safe?

The order of response matters. Changing a password from a device that remains compromised may expose the replacement credential. Resetting a password without revoking existing sessions may also leave another route into the account.

The NCSC’s analysis of traditional and FIDO2 credentials discusses credential-stealing malware and the security implications of credentials or session information held on devices. [Read the NCSC comparison of traditional and FIDO2 credentials](https://www.ncsc.gov.uk/sites/default/files/2026-04/Comparing-the-security-properties-of-traditional-user-credentials-and-FIDO2-credentials-for-personal-use.pdf).

A correct password is not the only proof of access

Many security processes still treat the password as the centre of an account investigation. Modern authentication involves a wider set of components:
- The credential used to begin authentication
- The additional factor used to approve access
- The device from which access is requested
- The session created after authentication
- Recovery email addresses and telephone numbers
- Connected applications and delegated permissions
- Tokens that allow applications to retain access

If a password is the only affected component, rotating it may be sufficient when combined with a review of recent activity.

If the device or session is affected, the response needs to go further. Active sessions may need to be revoked, remembered devices removed, recovery settings reviewed and connected applications checked. The endpoint may require isolation, investigation or rebuilding before the user signs in again.

This is why security teams need provenance. Two identical email-and-password pairs can represent different levels of organisational risk depending on where and how they were acquired.

What the headline numbers do and do not tell us

The 35,167,061 exposed accounts should not be interpreted as the same number of unique or newly affected people. Compiled collections may contain:
- Credentials already present in earlier releases
- Duplicate records across different files
- Old passwords that have since been changed
- Inactive or abandoned accounts
- Several accounts belonging to one person
- Records associated with services that no longer exist

The 42 different data types were identified across all 35 events. This does not mean that every record contained all 42 types.

Likewise, the presence of one stealer-log event does not mean that all accounts in this week’s findings came from infected devices. Each event needs to be classified and assessed according to its own provenance.

Volume helps describe the scale of the material being processed. It does not replace the more important questions of currency, uniqueness, source and consequence.

Three defensive checks for B2B organisations

1. Classify exposure before selecting the response
Response procedures should distinguish between a service-specific breach, compiled credential collection and device-derived stealer log.

The classification should influence the investigation scope. A compiled credential may trigger checks for password reuse and suspicious logins. A stealer-log match should also trigger endpoint, browser-session and token considerations.

This prevents every exposure from being handled through the same generic password-reset workflow.

2. Use the correct sequence for device-related exposure
Where a managed device may be involved, establish whether it is safe before introducing replacement credentials. Depending on the evidence, this can involve isolating the endpoint, collecting relevant security telemetry, removing the cause of compromise and rebuilding the device.

From a trusted device, rotate affected credentials, revoke active sessions and review recovery options, connected applications and authentication factors. Higher-consequence accounts should receive priority, including email, identity administration, finance and remote-access services.

3. Reduce what a stolen credential can achieve
Prevent users from selecting known-compromised passwords and support unique credentials through password managers. Introduce phishing-resistant authentication, such as passkeys or hardware-backed FIDO credentials, where practical.

Authentication monitoring should also consider device reputation, unusual session creation, impossible travel, unexpected changes to recovery settings and access inconsistent with the user’s normal role.

These controls recognise that some credentials will eventually be exposed and limit the consequences when that happens.

The wider lesson

This week’s sample demonstrates why “change the password” is not a complete incident-response strategy.

A historical credential found in a ULP collection may require validation, monitoring and a targeted reset. A credential connected to a stealer log may point to a compromised device, exposed browser sessions and multiple affected services. Treating those situations as equivalent can leave important access routes unexamined.

Businesses do not need to assume that every exposed credential has been used or that every stealer-log match represents an active corporate compromise. They do need a repeatable way to distinguish the possibilities.

The most useful question is not simply, “Was a password exposed?” It is, “What does the source tell us about the device, session and identities that may also need protection?”