Updated May 2026, by the Ransomnews Research Team. This piece describes the structure of stealer logs at a defensive-analysis level. We do not link to log marketplaces and we do not include real captured credentials.
Most defenders only encounter infostealer logs through their second-order effects: a credential turning up in a breach feed, an account compromised, an MFA-bypass via session-cookie replay. The log itself stays abstract. That’s a problem for IR teams in 2026, because the structure of a stealer log determines how you scope an incident, what a single hit on your domain means depends entirely on what else is in the same archive.
This article walks through the typical structure of a 2026-era stealer log so analysts can read one when it lands on their desk. We don’t include sample credentials, sample cookies, or sample session tokens, the structural information is what matters for defenders, not the contents.
Where a log comes from
An infostealer is malware that runs on a victim machine for a single objective: harvest data, exfiltrate it, exit. Modern variants, Lumma, Vidar successors, Stealc, RisePro, the late-stage Redline forks, execute in seconds and leave minimal persistence. The output is one compressed archive, named after the stealer family and a machine UUID, dropped to attacker-controlled storage.
The archive then enters one of two pipelines. Free-tier logs end up on Telegram channels and forum giveaways within hours. Paid-tier logs are sold to initial access brokers who filter, enrich, and resell them at corporate-credential-grade pricing.
The standard archive layout
Different stealer families produce slightly different layouts, but the converged 2026 structure looks like this:
UUID-COUNTRY-DATE.zip
├── System.txt # device and OS fingerprint
├── Passwords.txt # decrypted browser-saved passwords
├── Cookies/ # browser cookies, per browser
│ ├── Chrome_Default.txt
│ ├── Edge_Default.txt
│ └── Firefox_Default.txt
├── Autofills/ # browser autofill data
├── CreditCards.txt # decrypted card data from browsers
├── Wallets/ # crypto-wallet directories
│ ├── Metamask/
│ ├── Phantom/
│ └── Exodus/
├── ScreenShot.jpg # full-screen capture at run time
├── DomainDetects.txt # quick-scan list of corporate-shaped logins
├── ImportantAutofills.txt # filtered "high-value" autofills
└── Telegram/ # session files for Telegram DesktopEach directory has a defensive interpretation:
System.txt, the fingerprint
The first file an analyst opens. It typically contains:
- Hostname and Windows username.
- OS version and build.
- Hardware fingerprint, CPU, RAM, GPU, MAC address.
- Public IP and approximate geolocation at run time.
- Installed antivirus and EDR products (the stealer enumerates them to inform operator targeting decisions).
- List of installed software and running processes at the moment of execution.
- Time zone, locale, keyboard layout, used by buyers to filter “logs from country X” listings.
For defenders this is gold. If the System.txt mentions your domain in the username, your MDM-enrollment user agent, or an EDR product you license, the log is from a corporate device and you have an inferred “device patient zero.” Triage from there.
Passwords.txt, the obvious bit
Decrypted browser-stored passwords, one record per line, formatted as URL | username | password. Modern stealers handle the Chromium DPAPI decryption on-host, so what arrives in the log is already cleartext.
Defender response: rotate every password matching your domain. Treat reuse as automatic, assume the user used the same password elsewhere. Move them to a password manager as the durable fix; the rotation is the immediate one.
Cookies/, the harder problem
Each browser’s cookie store, exported as a tab-separated file. This is the archive’s most operationally damaging component. Session cookies, particularly the SSO cookies for Microsoft 365, Okta, Google Workspace, GitHub, and AWS, let an attacker replay an authenticated session without going through MFA. The MFA was already proved when the cookie was issued.
Defender response if you find your domain in a cookies file:
- Force a global sign-out for the affected user across every IdP.
- Revoke all refresh tokens. In Entra ID, that’s
Revoke-AzureADUserAllRefreshToken; in Okta, the corresponding admin action. - Reset the user’s password and require a step-up re-auth on next sign-in.
- For administrative accounts, treat as a high-confidence compromise and follow the incident-response runbook.
Autofills and ImportantAutofills
Browser autofill data: addresses, phone numbers, names, sometimes credit-card hints. The “Important” file is the stealer’s pre-filtered version, keywords like passport, routing, SSN, 2fa, recovery, seed phrase. This is what the operator looks at first.
Defenders often miss this when scoping. A stealer log that doesn’t contain corporate credentials but does contain a user’s home address, phone number, and personal-tax-software autofill is still a problem, those data points feed downstream phishing and SIM-swap attacks against the same user.
Wallets/, the crypto angle
Browser-extension wallet directories copied verbatim. Metamask, Phantom, Brave, Exodus, Coinbase Wallet. Whether the attacker can drain the wallet depends on whether they captured the user’s wallet password too, Metamask’s local vault is encrypted, and the password is what they need.
Operationally relevant for corporate environments only if employees handle treasury or have signing authority on corporate wallets, but where that applies, the consequences are severe and immediate.
Telegram/, session theft
Telegram Desktop session files. With these the attacker can resume the user’s Telegram on their own machine without re-authentication. Less common in enterprise but extremely common in cybercrime-adjacent investigations and for users in jurisdictions where Telegram is the dominant messenger.
Parsing a log defensively
If your IR team encounters a log archive, typically through a third-party threat-intel feed, the standard parse is two scripts. First, find every line referencing your domain or any of your aliases:
# Quick triage, extract everything matching your owned domains
unzip -p suspect.zip Passwords.txt \
| grep -i -E '(acme-corp\.com|acme\.io|acme-internal)' \
| sort -u > passwords-our-domain.txt
# Cookies, same idea, but watch field separators (TSV)
unzip -p suspect.zip 'Cookies/*.txt' \
| awk -F'\t' '$1 ~ /acme-corp/' > cookies-our-domain.txtSecond, classify each hit by criticality. A user-tier credential to your customer-support portal is one severity; a Domain Admin’s stored password to the AD admin centre is another. Build a small lookup table of your sensitive domains, score each match.
For larger jobs, a Python script is appropriate:
import csv
import zipfile
from pathlib import Path
OWNED = {"acme-corp.com", "acme.io", "internal.acme"}
def scan(zip_path):
findings = []
with zipfile.ZipFile(zip_path) as zf:
for name in zf.namelist():
if "Passwords.txt" in name or "Autofill" in name:
with zf.open(name) as f:
for line in f.read().decode("utf-8", errors="ignore").splitlines():
if any(d in line.lower() for d in OWNED):
findings.append((name, line))
return findings
for log in Path("intel-feed").glob("*.zip"):
hits = scan(log)
if hits:
print(f"== {log.name} : {len(hits)} hit(s) ==")
for src, line in hits:
print(f" [{src}] {line[:200]}")For more thorough analysis use jq against any JSON-formatted variants and parse cookie files with a CSV reader respecting tab separators. Never run the unpacked log archive on a machine you care about, open it inside an isolated VM, ideally a dedicated analysis sandbox.
What the log structure tells you about scope
One pattern worth internalising: the System.txt + Cookies/ pair tells you whether the same machine that produced the log also has active sessions to your environment. If yes, the credential set in Passwords.txt is the least of your concerns, the cookies are a working session and the device is potentially still under attacker control.
Three scope tiers in 2026:
- Credential-only hit, domain matches in Passwords.txt, no cookies for our SSO. Rotate the password, monitor for replay.
- Cookie hit, active session token for our SSO. Revoke tokens, force re-auth, investigate the affected user’s downstream activity.
- Device-confirmed hit, System.txt matches a managed device by hostname, MAC, or hardware fingerprint. Treat as device compromise: isolate, image, reinstall, follow IR runbook. Assume persistence beyond what the log alone shows.
Defensive controls that matter
- Stop browsers from storing sensitive credentials. Group Policy:
Computer Config → Administrative Templates → Windows Components → Internet Explorer / Edge / Chrome → "Enable saving passwords" = Disabled. Force users into a real password manager. - Phishing-resistant MFA on every administrative account. Cookie theft is the 2026 MFA-bypass; passkeys and FIDO2 break that loop.
- Short SSO token lifetimes for privileged accounts. Stolen cookies have a half-life equal to your token lifetime.
- EDR with browser-credential-store telemetry. Modern EDR catches the distinctive process tree of browser-store enumeration. See our EDR and antivirus picks.
- Continuous stealer-log monitoring via Hudson Rock, IntelX, or our own Stealercheck.
Further reading
- Our infostealer family overview, the operators behind the logs.
- Our Telegram stealer-log economy piece, the distribution layer.
- Our stealer logs → ransomware piece, the downstream consequence.
- MITRE ATT&CK T1555, Credentials from Password Stores.
The log is a structured artifact, not a blob. Read it the way you’d read a forensic disk image, every directory means something specific, every filename predicts what’s inside. Once analysts can read one cleanly, scoping a stealer-log incident becomes a 30-minute exercise instead of a multi-day rabbit hole.