Ransomware Alert: Pay2KeyNovember 6, 2020
Over the past week, an exceptional number of Israeli companies reported ransomware attacks. While some of the attacks were carried out by known ransomware strands like REvil and Ryuk, several large corporations experienced a full blown attack with a previously unknown ransomware variant names Pay2Key.
As days go by, more of the reported ransomware attacks turn out to be related to the new Pay2Key ransomware. The attacker followed the same procedure to gain a foothold, propagate and remotely control the infection within the compromised companies.
The investigation so far indicates the attacker may have gained access to the organizations’ networks some time before the attack, but presented an ability to make a rapid move of spreading the ransomware within an hour to the entire network. After completing the infection phase, the victims received a customized ransom note, with a relatively low demand of 7-9 bitcoins (~$110K-$140K).
The full scope of these attacks is still unraveling and is under investigation; but we, at Check Point Research and the Incident Response teams, would like to offer our initial analysis of this new ransomware variant, as well as to provide relevant IOC’s to help mitigate possible ongoing attacks.
- Previously unknown ransomware dubbed Pay2Key, carries targeted attacks against Israeli companies
- Initial infection is presumably made through RDP connection
- Lateral movement is made using psexec.exe to execute the ransomware on the different machines within the organization.
- Special attention was given to the design of the network communication, in order to reduce the noise a large number of encrypted machines may generate while contacting the Command and Control servers.
- The encryption scheme is solid – using the AES and RSA algorithms.
During the last days, we were able to obtain bits and pieces of information as well as various forensics artifacts from Israeli Incident Response teams, indicating that a new ransomware strain is being deployed against Israeli corporations (perhaps exclusively).
Combining these elements, we were able to bring together a partial image of the attacks as they unfolded:
- 2020-06-28 – The attacker created a KeyBase account by the name of “pay2key”
- 2020-10-26 – First ransomware sample compilation date
- 2020-10-27 – Second ransomware sample compilation date
- 2020-10-27 – First Pay2Key sample uploaded to VT and compiled on the same day – may indicate its first appearance in the wild.
- 2020-10-28 – Second ransomware sample uploaded to VT – Indicating a possible attacked organization.
- 2020-11-01 – Third sample compilation date
- 2020-11-01 – The first reported attack (Sunday; working day in Israel)
- 2020-11-02 – The second reported attack
The Pay2Key propagation appears to be conducted as follows:
- Right after midnight, the attackers connected to a machine on the targeted network most probably via RDP.
- A machine is defined as Pivot / Proxy point within the network, likely by using a program named “ConnectPC.exe”. All outgoing communication between all ransomware processes within the network and the attacker’s C&C server will be going through this proxy from this point on.
- The attacker used psexec.exe to execute “Cobalt.Client.exe”, which is the Pay2Key ransomware itself, on different machines within the organization.
Analyzing Pay2Key ransomware operation, we were unable to correlate it to any other existing ransomware strain, and it appears to be developed from scratch.
Only a single engine on VirusTotal detected the uploaded ransomware samples as malicious, even though the ransomware does not use a Packer or protection of any kind, to hide its internal functionality.
Numerous compilation artifacts point to the fact that internally, this ransomware is in fact named Cobalt (not to be confused with Cobalt Strike).
While the identity of the attacker is unknown, inconsistent English wording within the various strings found in the code, as well as the ones we observed in the Log file, suggests that the attacker is not a native English speaker.
After successful encryption, the ransomware drops a ransom note to the system, customized to the targeted corporation in the form of
[ORGANIZATION]_MESSAGE.TXT. The ransom amount ranges between 7 and 9 Bitcoins, among the ransom notes we observed.
Worth mentioning, that although the ransom note informs the victims for data breach, like other double extortion ransomwares do, we have yet to find any evidence that supports it.
One interesting thing to note is that the Keybase account used by the attacker to chat with their victims has the same logo of the Pay2Key EOSIO smart contract system. A possible explanation is the fact that when searching “pay2key” in Google images, this is the first result.
Our analysis of the attack by Pay2Key focused on the binary of the ransomware itself since some of the previous stages in the attack were not accessible to us. The attack, as we mentioned earlier, started by manually accessing one of the machines on the victim’s network, likely via RDP. The attacker copied and created multiple files on the machine, including:
- Cobalt.Client.exe – Pay2Key ransomware
- Config.ini – A configuration file that specifies “Server” and “Port”
- ConnectPC.exe – Pivot / Proxy server
After the creation of these files on the infected machine, the attackers execute
ConnectPC.exe. Then, they copied or downloaded the PsExec utility and used it to remotely execute the ransomware on other machines in the organization. In order to work properly, the ransomware requires a config file to be located in the same working directory. Thus,
Config.ini is required to be dropped in the victim’s computer along with
Cobalt.Client.exe. In the cases we’ve seen, the Pay2Key ransomware was executed from paths of this template:
The artifacts we were able to put our hands on are the ransomware,
Cobalt.Client.exe, and the configuration file. The configuration file is a very simple INI file that contained two entries — Server and Port. To our surprise, the Server wasn’t an external command and control server, but rather the IP of the initial infected machine. Thus, we believe that the original machine was using
ConnectPC.exe as a utility to relay communication from victims inside the organization to the external control server. This approach increases the chance that the different machines will be able to communicate because internal communication is more likely to be allowed. It also decreases the chances that the address of the command and control will be revealed by analysts as there is only one machine in the organization that knows of it.
The configuration file that was used in the attack looked like this:
[Config] Server = <internal IP address> Port = 5050
If the ransomware was executed with
--config [path] as a command-line argument, it will read the configuration file from the path specified in the argument.
The Pay2Key ransomware is written in C++ and compiled using MSVC++ 2015. It heavily relies on Object-Oriented Programming and uses well-designed classes for its operation. It also makes use of 3rd-party libraries like the popular libraries of Boost. Luckily, the ransomware was not stripped and it contained a decent amount of debug logs as well as rich RTTI information.
$ diec Cobalt.Client.exe PE: compiler: Microsoft Visual C/C++(2015 v.14.0)[-] PE: linker: Microsoft Linker(14.0, Visual Studio 2015 14.0*)[EXE32,console] $ rabin2 -I Cobalt.Client.exe | grep "compiled\|pdb" compiled Mon Oct 26 12:37:49 2020 dbg_file F:\2-Sources\21-FinalCobalt\Source\cobalt\Cobalt\Cobalt\Win32\Release\Client\Cobalt.Client.pdb
Upon execution, Pay2Key is reading the Server and Port keys from the configuration file. If a configuration file was not found in the current working directory and wasn’t supplied in the command line arguments, the ransomware will write “no config file found” to a file at
.\Cobalt-Client-log.txt. This log file will be used extensively by the ransomware during its execution. Newer versions of the ransomware are making sure to remove this log file from the disk. The full list of supported log messages can be found in the appendix section of this article.
It then initializes the main class of the program,
Cobalt::DataProcessing::RansomwareEngine, followed by initialization of other important classes that are responsible, among other things, for communication, message handling, managing files and encryption.
Pay2Key generates a pair of RSA keys and sends the public key to the server over raw TCP. The keys will be used to set up secure communication between the ransomware and the server. After sending the key, the ransomware will wait for messages from the server. These messages are parsed and handled by a custom Message Handler.
|0||PublicKey||Receive the server’s public key|
|1||Identification||Send to the server the IP address, the MAC address and the hostname.|
|2||Config||Receive a configuration from the server. The configuration is a very important aspect in the ransomware as it contains valuable information such as a list of file extensions to encrypt, the name of the victim’s organization, the ransom note, the extension of the encrypted file, and more.|
|4||SessionKey||Receive unique session key from the server|
|5||JobFinished||Announce that the encryption job is finished|
|6||Abort||Stop the execution|
|9||GetClientInformation||Send, upon request, status of different tasks like the encryption task.|
|10||ClientInformation||Send status of different tasks like the encryption task.|
|12||GetIdentification||Send to the server, upon request, the IP address, the MAC address and the hostname.|
The ransomware uses dedicated classes to handle different messages. We noticed some of these handlers and message types are not implemented in the binaries we have, and some of them aren’t even checked by the message handler manager. This is another indication that the ransomware is under active development. The missing messages, perhaps, can be part of code that is now removed, or alternatively — code that wasn’t implemented yet.
During the reverse engineering process of the ransomware samples, we utilized the fact they contain rich RTTI data. Such information helps us understand the role of different pieces of the code and the relationship between them. With the help of Cutter, we were able to inspect the different classes elegantly.
The most interesting message type is “Config” as it contains information that the ransomware use during the infection. Analyzing the ransomware without the information from this message results in constant fallbacks to default configurations. Among other things, the configuration message contains the list of file extensions to encrypt, the file extension for encrypted files (default
.enc), the name for the ransom note file (default to “salam” as in
SALAM_MESSAGE.TXT), and the ransom note.
It is interesting to mention, that both the file name and the ransom note specified the name of the infected organization. The attackers even went all the way to generate an ASCII-Art with the name of the infected organization. The file name of the ransom note from the config will have the following template
[ORGANIZATION]_MESSAGE.TXT. In the incidents we analyzed, the extension that was received from the server was
.pay2key, but it could have been anything else as the ransomware is flexible enough.
At the end of the encryption process, Pay2Key will also terminate the MS SQL service using the following command
net stop mssqlserver > nul in order to release the files locked by the service. It might also replace the wallpaper of the victim, but we did not see this happening on the machines we analyzed.
We analyzed multiple samples in a small period of time and we noticed several improvements in them. This means that Pay2Key is under active development and the developers update it with more features. For example, in the latest version of the ransomware, we noticed that the attackers added a Self Killing mechanism, in addition to a new command-line argument
The new “housekeeping” mechanism is responsible for removing the files created by the attacker and restarting the machine.
As standard for ransomware, a hybrid of symmetric and asymmetric cryptography is used for file encryption — using the AES and RSA algorithms. The C2 server supplies an RSA public key at runtime during communication. This implies that this ransomware doesn’t encrypt offline – if there’s no internet connection, or the C2 is down, then no encryption will occur. Recent years have seen some ransomware that aggressively use cryptographic primitives to put the onus of creating successful contact with the operations on the victim (e.g. by embedding the server public key in the executable), and at the time this was considered a technical improvement, but evidently the authors here prefer the classic flavor.
One unusual thing to point out is the use of RC4 for some (not all) of its cryptographic functions. RC4 is a stream cipher, and is easier to misuse in catastrophic ways; it is usually popular among malware authors for its ease of implementation, but here the authors actually used a third party implementation (via the Windows API). This may be the first ever time we’ve seen malware authors essentially say “we have the whole world of cryptography at our fingertips, third party libraries for everything, powerful symmetric crypto as far as the eye can see. Let’s pick… RC4”. But, again, for this to really matter would require some sort of subtle error when invoking the cipher, and we were not able to pinpoint one.
Another curiosity is the malware’s use of a custom-named key container named
pippo container. Other ransomware pretty much universally set a
null value for the
szContainer parameter, which defaults to a new key container — then performs all cryptographic operations with the context still open. It’s a piece of boilerplate code, a standard ransomware building block that is known to work and cybercriminals therefore copy, paste and forget; the fact that the authors did not use it outright is evidence for some amount of unhealthy curiosity about the windows cryptographic API and its capabilities.
One final deviation from the “classic” ransomware formula is the use of
CryptDeriveKey on a hashed value in order to derive an AES key (instead of the traditional
CryptGenKey ). If the hash values were derived deterministically then the resulting key could be reconstructed, but some element of randomness in the hash (or any other number of possible separate tweaks on the client or server side) could render this approach viable. Still, we can’t repeat enough that when it comes to cryptography, reinventing the wheel is not advised.
While the attack is still under investigation, the recent Pay2Key ransomware attacks indicate a new threat actor is joining the trend of targeted ransomware attacks – presenting well designed operation to maximize damage and minimize exposure.
The attack was observed targeting the Israeli private sector so far, but looking at the presented tactics, techniques, and procedures we see a potent actor who has no technical reason to limit his targets list to Israel. The incidents are still under investigation, and we will update this blogpost with new findings if any new findings come to light.
Check Point’s Anti-Ransomware solution defends organizations against the most sophisticated ransomware attacks, and safely recovers encrypted data, ensuring business continuity and productivity. Anti-Ransomware is offered as part of Check Point’s comprehensive endpoint security suite, SandBlast Agent, to deliver real-time threat prevention to your organization’s endpoints.
We would like to thank the researchers from Claroty Research for their assistance and collaboration during this research.
Check Point Protections
Threat Cloud Protections:
Threat Emulation Protections:
Indicators of Compromise
List of Classes retrieved from Cutter based on RTTI information in the binary:
Base classes: Cobalt::Common::IDecryptor Cobalt::Common::IDirectory Cobalt::Common::IEncryptor Cobalt::Common::IException Cobalt::Common::IExceptionFactory Cobalt::Common::IFile Cobalt::Common::IFileMatcher Cobalt::DataAccess::IFileReader Cobalt::DataAccess::IFileWriter Cobalt::DataAccess::ISystemFileManager Cobalt::DataAccess::IWindowsDrive Cobalt::Peripheral::IPeripheralConnection Classes: Cobalt::Common::MyselfKiller Cobalt::Common::CommonExceptionFactory, Base Classes: : Cobalt::Common::IExceptionFactory Cobalt::Communication::AbortMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::AcknowledgeMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::ClientInformation, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::ConfigurationMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::ExceptionMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage, Cobalt::Common::IException Cobalt::Communication::ExceptionMessage_1, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage, Cobalt::Common::IException Cobalt::Communication::GetClientInformation, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::GetIdentificationMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::IMessage Cobalt::Communication::IMessageExtractor Cobalt::Communication::IMessageFactory Cobalt::Communication::IMessagePackager Cobalt::Communication::ISerializableMessage Cobalt::Communication::IdentificationMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::JobFinishedMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::MessageExtractor, Base Classes: : Cobalt::Communication::IMessageExtractor Cobalt::Communication::MessageFactory, Base Classes: : Cobalt::Communication::IMessageFactory Cobalt::Communication::MessagePackager, Base Classes: : Cobalt::Communication::IMessagePackager Cobalt::Communication::PublicKeyMessage, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::Communication::SessionKey, Base Classes: : Cobalt::Communication::ISerializableMessage, Cobalt::Communication::IMessage Cobalt::DataAccess::BasicFileReader, Base Classes: : Cobalt::DataAccess::IFileReader Cobalt::DataAccess::BasicFileWriter, Base Classes: : Cobalt::DataAccess::IFileWriter Cobalt::DataAccess::WindowsDirectory, Base Classes: : Cobalt::Common::IDirectory Cobalt::DataAccess::WindowsDriveHandler, Base Classes: : Cobalt::DataAccess::IWindowsDrive Cobalt::DataAccess::WindowsFile, Base Classes: : Cobalt::Common::IFile Cobalt::DataAccess::WindowsFileManager, Base Classes: : Cobalt::DataAccess::ISystemFileManager Cobalt::DataProcessing::AESEncryptor, Base Classes: : Cobalt::Common::IEncryptor Cobalt::DataProcessing::ExtensionFileMatcher, Base Classes: : Cobalt::Common::IFileMatcher Cobalt::DataProcessing::RSAClient, Base Classes: : Cobalt::Common::IEncryptor Cobalt::DataProcessing::RSAServer, Base Classes: : Cobalt::Common::IDecryptor Cobalt::Peripheral::TCPClient, Base Classes: : Cobalt::Peripheral::IPeripheralConnection, std::enable_shared_from_this_class_Cobalt::Peripheral::TCPClient_
Suspected file paths
C:\Windows\IME\en-GB\client\Cobalt.Client.exe C:\Windows\IME\en-GB\mngr\ConnectPC.exe C:\Windows\IME\en-GB\mngr\binPS\PsExec.exe C:\Windows\Temp\[organization-name]tmp\Cobalt.Client.exe
Strings Written to the Log
Deleting Myself Restarting Application Closed wrong config file no config file found Prevent ShutDown end of main procedure message is encrypted message is not encrypted Cannot initialize RSA encryptor Cannot initialize RSA decryptor Error: receiving wrong response receiving server public key Error: receiving wrong response receiving session_key Error: receiving Configuration Message Start Encrypting Engine GetClientInformation message received Sending Identification message again Receive Abort Message Connection Restarted Sending Identification Message Error in getting ipaddress and macaddress Sending public key Sending public key finished send_session_key Wait for threads to finish their encrypting job End of encrypting Change Computer Background Send Job Finished Message We are not connected to serverr, trying 3 second later Send Message in Another Thread Send message again time out reached Connect Again to Server Sending Message Process Finished copy file to desktop background path Receive Data Failed To Get Data.... Start Searching Details of Drive Its in Black Path List