Editor’s Note: This article was originally published in November 2021 and has been substantially updated to reflect current ransomware recovery guidance, including securing administrative access, validating backups and restoring services without reintroducing attacker access.
A successful restore can return compromised systems to service. Backup selection, identity recovery and reconnection decisions determine what comes back with them.
Recovering from a ransomware attack requires removing the attacker’s access before restored services become reachable again. Reinstalling servers and recovering files will not resolve stolen credentials, unauthorized accounts, or compromised management systems that could let an intruder control the rebuilt environment.
The recovery plan must establish which infrastructure is trustworthy, which backups are usable, and what evidence is required before each service returns to production. Containment, investigation and recovery planning proceed together, with investigation findings controlling what can safely reconnect.
Contain the attack and preserve evidence
Isolate affected systems immediately. Where multiple systems or subnets are involved, coordinated network isolation may be necessary. Include wireless connections and remote-access paths. Use a separate, trusted communication channel to coordinate the response if corporate email or collaboration accounts may be compromised.
Network isolation limits further spread but does not stop encryption already running on a host. Responders must also stop identified ransomware processes.
Avoid indiscriminate shutdowns. Disconnecting a host preserves volatile evidence that powering it off destroys. The joint federal StopRansomware guide recommends powering down affected devices when network disconnection is not possible and shutdown is needed to prevent further spread.
Have responders preserve relevant logs, ransom notes, encrypted samples and selected system images and memory captures before rebuilding. Record containment actions and their timing so investigators can distinguish defensive changes from attacker activity.
Activate the incident response team and involve business owners, legal counsel and the insurer where applicable. In the United States, report ransomware to the FBI through its Internet Crime Complaint Center or a local field office. Do not wait until recovery is complete.
Scope the intrusion beyond encrypted machines
The encryption event does not establish when the intrusion began or how far it reached. Review identity, VPN, endpoint, firewall and cloud audit records to identify the entry point, compromised accounts and systems accessed before encryption.
Include domain controllers, virtualization management, backup consoles and remote administration systems in the assessment. A server without encrypted files may still be compromised. Endpoint detection and response provides host telemetry, but it does not replace investigation of identity services, network appliances or cloud administration.
Close the identified entry route and investigate persistence, including unauthorized accounts and unexpected remote-management tools. Where evidence is incomplete, document the uncertainty and restrict the affected environment accordingly. An absence of alerts is particularly weak evidence when logging was disabled or records have expired.
Recover trusted administration
Perform recovery administration from devices built from trusted sources. Reusing a compromised administrator workstation can expose replacement credentials as soon as they are entered.
During containment, disable compromised accounts and revoke supported sessions and tokens. Coordinate subsequent credential rotation with removal of attacker persistence. Changing passwords while the attacker still controls the identity infrastructure can leave the replacement credentials exposed.
Review more than user passwords. Depending on the intrusion, recovery may require rotating service-account secrets, application credentials and certificates; removing unauthorized application permissions; and correcting attacker-added authentication methods. Verify privileged roles and group membership before restoring access.
If Active Directory or a federated identity system was compromised, use a platform-specific compromise recovery plan. Directory recovery and signing-key changes affect dependent services and require deliberate sequencing. A general password reset cannot establish that the identity system is trustworthy.
Select backups against the intrusion timeline
A backup taken before encryption may still contain attacker tools or altered configuration. Compare candidate recovery points with the earliest evidence of compromise, recognizing that the first recorded malicious event may not be the actual entry time.
Restore candidates into an isolated validation environment. Investigate their contents, scan for malware and test application behavior before approving them. A successful backup job establishes neither that the captured system was clean nor that the application can recover.
Immutable storage protects retained recovery points against modification or deletion under its configured controls. It does not remove malicious content captured before the backup was written. Separately assess the trustworthiness of backup administration and the availability of required recovery keys.
If the latest defensible recovery point is older than the business can comfortably accept, make the resulting data-loss decision explicit. Identify records that can be reconstructed from independent sources, and plan how transactions created during temporary operations will be reconciled.
Rebuild behind an enforced boundary
Rebuild compromised systems from trusted installation media or validated images, and apply relevant security fixes before granting production access. Restoring an entire machine image also restores its configuration and software, including anything malicious present when it was captured.
Keep the recovery environment separated from the compromised estate. A dedicated VLAN is insufficient if routing, shared administration or remote-support systems preserve access across the boundary. Test which systems can reach recovery hosts and through which management paths.
Allow only the connections required for recovery and validation. Record the purpose, owner and review point for temporary exceptions. Undocumented application dependencies create pressure to broaden access when services fail to start; investigate the missing dependency before opening communication between entire segments.
Restore services in dependency order
Prioritize business functions and map the services each requires. A restored application may still be unusable without trusted authentication, DNS, databases, certificates or external integrations. Recovery order should reflect those dependencies and the consequences of continued downtime.
Define acceptance criteria before reconnecting a service:
- Responders have addressed identified access and persistence mechanisms affecting the service.
- The selected recovery data and application configuration have passed validation.
- Responders have reviewed and remediated required credentials and permissions.
- Logging and security monitoring are operating and visible to responders.
- The service owner has tested essential workflows and has a defined procedure to isolate the service again if suspicious activity appears.
Reconnect in controlled stages and monitor for renewed suspicious authentication, administrative changes and unexpected connections. Keep unresolved systems quarantined. Partners may also require evidence of remediation before restoring their connections.
Separate decryption from incident recovery
Free decryptors exist for some ransomware families and versions. Check the No More Ransom project and consult responders or law enforcement about applicability. Preserve the original encrypted files and test an appropriate tool on copies before using it more widely.
The FBI does not support paying a ransom, and payment does not guarantee data recovery. Even a working decryptor leaves the investigation, removal of attacker access and rebuilding work to be completed.
Investigate data theft alongside service recovery. Restoring a database does not retrieve copies an attacker has already taken. Legal and communications teams must assess notification obligations and extortion exposure independently of whether operations have resumed.
Make the next recovery test harder
Use the incident to test whether recovery can succeed when production identity, administrative workstations and the primary backup console are unavailable. Measure the time needed to restore a usable business service, including validation and dependency recovery. That exercise exposes weaknesses a file-restore test cannot: inaccessible credentials, missing configuration, untrusted management paths and decisions nobody has authority to make.
Sources
- CISA, NSA, FBI and MS-ISAC: StopRansomware guide
- Microsoft: Ransomware incident response approach
- Microsoft: Recovery from systemic identity compromises
- Microsoft: Compromised identity response procedures
- Microsoft: Ransomware-resilient backup architecture
- NCSC: Recovery and ongoing investigations
- FBI: Ransomware reporting and ransom guidance
- No More Ransom: Decryption resources
About NetworkTigers
NetworkTigers is the leader in the secondary market for Grade A, seller-refurbished networking equipment. Founded in January 1996 as Andover Consulting Group, the company originally built and re-architected data centers for Fortune 500 firms. Today, NetworkTigers provides consulting and network equipment to global government agencies, Fortune 2000 companies, and healthcare companies. Visit www.networktigers.com
