AppSec.Science

The Infostealer Era and Why Device Bound Sessions Change the Math

The most effective credential theft in 2026 does not break anything. No exploited CVE, no brute-forced password, no phishing page that fools your MFA prompt. An infostealer lands on an endpoint, reads the browser’s cookie store and token caches, and ships the loot to a marketplace. Hours later someone on the other side of the world resumes your authenticated session as if they were sitting at your desk.

This post looks at where infostealers are today, why session theft has quietly become the dominant account takeover vector, and how Device Bound Session Credentials (DBSC) finally changes the underlying math. It also covers what we are shipping to help services adopt that defense now, not in a few years.

The infostealer economy in 2026

Infostealers are no longer a niche. They are an industrialized supply chain.

  • It runs at commodity scale. Flare’s 2026 State of Enterprise Infostealer Exposure report analyzed 18.7 million infostealer logs. By their estimate the ecosystem now harvests over a million fresh logs per day, with automated sorting and near-instant monetization.
  • A handful of families dominate. LummaC2, StealC, Vidar, and ACRStealer drive most current infections. By one measure Lumma, StealC, and RedLine together accounted for over 75% of infections. They sell as Malware-as-a-Service subscriptions starting around $250 per month, which puts a capable credential harvester in the hands of anyone with a budget.
  • Takedowns slow it, they do not stop it. Lumma was disrupted by law enforcement in May 2025 and was back at scale within weeks. RedLine declined after Operation Magnus in late 2024, yet its logs keep circulating in underground markets and remain a live threat.
  • The enterprise blast radius is growing. The share of infections that expose enterprise SSO credentials rose from roughly 6% in early 2024 to 16% in 2026. Personal and BYOD machines, which sit outside most corporate controls, make up a large fraction of infected devices used for work.

The part that should worry every defender: the most valuable thing these tools steal is not your password. It is your session.

Why session theft beats your MFA

Multi-factor authentication protects the act of logging in. It does nothing for a session that is already authenticated.

When an infostealer lifts a valid session cookie or bearer token, the attacker does not need your password, and they do not need to satisfy an MFA challenge. They replay the cookie and the application treats them as the already-verified you. This “pass the cookie” technique sidesteps MFA entirely rather than defeating it. Modern stealers have gotten good at the extraction step too: Vidar 2.0, for example, launches the browser in debug mode and pulls decryption keys straight from memory to crack encrypted cookie stores.

The downstream damage is not theoretical:

  • The 2024 Snowflake campaign is the canonical example. The group tracked as UNC5537 used credentials harvested by infostealers (some from infections dating back years) to take over roughly 165 customer environments, including AT&T, Ticketmaster, and Santander. The common thread was authentication that came down to a still-valid credential with no device binding behind it.
  • Stealers are the on-ramp to ransomware. Reporting has tied a majority of ransomware victims to domains that previously appeared in infostealer credential dumps. The stealer log is increasingly the first step of the breach, not a footnote to it.

Rotating passwords does not help when the stolen artifact is a live session. The real fix has to make the stolen cookie itself worthless off the device it came from. That is exactly what DBSC does.

How DBSC changes the math

Device Bound Session Credentials is a W3C standard that cryptographically binds a session to a private key that never leaves the originating device. Chrome has now rolled it out to general availability on Windows (Chrome 146), with macOS following, and Google reports a significant reduction in session theft for protected sessions.

The mechanism is elegant:

  1. At login the browser generates a public/private key pair and stores the private key in secure hardware: a TPM on Windows, the Secure Enclave on macOS. The private key is non-exportable, so malware on the host cannot read it.
  2. The server issues a short-lived cookie, typically valid for around ten minutes, instead of a long-lived one.
  3. When that cookie expires, the browser hits a refresh endpoint, receives a challenge, and signs it with the device-bound private key. The server validates the signature and issues a fresh short-lived cookie.

Now picture the infostealer. It can still exfiltrate the cookie, but the cookie expires in minutes, and refreshing it requires a signature from a key the malware cannot extract. The stolen artifact ages out into worthlessness almost immediately, and replay from an attacker’s machine fails the binding check. The entire economy described above, lift a cookie and replay it from anywhere, stops paying off.

Our contribution: DBSC you can adopt today

A browser standard only matters if servers actually implement it, and the server side of DBSC (registration, challenge issuance, signature verification, cluster-safe session state) is precisely where adoption stalls. So we built it.

DBSC - Device Bound Session Credentials is our framework-agnostic TypeScript implementation of the standard: the protocol logic, pluggable storage, and web-framework glue needed to put DBSC into real services. It ships as a pnpm monorepo of focused packages:

  • Core protocol with the challenge and binding logic, plus an in-memory store for getting started and for tests.
  • A Hono adapter, drop-in middleware for the Hono web framework.
  • Redis-backed storage that is cluster-safe via a Lua compare-and-set, for multi-instance deployments.
  • ESLint rules that pin JWT algorithms and head off the classic alg confusion and downgrade mistakes.

Because this is security infrastructure, the repo ships its assurance alongside the code: a threat model that states plainly what DBSC does and does not defend against, an assurance case mapping each security claim to the source and tests that back it, and a documented vulnerability-reporting path.

Staying ahead of the curve

The pattern we keep seeing is that attackers move to the easiest unguarded layer. As MFA closed the password door, infostealers walked through the session window. DBSC closes that window, and the work now is making the defense practical for everyone, not just the handful of platforms with the engineering depth to build it from the spec.

That is the kind of hard problem worth taking on: get ahead of the threat, turn an emerging standard into something a team can drop into production, and ship it with the assurance to prove it holds. The stolen cookie is on its way to becoming a worthless artifact. We are building the tooling to get there faster.

Sources