What should we do when Guanjiapo or Suda account sets are encrypted by ransomware?

SME inventory and accounting packages almost always keep everything on one Windows PC or server. Knowing where the account sets live tells you what to preserve and where to look for backups:

SaaS editions such as Kingdee Jingdouyun and Chanjet T+Cloud keep account sets in the vendor's cloud, so encryption of a local PC does not normally reach them - but treat the login as potentially compromised.

Why the automatic backups fail. These products write their automatic backups to another folder or partition on the same machine - same disk, same operating-system privileges as the database. Database-focused families such as Mallox and Weaxor stop the SQL Server service, delete volume shadow copies, and then encrypt .mdf, .ldf and .bak files alike. The result is a business that "backed up every day" and has nothing usable on the day it matters.

What is worth hunting for is any copy that has ever left that server: exports made for tax filing, audits or the bookkeeping firm; USB sticks and external drives; cloud-sync folders; data a reseller kept during an upgrade or migration; and retired PCs. Deleted older backups may also survive in unallocated disk space, but they must be carved from a disk image - never by running recovery software on the original disk.

Accounting servers usually do several jobs at once - database, software server component and remote desktop on one box - and to let shops and travelling staff connect, ports get exposed through router port forwarding or a tunnelling service. Public reporting points to three main ways in.

1. Brute force against SQL Server on port 1433. Unit 42 and AhnLab both document Mallox (TargetCompany) running dictionary and brute-force attacks against exposed MS SQL Server instances, then executing commands to deploy its payload once a privileged account falls. Its same-lineage successor Weaxor has been among the highest-volume families in China, and 360's April 2026 landscape report notes that some Weaxor builds brute-force the database login, plant AnyDesk, and then deploy the encryptor by hand.

2. Weak remote desktop (3389) passwords. The same report lists RDP password brute force as the main route for families including Wmansvcs and BeijingCrypt. An accounting server sharing one administrator password that has not changed in years is a steady supply of victims.

3. Vulnerabilities in the accounting software itself.

• Chanjet T+ has been mass-exploited twice. On 30 August 2022 China's national vulnerability sharing platform (CNVD) recorded an arbitrary file upload flaw (CNVD-2022-60632), noting that users had already been hit with ransomware through it; affected were T+ standalone editions 17.0 and earlier running on IIS below 10.0. Antiy attributed the payload to TellYouThePass based on the extension, ransom amount and note. In June 2023, 360 observed TellYouThePass exploiting a T+ command-execution flaw disclosed on 8 June, attacking more than a thousand servers running the product between 9 and 12 June.
• In 2026 the focus moved to a server-side communication component. 360's May 2026 landscape report states that the Windows version of the Sorry family spread that month mainly through a vulnerability in Borland Socket Server (scktsrvr.exe), a component used in SME management software from several leading Chinese vendors, with pharmaceuticals, medical devices and small trading firms most affected. Solar's incident response team published an attack chain in July 2026 using Guanjiapo as the example: connect to port 211 with no credentials, run SQL through the server component, then execute operating-system commands via SQL Server's xp_cmdshell. The team recorded .weax and .sorry extensions in the incidents it handled.

That last path deserves emphasis: a server can be hit even when 1433 was never exposed and SQL Server's login audit shows nothing unusual. The entry point cannot be found by elimination; it has to be evidenced from port-forwarding configuration, Windows logs, and the software's server and database logs - which is what forensics is for.

Ranked by reliability there are roughly four paths; the full reasoning is in can encrypted files be recovered.

• A clean backup from somewhere other than that server. The best outcome. Test-restore it in an isolated environment first, confirm it opens and the dates are right, then decide which copy to use.
• A public decryptor. Works for very few families and builds: Avast's Mallox decryptor only covers files encrypted from 2023 to early 2024, and Weaxor, TellYouThePass and Sorry have no public decryptor at all. Do not burn time here.
• Page-level repair of the database file. SQL Server stores data in 8KB pages, and many families encrypt only the start of large files or encrypt intermittently for speed, so untouched pages still parse into complete rows that can be exported table by table into a new database. Thresholds differ by family, though, and a small account-set database may be encrypted end to end. Whether repair is viable has to be measured with segmented entropy analysis of the .mdf, not guessed from file size - and one extension can hide more than one payload branch, so the sample in hand decides. The full SQL Server method is on SQL Server encrypted by ransomware.
• Re-entry from external records. Anything after the backup point, or genuinely unrepairable, can be rebuilt from e-invoice and invoicing records, bank statements, marketplace and payment-platform orders, customer and supplier statements, and paper documents.

If you run mid-size or large ERP instead - Yonyou U8 or NC, Kingdee K/3, EAS or Cloud Galaxy - the application tier, attachments and interfaces have to be recovered as well; see ERP encrypted by ransomware.

A database that mounts is not the same as books that balance. Page-level repair can lose a few rows, and a backup restore is missing everything after the backup point. Finance and warehouse staff should check together, in this order:

1. Fix the time boundary. Find the last document and last voucher in the recovered account set; everything after that goes on the re-entry list.
2. Stock. Spot-count high-value and fast-moving items against quantity and value; negative stock or odd cost prices usually point to missing documents.
3. Receivables and payables. Reconcile balances customer by customer and supplier by supplier against their statements, paying special attention to payments in the days before the incident.
4. Cash. Match cash and bank account balances to bank statements, and online receipts to payment-platform statements.
5. Document and voucher continuity. Look for gaps or duplicates in sales, purchase, goods-movement and voucher numbers.
6. Period status. Confirm month-end, year-end and tax periods match reality, so nothing is re-entered into the wrong period.

Re-enter master data and opening balances first, then business documents in date order; retail editions need stored-value and loyalty point balances checked separately. Keep a record of every gap and how it was handled, for later audit and tax explanations.

• Expose nothing directly. No public port forwards for 211, 1433, 3389 or the T+ web port; shops and travelling staff connect over a VPN with source addresses restricted.
• Keep the software and its components current. Check with the vendor or an authorised reseller whether the accounting software, its server components and web front end have security updates - especially for products like Chanjet T+ with a record of in-the-wild exploitation.
• Database and system passwords. Replace the sa, Windows administrator and software admin passwords with strong, distinct ones, keep xp_cmdshell disabled where it is not needed, and stop using sa for day-to-day connections.
• At least one offline backup. Keep the built-in automatic backup, but also copy it regularly to a drive that is disconnected afterwards or to off-site storage - and actually restore an account set from it now and then.
• Dedicate the machine. The accounting server is not for browsing, receiving files, unvetted software or unapproved remote-control tools.
• Watch for pre-encryption signals. A stopped SQL Server service, deleted shadow copies, an unfamiliar administrator account or newly installed remote-access software all warrant an immediate response.

If this is not the first time, read why ransomware keeps coming back first; structured remediation is what security hardening covers.