Pay2Key Ransomware Joins the Threat Landscape
As we approach the end of a year that has been trying for so many reasons, yet another ransomware has been seen in the wild targeting corporations—in particular, Israeli companies. A report published by Check Point Software tells of the new ransomware, which is called Pay2Key based on the heading of its ransom note but at one point it seems its developer wanted to call it Cobalt (not to be confused with Cobalt Strike, a tool used by hackers to check for penetration vulnerabilities).
Pay2Key can be considered a new and unique ransomware variant given that, based on initial analysis, it was built from the ground up with no obvious links to other ransomware families. The ransomware is written in C++ and the encryption process is robust, with no discovered errors that could help researchers develop an encryption key. Other notable features include the now-infamous double extortion tactic and the demand amounts to decrypt files are relatively low when compared to other ransomware families—$110,000 to $140,000 USD in Bitcoin. Further, the attacker will compromise the target network sometime before encryptions occur so that when the attacker does decide to deploy the ransomware they can spread the malware rapidly across a network, completing the encryption process in an hour.
Pay2Key Network Compromise
Given the relative youth of the ransomware, the exact infection chain is yet to be mapped out completely. Researchers believe that access to the network is achieved manually by the attacker via a vulnerable RDP port, a favorite tactic for ransomware operators. Once the network is compromised, the attacker copies several files over to the compromised machine including Cobalt.Client.exe, the Pay2Key ransomware and important configuration files.
The configuration files deserve special mention as they only contain two entries, Server and Port. Unlike with many other ransomware strains, the server entry is not through a connection to a command-and-control server; rather, it is through the IP address of the infected machine. This approach has both advantages and disadvantages: It allows the possibility for multiple machines to communicate with the infected machine, as internal communications will be allowed; however, the address of the command-and-control server would be difficult to trace by researchers as it wouldn’t be revealed via the entries, as has been seen in the past.
According to researchers, the ransomware relies heavily on object-orientated programming methodologies that emphasize organizing code around data structures rather than functions and logic. The code features well-constructed classes and uses several third-party libraries, including the popular library Boost. The code makes extensive use of log files, which have helped efforts to analyze the ransomware greatly; however, newer versions are making sure to delete log files to make further analysis far more difficult.
Files encrypted by Pay2Key ransomware:
The main class of the program, “Cobalt::DataProcessing::RansomwareEngine,” is responsible for most of the key features of the malware including communication, message handling, managing files and encryption. Another interesting note on the code is that Pay2Key will generate a pair of RSA keys and send the public key to the server over TCP. These keys are used to set up communication between the server and infected machine so messages can be received and the ransomware can enact them.
The ransom note can be customized to include the victim’s name and different ASCII art depending on the victim. Researchers also noted that the extension added to encrypted files is .pay2key; however, the code is robust enough for this to be changed to anything the attacker wants in the future.
Ransom demanding message:
During the period when the ransomware was analyzed researchers noted multiple versions had been developed, each showing slight improvements over previous versions. The most notable improvement was a “housekeeping” feature capable of deleting files added by the attacker and restarting the targeted machine.
Over the years the industry standard for ransomware encryption is to apply a hybrid of asymmetric and symmetric encryption algorithms, typically the use of AES and RSA algorithms. Pay2Key has adopted this standard but has included a few quirks to make it worthy of a special mention. As the command-and-control server supplies the RSA key, it can be safely assumed that the ransomware is not capable of offline encryption. The malware’s developer has also opted not to include cryptographic primitives that are used to contact the victim.
The quirk in the encryption process is the use of the RC4 algorithm for some of the encryption process. RC4 is easier to implement but the cipher is easier to misuse, which could cause the encryption process to fail. To implement the cipher, the developers used a third-party implementation via Windows API; this tactic is odd in the sense that with all the choices now available to malware authors, including incredibly powerful symmetric ciphers, RC4 with its known liabilities seems counterintuitive. This would be more of an issue if the researchers could find an error in its use, but none could be found. The encryption process is solid and it is unlikely a decryptor can be developed from failure in the encryption process.
Victims Paying the Ransom
About a week after it released its initial analysis, Check Point published a follow-up analysis. This time the focus was less on the ransomware’s code and more who is the possible threat actor behind Pay2Key’s distribution. This information comes about as a silver lining to the fact that some of the victims ended up paying the ransom—by victims paying the ransom, cryptocurrency specialists were able to trace the wallets in which the ransom was going and the services that were used to handle the Bitcoin paid by victims. While the vast majority of victims were Israeli organizations, one at least is based in Europe.
The Double Extortion Tactic
When Pay2Key initially was analyzed, the ransom notes said the attacker had stolen data from the victim and would release the information if the ransom was not paid. This forms the heart of the double extortion tactic: stealing data and then releasing it if no ransom is paid. However, during the initial analysis, there was no evidence that Pay2Key had indeed stolen data from victims. Typically, other ransomware operators set up websites on the dark web that act as a blog and information-leak site. Often the attacker will announce a victim and provide a small bit of data stolen to prove they had done what they claim.
At the time of the initial analysis, no such website appeared to be in place. That soon changed. By the time the second report was published, the attackers had started a website and leaked the data of three Israeli organizations, including sensitive data such as information pertaining to domain, servers and backups. Of the three, one was a law firm and another a game development company. Data from the law firm was released as soon as the deadline to pay the ransom was hit. The game developer apparently was given an extension, but to prove they had stolen data the attacker released information pertaining to the victim’s NAS servers and then released a supposed finance-related folder. In both cases, the attackers alleged to have hundreds of gigabytes of data.
Following the Bitcoin
At the time the second report was released, four victims had paid the ransom, giving researchers an opportunity to trace the movement of the fund, which hopefully will help prove the identities of those behind Pay2Key beyond a doubt in the near future. Once the victims paid the ransom to the wallet address mentioned in the note, attackers would then move the funds to another intermediary wallet. This wallet has been used for several victims as a stop before being sent to the final wallet. This final stop is a high-activity cluster, which suggests it was owned by a financial institution or exchange.
This assumption was proved correct. When the final wallet’s address was analyzed and tracked, researchers found it belonged to an Iranian cryptocurrency exchange. The exchange was set up to provide secure cryptocurrency exchange services to Iranian citizens. To use the exchange’s services, the user must have a valid Iranian contact number and ID number, and to actively trade cryptocurrencies, the exchange needs a copy of the ID. This does point strongly to the attacker being Iranian; however, Iranian money mules possibly are being used to launder the funds once they reach the exchange. Here again, however, there is a strong possibility the threat actor is Iranian.
Another trend has emerged that points to the threat actors behind Pay2Key being Iranian: Iranian-led ransomware attacks targeting Israeli organizations have been noted by other security firms. In September, several campaigns were seen that were attributed to an Iranian APT group MuddyWater, known for exploiting the ZeroLogon flaw. During the campaign, researchers noted that the attackers attempted to install PowGoop, a malicious replacement for a Google update dll that has been used as a loader for the Thanos ransomware. Further, it is believed that the use of Thanos is a smokescreen to deploy more destructive malware such as wipers, a signature tactic used by several Iranian APT groups. The entire campaign has been codenamed “Operation Quicksand” and has received a fair amount of media attention.
The use of Thanos in such a way is reminiscent of the NotPetya attacks of 2017, in which ransomware was used as a smokescreen to cause disruption among those deemed state enemies by Russian authorities. In particular, the deployment of NotPetya was intended to cause significant disruption to the Ukrainian financial sector.
There are currently no indications that those behind Pay2Key are state-sponsored. Further, given how the attackers have been willing to use exchanges to launder the funds extorted from victims and the fact that Pay2Key doesn’t include any destructive features other than the ransomware, the attacker is likely financially motivated. It is not unheard of for state-sponsored groups to pursue financial aims—the Lazarus Group is seen to be behind VHD ransomware distribution—but currently more evidence is needed that points to a state-sponsored group behind Pay2Key.