BrzCrypt Ransomware Decryption & Data Recovery

BrzCrypt first appeared in late May 2026 and climbed the domestic charts within weeks. Per 360's monthly reports: "rapidly among the leading families by spread" in June, second place at 17.73% of victim devices reported to 360's anti-ransomware service in July (Weaxor first at 45.45%), and still second at 11.11% in August, again behind only Weaxor. 360's characterisation is consistent across those reports: spreading only inside China, delivered by brute-forcing remote desktop passwords and then deploying by hand.

Its origin matters more than its technical novelty. 360's dedicated analysis attributes BrzCrypt and Wmansvcs to the same crew on the basis of shared attack infrastructure. Wmansvcs, active since June 2025, sat in the top two domestic families until April 2026, when 360 found a flaw in its encryption logic, broke it and began decrypting victims' files. Stripped of leverage, the operators dropped it and shipped BrzCrypt a month later - a forced rewrite, visibly hardened around key handling.

Victimology is server-heavy: in August 2026 servers ran far ahead of desktop PCs among compromised systems, with Windows 10, Windows Server 2012 and Windows Server 2008 the top three victim operating systems. One publicly described Chinese case lost an Oracle database server, a file share and CRM/MES application servers to the .brz variant in a single incident. BrzCrypt has no known leak site - international ransomware trackers do not list the name either - and 360's published analysis records no exfiltration, but the intrusion chain harvests credentials in bulk, so exposure must be assessed on its own merits.

Extension and naming. Early builds appended .brz; from June 2026 360 captured multiple variants switching to .flex. The full pattern adds .(__{ID}__).(__{email}__).brz or .flex after the original filename, the ID corresponding to the naming of the RSA public-key file shipped with the encryptor. A random ID plus a cock.li or tutamail.com address inside a filename is close to conclusive.

Ransom note. An English HTML file, information.html, opens with YOUR FILES ARE ENCRYPTED, prints a per-victim unique ID, offers one file decrypted free and, before payment, up to three more files totalling under 1MB, names hunter505@cock.li as primary contact and supp_brz@tutamail.com as backup, and points to offshore exchanges for Bitcoin. Published indicators add talbotor@cock.li and billyai@cock.li.

Ciphertext marker. Every encrypted file carries RSA-wrapped key material at its tail, terminated by the ASCII string DATACORE. Finding DATACORE at the end of a file in a hex viewer is the cleanest attribution signal and the cheapest way to separate this family from other ChaCha20 lockers.

Other indicators. The wallpaper is replaced with a ransom banner and a registry Run entry provides persistence. The encryptor needs a public-key file ending in _public_key.pem in its own directory; without it, it errors out and exits, and that PEM file is often still sitting in the staging directory during response. System paths survive - windows, programdata, $recycle.bin, windows.old and recovery are on the exclusion list, while business volumes are walked in full.

Bottom line. The extension, information.html and a DATACORE tail together confirm the family - but an extension does not identify the build or its encryption parameters, so the recovery plan still has to come from measurements on your own files.

360's monthly reports and its dedicated analysis describe the same unglamorous path: brute-force the remote desktop password, then deploy by hand. No zero-days, no phishing attachments - just exposed port 3389 and weak credentials. The .flex analysis lays out the sequence:

• Initial access. Password brute force against internet-facing remote desktop, then a normal interactive logon.
• Defence evasion. Process-management and anti-security tooling shuts down or bypasses endpoint protection first.
• Credential theft. Browser password viewers, network credential exporters and Mimikatz-class components harvest stored local and network passwords in bulk.
• Lateral movement. The operators connect from the compromised host to other internal machines through the remote desktop client with the stolen credentials. 360 calls this the defining feature of the campaign and the reason one foothold becomes network-wide encryption.
• Hands-on deployment. Only then is the encryptor dropped, targeting database files, office documents and images.

This maps onto a familiar set of weaknesses: 3389 published straight to the internet, one local administrator password reused across every server, database and backup credentials cached on the servers themselves, endpoint protection installed but disabled or removed - 57.52% of devices in 360's August 2026 reports had no security software at all. Public reporting shows no affiliate programme, no edge-device exploitation and no phishing campaigns.

Key handling. On startup the encryptor looks for an RSA public-key file ending in _public_key.pem in its own directory and exits if it is missing. It then calls OsRng for a 32-byte ChaCha PRNG seed, derives a 32-byte symmetric key, encrypts file content with ChaCha20, wraps that key with RSA into the ciphertext tail and appends the DATACORE terminator. Everything happens offline with no key sent to a C2, so decryption depends entirely on the operators' private key. 360 notes the wrapping uses OAEP padding rather than the PKCS#1 v1.5 common in older families, ruling out several padding-oracle style attacks - deliberate hardening, given the family shipped only after its predecessor was broken.

Scope. A drives parameter selects volumes, defaulting to all. The target extension list holds 199 entries, stored XOR-obfuscated and decoded at runtime, covering databases (dbf, mdf, ldf, sql, sqlite, accdb), backup artefacts (bak, dump, dmp, trn, bacpac), virtual disks and VM configuration (vmdk, vhdx, avhdx, qcow2, vmx, vmcx, vmrs), plus office documents, CAD and design files, archives and source code.

Two points matter for management. Backup files reachable from the same host and account are themselves in scope, so "we have a local backup" counts for very little here; and vhdx, avhdx, vmcx and vmrs are direct targets, so Hyper-V guests go down with their Windows host. No Linux or ESXi encryptor has been reported, and published analysis does not document shadow-copy deletion, service stopping or exfiltration - which is not the same as shadow copies being intact, and must be verified on site. A registry Run key provides persistence and the wallpaper is replaced.

An undisclosed parameter that matters. 360 does not state whether BrzCrypt encrypts large files in full or in blocks, nor the stride. For reference, Wmansvcs encrypted files up to 512KB in full and only the first 512KB of larger ones, while its .peng branch touched three 64KB blocks - head, middle, tail - covering roughly 7.2% of one measured 2.67MB file. Whether BrzCrypt inherits that can only be established by measuring your own files.