Computer Repair · October 25, 2026 · ComputerKing Team
After a Ransomware Attack, How Do You Get Back to Work? Restore or Reinstall, Resetting Passwords, and What to Check Before Reconnecting
After a ransomware attack, the most dangerous step is not the first disconnection — it is rushing back to work. Restoring data onto a machine that is not yet confirmed clean, reusing old passwords, and reconnecting every computer at once can easily bring the problem back.
Key Summary: After a ransomware attack, the most dangerous step is not the first disconnection — it is rushing back to work. Restoring data onto a machine that is not yet confirmed clean, reusing old passwords, and reconnecting every computer at once can easily bring the problem back. This article covers the recovery order after the first response: confirm the machine is clean, then decide between restore and reinstall, then reset passwords and permissions, and finally reconnect in batches, checking each one. Get the order right, and getting back to work is far safer.
What this article covers — and what it does not
The six first-response steps — disconnect, do not power off, do not plug in external storage, photograph the ransom screen, keep the encrypted files, do not pay the ransom — are already covered in our first-response guide, and this article does not repeat them. For the first hour, see "What to Do in the First Second of a Ransomware Attack" (https://www.computerking.hk/blog/ransomware-protection-guide/).
This article covers only what comes after that: the machine is isolated, the evidence is kept, and the question is how to move from "work has stopped" back to "work is normal" without carrying an uncleaned problem into everyday systems. Whether it is one home computer or several office machines, the order is the same: clean first, work second.
First principle: clean first, work second
Most people hit by ransomware want one thing immediately: restore the backup and get back to work. That impulse is the most dangerous part of recovery. Restoring a backup does not itself make a machine clean. If malicious software is still hiding on the machine, restored files can be hit again, or the restore itself can carry the problem to other devices.
So the first step of recovery is not restoring. It is confirming:
- The affected machine is still isolated from the network, and has not been reconnected to the office or home network.
- A full check has been done using a separate machine already confirmed clean, or a trusted scanning tool — not by asking the suspected machine to scan itself.
- There are no further warning signs, such as unknown programs launching at startup, file extensions changing again, or the ransom message reappearing. Any one of these means the machine is not yet treated as clean, and the next step should not start.
The test is not "one scan found nothing, so it is clean." It is "checked while isolated, with no further abnormal signs" before moving to the restore stage. That distinction decides whether you are genuinely recovering, or only postponing the problem.
Restore or reinstall: how to choose
Once the machine is confirmed clean, the second decision is whether to restore from backup or reinstall the whole machine. Each option has a cost, and neither is right for every situation:
| Approach | Suitable when | Cost to watch |
|---|---|---|
| Restore from backup | There is an offline backup, or a backup with version history, and the backup itself is uncontaminated; the system setup is complex and reinstalling would be very costly | The backup version and contents must be verified first — never restore a version made after encryption |
| Reinstall the whole machine | It is unclear whether the machine can be cleaned reliably; there is no trusted backup; the system is already old and a fresh install is cleaner | Time to reinstall software, set up accounts and permissions; data must be recovered separately from a clean source |
| Restore data only, not the system | The system has already been cleanly reinstalled, and only files are needed | Do not restore the old system settings wholesale, or problem settings may come back with them |
The deciding question is simple: do you trust the restore source? If the backup source is clean and the version is clear, restore. If the source is doubtful or the versions are confused, reinstalling is the safer choice. Saving time by restoring from a doubtful source only creates more work later.
Verifying a backup restore: four checks
Even after choosing to restore from backup, do not restore everything at once. Four checks are the part of recovery most worth spending time on:
1. Check the version. Choose a backup version from before the encryption event, not the most recent one — if cloud backup syncs automatically, encrypted files may already have synced to the cloud, making the "latest version" itself encrypted. A cloud service with version history lets you pick a point in time before encryption.
2. Check the backup itself. Check whether the backup files have been encrypted or damaged. An offline backup (for example, an external drive that is not normally left connected) is most valuable here, because ransomware could not reach it.
3. Test-restore in isolation. First restore a small set of files onto an isolated computer, open them, and check they open correctly and the contents are right. Only scale up after that test passes.
4. Restore in batches. Restore the most important working files first, confirm they are normal, then restore the rest. Leave checking time between batches — do not restore everything and then check everything.
These four steps look slower, but they are the only way to be able to say after a restore, "this batch was checked and is fine." Finding a problem only after a full restore means starting the whole process again, and stopping work a second time.
Passwords and permissions: what must be reset
Password problems are easily overlooked after a ransomware incident. The machine is restored, the files open, and everyone treats the incident as over — but account credentials may have been exposed or stolen during the incident. Reset in this priority order:
| Priority | Items to reset | Why |
|---|---|---|
| First batch | Email accounts, system administrator accounts, cloud service accounts | These accounts can reset passwords for other services — losing one is like losing the whole set of keys |
| Second batch | Remote desktop, VPN, internal company system accounts | Remote access is a common entry point; leaving it unchanged after an incident leaves the door open |
| Third batch | Other work platforms, shared documents, social accounts | Any service used or with a stored password on the affected machine, reset one by one |
| Do at the same time | Turn on two-factor authentication; disable accounts and remote entry points no longer used | Changing the password alone is not enough — two-factor authentication is the second layer of protection; close entry points you do not use |
Reset passwords on a device already confirmed clean, not on a machine still suspected of infection — otherwise the new password may be taken immediately. After resetting, check account sign-in records for abnormal activity, and act at once if any appears.
Reconnecting in batches: do not reconnect everything at once
With the machine clean, files restored, and passwords reset, reconnecting to the network comes next. The most common mistake here is reconnecting every computer at once and assuming the incident is over. The correct approach is batches:
1. Reconnect one machine first, use it normally for a while, and watch for abnormalities: file extensions changing again, the ransom message reappearing, the system slowing for no reason, or unknown programs appearing.
2. Only when the first machine shows no abnormality, reconnect the next batch — again leaving observation time between batches.
3. After everything is reconnected, stay alert for the first few days. Do not treat reconnection as the end of the incident.
In an office, add one more step: tell colleagues which systems are restored and which are not yet restored, and who to report abnormalities to at once. Recovery is not only a technical process, it is also a communication process. If colleagues do not know which machine is still unsafe, they may easily keep working on an unrestored system.
Recording the incident and considering notification
When the incident is handled, there is one last step many people skip: writing it down. The record does not need to be complex, but it should be complete:
- When it was discovered, which devices were affected, which files were encrypted.
- Which isolation and checking steps were taken, and which backup version was used for restore.
- Which passwords and permissions were reset, and which systems were reconnected in batches.
This record has two uses. First, if a similar incident happens again, there is no need to start from zero. Second, if the incident may have exposed customers' or employees' personal data, the organisation can refer to the Hong Kong Privacy Commissioner for Personal Data's guidance on data breach handling, and consider whether notification and follow-up are needed. The notification decision should be based on the actual situation, not on a feeling that "it is probably fine."
Five common mistakes during recovery
| Mistake | Why it causes trouble | What to do instead |
|---|---|---|
| Restoring before confirming the machine is clean | Malicious software is still present, so the restore is wasted | Check while isolated; restore only with no abnormal signs |
| Restoring a version made after encryption | Cloud sync may already have written encrypted files into the backup | Choose a pre-encryption version; test-restore in isolation |
| Reusing old passwords | Credentials may already have been exposed | Reset in priority batches; turn on two-factor authentication |
| Reconnecting all machines at once | A problem spreads everywhere at once, and the source cannot be traced | Reconnect in batches, observing each batch |
| Keeping no record of the incident | The next incident has to be worked out from scratch, and notification has no basis | Before closing the incident, write down the timeline, scope, and steps |
Before asking for help, prepare these five items
If you decide to ask someone to help with recovery, preparing the following lets them judge the situation faster, and lets the fee arrangement be discussed clearly (fees are quoted individually; there is no flat rate):
1. Which devices are affected — home machines or office machines.
2. A photograph of the ransom screen and the time it was discovered (the evidence already kept during first response).
3. Whether there is a backup, where it is (external drive, cloud, NAS), and when the last successful backup was.
4. Which steps have already been taken: isolated or not, scanned or not, restored or not.
5. Which data matters most, what can wait, and what is needed for work immediately.
Having these five items ready not only saves back-and-forth questions, it also avoids an inaccurate estimate being given when information is incomplete.
Summary
The order of ransomware recovery comes down to one sentence: clean first, work second. Confirm the machine is clean before restoring, verify the version before a large-scale restore, reset passwords before reconnecting, and reconnect in batches before calling it done. Each stage buys insurance for the next one. Skipping any stage saves time that will have to be repaid later.
If you are in the recovery stage right now and are unsure whether a step was done correctly, stop, and work through the order above item by item. The item not yet ticked is the thing you should be doing now.
Frequently Asked Questions
Q: After a backup restore, if the files open, does that mean everything is fine?
A: No. Files opening only proves that batch of files is fine; it does not prove the machine is clean. The system must still show no abnormal signs, and a period of batched reconnection must pass without problems, before recovery can be treated as complete.
Q: With no backup, is there no hope?
A: Not necessarily. First, keep the encrypted files and do not delete them, because public decryption tool projects (for example, No More Ransom) occasionally release free decryption tools for certain older variants. Second, confirm the machine is clean and reset passwords, so the damage does not spread. Whether individual files have any other recovery route has to be judged case by case — do not trust any claim made in advance that recovery is guaranteed.
Q: Can cloud backup auto-sync copy encrypted files to the cloud too?
A: Yes, which is why restoring must use a pre-encryption version. A cloud service with version history lets you pick an older point in time. If it is unclear which version is clean, test-restore a small set in isolation first, and only scale up after checking.
Q: Is reinstalling the whole machine always the safest option?
A: Reinstalling is one of the most thorough options, but it is not necessary in every case, and reinstalling alone does not automatically make everything safe. After reinstalling, passwords must still be reset, the system and software updated, and reconnection done in batches — none of those steps can be skipped. If the backup source is clean and the version is clear, restoring from backup is also a reasonable choice.
Q: Must every password be changed immediately?
A: Change them in priority order: email, administrator, and cloud accounts first, then remote and company systems, then other services used. Most importantly, change them on a clean device, and turn on two-factor authentication at the same time — changing the password alone is not enough.
Q: For an office with several affected machines, what needs special attention when reconnecting?
A: Reconnect in batches, observe each batch, and tell colleagues which systems are restored and which are not. Also record the incident, so that if personal data may have been exposed, the Privacy Commissioner's data breach handling guidance can be referred to when considering notification.
Q: What if files are encrypted again after restoring?
A: Isolate the affected machine again at once, do not reconnect it, and do not restore again from the same source. This usually means the machine was never clean, or the restore source itself has a problem. Restart from the "confirm clean" step, and do not repeat restores from the same source.
Q: How long does recovery take?
A: There is no flat timeframe. It depends on how many devices are affected, whether backup versions are clear, and whether reinstalling is needed. Getting the order right matters more than speed — skipping verification and batched reconnection to get back to work faster usually makes the whole recovery period longer.
Sources
- Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT), "Beware of Crypto Ransomware": isolate the infected computer, restore from backup, keep an offline backup copy. https://www.hkcert.org/blog/beware-of-crypto-ransomware
- Hong Kong InfoSec website (infosec.gov.hk), "InfoSec: Ransomware": disconnect from the network, run a comprehensive scan, confirm backup data is offline and secure, restore to a clean device. https://www.infosec.gov.hk/en/knowledge-centre/ransomware
- This site's first-response guide, "What to Do in the First Second of a Ransomware Attack": https://www.computerking.hk/blog/ransomware-protection-guide/
- No More Ransom public decryption tool project (mentioned as general practice only; whether a tool exists for a particular variant depends on that project's announcements)
- Hong Kong Privacy Commissioner for Personal Data, data breach handling guidance (for organisations to refer to when considering notification, depending on the actual situation)
Frequently Asked Questions
After a backup restore, if the files open, does that mean everything is fine?
No. Files opening only proves that batch of files is fine; it does not prove the machine is clean. The system must still show no abnormal signs, and a period of batched reconnection must pass without problems, before recovery can be treated as complete.
With no backup, is there no hope?
Not necessarily. First, keep the encrypted files and do not delete them, because public decryption tool projects (for example, No More Ransom) occasionally release free decryption tools for certain older variants. Second, confirm the machine is clean and reset passwords, so the damage does not spread. Whether individual files have any other recovery route has to be judged case by case — do not trust any claim made in advance that recovery is guaranteed.
Can cloud backup auto-sync copy encrypted files to the cloud too?
Yes, which is why restoring must use a pre-encryption version. A cloud service with version history lets you pick an older point in time. If it is unclear which version is clean, test-restore a small set in isolation first, and only scale up after checking.
Is reinstalling the whole machine always the safest option?
Reinstalling is one of the most thorough options, but it is not necessary in every case, and reinstalling alone does not automatically make everything safe. After reinstalling, passwords must still be reset, the system and software updated, and reconnection done in batches — none of those steps can be skipped. If the backup source is clean and the version is clear, restoring from backup is also a reasonable choice.
Must every password be changed immediately?
Change them in priority order: email, administrator, and cloud accounts first, then remote and company systems, then other services used. Most importantly, change them on a clean device, and turn on two-factor authentication at the same time — changing the password alone is not enough.
For an office with several affected machines, what needs special attention when reconnecting?
Reconnect in batches, observe each batch, and tell colleagues which systems are restored and which are not. Also record the incident, so that if personal data may have been exposed, the Privacy Commissioner's data breach handling guidance can be referred to when considering notification.
What if files are encrypted again after restoring?
Isolate the affected machine again at once, do not reconnect it, and do not restore again from the same source. This usually means the machine was never clean, or the restore source itself has a problem. Restart from the "confirm clean" step, and do not repeat restores from the same source.
How long does recovery take?
There is no flat timeframe. It depends on how many devices are affected, whether backup versions are clear, and whether reinstalling is needed. Getting the order right matters more than speed — skipping verification and batched reconnection to get back to work faster usually makes the whole recovery period longer. - Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT), "Beware of Crypto Ransomware": isolate the infected computer, restore from backup, keep an offline backup copy. https://www.hkcert.org/blog/beware-of-crypto-ransomware - Hong Kong InfoSec website (infosec.gov.hk), "InfoSec: Ransomware": disconnect from the network, run a comprehensive scan, confirm backup data is offline and secure, restore to a clean device. https://www.infosec.gov.hk/en/knowledge-centre/ransomware - This site's first-response guide, "What to Do in the First Second of a Ransomware Attack": https://www.computerking.hk/blog/ransomware-protection-guide/ - No More Ransom public decryption tool project (mentioned as general practice only; whether a tool exists for a particular variant depends on that project's announcements) - Hong Kong Privacy Commissioner for Personal Data, data breach handling guidance (for organisations to refer to when considering notification, depending on the actual situation)