Skip to content

Lesson 7 of 15 · 4 min read

Infostealers and Session Theft

Free lessonReviewed By the AISecurityInterviews editorial team
Reading position
In this lesson

TL;DR: An infostealer runs once and copies everything useful from a machine: browser passwords and session cookies, autofill data, crypto wallets, VPN and chat configuration, and on developer laptops cloud CLI credentials, package-registry tokens and SSH keys. The bundle (a log) is sold, often searchable by the domains it unlocks. A session cookie represents a login that already passed MFA, so replaying it in another browser makes the attacker the user with no password and no second factor. Most infections come from cracked software, malicious ads and ClickFix lures that get the user to paste a command themselves, and often land on personal or contractor machines the company does not manage. Defences: make stolen secrets worthless (phishing-resistant MFA, short sessions, device-bound sessions such as Chrome's DBSC, no long-lived keys on laptops), keep work access on managed devices, harden endpoints, and watch stealer-log feeds so you revoke and rotate first.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

  1. 1Your company enforces MFA on single sign-on. A stealer log for sale contains an employee's SSO session cookie. Is the account at risk?

Why sessions are the prize

Authentication happens once; a session lasts hours, days or, for some apps, months. After a successful login the site sets a cookie (or issues a refresh token) that the browser presents with every request. Whoever holds it is treated as the user. Passwords plus MFA defend the login ceremony; they do nothing for a session that already exists.

FIG · WHAT A STOLEN SECRET IS WORTH
The same theft, before and after binding

Bearer session cookie

Stealer copies cookie

from the browser profile

Imported elsewhere

attacker's browser

No password, no MFA

Logged in as the user

until expiry or revocation

Outcome, unsafe: Account taken over

The cookie is the session.

Device-bound session

Stealer copies cookie

short-lived

Refresh needs proof

signature from TPM key

Key cannot leave the device

Cookie expires

minutes later

Outcome, safe: Theft has little value

The attacker cannot renew the session.

How infections happen

Infostealers are sold as subscriptions, so many unrelated crews spread the same families. Common lures:

  • Cracked software, game cheats and keygens, often promoted through videos and forums.
  • Malicious search ads impersonating popular downloads.
  • Fake updates on compromised websites.
  • ClickFix: a fake CAPTCHA or error tells the user to press a few keys and paste a command, so the user runs the payload and controls aimed at downloads and macros never trigger.

The infected machine is frequently a personal computer where an employee once signed in to work services, or a contractor's laptop. The company sees nothing until the credentials are used.

The market

Logs are uploaded to the operator's panel, then sold individually or in bulk, and buyers search by domain: "every log containing a login for this company's SSO". Initial access brokers turn working sessions into resold access. Law-enforcement actions disrupt the market (RedLine and META in October 2024; about 2,300 Lumma domains seized in May 2025, after Microsoft counted more than 394,000 infected Windows computers in two months), but other families keep operating. The 2024 Snowflake customer breaches showed the end result: credentials stolen by infostealers, sometimes years earlier, used against accounts with no MFA and no network restrictions.

Defences, in order of leverage

Make stolen secrets worthless.

  • Phishing-resistant MFA (passkeys, security keys) for every human login.
  • Short session lifetimes and re-authentication for sensitive actions.
  • Device Bound Session Credentials: the browser holds a private key in the TPM and the site issues short-lived cookies only after proof of possession. Chrome made it publicly available on Windows in April 2026; sites must implement it.
  • No long-lived cloud keys, registry tokens or SSH keys on laptops; issue short-lived credentials from single sign-on.
  • Network allow lists for data platforms, so a valid login from elsewhere fails.

Keep work on managed devices. Conditional access that requires an enrolled, compliant device stops personal laptops from holding work sessions at all.

Harden managed endpoints. Application control and script restrictions for standard users, EDR, no local admin rights, and browser policies that block password sync into personal profiles. Chrome's App-Bound Encryption made cookie theft harder for malware running as the user on Windows, but stealers adapted, so treat it as cost, not prevention.

Detect and respond. Watch for the same session used from two devices or networks, sign-ins from new devices immediately after a known infection, and your domains in stealer-log intelligence feeds.

Responding to a log

A small worked example of the order of operations:

log = [
    ("session_cookie", "sso.example.com"),
    ("password", "sso.example.com"),
    ("access_key", "cloud-cli"),
    ("password", "personal-email.example"),
]
bypasses_mfa = {"session_cookie", "access_key", "refresh_token"}
work = [item for item in log if not item[1].startswith("personal")]
first = [item for item in work if item[0] in bypasses_mfa]
then = [item for item in work if item[0] not in bypasses_mfa]
print(first)  # => [('session_cookie', 'sso.example.com'), ('access_key', 'cloud-cli')]
print(then)  # => [('password', 'sso.example.com')]

Revoke what bypasses MFA first (sessions, refresh tokens, keys), then reset passwords, then hunt in sign-in and cloud audit logs from the infection date, not the date the log was reported, and tell the user their personal accounts are exposed too.

Misconceptions interviewers listen for

"We have MFA, so stolen credentials do not matter." Stolen sessions and keys skip MFA entirely.

"Resetting the password ends the incident." Existing sessions and refresh tokens may stay valid until revoked.

"A takedown removed the threat." Takedowns raise costs temporarily; the market moves to other families.

"It was a personal laptop, so it is not our incident." If it held work sessions or keys, it is your credential exposure.

How this shows up in interviews

Expect "how do infostealers bypass MFA", "a stealer log contains our employee's session, what do you do", and "how would you reduce infostealer risk for 5,000 staff and contractors". Strong answers separate the login from the session, rank response actions by what is usable now, and spend most of the design on making secrets worthless rather than on cleaning infected machines.

Say it in 30 seconds: "Infostealers copy passwords, session cookies and keys and sell them as logs. A session cookie is a login that already passed MFA, so replaying it skips MFA. I make stolen secrets worthless with phishing-resistant MFA, short and device-bound sessions and no long-lived keys on laptops, require managed devices for work access, harden endpoints against lures like ClickFix, and monitor stealer-log feeds so we revoke sessions and rotate keys first, then hunt from the infection date."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

  1. 1Why does a stolen session cookie bypass MFA?

  2. 2What does Device Bound Session Credentials change?

  3. 3A stealer log contains a password, a session cookie and a cloud access key. Which do you act on first?

  4. 4Why is ClickFix effective against controls aimed at downloads and macros?

Practise it as an interviewer asks it

Course lessons that teach this

Related lessons