Ransomware Recovery Steps: 8 Actions [Solved]

Action 1: Immediate Network Isolation

Pull the network cable. Disable wireless. The first goal is stopping lateral movement, not preserving uptime.

Modern ransomware scans the local network for file shares, backup repositories, and domain controllers. Variants like Ryuk and Conti move laterally within 20-40 minutes of initial compromise. If the infected system stays online, encryption spreads.

Physical disconnection beats firewall rules because the attacker may already have admin access to modify firewall configs. In virtualized environments, disable the virtual NIC at the hypervisor level rather than inside the guest OS.

Trade-off: Isolation breaks active connections and stops legitimate services. For production servers, this causes immediate downtime. The alternative—leaving systems connected while you investigate—risks losing every server and backup target in your network.

• Physical servers: unplug Ethernet cable, disable WiFi adapter in BIOS if present
• Virtual machines: detach virtual network adapter from hypervisor console
• Cloud instances: remove from security groups and VPC subnets via provider console
• Document time of isolation and which systems remain connected

Action 2: Forensic Snapshot vs. Immediate Shutdown

If the system is still running when you discover the infection, you face a choice: take a memory dump and preserve volatile evidence, or power off immediately to stop encryption in progress.

Memory dumps capture loaded malware, encryption keys, and active network connections that disappear on shutdown. Forensic teams need this data to identify attack vectors and build timelines. But capturing a memory dump takes 5-30 minutes depending on RAM size, and encryption continues during collection.

For servers with irreplaceable data still being encrypted, shut down immediately. For systems where encryption already finished, or where you need to understand how the attacker got in, take the memory dump first.

Disk imaging comes next. Use a live boot USB with forensic tools (CAINE, Paladin) to capture a bit-for-bit copy without mounting the filesystem. Write the image to external storage, never to another volume on the infected system. Hash the image with SHA-256 and store the hash separately.

• Active encryption in progress: hard power off to stop damage
• Encryption finished, system stable: capture memory dump with tools like LiME (Linux) or DumpIt (Windows)
• Create disk image with dd, FTK Imager, or dcfldd before any filesystem modifications
• Verify image integrity with checksums; store original media as evidence

Action 3: Backup Verification and Offline Scanning

Check your backups before assuming they're safe. Ransomware attacks often include a reconnaissance phase where the attacker locates and corrupts backup files.

Mount backup media on an isolated system—one that has no network connection and isn't part of your production environment. Check file timestamps. If backup files were modified during the infection window, assume they're compromised.

Scan every backup file with updated antivirus definitions. Some ransomware variants encrypt backup archives but leave the container file structure intact, so size checks alone aren't sufficient. Extract a few test files, open them in safe viewers, and confirm they're readable.

Compare backup dates against your infection timeline. If you discovered ransomware today but the attacker gained access two weeks ago, last night's backup may already contain malware. You might need to restore from a backup that predates the initial compromise, which means accepting data loss for recent changes.

Action 4: Decryption Attempt vs. Restore Decision

Free decryption tools exist for some older ransomware families. Check the No More Ransom project database and vendor security sites (Kaspersky, Avast, Emsisoft) for decryptors matching your ransom note.

Decryption rarely works. Tools exist for fewer than 15% of active ransomware families, and attackers update encryption methods every few months to break existing decryptors. Even when a decryptor exists, success rates are inconsistent—file corruption during decryption is common.

Compare time costs: decryption attempts take 6-24 hours for moderately sized datasets, and you won't know if it worked until completion. Restoring from backup takes 1-4 hours depending on data volume and transfer speed. For business environments, restoration is almost always faster and more reliable.

If backups don't exist and no decryptor is available, the data is gone. At that point you're deciding between paying ransom (which I don't recommend) or accepting data loss and rebuilding.

• Search No More Ransom and vendor sites using exact ransomware family name from ransom note
• Test decryptor on 3-5 non-sensitive files before attempting full decryption
• Run decryption on a copy of encrypted data, never on the only remaining copy
• Set a 12-hour decision window; if decryption isn't working by then, switch to restoration

Action 5: Root Cause Analysis and Entry Point Identification

You can't safely restore systems until you know how the attacker got in. The entry point must be closed or they'll re-encrypt everything within days.

Common entry points: RDP exposed to the internet with weak passwords, unpatched VPN appliances, phishing emails with macro-enabled documents, and compromised third-party vendor access. Check authentication logs, web server access logs, and email gateway logs for suspicious activity in the 7-14 days before encryption started.

In support tickets I handled, the usual culprit was exposed RDP on port 3389 with local admin accounts using passwords under 12 characters. Attackers brute-force these in under 48 hours. The second most common entry was unpatched vulnerabilities in internet-facing web applications.

Finding the entry point is detective work. Look for new user accounts created in the week before the attack, scheduled tasks that weren't there before, and unfamiliar executables in temp directories. If you're not experienced with forensic analysis, this is when you call in a security consultant or incident response firm.

Action 6: Credential Reset and Access Revocation

Change every password, API key, service account credential, and SSH key in your environment. The attacker may have harvested credentials from memory, registry hives, or configuration files during their reconnaissance phase.

Start with administrative accounts, then service accounts, then end users. Revoke all active sessions in your identity provider. Regenerate API tokens for monitoring tools, backup services, and third-party integrations.

Don't reuse old passwords with minor modifications. Attackers maintain credential databases from previous compromises. Use a password manager to generate unique 20+ character passwords for each account.

For SSH access, regenerate all keypairs and remove old authorized_keys entries. Check for unauthorized keys that might have been added during the compromise.

• Reset domain admin and local administrator passwords first
• Regenerate service account credentials and update application configs
• Revoke all active API tokens and issue new ones
• Force password reset for all user accounts via identity provider
• Rotate SSH keys and remove unrecognized entries from authorized_keys files

Action 7: Clean Rebuild vs. In-Place Remediation

Two approaches: rebuild from a known-good base image, or attempt to remove malware from the infected system. Rebuild is cleaner. In-place remediation is faster.

Rebuild means wiping the infected system completely, reinstalling the OS from verified installation media, and restoring only data files from backup. You lose any configuration changes made since the last infrastructure-as-code commit or manual documentation, but you're certain no malware persistence mechanisms remain.

In-place remediation means scanning with antivirus tools, removing identified malware, and checking for persistence mechanisms manually. Faster for single systems, but you can't be sure you found everything. Rootkits and bootkit-level persistence often survive antivirus scans.

For production servers and any system that had admin-level compromise, rebuild. For workstations with limited access that were caught early, in-place remediation might be acceptable if followed by intensive monitoring.

After rebuild, restore application data and configs from backup. Don't restore system directories, executables, or registry hives—those should come from fresh installation only. Restore databases by replaying transaction logs against a clean instance rather than copying binary database files.

Action 8: Isolated Testing and Monitored Restoration

Don't put rebuilt systems directly back into production. Set up an isolated network segment—a separate VLAN or VPC with no route to your main network—and run restored systems there for 48-72 hours.

During this quarantine period, monitor for signs the attacker's persistence mechanisms survived. Watch for unexpected outbound connections, new scheduled tasks appearing, or unauthorized processes. Check authentication logs for login attempts with old credentials that should no longer work.

Run vulnerability scans against restored systems. The same unpatched vulnerabilities that allowed initial entry will allow re-entry. Prioritize patches for remote code execution flaws and authentication bypass issues.

After 48 hours of clean operation with no suspicious activity, gradually restore network connectivity. Start with one system. Monitor for 24 hours. If clean, proceed with the next. Stagger the restoration to contain damage if the attacker left behind a time-delayed payload.

• Create isolated test network segment with no routing to production
• Run restored systems for 48-72 hours with full logging enabled
• Monitor authentication logs, process creation, and network connections
• Perform vulnerability scan and apply all available security patches
• Restore production connectivity one system at a time with 24-hour monitoring gaps

Comparing Recovery Approaches: Speed vs. Forensics

The eight actions above form a complete recovery workflow, but real incidents require prioritization based on your constraints.

Speed-first approach: immediate isolation, skip forensics, restore from last known-good backup, rebuild systems without root cause analysis, return to production within 12 hours. Risk: attacker returns through the same entry point within days. Use this only for small environments without compliance requirements where downtime costs exceed re-infection risk.

Forensics-first approach: preserve all evidence, hire incident response firm, perform complete root cause analysis, document every action, restore after full investigation. Timeline: 1-3 weeks. Required for regulated industries, recommended for any organization that needs to understand what data was accessed or must report the incident to authorities.

Balanced approach: isolate immediately, take quick forensic snapshots, begin restoration from backup while forensic analysis runs in parallel, apply obvious fixes (patch RDP, disable exposed services) before returning to production. Timeline: 48-96 hours. This works for most small to medium environments.

The recommendation: use the balanced approach unless you have specific reasons not to. Skipping forensics entirely means you'll likely face the same attack again. Delaying recovery for a full forensic investigation costs more in downtime than the additional security insight provides for most organizations.

Long-Term Prevention After Recovery

Recovery is not the end. Post-incident hardening prevents the next attack.

Implement network segmentation so ransomware can't spread laterally. Put backup systems on a separate network with one-way replication. Use immutable backups that cannot be modified or deleted for a set retention period. Test backup restoration monthly, not after an incident starts.

Close the entry point permanently. If RDP was exposed, move it behind a VPN or remove external access entirely. If phishing was the vector, deploy email filtering and user training. If an unpatched vulnerability was exploited, establish a formal patch management process with SLAs.

Enable comprehensive logging and ship logs to an external SIEM or log management service. Ransomware operators often delete local logs to hide their tracks. Logs stored off-system survive and provide the evidence needed for forensic analysis.

Schedule a tabletop exercise 90 days after recovery. Walk through the incident timeline with your team, identify what worked and what didn't, and update your incident response plan based on lessons learned. The best time to fix your response process is when the incident is still fresh, not when the next attack hits.