Skip to content
Journal

Cybersecurity · Threat Intelligence

Aurora Ransomware Used an AI Coding Agent to Break In

A ransomware crew used Cursor's AI coding agent to run reconnaissance and lateral movement by hand across dozens of victims. What that means for defenders.

Prathviraj Singh

Prathviraj Singh

5 min read

Timeline of the Aurora ransomware group's intrusion stages, from initial access through an AI coding agent to ESXi encryption

Sponsored

Share

Most of the AI-and-ransomware headlines this year have been speculative: a proof-of-concept here, a “what if attackers used this” thought experiment there. Aurora is different. Security researchers at Gambit Security, reported first by The Hacker News, watched an actual ransomware operator run Cursor, a commercial agentic coding tool, as a hands-on member of the intrusion team across at least 10 real attacks between April 8 and May 21, 2026.

Nobody had to speculate about whether this would happen. It already did.

What the agent was actually told to do

This wasn’t an AI generating novel malware from scratch. It was closer to a very literal, very fast junior operator. Once the group had credentials or an existing foothold, sometimes through SOCKS-based proxied access, they handed Cursor’s agent a sequence of concrete jobs: install a VPN client or configure proxychains, scan the internal network with Nmap or NetExec, enumerate domain users to map out privilege levels, then move laterally using NTLM relay techniques (PetitPotam, Coerce Plus, and PrinterBug, all run through Impacket) and certificate-based attacks via Certipy.

None of that is exotic tradecraft. Every one of those tools has existed for years and shows up in red-team playbooks and blue-team detection rules alike. What changed is who was typing the commands.

The operator worked in Russian and gave the agent one hard constraint that shows up in the research repeatedly: exclude CIS-country IP ranges and domains, without exception. That’s not a new pattern, it’s the same jurisdictional shielding that’s shown up in Russia-linked ransomware operations for years. What’s notable is that it was baked directly into the AI agent’s instructions, as a standing rule the operator didn’t have to re-specify for every target.

It didn’t work on the first try, and that’s the actual finding

Here’s the detail worth sitting with: according to the research, most of the agent’s commands failed to achieve their objective on the first attempt and needed refinement before they worked. That’s not a story about an unstoppable AI hacker. It’s a story about an operator who could iterate on failed attack commands faster than a comparable human operator working the same targets by hand, and who could run the same playbook against ten organizations in six weeks instead of stretching it across a quarter.

That’s the actual shift agentic tools bring to offense: not new capability, throughput. The ceiling on what’s technically possible barely moved. The floor on how much a small crew can execute per week dropped.

The payload: conventional ransomware with an ESXi-specific mode

Once the agent-assisted intrusion phase finished, the ransomware itself was unremarkable by design. It’s written in Zig, shipped as separate binaries for Windows (sap.exe) and Linux (encrypt.out), and does the standard pre-encryption housekeeping: deleting volume shadow copies, disabling System Restore, and terminating running virtual machines before the encryption pass starts.

The Linux/ESXi variant carries a dedicated reconnaissance script, esxi_finder.py, whose job is to locate every VMware ESXi hypervisor and vCenter server reachable on the internal network before the operator pulls the trigger. Kill the VMs first, then encrypt the datastore underneath them, is a pattern that’s shown up in enough ransomware families by now (LockBit, BlackCat, and others) that it’s basically the standard playbook for hitting virtualized environments. Aurora didn’t innovate here. It just executed the standard playbook with an AI agent doing more of the manual labor.

How big is this, really?

Estimates differ depending on who’s counting and when. CloudSEK’s independent analysis put the group’s reach at more than 20 organizations across 9 countries, with 4 listed on Aurora’s leak site at the time of their report. Ransomware.Live’s broader, ongoing tracking counts 33 total victims, concentrated in the US, Germany, the Netherlands, Canada, and the UK. Reuters has named specific victims including Christeyns, Teckentrup, the Helideck Certification Agency, Bayou Title, an Argentine pharmaceutical distributor, and an Italian manufacturer.

The variation between trackers isn’t a red flag, it’s normal for an active campaign where new victims surface on leak sites over time and different researchers have visibility into different slices of the activity.

What defenders should actually take from this

Resist the urge to treat “ransomware operators use AI agents now” as a new detection category, because it isn’t one. Nmap scans, NTLM relay attacks, and Certipy abuse all generate the same telemetry regardless of whether a human or an agent typed the command. If your team already has detection coverage for PetitPotam-style relay attacks and unusual Certipy activity, that coverage still applies here.

What’s worth changing is the assumption about attacker tempo. A crew that used to need weeks per target to manually work through recon, privilege mapping, and lateral movement can now compress that into days, because the tedious, error-prone parts of exploitation are exactly what an agent iterates on fastest. If your incident response plan assumes a multi-week dwell time before an attacker reaches your ESXi hosts, this is the case study that says to stop assuming that.

For teams running client infrastructure with any VMware ESXi footprint, isolating hypervisor management interfaces from general network access and enforcing credential rotation after any suspected compromise matters more today than it did a year ago, not because the attack techniques changed, but because the time between initial access and the encryption event just got shorter. If you’re auditing exposure on infrastructure you manage for clients, our security review process starts with exactly this: what’s reachable, what’s credentialed too broadly, and how fast an attacker (human or otherwise) could move from one to the other. It pairs well with the exposure questions we walk through for the recent MikroTik router flaws under active exploitation, since both cases come down to the same root issue: something reachable that shouldn’t be.

Frequently asked questions

What did Aurora ransomware actually do with Cursor?
According to Gambit Security's analysis, the Aurora operator used Cursor's agentic coding assistant as a hands-on operator during the exploitation phase of at least 10 intrusions between April and May 2026. Given valid credentials or an existing foothold, the agent ran reconnaissance, privilege assessment, internal network scanning, and lateral-movement tooling on the operator's instructions.
Is this a new kind of AI-powered malware?
No. The ransomware payload itself is conventional: Zig-language binaries for Windows and Linux that disable System Restore, delete shadow copies, and encrypt data, with a dedicated mode for killing VMware ESXi virtual machines before encrypting the datastore. What's new is using a commercial AI coding agent as the operator during live intrusion, not a new class of AI-written exploit.
Did the operator hide that they were Russian-speaking?
The opposite: researchers observed the operator instructing Cursor in Russian and explicitly directing it to exclude CIS-country IP ranges and domains from targeting, without exception. That's a longstanding operational pattern among Russia-linked ransomware crews, meant to avoid prosecution risk in jurisdictions that don't extradite to the West.
How many organizations has Aurora hit?
Estimates vary by tracker. CloudSEK identified 20+ organizations across 9 countries, with 4 listed on Aurora's data leak site at the time of their report. Ransomware.Live's broader count puts total tracked victims at 33, concentrated in the US, Germany, the Netherlands, Canada, and the UK.
What should security teams actually do about this?
Treat it as a wake-up call about attacker tempo, not a new detection category. The attack techniques (NTLM relay, Certipy certificate abuse, ESXi targeting) are well-documented and already covered by existing detection rules. The change is how fast an operator can chain them together with an AI agent doing the typing, so the real defensive priority is closing the access AI speeds up: credential hygiene, ESXi host isolation, and alerting on the specific tools (Certipy, PetitPotam, NetExec) mentioned here.

Sources

Sponsored

Sponsored

Discussion

Join the conversation.

Comments are powered by GitHub Discussions. Sign in with your GitHub account to leave a comment.

Sponsored