March 31, 2017

Sage is yet another ransomware that has become a common threat nowadays. Similarly to Spora, it has capabilities to encrypt files offline. The malware is actively developed and currently, we are facing an outbreak of version 2.2. of this product.

Analyzed samples

3686b6642cf6a3d97e368590557ac3f2 – JS downloader
d8226b7697524c60eddd22a46b588ff7 – original payload (dropped by the script)
159af0102877e71a1c3f5468bd02a8f3 – unpacked payload

Distribution method

Most often, Sage is dropped by downloader scripts distributed via phishing e-mails (office documents with malicious macros or standalone JS files). In the analyzed case, the sample was dropped via a JavaScript file.

Behavioral analysis

After being deployed, Sage deletes the original sample and runs another copy, dropped in %APPDATA% (names of the dropped files are different for different machines – probably generated basing on GUID):


The dropped copy deploys itself once again, with a parameter ‘g’. Example:
After finishing its work, that dropped copy is also being deleted with the help of a batch script dropped in the %TEMP% folder.


The content dropped in %TEMP% is shown on the below picture. We can see the batch scripts and the BMP that is being set as a wallpaper:


Sample contents of the batch scripts is given below. As we can see, the ping command is used to delay operations.

Just in case the system gets restarted before the encryption finished, Sage sets a link in the Startup folder, so that it can continue after the reboot:

However, if the ransomware successfully completed encryption process and deleted itself, the link is left abandoned.

After finishing, the wallpaper is changed. In version 2.2 the wallpaper looks very similar to 2.0, except the font is green instead of red:

At the end of the execution, the ransom note !HELP_SOS.hta opens automatically:

In addition to the written information, Sage 2.2 plays a voice message informing about the infection. It is deployed via WScript running the default Microsoft voice-to-speech service – just like in the case of Cerber.

Some content is left in %APPDATA%:


Encrypted files are added to the “sage”extension and their icons are changed:

Visualization of a file – before and after encryption:
Files with the same plaintext produce different ciphertexts, that leads to the conclusion that each file is encrypted with a new key.

Sage can work well without internet connection, however, if connected it sends data via UDP (similarly to Cerber):

The traffic is encrypted:

Page for the victim

The ransom note contains a link to the page for the victim. Encrypted and Base64 encoded key of the victim is passed via URL to the server of attackers. Example: http://7gie6ffnkrjykggd.onion/login/AQAAAAAAAAAAv4NRzsVPkfwPPWixq2mqtFwGWlZTeCDpL_BGPyeJFhDA

The key can be also pasted via field on the website:

Keep in mind that the first login on the page for the victim triggers the timer to start. From this moment, the countdown to the price increment is running.

The website is protected by a simple captcha and allows for a simple customization – the victim can choose one of the supported languages (currently 17):

The page contains typical information, such as the amount of ransom to be paid and further instructions:


The malware allows to test decryption capabilities by permitting the victim to upload some encrypted files (the size of the file must be lesser than 15 KB):


However, the result is not available instantly:


After some hours, the decrypted version of the uploaded file is indeed available to download:

Inside

Sage is delivered packed by various crypters. After defeating the first layer we obtain second PE file – the malicious core, that is not further obfuscated.

At the beginning of the execution, Sage generates the Victim ID/key and saves it in the .tmp file dropped in %APPDATA% folder. Then, it removes backups from the system:

Executed commands:
Sage enumerates through the files, and if they matched the defined criteria, they are getting encrypted. First, the malware creates a file with the same name as the attacked one, but with three dots at the end.


Both files coexist in the system until the encrypting is finished.


Then, the original file is deleted and the newly created one – renamed with the extension .sage:


At the end, only the .sage file is left:

What is attacked?

Sage comes with a long list of the attacked extensions, that is hard-coded in the binary:
In order to access all the files without any interference, Sage searches and terminates any associated processes. Processes are identified by their names:
As it is common in ransomware, some paths are excluded from the attack. In this case, blacklisted are not only system directories, but also others, related to popular games like “League of Legends”, “steamapps”, “GOG Games”, and etc.
Some countries (recognized by keyboard layouts) are also excluded from the attack. Below is the function checking if the selected keyboard layout is present in the system:

Systems with the following keyboard layouts are omitted by Sage 2.2: Belarusian, Kazak, Ukrainian, Uzbek, Sakha, Russian, Latvian.

How does the encryption works?

Sage uses two cryptographic algorithms: Elliptic Curves and ChaCha20. ChaCha20 is used to encrypt content of each file, while ECC is used to protect the randomly generated keys.

Each random key is retrieved using a cryptographically secure generator (SystemFunction036). The filled buffer is preprocessed by a simple algorithm:

Victim ID

At the beginning of the execution, Sage creates a random buffer and encrypts it using ECC. The buffer created in the first round of encryption we will refer as a Victim ID and the output of the next rounds – as Encrypted Victim ID.

In the first round, the random value is encrypted using ECC, producing the Victim ID.

In the second round, the same random value is encrypted using ECC along with another buffer, that is hardcoded in the binary. The output is processed in the similar way like the random buffer:

In the third round, the resulting buffer is again encrypted by ECC – producing the Encrypted Victim ID.

Both output buffers are kept in the memory of the application and used further (also they are saved in the TMP file dropped in %APPDATA% folder).

The part highlighted on the screenshot is the Victim ID (after that, next 32 bytes are the Encrypted Victim ID):

The victim ID is also saved in the ransom note, in Base64* version:

*The character set is slightly modified in comparison to the classic Base64. In order to decode it as Base64 we must replace ‘-‘ with ‘+’ and ‘_’ with ‘/’ for example the ID: AQAAAAAAAAAAGwsZ-IAO5_pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA is Base64: AQAAAAAAAAAAGwsZ+IAO5/pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA

In addition, the Victim ID is also saved in each and every encrypted file:

The Encrypted Victim ID takes part in encrypting file’s content (as a key unique per victim).

File encryption

At the beginning of the file encrypting function, a new 32 bytes long key is generated (unique per each file).

The random number is encrypted with the help of ECC twice:

• Individually – to make the key1 that is stored in the file
• Along with the Encrypted Victim’s ID – to make the key2, used by ChaCha20

As we can see, the key2 is used to initialize the cryptographic function’s context. ChaCha20 can be recognized by typical constants used in the initialization function:

The file is encrypted chunk by chunk (the maximal chunk size is 0x20000) with the help of ChaCha20:

At the end of the file, the first derived key (key1) and some additional data is appended:


Appended data is separated from the encrypted file’s content by two hard-coded markers: 0x5A9EDEAD and 0x5A9EBABE


Markers at the end of the encrypted file:
After the first marker Sage stores the following information: Victim ID, Key1, size of the original file.

Network communication

Sage does not need any data from the CnC in order to work. However, as mentioned before, it may generate some UDP traffic. It is because it has capabilities to send some data about the attacked system. Depending on the configuration, the data may be sent either via UDP or via HTTP POST request. The data is encrypted before being sent – also with the help of ChaCha20 algorithm. In the observed case, the ChaCha20 key was a buffer filled with 0 bytes.

Examples of the data sent to the CnC

Sage sends the generated keys to the CnC, i.e.:

Compare with the buffer before encryption:


The same data is also formatted into a human-readable form, like shown below. However, so far we didn’t observed any use of this data. It may be some unfinished feature, that will be developed further in new versions of this product. Formatted equivalent of the above buffer:
Other examples – collected information about the attacked machine:

Adding icons

Interesting and uncommon feature deployed by Sage is the change of icons for the used datatypes. Padlock icon is added to the encrypted files with the .sage extension and the key icon is added to the files with .hta extensions (that are used for the ransom notes). Icon change is implemented via setting appropriate registry keys:

Conclusion

Sage, similar to Spora, uses a complex way of deriving keys. So far, there is no solution that would allow recovering files without paying the ransom – that’s why we recommend focusing on prevention instead. Malwarebytes 3.0 Premium users are protected from Sage ransomware as long as it is installed prior to being infected.

News Courtesy : https://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/