How it works
The code enumerates browser profiles, credential stores, token caches and configuration files, or hooks input and screen capture, then transfers what it collects to operator infrastructure. Nothing is encrypted and nothing breaks, which is why infection often goes unnoticed.
Stealing the session, not the password
The important shift in this category is that modern stealers prioritise session tokens over passwords. A password can be changed and is often protected by a second factor; a stolen session cookie is a completed authentication that carries no memory of how it was obtained.
That is why an infection frequently produces account access with no login event, no MFA prompt and no failed attempts. From the application's perspective the user simply continued browsing — from a different machine.
It also explains why password resets are an insufficient response. If the stolen session remains valid, the attacker retains access through a credential the user cannot change. Revoking sessions is the step that ends it, and it is the step most often skipped.
What gets taken, and from where
Stealers are thorough and fast, typically finishing in seconds. The common targets are predictable because they are where credentials actually live.
- Browser profiles — saved passwords, cookies, autofill data and history across every installed browser.
- Token caches belonging to cloud CLIs, developer tools and messaging clients, which frequently hold long-lived refresh tokens.
- Configuration files containing connection strings, API keys and SSH private keys.
- Cryptocurrency wallet files and browser wallet extensions.
- Screenshots and clipboard contents, which catch anything typed or copied around the time of infection.
Why infection means credential compromise
The single most consequential mistake in responding to a stealer is treating it as an endpoint problem. Removing the malware or reimaging the machine addresses the host and leaves the actual damage untouched: the credentials left the building.
Anything that machine was signed into should be considered compromised. That includes services the user forgot about, personal accounts sharing a password with corporate ones, and any system whose session was open at the time.
The correct sequence is revoke sessions, rotate credentials, then reimage — in that order, because reimaging first removes the evidence needed to determine what was accessible.
Reducing the blast radius
Because prevention is imperfect, the useful question is how much a single infected machine can be worth.
Phishing-resistant, device-bound authentication is the strongest answer: a stolen cookie from an unbound session is usable anywhere, whereas credentials tied to hardware are not portable. Shorter session lifetimes on sensitive systems reduce the window during which stolen tokens remain valid.
Keeping privileged credentials out of browser password stores removes the richest single target, and restricting which processes may request input monitoring or screen capture closes the collection path used by the surveillance variants.
Also known as
What defenders may observe
- Unusual processes reading browser or credential stores
- Archive creation followed shortly by outbound transfer
- Account access from a new device with no password prompt
- Regular low-volume exfiltration on a schedule
- Accessibility or input-monitoring permissions granted unexpectedly
Prevention and mitigation
- Deploy EDR with behavioural detection and application allow-listing
- Use phishing-resistant MFA and bind sessions to devices where possible
- Treat any infection as credential compromise: revoke sessions and rotate secrets
- Keep secrets out of browser password stores for privileged accounts
- Restrict which processes may request input monitoring or screen capture
- Shorten session lifetimes on high-value systems
Initial response priorities
- Isolate affected systems without destroying volatile evidence.
- Activate the incident-response and continuity plans.
- Scope initial access, persistence, lateral movement and affected identities before recovery.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.