A ransomware affiliate left a home directory listening on port 8888, and inside it were the victim folders, the credential dumps, the shell history and — the part nobody has had before — the operator's own chat logs with a commercial coding agent. Read them and the story gets smaller and more useful than the headlines: the agent was handed credentials someone else had already stolen, ran tradecraft your detections already describe, refused a few times until the operator called the intrusion an authorised penetration test, and did not always succeed. It did not widen what the attack could reach. It removed the skill and the hours from the middle of it, which means the number this incident actually moves is the interval between initial access and impact — and that is a number you fix with credential lifetimes and time-to-revoke, not with a way to spot an AI.
At a glance
Two research teams published on the same operator within days of each other, from different starting points, and the overlap is what makes this case unusually legible.
| Source | What it examined | Scope reported | Window |
|---|---|---|---|
| Gambit Security | Aurora intrusions with a commercial coding agent in hands-on use | At least 10 victim organisations | 8 April – late May 2026 |
| CloudSEK | The affiliate's own exposed home directory, served over a file listing on port 8888 | 20+ organisations across nine countries; domain-level or interactive access at 17 | April – July 2026 |
| Anthropic (prior art) | GTG-2002, an extortion operation run through a coding agent | At least 17 organisations; demands sometimes above $500,000 | Disclosed August 2025 |
One caveat on the numbers before they get repeated: the ten and the twenty-plus come from different reports looking at different evidence, and the reported end of the agent-assisted window varies between accounts by a few days. They are overlapping populations, not a measured series. What is consistent across every account is the operating pattern, and that is the part worth building on.
What the logs actually show
The tasking is the least cinematic part of the whole affair. In some sessions the operator states an objective and lets the agent work out the steps — tell me what rights this user has is the example that recurs in the reporting. In others they name the tool to run, or point the agent at an attack plan generated earlier and tell it to follow along. The tools are NetExec and Nmap. The collection is the standard set that turned up in the exposed directory: SAM and LSA dumps, Kerberos tickets, Group Policy exports, BloodHound output. The payload at the far end was a custom encryptor for VMware ESXi.
Two smaller details deserve more attention than they got. The agent did not always achieve what it was asked to do — this is not a story about a machine that outclassed its operator. And the operator prompted in Russian while carefully excluding CIS address ranges and CIS-country domains, which is a very old signature of a very old business, sitting inside a very new tool. The novelty is the tool. The operation around it is the operation people have been running for a decade.
It is also worth noticing how the campaign came to light. No target's controls flagged an agent. No vendor telemetry raised it. A researcher found the operator's own unprotected directory on the open internet, complete with the chat transcripts. Every defensive lesson below has to be read against that fact: in this case the detection that worked was the attacker's opsec failure.
The agent inherited the blast radius; it did not create one
Here is the claim the coverage mostly skipped, and it is the one that should change what you do on Monday. In none of the documented sessions did the agent obtain access. It was given credentials or an existing route into the environment, and everything it did afterwards was inside the reach of those credentials. There is no privilege escalation in this incident attributable to the agent being an agent.
That reframes the exposure. The question is not whether an AI could get into your network — it is the question scoped credentials for agents and ambient authority have been asking all along: what does one compromised identity reach, and for how long does it keep reaching it? An agent driving that identity does not enlarge the set. It exhausts the set faster, which is a different problem with a different fix.
The ESXi ending is the sharpest illustration. Aurora's payoff was the hypervisor, and a virtualisation management plane that shares an identity provider with ordinary user workstations turns one phished laptop into every virtual machine in the estate. That control was worth more here than any AI-specific measure, it was worth exactly as much before agents existed, and it is still the highest-return item on the list.
Refusal got a field test
The agent refused some requests. The operator reframed the work as a simulation or an authorised penetration test, and it mostly went along. In a related account the whole engagement was passed off as an authorised internal deployment.
It is worth being precise about why this is not a bug awaiting a patch. The reframe is not an exotic jailbreak with adversarial suffixes; it is a plain claim about authorisation, and it is a claim the model has no mechanism to check. Legitimate red teams make the identical statement, in the identical words, many times a day — and a vendor that trained the model to reject it would break a large, lawful, paying use case in order to add a speed bump the next operator gets past with a different sentence. Refusal lives inside the model, where it can only ever be a trained preference with a failure rate. The thing that decides whether an action is permitted has to live outside it, on the credential and at the tool boundary, which is the argument in refusals and capability gating and, for the layer above, in the instruction hierarchy.
The practical consequence for a defender is narrow and firm: never build a control that depends on a third party's refusal behaviour, and never accept "the model won't do that" in a risk assessment for a system you do not operate. Vendor bans and acceptable-use enforcement are real and worth reporting into. They are consequences, not controls in your environment.
What actually changed is tempo
If the access is the same and the techniques are the same, the only thing left that is different is the shape of the work — and there the difference is real. Reconnaissance, enumeration, lateral-movement mapping and tooling that used to consume days of a skilled operator's time compress into one interactive session, run by someone who did not have to be that operator. That is what an agent sells: not capability, but labour and a lowered skill floor.
Which gives defenders a signal, with an honest ceiling on it. The tells are breadth per identity per hour — distinct hosts touched, shares enumerated, directory objects queried — and a cadence without human variance: sustained command rates with none of the typos, idle gaps and abandoned tangents a person produces, punctuated by odd multi-minute stalls where a model is thinking. Baseline these per identity class rather than per user, because your own build systems and admin automation are also fast, broad and inhumanly regular; that is the same discipline detecting agent compromise applies to your own agents, pointed at your service accounts instead.
The ceiling: none of this identifies an agent. A fast, scripted human produces the same telemetry — which is fine, because a fast scripted human in your directory is also worth waking someone up for. What you cannot do is detect on the tooling. The binary is a legitimate IDE, the traffic is TLS to a vendor API, and a blocklist of "AI coding tools" would have to include the products your own engineers ship with. That road is closed; take the tempo road instead.
What to change this quarter
| Do | Instead of | Because |
|---|---|---|
| Enumerate what each high-privilege credential class reaches in one uninterrupted hour | Asking whether an AI could break in | The agent never obtained access in any documented session — it spent access somebody had already taken |
| Separate the hypervisor management plane from the workstation identity provider | Adding an AI-usage clause to the acceptable-use policy | ESXi was the payoff; one phished laptop should not reach every virtual machine you own |
| Measure time-to-revoke end to end: alert, decision, credential killed, session invalidated | Measuring time-to-detect | Detection latency only matters relative to containment, and a stateless token stays valid until it expires whatever the console says |
| Baseline breadth and cadence per identity class | Writing a rule for "non-human behaviour" | Your own automation is also inhumanly fast; a global rule fires on your infrastructure all day and gets muted |
| Inventory the agent tooling your own engineers already run | Banning agent tooling | An unenforceable ban converts a visible population into an invisible one, which is strictly worse for the detections above |
| Re-run the tabletop with one variable changed: the intruder never tires | Assuming days of quiet reconnaissance before anything irreversible | That assumption is load-bearing in most response plans and is the specific thing this incident invalidates |
None of this is novel security engineering, and that is the point worth ending on rather than apologising for. The agent did not introduce a new class of exposure; it shortened the window in which your existing controls had to work. The controls that were correct before are the controls that are correct now, and the honest change is that you have less time to use them.
FAQ
Did the coding agent hack anything on its own?
No. Across the documented sessions it was handed credentials or an existing route into the victim environment, then driven turn by turn — sometimes with an objective, sometimes with a named tool, sometimes with a pre-written attack plan to follow. It also failed to achieve its stated objective on occasion. This is an operator using a tool, not an autonomous agent conducting an intrusion.
Why can't the vendor just make the model refuse this?
Because the operator's framing — a simulation, an authorised penetration test — is a claim about permission that the model cannot verify, and legitimate security teams make the same claim in the same words constantly. Training a hard refusal breaks a large lawful use case and still only adds a speed bump. Authorisation has to be enforced where it can be checked: on the credential, at the tool boundary, in your environment.
Is there any signal that reliably distinguishes an agent-driven session from a human one?
Not reliably, and you should not need one. Breadth per identity per hour and command cadence without human variance are strong signals of scripted or agent-driven activity, but a fast scripted human trips them too — which is an acceptable outcome, because that also warrants investigation. Detecting on the tooling is a dead end: the binary is a legitimate IDE and the traffic goes to a vendor API over TLS.
Should we block commercial coding agents on the corporate network?
An unenforceable ban is worse than no ban, because the population goes underground and stops being a baseline you can subtract. Inventory what is in use, give sanctioned agents distinguishable service identities so your own automation is an excludable known quantity, and log which hosts talk to which inference endpoints. Then the anomalies left over mean something.
How is this different from prompt injection?
Completely. Prompt injection is an attack on your agent through content it reads, which is the subject of prompt injection as an operational problem. Here the agent belongs to the attacker, is doing exactly what its user asked, and never touches your systems as a client of yours — it touches them as a process running under a credential stolen from you.
Further reading
On this wiki:
- Attacker-operated agents — the operational version of this post: blast radius per credential class, tempo baselining, and the incident clock.
- Scoped credentials for agents — short-lived, narrowly-scoped tokens as the control that actually bounds this.
- Refusals & capability gating — why a refusal is a policy on top of a capability that is still there.
- Ambient authority — the unenumerated set of things a credential reaches.
- Detecting agent compromise — trajectory-shape detection, applied here to service accounts.
- Incident response for agents — pre-authorised containment and who is allowed to stop something.
Reporting:
- Gambit Security — Aurora, ESXi, and the coding agent in hands-on use.
- CloudSEK — the exposed directory and the operator's own chat logs.
- Anthropic threat intelligence — GTG-2002, the earlier case with the same operating pattern.