Verified client result
Industry: Sector withheld for confidentiality
ERP Recovery When Encrypted Files Kept Their Names
- AX 2012 R3
- SQL Server 2012
- PowerShell
- T-SQL / SqlBulkCopy
- Hyper-V
- Active Directory
- Kali Linux
- SHA-256
Delivery duration: About 5 weeks, from triage to handover
Overview
Four months after ransomware encrypted the ERP system an operating business runs on, and after several repair attempts, it was still down. A previous contractor had produced clean copies of its databases, but on a newer SQL Server version the system could not use; we moved that data to the version this installation needed, rebuilt the system on clean, isolated infrastructure and handed it over running, with its business records verified.
The Challenge
There was no decryption key, every original database backup was encrypted, and after earlier repair attempts nothing on the disks could be taken at face value. The ransomware had also encrypted some files without renaming them: the name stayed normal while the contents were replaced. Trusting file names would have meant rebuilding on a database that was still encrypted, and finding out days later. The only clean, complete copies had been made by a previous contractor on SQL Server 2025, but this ERP installation was bound to SQL Server 2012, and SQL Server offers no supported way to move a database back to an older version.
The Solution
We kept the original disks read-only and checked every candidate file by its header bytes, not its name: a clean SQL Server page carries one signature, and an encrypted file here began with RAWR. That check proved the original 23 GB business database was encrypted while a separate 15.4 GB copy was clean, and that a 1.09 TB backup virtual disk was encrypted too. We copied out 74 GB of targeted files under a SHA-256 manifest, then rebuilt the Active Directory domain, SQL Server and ERP application tiers on a new, network-isolated Hyper-V host. The standard SqlPackage export crashed on the size of the ERP schema, so we moved the data into SQL Server 2012 with a purpose-built PowerShell bridge that generates the schema as T-SQL and streams rows with SqlBulkCopy, table by table. The bridge was written with AI assistance under direct engineering supervision, and the record counts in the results below were taken from the data it moved. A previous full compile had crashed; we traced the crash to one damaged metadata object and had a correctly configured AXBuild regenerate it, rather than overwrite it from a clean reference and destroy the client's customisations, then confirmed the result matched that reference byte for byte. Before the full compile, and again before CIL generation, we took checksummed backups and verified them. When three tables turned out to hold duplicate business rows, we stopped: adding their missing keys would have meant deduplicating or renumbering business data, which the written scope did not allow. We have carried out ransomware data recovery for four organisations.
The Results
At handover all five virtual machines were running and the ERP application server was up. Business records were verified in the recovered system: 268,921 general-ledger vouchers, 432 customers and 1,902 items, current to the last sales order placed on the day of the attack. The business database (6,960 tables) and the model database (48 tables) both landed on SQL Server 2012. To show the system was usable and not only readable, a test customer and a test item were created through the ERP client and then confirmed in the database. Formal handover documentation was delivered.
Measurement & evidence
The record counts come from the system-state export taken at handover. File sizes, table counts and the other figures from this engagement come from its triage results, handover notes and a written recovery log with evidence references for each finding, backed by 81 timestamped evidence files. The clean SQL Server 2025 copies of the databases were produced by a previous contractor before this engagement began, and our work started from that point. This was data recovery, not a legal forensic investigation. Final CIL generation, report services and the Role Center dashboard are not proven by the captured evidence, so none of them is claimed here, and neither is a hardened production environment. A further 12 pre-existing or custom metadata compile errors were deliberately left unrepaired. Client name, sector, hosts and dates are withheld.