QuickBooks Desktop Ransomware Recovery: File Triage and Rebuild

When ransomware encrypts a QuickBooks Desktop company file and its backups, this playbook covers triage and a verified path back to multi-user access.

Run this playbook when ransomware has hit a machine that hosts or accesses QuickBooks Desktop: the company file will not open, backups on the same network are suspect, and the safe route back is a disciplined sequence of containment, triage, clean-copy recovery, platform rebuild, and verification. Our engineers use it to return a QuickBooks environment to verified multi-user operation without trusting any machine the attack touched.

Phase 1: Contain and Preserve

Isolate every machine that hosted or opened the company file: disconnect the network cable, turn off Wi-Fi, and leave the drives as they are. Do not delete ransom notes, do not rename encrypted files, and do not reboot repeatedly.

Before any recovery work, make a block-level copy of each affected drive onto clean offline media and work only from those copies. This is the first rollback point: if a later step damages a file, the image preserves the post-attack state exactly as the attacker left it.

Record the encrypted file extensions, the ransom note filename, and modification timestamps. Some ransomware families have published decryptors, and these details identify the family. Copy the encrypted originals to quarantine storage, mark them read-only, and leave them there; a decryptor may appear later.

Phase 2: Triage the QuickBooks Files

Inventory every QuickBooks artifact on the images: .QBW company files, .QBB backups, .QBM portable files, accountant's copy sets (.QBA and .QBX), and .TLG transaction logs. Classify each as encrypted, clean, or unknown.

Check headers before trusting extensions. A healthy .QBW starts with a recognizable QuickBooks header; an encrypted file reads as uniform random bytes no matter what it is named. Our engineers verify headers on anything that lived on the network during the attack.

Never open an encrypted file in QuickBooks, and do not run password recovery tools against one. Once the database itself is encrypted, password recovery cannot succeed, and failed open attempts only add clutter. Record the size and modified date of every file; the newest clean .TLG matters in the next phase.

Phase 3: Hunt for Clean Copies

Sweep every storage location the attack could not reach: rotated USB drives, tape, NAS snapshots that were offline, offsite backups, and versioned cloud backup services. In cloud sync folders, check version history for pre-attack generations, because sync clients can propagate encrypted copies in both directions.

Ask around for human-carried copies: a portable file emailed to the accountant, a laptop that traveled, an accountant's copy distributed earlier.

The highest-value find is often a .TLG. If the newest clean .QBW backup predates the attack but a matching .TLG was modified closer to it, QuickBooks can replay the logged transactions on top of the older backup and recover the gap.

Test every candidate on the isolated machine, never on production hardware. Rollback point: this phase copies, it never moves or overwrites, so a wrong guess costs nothing.

Phase 4: Rebuild the Platform

Rebuild the host and every workstation from a fresh operating system image. Do not clean machines in place; ransomware routinely leaves persistence that survives casual cleanup.

Install the same QuickBooks Desktop edition and version year as before, or a newer one. Company file formats upgrade forward only: a newer release restores an older backup, but an older release cannot open a newer file. Apply the current release updates before touching data.

On the host, install QuickBooks Database Server Manager, create a fresh folder for company data, and scan the folder. Restore the chosen .QBB into it, or open the .QBM and save it as a company file. For .TLG recovery, place the log beside the restored .QBW under the same base name and open the file so the log replays. Set a new admin password before anyone else touches the file.

Rollback point: keep the backup file you restored from, plus a copy of the restored .QBW taken before the first Verify, so a bad replay or a heavy Rebuild can be undone.

Phase 5: Verify Before Anyone Works

Run Verify immediately after the restore. If it reports problems, run Rebuild once, then Verify again. Repeated Rebuild runs on a file that keeps failing do more harm than good; if the second Verify still fails, stop and move the file into a dedicated repair workflow rather than continuing in place.

Tie the books to records that never touched the network: the trial balance against the last printed statements, bank registers against the most recent reconciliation reports, AR and AP aging totals, and an inventory valuation summary. Compare the list and transaction counts in the Product Information window (press F2) with anything captured before the incident.

Phase 6: Return to Multi-User and Harden

Enable hosting on the host only. Confirm Database Server Manager lists the folder as scanned and the company file as available, map the workstations, and recreate users with new passwords. Bring users back in small groups and confirm each session opens in multi-user mode.

Re-establish backup rotation with at least one offline copy, then prove it by restoring a test backup end to end.

What a Clean Outcome Looks Like

Verify passes with no errors. Balances tie to independent records, and the newest transactions present are consistent with the .TLG timeline. All users work in multi-user mode, a test backup restores cleanly on the first try, and the encrypted originals sit quarantined offline, untouched, in case a decryptor for that family emerges.