Threat IntelligenceAI AgentsIncident Response
Most reporting on AI and ransomware is speculative. Someone demonstrates that a model could write an encryptor, or could plan a network intrusion, and the finding gets published as a warning about what may happen next.
This one is not speculative. It is a log file.
Between April and July 2026, an operator affiliated with the Aurora ransomware group ran their post-compromise work through a commercial agentic coding assistant — and then served their own Linux home directory to the internet on port 8888 with no authentication. CloudSEK found it and published the contents as Caught in 4K: The Aurora Files. Gambit Security's threat intelligence team independently documented the same operator's hands-on exploitation across ten organisations between April 8 and May 26, and The Hacker News tied the two datasets together on August 31.
The exposed directory held four months of operational output against more than 20 organisations across nine countries, with the United States the largest concentration. Inside were SAM and LSA dumps, Group Policy exports, BloodHound collections, the operator's shell history, the Aurora encryptor itself with its ransom note and onion address compiled in — and the prompts.
The interesting part is not that an AI was involved. It is the specific list of tasks the operator delegated, because it is an ordinary internal penetration test, executed by a chatbot.
Per Gambit Security's reconstruction, the operator tasked the agent with:
Nothing on that list is novel. Every technique has been in public tooling for years. What changed is who can now execute it correctly, and how quickly.
Two details are worth sitting with. First, the prompts were written in Russian, and the targeting shows a rule the operator never broke: across three months of target lists, scans and success logs, CloudSEK found no CIS-allocated IP ranges and no CIS-country domains. Second, the operator imposed their own guardrails on the agent — explicitly forbidding DCSync commands and anything that would trigger account lockouts. They were not asking the model to be creative. They were using it as a careful, tireless junior operator who had read every blog post.
The hype reading of this story is that AI has automated intrusion. The logs say something more useful.
Gambit's researchers noted that the majority of the agent's commands failed to achieve the stated objective on the first attempt, requiring repeated refinement of the commands and scripts for each task. The transcript is not a clean kill chain. It is a long, noisy, iterative loop of a machine getting it wrong and trying again.
That is a real finding in both directions. It means the capability is currently an accelerant, not a replacement — the operator still had to know what "correct" looked like. It also means that AI-assisted lateral movement is, for now, louder than a skilled human doing the same work by hand. An expert runs three commands. An agent runs thirty. Every failed NTLM relay, every rejected certipy invocation, every Nmap sweep against a subnet that does not exist is a detection opportunity that a quieter intrusion would never have produced.
Defenders should not take comfort in the failure rate. They should take the noise seriously as signal, and assume the ratio improves.
For all the machine involvement downstream, the front door was human. Initial access came from email bombing a target employee and then calling them on the phone posing as IT help desk staff, offering to fix the flood — and using that trust to establish remote access via the open-source Xray-core utility.
That is the same tradecraft that moved 284 million records out of McKesson with two phone calls and a consent screen earlier this week. No CVE, no exploit, no patch that would have helped. The AI agent did not get in. A person did, and then handed the agent domain administrator credentials, VPN credentials, Kerberos material, Group Policy data and credentials to the backup systems.
The payload is worth a paragraph because it shows the same pattern — competent, current, unremarkable.
The encryptor is written in Zig, a pre-1.0 systems language and an unusual choice in a space dominated by Go and Rust. Both platform builds come from a single codebase: sap.exe on Windows, which deletes shadow copies and disables System Restore, and encrypt.out on Linux and ESXi, which force-kills virtual machines to release disk locks before encrypting. Both use ChaCha20 with RSA-4096 key wrapping. To find hypervisors, the group wrote esxi_finder.py, a custom NetExec LDAP module that discovers ESXi and vCenter infrastructure from Active Directory. The ESXi variant skips system volumes so the host stays bootable, and delivers the ransom note as the SSH login banner rather than a dropped file.
TRM Labs traced the payment side through shared laundering infrastructure and found affiliate splits that moved around — 35/65, 21/79, 46/54, 40/60 — rather than a fixed percentage, which is consistent with an operator negotiating each job rather than running a rigid programme. CloudSEK assessed with high confidence that this was a Russian-speaking operator executing attacks directly, not reselling access.
Strip the ransomware off this story and look at what remains: a person gave an agentic coding assistant a set of credentials and unrestricted network reach, and the agent spent weeks scanning subnets, enumerating directory services, reaching external endpoints and running tooling against internal infrastructure.
Your engineering organisation is doing the identical thing right now, with the same class of tool, and probably with fewer restrictions than Aurora's operator imposed on theirs.
That is the part that should land. The Aurora affiliate told their agent not to run DCSync and not to lock out accounts. Most enterprises cannot produce an equivalent statement about their own coding agents — which model each agent is permitted to call, which tools it may invoke, which external domains it may reach, and what it actually did last Tuesday at 3pm. When an agentic assistant inside your network performs reconnaissance-shaped activity, nothing in a typical stack distinguishes a developer debugging a service mesh from an intrusion in progress. Both look like an AI process making a lot of calls.
The control is not banning the tools. It is knowing where they are pointed.
This is what Obiguard Governance AI is built for: putting a policy boundary and a permanent record around the AI systems operating inside your own environment.
Allow-lists invert the default. Rather than trying to enumerate everything an agent must not do, you register what it may: which model IDs a given agent is permitted to call, which tools it can invoke, and — most relevant to this story — which external domains it is allowed to reach through retrieval or browser tooling. A call outside the approved list is blocked before the request leaves, and written to the ledger automatically. An agent approved to read a service repository does not get to reach an unregistered endpoint just because something in its context told it to.
The Audit Ledger is the other half. It is an append-only, cryptographically immutable record of every prompt, response, tool-call and policy decision — the model called, the agent ID, the initiating user or service account, timestamped to the millisecond. It streams to Splunk, Sumo Logic, Datadog or any SIEM via webhook or S3.
Aurora's operator was caught in full because their agent's activity was written down and left where someone could read it. That is an accident on the attacker's side. On yours it should be a design decision — because if an agent inside your network ever runs the sequence in this article, the log is the only thing that will tell you it happened.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →