by Mark Rasch
By Lance James
The last few weeks, I’ve been spending my days helping victims recover from ransomware attacks. When doing this, restoration is the number one priority, and the motto becomes “as fast as you can“. There have been some challenges along the way, and some “shocking” reveals when working with criminal software when expecting it to unlock your files. Here are some of the following use cases that Unit 221B encountered and the workarounds we applied to get a successful restoration.
Single Decryption Tool Per Key
In many cases there are multiple keys involved that have to be purchased. Different servers tend to have different keys, so that the threat actor can capitalize on the recovery point. So when a purchase is made, it’s usually with multiple keys. In some cases, we have found that the decryption tool loads up one key, so you are sent multiple decryption tools, one for each key. As you know, we are already in a bad position here having to run a criminally written software after paying them, but now we are slowed down by having to run multiple tools to solve the problem.
221B’s workaround
We built key extractors for the decryption tools and loaded it into a decryption tool we wrote, allowing for decryption of mixed keys within single directories, and one tool to solve all the problems across all the servers in one go.
Tool Won’T UNLOCK EVERY FILE
What a surprise… As you know, the threat actor spends more time on the software designed to lock your software, than to unlock it. And you probably aren’t calling him up to request new features in their software other than the worst YELP review ever. So, of course, their unlocker tools will be buggy and miss stuff. Here are some reasons why…
File Footer Malformation
In some cases, we found that the file footer contained almost everything it needed, but was missing the master public key. We would get the length for the key, and then it would just end. This could happen for many reasons, such as a bug in the encryption process, or otherwise, but it causes the criminal unlocker tool to skip these files. In our cases, it skipped gigs of files across multiple servers, and this was not good when you have chained backups you need.
Key Missing from Footer
Yes, this actually happened. The actual keys were missing from some of the files it was supposed to unlock, rendering this tool useless for at least 10% of the files. When examined, the actual private symmetric key encrypted to the master key was missing, making for a bad day.
221B’s workaround
We simply built decryption tools in advanced that covered these issues. For the footer malformation issue, we knew the key was still in tact, so we simply added conditions that would look for the missing footer length, and subtracted it from the footer, and continued decryption as if the footer was normal.
For the keys missing, we noticed that keys were repeated a lot, and many keys were repeated specifically if it used the same path. We recorded the symmetric keys for each path, and simply performed decryption on breaking files using the path’s symmetric key with 100% success.
Criminal UNLOCKER TOOL TOO SLOW
Due to a multitude of reasons, the criminal unlocker tool might be too slow, and not be hitting the speeds you might need for getting back up in a timely manner. This isn’t as common, since they are typically built with compiled languages, but no matter what, you are depending on the criminal’s unknown code to deliver the speed and quality you want.
221B’s workaround
We simply built our own decryption tools instead of using the criminal’s buggy software. Combining our key extraction tools (pulling the keys from the criminal decryption tools) with C compiled decryption functions and a python front end interface that we could modify on the fly, this enabled agile maneuverability for all the use cases we discussed above, and we could multi-thread the decryption process across multiple servers in parallel.
Why use their buggy tools when we could write our own decryption tools that are much faster, reliable, and trusted?