Aokigahara InfoStealer Targets AI Developer Tools & Keys

Over the weekend, Check Point researchers published Infostealer riding the AI Train, an analysis of Aokigahara, a newly identified infostealer, and its connection to the evolving AI-driven threat landscape. It explores how cybercriminals are adapting malware operations, including targeting AI coding assistants and developer tools.

Waseem Ahmed, Head of Engineering at Secure.com

“Infostealers follow whatever credentials pay: browser passwords, session cookies, crypto wallets, cloud keys. Check Point’s analysis of Aokigahara shows AI tools joining that list as a category of their own.

“The stealer has a dedicated handler for AI sessions that goes after the credential and config files of Claude Code, Codex, ChatGPT Desktop, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Amazon Q, Kiro and others, right alongside the AWS, Azure, Google Cloud, Git and SSH credentials it also takes.  That pairing is the point. On a developer’s machine, the AI assistant is now wired into the same code, cloud, and secrets as everything else. To be clear, this is theft from a machine that is already infected, not a flaw in any of those tools.

“Check Point names three routes that a successful attacker could take using stolen AI creds or session tokens. These are: using paid AI services on someone else’s account, reselling the accounts, and extortion too if the tokens open up conversation history or uploaded files. It is careful to say it has not confirmed how this group actually makes money, and I would not overstate the market yet.

“”But we already know what AI abuse on a victim’s bill looks like. Last week Wiz documented attackers who hijacked cloud billing accounts and ran up tens to hundreds of thousands of dollars in AI usage within 24 to 48 hours.

The bigger risk is access. A coding assistant session can hold conversation history, uploaded files, and pasted code, and the stealer also takes the .env files that sit next to some of these tools, which often carry keys for other services.

“”Threat actors target AI coding assistants because developers are where the keys live. A developer workstation holds source code, cloud credentials, Git tokens, and now an AI assistant with access to all of it so it can do useful work.

Many of these tools store their tokens in files in the user’s home folder, and this stealer also reads the Windows credential store, so it can collect both in one pass. Unlike a password, a stolen session token usually bypasses multi-factor authentication entirely.

“Companies are more exposed to this kind of scenario than most realize, because AI tools spread faster than inventories. Developers install assistants and command-line tools themselves, often using personal accounts, and security teams often don’t know which ones are on which machines. The biggest blind spot is incident response.

“Most compromised-workstation playbooks reset the password, revoke browser sessions, and rotate cloud keys. Few include signing out of every AI tool, revoking AI provider API keys, or checking AI usage and billing for activity that didn’t come from the developer. The second blind spot is monitoring. Organizations rarely monitor spend and usage on AI provider accounts with the same care as cloud spend.

“Security teams must add AI tools to the containment checklist. First, list every AI assistant, coding tool, and command-line client on that machine, because each one is a separate session to kill. Sign out of all of them and revoke their tokens at the provider, not just on the device. Second, rotate every AI provider API key the developer could access, including keys in .env files and in any tool configuration the assistant uses. Third, check the provider’s usage logs and billing for activity from unfamiliar locations or sudden spikes. Fourth, review the conversation history and uploaded files, because that data may now be exposed.

“Then they have to do everything they’d normally do: reimage the machine, rotate cloud, Git, and SSH credentials, and treat anything those credentials could reach as at risk.”

Note: “

Denis Calderone, CTO, Suzu Labs

Stolen AI credentials can be used to be harvested for the compute behind someone else’s paid subscription, or resold as infra on-demand, kind of like a subscription service. The even scarier scenario is that the stolen accounts will come with private chat logs that could then be used to extort the rightful owner, or provide actionable intelligence about other assets leading to further attacks.

“A developer’s AI assistant is a keyring and that makes it a particularly attractive target. The same malware that lifts the Cursor or Copilot session is also grabbing Git credentials, SSH private keys, and AWS config files off that workstation, so one infected machine can expose the codebase, the repos, and the cloud in a single run.

“”Too many organizations are susceptible to this kind of attack. As a penetration tester, the developer workstation has always been my favorite target. Developers typically run with local admin, and the test infrastructure they stand up is usually the least secured real estate in the entire environment.

If an organization suspects an infostealer has compromised a developer’s workstation, they should treat it like any infostealer compromise. That means they isolate and rebuild the workstation, but expand the rotation list: SSH keys, Git credentials, cloud credentials, and Windows Credential Manager entries, not just the AI tokens. And then they also have to audit what was actually discussed with the AI tools, because those conversation histories are now part of their exposed data. The AI assistant transaction logs just became very important evidence when a break occurs.”

This is yet another info stealer to be aware of. And seeing that AI is the new hotness, this should be the top of everyone’s list to protect themselves against. Until the next one shows up.

Leave a Reply