Scenario solution
SQL Server Database Encrypted by Ransomware
- Microsoft SQL Server
- 用友 U8
- 用友 NC
- 金蝶 K/3
- 金蝶 KIS
- 管家婆
- 速达
- Windows Server
When SQL Server .mdf / .ldf files are encrypted, the ERP and inventory systems built on them — Yonyou U8, Kingdee K/3, Guanjiapo, Suda — stop completely. This page covers evidence handling, how we judge whether page-level repair is viable, and the conditions for backup-plus-log restore.
Typical symptoms
- Files in the data directory carry appended extensions: U8ERP.mdf.mallox, AIS.mdf.weax, .locked, .[8 random chars]
- The SQL Server service will not start, or databases show as Recovery Pending or Suspect
- SQL Server error log shows 823 / 824 / 825 page errors, or reports that the file header is not a valid database header
- Yonyou and Kingdee clients report database connection or account-set login failures, with an empty account-set list
- MSSQL services are stopped or removed, SQL Server Agent jobs have disappeared, and backup jobs fail
- .bak and .trn files in the backup directory are encrypted or deleted, and shadow copies have been cleared
Business risk & common mistakes
SQL Server is the most common back end for ERP and inventory systems in China. When it is encrypted, the loss is not limited to database files — account sets, attachments, report templates and document histories usually live in several locations, so recovery scope must be defined in business terms rather than file terms.
The attack paths against SQL Server are distinctive. Public reporting shows the Mallox (also known as TargetCompany) lineage has long used internet-exposed MS-SQL instances as its primary entry point, brute-forcing or dictionary-attacking sa and other privileged accounts, then using the command line and PowerShell to fetch the payload. Weaxor, the rebrand that emerged from late 2024, kept the same target profile and ranked among the top three families by case volume in 360's published 2025 China landscape report. In parallel, other families log in directly over weak-password RDP, or land through file-upload and command-execution flaws in the front-end ERP. What these paths share is that the attacker arrives with administrative rights, and therefore stops SQL services, deletes shadow copies and clears logs before encrypting.
Frequent mistakes, worst first:
- Repeatedly starting the SQL Server service, or running DBCC repair against a suspect database. The engine keeps writing and attempting rollback, destroying extractable pages. Any repair belongs on a copy.
- Detaching and re-attaching, or forcing the database up in EMERGENCY mode. Performed on an encrypted file, this usually makes the state worse.
- Restoring an encrypted .bak into production, or reinstalling the ERP into the original directory over residual files.
- Running recovery software on the original partition and writing results back to the same disk.
- Running the attacker's decryptor. Case after case shows incomplete decryption plus a backdoor and persistence left behind.
We do not recommend paying, and we do not negotiate on your behalf.
Our response plan
Isolate, preserve, and inventory account sets
Isolate the database and ERP application servers from the network without powering off or rebooting, and image the data and backup volumes read-only. In parallel, work with the business owners to inventory which account sets must be recovered: the .mdf / .ndf / .ldf files behind each one, where attachments live, and which external interfaces feed data in. Evidence includes ransom notes, samples, SQL Server error logs, Windows security logs (notably 4625 failed logons and 4624 type-10 remote logons) and firewall forwarding rules.
Identify the family and encryption coverage
Match the family by extension, ransom note filename and contact domains, paying particular attention to whether it belongs to the Mallox / Weaxor lineage that targets MS-SQL specifically, and whether any public decryptor exists. Then run segmented entropy analysis on the .mdf to quantify the encrypted regions: header-only (common on large files), intermittent, or full-file. Check .ldf integrity at the same time — transaction log availability changes the plan outright.
Assess recoverability: repair, restore, or rebuild
Compare the three paths side by side. File repair: where only the .mdf header was overwritten, the remaining 8KB pages can be parsed, system tables reconstructed and user tables exported — well suited to large account sets. Backup plus log restore: where an unencrypted full backup plus differentials exist and the tail log is readable, recovery close to the point of failure is possible. Rebuild: where account-set data is genuinely unusable, key opening balances are reconstructed from paper documents, external interfaces and downstream systems. The assessment must state the expected outcome per account set.
Execute recovery and reconcile with the business
Build a clean SQL Server instance in the isolated environment and work only on the image. On the repair path, load extracted tables into a new database and attach it to an ERP test environment; on the backup path, restore full, then differential, then logs. Sign-off requires finance and operations staff: verify that the general ledger balances against subledgers, check closing inventory quantities, confirm that the latest document and voucher numbers are continuous, and open sample attachments. Missing ranges are itemised and handed to the business to decide how to re-enter.
Close the entry point, harden, and sign off
Find and close the entry point: remove public port forwards for 1433 and 3389, reset every SQL and system credential, disable or rename sa, turn off xp_cmdshell, delete rogue accounts and scheduled tasks, and patch the front-end ERP and middleware. Rebuild backups as full plus log backups with one offline or immutable copy, keep the backup server outside the production domain, and complete a real restore drill. Finally, deliver an incident report covering root cause, timeline, recovered scope and a remediation checklist.
Recovery paths
There is an important technical premise here: SQL Server organises data in 8KB pages, each carrying its own header and checksum. So long as encryption did not cover the entire file, untouched pages remain complete, parseable rows. This is why "most of the data was recovered from an encrypted .mdf" holds true in many cases.
Path 1: restore from backup and transaction logs. The best outcome available. It requires an unencrypted full backup, an intact differential chain and a readable tail log. Where those exist, an account set can be brought back to close to the moment of encryption. Note that backup files themselves must be entropy-checked first, to confirm their headers were not quietly encrypted.
Path 2: page-level repair and data extraction. Applies where the .mdf was header/footer or intermittently encrypted. The method bypasses damaged metadata, scans page structures directly, reconstructs table definitions and exports readable rows as a loadable dataset. Its limits must be stated: the output is readable data, not the original file; tables with damaged clustered indexes may lose rows; LOB / FILESTREAM values, full-text indexes, some constraints and stored procedures may need to come from elsewhere; and business reconciliation is mandatory afterwards.
Path 3: public decryptor. Viable only where the family and version match a decryptor actually published by a vendor or research body. Identify the family first, then validate against a copy in an isolated environment — never test on production files.
Path 4: snapshots and residual files. Check storage- and hypervisor-layer snapshots, read-only NAS snapshots, tempdb and temporary export remnants, and ERP-generated artefacts such as end-of-day exports, reconciliation files and report caches. These frequently fill critical gaps.
What we will not claim: no "100% recovery", no "guaranteed decryption", and no recovery rate quoted before assessment. We do not pay ransoms and we do not negotiate. The assessment states expected recoverable scope, achievable recovery point, and what is definitively lost.
Common ransomware families
- Some versions decryptable
Mallox
Mallox (also known as TargetCompany) breaks in mainly through brute-forced MS SQL Server credentials, targets database servers specifically, and has a Linux/ESXi variant. Files encrypted between 2023 and early 2024 may be decryptable with Avast's free tool; later builds have no public decryption method.
- No public decryptor
Weaxor
Weaxor emerged in late 2024 as a same-lineage successor to Mallox, continuing its focus on MS SQL Server and exposed web services. It appends .rox, .weax or .wxx and drops a RECOVERY INFO.txt note. It has led infection volume in China through 2025 and 2026 (45.45% in July 2026, 65.74% in August 2026) and has no public decryptor.
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- No public decryptor
Makop
Makop has operated as a RaaS since 2020, with affiliates breaking in mainly through brute-forced remote desktop credentials and deploying by hand. Extensions include .makop, .mkp and .baseus, with a readme-warning.txt note. It ranks consistently high in Chinese infection statistics and has no public decryptor.
Hardening recommendations
- Never forward port 1433 to the internet. It is the principal entry point for MS-SQL ransomware incidents. Where external access is genuinely required, front it with a VPN or reverse proxy and restrict source IPs.
- Harden SQL authentication. Disable or rename sa, set strong passwords on every login, prefer Windows authentication, and enable failed-logon auditing and lockout. Give application connection strings a dedicated least-privilege account, never sysadmin.
- Close high-risk surfaces. Disable xp_cmdshell, OLE Automation and ad hoc distributed queries; restrict the SQL Server service account and do not run it as Local System or a domain administrator.
- Make backups ransomware-resistant. Full backups plus transaction log backups, written to an independent host or immutable storage, with the backup directory not SMB-shared to the production network, and one offline copy retained.
- Run restore drills. Each quarter, fully restore one account set and time it, proving the backup and log chains actually work.
- EDR must cover database servers, with tamper and shadow-copy protection enabled; alert on precursor behaviour such as SQL services being stopped, vssadmin delete shadows, and wevtutil cl.
- Govern the front-end ERP too. Keep Yonyou, Kingdee and their middleware and web components patched, and close unnecessary external interfaces. Public reporting documents families delivering ransomware at scale through file-upload and command-execution flaws in domestic finance software.
- Segment the network. Open only required ports from application servers to the database segment, keep office endpoints out, and consolidate administrative access onto a jump server with MFA.
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.
Related industries
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Retail and E-commerce Ransomware Response
In retail and e-commerce, ransomware translates directly into an inability to sell: order systems, membership, POS and warehouse fulfilment stop together and losses accrue by the hour. This page covers the sector's attack patterns, a recovery order built around the order-to-fulfilment chain, and handling of member data exposure.
Construction and Real Estate Ransomware Response
In construction and real estate the core assets are drawings, models and project documentation — typically scattered across project-site NAS units, shared drives and personal computers with no unified backup. This page covers the sector's threat profile, recovery of drawings and BIM models, and defences for dispersed, multi-project environments.
Logistics and Supply Chain Ransomware Response
Logistics is acutely time-sensitive: when TMS, WMS, dispatch and sorting systems stop, goods pile up in warehouses and on routes immediately, and the effect propagates up and down the supply chain. This page covers the sector's threat profile, a recovery order built around goods movement, and hardening for EDI-interconnected environments.
Related services
Ransomware Decryption
Identify the family first, then commit to a recoverable scope — without paying a ransom.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
Our SQL Server .mdf is encrypted — can the Yonyou / Kingdee account set be recovered?
Most cases leave room for recovery, and two factors decide it. First, whether encryption covered the whole .mdf: ERP account-set files are typically tens to hundreds of gigabytes, and many families encrypt only the header for speed, leaving the remaining 8KB pages intact and extractable page by page. Second, whether backups and transaction logs are usable: an intact chain gives the best result. Note that recovering an account set is not the same as restoring a file — attachments, report templates and interface data must be inventoried too, and finance must reconcile the result before sign-off.
How did the attackers get in? We only exposed the database port.
An exposed database port is itself a primary entry point. Public reporting shows the Mallox / TargetCompany family has long preferred internet-reachable MS-SQL instances, dictionary- and brute-forcing sa and similar privileged accounts, then using the command line and PowerShell to pull payloads and escalate; its Weaxor rebrand kept the same focus. Other common entries are weak-password 3389, leaked VPN credentials, and file-upload or command-execution flaws in the front-end application. Our forensics phase delivers a specific conclusion rather than a vague "probably a weak password".
Can we just run DBCC CHECKDB repair on the encrypted database?
Not on the original file. DBCC's repair options — especially REPAIR_ALLOW_DATA_LOSS — are designed for logical corruption. Faced with an encrypted file header they cannot restore data, and they can trigger engine writes and page deallocation that destroy pages which were still extractable. The correct order is: image the data volume read-only, then run entropy analysis and page-level parsing against the copy in an isolated environment. Where engine-level operations genuinely help, they too run only on the copy.
What is the .ldf transaction log for? Ours was also encrypted.
The transaction log determines the recovery point you can reach. With a usable full backup and an intact tail log, you can in principle recover to the last commit before encryption; with a damaged log, you fall back to the last good backup and re-enter later transactions. An encrypted .ldf is not automatically a dead end — it may also be header-only encrypted with parseable log blocks remaining, and log backups (.trn) stored elsewhere may be untouched. All of this is checked during assessment.
Could the recovered data fail to reconcile?
It can happen, which is why reconciliation is a required step rather than an option. Page-level repair may lose a few rows or damage some indexes; a backup restore leaves a gap after the backup point. Our practice is to sit down with finance, warehouse and operations after recovery to check the ledger against subledgers, closing inventory, latest document numbers and voucher continuity, itemise every discrepancy with its cause, and let the business decide how to re-enter or reverse. The recovery report states these gaps explicitly.
Updated