Software as a service (or SaaS) is a relatively new model of how a lot of software companies are conducting their business today – often to great success. So it comes as no surprise that malware writers and cyber crooks are attempting to adopt this model for their own nefarious purposes. In the past year a whole bunch of these “Ransomware as a Service” campaigns appeared, like for example Tox, Fakben or Radamant. Today we want to spotlight the newest of these campaigns.
At first glance Ransom32 looks like a dime a dozen among many similar malware campaigns. Signups are handled via a hidden server in the Tor network. A simple Bitcoin address where you want the funds generated by your ransomware to be sent to is enough to signup.
After you type in your Bitcoin address, you will get access to the rudimentary administration panel. In the admin panel, you can get various statistics, like for example how many people already paid or how many systems were infected. You can also configure your “client”, which is their term for the actual malware. It is possible to change the amount of Bitcoins the malware will ask for, as well as configure parameters like fake message boxes the malware is supposed to show during install.
A click on “Download client.scr” will then generate the malware according to the specifications and will start the download of the more than 22 MB large malware file. At this point it becomes evident that Ransom32 is very different to other ransomware, which rarely exceed 1 MB in size. In fact, most ransomware authors use the small size of their malicious files as some kind of unique selling point when advertising their campaigns in underground hacker communities. Ransom32 definitely had our interest.
Unwrapping the behemoth
After further examination the downloaded file turned out to be a WinRAR self-extracting archive:
The malware uses the script language implemented in WinRAR to automatically unpack the content of the archive into the user’s temporary files directory and execute the “chrome.exe” file contained in the archive. The files within the archive have the following purposes:
- “chrome” contains a copy of the GPL license agreement.
- “chrome.exe” is a packaged NW.js application and contains the actual malware code as well as the framework required to run the malware.
- “ffmpegsumo.dll”, “nw.pak”, “icudtl.dat” and “locales” contain data that are required by the NW.jsframework to function properly.
- “rundll32.exe” is a renamed copy of the Tor client.
- “s.exe” is a renamed copy of Optimum X Shortcut, a utility to create and manipulate Desktop and start menu shortcuts.
- “g” contains the malware’s configuration information as configured in the web interface.
- “msgbox.vbs” is a small script that displays a customizable popup message and is used to display the configured message box.
- “u.vbs” is a small script that enumerates, and deletes all files and folders in a given directory.
The most interesting part by far in that package is the “chrome.exe”. Upon first inspection, “chrome.exe” looks suspiciously like a copy of the actual Chrome browser. Only the lack of a proper digital signature and version information hints that this file is not the actual Chrome browser. Upon further inspection, it turned out that this file is a packaged NW.js application.
Using modern web-based technologies for ransomware
This also means, that at least in theory, Ransom32 could easily be packaged for both Linux and Mac OS X. That being said at this point we haven’t seen any such packages, which at least for the moment makes Ransom32 most likely Windows-only. Another large benefit for the malware author is that NW.js is a legitimate framework and application. So it is no surprise that even almost 2 weeks after the malware was first created, signature coverage is still incredibly bad.
Once Ransom32 arrives on a system and is executed, it will first unpack all its files into the temporary files folder. From there it copies itself into the “%AppData%\Chrome Browser” directory. It uses the bundled “s.exe” file to create a shortcut in the user’s Startup folder named “ChromeService” that will make sure the malware is being executed on every boot. The malware will then start the bundled Tor client to establish a connection to its command and control server (C2 server) hidden inside the Tor network on port 85. After a successful connection with the C2 server to negotiate the Bitcoin address the affected user is supposed to send the ransom to, as well as exchanging the cryptographic key used for encryption, the malware will eventually display its ransom note.
It then starts encrypting the user’s files. All files with one of the following file extensions are being targeted:
*.jpg, *.jpeg, *.raw, *.tif, *.gif, *.png, *.bmp, *.3dm, *.max, *.accdb, *.db, *.dbf, *.mdb, *.pdb, *.sql, *.*sav*, *.*spv*, *.*grle*, *.*mlx*, *.*sv5*, *.*game*, *.*slot*, *.dwg, *.dxf, *.c, *.cpp, *.cs, *.h, *.php, *.asp, *.rb, *.java, *.jar, *.class, *.aaf, *.aep, *.aepx, *.plb, *.prel, *.prproj, *.aet, *.ppj, *.psd, *.indd, *.indl, *.indt, *.indb, *.inx, *.idml, *.pmd, *.xqx, *.xqx, *.ai, *.eps, *.ps, *.svg, *.swf, *.fla, *.as3, *.as, *.txt, *.doc, *.dot, *.docx, *.docm, *.dotx, *.dotm, *.docb, *.rtf, *.wpd, *.wps, *.msg, *.pdf, *.xls, *.xlt, *.xlm, *.xlsx, *.xlsm, *.xltx, *.xltm, *.xlsb, *.xla, *.xlam, *.xll, *.xlw, *.ppt, *.pot, *.pps, *.pptx, *.pptm, *.potx, *.potm, *.ppam, *.ppsx, *.ppsm, *.sldx, *.sldm, *.wav, *.mp3, *.aif, *.iff, *.m3u, *.m4u, *.mid, *.mpa, *.wma, *.ra, *.avi, *.mov, *.mp4, *.3gp, *.mpeg, *.3g2, *.asf, *.asx, *.flv, *.mpg, *.wmv, *.vob, *.m3u8, *.csv, *.efx, *.sdf, *.vcf, *.xml, *.ses, *.dat
The malware will not attempt to encrypt any files if they are located in a directory that contains any of the following strings:
Files are being encrypted using AES with a 128 bit key using CTR as a block mode. A new key is being generated for every file. The key is encrypted using the RSA algorithm and a public key that is being obtained from the C2 server during the first communication.
The encrypted AES key is being stored together with the AES encrypted data inside the now encrypted file.
The malware also offers to decrypt a single file to demonstrate that the malware author has the capability to reverse the decryption. During this process the malware will send the encrypted AES key from the chosen file to the C2 server and gets the decrypted per-file AES key back in return.