A password reset is the right first move after a suspicious login. It is not always the last move. Modern infostealer malware can collect more than saved passwords. It can steal browser cookies, session tokens, autofill data, crypto wallet files, cloud credentials, and account context from the device itself.
That changes the recovery plan. If an attacker has an active session cookie or OAuth token, they may be able to stay signed in even after you change the password. If the infected device is still compromised, the new password may be stolen as soon as you type it.
What an infostealer does
Infostealers are quiet malware built to extract useful account data fast. They do not need to encrypt your files or announce themselves. Their job is to package secrets and send them out before you know anything happened.
Common targets include:
- Saved browser passwords and autofill data.
- Session cookies that keep you logged in.
- OAuth access tokens and refresh tokens for connected apps.
- Authenticator exports, backup files, documents, screenshots, and notes.
- Crypto wallet files, cloud keys, developer tokens, and admin credentials.
Microsoft has reported infostealer campaigns targeting macOS users through fake software, malicious installers, copy-paste Terminal tricks, WhatsApp abuse, and fake PDF tools. The important lesson is not that one operating system is unsafe. It is that attackers follow trust and convenience.
Why session cookies matter
When you sign in to a site, the site often gives your browser a session cookie. That cookie is proof that you already authenticated. If malware steals it, an attacker may be able to load that session into another browser and appear already signed in.
This is why "but I have MFA" can be misleading. MFA protects the login step. A stolen session may skip the login step because the attacker is reusing proof that the login already happened. Recorded Future reported that hundreds of millions of malware-sourced credentials indexed in 2025 included active session cookies, making this a real account-takeover problem rather than a theoretical one.
The wrong recovery sequence
Many people respond to account compromise like this:
- Change the password on the same infected computer.
- Assume MFA means the account is safe.
- Leave all sessions active.
- Ignore connected apps and OAuth grants.
- Forget to clean the device before logging in again.
That sequence can leave the attacker with a working session, a refresh token, or a fresh copy of the new password. The safer recovery sequence starts with the device and the sessions, not just the password field.
A safer recovery checklist
If you suspect infostealer malware, use a clean device for account recovery. That can be a trusted phone, a different computer, or a freshly cleaned system. Then work through the accounts that control recovery for everything else.
- Isolate the suspected device. Stop using it for banking, email, password changes, cloud admin, and crypto until it is cleaned.
- Recover email first. Email usually controls password resets for other accounts.
- Change passwords from a clean device. Use unique random passwords, not small variations of old ones.
- Sign out of all sessions. Use the account security page to revoke browser sessions, trusted devices, and app sessions.
- Review connected apps. Remove unknown OAuth apps, browser extensions, integrations, and device-code authorizations.
- Regenerate backup codes. Old recovery codes may have been captured from screenshots, notes, or downloads.
- Upgrade MFA. Prefer passkeys or hardware security keys where supported, then authenticator codes, then SMS only as a temporary fallback.
- Document the incident. Store what changed, when it changed, and what still needs review.
Where password managers help
A password manager still matters, but the goal is broader than storing passwords. You need a private account record that includes the login URL, username, recovery email, MFA method, backup-code status, connected-app notes, and the date you last cleaned up access.
Krypt is a zero-knowledge password manager and secure vault, so your account recovery notes, passwords, 2FA backup codes, secure notes, and sensitive files can live together in encrypted local-first storage. That gives you a clean place to keep recovery context without scattering it across screenshots, browser notes, cloud documents, or chat apps.
What to watch after cleanup
Infostealer recovery is not finished the moment the password changes. Watch for signs that a token, session, or recovery path survived:
- New login alerts after all sessions were revoked.
- Recovery email or phone changes you did not make.
- Unknown devices reappearing on the account.
- New forwarding rules in email.
- Unexpected OAuth apps, app passwords, or API tokens.
- Account activity from old browsers after cleanup.
If the account controls money, identity, cloud storage, business operations, or developer infrastructure, treat any confirmed infostealer exposure as a device-level incident. Rotate the password, revoke sessions, review tokens, and clean the endpoint.
Technical references
For current threat context, read Microsoft's infostealer research, Recorded Future's identity threat report, and Google Cloud's M-Trends 2026 coverage of attackers harvesting OAuth tokens and session cookies.
Keep passwords, recovery codes, secure notes, and account cleanup details in one encrypted local-first vault.
