New Guidance on Recovering Data After a Ransomware Attack
A ransomware attack does not end when the encryption stops.
That is one of the most important lessons in modern incident recovery.
Attackers may have spent days or weeks inside the organisation before files were encrypted. During that time they may have stolen data, compromised administrator accounts, disabled security controls, altered backups or established additional ways back into the network. The NCSC’s current recovery guidance warns that beginning recovery before you are confident the attacker has been removed creates a real risk of the incident starting again.
So ransomware recovery should not begin with:
“Restore yesterday’s backup.”
It should begin with:
“Can we trust the environment we are restoring into?”
1. Contain the Attack Before Restoring Anything
If ransomware is still active, your first priority is to stop it spreading.
Depending on the environment, that may mean isolating:
infected PCs
servers
virtual machines
compromised accounts
network segments
remote-access services
Do not immediately connect backup drives or repositories to machines that may still be compromised.
The NCSC specifically recommends connecting backups only to known-clean devices during recovery.
For a business incident, containment should be coordinated rather than employees independently switching systems on and off.
You may need evidence from:
security logs
endpoint detection
firewall logs
identity systems
Microsoft 365
backup platforms
to understand the extent of the incident.
2. Assume the Attacker May Have Been There Before Encryption
Modern ransomware frequently involves more than encryption.
Attackers may also:
steal business information
compromise privileged identities
search for backup systems
disable security tools
move laterally between systems
establish persistence
That is why simply deleting the ransomware executable is not enough.
The current Hamilton Group article already reflects this shift, correctly noting that modern ransomware recovery involves much more than malware removal and restoring yesterday’s backup.
Your recovery team needs to establish:
When did the compromise probably begin?
That date influences which backup versions can be trusted.
3. Preserve Evidence Before Rebuilding Everything
There is understandable pressure to get the business running again.
But immediately wiping every system can destroy evidence needed to understand:
initial entry point
attacker activity
affected accounts
stolen information
persistence mechanisms
other compromised devices
Preserve relevant:
logs
alerts
timestamps
suspicious files
sign-in records
ransom notes
security-tool evidence
before destroying compromised environments where practical.
This can also help you avoid restoring systems with the same vulnerability that allowed the attacker in originally.
4. Secure Privileged Accounts
Administrator credentials deserve immediate attention.
The NCSC specifically recommends resetting credentials—particularly administrator and system accounts—during ransomware recovery, while taking care not to lock yourself out of systems needed for recovery.
Review:
domain administrators
Microsoft 365 administrators
backup administrators
hypervisor administrators
firewall accounts
VPN accounts
service accounts
Also review:
MFA registrations
authentication methods
active sessions
recovery accounts
privileged groups
Changing passwords from an infected workstation is not enough.
Perform identity recovery from a trusted environment.
5. Do Not Trust the Existing Windows Installation Automatically
If a system was genuinely compromised, the question should not merely be:
“Can antivirus remove the malware?”
For important systems, a controlled rebuild is often safer.
The NCSC’s ransomware recovery guidance recommends safely wiping infected devices and reinstalling the operating system before restoring clean data.
That gives you a known starting point.
Otherwise you may restore files onto an operating system where:
backdoors remain
scheduled tasks remain
malicious services remain
security exclusions remain
compromised credentials remain
Recovery should restore trust, not simply functionality.
6. Validate Backups Before You Restore Them
This is probably the most important technical recovery step.
Do not assume:
Backup completed successfully = backup is safe.
The attacker may have been present before the ransomware became visible.
Malware or malicious configuration could therefore already exist inside recent backups.
The NCSC specifically advises scanning backups for malware and only restoring where you are confident that both the backup and the device receiving it are clean.
That means you may need to examine several recovery points.
For example:
Yesterday — possibly compromised.
Three days ago — possibly compromised.
Two weeks ago — perhaps clean.
The correct recovery point is not always the newest one.
It is the newest one you can reasonably trust.
7. Restore Into a Clean Environment
This should be a non-negotiable principle.
Do not restore business data onto an environment that may still contain the attacker.
The NCSC explicitly warns that if the attacker has not been evicted, recovery can lead to the incident restarting.
A safer sequence is:
clean infrastructure → patched systems → secured identities → validated backup → restore data
not:
encrypted server → restore files → hope
Where possible, separate recovery systems from the compromised production environment until you are confident they are safe.
8. Restore in Business-Priority Order
Do not necessarily restore systems in the order they appear on the backup console.
Ask:
What does the business need first?
For example:
1. Identity and authentication
2. Core networking
3. DNS
4. Security tooling
5. Critical databases
6. Line-of-business applications
7. File services
8. User endpoints
9. Lower-priority archives
The exact order will differ by organisation.
The important point is that recovery should follow business dependencies.
Restoring a file server first is little use if the authentication infrastructure it depends on is still unavailable.
9. Do Not Reconnect Everything at Once
A staged recovery is safer.
Bring systems online incrementally.
Then observe:
endpoint alerts
identity activity
firewall traffic
DNS behaviour
administrative events
unusual outbound connections
If suspicious behaviour reappears after one system is restored, you have a much smaller environment to investigate.
Reconnecting the entire organisation simultaneously gives an undetected persistence mechanism the opportunity to spread again.
10. Earlier Backup Versions Matter
Ransomware-resistant backup design should make it possible to restore older recovery points even if newer backups become corrupted.
This is one of the NCSC’s explicit principles for both cloud and on-premises backup systems.
That matters because an attacker may remain undetected for a long time.
Imagine:
Day 1: attacker gains access.
Day 4: malicious changes enter backups.
Day 12: data theft begins.
Day 19: ransomware deploys.
If you only retain seven days of backup history, all your available recovery points may already contain attacker activity.
Retention must reflect detection delay, not merely storage cost.
11. Protect the Backup Platform Itself
Ransomware groups understand that backups reduce their leverage.
So backup infrastructure is a target.
The NCSC’s ransomware-resistant backup guidance recommends making backup platforms isolatable, restricting their management interfaces, protecting them from destructive actions and generating alerts when significant or privileged changes occur.
That can include:
network segregation
separate administrative identities
MFA
immutable recovery points
delayed deletion
offline copies
restricted backup-management access
A backup that the compromised Domain Administrator can instantly delete is much less resilient than it appears.
12. Do Not Forget Cloud Backups
Moving data to the cloud does not automatically solve ransomware recovery.
The NCSC explicitly warns that cloud backups also need protection against:
deletion
account lockout
corrupted later versions
privileged compromise
Its cloud-backup principles include ensuring that customers can recover an earlier version even if later versions become corrupted and ensuring one attacker cannot simply deny the organisation all access to the backup service.
This is why:
cloud storage
and:
ransomware-resistant cloud backup
are not necessarily the same thing.
13. Restore Configuration as Well as Data
A business needs more than Word documents to recover.
Important recovery material can include:
firewall configuration
switch configuration
application settings
virtual-machine configuration
encryption keys
certificates
private keys
access tokens
licences
The NCSC specifically recommends ensuring critical system state and external credentials are backed up as well as ordinary business data.
Imagine restoring every file successfully but discovering nobody can recover the encryption key needed by the accounting database.
That is still a failed recovery plan.
14. Fix the Original Entry Point Before Returning to Normal
Suppose the attacker entered through:
unpatched VPN
stolen administrator password
phishing
remote desktop
vulnerable application
You restore every server perfectly.
But you leave that entry point unchanged.
The attacker—or somebody using the same technique—can simply come back.
Before declaring recovery complete:
patch exploited vulnerabilities
close unnecessary remote access
reset compromised credentials
strengthen MFA
review privileged access
correct security misconfigurations
Recovery should make the environment safer than it was before the incident.
15. Data Theft Still Matters After Files Are Restored
Successful restoration does not necessarily end the incident.
If attackers exfiltrated information, the business may still need to determine:
what was accessed
whose data was involved
whether customers need informing
whether regulators need informing
whether contractual notification requirements apply
whether cyber insurers need notification
Modern ransomware commonly combines encryption with data theft and extortion.
So:
“Everything is restored”
does not necessarily mean:
“The incident is finished.”
16. Test the Recovered Systems
Before users return:
Test:
authentication
applications
databases
printing
networking
Microsoft 365 integrations
backup jobs
security agents
monitoring
And critically:
restart systems.
A server that works immediately after restoration but fails after its first reboot is not fully recovered.
Test the actual workflows employees need to perform.
17. Restart Backups Carefully
Once systems return to production, the backup platform needs to resume as well.
But confirm first that:
production is clean
backup infrastructure is clean
credentials have been secured
retention settings are correct
immutability remains enabled
You do not want a freshly recovered production environment immediately overwriting the clean recovery points you just depended on.
Preserve important incident-era recovery points until the organisation is confident the investigation and recovery are complete.
18. Monitor More Aggressively After Recovery
The days and weeks after restoration deserve heightened monitoring.
Watch for:
new administrator accounts
suspicious sign-ins
unusual PowerShell
unexpected scheduled tasks
remote-access tools
backup configuration changes
unusual outbound traffic
security controls being disabled
The new NCSC recovery guidance specifically frames recovery as an ongoing programme rather than a one-time technical event.
That is the right way to think about it.
What Not to Do After Ransomware
Avoid:
restoring immediately without containment
restoring onto infected machines
assuming yesterday's backup is clean
reconnecting every recovered system at once
using compromised administrator credentials
deleting all forensic evidence before understanding what happened
assuming successful file recovery means no data was stolen
rebuilding systems without fixing the original attack path
The objective is not simply:
get the files back.
It is:
restore the organisation without restoring the compromise.
The Ransomware Recovery Order
I would reduce the entire recovery process to this:
1. Contain the attack.
2. Preserve useful evidence.
3. Determine the likely compromise timeline.
4. Secure privileged identities.
5. Evict the attacker and remove persistence.
6. Fix the original entry route.
7. Build known-clean systems.
8. Validate several backup recovery points.
9. Select the newest trusted backup.
10. Restore critical services in dependency order.
11. Reconnect systems gradually.
12. Monitor intensively.
13. Resume protected backups.
14. Complete data-breach and regulatory assessment where required.
15. Review what needs changing before the next incident.
That is much safer than:
wipe → restore yesterday → reconnect everything.
How Hamilton Group Can Help
Ransomware recovery is no longer simply a backup job.
Hamilton Group can help businesses with:
ransomware incident response
containment
Microsoft Defender
identity compromise
Microsoft 365 security
clean Windows/server rebuilds
backup validation
ransomware-resistant backups
immutable storage
data restoration
disaster recovery
business continuity
post-incident hardening
The most important question after ransomware isn't:
“Do we have a backup?”
It is:
“Can we restore that backup into an environment we genuinely trust without reintroducing the attacker?”
Visit hgmssp.com or call 0330 043 0069 to discuss ransomware recovery and cyber security.