This article shows you how SSProtect uses built-in capabilities for :Respond Integrity Remediation that repairs corrupted data content.
Ransomware since around 2013 has become an increasingly widespread problem that isn't going to disappear anytime soon. There are countless products designed to address the problem, and SSProtect delivers a simple yet highly-reliable method for remediating its' effects on sensitive data, which addresses other forms of sabotage/ corruption.
The Short Version
For Privileged SSProtect Accounts using :Respond:
- Log In to your Privileged SSProtect Organization Account
- From the SSProtect icon in the notification tray, right-click and choose the Sabotage Remediation menu item
- Make certain Restore Corrupted and Auto-Report are checked, then click Start.
This article walks through the steps necessary to create a test file, corrupt content, then execute Remediation and verify results. Subsequent text shows you how the associated Integrity Protection operates as a means of contributing to this simplified Remediation process.
Execution requires that you've Licensed :Respond as directed in this section's Overview.
Finally, STEP guidance uses Profiles created in the Walkthrough, Third Party Trust Sharing. This is a matter of convenience rather than a requirement; execution is straightforward and simple.
NOTE: You do NOT have to have Integrity Protection enabled for Remediation to find corruption, since SSProtect incorporates several methods for determining when a file's integrity has been compromised. For more information, refer to the article, Operating Modes and/ or coordinate a technical review session through your DefiniSec Representative.
Ransomware operators use technology to access your computing resources then encrypt content before offering to sell you access to the utility and decryption key(s) necessary to recover your original plaintext. If you have suitable, up-to-date Backups and can reasonably Restore data to continue forward operation, there may be little reason to pay the Ransom - though as a fallback the attacker may then threaten to sell or disclose the plaintext content if their activities allowed them to steal the data they encrypted.
SSProtect is highly effective in stopping both threats due to the way protective measures are implemented, deployed, and utilized.
IMPORTANT: Whereas Ransomware may encrypt more than just data files, SSProtect's ability to Remediate focuses on content protected/ managed with the software. This won't typically include binaries and non-critical data files. This does however allow you to quickly and efficiently utilize Remote Profile Deployment to utilize a replacement computer with your sensitive content while avoiding threats to publicly disclose sensitive information.
Create Test Content
Let's start by corrupting our own managed content so we can see how :Respond Integrity Remediation works.
STEP 1: Refresh Login with SSProtect, choose your Org1_Admin Profile, then enter your Password, Log In.
STEP 2: Create a new data file we'll protect then corrupt, C:\TestData\IntegrityTest.txt, and add some content. We suggest, Ransomware can't hurt me, I'm using SSProtect. Save/ Close the file.
STEP 3: From File Explorer, right-click C:\TestData\IntegrityTest.txt and choose SSProtect Activate, creating Version 1 of the target file.
Looking Deeper: Managed Data Encoding
Before we attempt to, "simulate" data corruption, it's for some helpful to understand the nature of protected data. In general, we can say that data encryption transforms plaintext into what we call ciphertext, using one or more encryption keys. This ciphertext is stored with additional management information sometimes scoped by published standards and other times driven by proprietary means. In each case, there is an underlying encoding scheme that is used to read/ write management information and enciphered content in a form easily interpreted by the management facilities.
When data is corrupted, it can affect the management data, which is often used to identify content. It can also affect the enciphered data. In the case of Ransomware, corruption affects both types of material since the data file is completely rewritten. Good encryption is designed to make it impossible to correlate source material with enciphered results, and good encryption algorithms are public. As such, these results are easy to achieve and have the effect of making it such that management technologies can no longer deterministically correlate content back to its' source.
In our exercise, below, we'll corrupt the data file by overwriting the management information - the header for enciphered content. This is enough to make it such that SSProtect cannot recognize the corrupted file as a managed item, which then reduces recovery to the most limited case possible. We do this on purpose, then refer back to the more manageable case of corrupted ciphertext to show how SSProtect enforces data integrity protection, since it is closely related.
Corrupt Test Data
STEP 4: From the SSProtect icon in the notification tray, right-click then choose Exit to terminate SSProtect operation.
IMPORTANT: We terminate SSProtect only to ensure we can corrupt our own data without accidentally triggering the In-Place Encryption mechanism that securely accesses plaintext content. This doesn't, "cheat" the idea that Ransomware encryption makes it into traditional backup images. We have more to say about this, below - for now, know that it's only a matter of conveniently simulating data corruption.
STEP 5: From File Explorer, double-click C:\TestData\IntegrityTest.txt to open the Version 1 ciphertext in Notepad. Right at the beginning of the file, type, CORRUPTED CONTENT then Save/ Close.
Because we're using a text editor to open a binary file, some of the content is likely not properly rendered. As such, when we make changes, the content that doesn't map to recognized text will not be stored properly, further corrupting the data. This doesn't affect the nature of our test since the content we introduce makes it unrecognizable to SSProtect.
Handling Corrupted Interpretation
Before we skip to the Remediation part of things, it's worth first looking at how SSProtect reacts to the corrupted file. The first thing you'll notice is the File Explorer Overlay Icon is removed - this means SSProtect doesn't recognize the file as a managed entity. As you may have deduced, that requires the header to provide proper information, and the data we stored obviously doesn't represent identifying information SSProtect recognizes as valid.
Let's take a look at how this renders in our Working Set as depicted by the Hostlist.
STEP 6: Double-click the SSProtect desktop icon to restart the :Foundation Client and display the Login dialog, then choose the Org1_Admin Profile, enter your Password, Log In.
STEP 7: Navigate to the Managed Files/ Restore dialog by right-clicking the SSProtect icon in the notification tray and choosing the context menu of the same name:
Notice here we see the file IntegrityTest.txt with the (ChgPlnTxt) designation. Though the file is obviously not in plaintext format, SSProtect is more importantly noting that it isn't in a recognized ciphertext format - clearly it's changed. Despite that the software can't interpret the corrupted content, it does of course keep track of the fact that the noted filename and location should hold protected data.
If you use the Archive... button to view content in the KODiAC Data Archive you'll see that Version 1 is available for Restore. This is, in fact, the specific instance that's used in the activities that follow.
Execute Integrity Remediation
STEP 8: Dismiss the Hostlist/ Archivlist then use the notification icon's context menu and navigate to Sabotage Remediation.
STEP 9: Check the Restore Corrupted and Auto-Report checkboxes to match the display shown below, then click Start:
Problem solved. Let's take a look at the results.
The first thing you'll notice is the Report that comes up in Excel, which for us shows the following:
The screenshot truncates columns of secondary importance but retains enough visible data to confirm that our target test file was seen as Corrupted and also Remediated.
You can also see that the target scope matches our Profile's Working Set of files, enumerated in the Hostlist display, but only from the standpoint of unique Version Chains. For this reason, copied_file.txt is not listed. This is by design though perhaps undesirable. Look for changes in an upcoming v11.x release. If unclear, refer to the Walkthrough, Version Chains.
If we use File Explorer and navigate to C:\TestData we'll find both C:\TestData\IntegrityTest.txt and also C:\TestData\IntegrityTest.txt.bak, the latter being the Corrupted instance that's maintained for further review and the former taking its' place for ongoing use.
To verify that Remediation holds proper content, you can do any of several things:
- From File Explorer, double-click the Remediated IntegrityTest.txt to make sure it opens and holds the original plaintext we expect
- From File Explorer, shift-right-click the Remediated IntegrityTest.txt then choose SSProtect Release to decrypt, then verify results
- Navigate to the SSProtect Hostlist, choose IntegrityTest.txt then Restore (and confirm Replace operation) and compare IntegrityTest.txt to IntegrityTest.txt.bak.0, the latter being the Remediated instance moved for Restore operation
- Similarly but in less confusing fashion, from the SSProtect Hostlist with IntegrityTest.txt selected, choose Versionlist... then Restore Version 1 (the only instance in the list) and compare the Remediated IntegrityTest.txt to the Restored IntegrityTest-v1.txt
Looking Deeper: Combining Primitives for Remediation
The :Foundation Client provides reliable :Respond Integrity/ Sabotage Remediation by leveraging the underlying platform used to protect and manage content. As a result, the :Respond service facility relies on existing and proven fundamentals that form the foundation of our SSProtect/ KODiAC platform.
:Confidential, as you know, is the built-in service component that delivers data encryption using our patented cryptographic offloading methodology. This approach isolates decryption keys from the host computer while at the same time providing a simple, secure means for KODiAC to store secure Version Instances for later recall. This is the source material for :Recover Archive content, which is vastly different from the approach used by traditional, scheduled Backup operations that copy data: Because :Recover retains secured Version Instances when and as they are changed, as a natural extension of the underlying offloading methodology, Backup materials are not impacted by subsequent, unsecured changes to host-based ciphertext content.*
By the same token, :Recover Restore uses the same cloud-managed data access logic that's called into action when you access protected content on your host computer. This maintains a highly-reliable mechanism for delivering secured content instead of using independent Restore operations that may not succeed (and don't get used except in critical situations - the worst time to find out there's a problem).
Perhaps most importantly, AES Data Encryption does not provide Integrity assurance despite that it can detect some errors in ciphertext input data. :Confidential integrates HMAC-SHA512 into the protection/ offloading mechanism with special care taken to avoid issues with Generic Composition, as described in our Insights article, All Crypto !Are Created Equal.
* The KODiAC Managed Data Archive doesn't overwrite stored content instances when secured data is processed, it creates new Archive Version Instances that make up the set of materials available for later recall.
Host Integrity Protection
Let's navigate to the License and Components display to see how our Org1_Admin Account is setup.
STEP 10: Dismiss the Sabotage Remediation dialog then navigate to License and Components:
Notice the checkbox, Integrity Protect. This is set, by default, as part of :Confidential data protection and uses HMAC-SHA512 Integrity Protection with independent keys that are built into the cryptographic offloading methods used to protect content.
Let's see what happens when we protect content with and without Integrity Protection, then subsequently corrupt enciphered data content and attempt to securely access the corrupted result.
STEP 11: Leave the License and Components dialog open, then create the file, C:\TestData\TestIntegrity.txt, and add the text, Protected With Integrity. Save/ Close. In File Explorer, right-click C:\TestData\TestIntegrity.txt then choose SSProtect Activate to protect content.
STEP 12: In License and Components, uncheck Integrity Protect. Choose Yes when prompted to execute the request.
STEP 13: Create C:\TestData\TestNoIntegrity.txt, and add the text, Protected WITHOUT Integrity. Save/ Close. In File Explorer, right-click C:\TestData\TestNoIntegrity.txt and choose SSProtect Activate to protect content.
Corrupt Content and Test Managed Access
Now let's corrupt our own content to set the stage for further activity.
STEP 14: Dismiss the License and Components dialog, then in the notification tray, right-click the SSProtect icon and choose Exit.
As an alternative, instead of Exiting SSProtect, in the steps below edit ciphertext content with something other than Notepad, the default Windows application for .txt content - we suggest Notepad++.
STEP 15: Double-click C:\TestData\TestIntegrity.txt to open it in Notepad. Select a character in the middle of the file and replace it with the letter, 'a'. Save and Close.
STEP 16: Double-click C:\TestData\TestNoIntegrity.txt to open it in Notepad. Select a character in the middle of the file and replace it with the letter, 'a'. Save and Close.
STEP 17: If and as required (depending on how you corrupted content), restart SSProtect by double-clicking the SSProtect desktop icon, then in the Login dialog choose the Org1_Admin Profile, enter your Password, Log In.
Let's see how SSProtect handles Managed Access attempts with corrupted content.
STEP 18: In File Explorer, double-click C:\TestData\TestNoIntegrity.txt to perform Managed Access, which should decrypt content then display it in Notepad for editing.
This may or may not succeed - it depends. As noted, AES can detect some changes to ciphertext input, but not all changes. If the file does not decrypt and render plaintext, retry by navigating to the Managed Files/ Restore dialog, select TestNoIntegrity.txt then Restore content (and Replace existing data). Corrupt the file though change a different character toward the middle or end of the file, save/ close and repeat the noted procedure.
Eventually, and without too much trouble, you'll find a modification that decrypts and renders perfect plaintext in Notepad. But how can that be - we corrupted the ciphertext....
Enciphered data corruption can result in decrypted data that results in characters Notepad can't render, and as a result may be ignored/ discarded, etc. This can alternatively generate characters that don't show up in the display, but still exist (escape characters for example). In some cases you'll see perfect plaintext, in others corrupted plaintext, and as noted, sometimes decryption simply fails.
This is dangerous: At the very least, corrupted content can crash or corrupt managing applications. Is it possible to corrupt content in a very specific way to exploit application flaws and gain control of a host computer? That seems pretty far-fetched, but still when there's a way to create a failure in software, it can be used with other techniques to create more than simple problems.
For these reasons, SSProtect will not permit Managed Access to content that has been create with Integrity Protection that's also corrupted. Let's see this in action by attempting to open the file we modified after protecting it with Integrity Protection enabled.
STEP 19: In File Explorer, double-click C:\TestData\TestIntegrity.txt to perform Managed Access. This will fail with the following notification:
SSProtect allows Privileged Account holders to override this behavior when Releasing Protection, but it must be configured and isn't by default. Let's fix our Account to do this, then give it a shot.
STEP 20: Navigate to the User Administration display (using the context menu Administer Users entry), choose your Account from the Userlist, then select Edit. In the right-middle of the dialog, you'll see an unchecked box, Int Override. Check this box the click Save. Choose OK to dismiss the dialog.
STEP 21: In File Explorer, shift-right-click C:\TestData\TestIntegrity.txt then choose, SSProtect Release. You will be prompted with a message indicating that the file is corrupted with an accompanying opportunity to continue:
STEP 22: Choose Yes. There is no assurance that Decryption will succeed - it depends on the nature of the corrupted text, as noted above. However, if and when it does decrypt, you can double-click the resulting file to view results. As also noted above, you may or may not see visible corruption in the resulting plaintext.
Reset your Configuration for Ongoing Use
Before we continue forward, remember to re-configure Integrity Protection since we disabled it in prior STEPs.
STEP 23: Navigate to the License and Components dialog, check, Integrity Protect, then choose Yes to execute the operation. Dismiss the dialog with OK.
Prior Walkthroughs have talked about the way :Recover stores content in the KODiAC Managed Data Archive, avoiding storage of unsecured modifications to ciphertext data. From the information in this article, you have learned that :Confidential is a bit more complex than previously noted, by default including Integrity Protection with HMAC-SHA512. When enabled, SSProtect will keep you from accessing ciphertext content that's been modified after securely protected: Even though AES decryption can detect some ciphertext errors, HMAC-SHA512 and the independent keys SSProtect creates and uses delivers Integrity Protection assurance for your managed content.
:Respond Integrity Remediation leverages these built-in capabilities to verify your Working Set content Integrity, then prepares a Report indicating whether or not content remains in expected form. We chose to execute with the optional Remediation option selected, which retains corrupted backup files then replaces them with proper Restored content. This allows you to quickly repair any sabotage/ corruption that's been imposed on your managed content, maintaining operational integrity and continuous access to managed content.
Refer to the :Respond section of articles for additional details, more specifically, Using Integrity Remediation, which shows you how as a Privileged User to dispatch Integrity Remediation to Users in your Organization.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client