Multi-factor authentication is supposed to be the line that stops a stolen password from becoming a breach. Infostealer malware has found a way around that line entirely: instead of stealing a password, it steals the session that already passed the check.
What happened
When malware infects a device, it doesn't just grab saved passwords. It pulls browser cookies that represent an already-authenticated session, then hands that cookie to the attacker's own browser. To the cloud service on the other end, the request looks identical to the real user continuing their session — no login prompt, no MFA challenge, because none is required for a session that's already open.
The same malware families are also sweeping up long-lived credentials sitting in plain configuration files: AWS profiles and access keys, Azure CLI and identity caches, Google Cloud application-default credentials, GitHub and GitLab tokens, SSH keys, and increasingly API keys for AI platforms including OpenAI and Anthropic's Claude. Recent tracking puts GitHub tokens at roughly 10% of all secrets found in stolen credential logs, with AI-platform keys accounting for about 5% — a sign of how much of a developer's working life now lives in local config files rather than behind a login form.
Delivery keeps getting less conspicuous. Investigators have seen the theft chain ride on abused legitimate Windows binaries, trojanized gaming tools disguised as things like game cheats and skin changers, and infrastructure targeting developer machines directly — all without a single phishing email in the chain. Because these devices often carry privileged access to build pipelines and production projects but not the same monitoring as core corporate infrastructure, they've become a quiet, high-value target.
Why it matters
The business model behind this is assembly-line efficient: malware-as-a-service operators distribute the stealer, initial-access brokers sort and validate what comes back, and the most valuable accounts get resold to whoever wants in. That means a single infected laptop can escalate from a malware alert to a full cloud incident before a team even finishes the cleanup — a pattern recent developer-targeted campaigns and supply-chain exposures involving AI infrastructure tooling have both demonstrated.
The core lesson: strong MFA still matters, but it was never designed to stop an attacker who already holds a valid, active session. Once that session or those cached keys are in someone else's hands, the authentication step has already happened.
What to do
- Treat any confirmed infostealer infection as an identity incident, not just a malware cleanup. Isolate the device first.
- Investigate every account used on the infected device, then revoke active sessions and rotate passwords, API keys, SSH keys, cloud credentials, and repository tokens — all from a clean device.
- Audit cloud, identity, source-control, and CI/CD logs for unfamiliar sessions, new access keys, unusual token activity, role changes, and unexpected repositories.
- Rebuild from a clean image rather than trusting a malware removal tool to fully undo stolen access.
- Move to short-lived credentials and workload identity wherever the platform supports it, and keep long-lived secrets in an OS keychain or managed vault instead of a config file.
- Keep developer devices managed and tightly scoped, pin build dependencies, and review build-time behavior for anything unexpected.
- Add device-based access controls for sensitive services and monitor continuously for exposed credentials so a stolen session gets revoked in minutes, not weeks.
Protecting the cloud increasingly means protecting every endpoint that's allowed to hold its keys.