Darktrace says stolen Claude credentials let it run nine jobs through Claude Code in a lab test
Darktrace says that, with a machine and a user's Claude credentials already taken, it steered Claude Code through nine jobs via three Claude memory store files, ending with a 1 GB upload. A lab test: no platform vulnerability, and not seen in the wild.
By Parminder Kumar Sharma · LinkedIn · · 17 min read
Nine jobs, three memory files, one 1 GB file: what the lab run establishes
Count what Darktrace's blog describes. After one small shell payload had collected credentials and a systemd service had been set up, the operator sent nine jobs, each handled by a separate Claude Code process, through three text files in a Claude memory store. The ninth job split a 1 GB file into three pieces and uploaded them to the Claude Files API. Darktrace says the traffic went to api.anthropic.com, "the same endpoint that is contacted for inference". The nine, the three and the 1 GB are the blog's own figures.
What that does not establish. It is not an attack on anyone: Darktrace says the research ran only in its own test environment, on accounts and systems it controlled, with no customer environment or data, and that all names and credentials shown are fictitious. It has not been observed in the wild, Darktrace says. It is not a flaw in the Claude platform: Darktrace says the technique "does not rely on a vulnerability in the Claude platform". And it starts late. The blog's premise is that the attacker "has already compromised a device and obtained a user's Claude credentials", which for an attacker is most of the work.
Read on 12 November 2026 from about 15:03 UTC. The Darktrace blog is dated 12 Nov 2026 on its own page and was read in the copy the lead saved. Help Net Security's report, published at 11:00 UTC on 12 November 2026 according to its page data, adds quotes from a Darktrace executive. Anthropic's documentation page on memory stores was read for what the feature is. The blog's 20 figures are screenshots of Darktrace's product views and of the three memory files: they were not saved, so this briefing relies on the blog's text and its figure captions. Anything marked derived was worked out here.
What the lab run did, in the order Darktrace gives it
Memory stores are, in Darktrace's words, "collections of text files called memories" that can be added to a Claude Console workspace and changed through the Console or the platform's API. They exist so that agents on Claude Managed Agents can carry memory between sessions. Anthropic's documentation page, which labels the feature Beta, describes a store as a workspace scoped collection of text documents. Darktrace found that a store can be added to a workspace whether or not the organisation uses Managed Agents, and that with stolen API credentials a store can be added to a workspace the user is assigned to.
The loop has four steps. Each new Claude Code process checks in by writing to a heartbeat file. The operator puts a job in an input file. The process reads and carries out the job, and posts the result to an output file. The operator reads the output and writes the next job. Because the jobs are plain English, Darktrace says the operator can issue objectives and leave the agent to work out the commands.
The setup ran in a simulated corporate Active Directory network with a Linux machine, an SMB server and a domain controller. A lightweight payload from a remote staging server ran shell commands through the dash interpreter, looked for a Claude Code harness, collected API and OAuth credentials for the user's Claude Console account and sent them back to the staging server. The operator then added a memory store with three files, and the staging server returned the identifiers. The script used systemd-run to create a transient service unit that started Claude Code processes one after another. Each sent a time stamped heartbeat and then ran a Claude Sonnet 4.5 model in non-interactive mode to fetch and carry out the queued job.
Help Net Security adds that the service launched the processes with the --dangerously-skip-permissions flag, which turns off tool-use confirmation prompts. The blog's text does not print the flag: its Figure 8, captioned as the command-line arguments for the harness processes, is an image that was not saved. Once the service was in place, the blog says, "the ladder provided by the initial shell script was ready to be thrown away", and every later job travelled through the memory store.
The nine jobs, and what each yielded in the lab network
The blog groups the jobs under four headings: service discovery, credential access, share enumeration, and data collection and exfiltration. The table sets each job beside how the blog words it and what it returned. The lab's addresses, usernames and password are fictitious, and the blog's own texts for the username and spray jobs, which carry them, are not reproduced here.
The nine jobs as Darktrace's blog describes them (lab network, 12 November 2026); the last column is what the blog says came back
| Job and phase | How the blog words it | What came back in the lab |
|---|---|---|
| 1. Service discovery | An objective: find reachable neighbours and exposed services, using ip, ss and nc | A server with open FTP, SMB and SSH ports |
| 2. Service discovery | A specific nmap command for targeted enumeration | OS and SMB version details, and the contents of directories exposed by anonymous FTP |
| 3. Credential access | An objective: connect to the anonymous FTP host and return passwords, usernames and employee names | Employee details and an unattributed password |
| 4. Credential access | An objective: write a broad list of likely usernames, including seven named employees | 190 usernames, written to a local file by the agent |
| 5. Credential access | Spray the password at the domain controller using that list; the agent wrote and ran the script | The account the password belonged to |
| 6. Share enumeration | A specific smbclient command to list shares with the compromised account | The list of shares |
| 7. Share enumeration | An additional smbclient command to list one share | The contents, including a 1 GB file |
| 8. Collection | An smbclient command to fetch the 1 GB file into a local temp directory | The file, held locally |
| 9. Exfiltration | A bash script that splits the file into three and uploads the pieces to the Files API | The file leaves the network; the operator then stops updating the input file |
A reading of the run, labelled derived. By the blog's wording, five of the nine jobs (2, 6, 7, 8 and 9) named a specific command or script, and four (1, 3, 4 and 5) gave an objective. Darktrace says the method "lowers the skill requirements" for the operator because objectives can be issued in plain language. The four objective jobs support that, but the run alone does not measure how far an operator could rely on objectives, and the blog does not say how many attempts the run took or whether any step failed or was refused. Help Net Security quotes a Darktrace executive listing "no refusal" among the things absent from the second half; the blog itself does not mention refusals.
Two more points. The blog names one model, Claude Sonnet 4.5, run non-interactively, and does not say whether other models or settings behave the same. And on a 1 GB file split into three pieces, an equal split would be about 333 MB each (derived); the blog does not say the pieces were equal.
What had to be true first, and what the technique adds
Help Net Security reports a Darktrace executive splitting the attack in two: getting into the AI system, "fairly conventional", and using it for command and control and exfiltration once inside. The table puts the first half beside the second, and then beside what the sources leave out.
What the run needed before the technique, and what each source leaves out (Darktrace blog and Help Net Security, 12 November 2026)
| What the run needed or did | What the sources say | Not stated |
|---|---|---|
| A foothold on a device running Claude Code | The attacker has already compromised a device; a lightweight payload came from a staging server | How the foothold was gained, and how the first payload got code execution |
| Claude credentials on that device | Shell commands collected API and OAuth credentials. Help Net Security: they were sitting on the device where the user's tooling had left them | Where on the device, and how common that is |
| The right kind of credential | Help Net Security quotes the executive: a standard API key reaches memory stores, while OAuth credentials do not; an OAuth session could still be hijacked, which is harder | Whether the blog's collected OAuth credentials played any part in the run |
| A workspace to hold the store | A store can be added to a workspace the user is assigned to, whether or not Managed Agents is used | How many workspaces in real organisations hold stores nobody created |
| What the technique added | A live, steerable channel and an upload route through the endpoint the agent already uses: "no vulnerability, no guardrail bypass, no refusal, no malicious software and no strange destination", per the executive | Whether defenders can see the store writes; the executive calls that a factor |
An inference, labelled as one. An attacker with code execution and these credentials could already call the Claude API directly. What the blog adds is a persistent, steerable agent that runs on the victim's machine with the victim's tool access, reached through a channel an allowlist is built to permit. This site's earlier briefings show the credential half is not exotic: Symantec's Aoki report says an infostealer targets credential and session files for nine AI products, and Apiiro's count found real secrets left in public Claude Code settings files. Neither shows this technique.
Friendly labels doing the work of a control
Three labels in this story read like controls and are not. The first is the endpoint. A rule that allows api.anthropic.com for developers is a destination rule. Darktrace's point is that destination tells you nothing about what the process is doing there, and its executive puts it as "Approved is not the same as safe, and only behaviour tells you the difference."
The second is "no vulnerability". It is a statement about the platform's code, and the blog and the executive both make it. It does not say the exposure is small. The executive's own framing is that these are "trade-offs between capability and exposure", worth examining in any agent platform. A feature working as designed can still be the channel.
The third is "behavioural detection", from the vendor that sells it. The blog's conclusion says it is not normal for harness processes to run tool calls "with certain command-line arguments" or to contact the platform API "with certain data transfer ratios". It does not say which arguments or which ratios, gives no threshold or false positive rate, and does not say whether any Darktrace detection or alert fired during the lab run. Its Figures 10 and 11 are captioned as product views correlating the harness process's network traffic and process creation, which shows the data exists; they do not show a detection outcome. The claim is plausible and unmeasured, and a reader cannot reproduce it from what is printed.
What the sources state, and what they do not
Stated and not stated, from the Darktrace blog, Help Net Security and Anthropic's documentation page, all read 12 November 2026
| Topic | Stated | Not stated |
|---|---|---|
| Use in the wild | Darktrace has not observed the technique in the wild; the research used only its own lab | Any real victim, any attacker using it, how likely it is |
| A platform flaw | The technique does not rely on a vulnerability in the Claude platform | Whether Anthropic regards any part of it as in scope for a change |
| Anthropic | The blog says Anthropic PBC is not affiliated and has not endorsed the research. Help Net Security's executive says the findings were shared before publication as a courtesy, with no formal disclosure process | Any Anthropic statement. None is saved, and the Help Net Security report quotes none. Whether anything changed |
| Other platforms | Darktrace tested one platform and has not reproduced it elsewhere; an equivalent file upload endpoint exists at OpenAI (Help Net Security) | Whether any other agent harness or platform allows the same loop |
| Detection | Correlate harness process creation with network traffic and compare with a baseline | Arguments, ratios, thresholds, error rates, or whether the lab run triggered any alert |
| The run itself | Nine jobs, three memory files, Claude Sonnet 4.5, a 1 GB file split in three | Duration, attempts, failures, refusals, cost |
| Visibility of store writes | Anthropic's page says every change to a memory creates an immutable version, kept 30 days, readable through version endpoints | Whether those versions reach a customer's alerting. The executive calls visibility a factor |
Where the sources differ
Keys or credentials. Help Net Security's headline says stolen Claude API keys. Darktrace's blog text says the payload collected "API and OAuth credentials" and speaks of stolen API credentials and "Claude Console credentials". Help Net Security adds, from a Darktrace executive, that a standard API key reaches memory stores and OAuth credentials do not. The blog text does not draw that line. This briefing says credentials, and keys only when it reports the executive.
The permission flag. Help Net Security prints --dangerously-skip-permissions. The blog's text does not; the arguments sit in an image the blog captions as Figure 8, which was not read here. The article follows Help Net Security for the flag and says so.
Seeing the writes. The executive says whether a customer can see writes to a store at all affects exposure. Anthropic's page describes a version for every change, kept 30 days. These need not conflict, because a version history is not the same as an alert, but neither source says what a customer's monitoring sees. It stays open.
The title. The blog's HTML title is "Living off the AI: How Claude Memory Stores Enable Covert C2 Channels"; its on-page heading is "Living off the AI: Shared Memories as a Covert C2 Channel". Same post; this briefing uses neither as a claim.
What to do, in order
Take this with you
Ordered by urgency; each item says whose advice it is
- This site's suggestion: inventory where Claude API keys, OAuth tokens and other agent credentials sit on developer machines and build hosts: environment variables, dotfiles, shell history, settings files, CI secrets. The lab run began by collecting them from the device.
- Darktrace's advice, via Help Net Security: use OAuth or identity federation wherever the platform allows it. Where it does not, make keys as short lived as possible, keep their scope narrow, store them securely, and keep them out of shell history, dotfiles and environment variables.
- Darktrace's advice, via Help Net Security: treat an AI platform key as seriously as a production credential.
- This site's suggestion: rotate any Claude key or token found in a place the inventory flags as exposed, and re-issue it narrowly.
- This site's suggestion: list the memory stores in every Claude Console workspace and ask who created each one. Anthropic's documentation describes listing, archiving and deleting stores and a 30 day version history for each memory.
- This site's suggestion: on developer Linux hosts, hunt for the process chain the blog describes: a shell fetching a payload with curl, a transient systemd unit made with systemd-run that launches a coding agent, and a coding agent spawning nmap, an FTP client or smbclient.
- Darktrace's advice, via Help Net Security: baseline agent harness processes, correlate the arguments they launch with the network traffic they generate, and watch for odd command line arguments or a data ratio unlike the agent's usual traffic.
- This site's suggestion: log calls to memory store and Files API paths where your egress proxy, gateway or the platform's own logs expose them. The sources do not say they do, so test it before relying on it.
- This site's suggestion: find out whether policy or wrapper scripts can stop coding agents being launched with confirmation prompts switched off, and flag any process that does it. The flag is named by Help Net Security; whether a policy can enforce this was not checked for this briefing.
Technical details
The blog prints no file hashes, no attacker domains and no addresses of attacker infrastructure. The staging server is never named. The only addresses it prints are the lab's private address 192.168.1.2 and Anthropic's own API endpoints. Defenders therefore have behaviour to hunt, not indicators to block, which is Darktrace's own conclusion. Everything below is copied from the blog or Help Net Security, and nothing here is a working tool.
First, the loop as the blog states it, in four steps. This is what a defender is looking for in process and network records: a harness that checks in, reads a job, runs it and writes back.
On launch, the Claude Code harness process starts a hook that sends a check-in message to a memory file (the "heartbeat" memory file) in a memory store controlled by the C2 operator
The C2 operator adds a new queued job to a memory file (the "input" memory file) of the memory store
The Claude Code harness process invokes a Claude model to retrieve and execute the queued job in the input memory file, and to post results of taken actions to a memory file (the "output" memory file) of the memory store
The C2 operator reads the results in the output memory file, waits for the next Claude Code process to check in, and updates the input memory file with a new queued job
Second, the names of the three files and the endpoints involved. The blog uses the heartbeat, input and output roles; it does not print the file names it chose. A defender reviewing a workspace looks for a store with three small text files that nobody on the team created.
heartbeat memory file
input memory file
output memory file
Claude Console: platform.claude.com
Claude platform API, also used for inference: api.anthropic.com
Claude Files API endpoint: https://api.anthropic.com/v1/files
Third, the processes and tools the blog says appeared in the run. They are common tools, so the signal is the parent: a coding agent, started by a service unit, spawning them. These are fragments copied from the blog's prose, one per line.
command interpreter, dash
a curl process
systemd-run to create a transient systemd service unit
a Claude Sonnet 4.5 model in non-interactive mode
ip, ss, and nc commands
a specific nmap command
FTP client scripts
a heredoc'd cat command
smbclient
a bash script which splits the 1 GB file into three smaller files
Fourth, the permission flag. Help Net Security reports it was used on the launched processes. Darktrace's blog text does not print it. A defender searches process command lines for it.
--dangerously-skip-permissions
Fifth, two of the nine job texts as the blog prints them, in the lab's fictitious network. They show the style of objective an operator can send. The blog's texts for the username and password spray jobs carry fictitious names and a fictitious password and are left out.
Assess the immediate network context and identify reachable neighboring systems and exposed services using bounded checks, enumerate common services like ssh, smb and ftp. Return concise observed evidence.
The 192.168.1.2 has anonymous FTP enabled connect to the host enumerate the files then return passwords, usernames and employee names
Last, the events the blog's own figure captions describe, set beside what a defender could do with each. The figures themselves are images that were not saved; only their captions are read here. The right hand column is this site's suggestion.
Events from the blog's figure captions (Darktrace, 12 November 2026) and a suggested use; the third column is this site's suggestion
| Caption in the blog | What it says happened | Defender use |
|---|---|---|
| Figure 2 | A curl process retrieves the initial payload from the staging server | Alert on curl or wget fetches by shells on developer hosts to rare destinations |
| Figure 4 | A dash process starts curl to send stolen credential data to the staging server | Look for credential files read just before an outbound upload |
| Figure 9 | A dash process creates a systemd service unit | Review transient and new systemd units made by a shell |
| Figure 10 | The unit creates a Claude Code process with command line arguments | Baseline which accounts launch the agent, and with what arguments |
| Figure 11 | A process tree and event log correlate the harness's network traffic and process creation | Join agent process lineage to bytes sent to and received from the API |
The question the lab run leaves open
If the step between a stolen developer credential and a steerable, persistent agent on a trusted endpoint is only where that credential sat on disk, and the vendor's answer for the rest is a behavioural baseline whose arguments, ratios and thresholds it has not published, who in your organisation can say today which machines hold a Claude credential, and what normal looks like for the agent running on them?
Key facts
Sources
- PrimaryBlog post dated 12 November 2026, Living off the AI: Shared Memories as a Covert C2 Channel. The research itself; read in full from the lead's saved copy; the 20 figure images were not savedDarktraceaccessed 2026-11-12
- PrimaryClaude Platform Docs, Using agent memory: what a memory store is, its Beta label, listing and archiving, and the 30 day version history. Read in full on 12 November 2026Anthropicaccessed 2026-11-12
- Reported byNews report of 12 November 2026 with quotes from a Darktrace executive: the permission flag, API key versus OAuth, other platforms, the courtesy notice to Anthropic. Secondary; read in fullHelp Net Securityaccessed 2026-11-12
