---
title: Stolen logins and infostealers
summary: Why most break-ins are now just log-ins, where the passwords come from, and why a second factor on every account is the single cheapest defence there is.
topic: attacks
order: 4
updated: 2026-09-23
---

## What it is

Most attackers no longer break in. **They log in**, with a real username and password that
was stolen somewhere else. There are three main sources:

- **Old breaches.** Billions of email and password pairs from past leaks are traded freely.
  People reuse passwords, so a leak at a game site opens a work account.
- **Credential stuffing.** A bot tries those pairs against your login page, thousands per
  minute, from thousands of IP addresses.
- **Infostealers.** Malware, often hidden in a pirated game, a cracked app or a fake
  download, that copies every saved password, browser cookie and crypto wallet from a
  machine in seconds and uploads it. The stolen bundles are called **stealer logs** and are
  sold by the million.

A stealer log is worse than an old breach: its passwords are current, and it often includes
**session cookies** that skip the login entirely.

## Why it is a rule

- **23andMe, October 2023.** Attackers used reused passwords to get into about 14,000
  accounts. A "DNA relatives" feature let each account see thousands of others, so the data
  of about **6.9 million people** leaked. The UK regulator later fined the company £2.31
  million, and the company went bankrupt in 2025.
- **Change Healthcare, February 2024.** A stolen password for a remote-access portal with no
  second factor. The attackers moved through the network for nine days, then deployed
  ransomware. It stopped a large share of US medical claims for weeks and affected about 190
  million people.
- **Snowflake customers, 2024.** Around 165 companies lost data, including Ticketmaster,
  AT&T and Santander. Google's investigators traced the logins to infostealer infections on
  contractors' and employees' machines, some **dating back to 2020**. The accounts had no
  second factor and the passwords had never been changed.
- **149 million logins in an open database, January 2026.** A researcher found an unprotected
  database of stealer logs covering Gmail, Facebook, Instagram, banking and government
  logins. The criminals had forgotten to lock their own loot.
- **Have I Been Pwned, June 2026.** A single batch of stealer logs added 56 million unique
  email addresses to the breach-checking service.

### Why it keeps working

- **Passwords are reused.** One leak unlocks many sites.
- **A password alone is enough** on too many accounts, especially old admin and vendor ones.
- **Stolen passwords do not expire.** Nobody knows theirs was taken until it is used.
- **Logins look normal.** A correct password from a home ISP looks like the real user.

## How to do it

### 1. A second factor on every account that matters

Staff, admin, cloud, database, domain registrar, email. Snowflake and Change Healthcare were
both one missing checkbox. Prefer **passkeys** or security keys, which the next lesson shows
cannot be phished. An authenticator app is still far better than nothing.

### 2. Refuse known-breached passwords

At sign-up and password change, check the password against a breached-password list. The
Pwned Passwords API does this without ever sending the password: you send the first five
characters of its SHA-1 hash and compare the results locally.

```js
const hash = crypto.createHash('sha1').update(password).digest('hex').toUpperCase()
const res = await fetch(`https://api.pwnedpasswords.com/range/${hash.slice(0, 5)}`)
const breached = (await res.text()).split('\n').some((l) => l.startsWith(hash.slice(5)))
```

### 3. Slow the bots down

Rate-limit login attempts per account and per IP, and add a delay after failures. Stuffing
works because trying is free.

### 4. Make stolen sessions short-lived

Sessions that expire, and that end on password change, limit what a stolen cookie is worth.

### 5. Retire old accounts

The logins in the Snowflake case were years old. Remove accounts for people and vendors who
have left, and expire passwords that have not been used.

## How we do it here

Passwords are stored only as slow, memory-hard hashes (scrypt), so a stolen table cannot be
guessed through at speed. Sign-in attempts are limited both per IP and per account, sessions
carry their own expiry, and access is checked on every request rather than trusted from the
moment of sign-in.

## Benefits

- A second factor alone would have stopped several of the largest breaches of the decade.
- Breached-password checks cost one HTTP request and block the most common passwords.
- Rate limits turn a million guesses into a few hundred.

## Disadvantages

- Second factors add friction, and some users will resist or lose them. Recovery has to be
  designed, or it becomes the new weak point.
- Text-message codes can be stolen through SIM swaps and are the weakest second factor.
- None of this helps if the malware steals a **live session cookie** after the user has
  already signed in. That is its own lesson.

## Checklist

- Every staff, admin and vendor account has a second factor.
- New passwords are checked against breach lists.
- Login attempts are rate-limited per account and per IP.
- Sessions expire and end on password change.
- Accounts for people who have left are removed.

## Sources

- [Google Cloud — UNC5537 targets Snowflake customer instances](https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion)
- [Have I Been Pwned — Pwned Passwords API](https://haveibeenpwned.com/API/v3#PwnedPasswords)
- [Have I Been Pwned — June 2026 Stealer Logs](https://haveibeenpwned.com/Breach/June2026StealerLogs)
- [Wired — 149 Million Usernames and Passwords Exposed](https://www.wired.com/story/149-million-stolen-usernames-passwords/)
- [OWASP — Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html)
- UK Information Commissioner's Office, penalty notice to 23andMe, June 2025.