In the past few months, we have witnessed several indiscriminate attacks targeting big companies. Whereas years ago different threat actors focused on specific sectors, nowadays the same techniques, tactics, and procedures (e.g., how the perimeter is penetrated, which tools are used for lateral movement) are consistently applied regardless of company size, location, or industry. Target selection is much more dependent on an organization’s IT infrastructure: for example, recent trends show several actors (among them REvil, HelloKitty, or what was known as Darkside) increasingly targeting companies running workloads on VMware ESXi by adding to their ransomware capabilities to gracefully stop virtual machines before encrypting them (see Figure 1).
Another important trend we have seen growing in the last few months is the use of ransomware to seize sensitive customer data — first by exfiltrating it, then encrypting it, and later pressuring the victim into paying a ransom under the threat of disclosing such data publicly (a technique called “double extortion”). Notable victims include CD Projekt RED, which faced the leak of the source code of some of its most famous video games.
While many threat reports have already dissected the technical internals of the malware involved (see here for a well detailed reverse engineering of a HelloKitty sample, including an analysis of its cryptography primitives), we rarely see how the negotiation between a threat actor and its victims unfolds (without irony, the victims are often termed “customers” by the threat operators). More importantly, there isn’t much discussion of the risks involved in dealing with parties that are actual cybercrime enterprises.
To shed some light on all these matters, in this blog post we give a brief peek into what happens to a victim when infected by the Linux version of HelloKitty ransomware, a known variant targeting ESXi workloads. While we do not focus on a specific sample or campaign, it is relatively easy to acquire a small dataset if the sample has been uploaded to VirusTotal. Searching for the ransom note extension “content: “.README_TO_RESTORE” is an effective method to select a mix of HelloKitty samples (or one of its most recent spin-offs, ViceSociety).
The note, or the start of the journey
While the image of thousands of monitors displaying the WannaCry ransom window is still engraved in our collective memory, nowadays ransomware attacks on workloads are perceived by users as a sudden loss of service availability. The system administrator is then confronted with the entire data directory tree suddenly containing encrypted files and a ransom note (see Figure 2 for the ransom note dropped during an attack on an Italian company operating in the health care sector).
Interestingly, this file has information both for the victim to get in touch with the attacker and for the attacker to get the necessary cryptographic details to develop a decryptor. This is of primary importance: the victim, as we will see later, is encouraged to ask for a free decryption sample as a way to verify the trustworthiness of the attacker. As every customer knows, a smooth first “technical support” experience is the perfect welcoming mat to a successful business transaction.
The ransom note ends with a link to a TOR website. Note that there is no password or authentication required; in other words, anybody holding a copy of the ransom note can access the very same website the victim is invited to use. This would not be a concern if the process of paying the ransom were just a matter of uploading a file (the ransom note, for example) and providing credit card details; unfortunately, the whole process is more akin to a technical support interaction rather than a shopping experience — everything takes place within the boundary of a persistent public chat window.
The chat, or getting to know each other
Figure 3 shows the first exchange of messages between a victim and the support engineer operating the ransomware infrastructure. As we can see, the priority for the victim is to ascertain whether the chat is authentic, and if the threat actor is actually able to decrypt the files. If the victim is not aware of this possibility, the attacker reminds the victim of this fact by disguising it as a goodwill gesture.
Unfortunately, files are transferred in the least secure manner possible: using public file sharing services. This means that anybody accessing the chat can retrieve any file exchanged. As the password is also shared using the same channel, the victim should think carefully about which file to use for a free decryption. The incentive here is for the victim to recover his most prized (and thus sensitive) possession: in some cases, this means a full-fledged virtual machine file, possibly containing highly sensitive data; on the other hand, the threat actor is only willing to allow some “not important” files to test decryption (in the case of running ESXi, log files were requested).
Obtaining a decryption is not instantaneous, and questions requiring engineering expertise or technical work are often ignored or only answered after several hours. This shows how the threat actor divides its workforce like modern businesses do, having non-technical staff as first-level technical support while keeping engineers and developers far from the “front line”. This also means that any attempts to outsmart the operator by, for example, asking to decrypt backups, are eventually detected and not well-received. In the best-case scenario, they are the fastest way out of negotiating a discount (see Figure 4); in the worst case, they may be enough to push the actor to hike the ransom or leak the exfiltrated data.
The deal, or the cash does the talking
While we are used to thinking of a negotiation as something agreed between two parties, victims participating in this type of chat are rarely able to make business choices for themselves. For example, the system administrator on the victim’s side cannot make any decision regarding the payments, especially if amounts of several million dollars are involved. Likewise, the chat operator cannot develop the decryptor or even decrypt test files alone, as he relies on other teams. This leads to a lengthy ping-pong, which can last as much as two or three weeks, before any of the parties decide to commit to the deal.
The first choice that the victims must make is whether they are ready to pay up for the data or they only want to make sure that the data does not get leaked (the double extortion). Advice such as “make your backups” or “have a disaster recovery plan,” while sound, and rightly part of any company’s proper security posture, quickly lose their importance if the future of the company and its competitive advantage in the market are at stake with a leak. In other words, at this point, the availability of backups means only the ability to choose the least expensive extortion. Defending the perimeter and preventing lateral movement should still be an enterprise’s foremost priority.
The price negotiation is also utterly unfair: the threat actor is already in possession of all the data, and, with some luck, has also gained access to the company financials. This means that the threat actor can adjust the ransom to what the company is able to pay, and if the victim objects that they can’t afford such a steep transaction, they either need to provide some proof by coming up with a compelling story or convince upper management that there is no viable alternative. This also needs to be done quickly, as chat operators can grow impatient (see Figure 5).
Obviously, it is not in the interest of the threat actor to pull the rug out from under the negotiation at this point, and threats at this phase should simply be seen as brinkmanship. See, for example, the chat operator calling for a “more constructive approach” after being ignored for a couple of days. The threat actor does not gain anything by leaking the data, they have every incentive to come to an agreement, whether it is for 10 million dollars or 5. At the same time, the threat must be made credible, and one way to do this is to apply pressure by pretending that time is a concern. It is often not the case; a proposal for a “constructive and responsible approach” (see Figure 5) can always be extended.
Another interesting aspect of the negotiation is that it is often possible to pay the ransom either in Bitcoin or in Monero. While both cryptocurrencies are fungible, Monero is much more private, as the actual recipient of a transaction is kept hidden. As shown in Figure 6, this fact is known by both the victim and the threat actor. While accepting both types of payment, the threat actor charges up to 10% more when payment is done in Bitcoin; at the same time, banks (because the victim needs to involve a bank when transferring this amount of money) prefer Bitcoin, precisely because Monero is an asset more closely associated with money laundering, and thus more difficult to manage.
When the deal is sealed and the transaction is confirmed, the threat actor morphs into your everyday technical support account specialist: if the decryptor does not work, engineers are promptly involved to fix it. Often it is the victim who asks for the chat to remain online, at least until the entire decryption process is completed. While we fully understand that after paying several million dollars the victim would want to make sure there is a way to reach out to the threat actor if needed, we cannot help but point out that this makes any exchanged files available for download in the public transcripts of . We performed a cursory check of all the chats referenced in the samples uploaded to VirusTotal, and in all cases the chat contained accessible files (which we did not download).
Keep in mind that chat operators do not respond kindly if they feel played around with, so if your aim is to collect additional threat intelligence, you will need a more convincing cover story than our feeble attempt, in which we tried to extract the name of the targeted company from a chat in which the victim did not reach out to the threat actor (see Figure 7).
Conclusions
Ransomware is one of the worst nightmares a company can go through nowadays. It is vitally important for enterprises to keep infrastructure and workloads well-protected from every possible threat lurking in a data center, as attackers have been pivoting for some time now from end users to large companies, where big payouts are possible. After all, why ransom 100 people for $300 when you can ransom a single company for $3 million? In conclusion, our advice is to be aware that all communications and file exchanges are publicly accessible, and careless interactions with ransomware operators may cause additional embarrassment even if the ransom is paid.
