Thorium incident : the end of a startup
Thursday 4:15 p.m.
Our office phone is ringing.The founder of a development startup in the entertainment industry is online. His team has been working for 2 years on a revolutionary software and unfortunately their development server has just been infected by ransomware. The startup had a backup server that was connected directly to the development server. So the backups were also encrypted by the ransomware. The company does not have any other backups.
We collect information on the response measures already taken by the company and take the company's address. The client informs us that he has already exchanged a few emails with the hacker who is asking for a ransom of approximately $100,000 payable in Bitcoins. The startup in question has very little resources and could not even pay a ransom of $7000 according to our interlocutor.
Thursday 4:30 p.m.
As with all emergencies, we bring our incident response team together in our crisis management room for debriefing. In this case, since the client has no back-up, the challenge is to allow them to decrypt their data without having to pay the ransom.
An incident response expert from our team is sent to the client to take charge of the situation.
Thursday 6:15 p.m.
Our expert arrives at the startup's premises and finds a collapsed founder.
Following the debriefing, he quickly mentions that the startup is playing for its survival because if it loses its software developed in 2 years, it will unfortunately have to cease its activities. The founder negotiated in vain with the pirate who refuses to compromise and stubbornly holds on to "his 100 000$". A scenario that we know perfectly well for having handled several similar cases. In such a situation, the pirate thinks he has suffered and worked so hard to finally find a victim, that he deserves a big reward. Especially since they are not convinced to make new victims. This is usually the attitude of novice or unstructured hackers.
Thursday, 6:30 p.m.
We make a phone call and agree on a plan of action. The urgency is to find a copy of the ransomware and analyze it to see if it is possible by some means to find the encryption key.
Thursday 7:03 P.M.
A copy of the ransomware is found. Our incident response expert sends a copy of the ransomware executable to our Managed Detection and Response (MDR) team who remotely dissects and analyzes it to determine its behavior, propagation and encryption mode. The customer informs us that there is no urgency to resolve the situation. We therefore agree that the analysis of the ransomware will take place the next day.
Friday, 9:03 a.m.
The ransomware is analyzed by our DRG team and we are able to determine how it entered the company's network. It all started with a brute force attack via an RDP server (Remote desktop or remote connection) of the startup that was accessible on the Internet. Once the hacker had access to the RDP server, he located the development server, connected to it and manually executed the ransomware. The ransomware does not establish any external communication with any command and control unit. There is no exchange of encryption keys. Therefore, we are not able to find the decryption key. We consider alternative methods of decryption key recovery and inform the customer.
Friday 1:53 p.m.
Other methods of recovering decryption keys that we have tried have not been positive. We inform the founder of the startup and feel his level of concern increasing. We believe that the investigations should be stopped in order not to add to his bill, especially since we are certain that his data can be recovered without payment of the ransom. The founder informs us that he must discuss with his partners and get back to us.
Friday 5:19 p.m.
The founder calls us and informs us that he has undertaken a search for funds to pay the ransom and that unfortunately the motive for the search for funds makes lenders cold. No loan has been granted to him. The cessation of his company's activities seems more and more unavoidable to him, because he has neither the energy nor the means to start afresh.
Friday following 3:00 p.m.
We do an internal debriefing and decide not to charge the client in view of the situation he is experiencing.
A week after the incident, the founder informs us that his company is closing down. Sad end for a startup that paradoxically had been created to entertain... The worst thing in the story: the attack was not targeted. A random attack that ended in the saddest possible way.
Whether you are a large company or a small business, if such a random attack targeted your critical infrastructure, would you be able to get up?