Ransomware has been a growing threat, with new families cropping up every week. Emsisoft researchers are often involved in the discovery and analysis of new threats, and this ransomware is no different. Originally spotted on ID-Ransomware earlier today, it caught our attention due to a few unique features and the high level of professionalism in both implementation and presentation. We will not only go through the inner workings of Spora, but we will highlight its sophisticated commercial model and how you can keep yourself protected from this latest family of ransomware.

Meet Spora

Spora is written in C and is packed using the UPX executable packer. Unlike most ransomware families, Spora doesn’t rename files it encrypts, so there are no specific file extensions associated with it. When infecting a system, it drops a nicely designed HTML-based ransom note and a .KEY file. The base name of both files is identical to the user ID the ransomware assigns to each user. The ransom note is written in Russian:

If you click on the large button with your ID filled in, you will be taken to their website:

A couple of things immediately caught our attention: Firstly, the presentation and the interface itself have a professional, almost beautiful, look. Secondly, and unlike other ransomware, the ransom it asks for seemed comparatively low. A bit later we will explain why this is, but the availability of different ‘packages’ the ransomware offers to its victims is also interesting. You can choose to only recover your files or pay for removal of the ransomware and immunity from future attacks at an extra cost. This is something unique to the Spora ransomware, as we have not seen anything like this before. The site also features a chat box where you can communicate with the criminals which, while not unique, is rather uncommon. From what has been observed so far, the criminals seem to be replying rather promptly.

How does a user get infected with Spora ransomware?

At present Spora is targeting mainly Russian users via emails pretending to be an invoice from 1C, a popular accounting software in Russia and many former USSR countries. The currently seen file name is “Скан-копия _ 10 января 2017г. Составлено и подписано главным бухгалтером. Экспорт из 1С.a01e743_рdf.hta” which would translate to “Scan-copy _ 10 Jan 2017. Written and signed by the chief accountant. Exported from 1C.a01e743_pdf.hta”. It uses a double extension in an attempt to trick the user into believing this would be just another PDF invoice, when in fact it is an HTA file.

HTA files are so-called HTML applications. The idea of an HTML application is to essentially allow anyone to write desktop applications in HTML and various scripting languages. Think of your browser, but without the security mechanisms that prevent a website from changing anything on your system. The two scripting languages supported by HTML applications on Windows are JScript and VBScript, both of which are used in Spora.

When the user double-clicks the HTA file, it will create a new file in %TEMP% called close.js, then writes an encoded script into said file. Last, but not least, the JScript file is executed:

The JScript is encrypted and obfuscated to avoid detection using custom algorithms and CryptoJS. If you were to remove the obfuscation, you would find a large BASE64 encoded string, which contains the malware executable. The purpose of the script is to decode said string and drop two files into the user’s %TEMP% folder:

• doc_6d518e.docx
• 81063163ded.exe

Afterwards, the JScript dropper will try to open or execute both and then quit. The first file is a document that contains invalid data, causing WordPad or Word to display an error when attempting to open it:

We assume this behaviour is intentional to divert attention away from the fact that the expected document isn’t there by pretending that the file has been damaged during transfer. The corrupt document also makes the user less suspicious of the malicious HTA file that they just ran. The second file is the actual ransomware that does the encrypting of the data.

Spora key generation and encryption

Spora uses a mix of RSA and AES to encrypt the victim’s data. To facilitate encryption on a system, the Windows CryptoAPI is used. When Spora arrives on a system, it will first find and decrypt the malware author’s public RSA key embedded inside the malware executable using a hard-coded AES key. Once the malware author’s public RSA key has been successfully imported, the malware continues by creating a new 1024 bit RSA key pair, which we will call the victim’s RSA key pair, consisting of both a private and public key. It will also generate a new 256 bit AES key to encrypt the victim’s private RSA key with. Once the victim’s private RSA key is encrypted, the AES key used is then encrypted using the malware author’s public RSA key. The encrypted key material together with some additional information is then saved inside the .KEY file.

To encrypt a document or file on the system, Spora will first generate a new 256 bit per-file AES key. This per-file key serves to encrypt up to the first 5 MB of the file. Once done, the malware will encrypt the per-file key using the victim’s public RSA key and the RSA-encrypted per-file key is appended to the encrypted file.

This procedure may look convoluted at first but essentially allows the malware author to operate without the need of a command and control server that the malware would have to talk to during infection and that could be taken down. This means that Spora can encrypt without an internet connection. It also works around weaknesses in other ransomware families like DMA Locker 3, where the malware author’s public key was used to encrypt the per-file keys directly, resulting in the decrypter for one person to work for all other victims of the same campaign.

Unfortunately, after evaluating the way Spora performs its encryption, there is no way to restore encrypted files without access to the malware author’s private key.

Tell me who you are, and I tell you how much you need to pay

As mentioned before, Spora is unique in many different ways. Not only did they manage to get their encryption procedures right on the first try, which in today’s ransomware world isn’t a matter of course with even extensive professional campaigns like Cerber having gaping insecurities in their first iterations, but they also implement a unique pricing model to determine how much a victim has to pay.

As mentioned before, the .KEY file created by the ransomware contains not only the victim’s RSA private key but also certain additional information:

The RSA private key part is immediately visible, and we talked about its relevance before, but we want to draw your attention to the additional information at the end. The RSA private key is followed by the date when the infection took place, the username of the victim, and the locale of the infected system. The next value is a hard-coded identifier and the same for all victims who were infected by the same Spora sample we analysed. We are relatively confident that this is used as a campaign ID that is used to track the effectiveness of different campaigns and potentially pay out shares to affiliates responsible for those campaigns, suggesting that Spora may be offered as ransomware-as-a-service.

The following six numeric values are particularly interesting. When selecting targets to encrypt, Spora will sort them into one of six categories based on their file extension:

These statistics are then included into the .KEY file as part of the six numeric values. Moreover, these statistics will determine how much the malware author will ask for. We have seen these victim-specific pricings before in targeted attacks via RDP, where attackers check who owns the server and what files it contains before encrypting it. Spora, however, takes it further and not only makes this tactic accessible to the mainstream but fully automates it. This also explains why the prices for our test system were so low since it barely had any files on it that the malware author deemed valuable.

In addition, the content of the .KEY block, as well as the statistics, are also used to create the user ID that any user is asked to type in when accessing the web panel for the first time. A typical ID may look like this:

US741-85RZR-TRTZT-ZTFFT-ZYYYY

Spora IDs will always be presented in five character blocks, separated by a hyphen. The first two characters (US) are the 2-letter country code of the system’s locale. The next 5 characters (75185) are the first five characters of the MD5 hash calculated over the .KEY file’s unencrypted content. The following letters (RZRTRTZTZTFFTZ) is the statistics string from the .KEY file encoded with a simple substitution cipher. All pipe symbols (|) are replaced with T-characters. The other substitutions can be seen in the following code fragment:

If the last block doesn’t add up to 5 characters, it is padded with Y-characters. Based on this, it is possible to track the number of files encrypted by Spora based on the ID alone. We are currently working together with help platforms like ID Ransomware and No More Ransom in an attempt to gather statistics based on the identifiers contained in uploaded ransom notes.

How can I protect myself from Spora?

As explained in our ransomware article, the best protection still remains a reliable and proven backup strategy, especially since the encryption used by Spora is secure and the only way to get the data back is through the help of the ransomware author. Apart from regular backups, you will be glad to hear that the behaviour blocker technology used by Emsisoft Anti-Malware and Emsisoft Internet Security has proven to be the next best defence, as it has caught the ransomware before the file could execute and thus once again keeping our users protected from this and hundreds of other ransomware families without the need for signatures.

We consider ransomware one of the biggest threats of the past year and plan to do our best to continue our excellent track record in the next year, to keep our users as protected as possible.