Files encrypted? Don't delete anything.
Recovering Files Encrypted by Ransomware
When ransomware encrypts files, deleting, formatting or using untrusted tools can increase the damage. Fast, organised handling preserves your assessment options.
- +25
- Years of experience
- +50K
- Cases handled
- 99%
- Success rate after diagnosis
Is the infection still active? Disconnect the machine from the network first.
Unplug the network cable, turn off Wi-Fi and VPN, and disconnect attached storage and backups. Do not power the machine off if it can be isolated and a response team is available, because memory and logs may help the analysis. If it cannot be isolated and encryption or spread continues, ask for immediate guidance.
Speed matters, but randomness is more dangerous.
What to do when your files are encrypted?
- 01
Isolate the device
Stop using the affected device or server as much as possible.
- 02
Keep the files
Don't delete the encrypted files, and keep the ransom note and the strange extension.
- 03
Stop random tools
Don't install untrusted decryptors and don't format the device.
Recovery starts by understanding the infection type.
Business data recovery after a ransomware attack
The infection type, the encrypted files and the available backups are inspected. In a business environment we review servers, storage media and backups to determine recovery chances and reduce downtime impact.
Inspect the case
Choose the path
Safe recovery
Supported devices & brands
The systems and environments we inspect after encryption
What ransomware leaves behind depends on what it hit. A database file and a virtual disk image are not read the way documents are read. We start by identifying the encryptor family from the new extension, the ransom note and the structure of an encrypted file — families such as LockBit, Phobos and Makop leave known markers — then measure how much of each file was actually encrypted.
SQL Server databases
MDF and LDF files are held open by the service at the moment of infection, and only part of them may be encrypted. BAK copies sitting on the same volume are usually hit along with them. The database should not be started before its page consistency is inspected.
MySQL and MariaDB databases
InnoDB data is split between ibdata and a per-table ibd file. Encrypting the first pages breaks the tablespace header, while the data pages behind it stay readable in many cases and are handled page by page.
Oracle databases
Data files, control files and redo logs have to come back consistent with each other in time. RMAN copies kept on the same mount are usually inside the blast radius, so the work starts with an inventory of what survived intact, before anything is opened.
Virtual disk images: VMDK, VHDX, qcow2
Large files are sometimes encrypted in spaced intervals rather than end to end. That means the guest file system inside the image can be intact across wide regions, and can be read from within the image without booting the virtual machine.
Exchange mail servers
The EDB database and its transaction logs belong together, and a database left in a dirty shutdown is not fixed by a quick repair command. OST files on staff machines may hold a copy of the mailboxes the infection never reached.
Backups and NAS storage
Most families delete shadow copies and go after backup repositories and any mounted NAS share. A deleted backup is not necessarily a lost one, as the volume can be inspected for remnants of the deleted files before they are overwritten.
How an encryption case is handled
- 01
Isolate and image before any analysis
No work happens on the infected system. We take sector images of the disks or of the virtual machine images in the lab, and keep the ransom note and a sample of the encrypted files exactly as they are.
- 02
Measure the encryption pattern, do not assume it
We compare an encrypted file against an original of the same format and identify which bytes changed and where they stop. That comparison shows whether the file is encrypted end to end or only in part, and it is what decides whether there is anything in the case to work with at all.
- 03
Extract what the encryption never touched
Many programs write a new encrypted file and then delete the original, leaving those originals in unallocated space. We look for them, for system snapshots, temporary copies, transaction logs and older versions, and for the untouched regions inside database files and virtual disk images.
- 04
Rebuild, then hand over in isolation
Databases are rebuilt from the intact pages and tested for whether they open before handover, and reconstructed virtual disks are read to confirm the file tree. Handover is on a separate medium, and we sign an NDA on request.
Start from your case
Which case describes what happened to you?
Ransomware incidents are not alike. Pick the closest one, and the assessment starts from the available evidence without altering the original files.
- 01
One machine's files will not open
New extensions or a ransom note appeared on a desktop or laptop, and the rest of the machines are working.
- 02
A company server or network stopped
Network shares, user accounts, or more than one machine were affected at the same time.
- 03
NAS, RAID or shared storage
Files were encrypted on network-attached storage, a disk array, or central storage.
- 04
Backups encrypted or deleted
The backups exist but will not open, or restore points and snapshots were deleted.
- 05
Virtual environment or VM files
A VMware or Hyper-V environment, virtual disk files, or hosted systems were affected.
- 06
Threat to leak data
A message arrived claiming data was stolen or threatening to publish it, whether or not files were encrypted.
An illustrative case explaining the route
Six illustrative cases from the most targeted sectors
The sectors come from the Saudi threat research: construction, manufacturing, technology, retail, health and logistics. Each case sets out what was examined, what came back, and what did not.
-
01
Construction & contracting
A project file server with its backup attached
A contracting office: drawings, bills of quantities and payment applications on one network share, with the backup on a disk attached to the same server.
Drawings and contracts came back from an older snapshot; the mail archive did not.
-
02
Manufacturing & industry
Production stopped without one controller being encrypted
A building materials plant: ERP, quality and warehouse systems were encrypted, and production halted although the machines themselves were untouched.
ERP came back from an offline copy; the custom production recipes did not.
-
03
Technology & managed service providers
One admin credential opened several client environments
A managed service provider: an admin account reused across clients, so a single compromise reached more than one environment.
Two environments came back from snapshots; the management tool's own logs did not.
-
04
Retail & e-commerce
Tills still selling while stock had no idea what left
A small retail chain: the stock and orders server was encrypted, so the tills kept selling without a correct balance.
Orders came back from the online store database; two days of branch stock did not.
-
05
Health & care
Patient records and imaging on one storage unit
A clinic group: the records system and the imaging archive were encrypted together, halting both booking and consultation.
Records came back from a nightly copy; a full day of images did not.
-
06
Transport & logistics
Shipments on the road and a tracking system that will not answer
A transport company: the operations and tracking system was encrypted while shipments in transit had no confirmed destination.
Trip data came back from partner records; two days of proof of delivery did not.
Definition before action
What is ransomware?
Ransomware is malicious software that blocks access to files or systems, after which the attacker demands payment to restore access or to withhold data they claim to have stolen. An attack may stay on a single machine, or move across the network to reach servers, shared storage, backups, and synchronised cloud services.
A changed file extension does not mean the extension name is the decryption key, nor does removing the malware bring the files back on its own. A sound assessment starts by identifying the pattern of infection, preserving the evidence, and examining the available recovery paths without writing over the source.
Before you assume
How do you know what happened might be a ransomware attack?
The indicators are more reliable together than any one of them alone. Read them as a whole picture, not a checklist.
- A new extension appearing on a large number of files.
- Images, documents and databases failing to open while their sizes stay the same.
- A text or HTML file containing payment instructions or a contact method.
- The desktop wallpaper changing, or a lock screen appearing.
- Company services or applications stopping suddenly.
- Files encrypted across shared folders or several machines at around the same time.
- Backups, restore points, or virtual snapshots disappearing.
- Messages threatening to publish data or to contact your customers and partners.
Order before tools
Recovery starts by identifying the infection, not by trying software
We compare the ransom note, the file extension, the encryption pattern, the timing of the incident, and the executables and logs available. We may ask for a small encrypted sample together with a matching original file if you have one. These indicators help identify the family or the technical pattern, and establish whether there is a trustworthy tool, a valid backup, an earlier version, unencrypted remnants, or another route to recovery.
The extension name alone is not enough to identify the family: different families may use the same extension, and a family may change its extensions or messages from one victim to the next.
Not one single thing
Types of ransomware attack
The route differs with the type. These eight cover most of what reaches us.
Encrypts files or parts of them while the system sometimes keeps working. It may target documents, images, databases, backups, and virtual machine files.
Blocks sign-in or use of the machine behind a lock screen, without that necessarily meaning every file is encrypted. The assessment has to separate a locked interface from data that is genuinely encrypted.
The attacker claims to have stolen data before encrypting it, then threatens publication as well as blocking access. That is two separate jobs: restoring operations, and establishing the scope of the leak alongside the regulatory and legal response.
The attacker may add further pressure such as contacting customers or partners, disrupting services, or threatening a denial-of-service attack. Decryption alone does not end the incident.
In some incidents the attacker steals data and demands payment without encrypting anything. That is a data-breach response case, not only a file recovery one.
The attack may look like ransomware while actually destroying the data or its keys for sabotage. The odds of recovery are fundamentally different, which is why no key or decryption is promised before analysis.
It may run on Windows, Linux, or virtual environments, and can encrypt large stores quickly. The priority is isolating the points of spread, protecting unaffected copies, then identifying critical systems and the order in which to restore them.
Not a distinct encryption type but an operating model, in which tool developers supply an extortion infrastructure to other groups who carry out the attacks. Messages and extensions can vary even within the same family.
More than one route
Which options do we examine before reaching a result?
Recovery does not rest on a single route. We examine the following paths as the case allows, working on a matching copy wherever possible and preserving the original source.
A trustworthy decryption tool
A known tool may exist for certain builds or victims. A tool existing for a family does not mean it works with every build or key, so it is tested on a copy before any wider use.
An intact backup
The backup's date, completeness and integrity are verified, along with the absence of any remnants of the breach, before it is restored into a clean environment.
Earlier versions and snapshots
Earlier copies may exist in the storage system, the cloud service, or the virtualisation platform. They must be examined before any sync or new write erases them.
Remnants of the original files
The encryption method may leave deleted or temporary copies, or unencrypted fragments. The odds depend on the storage medium, how much the device was used after the incident, and TRIM or overwriting behaviour.
Recovery from the application or database
Transaction logs, export copies, temporary files, attachments, or application output may help return part of the data even when the files themselves cannot be decrypted directly.
Virtual environment or central storage
The route may run through virtual machine files, snapshots, replication copies, or storage layers that were not fully affected. That calls for examining the structure, not a single file.
Partial recovery ordered by priority
Where full recovery is not possible, files and systems are ordered by operational priority, then the result is measured and the recovered files checked for validity.
No current technical route
Some cases have no key, no copy, and no recoverable remnants. That result is stated plainly, and a copy of the encrypted data is preserved in case a trustworthy solution appears later.
What do we need to assess the case?
- 01
The ransom note
A photograph or copy, ideally the original text or HTML file exactly as it is.
- 02
The extension that appeared
Exactly as it appears, with no correction or retyping.
- 03
A small encrypted sample
A non-sensitive file, together with a matching original of that same file if you have one.
- 04
Device and system types
The devices, systems and storage media affected, and roughly how many.
- 05
Timing of the incident
When the problem was noticed, and the last time the files were working.
- 06
Network and backup state
Is any machine still connected? Do backups exist, and were they connected?
- 07
What happened after the infection
Was a cleanup, decryption or formatting tool run? Are there signs of unauthorised access?
- 08
Recovery priorities
Which systems and files should come first if full recovery is not possible.
From sending the case to handover
- 01
Urgent triage
We establish whether the attack is still active, the scope of affected machines, and any risk to other machines or backups.
- 02
Preserving evidence and source
We identify what must be kept, and recommend working from an image of the storage medium where that is appropriate.
- 03
Identifying the pattern
We examine the ransom note, extension, samples, logs, and affected structure to assess the closest match.
- 04
Testing recovery paths
We test trustworthy tools, backups, earlier versions, data remnants, or application routes on a limited and safe scope.
- 05
Presenting result and scope
We set out what is possible, what is uncertain, the priorities, and the time and cost before continuing with the full job.
- 06
Recovery into a clean environment
Data is recovered onto a clean medium or environment, and files are not returned directly to a system that is still compromised.
- 07
Verification and handover
A documented sample of files and systems is checked for integrity, and the data is handed over within the agreed scope.
- 08
Reducing the chance of recurrence
After recovery we can give recommendations on backups, accounts, patching, network segmentation, and monitoring.
Between the extremes
Not every case is decryption or nothing
These are common patterns and their likely outcomes. Not promises — an account of what actually happens between the two extremes.
- 01
A trustworthy tool exists for the same build
Testing is carried out on copies of a limited set of samples. If the test succeeds while file integrity holds, the scope can be widened under a clear plan.
- 02
The backup is intact but the environment is compromised
The backup is not restored straight away. The priority is isolating the breach, verifying the backup, cleaning or rebuilding the environment, and then restoring.
- 03
The backups themselves are encrypted
We examine offline copies, earlier versions, older storage, backup logs, and protection layers or snapshots that may not be visible to the user.
- 04
Partial encryption, or the attack stopped mid-run
Files, fragments or whole machines may be untouched. What remains must be protected immediately, then the data triaged rather than assumed to be all in the same state.
- 05
A large database or VM will not open
The current file may be partially encrypted or corrupted. Encryption is assessed first, then internal structural integrity and whether partial extraction is possible.
- 06
An SSD used heavily after infection
Overwriting and TRIM can reduce the chance of recovering deleted copies. Usage should therefore be minimised, and no tools installed onto that disk.
- 07
A leak threat with no encryption
The focus is containing access, preserving logs, identifying the affected data and accounts, and coordinating with cyber security, legal counsel, and the relevant authorities.
- 08
No current technical solution
The encrypted files, the ransom note, and the case details are preserved unmodified. Trustworthy tools may appear later for some families, but that cannot be guaranteed or dated.
Most damaging
Avoid the steps that can reduce the chance of recovery
Most of what is lost for good is lost in the first hours, through actions that look reasonable.
- Do not format the disk or reinstall the system onto the original source.
- Do not delete the encrypted files, the ransom note, or the logs.
- Do not rename file extensions by hand; renaming does not decrypt anything.
- Do not run decryption tools from adverts or untrusted links.
- Do not install software onto the affected disk or copy new files to it.
- Do not connect backups or healthy disks to a machine you suspect is infected.
- Do not start restoring backups to the network before the breach is contained.
- Do not open samples on a work machine that is connected to the network.
- Do not keep power-cycling the machines without a plan.
- Do not negotiate or pay before a technical, legal and management assessment.
- Do not assume that removing the malware makes the accounts or network safe.
- Do not disclose sensitive incident details publicly before the response is coordinated.
Not a shortcut
Paying does not guarantee the data back, nor the end of the incident
The attacker may not send a key, the decryption tool may be slow or faulty, and the extortion may continue because of a stolen copy of the data. Payment can also encourage repeat targeting. Backups, trustworthy tools, the scope of the breach, and the recovery paths should therefore be assessed first, with oversight from management, cyber security, legal counsel, and the relevant authorities where needed.
Even where a decryption tool is supplied by the attacker, the breach still has to be contained, credentials changed, systems examined, and continued access ruled out.
Obligations that may apply in Saudi Arabia
Recovery is one track; regulatory notification is another that starts early
If the incident touched personal data, a notification period may run from the moment you become aware of it rather than from the end of the technical analysis — the National Data Governance Platform publishes a period of no more than 72 hours along with the notification conditions. That is why assessing the obligation runs alongside the technical work rather than after it.
The National Cybersecurity Authority's controls cover backups, incident management, business continuity and third parties — the same places that decide the outcome of a ransomware incident before it happens.
After recovery
Close the entry point so it is not used again
Returning to operation is not the end of the incident. If the entry point stays open, the infection can return after recovery.
- Keep separate, offline backups at all times, and test restoring them regularly.
- Use a copy that day-to-day operational accounts cannot modify or delete, wherever possible.
- Enable multi-factor authentication, especially for email, VPN, and administrative accounts.
- Patch systems, applications and network devices under a clear programme.
- Reduce administrator rights and separate admin accounts from daily use.
- Restrict remote access services; do not leave RDP or management panels exposed to the internet.
- Segment the network so one compromised machine cannot reach every server and backup.
- Monitor sign-in attempts, account creation, protection being disabled, and backup deletions.
- Use endpoint and email protection with attachment and link filtering.
- Set out a response plan naming who isolates systems, who communicates, and the order of recovery.
- Test business continuity, not merely that the backup job succeeded.
- Review third-party access, dormant accounts, and secret keys.
FAQ
Don't pay and don't format before assessment.
It may be possible depending on the encryption type, the backup state and the infection method.
Usually not; removing the virus may stop the damage but it doesn't decrypt the files.
The decision is not advised before a technical assessment, because paying doesn't guarantee recovery.
No. It depends on the family and build, how keys were handled, and whether a trustworthy tool or a restorable copy exists. Work starts with identification and testing, not with a promise.
Do not delete the correspondence, the tool files, or the payment details. Do not run any tool directly on the source — test it on a copy in an isolated environment — and continue containing the breach and checking accounts and systems.
Separate, offline backups tested regularly, multi-factor authentication, a clear patching programme, restricted remote access, network segmentation, and monitoring of sign-ins and backup deletions.
Usually not. It may remove the malware, but it does not reverse encryption that has already happened. Installing onto the affected disk can also overwrite recoverable data.
No. The extension is part of the file name, not the decryption key. Keep the name and extension exactly as they are.
The ransom note, the extension, a small non-sensitive sample, the device types, the time of the incident, and how many systems are affected. If you have an original copy matching the sample, send it once the channel is agreed.
Triage can often start remotely, but some cases require receiving the storage medium or an image of it, or controlled access to the company environment. That is decided after the initial details.
It varies with the number of systems, data volume, encryption type, storage health, and the recovery path. We give an estimate after the initial inspection, prioritising critical systems in company cases.
It depends on the scope of devices, storage type, volume of work, whether a complex structure must be examined, and the recovery path. A case cannot be priced accurately from the extension alone.
We do not give a guarantee before inspection. We set out the scope of testing, which files succeeded, and the expected outcome before carrying out a full recovery.
It depends on the encryption mode, file-system integrity, and available copies. Sometimes the structure is recovered intact; sometimes files come back with partial names or paths.
We examine offline copies, previous versions, snapshots, backup logs, and older storage media. Backups are not reconnected to the infected network before containment.
There may be options through backups, snapshots, virtual machine files, or partial data extraction. It depends on the platform, the state of its files, and the level of encryption.
It may be possible from a backup, a transaction log, a partially intact database file, or a logical extraction. Encryption is examined first, then the internal integrity of the database.
Avoid testing on the source. Some applications modify the file or write new data to the disk. Work on a copy, and after technical guidance.
Extensions, samples, logs, incident timing, and suspicious processes can all help, but the absence of a note can make identification harder.
The encrypted file itself is not necessarily the malware, but the environment it came from may contain executables or harmful scripts. Do not move its contents to a connected work machine without inspection.
Yes, if the compromised account, the entry point, or an attacker access tool remains. The incident must be contained and the environment cleaned or rebuilt, and credentials changed, before a full return.
Treat the claim as a security incident separate from file recovery: preserve the logs, identify the affected systems and data, and involve cyber security, legal counsel, and the relevant authorities.
Trustworthy tools exist for some families from known organisations, but the family and build must match, the instructions must be read, and testing must happen on a copy. Avoid unknown links and adverts.
Yes. Keep an unmodified copy along with the ransom note and the case details. A trustworthy tool may appear later for some families, though it cannot be promised.
Usually it is better to recover onto a clean medium or environment after the breach is contained. Writing to a damaged source can reduce the chance of recovery or put the data back at risk.
Storage health is addressed first and a suitable image is taken where possible, then the encryption is analysed on that copy. Running a degrading disk without a plan can increase the damage.
It may mean part of the data is untouched, but it can also leave partially encrypted files or an inconsistent structure. Do not keep power-cycling it; isolate the machine and ask for an assessment.
The service may sync the encrypted or deleted files. Pause syncing from the suspected devices and check version history and restore options before resuming.
There may be regulatory or contractual obligations that differ by organisation type, data, and customers. Coordinate with your cyber security lead, legal counsel, and the relevant authorities to determine what applies.
BitLocker is a legitimate disk-encryption feature. An attacker may misuse legitimate tools or change their keys, but losing a BitLocker key alone does not prove ransomware. Diagnosis rests on the incident context, the logs, and the messages.
No. Data recovery and incident response are related but different tracks. Attacker access must be removed, the entry point addressed, credentials changed, and verification done before normal operation resumes.
Next step
Send case detailsIsolate the device and keep the ransom note.
Send the file extension, the ransom note and a description of the affected devices. We assess the case without inaccurate promises.