Rollback, SentinelOne's rewind for ransomware. This feature boasts the ability to restore, with a single click, files that have been maliciously encrypted/deleted, to their previous state. What's more, this functionality is provided in a single agent EPP/EDR solution that has an average CPU footprint of 1-5%.

In this article, we take a technical deep dive into the rollback feature to understand its key strengths, let's dive in.

Introducing the Volume Shadow Copy Service (VSS)

To understand how SentinelOne implements rollback functionality, we first need to understand the VSS (Volume Shadow Copy Service) feature provided in Microsoft's Windows Operating Systems. The VSS is a feature that can maintain backup copies of volumes or computer files, even while they are in use. The VSS operates by taking what is called a 'copy on write' snapshot of a system which ensures that for each disk write operation, a copy of the file currently on disk is taken and moved to a small temporary storage location allocated by the VSS. The disk write operation can terminate after the end of the snapshot creation.

‍

The process of moving a copy of files to a temporary storage location enables the VSS to efficiently take a snapshot of only files that have changed since the previous snapshot, instead of having to take a full copy of a disk.

These copies are read-only point-in-time copies of the volume. The VSS was introduced in Microsoft Windows XP/Server 2003, and since then it has become a core feature in all recent versions of the Windows OS. SentinelOne's rollback service is available from Windows Vista/Windows Server 2008 R2 and onward. Unfortunately, the SentinelOne rollback feature does not extend to macOS versions, and Linux Supported kernels.

How SentinelOne is using VSS

SentinelOne uses VSS snapshots to provide its rollback capabilities. As a VSS requestor, it interacts with the service to create, manage and protect snapshots by detecting any attempt of VSS tampering and blocking it on the spot. On top of that, it gives administrators the ability to enforce VSS snapshots on the endpoint directly from the management console without the need to have direct access to it.

‍

The timing in between Snapshots taken by SentinelOne is 4 hours by default, starting on installation. The timer does not count during sleep mode or hibernate, meaning that if the endpoint takes a snapshot at midnight, then sleeps for one hour, then is activated again, the next snapshot is going to be at 5:00 AM not 4:00 AM.

Note - It is possible to adjust the snapshot timings up or down, however, doing so should be done with utmost consideration of the repercussions as a poorly configured setting could affect the reliability of a rollback.

Testing Rollback

In this blog, our goal was to create a perfect environment for ransomware to execute without any disturbance, and demonstrate how SentinelOne can mitigate the attack by restoring the endpoint to a previous healthy state with its rollback feature utilising VSS snapshots.

The endpoint used to demonstrate the exploit was a Windows 10 Enterprise Virtual Machine. The SentinelOne Agent used was version 3.7.2.45. The strain of ransomware used in this demonstration was called "Locky".

Locky was a piece of ransomware that released in 2016. It uses RSA-2048 and AES-128 cypher with ECB (Electronic Codebook) mode to encrypt targeted files. Keys are generated on the server-side, making manual decryption impossible. Another thing worth mentioning is that "Locky" encrypts files on all fixed drives, removable drives, network and RAM disk drives. In our case, the malware was just downloaded from the internet by us, in a real-life scenario the most common ways of delivering it is through an email where it's embedded in a link or attached as a macro on Microsoft Word/Excel documents.

The methodology that we followed for the demonstration was:

Step 1: Setting up SentinelOne with the correct settings is something vital for this demo. First, we need to install the agent on the device by logging into the management console, download and run the executable. After that, we need to ensure that the demo group our endpoint is a member of has its policy is set to Detect/Detect because if not, the malware is going to be blocked immediately. We do not want that; we need the malware to execute and infect our system.

‍

Note: Our recommendation is always to have the policy to Protect/Protect, which means that threats such as the ones shown are blocked before they take any action. The rollback option is something that is used only in rare cases where the malware bypasses all previous detection layers, an extremely challenging task.

Note: After installation, we can see that the VSS is running, which means that a snapshot is currently in progress. SentinelOne always takes a snapshot immediately after installation.

‍

Step 2: Executing the attack is an easy task because all we have to do is download and run the malware executable. From the time that the file downloads on the endpoint, SentinelOne detected its malicious nature. The reason that it is not blocked immediately is because of the policy change we implemented in step 1, resulting in SentinelOne only showing us alerts about the threat rather than preventing it.

Following the execution of the Locky Ransomware, It's evident our data has become encrypted and subsequently renamed to a unique combination of letters, numbers and symbols with .ykcol (locky backwards to the keen eye) file extension. Following the encryption stage, a message on the desktop instructs us to download the Tor Browser and visit a specific criminal-operated website for further instructions.

‍

Step 3: To respond to this attack, we use the rollback feature form SentinelOne's management console. To do that, we must log in to the management console, go to the site in which our demo group and our infected endpoint resides, identify the malicious process and initiate the rollback.

‍

Note: By logging into the management portal and selecting the right site and group, SentinelOne gives us a full overview of any suspicious or malicious incident that it detected.

‍

Note: SentinelOne gives the user a more thorough analysis of the event as well as 4 mitigation options. In our case, Rollback is the mitigation option of choice.

The successful restoration of our files is a result of their inclusion in one of SentinelOne's snapshots. As mentioned previously, the creation of new snapshots takes place every 4 hours, following the installation of the SentinelOne Agent. The recovery of files that were modified or newly created since the last snapshot took place is impossible since they are not included in a shadowcopy yet. This, unfortunately, is the nature of the VSS and not SentinelOne.

Note: If SentinelOne is not configured to keep VSS snapshots, however, other programs do keep "ApplicationRollback" type snapshots on the endpoint, SentinelOne is able to utilise these snapshots to initiate a rollback. Also, if both SentinelOne and other programs keep VSS snapshots on an Endpoint, SentinelOne always prefers its own snapshots.  

‍

Conclusion: Even though this test proves how valuable SentinelOne's rollback service is, what makes SentinelOne even more valuable is that the platform is autonomous. Its use of machine learning and artificial intelligence on the endpoint and its constant monitoring of all processes, even low-level ones, delivers a product that has revolutionised the EPP/EDR business and pushed the cybersecurity industry forward. Additionally, features like Deep Visibility extends SentinelOne's capabilities by offering full visibility into the endpoints network, files and processes, allowing for near real-time monitoring and search across endpoints.

‍