In recent years, ransomware families are often glamorized as being some of the most dangerous types of malware. They’ve certainly caused a wealth of damage to end users with some of the more prominent malware families, such as CryptoLocker, CryptoWall, TorrentLocker, and TeslaCrypt infecting millions of users overall.
For readers that might be unfamiliar with ransomware, it’s a type of malware that is responsible for encrypting a user’s files with a key known only to the attackers. Examples of files that might be encrypted include financial documents, home movies, photos, or business-related files. In order to decrypt these files, the victim must provide a ransom, or payment, to the attacker, often in the form of a digital currency.
While ransomware is often thought to be bullet-proof, it is certainly not always the case. In early 2015, Emnisoft identified a new family of malware named PClock. At the time, the malware was riddled with issues, specifically in the way it encrypted files. It used a simple XOR encryption routine with a static key, allowing victims to easily recover their files without paying a ransom.
In August, we started detecting updated copies of PClock, which has been improved upon by the malware author. We set out to determine if this updated version of PClock holds up to some of the more prominent families. For the sake of clarity, I will refer to this newer version of PClock as PClock2 going forward.
The following sample is used for analysis:
|Compile Time||2015-08-23 20:55:38 UTC|
Figure 1. PClock2 analysis sample
PClock2 is written in Visual Basic. For a copy of this file’s IDA Pro database (idb), please refer here.
When initially executed, PClock2 performs a very simple anti-analysis check where it will sleep for a random amount of time and compare the time spent sleeping against a set value. This check is essentially looking for sandbox systems where the sleep function accelerates analysis.
Figure 2. Check by PClock2 for hooking of sleep function
A simple check is performed to determine if the malware is running with administrative privileges. Once completed, the malware sends the result via an HTTP POST request to a remote server. All data sent via HTTP POST requests is sent in the clear.
Figure 3. HTTP POST request containing administrative privileges
The ‘P0’ is statically set by the malware in the above request. The ‘1828’ represents the thread ID (TID) of the malware, while the ‘rnd’ GET variable is randomly generated.
Throughout the runtime of PClock2, it makes multiple HTTP POST requests to a remote server using the same characteristics, including the ‘PO[TID]’ and the current time. Additionally, the user-agent used by the entire PClock family, including PClock2, is consistent across samples.
PClock2 proceeds to copy itself with the name “winjab.exe” in the following path. While this particular sample is seen installing itself to the %ALLUSERSPROFILE% path, other samples have been witnessed using %APPDATA% instead.
PClock2 also enables persistence by setting the following registry key. All instances of the entire PClock family have been found to use this particular registry key.
After installation is complete, the malware makes another HTTP POST containing the various file paths it used.
Figure 4. HTTP POST request containing file paths of malware
After installation, PClock2 will also set the following registry key with a value of ‘INSTALL_OK’.
- HKCU\Software\VB and VBA Program Settings\CLOCK\SData\S
This particular registry key is used to hold the latest state of the malware. Other messages that might be present in this key include the following.
- FSO object created
The following registry keys are also used within the CLOCK sub-path by PClock2:
|\BData\B||Holds current Bitcoin price|
|\CData\C||Holds key generated by PClock2 used in encryption|
|\EData\E||Date when key will be destroyed|
|\FData\F||The number of files identified for encryption|
|\WData\W||Unique bitcoin address used to forward payments to the attackers true bitcoin address|
PClock2 proceeds to use the API from blockchain.info to generate a unique Bitcoin (BTC) wallet identifier, which is configured to automatically forward payments to a hardcoded wallet identifier of ‘1MRfkK134ErfbcadUSoSUCBahngCqoBKju’. The following HTTPS request accomplishes this.
PClock2 will also make a request to the following blockchain.info address to determine the current value of BTC. This information is stored in the ‘\BData\B’ registry key as previously stated.
The malware proceeds to generate a unique key that will be used in subsequent file encryption using the following data:
- Current Time
- Process ID
- Process Heap
- Active Window
- Clipboard Owner
- Desktop Window
- Foreground Window
- Shell Window
This data is concatenated to form a string similar to the following:
Figure 5. Data collected to be used in formation of unique key
This data is then hashed using the SHA256 algorithm to generate a unique key. This key is stored in the ‘\CData\C’ registry key as previously stated. This key is also sent via a HTTP POST request.
Figure 6. HTTP POST request containing unique SHA256 key
PClock2 scans the file system of the victim in order to identify files that are to be encrypted. The following paths are ignored:
- \Application Data
- \Local Settings
- \Program Files
- Sample Music
- Sample Pictures
Additionally, for a list of targeted file types, please see the following link.
Once files are identified, PClock will begin encrypting them, one-by-one. Unlike the original version of PClock, this variant has forgone the simple XOR encryption routine in place of using RC4. The RC4 key is generated by concatenating the SHA256 value previously generated with the path to the file being encrypted.
250dd811187959220220574a185ccf669e06c0ee3926773a7cb94750c401812cC:\Documents and Settings\Administrator\Desktop\Form1.cs
It should be noted that PClock takes a very long time to encrypt these files. On a test sandbox, the malware took upwards of 20 minutes to complete encryption, which is less than ideal for an attacker as it gives the victim time to notice the infection and stop it. By comparison, the latest version of the CryptoWall malware family takes roughly 1-3 minutes to complete its encryption routine.
It’s also interesting to note that each time PClock2 scans a directory or encrypts a file, it makes an HTTP POST request to the C2 server.
Figure 7. HTTP POST request indicating a folder is being scanned
This resulted in over 1,000 requests being made on a sandbox machine, which contained little data of interest.
After it finished the encryption routine, PClock2 generates a VBScript file in the following directory:
This script file contains the following commands, which will delete shadow copies on the Windows operating system.
Set UAC = CreateObject("Shell.Application")
UAC.ShellExecute "vssadmin", "Delete Shadows /All /Quiet", "", "runas", 1
On Windows XP, the following dialog box appears to the victim when this script runs, making it fairly apparent that something suspicious is occurring:
Figure 8. Dialog box that appears to victim when VBS attempts to run
After running the clean up script the malware overwrites the ‘\CData\C’ registry key with a value of zero, which removes the unique SHA256 key. Finally, the malware changes the victim’s wallpaper and generates a GUI instructing the victim how they can provide payment and retrieve their files. This dialogue mimics the more-capable “CryptoLocker” malware family and provides instructions in both English and Spanish.
Figure 9. Ransom demand
I originally wished to determine if the new version of PClock, PClock 2, included enough improvements to compete with some of the larger ransomware malware families, such as CryptoWall, TeslaCrypt, or TorrentLocker. In truth, this version has made a number of improvements, such as adding more file types to target, ignoring certain directories, and using a better encryption routine.
However, a number of strong issues still plague this malware family, such as the following:
- 20+ minute runtime for the malware to complete
- 1000+ HTTP POST requests made
- Dialog pop-ups to the victim requiring user input
While this version is an improvement, it still lacks many of the features and stealth that are currently present in the larger ransomware families. While ransomware is a large problem for users, it’s important to realize that not all malware families are created equal. Like most things in life, malware comes in many shapes and forms, from the more elegant and robust solutions, to those that come up lacking.
All PClock malware family samples are properly classified as malicious by WildFire. AutoFocus users can find more information on samples and indicators related to this attack by viewing the PClock tag.