Ransomware Recovery and Incident Response (LockBit, Royal, BlackCat, Conti, and Known Families)
Three legitimate recovery paths (clean-backup restoration, published or law-enforcement decryptors, forensic recovery of un-encrypted data) plus containment, attack-vector identification, and cyber-insurance-aligned documentation; we do not recommend paying the ransom.
A ransomware incident is the rare IT emergency where the first hour of decisions matters more than anything that happens afterward, and where the loudest pressure (a countdown timer in the ransom note) is the thing the customer should pay the least attention to. The deadline is a manufactured-urgency tactic; a measured response beats a panicked one every time. What actually determines the outcome is whether clean backups exist somewhere the attacker couldn't reach, whether the family that hit the customer has an available decryptor, and whether the environment gets contained before someone restores clean data into a network the attacker still controls.
MCR Business Tech Solutions runs ransomware recovery and incident response for businesses across Western Pennsylvania, eastern Ohio, the West Virginia panhandle, and western New York. We recover from LockBit, Royal, BlackCat/ALPHV, Conti, Akira, Phobos, REvil/Sodinokibi, and other known and emerging families. The recovery rests on three legitimate paths worked in combination: restoration from verified-clean backups, decryption with published or law-enforcement-released decryptors where the family has one, and forensic recovery of the data the encryption missed (surviving shadow copies, cloud version history, offline media, mail-server data). We do not recommend paying the ransom, and we do not run the engagement around payment as a shortcut.
Containment comes before recovery, always. The threat actor is frequently still on the network when the customer discovers the encryption, with persistence mechanisms and sometimes an exfiltration or re-encryption process still running, so we isolate the environment, identify the encrypted and missed systems, and evict the actor's footholds before restoring anything. Restoring clean data into a compromised environment just hands the attacker a fresh set of files to encrypt. With the environment contained, we identify the family precisely from the ransom-note and file-signature artifacts, triage the backup landscape to find what genuinely survived, and check current decryptor availability for the exact variant before committing to a recovery plan.
Two things run in parallel with the technical work because they are far easier to do during the incident than reconstruct afterward: identifying how the attacker got in so the rebuilt environment closes that door rather than guessing, and producing the documentation a cyber-insurance carrier and any required regulator will need. Western Pennsylvania recoveries we've worked typically land in the 5-to-15-day range depending on environment size and backup posture. We're honest that no reputable practice can guarantee 100% recovery from ransomware; what we commit to is working all three paths exhaustively and giving the customer a realistic recoverability assessment at intake rather than a hope-and-pray engagement.
What's included
Containment First, Before Any Recovery Begins
The first hour of a ransomware incident is about stopping the bleeding, not restoring data, and recoveries that skip containment frequently get re-encrypted partway through. The threat actor is often still present on the network when the customer discovers the encryption, with persistence mechanisms, additional footholds, and sometimes a scheduled re-encryption or a data-exfiltration process still running. Our intake sequence isolates the affected environment from the internet and from unaffected network segments, identifies which systems are encrypted and which were missed, and locates and removes the threat-actor presence (scheduled tasks, new admin accounts, remote-access tooling, persistence in startup and services) before any restoration is attempted. Restoring clean data into an environment the attacker still controls just hands them a fresh set of files to encrypt; containment has to come first.
Path One: Restoration From Verified-Clean Backups
When usable backups exist, restoration is the preferred path because it returns the customer to operation without decryption uncertainty and without engaging the threat actor at all. The critical word is verified: modern ransomware operators specifically hunt for and encrypt or delete backups before triggering the visible encryption, so the existence of a backup is not the same as the existence of a clean backup. We triage the backup landscape to identify which media survived intact (offline backups, immutable cloud backups, air-gapped media, and backups on systems the attacker's credentials couldn't reach are the usual survivors; backups on the same domain and network share as the production environment are the usual casualties), verify the surviving backups are themselves uninfected before restoring from them, and rebuild the environment from the most recent clean restore point. We then close the gap between the last clean backup and the encryption event using the forensic-recovery path where possible.
Path Two: Decryptors for Families With Available Keys
A meaningful number of ransomware families have working decryptors available through legitimate channels, and checking is always worth doing before assuming the encrypted data is lost. The LockBit 3.0 keys were released by international law enforcement in 2024; Conti, REvil/Sodinokibi, GandCrab, Akira (under specific conditions), and a growing list of other families have decryptors published through the No More Ransom project, the FBI, CISA, and vendors like Bitdefender, Kaspersky, Emsisoft, and Avast. We identify the family precisely from the ransom-note artifacts, the encrypted-file extensions and signatures, and the encryption behavior, then check the current decryptor availability for that exact family and variant. When a decryptor exists, we validate it against an isolated copy of a few encrypted files first to confirm it actually works on the customer's specific variant before running it against the full data set, because a wrong-variant decryptor can corrupt files it can't actually decrypt.
Path Three: Forensic Recovery of What the Encryption Missed
Ransomware encryption is rarely as complete as the ransom note claims, and a forensic sweep for un-encrypted copies often recovers more than the customer expects. We check the surfaces ransomware commonly fails to reach: Volume Shadow Copies that survived (some families delete them, many fail to delete all of them or miss copies on secondary volumes), OneDrive, SharePoint, and Google Drive version history (cloud platforms retain prior versions that can be rolled back even after the local files were encrypted and synced), files on disconnected or offline media the attacker's network access couldn't reach, email and attachments still sitting on the mail server, and cold-storage archives. This path frequently bridges the gap between the last clean backup and the encryption event, recovering the most recent work that a backup-only restore would lose.
Attack-Vector Identification So It Doesn't Happen Again
Recovering the data without finding how the attacker got in just resets the clock until the next incident, often by the same actor through the same door. As part of the recovery we identify the initial access vector (the standard candidates: a compromised RDP or VPN credential, an exposed remote-access port, a phishing email that delivered a loader, an unpatched internet-facing vulnerability, a compromised managed-service or supply-chain connection), trace the lateral movement and privilege escalation the attacker used, and document the timeline. The customer comes out of the engagement with a written account of how the breach happened and a prioritized remediation list (MFA on remote access, RDP off the public internet, the specific patch that was missing, the credential that was exposed) so the rebuilt environment closes the door the attacker actually used rather than guessing.
Cyber-Insurance and Regulatory Documentation as Part of the Work
A ransomware incident usually triggers obligations beyond the technical recovery, and the documentation those obligations require is far easier to produce during the incident than reconstructed afterward. If the customer carries cyber-insurance, the carrier has notification deadlines, approved-vendor requirements, and evidence expectations that the recovery has to be run against from the start; we coordinate with the broker and carrier in parallel with the technical work and document the incident to their requirements. Where the breach involved protected data (PHI under HIPAA, personal information under state breach-notification laws, payment-card data under PCI), the regulatory notification obligations turn on findings the forensic work produces (what data was accessed, whether it was exfiltrated, how many records). We document the incident timeline, the affected data, the containment and recovery actions, and the attack vector in a form the customer's counsel, carrier, and any required regulator can rely on.
Why businesses choose MCR
Containment and Threat-Actor Eviction Before Any Restore
The actor is often still present when encryption is discovered, with persistence and sometimes exfiltration still running. We isolate the environment, map the encrypted versus missed systems, and remove the actor's footholds (scheduled tasks, rogue admin accounts, remote-access tooling, persistence) before restoring anything, because restoring into a compromised network just gets re-encrypted.
Three Legitimate Recovery Paths Worked in Combination
Restoration from verified-clean backups (verified, because modern actors hunt and encrypt backups first), decryption with published or law-enforcement decryptors validated against an isolated copy before full use, and forensic recovery of what the encryption missed. We combine all three: bulk restore from the cleanest backup, decrypt where it works, and forensically recover the gap to the encryption event.
We Do Not Recommend Paying the Ransom
In line with FBI and CISA guidance: payment funds the next attack, decryption is unreliable even when the actor cooperates, double-extortion on retained stolen data is common, and OFAC sanctions language leads many carriers to decline ransom-payment claims. We work the legitimate paths exhaustively rather than treating payment as a shortcut.
Attack-Vector Identification and Carrier-Ready Documentation
Recovering data without finding the entry point just resets the clock. We trace the initial access vector and lateral movement, document the timeline, and hand over a prioritized hardening list tied to what actually happened, plus incident documentation in a form the customer's cyber-insurance carrier, counsel, and any required regulator can rely on.
Getting started
Containment, Scoping, and Family Identification
Isolate affected systems from the internet and unaffected segments without indiscriminate wiping (encrypted drives and system state are evidence). Identify which systems are encrypted and which were missed, locate and remove the threat-actor presence, and preserve the ransom note and encrypted-file samples to identify the family and variant precisely. Coordinate cyber-insurance notification if the customer carries a policy, since carriers often dictate approved responders.
Backup Triage, Decryptor Evaluation, and Forensic Sweep
Triage the backup landscape to find verified-clean restore points the attacker couldn't reach, confirming the backups are themselves uninfected before use. Check current decryptor availability for the exact family/variant and validate any decryptor against an isolated sample before full use. Forensically recover what the encryption missed: surviving shadow copies, OneDrive/SharePoint/Google Drive version history, offline media, and mail-server data.
Rebuild, Attack-Vector Remediation, and Documentation
Rebuild the environment from the combination of clean backups, successful decryption, and forensic recovery. Identify and close the initial access vector (compromised RDP/VPN credential, exposed remote access, phishing, unpatched system, vendor connection) and deliver a prioritized hardening list. Produce incident documentation (timeline, affected data, containment and recovery actions, attack vector) for the carrier, counsel, and any required regulatory notification.
Frequently asked questions
We got hit overnight, files across our server have a weird extension and there's a ransom note in every folder. The note demands payment in 72 hours. What do we do in the first hour, and should we pay?
First, do not pay, and do not start the clock-driven panic the 72-hour deadline is designed to create; that deadline is a pressure tactic, and a measured response in the first hour matters far more than the countdown. The standing guidance from the FBI, CISA, and every reputable recovery practice including ours is to not pay the ransom: payment funds the next attack, decryption results are unreliable even when the actor cooperates, many actors retain a copy of stolen data and return months later to extort again, and under current OFAC sanctions language a number of cyber-insurance carriers now decline ransom-payment claims outright. The first-hour actions: (1) Isolate, don't shut down indiscriminately. Disconnect affected systems from the network and the internet to stop spread and stop any exfiltration still running, but don't wipe or reimage anything yet, the encrypted drives and the system state are evidence and may be recoverable. (2) Identify scope: which systems are encrypted, which were missed, whether backups are reachable from the affected network. (3) Photograph or save a copy of the ransom note and a few encrypted file samples; these identify the family and determine whether a decryptor exists. (4) If you carry cyber-insurance, notify the carrier now, before engaging vendors, because most policies require it and may dictate approved responders. (5) Call us at 833-859-9021. We contain the incident, evict the actor, identify the family, check decryptor availability, triage your backups, and work the three legitimate recovery paths. Do not delete the ransom note or reimage machines before the family is identified and the recovery path is chosen.
Our backup vendor says some of our backups got encrypted too. Does that mean we've lost everything that wasn't backed up to a clean copy?
Not necessarily, and the encrypted-backups situation is common precisely because modern ransomware operators specifically target backups before they trigger the visible encryption. The recovery doesn't depend on backups alone. First, 'some backups encrypted' usually means some survived: offline backups, immutable or object-locked cloud backups, air-gapped media, and backups on systems the attacker's stolen credentials couldn't reach are the typical survivors, and we triage the full backup landscape to find the clean restore points rather than taking the vendor's first assessment as final. Second, even where the most recent backups were hit, the family may have an available decryptor (LockBit 3.0, Conti, REvil, and others have law-enforcement or vendor decryptors), which we check against your specific variant. Third, the forensic-recovery path frequently recovers what neither backups nor decryption cover: Volume Shadow Copies the ransomware missed, OneDrive and SharePoint version history that retains pre-encryption versions even after the encrypted files synced, files on disconnected media, and data still on the mail server. In practice we combine all three: restore the bulk from the cleanest surviving backup, decrypt where a decryptor works, and forensically recover the gap between the last clean backup and the encryption event. The combination usually recovers far more than a backup-only assessment suggests.
How long does ransomware recovery take, and can you guarantee you'll get our data back?
Recovery timelines for the Western Pennsylvania businesses we've worked land in the 5-to-15-day range for a typical environment, driven mostly by the environment's size, the backup posture going in, and which recovery path the situation supports. A customer with a clean immutable backup and a contained blast radius can be substantially back in days; a customer whose backups were encrypted, who needs decryptor-based recovery on a large data set, and whose environment has to be rebuilt from the ground up sits at the longer end. We're honest about guarantees: no reputable recovery practice can guarantee 100% recovery from ransomware, because the outcome depends on factors fixed before we arrived (whether clean backups exist, whether the family has a decryptor, whether shadow copies and cloud version history survived). What we can commit to is working all three legitimate paths exhaustively, giving the customer an honest probability assessment at intake rather than a hope-and-pray engagement, and never recommending the ransom payment as a shortcut. The intake assessment, after we've identified the family and surveyed the backup and forensic landscape, gives the customer a realistic picture of how much is recoverable and through which path before the engagement is authorized.
Once we're recovered, how do we keep this from happening again, and is that part of what you do?
Identifying how the attacker got in and closing that door is part of the recovery engagement, not a separate upsell, because recovering the data without fixing the entry point just resets the clock until the next incident. As part of the work we trace the initial access vector (the usual candidates are a compromised RDP or VPN credential, RDP exposed directly to the internet, a phishing email that delivered the initial loader, an unpatched internet-facing system, or a compromised vendor/remote-management connection), reconstruct how the attacker moved laterally and escalated privileges, and document the timeline. The customer leaves the engagement with a written account of the breach and a prioritized hardening list tied to what actually happened. The standard post-incident hardening that prevents the large majority of repeat attacks: phishing-resistant MFA on every remote-access and privileged account, RDP off the public internet behind a VPN or zero-trust gateway, EDR with SOC-attached alerting replacing signature-only antivirus, immutable or air-gapped backups the next attacker can't reach, DNS filtering, prompt patching of internet-facing systems, and documented employee security-awareness training. For customers who want it, we provide that hardening as part of our managed security and proactive-monitoring service so the rebuilt environment is materially harder to hit than the one that went down.
Ready to get started?
Book an assessment and find out what MCR can do for your business.