Executive Summary

An exposed open directory revealed months of activity from belonging to a Russian speaking Aurora ransomware affiliate, active against more than twenty organisations between April and July 2026. The directory included the operator's own toolkit and shell history alongside the Aurora encryptor itself, with the ransom note and onion address embedded directly in the binary. Four of the operator's victims have since been listed on Aurora's leak site.

With keys recovered from the encryptor CloudSEK gained visibility into past ransom negotiations. In partnership with TRM Labs, CloudSEK traced the resulting payment on chain and found it converging with at least one other Aurora victim's payment through shared laundering infrastructure. 

We assess with high confidence that the operator is a Russian-speaking Aurora affiliate operating directly, not a broker selling access onward.

Disclosure note: Coordinated notification to the relevant national CERTs and/or the victims was initiated ahead of publication for the organisations identified in this report that have not yet appeared on Aurora's public leak site. TRM Labs reviewed the on-chain findings described in this report ahead of publication. Publication was held until 27 August 2026 to allow notification to proceed.

Key Findings

• The exposed directory provided a timestamped record of the operator's activity spanning April to July 2026.
• The operator compromised more than twenty organisations across nine countries, achieving domain-level or interactive access at seventeen of them, four of which were later listed on Aurora's public leak site.
• A key recovered from the operator's own encryptor binary gave CloudSEK visibility into negotiation between the operator and a victim.
• In partnership with TRM Labs, CloudSEK traced the resulting payment on-chain. TRM's independent analysis of Aurora's broader on-chain footprint identified two confirmed victim payments and two further payments consistent with separate victims, all converging through a shared laundering network, rated high-moderate confidence.
• The operator used Cursor, an agentic coding assistant, to plan attacks in Russian, while excluding CIS ranges and CIS-country domains, without exception.
• The Aurora encryptor itself is written entirely in Zig, an unusual language choice in this space..

Taken together, these findings place this operator well beyond the point where access simply becomes sellable: a repeatable AD-compromise playbook, an encryptor deployed under the operator's own hand, and a payment trail that TRM Labs has now linked to more than one victim through shared laundering infrastructure.

The Open Directory

The directory was the operator's own Linux home directory, served without authentication from a file listing on port 8888. Results are filed per organisation with a consistent naming convention. Kerberos tickets and credential material remain in place from the time of collection. SAM and LSA dumps, Group Policy exports, and BloodHound collections sit alongside the operator's shell history, Cursor chat logs, and the Aurora encryptor itself.

The ransom note embedded in that encryptor matches Aurora's published note character for character. Four of the operator's recorded victims later appeared on Aurora's leak site with matching organisational and technical detail.

‍

Following the Attacker's Keystrokes

Infrastructure

• Every victim-facing action routed through a rented SOCKS pivot, mostly VPS providers in Germany and the US. The operator's own infrastructure never touched a victim network directly.

Enumeration

• NetExec driven LDAP and SMB discovery, password policy retrieval, ASREPRoasting, Kerberoasting the same sequence, the same output file naming convention, every time. Against the operator's deepest engagement, this reached many hosts across several domain controllers.

Escalation

Three paths, chosen by target:

• A custom-scripted noPac chain (machine-account rename, TGT, S4U2self)
• ADCS abuse across ESC1, ESC6, and ESC8
• NTLM relay coerced via PetitPotam, PrinterBug, and DFSCoerce

In some cases template misconfiguration capable of minting a domain-administrator certificate was also identified and pursued live by the operator.

Exfiltration

• PowerShell-driven 7-Zip archiving in 50GB chunks, staged and pulled. 

Encryptor

• 2 different variants of the Aurora encryptor were found each for Windows and Linux, both written in Zig and pulled from a public Cloudflare R2 bucket and pushed via scp to staging hosts. The ESXi variant stops running VMs before it starts encrypting.

Planning

In the final weeks, the operator's history shows Cursor in active use drafting and reasoning through attack sequences, including a full ADCS exploitation plan written entirely in Russian. The recovered sessions, run against a multiple victim, show unusually sustained back-and-forth use of the tool.

Exploitation Arsenal

Exploit code for at least a dozen distinct vulnerabilities was staged across the tree. Most are unmodified public proof-of-concept clones, several still carrying their original authors' metadata and credit lines. A small number were modified beyond upstream, and one FortiOS toolkit was rebuilt as an independent framework.

The operator also maintained a private GitLab repository of custom NetExec modules, including a browser-credential module targeting seven browsers and a dedicated ESXi-discovery module, documented in Russian.

Inside The Ransomware Payloads

Ransomware written in Go has been common for years, and Rust has picked up ground more recently. Zig is a different choice, and a much rarer one. It's a young, still-pre-1.0 systems language that shares some of Go's appeal for this kind of tooling: single static binaries, straightforward cross-compilation to multiple operating systems from one source tree, and no garbage collector or runtime overhead getting in the way. What it doesn't share is the track record. Public malware corpora have far fewer Zig samples to train signatures against than they do Go or Rust, and a binary this unusual is arguably easier to fingerprint precisely because it stands out, not because it hides better.

Both encryptor binaries, the Windows sap.exe and the Linux/ESXi encrypt.out, are static builds from a single Zig codebase, compiled for different targets rather than written twice. The Windows binary even carries the Linux build's usage examples inside it, a leftover from sharing one source tree across both platforms.

‍

The full flag set, as compiled into both binaries:

• -path <folder>: target a single folder rather than every disk (the default is everything)
• -percent<N>: encrypt only 0-100% of each file's contents, defaulting to an automatic ratio based on file size, speed over completeness
• -f<N><K|M|G>: skip files above a given size
• -threads <N> / -scanners <N>: control worker and scanner thread counts, defaulting to twice the core count
• -noparallel: disable multi-threaded encryption of a single file
• -esxi: a dedicated mode that encrypts only VM-related files (vmdk, vmx, vmsd, vmsn, nvram, vmem, vswp, log) while explicitly skipping ESXi's own system volumes
• -extensions <list>: Windows-only, restrict encryption to specific file extensions
• -allowfolders <list>: Linux-only, opt back in to system folders like tmp and var that are otherwise skipped

The Windows Variant

A single routine chains four separate anti-recovery steps: it enables backup privileges, shells out to delete every volume shadow copy and resize shadow storage, disables System Restore directly through the registry, then checks for a running Hyper-V management service.

‍

‍The Linux/ESXi variant

Before encryption starts, the locker enumerates every running virtual machine on the host and force kills each one individually in a single command.

Once the VMs are down, the ransom note doesn't get dropped as a file the way it does on Windows. It     gets written into the ESXi host's own SSH login banner.

Two smaller details round out the Linux build. An entropy watchdog checks the kernel's available randomness before generating key material, and logs a warning if the system's entropy pool looks exhausted, a rare bit of self-awareness in ransomware tooling and an orchestrator function ties the ESXi decision tree together, calling the VM-killer as one step in a larger sequence rather than running it standalone.

Targeting and Victimology

The operator's victim set spans nine confirmed countries, with the United States accounting for the largest share. A handful of victims remain unidentified and are excluded from the country breakdown until confirmed.

‍

Manufacturing organisations make up the largest single sector, followed closely by food and agriculture, pharmaceutical and chemical distribution, and professional and consulting services. The spread reflects an opportunistic operator working whatever access becomes available, rather than one pursuing a specific industry.

Most of these organisations have not appeared on any public leak site. A small number of those cases are named below, since the compromise is already public. Everyone else is being handled through coordinated notification and is not identified here. One additional case in the dataset had already been breached by a different ransomware group roughly a year earlier, this operator's own access attempt against it failed outright.

The interval never runs longer than a couple of months, and in the fastest case barely two weeks pass between the operator's recorded access and the listing going live. That range is short enough to rule out a broker sitting on access indefinitely before selling it it reads as one operator moving from intrusion to extortion on a working schedule, not shopping access around.

Tooling

Attribution

A Russian speaking operator

Every artifact the operator wrote themselves, Cursor plans, module documentation, session notes, is in Russian, not translated boilerplate and not inherited from an upstream tool.

We assess a Russian speaking operator with high confidence.

An Aurora affiliate, not a broker

The recovered activity doesn't stop at the point access becomes sellable. It runs through credential theft, domain compromise, exfiltration, encryptor staging, and, as this report shows, completed payments. The encryptor sits in the operator's own directory, ready to deploy, not handed off to someone else.

What happens after access is established is visible in public leak-site reporting. The following two cases are already public; several further instances of the same pattern exist in the directory against organisations not yet named here.

CIS exclusion

No CIS-allocated IP range and no CIS-country domain appears anywhere in three months of target lists, scans, or success logs. A behavioural pattern from the operator's own data, also information derived from HUMINT sources say the same.

Following The Crypto

A key recovered from the Aurora encryptor provided access to the record of a negotiation between  the operator and a victim. The negotiation had already concluded by the time CloudSEK reviewed it.

CloudSEK is not naming that victim, and will not in any future publication. What follows is the    payment, not who paid it.

The negotiation followed the pattern Aurora's other threads reportedly do: an opening demand, a deadline framed around public disclosure, and a closing line that discouraged any further contact once payment was committed.

It ended with a settlement. The wallet address the operator provided for payment was found to hold 7 BTC at the time of analysis, a balance more consistent with accumulated proceeds from several victims than a single payment, and itself a strong indicator that this operator's activity generates significant revenue.

Working with TRM Labs, CloudSEK traced that payment on-chain. Independent analysis of Aurora's broader on chain footprint surfaced a wider pattern than a single transaction.

‍

We identified two confirmed victim payments and two further payments consistent with separate victims, all moving through the same laundering infrastructure. Each payment starts on its own path with its own split, but several of these paths don't stay separate. They reconverge downstream at shared consolidation points before continuing toward cash-out. This shows a laundering network, not a single network.

No consistent affiliate cut. Ransomware-as-a-service economics typically assume a fixed or near-fixed split between the affiliate who carries out the intrusion and the operator running the program behind it. Across the payments we examined, that assumption doesn't hold. The splits vary: 35/65, 21/79, 46/54, 40/60, with no single ratio repeating. This matches what CloudSEK separately learned through direct HUMINT engagement that the affiliate's cut is negotiated per victim, scaled to the ransom amount and other factors like revenue etc, not fixed in advance. Two independent sources, on-chain data and direct engagement, arriving at the same conclusion.

‍

The splits blur once they merge. We colour-coded the flows by which side of the initial split they originated from, then followed them downstream. Some consolidation points show a clean pairing; others show a mix, funds from what looked like the operator's share and the affiliate's share landing in the same downstream cluster. If flows that merge are assumed to belong to the same party, that assumption breaks here. It means either the initial split isn't a clean two-party division to begin with, or affiliate and operator proceeds are being deliberately pooled before cash-out

‍

The traced funds pass through two dominant consolidation clusters before reaching cash-out addresses. One payment breaks that pattern: it moves through a sequential "peeling chain," a laundering technique that shaves off amounts step by step across a series of hops, straight to cash-out, without passing through either consolidation hub.

‍

‍

Zoomed out, the pattern holds across the full set of traced flows, not just the handful of examples above. Two dominant nodes account for nearly all of the branching, pulling in payments from across the network before funnelling them down through several more layers to a small number of final cash-out points. The isolated exception described above is visible here too: one thin chain running down the left side, separate from both hubs, reaching its own cash-out point without ever joining the larger structure.

‍

Assessment

One operator, methodical, Russian-speaking, running the same AD-compromise playbook across a wide and opportunistic victim set, increasingly leaning on an AI coding assistant to plan each new engagement, and, as this report shows, sitting behind a payment network that moves more cryptocurrency through more victims than any leak site discloses. Roughly one in five confirmed victims has reached public extortion. The financial picture here suggests the real scale is still wider.

‍

‍

‍