Aurora Ransomware Ran Cursor's AI Coding Agent Through Ten Live Intrusions

Ten. That is how many victim networks an Aurora ransomware affiliate ran Cursor's AI coding agent through between April 8 and May 21, tasking it the way you would task a junior pentester: check what rights this account has, find a path to domain admin, confirm whether this host is an ESXi server. Cursor Agent, running Anthropic's Claude Sonnet model, did the reconnaissance and the tool selection. A human still pulled the trigger on the ransomware.

The research comes from Gambit Security, whose director of threat intelligence Eyal Sela published a detailed account on August 27 built from an exposed operator server: six weeks of session logs showing an Aurora affiliate handing the agent credentials or an existing foothold, then issuing objective-based prompts instead of raw commands. CloudSEK's parallel report, drawn from the same misconfigured infrastructure, puts the wider campaign at more than twenty organizations across nine countries between April and July, with four victims already listed on Aurora's leak site and the operator's Cursor chat logs, written in Russian, sitting in plain text next to Kerberos tickets, SAM and LSA dumps, BloodHound collections, and the ransomware binary itself.

Here is the relevance verdict. If you run on-premises Active Directory, Active Directory Certificate Services, or VMware ESXi, this one is yours to read carefully; the tools the agent drove are the same ones a competent red team already uses against you, which means your detections either cover them today or they do not. If your entire estate is cloud-native SaaS with no Windows domain and no hypervisor to protect, most of the hunting guidance below will not apply, though the closing section on governing your own coding agents still will.

What the agent actually did

Per Gambit's account, the operator supplied Cursor Agent with valid credentials or an existing route into the target, then worked in short, plain-language tasks rather than scripting each step by hand, asking things as simple as what rights a given account held. Most first attempts did not succeed. Reporting corroborating Gambit's findings notes the majority of commands failed to achieve the stated objective on the first try, requiring the operator to refine the prompt and try again. Sela's own estimate, cited in that same coverage, is that the agent made the crew 30 to 50 percent faster while running entirely conventional techniques: credential theft, Kerberos abuse, Active Directory escalation, account takeover. Nothing here is a novel exploit class. The agent is a force multiplier on tradecraft that already existed.

The recovered session logs list a specific toolchain: NetExec and Nmap for enumeration, Certipy for certificate-based attacks, the PetitPotam, Coerce Plus, and PrinterBug NTLM-coercion techniques feeding Impacket's ntlmrelayx, GodPotato for local privilege escalation, and a custom NetExec LDAP module named esxi_finder.py built specifically to locate ESXi hosts and vCenter servers inside the target's directory. CloudSEK separately found a full Active Directory Certificate Services exploitation plan, drafted entirely by the agent in Russian, sitting among the recovered chat logs. None of these tools are exotic. They are the standard kit of any AD-focused red team engagement, which is exactly why the detections below matter more than any AI-specific defense would.

GodPotato and the recovered use of s5cmd round out the toolkit for a reason worth noting separately. GodPotato abuses the SeImpersonatePrivilege token right, a default on many built-in Windows service accounts, to escalate a low-value web-facing process straight to SYSTEM. s5cmd is a legitimate, high-throughput S3-compatible command-line client, here repurposed to move stolen data out fast once the operator reached a host with outbound internet access. Neither tool triggers most signature-based antivirus, since both are widely used by legitimate administrators; the reliable signal is context, meaning a service account invoking either tool at all is the anomaly, not the binary itself.

The identity surface: Certipy and NTLM coercion

Certipy targets misconfigured certificate templates in Active Directory Certificate Services, the class of bug security researchers label ESC1 through ESC8, where a low-privilege account can request a certificate that authenticates as someone else, including a domain admin. PetitPotam, Coerce Plus, and PrinterBug force a machine account to authenticate outward to an attacker-controlled listener over MS-EFSR or MS-RPRN RPC calls, and Impacket's ntlmrelayx catches that authentication and relays it somewhere useful, frequently straight into a certificate enrollment endpoint. Chained together, this path gets an attacker from a single foothold to domain admin without ever touching a password hash on a domain controller. Any organization running ADCS at all, including the common case of running it quietly for internal TLS or 802.1x Wi-Fi authentication, has this exposure whether or not anyone remembers configuring it.

# Hunt for NTLM-coercion attempts (PetitPotam / Coerce Plus / PrinterBug)
# against domain controllers and CA hosts: MS-EFSR or MS-RPRN RPC calls
# originating from hosts that have no business making them.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5145} |
  Where-Object { $_.Message -match 'EFSRPC|SPOOLSS' -and
                 $_.Message -notmatch 'PRINTSRV01|BACKUPSRV01' } |
  Select-Object TimeCreated,
    @{n='SourceAddress';e={($_.Properties[1]).Value}},
    @{n='ShareOrPipe';e={($_.Properties[5]).Value}}

# Flag certificate requests against a template that allows client
# authentication with an enrollee-supplied subject name, the pattern
# Certipy's ESC1 attack automates.
Get-WinEvent -LogName 'Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational' `
  -MaxEvents 1000 |
  Where-Object { $_.Message -match 'Template' } |
  Select-Object TimeCreated, Id, Message

Run both queries against every domain controller and certificate authority host, not a sample. A single unexplained hit from a workstation that has no service account reason to talk to a CA is worth a same-day follow-up, not a ticket for next sprint.

The ESXi blind spot

Aurora's payload is written in Zig, an uncommon choice for ransomware, with separate Windows and Linux builds. The Linux variant, compiled as a roughly 139 KB ELF binary, uses ChaCha20 encryption with RSA-4096 key wrapping and is built to target ESXi directly: it encrypts every virtual machine's disk files while leaving the hypervisor host itself bootable, so the ransom note displays and the box still answers pings while everything running on it is gone. esxi_finder.py exists precisely because most small and mid-market environments run VMware without pointing meaningful logging at the hypervisor layer. ESXi's own syslog rarely gets forwarded anywhere, and endpoint detection tools almost always run inside guest virtual machines, never on the host underneath them.

Aurora's targeting of ESXi over generic Windows file servers is not incidental. A hypervisor hosting a dozen virtual machines gives an attacker a single encryption pass that takes down every workload those VMs run, with none of the per-host lateral movement a Windows-only campaign requires. For a small IT team, recovery time then scales with the number of guest VMs on the box, not the number of hosts the attacker actually touched directly, which is why one unmonitored ESXi host is a worse single point of failure than it looks on an asset inventory that only counts physical servers.

The concrete fix is not exotic either: forward ESXi and vCenter syslog to your SIEM or, at minimum, to a separate log host the hypervisor cannot reach, and alert whenever SSH is enabled on a host outside a scheduled maintenance window. An encryptor built to reach the datastore directly needs shell access to the host, and SSH is normally disabled by default on ESXi. An unexpected SSH-enabled event is one of the highest-signal, lowest-noise alerts you can stand up on infrastructure that otherwise gets almost no security attention.

Why the money trail still matters for response

CloudSEK partnered with TRM Labs to trace the operator's cryptocurrency payments and confirmed two victim payments plus two more consistent with separate, unconfirmed victims, moving through two dominant consolidation clusters with variable affiliate splits ranging from 35/65 up to 46/54 before cash-out. There is no fixed cut; the split varies case to case. The practical point for an incident responder is narrower than the laundering analysis itself: capture any ransom wallet address from the negotiation chat before you close the case, even if your organization never pays. That address costs nothing to record during containment and feeds directly into the clustering work that eventually supports attribution and law enforcement referrals for other victims of the same affiliate.

Govern the agent sitting on your own developers' laptops

The finding generalizes past this one campaign. Any AI coding agent with shell access and an inherited credential or session, Cursor or any competitor with the same agentic feature set, carries exactly the access it was handed, regardless of whether the hands typing the prompt belong to a ransomware affiliate or one of your own engineers with a broadly scoped service account pasted into a chat window. Three checks worth running against your own environment this week: confirm which service accounts and API keys any AI coding agent in use has access to, and whether that access is narrower than what the underlying human developer already holds; log agent-initiated shell and API commands with the same fidelity as an interactive session, since "the agent ran it" is not a smaller audit event than "I ran it"; and review whether your agent tooling has any equivalent of the objective-based tasking Aurora used, where a single high-level instruction can trigger a chain of privileged actions without a human reviewing each step.

Point Your ESXi Syslog at a SIEM Before You Worry About the AI Angle

The AI part of this story is the least urgent part to act on. The NTLM-coercion paths, the unmonitored ADCS templates, and the unmonitored hypervisor layer were all exploitable before Cursor existed; Aurora's affiliate just got faster at using them. Run the two PowerShell hunts above against every domain controller and CA host this week, confirm ESXi and vCenter syslog actually lands somewhere you watch, and only after those two items are checked off should you turn to reviewing what your own AI coding agents are authorized to touch. Sequencing it any other way spends your attention on the newest part of the story instead of the part still open on your network today.