Stealer logs are traded as archives, and the format varies by family. Underneath the differences they carry broadly the same material. Knowing what is in one changes how you respond to it.
The anatomy of a log
- System information. Hostname, username, OS build, locale, hardware identifiers, installed software, sometimes a screenshot.
- Credentials. Saved logins from every browser profile on the machine, as URL, username, password triples.
- Cookies. Full cookie jars per browser, including live session tokens.
- Autofill data. Addresses, phone numbers, occasionally payment details.
- Wallets and application tokens. Cryptocurrency wallets, messaging app sessions, VPN configurations.
Why the system information matters
Most tooling treats a stealer log as a bag of credentials and discards the rest. That is a mistake, because the system block is what makes the credentials correlatable.
If four hundred credentials share a hostname and a hardware identifier, you are not looking at four hundred incidents. You are looking at one infected machine — and the response is different. One machine means one reimage, one user conversation, and one scoped revocation sweep. Four hundred unlinked findings means four hundred tickets and a team that stops trusting the queue.
Reading severity off the URL
The URL field carries most of the signal. A credential for a consumer streaming service and a credential for an internal SSO endpoint appear identical in structure and differ enormously in consequence. Resolving the host against a known asset inventory — including subdomains and applications that are not on the main domain — is what turns the raw triple into a prioritized finding.
Dates, and why they are unreliable
Logs carry timestamps, and those timestamps are frequently wrong — set by the attacker’s tooling, by the repacker, or by the machine’s own clock. Treat the first date you observed the record as the reliable one, and the embedded date as a hint. Building a response SLA on an attacker-supplied field is not a foundation.
Handling it safely
Everything described here is someone’s personal data, and much of it is still live. Any process that touches it should mask by default, restrict and log access, minimize what is retained, and never require an analyst to read a working secret in order to act on it. The point of the analysis is the decision, not the plaintext.