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: “
- https://www.secure.com/news/ai-coding-agent-breach-api-keys
- https://www.secure.com/news/fake-web3-accelerator-hijacks-ai-agents
- https://www.secure.com/news/grafana-tells-extortionists-to-get-lost-after-github-token-breach-exposes-codebase
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.
Lessons from the latest Anthropic security incident involving security researchers
Posted in Commentary with tags Anthropic on October 27, 2026 by itnerdThere are recent reports about security researchers using AI agents to access Anthropic’s internal systems. And they have sparked an important conversation about third-party software risk and the security gaps that can emerge even in sophisticated technology environments. Like this one: https://cybersecuritynews.com/anthropic-internal-system-breach/#google_vignette
Darin Fredde, Sr. Director of Technical Marketing Engineering, Ridge Security
“There’s a certain irony in building some of the most advanced AI systems in the world and having researchers find a way in through ordinary enterprise software. It’s a reminder that even the smartest technology is only as secure as the architecture surrounding it.
“What makes this research interesting isn’t simply the reported speed of the AI agents. It’s their ability to identify potential attack paths across the trust relationships that connect enterprise systems. A vulnerability by itself tells us very little about the actual business risk. The important question is what an attacker can reach, what they can access, and how far they can go.
“Anthropic deserves credit for reporting that its monitoring detected some of the activity and for taking containment measures. But the real measure of remediation is independent verification that those attack paths are closed.
“We need to stop confusing a successful patch with a verified security outcome. Otherwise, we’re just closing the front door and hoping nobody discovered the spare key.”
Jacob Krell, Sr. Dir: Secure AI Solutions & Cybersecurity, Suzu Labs
“Cathedral’s agents got into Anthropic the same way attackers get into everyone else, through the vendors. By Anthropic’s account, days of direct attacks on its own software failed. The breach came when the agents pivoted to the commercial software-as-a-service (SaaS) tools running Anthropic’s sales, human resources, and IT operations, and Cathedral says its agents found exploitable weaknesses there in under 12 hours.
“Anthropic is about as well-defended as a company gets, and its crown jewels never moved, no model weights, no source code, no customer conversations with Claude. What got hit was the layer it bought instead of built, third-party software that tracks customers and manages staff, the kind of layer wired together with integration permissions nobody re-reviews. Security maturity is capped by the weakest vendor you integrate with, and no amount of in-house engineering changes that.”
John Strand, Owner, Black Hills Information Security (www.blackhillsinfosec.com)
https://www.linkedin.com/in/john-strand-a1b4b62
“This is one of those stories that highlights the dark side of bug bounty programs. A well-executed bug bounty program can work incredibly well because it establishes clear rules of engagement, scope, expectations, and communication. This one sounds like an absolute disaster. Now we’re getting into a he-said, she-said argument over the severity of the vulnerabilities and how they were handled.
“What is particularly frustrating is seeing vulnerability research used as a marketing opportunity. When that happens, it starts to look less like the goal was finding vulnerabilities and getting them fixed, and more like the goal was being as sensational as possible in the claims being made against Anthropic.
“But I don’t want the controversy around Cathedral to distract from the vulnerabilities themselves, because there is a much bigger security lesson here. This shows the risk created by heavily interconnected software-as-a-service applications that are tied into multiple critical parts of an organization.
“That becomes exceedingly difficult for any CISO. At some point, you are outsourcing a portion of your security risk. You can get letters of attestation. You can review compliance reports. You can ask vendors about their security practices. But ultimately, you are trusting those vendors to properly secure infrastructure that may have significant access to your organization.
“It’s a very interesting story, and I’m disappointed in how some of this was released and communicated. But there are important lessons here. One is about what happens when bug bounty programs are poorly run or the relationship between researchers and vendors breaks down. The other is about the enormous amount of risk organizations inherit from SaaS applications and the vendors they trust with access to critical parts of their infrastructure.”
While it is nice to see companies like Anthropic get a taste of their own medicine, it shows what an arms race that AI has become. And I am afraid that this is an arms race that we’ll lose.
Leave a comment »