The short answer

For staff logins: reset the affected passwords, revoke all sessions and tokens, and clean or rebuild the infected computer. Then require phishing-resistant MFA and managed devices for company systems, and stop staff saving work passwords in personal browsers.

How an infostealer turns one infection into a breach

How infostealer malware steals logins and session cookies, and which defences stop the stolen data being used Top, unprotected: an employee runs a fake software download, the infostealer copies saved passwords and session cookies, the log is sold, and an attacker replays the session cookie to sign in to company systems without needing the password or MFA. Bottom, protected: sessions are revoked, the device is rebuilt, and sign-ins require a phishing-resistant method on a managed device, so the stolen data no longer works. Stolen data still works Fake download Cracked app, fake update Browser emptied Passwords, cookies Log sold On criminal markets Session replayed Skips password and MFA Attacker signs in as staff Often the start of ransomware Stolen data made useless Sessions revoked Cookies stop working Passwords reset Device rebuilt Strong sign-in Passkey, managed device Replay fails Nothing usable left Old logins and tokens dead New theft is harder to use How infostealer malware steals logins and session cookies, and which defences stop the stolen data being used Top, unprotected: an employee runs a fake software download, the infostealer copies saved passwords and session cookies, the log is sold, and an attacker replays the session cookie to sign in to company systems without needing the password or MFA. Bottom, protected: sessions are revoked, the device is rebuilt, and sign-ins require a phishing-resistant method on a managed device, so the stolen data no longer works. Stolen data still works Fake download Cracked app, fake update Browser emptied Passwords, cookies Log sold On criminal markets Session replayed Skips password and MFA Attacker signs in as staff Often the start of ransomware Stolen data made useless Sessions revoked Cookies stop working Passwords reset Device rebuilt Strong sign-in Passkey, managed device Replay fails Nothing usable left Old logins and tokens dead New theft is harder to use
Infostealer logs are a common first step in breaches and ransomware, because they hand attackers working sessions rather than guesses.

How DNS Panopticon detects it

Security Posture asks Hudson Rock’s free lookup how many infected computers held logins for the scanned domain. Only counts are kept: no addresses, usernames, passwords or URLs are stored or shown. The lookup can be switched off by the site operator. The result appears on the Credential Exposure card.

FindingSeverityWhen it appears
Staff logins stolen by infostealer malwareHighComputers of people who sign in to the domain’s own services (employees) were infected. Ten or more costs the most.
Supplier logins to the domain’s services stolenMediumComputers at suppliers or partners with logins for the domain were infected.
User logins stolen from infected computersLowCustomers’ or members’ own computers were infected. The infections are outside your control, but the logins are for your service.
No infostealer infections linked to the domainPassHudson Rock has no infected computers with logins for the domain.
Infostealer data could not be checkedNot gradedThe lookup had no answer.

How to check it yourself

Page or toolWhat it tells you
https://www.hudsonrock.com/free-toolsCounts of infected employees and users for a domain, and the most recent infection dates.
Microsoft Entra ID: Users → Sign-in logsSign-ins from unusual locations or devices, and sessions reused from new addresses.
Google Workspace: Reporting → Audit and investigation → User log eventsThe same for Google accounts.

Your endpoint protection tool may also have flagged the infection on the device. Infostealer families include RedLine, Lumma, Raccoon and Vidar.

Why it matters

  • Session cookies bypass MFA. A stolen cookie for a signed-in session lets an attacker continue that session from their own machine, without the password or the second factor.
  • It is fast and cheap. Logs from millions of computers are sold for a few dollars each and searched by domain, so a company login is easy to find.
  • Personal devices count. Many infections are on home computers that staff also use for work, outside company security tools.
  • Suppliers are a way in. A partner’s infected laptop with access to your systems is as useful to an attacker as your own.

How to respond and reduce the risk

  1. Revoke sessions first, then reset passwords, for every account the infected computers could reach: identity provider, email, VPN, admin panels, SaaS tools. In Microsoft Entra ID, revoke the user’s sessions; in Google Workspace, sign the user out of all sessions.
  2. Clean or rebuild the computer. Infostealers often bring other malware. Reinstalling is safer than scanning.
  3. Rotate secrets stored on the machine: API keys, SSH keys, cloud credentials and password manager vault passwords.
  4. Use phishing-resistant MFA, such as passkeys or security keys, and require compliant, managed devices for company systems (see Device Enrollment Records for Intune and Entra ID).
  5. Shorten and bind sessions where your platform supports it, for example Microsoft Entra token protection, so a copied cookie fails on another device.
  6. Stop saving work passwords in browsers; use a company password manager instead, and block unapproved software downloads.
  7. For suppliers and users, review what outside accounts can access, require MFA for them, and watch for unusual sign-ins.

FAQ

The infection was on an employee’s home computer. Is it still our problem?

Yes, if that computer held logins for your systems. The stolen data is just as usable. Reset and revoke as above, and help the employee clean the device.

We use MFA. Are we safe?

Not fully. MFA stops a stolen password on its own, but not a stolen session cookie from a signed-in browser. Revoking sessions, short session lifetimes, device-bound tokens and managed-device requirements close that gap.

Why only counts? Can we see which accounts were affected?

DNS Panopticon deliberately keeps no personal data. Hudson Rock and other threat intelligence providers offer detailed reports to verified domain owners.

Sources and further reading