Port 8888 Was Open: Inside an Aurora Affiliate's Own Directory of Stolen Kerberos Tickets

On 27 August, CloudSEK's TRIAD team published something most threat intel reports never get to show you: the inside of an active ransomware operator's working directory.

Not a sandbox detonation. Not reconstructed telemetry. The operator's own Linux home directory, served as a plain file listing on port 8888, no authentication, indexed for anyone who wandered past. Three months of work sat in it. Kerberos tickets. SAM and LSA dumps. Group Policy exports. BloodHound collections. The full shell history. The Aurora encryptor binary itself, with the ransom note and onion address baked in, matching Aurora's published note character for character.

The coverage that followed fixated on one folder in that listing: the operator's chat logs with Cursor, the agentic coding assistant, conducted in Russian. "Ransomware hacker uses AI" is a good headline. It is also the least useful thing in the report.

I want to talk about the other folders.

What the directory actually held

CloudSEK's timestamped record spans April to July 2026. In that window the affiliate compromised more than twenty organisations across nine countries, with the United States taking the largest share. Domain-level or interactive access was reached at seventeen of them. Four ever appeared on Aurora's leak site.

Sit with that ratio. Roughly one in five confirmed victims became public. The other sixteen organisations were told by CloudSEK, by their national CERT, or by nobody at all until somebody knocked. If you build your threat model from leak site counts, and plenty of boards do, you are working from a sample that understates reality by a factor of four. Ransomware.Live lists 33 named Aurora victims across the US, Germany, the Netherlands, Canada and the UK. One affiliate, on one exposed box, accounts for more intrusions than the group's entire public list.

Per-victim, the haul reads like a directory services audit gone wrong. A manufacturer gave up multi-site AD plus the Azure AD Connect sync account hash, and had its certificate escalation path mapped. A food and agriculture distributor lost full domain compromise including krbtgt extraction. A professional services firm handed over validated SSL-VPN credentials and admin sessions. A consumer goods brand lost the private key to a wildcard TLS certificate. An IT and backup infrastructure provider lost backup system credentials, which is the one that should make you put your coffee down.

The same commands, in the same order, every time

Here is the detail I keep rereading. CloudSEK notes that the enumeration phase ran against every engagement in an identical sequence, with identical output file naming, stored per organisation under a consistent scheme.

NetExec for LDAP and SMB discovery. Password policy retrieval. ASREPRoasting. Kerberoasting. Then escalation through one of three paths: a custom-scripted noPac chain doing machine account rename into TGT into S4U2self, rather than the stock public proof of concept; AD Certificate Services abuse through ESC1, ESC6 and ESC8; or NTLM relay coerced with PetitPotam, PrinterBug and DFSCoerce, including a DCSync-equivalent variant. One target got EternalBlue, MS17-010, for direct account creation, in 2026.

That is not an adaptive adversary reading your environment and improvising. That is a script with a victim name as its only variable. The operator had a private GitLab repo holding custom NetExec modules, documented in Russian, including a browser credential stealer covering seven browsers and an ESXi discovery module. Everything else was public tooling: certipy, ntlmrelayx, PKINITtools, Kerbrute, hashcat, evil-winrm, chisel, proxychains, BloodHound. Most of the staged exploit code was unmodified public PoC, still carrying the original authors' credit lines.

I find that reassuring and alarming in equal measure. Reassuring because a repeatable chain is a detectable chain. Alarming because the barrier to running it has dropped to roughly zero, which brings us back to the AI.

Where the assistant actually sat in the kill chain

The recovered Cursor sessions show planning, not evasion. The Hacker News, reading the same logs, counted ten targets where the assistant was in the loop. CloudSEK describes sustained back and forth during live victim engagements, including an entire AD CS exploitation plan written out in Russian.

Nobody has published evidence that the model wrote novel malware, produced polymorphic payloads, or generated anything designed to slip past EDR. The encryptor is hand-built in Zig, which is genuinely unusual, but Zig is a language choice, not an AI artefact. What the assistant did was close the knowledge gap between "I have domain user" and "I have domain admin" for an operator who might not otherwise have known which of ESC1, ESC6 and ESC8 applied to a given template misconfiguration.

That is the actual shift, and it is not a detection problem. It is a population problem. The number of people who can execute a competent ADCS escalation just went up, and their tradecraft converged on the same handful of well-documented paths, because that is what the models were trained on. We wrote about automation flattening the skill curve when the Zerofot scanner turned credential harvesting into an end-to-end pipeline. Aurora is the hands-on-keyboard version of the same curve.

One human detail survived all of it. The ESC6 attempt failed on one engagement because of a DNS problem on the operator's own side. They fumbled, retried, moved on. You would never have known, because a failed escalation attempt against a real certificate template produces nothing anyone alerts on.

Every step here is a valid credential doing a legal thing

Walk the chain from your SOC's perspective.

LDAP enumeration is a read-only query from an authenticated domain user. Kerberoasting is a service ticket request the KDC is designed to answer. ASREPRoasting is a legitimate AS-REP for an account configured without preauthentication, and somebody in your directory configured it that way on purpose in 2019. BloodHound collection is a burst of normal protocol traffic. The noPac chain uses machine account privileges that ordinary domain users hold by default. NTLM relay involves your own servers authenticating to your own servers.

None of it is malware. Most of it is not even anomalous in isolation. Palo Alto's Unit 42, in its 2026 Global Incident Response Report built on more than 750 engagements, put identity-based techniques behind 65% of initial access against 22% for vulnerabilities, and found the fastest quarter of intrusions reaching exfiltration in 72 minutes, down from 285 minutes the year before. Meanwhile this operator's gap between intrusion and leak site listing was never more than a couple of months and in one case was barely two weeks, and the exfil itself ran as PowerShell-driven 7-Zip jobs splitting data into 50GB chunks, with every victim-facing action routed through rented SOCKS pivots on German and US VPS providers so the operator's own infrastructure never touched a victim network.

Behavioural detection can find pieces of this. It usually finds them after the account count crosses a threshold, which is after Kerberoasting already happened. We covered the underlying arithmetic in the 27 seconds breakout time analysis, and the structural blind spot around over-privileged service identities in the service account lateral movement post. Neither problem has improved.

Automation makes decoys stronger, not weaker

This is the part I want to argue rather than just report, because it runs against how most defensive controls age.

A skilled human operator looking at a BloodHound graph might hesitate over an account that seems too convenient. A service account with a juicy SPN, RC4 enabled, a password last set in 2017, sitting three hops from Domain Admin. A careful attacker might poke at it, notice it has never authenticated to anything, and move on.

A script does not hesitate. The Aurora affiliate's enumeration ran the same way against every one of twenty-plus environments, in the same order, writing to the same filenames. An LLM reasoning over graph output is worse still: it optimises for the shortest path it can see, and a well-built decoy is designed to be exactly that. The more automated and model-assisted the tradecraft becomes, the more reliably it walks into objects planted for it. Most controls decay as attackers improve. Deception improves as attackers industrialise.

That is why the answer to this specific playbook is not another rule. It is objects that have no reason to be touched:

A Kerberoastable decoy service account. It has an SPN, it looks weak, no service uses it. A TGS request for that SPN has exactly one explanation. This is the mechanism we detailed in the Kerberoasting and AD mines breakdown, and Aurora ran that exact technique against every victim in the dataset.

An ASREP-roastable decoy. Preauth disabled deliberately, on an account that does nothing. NetExec's sweep does not distinguish.

A decoy certificate template shaped like ESC1, with ENROLLEE_SUPPLIES_SUBJECT set and enrollment monitored. Certipy will find it. Nothing legitimate will.

Planted credentials in browser profile stores on admin workstations, because that custom module covered seven browsers and went looking specifically there.

A decoy ESXi host answering on the ports their discovery module scans for. MineField decoy services exist for this shape of problem: something that looks like infrastructure, has no production role, and generates a signal only when somebody who should not be enumerating starts enumerating.

And a honeytoken backup credential, sitting where the real ones sit. Given that this affiliate validated backup system credentials at one victim and the ESXi encryptor force-kills every running VM in a single command before writing the ransom note into the host's SSH login banner, that decoy buys you the most time of any single object on this list.

The zero false positive claim is easy to be cynical about until you apply it here. There is no legitimate business process that requests a service ticket for an SPN nobody uses. The alert is the event.

Two things worth doing before Monday

Rotate krbtgt twice with a full replication interval between resets if you have any doubt about the last twelve months, and audit your ADCS templates for ENROLLEE_SUPPLIES_SUBJECT. Those are CloudSEK's own recommendations and they are cheap. Then go look at which of your privileged accounts still carry SPNs, because that is the list the next affiliate's script will enumerate in its first ninety seconds.

The economics behind all this stayed stubbornly human, for what it is worth. TRM Labs traced two confirmed victim payments and two more consistent with separate victims through shared laundering infrastructure, with the operator wallet holding 7 BTC at analysis. The affiliate splits varied per victim with no pattern at all: 35/65, 21/79, 46/54, 40/60. Every deal negotiated separately. Whatever the AI was doing, it was not running the business.

If your Active Directory would answer that enumeration sequence honestly today, and almost every directory I have looked at would, the useful next step is to give it something dishonest to say. Book a walkthrough and we will map the decoy objects to the exact chain CloudSEK recovered.