Ransomware: Beyond Encrypted Files

Lessons from 2016–2026, hidden data theft, recovery opportunities, and practical preparation

An organization discovers that its servers have stopped working. Documents no longer open, databases are unavailable, and virtual machines refuse to start. A ransom note promises that everything can be restored after payment.

The immediate question is understandable: “How do we get our files back?”

But that is only one part of the incident. Were passwords stolen before encryption began? Did the attackers copy confidential information? Can they still access the network? Are the backups genuinely independent of the compromised environment? Is the “decryptor” itself safe?

A successful response must address three separate objectives: stop further damage, recover usable data, and restore trust in the environment.

This article examines how ransomware evolved, what major incidents have taught us, why some victims recover without paying, and why recovering files does not necessarily mean the compromise is over.

Figure 1. A ransomware incident can affect confidentiality, availability, identity, operations, and confidence in the rebuilt environment—not only files.

---

1. From Early Extortion to Organized Ransomware Operations

Ransomware predates modern cloud infrastructure and cryptocurrency. The 1989 AIDS Trojan, also known as PC Cyborg, is widely recognized as the first known ransomware. Later families adopted stronger cryptography, and CryptoLocker in 2013 helped establish the modern model of encrypting valuable files and demanding payment for recovery. (No More Ransom)

The business model also changed. Under Ransomware-as-a-Service, or RaaS, developers provide malware and supporting infrastructure, while affiliates conduct intrusions and deploy the ransomware. Different participants may therefore handle initial access, intrusion operations, encryption, and negotiations. The UK National Crime Agency’s investigation into LockBit documented this affiliate-based model. (National Crime Agency)

For defenders, the implication is important: removing the final encryptor may not remove everything the attackers installed or invalidate every account they compromised.

Selected incidents: 2016–2026

The following examples illustrate different kinds of harm. Ransom payments, recovery expenditure, business interruption, projected profit impacts, and affected-person counts are not interchangeable. The figures retain the meaning and reporting dates given by their sources.

Figure 2. The timeline summarizes selected milestones. The detailed table below preserves the source, metric, and limitation for each example.

The common lesson is not simply that ransom demands can be expensive. An organization must also account for interrupted services, investigation, rebuilding, lost productivity, customer harm, and damaged confidence.

---

2. Double Extortion: Why Backups Do Not Solve Every Problem

Traditional encryption-based ransomware creates an availability problem: the victim cannot use its data.

Double extortion adds a confidentiality problem. Attackers steal information and then encrypt systems, demanding payment both for decryption and for a promise not to publish the stolen data. Some operations skip encryption entirely and rely on data theft and disclosure threats alone. (CISA)

Consequently, restoring from a clean backup does not retrieve the attacker’s copy of the data.

The 2022 Medibank breach illustrates the harm associated with stolen information. Australia’s privacy regulator described a breach affecting approximately 9.7 million individuals, with personal information subsequently released on the dark web. This is an example of data-theft harm; it should not automatically be described as proof that the affected systems were encrypted. (Office of the Australian Information Commissioner)

Payment does not prove deletion, either. During its 2024 LockBit investigation, the National Crime Agency found that the operation retained data belonging to victims who had paid. (National Crime Agency)

An investigation must therefore ask two independent questions:

Can the organization recover its data?

What information did the attackers obtain, and what continuing risks does that create?

A threat actor’s statement that “all data has been deleted” is not a substitute for evidence.

---

3. The Attack May Begin Before the Ransom Note Appears

The first visible ransom note is not necessarily the beginning of the intrusion.

Figure 3. The ransom note is often a late-stage symptom. Not every incident follows every step, and observed sequencing must come from incident-specific evidence.

An attacker may first obtain access, compromise additional accounts, increase privileges, and move between systems. By the time encryption begins, the incident may involve administrative infrastructure rather than a single infected workstation. NCSC guidance on lateral movement explains why privileged accounts and access between systems are central to this risk. (NCSC)

A useful investigation model is:

Initial access → account and privilege compromise → discovery → data theft or backup interference → encryption and extortion

This is a model, not a mandatory sequence. Actual operations differ.

Investigators should also distinguish observations from conclusions. For example, thousands of failed login attempts establish that authentication attempts occurred. They do not, by themselves, prove that a successful brute-force attack caused the compromise.

The successful access event must be correlated with the account, source, authentication method, timestamp, and subsequent activity. Otherwise, an exposed vulnerability, stolen session, or compromised administrator account may be overlooked.

---

4. STOP/DJVU: Encryption May Be Only One Payload

STOP/DJVU deserves particular attention because some documented infections involved additional information-stealing malware.

AZORult accompanying STOP

In March 2019, BleepingComputer tested a STOP/Promorad variant and observed it installing AZORult, an information-stealing Trojan associated with theft of browser credentials, cryptocurrency-wallet information, and other sensitive data. (BleepingComputer)

Vidar accompanying STOP/DJVU

Quick Heal’s analysis documented a STOP/DJVU payload downloading Vidar while obtaining its personal identifier and public key. The observed Vidar component collected browser login information, cookies, history, and data associated with other applications. (Quick Heal)

These findings do not mean every STOP/DJVU infection contains both malware families. They show that information theft can occur before or alongside file encryption, depending on the campaign and sample.

This changes the recovery priorities.

Decrypting documents does not invalidate a stolen password. Reinstalling Windows does not automatically terminate a session established on another device. A restored browser profile is not evidence that the accounts used through that browser are secure.

From a clean device, affected users and administrators should address compromised credentials and sessions, not merely the encrypted files. Microsoft’s incident-access guidance illustrates why password resets, token revocation, device access, and application-managed sessions may require separate actions. (Microsoft Learn)

An infostealer infection and double extortion are also different findings. Evidence of credential theft does not automatically establish that the same attacker threatened to publish business documents.

---

5. Malware INFO Research Finding: An Infostealer Inside a Paid Decryptor

Malware INFO Research Team finding

>

According to the Malware INFO Research Team, an information stealer was discovered inside a STOP/DJVU decryptor supplied after a victim paid the ransom.

>

Source: Malware INFO Research Team, internal research finding. This observation concerns the decryptor examined by the team and should not be generalized to every STOP/DJVU decryptor.

This creates an additional risk: a victim may run an attacker-supplied program while attempting to recover, potentially exposing information again during an already vulnerable period.

A tool’s ability to decrypt files does not establish that decryption is its only function. Nor does paying for it turn software supplied by criminals into trusted software.

This finding must be distinguished from a separate, publicly documented threat: fake decryptors. In 2020, Zorab masqueraded as a STOP/DJVU recovery tool but instead encrypted victims’ files again. NHS Digital documented the behavior, and Emsisoft released a Zorab-specific decryptor. (NHS Digital)

The practical rule is straightforward:

Treat an attacker-supplied decryptor as untrusted code, even when it appears to work.

Have a qualified analyst examine it. Test only against copies in an isolated recovery environment without production credentials or unnecessary network access. Do not run it directly on a backup server, domain controller, administrator workstation, or the only remaining copy of important data.

A small demonstration that successfully restores a few files proves neither complete recovery nor software safety.

---

6. Knowing the Encryption Algorithm Is Not the Same as Having the Key

An analyst may identify AES, Salsa20, ChaCha20, RSA, or another cryptographic component. That is useful, but it does not automatically make decryption possible.

For example, Quick Heal’s examined STOP/DJVU variant used Salsa20 for file data and RSA-2048 to protect the associated key material. Finding the public key used in that process does not provide the corresponding private key. (Quick Heal)

The relevant questions extend beyond the algorithm’s name:

• How are keys generated, stored, transmitted, and erased?
• Are keys or nonces incorrectly reused?
• Does the sample contain fixed keys or predictable randomness?
• Which file ranges are actually encrypted?
• What metadata is stored in headers, footers, configuration files, or memory?
• Does the implementation contain a recoverable mistake—or irreversible corruption?

A filename extension is not enough to answer these questions. Nor is a ransom note’s claim that “military-grade encryption” was used.

The objective of malware analysis is to establish what this particular implementation did—not what the attacker says it did.

---

7. Ransomware Characteristics That Can Create Recovery Opportunities

Some recoveries result from cryptographic weaknesses. Others result from deliberate shortcuts that leave portions of files untouched. These are different mechanisms.

7.1 Limited-prefix encryption: sometimes only the first 1–2 MB

Some ransomware encrypts only the beginning of a file rather than every byte.

ESET documented that TorrentLocker encrypted the first 2 MB of files in its 2014 implementation, while later variants examined in its 2016 research reduced this to the first 1 MB. These were variant-specific behaviors, not a universal ransomware limit. (ESET / WeLiveSecurity)

The distinction matters enormously for a large container file.

Consider a hypothetical 100 GiB virtual-disk image whose first 2 MiB were encrypted while the remaining bytes were unchanged:

Encrypted prefix | Large remaining region containing unchanged data

The virtual machine may no longer start, and the image may no longer open normally. Yet a substantial amount of underlying data might still exist.

However:

A large proportion of unchanged bytes does not guarantee a similarly large proportion of recoverable files.

The encrypted prefix may contain metadata needed to interpret everything that follows. Recovery depends on the file format, allocation structures, compression, fragmentation, and exact affected offsets.

The “2 MB” example must never be turned into advice that large backups are automatically safe or that making files larger protects them.

7.2 Intermittent and size-dependent encryption

Figure 4. Encryption coverage is sample- and variant-specific. Unchanged regions can support careful recovery work, but unchanged bytes do not guarantee a usable file or complete recovery.

Other ransomware encrypts selected regions or changes behavior according to file size.

For example, Check Point’s 2025 analysis of a VanHelsing sample described full encryption for smaller files and encryption of the first 30% for files at or above a specified large-file threshold. This demonstrates that encryption coverage can be determined by the examined build’s rules rather than by a simple “all or nothing” model. (Check Point Research)

An analyst should therefore map the actual encrypted ranges across several files and sizes. Examining only the beginning and end of one file does not establish what happened throughout its middle.

Partial encryption is generally an operational shortcut, not necessarily a flaw in the cipher. It can make data unusable without processing every byte.

7.3 Cryptographic mistakes

Some implementations genuinely make recoverable mistakes.

These examples justify careful analysis. They do not justify promises that every ransomware family can be broken.

7.4 Offline keys and subsequently recovered keys

Emsisoft’s STOP/DJVU decryptor can help in supported circumstances, including files encrypted with an offline key when the corresponding key is available to Emsisoft. Its documentation distinguishes older variants from “New Djvu” variants appearing after August 2019. (Emsisoft)

“Offline key” does not mean “offline backup.” Disconnecting an already encrypted computer does not convert its existing encryption into a recoverable offline-key case.

Other recovery opportunities arise when law enforcement obtains attacker-held keys. In its 2024 LockBit operation, the NCA reported obtaining more than 1,000 decryption keys. (National Crime Agency)

Preserving encrypted originals and their metadata therefore remains worthwhile, even when no suitable recovery tool is currently available.

7.5 Some ransomware destroys rather than encrypts

An especially dangerous mistake is confusing these two behaviors:

“Only the first 2 MB of a large file were encrypted.”

“Files larger than 2 MB were overwritten with meaningless data.”

They are not remotely equivalent.

The legacy Onyx ransomware examined in 2022 was reported to overwrite larger files rather than preserve them as decryptable ciphertext. That behavior should not be attributed to an unrelated sample merely because it also uses the name “Onyx” or a similar extension. (BleepingComputer)

If original bytes were destroyed rather than reversibly encrypted, possessing an encryption key will not recreate them.

---

8. What Partial Encryption Means for Archives, Backups, and Virtual Disks

Archives: some entries may survive, but compression changes the outcome

A ZIP archive normally contains separately described file entries, including local headers and associated file data. Consequently, when damage is limited to a particular region, later intact entries may offer a recovery opportunity—provided their structures and compressed data can be located and interpreted. This is a format-based possibility, not a guarantee for every damaged ZIP. (PKWARE ZIP specification)

A solid-compressed archive is a different problem. Multiple files may depend on a shared compressed stream. Damage to part of that stream can prevent recovery of data that appears later, even when those later bytes were not themselves encrypted. The 7-Zip recovery documentation explains why intact headers, compressed blocks, and stream structure matter. (7-Zip)

Therefore, “most of the archive is unchanged” does not necessarily mean “most documents can be extracted.”

Virtual disks: access metadata can be more important than its size

For QCOW2, the header and mapping structures describe how guest-visible disk locations correspond to storage inside the image. QEMU’s format specification documents the role of the header and L1/L2 tables. Losing critical mapping information can make an image unusable even when many guest-data regions remain untouched. (QEMU)

A recovery specialist may need to reconstruct virtualization metadata, recover guest-filesystem structures, or extract surviving files independently.

Simply replacing the first few bytes with a known file signature is not equivalent to reconstructing the original disk.

Backups: identify the damage before declaring them lost—or usable

A backup may contain multiple independent objects, a compressed stream, a catalog, deduplicated chunks, or dependencies on earlier backups. The recovery question is consequently more specific than “Was the backup file encrypted?”

The investigation should establish which components were modified, whether their dependencies survive, and whether the backup application can validate reconstructed output.

Backup systems themselves are also targets. NCSC guidance emphasizes that attackers may interfere with backup infrastructure specifically to obstruct recovery. A large backup file should never be assumed to receive the same treatment as a large virtual disk. (NCSC)

A real example: ESXiArgs recovery

CISA’s ESXiArgs-Recover project illustrates recovery without breaking encryption. It reconstructs VM metadata from virtual disks that the relevant attack did not encrypt. It is not a universal decryptor for arbitrary ESXi ransomware incidents. (CISA ESXiArgs-Recover)

The broader lesson is:

An unusable VM is not automatically proof that all its data was encrypted. Conversely, an apparently intact disk is not proof that its contents are complete or trustworthy.

---

9. “We Recovered the Data” Can Mean Several Different Things

Figure 5. Each recovery mechanism answers a different question. None, by itself, proves that the environment is trustworthy again.

Incident reports should identify the actual recovery method.

For example, git clone retrieves content available in a repository. It does not recreate an uncommitted server-side change, a missing database, or an upload directory that was never stored there.

Likewise, recovering four terabytes of files does not establish that four terabytes of ransomware encryption were defeated.

Recovery results must also be validated. A database that starts may still contain missing records or damaged relationships. A recovered document may be truncated. NIST’s data-integrity guidance emphasizes confidence in the correctness of recovered information—not merely restoring availability. (NIST)

A useful recovery report distinguishes complete and validated, partially recovered, corrupted, and unrecoverable data, rather than reporting only file counts.

---

10. Should an Infected Computer Be Shut Down?

Figure 6. Power-state decisions are conditional. Protect people first, stop active spread where possible, and preserve volatile evidence only when qualified responders can do so safely.

There is no safe universal answer such as “always switch it off” or “never switch it off.”

Why unnecessary shutdowns can reduce recovery opportunities

The WannaCry tools WannaKey/WanaKiwi demonstrated that, under specific operating-system and process-memory conditions, useful RSA material could remain in memory. Recovery depended on that material still being present. Rebooting, terminating the relevant process, or overwriting the memory could remove the opportunity. (WanaKiwi project)

Memory may also contain evidence valuable to the wider investigation. But preserving it must be balanced against ongoing damage.

The practical decision

When the system can be isolated and destructive activity is controlled: avoid unnecessary rebooting or shutdown while qualified responders assess volatile-evidence collection.

When the system cannot be disconnected and may spread the attack: shutting it down may be necessary. CISA explicitly recommends powering down when network disconnection cannot be achieved, while noting the resulting loss of volatile evidence. (CISA)

When local encryption continues after network isolation: isolation alone is insufficient. The incident-response lead must decide how to stop the destructive process, potentially through controlled suspension, termination, or shutdown.

When the system is already off: do not casually boot it “to check whether the files are still there.” Plan evidence acquisition and examination first.

The governing principle is:

Preserve memory when it is safe to do so—but never allow active destruction to continue merely because a key might be recoverable.

This decision should be part of a prepared incident-response procedure, not improvised from a social-media slogan.

---

11. Preserve the Malware and the Evidence—Without Running It Again

Identifying the actual encryptor can establish the family, cryptographic implementation, affected file ranges, and possible recovery methods. The loader and other malware may also explain what happened before encryption.

A practical evidence package includes:

CERT.br recommends preserving evidence and using disk images or other appropriate copies so that investigation and recovery efforts do not unnecessarily alter the original material. (CERT.br)

Record collection times, time zones, sources, hashes, and transfers. Retain an untouched evidence copy and use separate working copies.

Do not reinfect a system to obtain a sample. Do not restore quarantined malware into production. Do not execute a suspected encryptor to “see what it does.”

Memory dumps and business files can contain credentials, tokens, and personal information. Share them through an approved confidential channel—not indiscriminately through public forums or public sample-upload services.

Most importantly, the search for a malware sample must not delay containment or essential business recovery.

---

12. What to Do When Ransomware Is Discovered

Contain the incident and protect surviving recovery sources

Disconnect affected systems from network access, including Wi-Fi where applicable. Where many systems are involved, coordinated isolation may be more effective than disconnecting individual hosts.

Protect unaffected storage and backups immediately. Do not attach a clean backup drive to an infected computer to test it. CERT.br’s response guidance prioritizes isolation and preventing additional systems or storage from being affected. (CERT.br)

Apply the power-state decision described above; network isolation does not necessarily stop local encryption.

Establish incident leadership and a reliable communication channel

Notify the organization’s incident-response team and relevant external support. Depending on the incident, this may include a CERT/CSIRT, specialist responder, legal counsel, insurer, and law enforcement.

Assign decision-making responsibility and coordinate technical work with business continuity and communications. The ACSC ransomware playbook treats preparation, response, and recovery as an organizational effort rather than an IT-only task. (ACSC)

Use a communication method that does not depend entirely on potentially compromised systems.

Investigate the scope, not just the visibly encrypted computers

Determine whether the intrusion includes identity systems, cloud accounts, remote-management tools, backup infrastructure, or administrative workstations.

For data theft, investigate relevant access logs, outbound transfers, staging locations, and other available telemetry. The absence of a leak claim is not proof that nothing was stolen; a threat actor’s claim is not proof that everything was stolen.

Keep confirmed findings, hypotheses, and unanswered questions separate.

Secure identities from a clean environment

Reset exposed credentials and revoke compromised access using clean devices and trusted administrative access. Address privileged accounts, email, remote access, backup credentials, service accounts, API tokens, and other secrets according to the incident’s scope.

Do not assume that a password reset automatically ends every application session. Session lifetime and revocation depend on the identity platform and application behavior. (Microsoft Learn)

Rebuild trust before reconnecting production

Preserve the necessary evidence, then rebuild compromised systems from trusted sources where required. Address the entry point, exposed credentials, unauthorized access, and persistence before restoring business services.

Restore into a clean environment and verify the recovery source. Reconnecting restored systems to an unresolved compromise can undo the recovery effort. ACSC guidance emphasizes recovery from trusted backups and avoiding reinfection. (ACSC)

Validate critical services and data, then maintain heightened monitoring after restoration.

---

13. Prepare Before the Incident

Reduce exposed access and keep systems supported

Maintain an accurate inventory and patch more than employee laptops. Include VPN gateways, firewalls, remote-access services, NAS devices, hypervisors, and backup software.

Remove unnecessary Internet exposure. Restrict administrative interfaces to approved access paths. Use supported software, unique credentials, and appropriately limited privileges. ACSC’s prevention guidance emphasizes updates, access protection, and backup preparation. (ACSC)

Multi-factor authentication should be part of the design, especially for administrative and remote access. It is not a substitute for patching or restricting management access.

Changing a management port or installing a rate-limiting tool does not address every stolen-credential or vulnerability-based attack.

Treat hypervisors and backup consoles as high-impact systems

A hypervisor compromise can affect many virtual machines at once. Microsoft documented ransomware operators obtaining full administrative access to ESXi hosts and using that access for mass encryption and other actions against hosted systems. (Microsoft Security)

The same defensive principle applies when designing protection for virtualization infrastructure generally: the management layer needs protection independent of security controls inside individual guests.

Separate management networks, administrative identities, and monitoring. A compromise of one routine user account should not grant control over every VM and every backup.

Make security alerts actionable

Security software that nobody monitors provides limited operational value.

Develop alerts and response procedures for unusual privileged access, protection being disabled, unexpected remote-management tools, mass file changes, backup-policy changes, and abnormal deletion activity. CERT.br’s protection guidance emphasizes layered defenses, controlled access, monitoring, and organizational preparation. (CERT.br)

Monitoring must include the systems that can destroy recovery options—not only endpoints.

Train for early reporting, not blame

Users should know how to report suspicious installers, unexpected authentication prompts, and unusual system behavior promptly.

STOP/DJVU distribution has included cracked software and fake updates, making trusted software sources an important part of prevention. But training should not imply that every incident results from an employee opening an attachment. (BleepingComputer)

A user who reports a mistake immediately may provide the opportunity to contain an incident before encryption begins.

---

14. Build Backups the Attacker Cannot Easily Destroy

Figure 7. Resilient recovery depends on separation, independent identities, protected copies, and tested restoration—not on the presence of a backup job alone.

A backup is not ransomware-resistant merely because it is stored on another disk or server.

The important question is:

Can the attacker who controls the production environment also delete, overwrite, or disable the recovery copies?

NCSC guidance recommends separating backup management, protecting privileged access, preserving suitable retention, and making destructive backup actions difficult or detectable. (NCSC)

A resilient design should include multiple copies, separation from the production failure domain, an off-site recovery source, and at least one appropriately offline or immutable copy.

For cloud backups, examine actual deletion protection, retention enforcement, account recovery, and administrative permissions. A product label is not evidence that a compromised administrator cannot destroy the data. (NCSC)

Backup encryption keys and recovery credentials also need independent protection. A surviving encrypted backup is useless when its only decryption key disappeared with the production server.

Snapshots, synchronization, and Git have different roles

Snapshots can be useful recovery points. However, snapshots controlled by the same compromised storage system or administrator should not be the only protection.

Synchronization is not automatically an independent backup. A design must account for unwanted changes being propagated and verify whether usable historical versions remain.

Git protects the code actually committed and available in the repository. It does not automatically preserve databases, uploads, uncommitted modifications, or environment-specific dependencies. Keep repositories protected and separately recoverable; do not treat storing secrets in source control as a backup strategy.

These tools can contribute to resilience, but none should be credited with capabilities that have not been tested.

Test restoration, not just backup completion

A “backup succeeded” notification does not prove the organization can resume operations.

Define a Recovery Point Objective, or RPO: the point in time before disruption to which data must be recovered. Define a Recovery Time Objective, or RTO: the maximum time a system resource can remain unavailable before the impact becomes unacceptable. (NIST SP 800-34 Rev. 1)

Then test the complete service, including identity, networking, application dependencies, database consistency, and user access.

A meaningful exercise should answer: Can the team recover when the normal administrator workstation, domain, email, and backup console are unavailable?

Keep the response plan, emergency contacts, and essential recovery information available outside the systems they are intended to recover. Preparation and exercises are central elements of the ACSC ransomware playbook. (ACSC)

There is no universal promise that “good backups mean recovery in two hours.” Recovery time must be demonstrated for the actual environment.

---

15. Ransom Payments, Recovery Services, and AI Assistance

Payment does not guarantee a working decryptor, complete recovery, deletion of stolen information, or an end to the attacker’s access. Software defects can also make data unrecoverable even when a key is available. No More Ransom explicitly warns against treating payment as a guaranteed solution. (No More Ransom)

An organization facing serious operational consequences should evaluate its options through established leadership, incident-response, and legal processes—not leave the decision to one exhausted administrator.

When engaging a recovery provider, obtain a clear explanation of the proposed method. Is the provider restoring backups, applying a known decryptor, reconstructing data, or negotiating with the attackers? Require appropriate evidence handling and realistic validation criteria.

Similarly, AI assistance does not change the underlying recovery mechanism. AI may assist an analyst’s work, but the statement “AI recovered the files” does not explain whether the recovery used a key, an intact copy, or surviving disk regions.

Treat generated scripts as untrusted until reviewed and tested. Never run experimental repair code against the only copy of an encrypted disk.

Recovery should be measured by validated results—not confident promises, file counts, or the name of the tool used.

---

Conclusion: Recovery Means Regaining Trust

Ransomware is not one problem with one remedy.

It can combine encryption, credential theft, data leakage, destruction of backups, and compromise of the administrative systems needed for recovery. Some implementations have exploitable weaknesses. Some deliberately leave large regions untouched. Others destroy data in ways that no decryptor can reverse.

That is why careful analysis matters—and why preserving the malware, metadata, encrypted originals, and appropriate volatile evidence can make a difference.

But recovery opportunities are not a substitute for preparation.

The strongest position is an environment with restricted administrative access, supported and patched systems, monitored security controls, independently protected backups, and recovery procedures that have already been tested.

When an incident occurs, the priorities are clear:

Stop further damage. Preserve useful evidence. Determine what happened. Recover and validate the data. Rebuild a trustworthy environment.

Getting the files back is a milestone. Being able to trust the systems again is the real goal.