A stealer log finding usually points to data captured from an infected endpoint, often including active session material or saved secrets. A leaked credential finding means the identity material has entered broader reuse channels such as dumps or paste sites. The first is closer to device compromise, while the second is closer to replay risk across multiple services.
How to tell an infected-endpoint artifact from a wider credential leak
A stealer log finding is usually the stronger signal that the source endpoint itself was compromised. It often contains browser sessions, cookies, tokens, saved passwords, or other material pulled directly from a device, so the immediate question is whether the endpoint and anything authenticated from it are still trustworthy.
A leaked credential finding is broader in distribution and weaker in provenance. It tells you the secret, token, or password has escaped into reuse channels, but not necessarily that the originating device was actively infected. That distinction matters because the first often starts with endpoint containment, while the second starts with exposure assessment and credential governance.
Why the two findings imply different security actions
Stealer logs usually imply a compromise path: malware ran on an endpoint, harvested usable authentication material, and may have captured live sessions that remain valid until revoked. Infostealer Threat Guide is useful here because it explains how session theft, browser data theft, and stealer marketplaces change the response from simple password reset to broader session and token invalidation.
A leaked credential finding implies a reuse path: the secret may now appear in dumps, paste sites, combo lists, or other channels where it can be replayed against multiple services. That means the same credential can become a cross-service authentication problem, especially if it was reused, long-lived, or paired with weak session controls. API Key Management Guide is a good companion when the leaked material is an API key or bearer credential, because the operational question becomes rotation, revocation, and scope reduction.
The practical difference is therefore not just where the data was found, but what the finding tells you about the likely blast radius. Stealer logs suggest endpoint-origin compromise and possible active session abuse. Leaked credentials suggest broader exposure, including replay attempts against multiple services, federated logins, and downstream automation that may still trust the credential.
How to triage each finding without overreacting or underreacting
If the finding is a stealer log, first confirm whether the affected workstation or user context is still active, whether the exposed material includes session cookies or tokens, and whether the identity can still access critical systems. If the finding is a leaked credential, first determine whether the secret is still valid, where it has been published, and whether it was ever used outside its intended scope. Leaked Credential and Secret Incident Response Playbook is relevant because it aligns the response sequence to the exposure type instead of treating all secret leaks the same.
Rotation alone is not always enough. For stealer logs, you often need to revoke sessions, invalidate refresh tokens, and look for lateral use from the compromised endpoint. For leaked credentials, you need to assess whether the secret was already embedded in scripts, CI/CD, mobile apps, or integrations that will break if you revoke it too aggressively. That is why the response should be based on the credential’s role, not just on the fact that it leaked.
When the item is ambiguous, treat the finding as a provenance problem first and a credential problem second. A stealer log can contain a leaked credential, and a leaked credential can later appear inside stealer logs. The deciding factor is whether the strongest evidence points to endpoint infection, public reuse, or both.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stealer logs and leaked credentials both center on exposed secrets and tokens. |
| NHI-04 — Insecure Authentication | The distinction changes how stolen session and credential material can be replayed. | |
| NHI-07 — Long-Lived Secrets | Both finding types are worse when the exposed credential remains valid for long periods. | |
| Recommendation — Classify exposed material by secret type and revoke or rotate it promptly. Invalidate compromised sessions and harden authentication paths against replay. Reduce secret lifetime so exposed material expires before it can be reused. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The topic turns on protecting, rotating, and revoking credentials and tokens. |
| IA-9 — Service Identification and Authentication | Leaked API keys and tokens often function as service or workload authenticators. | |
| AC-2 — Account Management | Stealer logs and leaked credentials both require reviewing account status and access paths. | |
| Recommendation — Rotate exposed authenticators and remove any no-longer-needed credentials. Reissue service credentials and tighten trust paths after exposure. Review affected accounts and disable or remediate unnecessary access. | ||
| MITRE ATT&CK | T1555 — Credentials from Password Stores | Stealer logs commonly include browser-stored passwords and session material from endpoints. |
| T1528 — Steal Application Access Token | The findings often involve stolen tokens, cookies, or other replayable auth material. | |
| Recommendation — Hunt for password-store theft and validate endpoint compromise indicators. Track stolen token use and invalidate any bearer material that was exposed. | ||
| CIS Controls v8 | CIS-5 — Account Management | The response depends on rapidly identifying, disabling, and reviewing exposed accounts. |
| CIS-6 — Access Control Management | Credential exposure requires immediate control over who can still authenticate and where. | |
| Recommendation — Inventory affected accounts and remove access that is no longer required. Revoke exposed access paths and reissue credentials with tighter scope. | ||
Practitioner Guidance
What to verify: Confirm whether the finding contains active session material, long-lived secrets, or only a static password. That determines whether you need endpoint containment, session revocation, credential rotation, or all three.
Decision rule: If the artifact came from an infected device, treat it as potential live session compromise until proven otherwise. If it came from public reuse channels, treat it as likely replay exposure even if the original endpoint looks clean.
Common mistake: Teams often reset passwords and stop there. That misses session cookies, refresh tokens, API keys, and service credentials that remain valid after a password change.
Practitioner takeaway: The most important distinction is not “leaked versus stolen”, it is “endpoint compromise versus broad reuse risk”, because that determines whether the right response is containment, revocation, rotation, or all three.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- What is the difference between SAST and DAST for security teams?
- What is the difference between finding a suspected credential and proving it is exploitable?
- What is the difference between finding a leaked AWS key and knowing its effective blast radius?