Stealer logs and breach datasets can both contain account information, but they describe different collection paths. A service breach concerns information taken from a service or its systems. Stealer logs generally concern information collected from a device. A compilation may combine material from several sources without preserving a reliable history.
That distinction should shape the first sentence of an assessment. Seeing a company domain in exposed data does not, by itself, establish that the company's infrastructure was breached.
Compare the source types
| Source type | What the label suggests | What still needs confirmation |
|---|---|---|
| Stealer log | Account information collected from a device | Which device, when collection occurred, and whether the source attribution is reliable |
| Service-breach dataset | Information taken from a service or its systems | Whether the claimed incident and dataset are authentic |
| Compilation | Material gathered from one or more earlier sources | Original provenance, repeated records, and dates |
A collection label helps frame the review. The evidence must support the attribution before you treat it as established.
What a stealer-log entry can show
Have I Been Pwned's stealer-log documentation distinguishes a website domain, an email address, and the email's domain. Those fields answer different questions: which service was referenced, which account string appeared, and which organization may control the email domain.
Consider a fictional record connecting [email protected] with documents.example.net. The email domain and the service domain are different. The record provides an association to examine; it does not identify which organization lost data from its own systems.
A URL can also be a historical address, a redirect target, or a hostname that has since changed ownership. Preserve the observed value in the evidence and verify current ownership separately when that matters to your assessment.
What a service-breach dataset can show
A dataset attributed to a service breach may include account details copied from that service. Its usefulness depends on provenance: what is known about the source, whether the claimed incident has independent support, and which fields are actually present.
“Breach data” is a broad label. It should not erase differences between an original dataset, a later compilation, and a file with an unverified title. An archive name is a claim made by whoever named it. It is not independent confirmation of the incident, its date, or its contents.
For any source type, keep observations separate from attribution. “This record contains this hostname” is a direct observation. “An attacker stole it from that company's database last week” requires additional evidence.
Why password and session exposure differ
Credentials are only one possible part of an account-access problem. Session cookies represent another type of evidence with different implications. Microsoft's session-cookie theft guidance describes an attack in which an intermediary captures both a password and a session cookie.
A password-only exposure record cannot tell you whether a cookie was also captured, whether a session was active, or whether an attacker successfully used either. Do not infer the presence of tokens or device telemetry from a dataset that does not contain them.
Likewise, seeing a password in a collection does not demonstrate that an organization's MFA was bypassed. Authentication configuration and sign-in evidence must be checked through systems authorized for that purpose.
Four questions to ask about a source
What is directly observable? Identify the fields available in the actual record. Distinguish complete values from missing, truncated, or normalized fields.
Where does the attribution come from? Record whether the source identity is established, claimed by a distributor, or unknown. Avoid turning a collection label into a verified incident name.
What does the date describe? A source filename, archive creation date, publication date, and indexing date are separate concepts. An apparent date in a title may not describe the original capture.
What could be duplicated? Repeated records across files may be copies of one underlying exposure. More observations can improve source context without proving more compromises.
These questions make it easier to compare collections while preserving uncertainty. They also prevent a large archive from dominating a report solely because it contains repeated rows.
Apply the distinction in an organization review
Start from authorized scope. Check company-operated services and work email addresses as separate views, then examine the overlap. If a work address appears alongside an external service, investigate the account association without accusing that service of a breach.
Vuxep supports searches within verified domains and lets reviewers trace search results to available source evidence. Employee profiles collect affected services and priority reasons in one place. The profile provides context; it does not authenticate a person's current relationship to the organization or confirm that a listed credential works.
For colleagues outside security, use language they can interpret accurately: “work email observed in indexed exposure data,” “service referenced in the record,” and “source attribution unconfirmed,” where applicable. Explicit limits make a report more credible.
Keep the evidence useful
Treat source type as context for the next question, not as an automatic verdict. Reliable assessment combines the observed record with the organization's own account, service, and security information.
Read first indexed versus breach date before comparing findings over time. For signals that connect multiple services, see how to interpret password reuse at work.