An open web directory on port 8888 exposed an Aurora ransomware operator’s working files: Kerberos tickets, credential dumps, shell history, Cursor chats, victim folders, and the encryptor itself. CloudSEK’s investigation says the directory recorded activity against more than 20 organizations in nine countries between April and July 2026.
The operator achieved domain-level or interactive access at 17 organizations. Four later appeared on Aurora’s public leak site. CloudSEK and TRM Labs also traced two confirmed victim payments and two additional payments that they assessed were consistent with separate victims, giving the exposed files a financial trail beyond the public extortion listings.
CloudSEK held publication until August 27 while it initiated notification to relevant national CERTs and organizations that had not been publicly named. The research company does not identify most victims or quantify how many intrusions reached encryption. Its report also includes no response from Cursor’s developer, Anysphere.
An open directory mapped victims
The exposed directory was the operator’s Linux home directory, served without authentication. It kept each target in a consistent folder structure. SAM and LSA dumps, Group Policy exports, BloodHound collections, shell history, and credential material remained beside the Aurora encryptor and the operator’s planning notes.
That accidental archive let investigators compare private records with later public events. The ransom note embedded in the recovered encryptor matched Aurora’s published note. Four organizations recorded in the directory subsequently appeared on the group’s leak site with matching organizational and technical details.
CloudSEK’s conclusion is direct: “We assess with high confidence that the operator is a Russian-speaking Aurora affiliate operating directly.” The source distinguishes that role from an access broker because the recovered activity continued through credential theft, domain compromise, data staging, locker delivery, negotiation, and payment.
The evidence also sets a limit. Exploit code for at least 12 vulnerabilities was staged in the directory. Storage alone does not establish execution. CloudSEK identified a custom noPac chain, live pursuit of certificate-template weaknesses, and EternalBlue used to create an account on one target. Those observations cover three specific paths. The available evidence cannot show that every exploit ran everywhere.
One playbook reached domain control
The repeated sequence began with NetExec-driven LDAP and SMB discovery. The operator collected password policy data, ran AS-REP roasting and Kerberoasting, and kept the same output naming pattern across engagements. From there, the privilege path changed with the target.
One path used a custom machine-account rename, ticket-granting ticket, and S4U2self chain associated with noPac. Another pursued Active Directory Certificate Services weaknesses in ESC1, ESC6, and ESC8 configurations. A third coerced NTLM authentication with PetitPotam, PrinterBug, or DFSCoerce and relayed it toward domain control. CloudSEK observed certificate-template configurations capable of minting a domain-administrator certificate being pursued live.
After access, the operator used evil-winrm, chisel, and proxychains for movement and BloodHound for mapping. PowerShell-driven 7-Zip commands staged data in 50GB chunks. Browser credential theft covered seven browsers, while a private ESXi-finder module located virtualization hosts.
Figure details
The source-backed sequence begins with NetExec LDAP and SMB discovery, followed by Kerberos attacks, ADCS abuse, or NTLM relay. Those paths lead to domain-level or interactive access. The operator then stages data in 50GB archives, delivers Zig-based Windows or Linux and ESXi lockers through Cloudflare R2 and scp, and moves to encryption and extortion. CloudSEK documented Cursor use for planning; the source does not establish that the AI assistant autonomously compromised any organization.
CloudSEK found sap.exe for Windows and encrypt.out for Linux and ESXi, both static binaries built from one Zig codebase. The recovered locker files were pulled from a public Cloudflare R2 bucket and pushed to staging hosts with scp. Their presence and delivery records are distinct from proof of execution on every target.
The Windows code deletes volume shadow copies, resizes shadow storage, disables System Restore, and checks for Hyper-V. The ESXi mode enumerates and stops running virtual machines before encrypting VM-related files. It then writes its ransom message into an SSH login banner instead of dropping the usual note beside encrypted data.
Cursor accelerated attack planning
Cursor appears in the operator’s history during the final weeks. Recovered Russian-language chats show sustained back-and-forth planning, including a complete ADCS exploitation plan for a victim environment. The directory also contained Russian documentation for custom NetExec modules and notes written by the operator.
That record supports AI-assisted planning. It does not show Cursor independently choosing targets, gaining access, or running the intrusions. The operator still selected exploitation paths, handled credentials, moved through networks, staged data, and deployed Aurora tooling.
The distinction matters because the defensive opportunity remains in familiar enterprise controls. ESC1, ESC6, and ESC8 certificate configurations, Kerberos ticket lifetimes outside domain policy, coerced NTLM authentication, SMBv1 exposure, unrestricted WinRM, bulk browser-profile access, and 50GB archive staging are observable states or actions. The AI chat log explains how the operator prepared. Familiar enterprise telemetry still records the attack.
The financial evidence also reaches beyond an AI-use anecdote. A key recovered from the encryptor exposed a completed negotiation. TRM Labs traced that payment into a wider network with two confirmed victim payments and two additional payments rated consistent with separate victims. Split ratios varied rather than following one fixed affiliate share, and several flows reconverged through shared consolidation points.
Hunt the pre-encryption sequence
Start with the durable identity and infrastructure signals. Audit every ADCS template for ESC1, ESC6, and ESC8 conditions. Remove ENROLLEE_SUPPLIES_SUBJECT where it is unnecessary, require certificate-authority manager approval where appropriate, and collect certificate request and issuance events. Enable SMB signing and Extended Protection for Authentication, disable LLMNR, NBT-NS, and SMBv1, and restrict WinRM to designated administrative hosts.
Search retained telemetry for these file and network values. The addresses are defanged search strings:
| Type | Value |
|---|---|
| Windows locker SHA-256 | eb0aab1e892d7e09e2c7bcf1d21fd83c1743ed9196b3efac6c78482fb0d99207 |
| Linux/ESXi locker SHA-256 | a4af136d159a8eb96b54924fa80355ca52874913301300f55af7d67ae97edcfe |
| Windows locker | sap.exe |
| Linux/ESXi locker | encrypt.out |
| Ransom note | !!!README!!!DO_NOT_DELETE.txt |
| Aurora negotiation site | ijexszhscln27nl263lmcd7tx3jttkhm4wjhd4e3y6r4csdbfyeprvid[.]onion |
| Operator VPS | 172[.]86[.]113[.]245 |
| Operator VPS | 172[.]86[.]90[.]75 |
| Operator VPS | 144[.]172[.]116[.]150 |
| Operator SOCKS relay | 104[.]194[.]134[.]167 |
| Rented SOCKS pivot | 89[.]106[.]83[.]49 |
| Rented SOCKS pivot | 23[.]234[.]108[.]48 |
| C2 egress check | 167[.]88[.]167[.]37:50167 |
| Rented SOCKS pivot | 45[.]61[.]148[.]166:21056 |
For ESXi, correlate changes to /etc/ssh/sshd_config, creation or access of sshd-banner, and an init.d SSH restart in one sequence. Also hunt for PowerShell-driven 7-Zip archiving at 50GB scale, unusual access to browser profile stores, scp delivery to virtualization hosts, and certificate issuance that grants stronger identity than the requesting account should hold.
A useful verification test is to enumerate every enabled certificate template, compare enrollment permissions and subject-supply flags with an approved baseline, then review issuance events for requesters whose resulting certificate maps to a more privileged identity. The expected result is no unapproved subject-supply path, no web-enrollment relay exposure without Extended Protection, and no issued certificate that crosses the approved privilege boundary. Run the same test again after remediation so the measured configuration, rather than the intended policy, proves the change.
The open directory made this operator unusually visible, but defenders should assume the next directory stays private. Detection has to bind reconnaissance, identity abuse, staging, and locker preparation into one case before encryption supplies the obvious alert. A clean hash search alone cannot answer whether the operator already owns the domain.