Tales from decrypt: Differentiating decryptors from ransomware

A member of Red Canary’s Detection Engineering team was working the queue on an evening in February 2021 when an event triggered related to port-scanning activity. What immediately stood out was not the network connections that triggered the event, but rather, the anomalous file activity. Our detection engineer noticed hundreds of sequential file writes with the .lockbit extension followed by the deletion of restore-my-files.txt files. The executable creating these file writes was named MasterDecryptor_AF3DFF02BC68214E.exe (hexadecimal suffix renamed to protect the innocent).

For an analyst working the queue, the immediate question becomes, “do I push a detection to the customer?” Considering time is always of the essence—especially in cases of suspected ransomware—quick, confident, and consistent decisions are necessary. So the next question that arose naturally was:

Despite event data showing activity that appears to exhibit ransomware behavior, is this ransomware or a ransomware decryptor?

A cryptic filename

Typically, those working the queue will be given a heads up by our incident handlers when a customer purchases a decryptor with the corresponding hash, but in this case, there was no such communication. So rather than attempting to determine on his own if this was ransomware versus a decryptor based on the event data, the detection engineer first asked our incident handlers to validate if a decryptor was expected to be deployed by the customer. The answer didn’t arrive immediately, so in the meantime he needed to quickly make sense of what was going on. He made the following rapid observations about the event timeline:

1. A series of file writes were made to filename.extension.lockbit files within a directory
2. restore-my-files.txt was then deleted in each directory where a .lockbit file existed
3. Typically, when ransomware decryptors execute, there will be file writes associated with the restoration of the encrypted files. So, for example, if company_secrets.docx.lockbit was present, the decryptor would write the contents back to company_secrets.docx upon decrypting the file. No such file writes were present in sensor telemetry, however. Therefore, there was no immediate way to confidently discern between a ransomware encryption operation and a decryptor decryption operation
4. Because restore-my-files.txt files were being deleted, instead of written to, this behavior more closely aligns with decryptor operations. When ransomware initially executes, it will write ransom notes to disk. In this case, there were no such ransom note file writes apparent, only deletions. So this heuristic alone raised confidence that this might be a decryptor

Despite a suspicion that this is likely a ransomware decryptor, do we push this as a confirmed threat to the customer?

The detection engineer did the right thing and without hesitation, pushed these events as a confirmed threat as he still hadn’t heard back from the customer or incident handlers that this was a confirmed decryptor in their environment. Despite his suspicions that this was a decryptor based both on the filename (which should never be used solely as a high-confidence indicator) and the ransom note deletions, without positive confirmation that this was “approved software,” it had to be treated as malware to let the customer adjudicate whether or not it was expected in their environment.

In the end, the customer responded quickly, confirming that this was indeed an expected decryptor. We absolutely sympathize with the pain the customer endured dealing with the ransomware incident, and getting another ransomware-related detection surely caused brief heartburn and anxiety. But ultimately, we were relieved that the customer was given the opportunity to confirm that this event was expected.

Lessons learned

For each event worked, there are always lessons to be learned, and this was no exception. This incident allowed us to:

• identify new potential ransomware and decryptor detector logic
• re-validate and improve upon our decryptor deconfliction process
• appreciate the value of having a broad set of behavioral detectors that occasionally catch techniques and threats that otherwise would have flown under the radar
• consider the subtle differences in behavior between ransomware and their corresponding decryptors

This detection reaffirmed our perspective that even a confirmed decryptor should be considered malware on the basis that it is adversary-supplied software that is related to ransomware. It should always be a decision of the customer to decide if they don’t want to be alerted to the presence of a ransomware decryptor, and we will suppress future decryptor events based on a hash if explicitly requested by the customer.

Remaining questions

Working the event queue is no time to pontificate about “what ifs.” Hypothetical scenarios lead to rabbit holes that are far too easy to fall into and waste valuable response time. However, with the benefit of hindsight and in the interest of being better prepared for future scenarios like this one, hypothetical questions can often yield interesting research and detection opportunities. Consider the following:

• What makes a decryptor a decryptor when it doesn’t say the equivalent of “I_AM_DECRYPTOR” in the filename?
• Can a customer affected with ransomware be confident that the corresponding decryptor decrypts and only decrypts? Or is there any chance that there might be otherwise subversive functionality incorporated into the decryptor that exhibits additional, unexpected malicious behavior? While we’d like to think that incorporating subversive behavior into a decryptor would harm the “reputation” of ransomware operators and affect their business model, assumptions are dangerous, and many of us are unable to fathom the depths of the evil that ransomware operators will perpetrate. This calls for deeper analysis into what decryptors are actually doing under the hood.
• Did port scanning activity trigger in this case because the decryptor was designed to traverse SMB file shares? Further analysis of the decryptor binary could confirm this theory. Many of the .lockbit file writes occurred on file shares, which corresponded with the internal network connection activity.

Conclusion

Pushing actionable and timely detections to customers is hard work, and we don’t always get things right. In this case, the analyst made the right decision to push a detection without hesitation—despite reservations that this may be a decryptor. We’re also grateful to our detection engineer for sharing this story and his thoughtful analysis and hypotheses.

Every event, no matter how fascinating or utterly mundane, has a story behind it, and we hope that you’ve gleaned some insights from this one. Thank you to all security analysts working on the front lines!