CryptXXX Ransomware Learns the Samba, Other New Tricks With Version 3.100

Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditShare on Google+Share on TumblrPin on PinterestDigg this

Proofpoint researchers have been tracking the rapid development of CryptXXX since they first discovered the ransomware in April [1]. In mid-May, the first major CryptXXX update temporarily broke the decryption tool available from our colleagues at Kaspersky Labs and locked the screens of infected PCs, making it harder to access the file systems [3]. Last week, we observed the latest version of CryptXXX (Version 3.100) in the wild, which introduced additional capabilities including network share encryption. For the time being, at least, it has once again rendered the decryption tool ineffective.

This new round of updates means that even if users are able to decrypt their files, whether through an updated third-party tool or by paying the ransom, CryptXXX can still cause significant downtime by encrypting files on network shares. In this post, we also detail for the first time the StillerX module that underlies the information-stealing capabilities in CryptXXX and allows threat actors to sell credentials or launch targeted attacks.

Network Share Encryption

On May 24, Proofpoint researchers observed a new CryptXXX variant that exhibited interesting scanning activity on port 445. Port 445 is used for SMB (aka Server Message Block), and is primarily associated with Microsoft Windows Domain and Active Directory infrastructure. Infected machines were, in fact, scanning the /24 subnet of their local area network (LAN) in search of MS Windows shared drives. Further analysis demonstrated that this new version of CryptXXX was capable of finding shared resources on the network, enumerating files in every shared directory, and encrypting them one by one.

We can see how this works by examining the SMB traffic between the machine infected with CryptXXX and another machine sharing its resources over the network (Fig. 1). CryptXXX lists files by starting the search at the root of the shared drive, and descending in a breadth-first way into subsequent directories. Figure 2 shows the ransomware retrieving the list of files inside  ‘\My Pictures\Sample Pictures’.

Figure 1: Network capture illustrating CryptXXX using the Inter-Process Communication (IPC) of the SMB protocol to find the shared folder “SharedDocs” on a machine on the same LAN 

Figure 2: Network capture illustrating CryptXXX listing files in the “\My Pictures\Sample Pictures” folder

For files with extensions matching the list of encryptable files (see the complete list at the end of this post), CryptXXX will then proceed to query basic file information, read the file (Figure 3), and overwrite it with an encrypted version (Figure 4).

Figure 3: CryptXXX reading an image file over SMB. The JFIF header marker can be easily spotted in the clear-text payload.

Figure 4: CryptXXX overwriting (offset=0) the same file (FID=0x4005) with its encrypted version: the payload is encrypted and no clear-text image information is visible.

Once the file is overwritten, version 3.100 of CryptXXX renames the encrypted file by appending the filename with the .cryp1 extension. It is worth noting that previous versions of CryptXXX used the .crypt extension. Once the file is renamed, the malware searches the current file path for the presence of the recovery note (the file containing the ransom message). This activity is shown in Figure 5.

Figure 5: Addition of the .crypt extension and search for the presence of a recovery note in the current directory.

If, as in the case shown above, the recovery note is not found in the current directory, CryptXXX will proceed to upload a new ransom note to the shared directory (Figure 6). Note that this check happens for every encrypted file, as opposed to for every visited directory as one would expect. This means that, even if unnecessary, in a directory with 1000 files to encrypt, CryptXXX will search 1000 times for the presence of a recovery note.

Figure 6: Upload of the ransom note to the shared directory where a file has just been encrypted

Decryption Tool

As noted in previous blogs, our colleagues at Kaspersky Labs developed a decryption tool for files encrypted by CryptXXX Versions 1 and 2 [4]. However, this tool does not work for files encrypted with the latest version of the ransomware, as acknowledged by Kaspersky.

As of the writing of this blog, the Kaspersky “RannohDecryptor” was not yet updated to accept files with the “.crypt1” extension and does not do anything when given one as input. If we manually rename the extension to the old .crypt format, the tool throws an error.

Figure 7: No decryption support for the latest version implemented yet.

Although Kaspersky Labs were able to release an effective decryption tool quickly due to underlying similarities between CryptXXX and the older Rannoh ransomware, organizations and end users should not count on the presence of such a tool. Even when possible, decrypting individual files is time-consuming and scales poorly, especially as CryptXXX begins encrypting many more files across network shares. Similarly, as described below, the information stealing capabilities built into CryptXXX render organizations vulnerable even if they can recover critical files.


In order to further monetize the infections, CryptXXX downloads a DLL which acts as a credential stealing module. Internally referenced as “stiller.dll”, “stillerx.dll” and “stillerzzz.dll”, this DLL works as a plugin, but can also be used as a standalone stealer. The stealer, like the ransomware, is written in Delphi, and uses the object-oriented capabilities offered by the language. Its relatively large size on disk (around 1.2mb) is due to the static linking of several third party libraries such as DCPcrypt used for retrieving and decrypting locally stored credentials.

StillerX appears to be fully-featured and targets the credentials of a wide range of applications from poker software to Cisco VPN credentials. The malware makes extensive use of inheritance and “abstract” classes. Child classes inherit from the abstract classes based on the type of targeted programs (for example, TModule_ICQ2003 inherits from TModule_IM_Abstract). Figure 8 below shows a selection of such classes.

Figure 8: Sampling of class names implemented by the malware

The following is a partial list of targeted data:

  • Browser data (history, cookies, stored credentials)
  • Dialer credentials
  • Download managers credentials
  • Email credentials
  • FTP credentials
  • IM credentials
  • Poker software credentials
  • Proxy credentials
  • Remote administration software credentials
  • VPN credentials
  • WNetEnum Cached Passwords
  • Microsoft Credential Manager data

While the stealer is always deployed by CryptXXX, it is possible that it could be used as a standalone tool (and it is likely that this same malware was distributed in Bedep campaigns between December and March). Alongside the credential grabbing functions, we found unused routines handling system fingerprinting and data exfiltration. The “sysinfo” routine does not seem to be used because this task is carried out by the ransomware itself, but it would make sense in case of a standalone utilization. The “sysinfo” routine collects basic information about the host, such as the username, running processes, operating system details, Windows product ID key, and uptime of the computer. This information could be potentially used to spot fake data fed to the malware by sandboxes. Figure 9 illustrates the data formatting. Data exfiltration is performed using the same communication protocol on port 443.

Figure 9: Code snippet showing information collected by the stealer.

New Payment Portal

With the emergence of Version 3.100 on or around May 26, the payment portal received several cosmetic updates as mentioned in [2].

Figure 10: Updated lock screen now looks much simpler. Rebooting the computer gets rid of the lock screen but the user is able to read the ransom message notes left throughout the filesystem.

Figure 11: Home page of the payment portal hosted on an onion site, before the user enters their Identification Code

Figure 12: After entering their Identification Code, the user is allowed into the portal and has the option to pay in order to download the “UltraDeCrypter”

The versioning history for CryptXXX as observed in Proofpoint data is as follows:

  • 1.001 on April 16th
  • 2.000 on April 29th
  • 2.006 on May 9th
  • 2.007 on May 11th
  • 3.000 on May 16th
  • 3.002 on May 24th
  • 3.100 on May 26th


CryptXXX has become quite widespread, especially with a number of TeslaCrypt actors shifting operations to CryptXXX recently [5]. At the same time, the actors behind CryptXXX have continued to rapidly refine the ransomware with updates to encryption, scanning for network shares,  cosmetic updates, and updates to lock screen behavior. Because CryptXXX also includes robust information-stealing capabilities, multilayered network and endpoint protection are also critical to prevent data exfiltration in case of infection. CryptXXX updates have appeared very quickly over the last month and, without an available decryption tool, users and organizations must focus on detection and prevention.


Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditShare on Google+Share on TumblrPin on PinterestDigg this