A new ransomware operation called Prinz Eugen, detailed this week by BleepingComputer on the back of a thorough deep dive from Malwarebytes' Threatdown team, is worth a closer look than most strain-of-the-week stories. Not because it is loud — it is the opposite of loud — but because of one design decision that quietly undoes an assumption a lot of incident response is built on, and because the operator behind it is more interesting than the malware. I have written this in two parts: a board-level read first, for directors who need the risk and the decision without the internals, and then a full technical teardown for the people who have to defend against it.
Board-level analysis
Strip out the cryptography and the malware mechanics and here is what a board needs to hold.
It takes your most valuable data first, on purpose. Most ransomware encrypts files in whatever order it finds them — alphabetically, or by walking folders top to bottom. That means if your team catches it early and pulls the plug, the files you lose are often old and unimportant. Prinz Eugen does the reverse: it sorts your files by how recently they were changed and encrypts the newest ones first. The practical effect is that the first data destroyed is the live work — this week's contracts, the current model, the open cases — the things the business actually runs on, and the things least likely to be in last night's backup. Catching it quickly no longer means you got away lightly. The damage is front-loaded onto exactly what matters most.
This is one person, and a UK firm is already a victim. This is not a sprawling criminal franchise. The evidence points to a single operator who, until recently, made a living stealing and selling company databases and has now graduated to writing his own ransomware. He is opportunistic about targets: the public leak site already lists a UK business, Spratley's of Mortimer, alongside victims in France and South Africa. The flagship case — South Africa's Standard Bank — involved around 1.2 terabytes of data and a three-week dwell time before anyone noticed. This is a competent, deliberate, hands-on adversary, not an automated nuisance.
You may not get a ransom note. This strain deliberately leaves no note on screen and changes no wallpaper. Extortion happens out of band — a direct email, a phone call, a dark-web portal — and the pressure is applied by leaking your stolen data in escalating daily instalments. That matters for two reasons. First, your automated detection cannot rely on spotting a ransom note, because there isn't one; the incident may first look like mysterious data corruption. Second, the demand may arrive in someone's inbox rather than on a screen, so your people need to know that an out-of-the-blue extortion email is a security incident to be escalated, not a phishing curiosity to be deleted.
It walks in through remote access, not a clever exploit. The attacker gets in using stolen remote-desktop credentials and then operates by hand, using legitimate remote-management software that looks like normal IT administration. There is no exotic zero-day to patch your way out of. The defences that matter are the dull, durable ones: no remote desktop exposed to the internet, multi-factor authentication on every remote path, tight control of who can install remote-management tools, and alerts when a new administrator account appears.
The single question I would put to management: if our most recently modified files were encrypted in the next hour, how much working data would we lose between now and our last good, offline backup — and have we ever actually restored from it? If that number is uncomfortable, this strain is built to exploit precisely that gap.
Technical analysis
Who is actually behind it
The most useful thing the Threatdown research adds is attribution, and it reframes the whole story. Prinz Eugen is not a ransomware-as-a-service brand with affiliates; it is the latest tool of a single actor who posts as ROOTBOY (and earlier as avtokz on the XSS forum), linked across accounts by a shared TOX identifier. The attribution is unusually clean because the actor is consistent to the point of carelessness: the encrypted-file extension is .prinzeugen, the persistence account password is germania, the Go package that performs the encryption is named scorched-earth-ausfc, and the command-and-control domains contain festung — the German for fortress. The malware's namesake is a German WWII heavy cruiser. A whole campaign threaded through with the same national theme.
That theme is also the attribution. The persistence account ROOTBOY created in the investigated intrusion was named germania, and "GERMANIA" is the very extortion alias the same actor used months earlier when trying to extort a US firm called 700Credit before selling its data — roughly 8.4 million records including Social Security numbers — on a crime forum for around $2,500. A string in the binary therefore matches an alias used on a forum long before Prinz Eugen existed. The same operator's recent CV, before he started encrypting anything, is a straightforward data-broker's: a Vantage Finance database advertised in July 2025, a US and Canadian driving-school software provider sold in September 2025, the 700Credit breach in November 2025. Prinz Eugen is what happens when a data thief decides encryption is a second revenue stream on top of the data he was already stealing. On current evidence this is most likely one person, with — at most — a separate developer for the encryptor.
Access, execution and operating model
The intrusion Threatdown investigated began, in their assessment, with compromised RDP credentials. Once inside, the operator downloaded the encryptor — a Go binary named servertool.exe — using Chrome and dropped it into the user's Music folder, a deliberately unremarkable location. The binary is a command-line tool: it takes one or more directories to encrypt as arguments, with an optional --delete flag to remove originals after encryption. In the studied incident it was run, by hand, against an escalating set of targets that tells you everything about intent:
servertool --delete C:\Users\<redacted>\Downloads
servertool --delete C:\Users\<redacted>\OneDrive
servertool --delete C:\Users\<redacted>
servertool --delete C:\
servertool --delete G:\My Drive
servertool --delete G:\Shared DriveNote the last two lines. The operator deliberately pointed the encryptor at mounted Google Drive paths — My Drive and Shared Drive — so that cloud-synced storage was encrypted along with local disk. The convenience of a synced drive becomes a route for the damage to propagate into shared, "backed-up" cloud locations.
For post-exploitation the actor leaned on the legitimate RemotePC RMM tool to launch PowerShell stagers pulling further payloads (suspected RATs for infostealing and exfiltration) from a command-and-control host at 212.80.7.74, a server in Frankfurt. Persistence was a manually created backdoor administrator account — net user admin germania /add — the same living-off-the-land, hands-on-keyboard pattern that is now the norm: signed remote-access tooling, a plausible-looking admin account, native utilities. There is very little conventional malware to catch, which is why it survives environments that depend on signatures.
The targeting innovation: recency-first encryption
The Go encryptor enumerates each target directory recursively, with no depth limit. The code supports an exclusion list, but the analysed sample defined none, so it encrypts every file that is not already a .prinzeugen output or a .<originalname>.prinzeugen.tmp working file. Encryption is parallelised across multiple worker goroutines, one per CPU, for speed. And rather than processing in directory or alphabetical order, it sorts candidates by last-modified time and encrypts the most recently modified files first, using alphabetical order only to break ties on identical timestamps.
Consider what that does to the defender's timeline. The implicit promise of fast incident response is partial mitigation: detect encryption in progress, kill the process, save whatever it had not yet reached. Against ordinary alphabetical or directory-walk encryption, an early kill often spares the important material, because the malware may still be grinding through C:\Archive\2019\ when you stop it. Prinz Eugen inverts that. By the time you notice and respond, the files it has already taken are — by construction — your most recently touched, most actively used, most business-critical data. Speed of response still matters, but it no longer protects the right things. The blast radius is deliberately ordered worst-first. The mid-market defenders at Bellator make the same point for smaller practices: a tax preparer with current returns open, or a clinic with same-day records, suffers a practice-stopping loss even from a partial, interrupted run.
Per file, the encryptor works in three stages: it encrypts to a temporary copy (.document.docx.prinzeugen.tmp) via an EncryptFileToKey routine, renames that to the final document.docx.prinzeugen, and — where --delete is set — calls VerifyEncryptedWithKey to confirm the encrypted copy is decryptable before removing the original. Encrypted files carry a custom header with the magic bytes CHV1.
Cryptographic construction — and an important nuance
The cryptography is competently chosen. The encryptor uses ChaCha20-Poly1305 — an authenticated encryption (AEAD) construction — with a 32-byte (256-bit) master key, a fresh random initialisation vector for every file, key derivation through a chain of Argon2id, SHA-256 and HKDF-SHA256, processing in 1 MB chunks with SHA-256 integrity hashing. ChaCha20-Poly1305 is a sound modern AEAD with no known practical break; a random IV per file closes the catastrophic stream-cipher trap of nonce reuse; and the Argon2id-led KDF chain is textbook key management, not improvisation. There is no padding oracle, no weak custom cipher, no reused-nonce flaw to undo it from the maths.
But there is a nuance worth getting right, because it changes the recovery story. Threatdown describes the binary zeroing a hardcoded encryption key before exit. A symmetric key embedded in the sample is a very different proposition from the RSA-wrapped, per-victim key escrow that the mature RaaS lockers use, where the maths genuinely denies you any path back without the operator's private key. If the key lives in the binary and in process memory, then a responder who captures the running process or the binary before it self-deletes and scrubs may have a route to recovery. That is almost certainly why the operator spends effort destroying it. The honest framing for a defender is therefore not a flat "no decryptor is coming" — it is that recovery hinges on two things: the quality of your backups, and whether your incident responders can acquire memory and disk artefacts fast enough to win the race against the malware's own clean-up. Treat full-memory acquisition during a live encryption event as potentially decisive, not merely good hygiene.
Operational professionalism: decrypt-before-delete
One detail betrays a mature, revenue-protecting mindset. Before destroying an original under --delete, the malware verifies that the encrypted copy can actually be decrypted. This is not courtesy; it is business protection. A locker that corrupts files it claims it can restore destroys the only thing an extortion operation is selling — the credible promise that paying gets your data back. Building a decrypt-verification step into the destructive path is the behaviour of an operator who intends to be paid and understands that reputation, even among criminals, is a revenue input.
Anti-forensics
After encryption the binary attempts to scrub its tracks: it overwrites the encryption key in memory with zeroes, forces Go's garbage collector to run so the key does not linger, and then self-deletes from disk. The self-delete is a familiar trick — cmd.exe /C ping 127.0.0.1 -n 2 > nul & del /F /Q ...\Music\servertool.exe — using a short ping as a delay so the parent process exits before the file is removed.
It is worth being precise about how effective this really is, because it is not magic, and — per the point above — it is the linchpin of whether files are recoverable. Go's runtime does not guarantee that every copy of a secret is promptly and irrecoverably scrubbed; intermediate buffers and runtime structures can leave residue, and the timing of any memory capture relative to the scrub is decisive. Self-deletion likewise leaves journal and master-file-table artefacts a competent responder can recover. So the anti-forensics raises the bar and will defeat casual triage, without making the operation invisible — which is exactly why early acquisition matters so much against this particular family.
No ransom note: detection by behaviour, and the leak as the lever
The encryptor has no functionality to drop a note or change the wallpaper. Threatdown rightly frames silence as a tell of more organised actors: moving all ransom communication out of band — direct email, phone, dark-web portal — strips the forensic artefacts automated tooling keys on and complicates detection of the extortion phase. The pressure is applied instead through the leak site and staged, escalating daily leaks: in the Standard Bank case the actor ramped published rows from 5,000 to 25,000 to 50,000 to 100,000 a day after the bank refused to pay. The operator even stood up a Standard Bank typosquat domain, stndrdbnk.cc, serving an /unlocked page consistent with a victim payment or negotiation portal.
For defenders this forces detection to live on behaviour, not artefacts. You cannot wait for RESTORE_FILES.txt, because it never appears. Watch for a process recursively reading and rewriting files across a tree at speed; a bloom of .prinzeugen extensions; mass file-modification with rising write entropy; an unfamiliar RMM agent installing; a new local administrator account; anomalous RDP logons. In MITRE ATT&CK terms: valid accounts (T1078), external remote services and RDP (T1133 / T1021.001), remote-access software (T1219), local account creation (T1136.001), indicator removal and file deletion (T1070 / T1070.004), data encrypted for impact (T1486), and exfiltration (T1041 / T1567) for the double-extortion leg.
The flagship case: Standard Bank, and a UK name on the list
The campaign's marquee victim is South Africa's Standard Bank Group, together with Liberty. Threatdown's reconstruction has the intrusion starting on 27 February 2026 with roughly a three-week dwell time, around 1.2 terabytes and approximately 154 million SQL rows exfiltrated, a one-Bitcoin demand that the bank refused, and then the staged daily leaks described above. The lateral movement reads as a tour of the modern enterprise stack — SharePoint, OneDrive, Power Apps, AppDynamics, Jira, Confluence, Citrix, Remedy, and Microsoft and Oracle SQL databases — all reached through the same legitimate-tooling, hands-on-keyboard tradecraft.
Closer to home, ransomware.live's tracking of the group lists a UK victim, Spratley's of Mortimer (spratleys.co.uk), posted on 9 June with an estimated attack date of 4 June and "hundreds of GBs of data encrypted across company file shares," alongside Transitions Pro Centre Val de Loire in France. The victim set is small, recent and opportunistic across sectors and countries — which is exactly what you would expect from one capable operator picking targets of convenience rather than an affiliate machine running at volume.
What actually defends against this
Because the intrusion is identity-led and the payload is conventionally unremarkable, the effective controls are the unglamorous ones I keep arguing for.
Eliminate internet-exposed RDP; where remote access is necessary, put it behind a VPN with enforced multi-factor authentication, lockout and logon monitoring, since stolen RDP credentials are the front door here. Adopt default-deny application control so an unsanctioned servertool.exe or an unauthorised RMM agent like RemotePC simply cannot execute — allow-listing is the single control that most directly neutralises both the payload and the living-off-the-land tooling. Inventory your sanctioned RMM estate and alert on any new remote-management software. Monitor for new local administrator accounts and the net user ... /add pattern. Run behavioural EDR able to catch hands-on-keyboard activity rather than relying on signatures, and consider canary files. Recognise that mounted cloud-sync drives are in scope, so a synced Google Drive or OneDrive is not a backup — it is another thing that gets encrypted.
Then the recovery posture, which this strain attacks directly. Given recency-first encryption, your exposure is the working data created since your last good copy, so shrink that window: frequent, immutable or offline backups of active data, on a segment the production network cannot reach, with restores you have actually tested. Treat exfiltration as a given — this is double extortion — so data-centric controls and egress monitoring matter as much as the ability to rebuild. And rehearse fast forensic acquisition, because against this family the responder who captures memory before the binary scrubs its key may change the outcome entirely.
Prinz Eugen is not the most aggressive thing on the landscape this month, and that is rather the point. It is quiet, competent, the work of one persistent operator who decided his stolen databases were worth encrypting on the way out of the door. The strains that take your newest work first, say nothing, and clean up after themselves are the ones that reward the dull disciplines — identity hygiene, application control, tested immutable backups, and an IR team that moves fast — over any tool you can buy in a panic afterwards.
Indicators of compromise
For defenders who want to hunt, the headline indicators from the Threatdown report:
Payload: servertool.exe
SHA-256: 686213cc11d36af764de824801bced9366dfca3823fe0d51b752f74149bcf1f4
Encrypted ext: .prinzeugen
Go package: scorched-earth-ausfc
File-header magic: CHV1
Persistence: net user admin germania /add
Self-delete: cmd.exe /C ping 127.0.0.1 -n 2 > nul & del /F /Q ...\Music\servertool.exe
RMM abuse: RemotePC (IDrive) used for PowerShell staging
C2 / payload host: 212.80.7.74 (AS215439, Play2go International, Frankfurt, DE)
Domains: stndrdbnk.cc · g-captchafestung.sbs · festung-e.duckdns.org
PowerShell stagers: hxxps://212.80.7.74/serverscan.ps1 · /stager/mini · /stager/ps1
Contact: prinzeugen@mail2tor.co · standardbankcc@cock.li
BTC: bc1q2ztpcvqdaptej6uu2ywt9mrlatx6envu34rf0v
Actor selectors: ROOTBOY · avtokz · GERMANIA