Company Logins in Stealer Logs: Why a Password Reset Is Only the First Step

How stealer logs feed real attacks

Infostealers are cheap malware sold as a service. They spread through cracked software, fake browser updates and pages that talk the victim into pasting a command into a terminal. Within seconds they collect what the browser and other applications hold, pack it into a log and upload it. Logs are sold in bulk, and brokers sort them for corporate access they can resell to ransomware groups.

The link to ransomware is measurable. Verizon's 2026 Data Breach Investigations Report found that 73% of ransomware victims had an infostealer infection or a leaked credential in the year before the attack.

In May 2025 Microsoft, the US Department of Justice, Europol and Japan's JC3 disrupted Lumma, one of the most widespread stealers; Microsoft had counted more than 394,000 infected Windows computers in the two months before.

What a log contains

• Saved logins and passwords from every browser profile, including corporate single sign-on, VPN portals, cloud consoles and admin panels.
• Session cookies and tokens. A valid session cookie lets an attacker open the account directly, usually skipping both the password and the second factor.
• Autofill data: names, addresses, phone numbers, sometimes payment cards.
• Files and settings from other applications: VPN profiles, messenger sessions, SSH keys, cloud command-line credentials and crypto wallets.
• Details about the device: IP address, location, installed software and a screenshot taken at the moment of infection.

Why a password reset leaves gaps

Sessions outlive the password

Many applications keep existing sessions alive after a password change. An attacker holding the cookie stays logged in, and multi-factor authentication only asks again at the next full login. Revoke sessions in each application explicitly, including the long-lived refresh tokens that mobile and API clients use.

The attacker may already have a foothold

If the stolen login was used before you noticed, the attacker may have created accounts, granted access to an OAuth application, added a mailbox forwarding rule, registered their own MFA device or planted a web shell. Each of these survives a password reset and has to be found and removed.

One log opens more than one system

Browsers store logins for internal tools, partner portals and personal accounts side by side, and people reuse passwords. A single infected laptop can give access to several organizations at once. Google's threat intelligence team traced the 2024 campaign against Snowflake customer accounts to exactly this. Most of the credentials came from earlier infostealer infections, some dating back to 2020, and the affected accounts had no multi-factor authentication. About 165 organizations were notified as potentially exposed.

Old leaks stay usable

23andMe shows the same effect with passwords reused from earlier leaks. By the company's own count, attackers logged into about 14,000 accounts with credentials leaked from other services, then used a relatives feature to reach data on roughly 6.9 million people. The UK Information Commissioner's Office fined the company £2.31 million in June 2025.

What a penetration test answers after a leak

The goal is to measure the exposure with the attacker's own material and close every path the test finds. A grey box or assumed-breach test fits best: testers start with the leaked credentials, the cookies and the user's role, exactly as a buyer of the log would.

1. Where the credentials still work. Testers try each leaked login against single sign-on, VPN, email, cloud consoles and every internal application named in the log, including old and forgotten ones.
2. Whether stolen sessions are still valid. Testers replay the cookies and tokens to see which applications still accept them after the reset and whether any of them skip MFA.
3. How far the account reaches. From the compromised account, testers look for privilege escalation, movement to other systems and access to sensitive data.
4. Whether anything was left behind. Together with your administrators, testers check for new accounts, OAuth grants, mailbox rules, extra MFA devices, scheduled tasks and web shells.
5. Whether you would have noticed. Testers record which actions raised alerts and which passed unseen, so detection improves along with access control.

If the test turns up signs of earlier access, the work becomes an incident investigation: establishing what the attacker did, containing it and documenting it for regulators and insurers.

A response checklist

• Revoke all sessions and tokens for the affected users in every application, then reset their passwords.
• Reinstall the infected device from a clean image.
• Rotate every secret the device held: API keys, SSH keys, cloud credentials and VPN profiles.
• Move administrators, finance staff and remote access to phishing-resistant MFA such as passkeys or hardware keys.
• Phishing-resistant MFA does not stop a stolen session by itself, so bind sessions to the device where your identity provider supports it, and shorten session lifetime for sensitive applications.
• Keep personal browser profiles and personal software off corporate devices, since many infections start there.
• Watch new stealer logs and leak dumps for your domains, so the next exposure is found sooner.

When your logins appear in stealer logs or leak dumps, Jetlink can run the assumed-breach test described above, and move to incident response if the test finds traces of earlier access. Our penetration testing guide covers how the other test types work.