Start with Identity
SWI-T021 · Credential storage

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.

WidespreadHard to detect to detect
First observed: 2019ATT&CK T1555.003

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

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email [email protected]. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.