Lessons learned from a Cryptolocker virus attack

Last friday we were attacked from a Cryptolocker Virus. CryptoLocker is a ransomware trojan which targets computers running Microsoft Windows, believed to have first been posted to the Internet on 5 September 2013. CryptoLocker propagates via infected email attachments, and via an existing botnet; when activated, the malware encrypts certain types of files stored on local and mounted network drives using RSA public-key cryptography, with the private key stored only on the malware’s control servers. The malware then displays a message which offers to decrypt the data if a payment (through either Bitcoin or a pre-paid cash voucher) is made by a stated deadline, and threatened to delete the private key if the deadline passes. If the deadline is not met, the malware offered to decrypt data via an online service provided by the malware’s operators, for a significantly higher price in Bitcoin[1].

I was, despite my willing, the one that opened the door to the hackers. I received an email from one of our suppliers referring to a bill to pay. It was the first time I received it and I was a little suspicious, but it was, at least at a first glance, credible. It referred to a new contract we signed 8 months ago, for which we had some issues in paying the first bills due to problems they had in receiving the correct bank information. It was not a normal email, but a reasonable one. I tried to access the invoice document from my iMAC but it didn’t worked. The window opened in the browser said that the service was not supported on Mac browsers. It was strange but not so much, it happens sometime. I forwarded the email to our CFO and that was the big mistake. She tried to open the document from a Windows PC and the virus started to do its criminal job.  After ten minutes hep PC was totally encrypted and a popup appeared saying that all the files were encrypted and that we had to pay to recover them. Fortunately she was at her desk and could advice immediately our IT manager and myself. Before doing any kind of investigation we switched off the computer and disconnected from the network. The virus worked approximately 10 minutes and was able to encrypt the local PC and some files and directories in our various servers without a specific or logic schema.

Fortunately we have a pretty strong backup policy and almost everything was available in the previous night backup. It took about 5 hours to recover completely restoring the previous files, but the impact on our operations was really low. All our projects were untouched and all the software engineers could work without any problem.

Considering the happy end I can say it was a good stress test for our organization but honestly the risk was huge. Thinking to what happened there are several things we learned.

1. You are the best antivirus. We are on Office 365 and have a corporate Trend Micro antivirus deployed on each computer. Both of them could not intercept the message. If you have just a feeling that the email you received is “strange” (unusual, arrived in the wrong time, some uncommon or misspelled words, any graphic imperfection) check for details. Look at the small words, check any details that can help you verify the authenticity. In our case there was a small written VAT ID number that was wrong. I didn’t check it, but I had to. Check the mail address of the sender. Do not rely on the name that appears on the mail header, click on it and visualize the complete email address. Frequently the domain from which they are sent is inconsistent or reveals a different country (in our case it came from a .ro domain instead from a .it).

2. Investigation later. The best thing we did was switching off the PC before any investigation. If you see, or suspects, the PC is contaminated, unplug the power cord. You will have time to investigate the real situation and what happened later, in a isolated environment, possibly booting from a Linux OS so to avoid the virus continues its activity.

3. Backup and backup. We backup everything important each night. We replicate the virtual machines we use, we backup all the documents and in any case most of the files. Restoring the damaged directories we lost that we had just a few documents that were not available since the backup schema was a little outdated. We missed a couple of directories that were created “recently”. Be careful on how you manage your backups. If possible use a backup schema that guarantees that you can access the file versions you saved in different days. As soon as you recognize you need the backup stop the backup agent. Last thing you would like is to backup the damaged files and maybe overwrite the good ones you preciously saved.

4. Do not panic. Keep you brain active and effective. Do not loose control and act quickly and correctly. Speed is fundamental at the beginning.

5. Be prepared. I do not suggest to do simulations with real viruses to be prepared, but have a plan. Discuss it with your colleagues, analyze the possible scenarios, work on the “what if”. Do not limit your fantasy, think at the most unlikely situations. It will help. If possible write the plan in a document. You will have no time to read it when it happens, but it will help to consider all the possibilities and recognize any missing part. Review the plan periodically and try to stress it considering missing scenarios. Keep in mind that the type of attack you can suffer changes during time. A plan you defined two years ago will probably be not so efficient today.

1. Source: Wikipedia

You may also like

Digital Transformation Is Not Just a Shift From Analog
Three Steps to Start the Smart Manufacturing Journey
The Knowledge Required for IoT
CSIA Interview

1 Response

Leave a Reply