Attackers are no longer fighting through hardened cloud perimeters—they’re quietly slipping in by stealing credentials. Using infostealer malware, cybercriminals infect developer or employee devices to harvest API keys, session tokens, and other secrets that organizations already trust. Once stolen, these credentials are resold or used to gain access to cloud consoles, code repositories, AI platforms, and production systems.
The initial infection vector might look familiar: phishing emails, deceptive file downloads, or malicious software dependencies. After infection, the malware scours browser data and developer secrets stored locally. Top culprits such as Lumma C2, RedLine, and Vidar were behind more than 85% of observed incidents. Secrets tied to AWS make up nearly half of compromised credentials, with Google Cloud trailing at around 13%.
Why Traditional Defenses Are Failing
Stealers can snatch session tokens or long-lived credentials—items like browser sessions or saved AWS access keys—and bypass multi-factor authentication altogether. Once such artifacts are lifted, they can be used from another device and still appear as legitimate user activity. Clicache directories, identity caches, service-account key paths, and configuration files across AWS, Azure, and Google Cloud environments offer rich pickings.
Victims are watching as source control systems become further vulnerability vectors. Repository tokens, SSH keys, and CI/CD credentials can all reveal private code, deployment settings, or sensitive variables. Surprisingly, AI platform credentials are creeping into the mix, too. Attackers are now using stolen keys not just to breach data, but to spin up or abuse AI services to rack up bills or steal internal conversations.
A Strategic Response: From Cleanup to Prevention
Organizations must treat a confirmed infostealer incident as an identity compromise—not just a malware infection. Standard response should include isolating compromised devices, revoking all active sessions, replacing API keys, SSH keys, tokens, and credentials—but only from clean machines. Detailed audits of cloud logs, identity systems, source-control platforms, and CI/CD pipelines are essential to spot odd sessions, unexpected repository changes, or excessive permissions.
On the preventative front, limiting credential lifetime and using workload identities rather than static long-lived keys significantly reduces exposure. Secrets ought to be stored in secure vaults or OS-managed keychains, while developer devices stay subject to strong device management policies. Dependency pinning and careful build-time reviews can curb risks introduced through supply chains, as demonstrated by recent incidents originating in vulnerable dependencies.
Continuous monitoring for risk signals—exposed credentials, unusual token use, session anomalies—must trigger immediate action. Protection of cloud environments depends as much on securing endpoints as on defending perimeters. Companies that neglect where access keys, tokens, and sessions live are letting the front door stay wide open.
What this reveals is a deeper shift in cloud security: the weakest link is no longer the cloud itself, but the devices and identities trusted to access it. With attackers targeting developer machines and identity artifacts, defense must move toward securing identities, minimizing credential lifetimes, and visibility across every token and session. Those who build cloud protections around these principles will be far better positioned to stay a step ahead.
