We spend most of our time on the outside of an infostealer campaign: the delivery pages, the C2 infrastructure, the loader that stages the payload. This post looks at the inside instead. Once a stealer is running on a host, it has to do a small number of things that it cannot avoid doing, because those actions are the whole point of the malware. That makes them the most durable detection surface we have. The panel names change every quarter. The behaviour on the endpoint barely moves.
The things every infostealer has to do
Strip away the branding and the invariants are the same across StealC, Lumma, Vidar, and the rest of the current field. A stealer has to locate credential stores, decrypt them, collect a few other high-value files, bundle the result, and send it out. Each of those steps leaves a signal that is hard to hide precisely because it is load-bearing.
Signal 1: a non-browser process reading the browser’s credential files
Browsers keep saved passwords, cookies, and autofill in known SQLite files: Login Data, Cookies, Web Data. A stealer opens them directly. The tell is not that the files are read, the browser reads them constantly. The tell is who reads them. When a process that is not the browser opens Login Data under a Chrome or Edge profile directory, that is close to a definition of the attack. MITRE catalogs this as Credentials from Web Browsers (T1555.003) and the cookie theft that rides along with it as Steal Web Session Cookie (T1539).
Signal 2: decryption, and the response to app-bound encryption
The saved secrets are encrypted. Historically a stealer just called DPAPI to unprotect them, which meant touching the user’s master key. Since Chrome added app-bound encryption in 2024, the loot can no longer be decrypted by any process running as the user; it has to be decrypted by the browser itself. The stealers adapted by getting their code to run inside or on behalf of the browser process, through injection or COM abuse. That adaptation is itself a signal: an unexpected module loaded into the browser, or a short-lived child of it doing credential work, is now part of the pattern rather than an anomaly to explain away.
Signal 3: the walk through the rest of the credential landscape
After the browser, a stealer sweeps a predictable list: cryptocurrency wallet directories, FTP and SSH client configs, email client stores, and the local databases of password managers. To an endpoint sensor this looks like one process opening a scattered set of sensitive files across unrelated applications in a short window, which is Unsecured Credentials: Credentials In Files (T1552.001). Normal software does not read your wallet, your SSH key, and your Thunderbird profile in the same two seconds.
Signal 4: staging and archiving
The collected material gets written to a working directory, usually under the user’s temp or app-data path, and compressed into a single archive for transport. That is Local Data Staging (T1074.001) followed by Archive Collected Data (T1560). A burst of reads across sensitive locations, immediately followed by an archive appearing in temp, is a tight, high-confidence sequence.
Signal 5: the exfiltration burst
Finally the archive leaves, in one short outbound transfer to a first-seen domain or a messaging API. It is Exfiltration Over C2 (T1041) or, increasingly, over a legitimate web service. Taken alone the network event is easy to miss inside TLS. Taken as the last link of the chain above, it is the confirmation.
Where this visibility has to live
The problem with every signal here is that it is on the endpoint, not the wire. The credential reads, the injection, the staging, the archive, none of it is legible from network logs, and the exfil is a single burst against normal-looking TLS. Catching it means process, file, and registry telemetry from the host, correlated in near real time, with someone actually reading the correlations at the hour the infection happens rather than the following Monday. That last requirement is where most organisations come up short, because a 24-hour endpoint watch is a staffing problem before it is a tooling problem. It is why teams that cannot run that watch in-house route these detections to a managed detection and response provider that already runs the endpoint side around the clock. The IOCs we publish through ThreatFox and the family notes on Malpedia feed the infrastructure side of the same detection; the behaviours above feed the host side.
Closing
We will keep tracking the infrastructure, because it is where attribution and early warning live. But if you are defending endpoints, build your detections on the invariants rather than the indicators. The domain in this week’s campaign will be dead by next week. A non-browser process reading Login Data, decrypting it, archiving the result, and shipping it out will still be an infostealer next year.