Infostealer credential harvesting
Commodity malware on an endpoint reads whatever the browser and OS have stored in the clear or under a key the same machine already holds, then ships it to a marketplace where the credentials outlive the machine they came from.
How it works
Infostealer malware (RedLine, Lumma, and their successors) is built for one job: land on an endpoint, read every credential store the browser and operating system expose, and exfiltrate the result before anyone notices. Browsers keep saved passwords, autofill data, and session cookies in local databases that are readable by any process running as the logged-in user, because the browser needs to read them itself on every page load. The malware does not need to break encryption or escalate privileges; it just asks for the same files the browser already opens. A single infection typically yields a bundle: passwords, active session cookies, browser history, and sometimes cryptocurrency wallet files, packaged and sold or dumped in bulk on criminal marketplaces.
The credentials in these logs do not expire when the malware is removed. A password harvested in 2020 and never rotated still authenticates in 2024 if nothing forced a change. That is exactly what happened in the 2024 Snowflake customer breaches: accounts were compromised using credentials pulled from infostealer logs harvested years earlier, on accounts that had gone without MFA and without a password rotation for up to four years. Connor Riley Moucka pleaded guilty in August 2026 to computer fraud, wire fraud, aggravated identity theft, and conspiracy over that campaign, which reached at least 165 organizations and records on at least 100 million people.
Why it works
The control assumption that fails is that a password is a secret known only to its owner. An infostealer breaks that assumption at the source: it does not guess or intercept the password, it reads it from local storage the same way the legitimate application does, and the theft leaves no trace at the authentication server because no failed login ever occurs. The second assumption that fails is shelf life. Most organizations treat password rotation as a compliance checkbox rather than a response to a specific exposure, so a credential stolen years earlier remains valid indefinitely unless something else forces a change. Endpoint compromise, not directory compromise, is the actual failure point, and directory-side controls like account lockout do nothing to stop it.
How to detect it
- Credentials for corporate domains appearing in infostealer log dumps and marketplaces, found through monitoring services that track these sources.
- A login using a password that has never been entered through the organization's own authentication flow before, which suggests it came from a store rather than a memory.
- Authentication from a device or endpoint with no history of security agent check-ins, immediately followed by activity consistent with account takeover.
Be honest about the limits: infostealer dumps are enormous and noisy, credentials in them may be stale, already rotated, or belong to accounts no longer in use, and matching a leaked credential to a live account does not by itself prove compromise happened. This is a monitoring and rotation trigger, not a detection that fires on the theft itself, since the theft happens entirely on the victim's endpoint outside any system the defender can observe.
How to stop it
- Enforce MFA on every account, including service and legacy accounts, so a harvested password alone is not sufficient for access. Snowflake moved to make this mandatory after 2024.
- Rotate credentials on a schedule you actually verify, since an unrotated password has no expiration and remains useful to whoever holds the infostealer log years later.
- Deploy endpoint protection built to catch infostealers, and treat the browser's credential and cookie stores as a protected surface rather than an implicit trust boundary.
- Monitor infostealer marketplaces and dumps for your own domains, so a leaked credential triggers a forced rotation before it is used rather than after.
- Move toward passkeys or workload-issued credentials where the underlying secret cannot be copied out of local storage the way a password or session cookie can. See infostealer.
Seen in the wild
- Infostealers and session hijacking: stealing the session, skipping the login
- The 2024 Snowflake customer breaches: stolen credentials meet missing MFA
- The Snowflake attacker pleaded guilty, two years after stale credentials did the work
Sources
Related identity CVEs and breaches
Related on Start with Identity
- Blog1Password buys Apono, moving from credential vault to access control plane
Reported at 250 to 300 million dollars, the deal gives 1Password just-in-time privileged access across AWS, Azure, GCP, Kubernetes, Snowflake, and Databricks, a
- RankingBest Verifiable Credential Platforms: Issuance & Verification Infrastructure
The best verifiable credential platforms in 2026: MATTR, Procivis, SpruceID, walt.id, and Hyperledger. Ranked for standards conformance (W3C VC, SD-JWT, OpenID4
- BlogChick-fil-A's second credential stuffing breach in three years hit 13,322 loyalty accounts
Automated login attempts using credentials obtained from a third-party source, not a Chick-fil-A breach, compromised 13,322 Chick-fil-A One loyalty accounts ove
- TechniqueCredential manager key extraction
A passkey or Windows Hello key is supposed to stay locked to its device. Code running on an already-compromised endpoint can pull the key material out of the pr
- TechniqueCredential stuffing
Attackers replay username and password pairs leaked from one breach against every other login page they can reach, betting on the well-documented habit of passw
- GlossaryCredential Stuffing
An attack that replays username and password pairs leaked from other breaches against a target, exploiting password reuse. Defended with MFA, passkeys, and bot