Symantec names 9 AI products in Aoki infostealer's targets; victims, sample dates and delivery are not stated

Nine AI products in one stealer's target list, and no count of victims

Symantec's Threat Hunter Team says newer versions of the Aoki infostealer (also called Aokigahara) now harvest credential and session files for AI coding assistants. Counting the products named across its report, published on 15 October 2026, gives 9 (derived): Claude, ChatGPT, Codex, Cursor, Codeium, Gemini, GitHub Copilot, JetBrains AI Assistant and Kiro, plus Amazon Web Services (AWS) credentials. The key findings paragraph names 5 of them and the paragraph on the newest version names 8; Codeium appears only in the first, and four products appear only in the second. Earlier versions, Symantec says, "did not target AI-related files", which it takes to mean the capability is a recent addition.

Set that against what the same report lists as Aoki's older targets. The key findings sentence names 7 categories (browsers, cryptocurrency wallets, password managers, messaging and gaming applications, and VPN and FTP clients), and the body lists 13 groups of target (derived), with about 200 named applications and wallets (derived, each listed entry counted once). AI products are therefore a small, new addition to a long list that is mostly about money: Symantec reads the "strong focus on cryptocurrency-related wallets and extensions" as pointing to a financial motive.

Counting is as far as the numbers go. The report states no count of victims, of stolen AI credentials, of samples by version or of any resale or misuse. It says what the malware was designed to take, not what it took. Symantec itself calls the AI capability "recent" and says it "appears to be expanding". A list of targets in a sample is a finding about the code. It is not a finding about harm.

This briefing reads Symantec's page in full, not the coverage of it. Infosecurity Magazine's report of the same day was also read in full and was used only as a pointer. Everything was read between 14:14 and 14:42 BST on Thursday 15 October 2026, so a vendor page or a detection could change within hours. Defender level only: Symantec's page lists 17 file hashes and three network domains (counted, not reproduced). This briefing prints no indicator, no file name or path of any credential store, no domain and no command-and-control detail, and describes the targets as each assistant's configuration, cookie and token stores.

Interests, in one sentence: Symantec sells endpoint protection and its report is a vendor's own telemetry and analysis, and every AI vendor named here sells the assistant whose credentials are discussed, so each is treated as an interested party and every claim below is attributed to the party that made it.

Stated and not stated: the Aoki record, line by line

"Not stated" means not found in the Symantec page read in full, or in the Infosecurity article. It does not mean the information does not exist.

What Symantec's report of 15 October 2026 states about Aoki, and what it does not. Quotations are short and exact. Infosecurity Magazine's article adds nothing that Symantec does not say, except one label noted in the last row.

The question	Stated	Not stated
Which AI products?	Key findings: Claude, OpenAI's Codex, Cursor, Codeium and Gemini. Newest version: Claude desktop and ChatGPT cookies, Codex configuration files, and tokens for GitHub Copilot, Cursor, Gemini, JetBrains AI Assistant and Kiro, plus AWS credentials.	Which version takes which product, or why Codeium is in the key findings but not in the newest-version paragraph.
How many samples, versions, dates?	"Older" and "newer" samples, and "the most up-to-date sample" analysed. 17 file hashes are listed (counted, derived).	A sample count, a version number or a date for any sample, or which samples carry the AI capability.
When first seen?	"Earlier in 2026".	A month or date. At most 287 days before the report (derived, 1 January to 15 October).
How many victims?	Nothing.	Any victim, machine, country or sector count.
How many AI credentials taken?	Aoki was "designed to harvest" the files.	Any count of keys or tokens taken, or whether any still worked.
Any resale or misuse seen?	A stolen AI key "can be cashed in directly, either through resale or by running up usage". That is a statement about keys in general.	Any observed resale, billing abuse or use of a credential taken by Aoki.
How is it delivered or sold?	It "collects whatever data is available and sends it" to a server. The malware "has no backdoor command list".	How it reaches a machine, whether it is sold or private, and who uses it.
Which operating systems?	It steals Outlook passwords "from the registry", which suggests Windows (inference).	Any statement of the operating systems targeted. CYFIRMA's August report lists Windows.
Who is behind it?	"We do not know what threat group may be behind this malware", and no indication of links to an existing family.	Any attribution, or whether other families overlap.
What does it take from AI tools?	Credential, token and session files, "rather than source code". The exception is Cursor's local state database, which "can cache chat context and code snippets".	Whether other products' prompts or histories are taken, or whether any protection had to be defeated.
Did an AI vendor respond?	Neither source quotes any AI vendor.	Any vendor statement, advisory or count of abuse tied to Aoki.
Detection?	Symantec Endpoint products "will detect and block that file" if the file is available to Symantec, under one family name.	Detection by other products, or how long samples went undetected.
Infosecurity's label	Infosecurity's article calls Cursor "SpaceX's Cursor".	Symantec's report says nothing about who owns Cursor, and Cursor's terms of service name Anysphere as the provider. This briefing makes no claim about ownership.

The clock: public records of Aoki are 48 to 65 days older than the report

Symantec says there has been "some limited publication" about the malware and cites none. The two earlier public records found in a limited search both predate its report. MalwareBazaar, the public sample database run by abuse.ch, shows a signature named AokigaharaStealer with a first sample on 11 August 2026 (65 days before Symantec's report, derived) and the latest on 12 October (3 days before, derived). CYFIRMA's weekly report of 28 August 2026 (48 days before, derived) picks "Aokigahara Stealer" as the malware of the week, types it as an information stealer, and lists Windows as the target technology and the geography as global. That report does not mention AI tools or cryptocurrency wallets.

Two cautions. The database page records a count and dates, not an analysis, and its label is MalwareBazaar's own identification. That these are the samples Symantec tracks is an inference from the shared name. And neither date is the first sighting: Symantec's own "earlier in 2026" is undated. So the record does not say when the AI capability was added. Symantec says only that older samples lacked it.

Dated public records read on 15 October 2026. Rows about other stealers are included because they set the context in which Aoki's AI capability appeared. Day counts are derived from the dates shown.

Date	Source	What it records
March 2026	SpyCloud, post of 10 September	Remus, a different Windows stealer, appears on underground marketplaces. Recent builds target AI credential folders.
11 August 2026	MalwareBazaar signature page	First sample under the Aoki-named signature. 16 samples listed on the page (as read).
28 August 2026	CYFIRMA weekly report	Aokigahara Stealer as malware of the week: Windows, global. No AI content. 48 days before Symantec.
8 September 2026	Gen, first post	Stealer collection rules now include AI agent data. Names other families. Does not name Aoki. 37 days before.
9 September 2026	Okta	Analysis of a free log dump of 2 August. Counts AI session tokens and keys. A different dataset.
September 2026	Anthropic threat report	Criminal groups sell stolen AI API keys and session tokens. No mention of Aoki found.
29 September 2026	Gen, on Warden Stealer	The authors of another stealer announce collection of AI coding agent tokens in version 1.9. 16 days before.
12 October 2026	MalwareBazaar signature page	Latest sample under the Aoki-named signature. 3 days before.
15 October 2026	Symantec	AI-file theft called recent and expanding. No dates for samples.

Aoki is one of several stealers reaching for AI assistants, and the evidence is thin on harm

Symantec says Aoki's targeting of AI assistants "hasn't previously been reported", which is a narrow claim about one family. Other security vendors reported other stealers doing the same before 15 October, and none of the pages read names Aoki. The table sets out what each says. The security vendors in the table each sell a related product, and each report is its own telemetry or analysis. Anthropic's is a vendor's account of misuse of its own service.

Other reporting on stealers and AI credentials, read on 15 October 2026. Different datasets, different families; the figures are not additive and none is about Aoki.

Source and date	What it reports	What it does not give
Gen, 8 September 2026	Recent stealer collection rules include data for Claude, Cline, Codex, Continue, Cursor and OpenCode. One family, then called CallbackBeaver, was seen in more than 5,000 samples in a 30-day period. A macOS stealer is linked to Claude, Codex, Gemini, Cline, OpenCode and Kilo. "AI agent data appearing in the collection rules of another stealer almost every day".	Aoki is not named. Detections, not confirmed infections, and the figures may overlap.
Gen, 8 October 2026	Warden Stealer is a malware-as-a-service stealer written in Rust. Gen says it is "one of the first infostealers" it has seen taking AI assistant files, and that the authors announced AI coding agent token collection on 29 September.	Aoki is not named. Gen's account of how the family is sold and priced is for Warden only.
SpyCloud, 10 September 2026	Remus targets AI credential folders in recent builds. SpyCloud says public reporting names ClickFix lures as a common route to Remus.	Aoki is not named. Delivery for Aoki is not stated anywhere.
Okta, 9 September 2026	A free dump of 5,871 infected-machine folders, released on 2 August, held 561 unique Anthropic tokens, 164 of them unexpired on 2 August, on 404 machines. Cursor: 32 tokens, 16 unexpired. It found 24 still-valid API keys for four AI services.	Which families produced the dump, beyond an example involving Remus. Whether any token was used.
Anthropic, September 2026	Access to AI "in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups". One scheme spread credential harvesters posing as AI harnesses, "including Claude Code". A harvester "continued to identify any new sessions" after the victim's keys were reset.	Any link to Aoki. Anthropic sells an assistant named in Symantec's report.

Two derived figures from Okta's table put the scale in proportion. 164 of 561 Anthropic tokens were unexpired, 29.2 per cent (derived), and they sat on 404 of 5,871 machines, 6.9 per cent (derived). Okta says AI-related session tokens were on "the majority of infected machines" in its sample and "many still valid months after collection". It also warns that whether a thief could use a replayed token depends on matters such as monitoring and IP restrictions. These are one vendor's count from one free dump, not the number of AI credentials Aoki has taken, which no source gives.

Anthropic's account of harvesters that keep collecting new sessions after a reset bears on a question every responder asks: whether revocation is enough. On Anthropic's account of a different campaign, it is not enough while the harvester is still on the machine. Gen's advice agrees: after an infection, revoke sessions and rotate keys "from a clean device". One route into developer machines is covered on this site: a fake Claude installer reached through a search advertisement. No source says Aoki arrives that way.

What each vendor's own pages say: where the login lives, how long it lasts, how it ends

The question for an engineering lead is what each of these files is worth to someone who copies it. Only the vendors can say, and the pages read answer unevenly. All statements below are the vendor's, read on 15 October 2026 from the pages cited in the sources list, and none is checked against the product.

Where the login is kept, as each vendor describes it. No file name or path is reproduced here.

Product (vendor)	Where the vendor says it is kept	Not stated
Claude Code (Anthropic)	The macOS Keychain; if the Keychain rejects a write, a file readable only by the user, the same storage it uses on Linux. On Windows, a file that inherits the user profile's access controls.	Whether the stored file is encrypted. How Claude Desktop keeps its session is not described on the pages read.
Codex (OpenAI)	"a plaintext file ... or in your OS-specific credential store", chosen by a setting. OpenAI says to treat the file "like a password: it contains access tokens".	Which option is the default is not stated in the lines read; the "auto" setting uses the credential store when available.
GitHub Copilot CLI (GitHub)	The operating system's keychain by default. If none is available, the CLI offers a plaintext configuration file.	Anything about the IDE extensions.
Gemini CLI (Google)	"Your credentials will be cached locally for future sessions."	Where, in what form, or for how long.
Cursor CLI	Browser login: "your credentials are securely stored locally".	Where, in what form, or for how long.
JetBrains AI Assistant	Not stated. An API key is entered in the AI Assistant settings.	Where it is kept, or for how long.
Kiro (AWS)	Not stated on the page read.	Where, in what form, or for how long. The page lists sign-in through GitHub, Google, AWS Builder ID, IAM Identity Center or an external provider.
AWS access keys	AWS says keys in the shared AWS credentials file "are stored in plaintext".	Anything about the AWS CLI's other stores.
Codeium	No vendor page on credentials found.	Everything.

Lifetimes are where the pages differ most. Of 18 credential types tabulated, a lifetime or expiry rule with a number is stated for 8 and none for 10 (derived). Where a vendor states no lifetime, the table says so, and this briefing does not guess one.

Lifetime and ending as the vendors state them. A row marked not stated means the pages read give no figure. Sources: the vendor pages in the sources list.

Credential	Lifetime as stated	How it ends, as stated
Claude Code one-year token	A "one-year OAuth token", from the setup-token command. It "can only make model requests".	No revocation step stated for it on the page read.
claude.ai web session	28 days when inactive, and any action refreshes it to 28 days from that point.	Terminate one session, or log out of all, in Settings, Account; the Help Center lists web, mobile and desktop apps as signed out. Claude Code authorisations are removed under Settings, Claude Code.
Claude API key	Chosen at creation: 3 hours, 1 day, 7 days, 30 days, custom, or Never. Not changeable afterwards.	Disable (reversible) or Delete (permanent) in the Console. A personal key stops when its owner leaves the organisation.
Claude Code subscription login	Not stated. A warning appears 3 days before expiry.	/logout. Server-side revocation not stated on the page read.
ChatGPT web session	Not stated.	"Log out all" in Settings, Security. Other sessions can take up to 30 minutes to end.
Codex sign-in with ChatGPT	Not stated. Tokens refresh automatically in use.	The log-out action is described as one that will "clear the current credentials". Server-side revocation not stated.
Codex access token (Business, Enterprise)	Chosen at creation, for example 7, 30, 60 or 90 days. An earlier dialog offered No expiration.	Revoke on the Access tokens page. Disabling local Codex permission suspends tokens but "doesn't revoke them".
OpenAI API key	Optional expiry date. Administrators can cap the maximum. No default stated.	Revoke the key. Hard spend limits stop traffic when reached.
Cursor login and API key	Not stated.	API keys are managed on the dashboard. Sign-out of other sessions not stated on the pages read.
Gemini CLI login (Google OAuth)	Not stated on the Gemini CLI page. Google's OAuth page says a refresh token can stop working if unused for six months.	Remove the app's access in the Google Account.
GitHub token (the kind Copilot CLI uses)	Revoked after one year unused. GitHub App user tokens expire after 8 hours by default. For Copilot CLI, GitHub says lifetime and expiration "depend on how the token was created".	Copilot CLI /logout "does not revoke it on GitHub". Revoke under Settings, Applications.
JetBrains AI Assistant	Not stated.	Revoke the authorisation in Agent Authorization, or log out of JetBrains AI.
Kiro through IAM Identity Center	Extended Kiro sessions up to 90 days (AWS).	Sign-out ends the sign-in session. Issued role sessions continue, up to 12 hours.
Kiro API key	Described as "long-lived credentials", no number.	Revoke in the Kiro web console.
AWS long-term access key	No expiry stated. AWS says exposure might give someone "permanent access to your account".	Delete or deactivate the key.
AWS temporary credentials	15 minutes up to 36 hours.	Revocable, but permissions must also be changed to stop use.
Codeium	No vendor page found.	No vendor page found.

Three of these rows are the friendly-name problem in miniature, because a verb that sounds like an ending is not one. GitHub's page says Copilot CLI's sign-out "removes the locally stored token but does not revoke it on GitHub". AWS says signing out of its access portal ends the sign-in session, while IAM role sessions already issued "continue until they expire", up to 12 hours. OpenAI says disabling local Codex permission suspends a token and "doesn't revoke" it.

What the vendors' pages name as reachable through each credential or account, counted from the pages. The counts are derived and mix different kinds of item, so they are shown per row, not as a total of services one thief could reach. 27 named items across eight rows; 25 distinct names after merging the repeated GitHub and GitLab (derived).

Credential or account	Items the page names	Does the page say a stolen copy reaches them?
Claude, signed in with a claude.ai account	4: claude.ai connectors, scheduled routines, Remote Control sessions, cloud sessions	Not stated for a stolen local copy
Claude, one-year token	1: model requests	Stated: it "can only make model requests"
Codex access token	2: Codex CLI runs, app-server client runs	Stated: "anyone with the token can start local runs" as its creator
Codex, signed in with ChatGPT	2: Codex cloud, Work Cloud local computer access	Not stated for a stolen local copy
Cursor team account	9: Slack, Microsoft Teams, Jira, Linear, Notion, GitHub, GitLab, Azure DevOps, Bitbucket	Not stated for a stolen local copy
GitHub Copilot CLI token	3: Copilot cloud agent (/delegate), GitHub MCP server, GitHub code search	Not stated for a stolen local copy
JetBrains AI Assistant, activated	4: Junie, Claude Agent, Codex, GitHub Copilot	Stated: one activation "also grants access to all AI Assistant features and other integrated agents"
Kiro Web	2: GitHub, GitLab	Not stated for a stolen local copy

Read the last column first. Only three of the eight rows carry a vendor statement about what the credential itself grants, and the others describe what an account can be connected to, which is a different question. Anthropic states that its one-year token "can only make model requests". OpenAI states that "anyone with the token can start local runs" as the token's creator. JetBrains states that activating one integrated agent through its subscription "also grants access to all AI Assistant features and other integrated agents". For the Gemini CLI login, the AWS access keys, the ChatGPT web session and Codeium, no vendor page read lists what is reachable. For AWS the answer is whatever the key's permissions allow, and the page gives no count.

The clock on a stolen token, and what the NCSC says a short one does not do

If a token were taken and never revoked, it would stay valid for its stated lifetime. As an illustration only, since no source says any token was taken on a particular date: the gap between the first vendor write-up of Aoki and Symantec's report is 48 days (derived). Three stated lifetimes are longer than that: Anthropic's one-year token (365 days, derived), the 90-day option on OpenAI's Codex access tokens, and AWS's extended Kiro sessions of up to 90 days. Four credential types also allow or imply no expiry: Anthropic's API key with the Never option, Codex tokens from the earlier dialog that offered No expiration, OpenAI API keys where no administrator cap is set (inference from OpenAI's wording that a cap prevents keys "remaining valid indefinitely"), and AWS long-term access keys. A one-year token created on the day of Symantec's report would run to 15 October 2027 (derived).

The shortest stated lifetimes are not a complete answer either. The NCSC's multi-factor authentication guidance, in a section on anti-patterns, says rigid time-outs limit "the time that a session credential (often a 'cookie' or other 'token') is useful for, in case it is stolen by malware", but that forced re-authentication does not "effectively limit an attacker's impact, as they often use a stolen session credential to promptly find and steal sensitive data before they are detected". Its alternative is detection: a suspected stolen session credential "should trigger a contextual access policy to block its use". The pages read for this briefing do not say whether any of the assistants offers that kind of detection. Okta's own post makes the same point from the other side: strong sign-in "does not stop a stolen session token or API key".

One machine, ten stores of credentials: what each reaches and what ends it

The diagram puts the three questions on one page: what one machine holds, what the vendors say it can reach, and what ends it. It draws a list of targets from Symantec's report and statements from the vendors' pages. It does not draw a theft.

Nine friendly names, and what each one hides

A label can sound like a measurement or a control when it is neither. These appear in the Aoki coverage or in the vendors' own pages.

Labels in the story, where each appears and what the record shows.

The label	Where it appears	What it hides
"Infostealer"	Symantec; Infosecurity.	A category, not a capability list. Symantec says Aoki has "no backdoor command list" and sends what it collects to its server. The harm, if any, comes at a later stage, which neither source describes.
"AI credentials"	Symantec's headline and significance section.	One phrase for at least five different things: a one-year token, a 28-day browser session, an API key with optional expiry, an OAuth login and AWS keys. A lifetime figure is stated for 8 of 18 credential types tabulated here.
"API key"	Symantec; every vendor.	A static secret. Anthropic says a personal key "acts as you" with your roles and permissions; a legacy workspace key keeps working after its creator leaves. Expiry is optional and may be Never.
"Session token"	Symantec; Okta; Anthropic.	Okta says a replayed token leaves a thief "effectively logged in to an LLM service without actually logging in". Gen says multi-factor authentication "may not stop abuse of a session token that has already been stolen".
"LLMjacking"	Symantec: "sometimes called".	Sysdig coined it on 6 May 2024 (892 days before Symantec's report, derived) for stolen cloud credentials used against hosted models, and estimated over $46,000 a day of consumption for a victim in the worst case if undetected. No source read measures any loss from Aoki.
"A legitimate developer's identity"	Symantec.	The service sees a genuine credential, so its logs point at the victim. Anthropic's report lists the attacker's gains as loot, compute and "Cover: The activity is attributed to the credential's legitimate owner".
"Bypass safeguards"	Symantec; Infosecurity.	No safeguard is named. Controls on the key itself, such as spend limits, expiry and scope, are the vendors' documented levers, and none is shown to have failed here.
"Sign out" and "log out"	Vendor pages.	Often local only: Copilot CLI's "does not revoke it on GitHub", Codex's suspend-not-revoke, AWS role sessions that run on after sign-out.
"Securely stored"	Cursor's page on browser login; Claude Code's page.	Says nothing about a process running as the same user. Gen warns that encryption at rest is a reassuring label without a threat model. Symantec does not say whether Aoki had to defeat any protection.

Method is separate from accusation. Symantec's report is a plain description of what the code does, with a stated limit on what is known, and the AI vendors' pages are mostly candid about expiry and revocation. The gap is that no source joins the two: which stolen credential, from which product, was usable, for how long and for what. A separate briefing on this site, about a flaw in Claude Code Desktop, shows the same pattern from another angle: the public record of the desktop app's flaw was a researcher's report, and no vendor advisory was found.

The UK: what the NCSC, Cyber Essentials, the ICO and UK GDPR say, and where each stops

No UK source read for this briefing mentions infostealers that target AI assistants. What follows is existing guidance applied by analogy, which is inference, with each document's limit stated. All were read on 15 October 2026 from the pages cited.

UK guidance and law as read, with where each stops. Quotations are short and exact.

UK instrument	What it says	Where it stops
NCSC, "Protect your code repository" (Secure development and deployment guidance, published 20 February 2019)	"Loss or compromise of access credentials ... may allow attackers to modify your code base". Separate secret credentials from source code. Revoke access "swiftly ... in the event of compromise". Its self-assessment calls insecure developer devices a risk that puts "repository access keys at heightened risk of being stolen".	Written in 2019 for small and medium organisations about code repositories. It does not mention AI assistants or the tokens they hold.
NCSC, multi-factor authentication for corporate online services (published 26 September 2024): "Avoiding MFA anti-patterns" and "Gaining trust in devices"	Time-based re-authentication does not effectively limit an attacker who steals a session credential. Suspected stolen sessions should trigger a contextual access policy. The device "has to be trusted enough to store and protect the user's digital identity" with secure credential storage.	Aimed at administrators of services the organisation controls. The assistant vendors' pages read do not say whether they offer those controls.
DSIT and NCSC, AI Cyber Security Code of Practice (31 January 2025)	Voluntary. Principle 5.4: developers, system operators, data custodians and end-users "shall protect sensitive data ... against unauthorised access". 6.1: evaluate access control frameworks to secure APIs. 12.1: system operators shall log system and user actions.	Written for developers and operators of AI systems. Whether an organisation using a coding assistant counts as a system operator or only as end-users is a reading, not stated. It does not mention stealers. "Shall" binds only those who choose to follow it.
Cyber Essentials requirements for IT infrastructure v3.3 (April 2026)	Malware protection "active on all devices in scope", through anti-malware software or application allow listing. User accounts with unique credentials, removed when no longer needed. For cloud services, "authentication to cloud services must always use MFA".	No mention of API keys, session tokens, cookies or AI. A certificate covers the scope the applicant defines. Sign-in MFA does not address a session token already issued.
UK GDPR Article 32 and the ICO's data security guide	"Appropriate technical and organisational measures" for "a level of security appropriate to the risk". The ICO says the regulation does not define the measures, and that Cyber Essentials is "only intended to provide a 'base' set of controls".	Bites only where personal data is involved. The ICO marks the guide as under review because of the Data (Use and Access) Act.
UK GDPR Article 33 and the ICO's breach page	Notify the regulator "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach, unless it is unlikely to result in a risk.	Whether a stolen assistant token that reached a repository or chat history is a personal data breach depends on what it reached. No UK source read says.

What a UK engineering lead can rely on is the baseline: malware protection, unique accounts, MFA, secrets kept out of code, and prompt revocation, all of which the sources above state. What none of them settles is the specific exposure here, which is a login that sits in a store on a developer machine and may keep working after the machine is cleaned, depending on its lifetime and on whether anyone revoked it. Article 32 is the lever: a risk assessment that leaves out the assistants' credential stores is an assessment of a smaller estate than the one that exists. The 72-hour clock in Article 33 starts on awareness, so the decision of who determines whether an exposed token reached personal data should be made before an incident, not during one.

What to do, in the order worth doing

Every item is a control one of the sources already names. None needs Aoki to be present to justify it, and none relies on an indicator, which this briefing deliberately does not print.

A last point on order. Revocation is only worth doing in the sequence above, because on Anthropic's account a harvester still on the machine feeds the thief each new session. Cleaning the machine comes first, and the vendor-side revocation second. On long-lived secrets in general, this site has covered 543,699 working credentials found in public GitHub code, where at least 63 per cent of the working credentials predate the push protection meant to block them.

What could not be verified

• Victims, credentials taken, misuse. Not stated by Symantec or any source read, and no vendor statement about abuse tied to Aoki was found.
• Samples, versions and dates. Symantec gives none. The 17 hashes were counted, not checked, and not compared with MalwareBazaar's 16 samples. MalwareBazaar's per-sample pages sit behind a bot check and were not opened; only the signature page was read.
• The first public report. CYFIRMA's 28 August 2026 report is the earliest write-up found in a limited search, and MalwareBazaar's 11 August entry is the earliest record. Neither is shown to be the first.
• Vendor pages. No Codeium page on credentials was found. Cursor, JetBrains and Kiro state no lifetime for a local login. The Gemini CLI page states none. For Claude Desktop, only the Help Center's session statement was read.
• OpenAI's Help Center. It refused a plain download (HTTP 403), so those two articles were read in a browser tab, where they loaded normally with no check to pass. Cookies were not accepted.
• Anthropic's September report. Its sections on AI access and credential harvesting were read. It is a vendor's own account and does not mention Aoki.
• Infosecurity's label. "SpaceX's Cursor" is not in Symantec's report. It was left out.
• Counts. The 9, 13, about 200, 17, 18 and 27 figures are this briefing's counts from the cited pages. Symantec lists its entries in prose, so a different counting rule could give a different total.
• Time-stamped. Sources were read between 14:14 and 14:42 BST on 15 October 2026.

The question that exposes the gap

If a stealer ran on one of your developers' laptops tonight, could you list every AI and cloud credential that machine held, say which of them you could end from the vendor's side before morning, and name the person who knows where each switch is?

Key facts