Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Case study

BrzCrypt encrypts an e-commerce agency's ERP database and NAS share

A SQL Server instance shared by two ERP account sets, together with a mapped NAS share, was encrypted by BrzCrypt and order processing stopped. NAS snapshot rollback plus page-level extraction restored the core data, and the exposed 3389 port was closed.

Industry
Retail and E-commerce Ransomware Response
Family
BrzCrypt
Scenario
SQL Server Encrypted
Handled
2026-08

This case study is composed from typical scenarios to illustrate our approach and the recovery paths involved. It does not describe a specific customer incident; real cases involving customer data are published only with authorization.

  • 约 97%

    Core order and inventory data recovered

  • 约 36 小时

    Order-to-dispatch chain restored

  • 4 个工作日

    Full handover and sign-off

  • 0

    Ransom paid

Incident background

The client is an e-commerce operations agency running online storefronts on behalf of several brands. Two ERP account sets — a domestic inventory package and a Kingdee installation — handle orders, stock and settlement, sharing one SQL Server instance on a single Windows Server. Product images, marketplace statements, contracts and the nightly database export all sat on a shared NAS, mounted on that server and on staff workstations under a fixed drive letter with credentials saved permanently.

To let night-shift and outsourced staff process orders remotely, port 3389 was published straight to the internet, the administrator password had not changed in years, and the same local password was reused on two other business hosts. Endpoint protection had been installed but was switched off after a performance complaint and never re-enabled.

Early on a weekday morning in August, operations reported that the ERP client could not open its account set. IT found mdf and ldf files in the data directory, plus backups, images and reconciliation spreadsheets on the mapped drive, carrying a new extension containing a random ID and an unfamiliar email address, information.html files in several directories and a ransom wallpaper. Before calling us they had rebooted the server once and tested a downloaded "decryptor" against a file on the original disk.

What we did

Containment went out on the first call: server and NAS off the network but powered on, writes stopped, no reboots, no tools on the original disks.

  • Evidence and imaging. Read-only images of the system and data volumes, with the NAS snapshot schedule locked so snapshots could not roll off. Security, Terminal Services and SQL Server logs were preserved; later work ran on copies.
  • Attribution and recoverability. The .flex extension, a random ID and cock.li address in filenames, the information.html note and DATACORE tail confirmed BrzCrypt. No free decryptor exists for this family (the predecessor Wmansvcs is decryptable), so that route was ruled out. Its behaviour on large files is undisclosed, so we measured: encryption sat in the header and a few fixed regions, leaving 8KB pages intact.
  • Recovery. The mapped drive's nightly backup was encrypted; the NAS snapshots, under a separate account, were not, and supplied the full backup and shared directories for restore on a clean instance. Page-level extraction from the day's mdf filled orders, stock movements and payments up to the outage.
  • Hardening in parallel. The public 3389 mapping was removed and administrative access moved behind a VPN with multi-factor authentication; the reused local administrator password was retired and domain, database, NAS and browser credentials rotated. Endpoint protection returned to real-time mode.
  • Deliverables. Incident report with an intrusion timeline, an IOC list, a per-account-set statement of recovered scope and gaps, plus remediation sign-off.

Recovery result

Both account sets came back up on a new instance, with order, inventory and payment data recovered at roughly 97%. The order-to-dispatch chain was running again in about 36 hours, and all account sets and shared directories were signed off within four business days. What could not be recovered was limited to in-progress picking states, report caches and campaign configurations from that day; operations re-entered those from marketplace back ends and waybills, and a stocktake reconciled inventory with the books.

Forensics showed the attacker brute-forced the administrator password over the exposed 3389 port, endpoint protection having already been switched off. Credential-theft tooling then harvested local and network passwords in bulk, remote desktop carried the operator to the two hosts sharing the same password, and the encryptor was deployed by hand. The NAS share, mounted as a drive letter, was encrypted along with its host.

No bulk exfiltration appeared in logs or traffic records and this family runs no leak site, but passwords had been harvested wholesale, so every credential reaching member and order data was treated as exposed and rotated. We recommended an access audit of systems holding consumer personal information and an assessment of notification duties to brands and marketplaces under personal information protection rules. No ransom was paid and no contact was made with the addresses in the note.

This is an illustrative case compiled from typical scenarios and anonymized; it does not refer to any specific client.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.