How to Use Recovery Manager

Introduction

Recovery Manager extends the capabilities of Ransomware Defender by automating data recovery in the event of a cyberattack. Integrated into the Event and Event History tabs, Ransomware Defender caches audit event history, allowing for recovery of data from before an attack is detected. This historical data is accessible through Recovery Manager, where you can perform targeted recoveries using file or path-based filters.

This solution provides full coverage across detection, response, and recovery, automating each step of the attack lifecycle. Recovery Manager highlights recoverable data if a snapshot was taken before the first event affecting the relevant path.

Example

• A file /ifs/test/document.txt is renamed to /ifs/test/document.locky at 5:00 PM.
• A snapshot was taken on the path /ifs/test/ at 4:00 PM.
  Result: The file is recoverable.
• If the only snapshot is from 5:03 PM and no previous snapshot exists, the file is not recoverable.
• If a snapshot exists on a different path, such as /ifs/otherpath/, but not for /ifs/test/, the file is unrecoverable.

Post-Mortem Analysis and Forensics

Recovery Manager includes an automated quarantine feature that moves affected files into a hidden location for analysis. This not only isolates harmful files from the system but also makes them invisible to end users, while still accessible for future investigation.

Prerequisites

• Release Version: 2.5.9 or later.
• Licenses:
  • Requires an Eyeglass DR license for inventory and snapshot management.
  • Requires an Eyeglass RWD license for ransomware event detection.

Data Retention

• Default Activity: User activity is logged 1 hour before the event.
• Retention Period: Data is retained for 7 days after the event. After this period, user activity data for a specific event is automatically purged.

To extend retention to 30 days:

1. On ECA Node 1, open the configuration file:

   nano /opt/superna/eca/eca-env-common.conf

2. Add the following line:

   export ECA_KAFKA_USER_TOPIC_RETENTION_DAYS=30

3. Save and exit by pressing Ctrl + X.

4. Restart the cluster:

   ecactl cluster down
   ecactl cluster up

How to Complete Forensics of Quarantine Data

When recovering compromised files, follow these steps to perform a forensic analysis of the quarantined data:

1. All compromised files are moved during recovery to a quarantine location in /ifs/.ransomwaredefender/corrupted/.
2. Under this location, each user's SID is created as a subfolder, and the full relative path to each file is maintained, allowing for targeted scanning with security or decryption tools.
3. This structure also serves as a map of the attacked data, enabling the cyber recovery team to analyze the attack pattern within the file system.
4. The quarantine location is secured outside of any SMB or NFS exports, keeping the data hidden in a protected area.
5. If necessary, create an SMB share with read-only access for cyber recovery teams to analyze the quarantined data.

How Recovery Manager Determines Which Version to Restore

When our software detects activity by a bad actor, it raises a ransomware event.

Once the event occurs, Recovery Manager tracks all events by the bad actor starting from 1 hour before the event.

Recovery Manager compiles a list of all files—or objects (in the case of AWS/ECS)—that the bad actor modified. Modifications include:

• Writing to files or objects,
• Creating new ones,
• Deleting existing ones,
• Renaming them.

For each file or object, Recovery Manager refers to the snapshot that was created before the event and selects the version of the file from this snapshot for recovery. This version comes from before the first modification by the bad actor, within the one hour before the ransomware event.

PowerScale Case: Finding the Correct Snapshot for Recovery

To understand how Recovery Manager determines the best snapshot for recovery, the following criteria are used:

1. Snapshot Location:

   • The snapshot must exist on the same path as the file.

2. Snapshot Timing:

   • The timestamp of the snapshot must be earlier than the timestamp of the first event initiated by the bad actor on that file, as tracked by Recovery Manager.

3. Best Snapshot Selection:

   • Among all snapshots that meet the above criteria, the best snapshot is the one that is closest in time to the first event on the file. This ensures the most recent and relevant version of the file is recovered.

Snapshot Recovery Example

Let’s consider the case of a file called document.txt located at /ifs/test.

• A bad actor renames the file to document.locky at 5:00 PM.

Recoverable Scenario

• A snapshot was taken on the path /ifs/test/ before the file was renamed, at 4:00 PM.
  • In this case, the original document.txt file is recoverable because the snapshot predates the malicious change.

Not Recoverable Scenario 1

• A snapshot was taken after the file was renamed, at 5:03 PM, and no prior snapshot exists on the system that covers the /ifs/test path.
  • In this case, the document.txt file is not recoverable because no valid snapshot exists from before the rename.

Not Recoverable Scenario 2

• There is only one snapshot on the system for a different path, /ifs/otherpath/, and no snapshot covers /ifs/test.
  • The document.txt file is not recoverable because no relevant snapshot exists for its directory.

note

If a previous ransomware event corrupted the file, and the administrator restored it to a previous version after acknowledging the event and archiving it, there is a chance the most recent snapshot may still contain the corrupted version if another ransomware event is raised within the hour.

AWS/ECS Case: Recovering an Object

To recover an object, bucket versioning must be enabled. Recovery Manager will restore the most recent version from before the first modification tracked by the bad actor.

info

To display the “Earliest Recoverable Version Time” column in Recovery Manager, the Eyeglass /opt/superna/sca/data/system.xml file must contain the versioningEnabled property (inside the <process> tag) set to "true".

• If versioningEnabled is set to false, the Bucket Versioning Status column will be displayed:

Bucket Versioning	Bucket Versioning Status
OFF	Disabled
ON	Enabled
SUSPENDED (was updated from ON to OFF)	Suspended

• If versioningEnabled is set to true, the Earliest Recoverable Version Time column will be displayed:

earliest_recoverable

Bucket Versioning	Bucket Versioning Status
OFF	NO_VERSIONS_EXIST
ON	<date_time_stamp>
SUSPENDED (was updated from ON to OFF)	NO_VERSIONS_EXIST

For example:

• A version of Object A exists in a bucket that has Versioning enabled.

• A bad actor triggers a ransomware event.

• Recovery Manager has access to the version of the file that existed before the ransomware event, therefore it can be restored.

If no such version exists, the object will be quarantined.

note

If a ransomware event is raised for a user and then the same user triggers another ransomware event, there is a small chance that the corrupted version might be chosen for restoration.

This may happen if:

• The second ransomware event occurred within 1 hour of the previous event, and the file was corrupted 1 hour before the second event, and the bad actor modified the file within 1 hour before the second event.

  OR

• The second ransomware event occurred 1 hour after the first event, and the object was restored within 1 hour before the second event, and the bad actor wrote to the object again before it was restored.

info

Recovery can mean many things:

• restored (if the file is not a bad extension, it is placed back in the share or bucket)

• deleted (if the file is a bad extension, it is not placed back in the share or bucket)

For example, locky files will not be restored.

ECS Differences

See Also

• Recovery Manager Guide Vast
• Installation Guide