SMBs Under Siege: Ransomware Attack Aftermath – Paying the Ransom (Final Part)

This post is the wrap up to our three part series on Ransomware – Paid The Ransom.  You can find Part 1 and Part 2 in case you haven’t read them yet.  Here’s where we left off in Part 2:

  • The Bitcoin transaction has arrived at the destination
  • We left an update on the hacker support page
  • Only 3 days until our client’s deadline
  • Files are still encrypted
  • Panic is beginning to set in

Where’s The Program To Decrypt?

Silence and more silence.  Why isn’t the program available to decrypt?  Okay, let’s give it a few hours.  Maybe they are at lunch.  After all, it is only 9am EST and they are probably 5 – 6 hours ahead of us.  We start checking every 2 hours.  No response.  It is approaching the evening now.  Friday has come and gone without seeing the decryption program and no response on the hacker web site.  Keep in mind that you have to check the web site to get the decryption program.  It doesn’t arrive via email and we wouldn’t give out our email address anyway.  Our client can’t understand why it is taking so long.  The expectation is the program would be available once the payment arrives.  Reality is sometimes way different especially with no precedent.

Even Hackers Need Some Time Off

Hacker business is probably like any other job.  Sometimes it is boring and other times pretty exciting.  Our theory was that it was Friday night in some foreign land and we suspected that most of these folks are young.  What do most young people do on a Friday night?  You can probably guess.  Not what the client wanted to hear but we aren’t sure what the other reasons could be.  They were very responsive in the past.  We told the client we would would check around 3am Saturday morning to see if maybe the status had changed.  Time was running out.

Saturday – Only Two Days Left

3am came very early.  No change on the web site.  Interestingly enough the Bitcoin transaction had not been cashed in.  A few more hours of sleep and then back to checking every two hours.  We stayed in touch with the client with status updates via text.  Saturday came and went with no change.  Only 1 day left before the deadline hits.

The Program Is Ready!

730am on Sunday.  Time for another check.  The website has now changed and the program is ready to be downloaded.  I didn’t ask why the delay.  After all, no sense in ticking off the people that are in control.  We downloaded the zip file onto the client’s machine and extracted it.  The program, a decryption key  and instructions were the three files unzipped into our test folder.  The instructions are to copy and paste the key into the program, select an option and click Ok.  The program has three options to decrypt – the whole computer, a folder or a file.

Our strategy was to decrypt a small folder and verify that it worked properly.  We took the extra step to backup up all of the files on the client’s computer just in case the program goes whacko.  So we created the folder and copied a couple of encrypted PDF manual files into it.  Time to test!  We ran the program, entered the key and told the program to decrypt our test folder.  The screen showed the program processing the files, creating decrypted versions and it was done.  The original file was still in place and a new one added.  This new file had the word decrypted_ put in front of the original name.  So if the file name was Steve.doc, then the new file would be decrypted_Steve.doc.  The program created this new file so that the original would not be deleted.  Having a backup of the original file was great but this approach would create huge issues as you’ll soon read.  But were the files decrypted?  Yes they were.  Maybe we could pull off a miracle.  The client was ecstatic.  Only 1 day remained.  Now we can go after the entire hard drive.  Remember there were a number of folders and subfolders on the client’s hard drive.  There was no way to accurately determine how deep Teslacrypt had gone before we stopped it but we weren’t taking any chances.  Not much time left.

Bad Programming

Some really smart people created these programs for their own gain.  Not exactly proper but unfortunately it is the way of the world.  They were responsive to my questions and had delivered what they promised.  Unfortunately their program wouldn’t work as expected.

We started the program again, entered the decrypt key, told the program to start at C:\ and off it went.  File names were appearing on the screen and showing whether they were decrypted or not.  The program went after all files in a folder not just the ones it encrypted.  It was smart enough to know it had been encrypted but still had to check each and every file.  How long will it take?  It all would depend on the number of files on the computer.  The average desktop / laptop computer today will have more than one million files on its hard drive.

This Is Easy To Fix

Famous last words.  We updated the client and monitored the progress.  Unfortunately a little problem was occurring that would eventually “blow up” the program.  Two hours into the decryption process, the program stopped working.  The culprit was a memory leak.  The computer was out of memory because of bad programming techniques.  The program couldn’t handle the sheer number of folders and files that it had to check.  So it just stopped working.  How many folders did it do, where did it stop, did it finish the last file, where do we restart, can we restart were all questions in our minds.

More Trouble On The Horizon

More time was now needed to figure out where it stopped and then devise a plan to go after folders individually because of the now known memory leak.  We captured a list of all folders under the C:\ folder and processed the folders individually.  Four hours later all folders were complete.  Now we have a big problem.  Remember previously that the program created a new file for every encrypted file (Steve.doc and decrypted_Steve.doc).  The original name is what a program like Word, Excel, Acrobat, etc might look for.  That original name is still encrypted however a new file exists that is decrypted.  The problem is the new file now has to be renamed to the original name.  Folders can’t have the same file name more than once.  So why don’t we just rename the files and everything will be fine?  That is the right solution but did I mention how many decrypted files there are?

Ready For Some Stats?

So just how big is this problem?  Here are some figures to digest:

  • More than 19,000 folders have ransom notes in them
  • Not all ransom note folders have encrypted files
  • Over 210,000 ransom notes reside on the computer
  • 32,000+ files are actually encrypted.
  • 32,000+ new files now exist with the decrypted_ prefix

Not exactly a simple rename in Windows Explorer.  How do we get the new files back into the old name and remove the ransom notes?

And The Answer Is

We have to write a program that will do the following:

  • Discover all of the decrypted files
  • Remove the prefix (decrypted_) to get the original file name
  • Rename the original file to a unique name in this case hck+file name
  • Rename the decrypted_ file to the original name

We discussed with the client and there were two folders that were needed before the deadline.  We would address the remaining folders once they got past their deadline.  Our commitment was to get the computer back to them by 5pm Sunday.  It was now 2pm.  We quickly wrote and tested a program to do the above.  We then backed up the computer again and began the process to get things back to normal.  The computer was returned by 7pm that evening and they worked thru the night to meet their deadline.  They did an amazing job getting it done.  A disaster was narrowly avoided and the client’s reputation was intact.  It was a great feeling to see it all come together for the client.  A couple of weeks later we finished the remaining folders and the client was whole again.  What’s the lesson to this story?  Remember how it started.  Should you pay the ransom?

Reasons NOT To Pay

  • You have nothing to lose on your computer and can wipe it and start over
  • You have recent backups including a complete system backup
  • You don’t have money to pay the ransom

As with any business, technology is a requirement to STAY in business.  Any type of disaster like ransomware should not result in a threat to the business.  In this case, the client could afford to pay not only the ransom but very expensive services to fix it.  But even then there was still the risk that the hackers wouldn’t deliver the decryption program.  The client was fortunate.

Can You Prevent It From Happening?

Probably not.  There are things you can do to have better defenses to keep out bad stuff like Teslacrypt but the reality is it will never be enough.  The best solution to minimize the impact is having a proper backup strategy based on your needs.  This also goes for home computers where precious music files, pictures and other important files can easily be targets of ransomware.  There isn’t a one size fits all.  We can help you with that strategy.  Reach us here.

Now I have to ask.  Was it worth it to pay the ransom?  Weigh in with your comments below.  

1 thought on “SMBs Under Siege: Ransomware Attack Aftermath – Paying the Ransom (Final Part)

  1. […] grey hairs to come in Part 3.  Check back or sign up for our blog updates.  Or if you can’t wait, reach us […]

Comments are closed.

Scroll to top