Infostealers now collect AI coding assistant credentials: what to change

Two reports published in the past week show that AI coding assistant credentials have joined passwords, cookies and crypto wallets on the standard infostealer shopping list. On 15 October 2026 Symantec's Threat Hunter Team described new versions of the Aoki infostealer that collect credential and session files for Claude, Codex, Cursor, Gemini and others. Three days earlier, Elastic Security Labs documented a campaign whose Windows stealer takes Claude, Cursor and Windsurf files, and whose fake coding agent routed model traffic through the attackers' own server. If your developers use AI coding tools, the files those tools keep on disk are now worth stealing.

What Aoki takes

Symantec describes Aoki (also called Aokigahara) as a relatively new, little-documented stealer first seen earlier in 2026. Older samples did not look for AI-related files, so the capability is recent. The newest sample the team analysed targeted:

• .claude.json, Claude desktop cookies and ChatGPT cookies;
• the Codex config.toml and .env files;
• tokens for GitHub Copilot, Cursor, Google Gemini, JetBrains AI Assistant and Kiro;
• Amazon Web Services credentials.

It also collects the usual infostealer targets: dozens of browsers, wallet extensions, password managers, messaging and gaming clients, and VPN and FTP clients. It has no backdoor command list; it gathers what it finds and sends it to its command-and-control server.

Two details matter for engineering teams. First, Symantec says the malware took credential, token and session files rather than source code, with one exception: the local state database Cursor uses, which "can cache chat context and code snippets". Second, Symantec's explanation of why attackers want these files: API keys and OAuth or session tokens let someone act "under a legitimate developer's identity and API quota", and can expose the repositories, cloud services and CI/CD pipelines linked to the account.

What the Apex Accelerator campaign adds

Elastic's report (tracked as REF8801) is about a different operation: a fake Web3 accelerator that offered founders free Claude and Gemini credits, coding tools and security audits. Its npm package @apexacc/cli repackaged Oh My Pi, a legitimate open-source coding agent. Elastic compared the files and found 1,351 of 1,363 identical to the original, so the genuine code helped hide the additions.

The additions did three things:

• Rerouted model traffic. The bootstrap overwrote the OpenRouter key and base URL in the running process, so requests still labelled OpenRouter went to an attacker endpoint. Elastic showed a test prompt and the content of a file the agent read reaching that server; the changes expose prompts, conversation history and tool output generally. It did not observe the server substituting malicious responses, but notes that the captured source defaulted tool approvals to "yolo".
• Registered an attacker MCP server. An entry in ~/.apex/agent/mcp.json pointed the agent at an MCP server run by the operation, which could add instructions and tool definitions to the agent's prompt. The entry persisted across restarts.
• Fetched and ran commands. Both packages asked a "verification" endpoint for a command and ran it, leading on Windows to a native stealer and on macOS to a known backdoor family.

The Windows stealer's collection list includes %APPDATA%\Claude\config.json, Cursor's storage.json and settings.json, and Windsurf's .env and auth.json, filed in its archive under a folder named Network Protocol Clients/MCP. That folder name suggests the authors are after MCP configuration as much as sign-ins.

What is new, and what isn't

Infostealers taking developer secrets is not new. Cloud keys, SSH keys and browser sessions have been targets for years. What changed is that AI coding tools added another set of long-lived credentials to every developer machine, often in files under the home directory, and that criminals noticed. Symantec compares a stolen AI key to card data: it can be "cashed in directly, either through resale or by running up usage on the victim's account", a practice sometimes called LLMjacking.

The Apex case also shows a second risk that a credential inventory alone won't catch: a coding agent you didn't vet can send everything it sees to someone else's model endpoint while appearing to work normally. A tool that only reads files is still a data path if its model traffic goes to the wrong place.

Where the reports differ is scope. Symantec documents a broad stealer whose AI targeting is one feature among many and doesn't name a delivery route. Elastic documents a targeted social-engineering operation aimed at crypto founders. Neither gives victim counts, so treat this as a shift in what malware looks for, not as evidence of a large campaign against any one tool.

Where the tools keep credentials

It helps to know where the files are. The Claude Code documentation says that on macOS credentials go in the encrypted Keychain, falling back to ~/.claude/.credentials.json (file mode 0600) when the Keychain rejects the write; on Linux they are in that file; on Windows in %USERPROFILE%\.claude\.credentials.json, protected by the user profile's access controls.

The Codex documentation says Codex caches login details "in a plaintext file at ~/.codex/auth.json or in your OS-specific credential store", controlled by cli_auth_credentials_store (file, keyring, auto or ephemeral). Admins can enforce that setting through local requirements, and users can't override it. The docs add: "treat ~/.codex/auth.json like a password".

An operating system credential store raises the bar, but it is not a wall. Malware running as the user can sometimes reach protected data: Elastic's stealer, for example, includes code to unwrap Chrome's DPAPI-protected keys on Windows. File permissions such as 0600 stop other users on the machine, not malware running as the developer.

What it means for engineering and security leaders

• AI tool tokens are production credentials. A Claude, Codex or Copilot token can spend money and, through connected integrations, reach code and pipelines. Put them in the same incident runbook as cloud keys.
• Plaintext configuration is the weak point. Keys pasted into .env files, MCP server definitions and tool settings are exactly what these stealers read.
• Tool provenance is a security control. The Apex agent was mostly genuine code. Approve coding agents and MCP servers by publisher and source, not by whether they seem to work.

Practical takeaways

• Ask each team which AI coding tools they use and where each stores credentials. Prefer the OS credential store: for Codex, enforce cli_auth_credentials_store = "keyring" through requirements on managed machines.
• Look for long-lived API keys in plaintext: .env files, ~/.codex/config.toml MCP env blocks, editor settings and shell profiles. Codex can read an MCP server's bearer token from an environment variable (bearer_token_env_var) rather than storing it in the file; a secrets manager that injects short-lived keys is better still.
• Set spending limits and alerts on provider accounts, so a stolen key shows up as a cost spike rather than a month-end surprise.
• If a developer machine is infected, revoke and reissue AI provider keys and sign out AI tool sessions along with passwords and cloud keys. Check the provider's usage logs for activity you don't recognise.
• Block the indicators Symantec and Elastic published, and add AI tool credential paths to your endpoint monitoring for unexpected reads.
• For the wider pattern of limiting what a stolen agent credential can do, see shrinking a coding agent's credential blast radius.

For teams that want provider keys off developer machines altogether, the SpanDock model proxy, in every plan, makes calls with the server's provider keys, which stay on the server in the OS credential store; the tools on each computer authenticate only with a local proxy key set up for them. It routes API-key traffic only, so Claude Pro and Max sign-ins aren't used while it is on.