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:
"C:UserstesterAppDataRoamingFkGtk5ju.exe" g
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:
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:
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:
vssadmin.exe delete shadows /all /quiet bcdedit.exe /set {default} recoveryenabled no bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
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:
tmp Temp winnt ‘Application Data’ AppData ProgramData ‘Program Files (x86)’ ‘Program Files’ ‘$Recycle Bin’ ‘$RECYCLE BIN’ Windows.old $WINDOWS.~BT DRIVER DRIVERS ‘System Volume Information’ Boot Windows WinSxS DriverStore ‘League of Legends’ steamapps cache2 httpcache GAC_MSIL GAC_32 ‘GOG Games’ Games ‘My Games’ Cookies History IE5 Content.IE5 node_modules All Users AppData ApplicationData nvidia intel Microsoft System32 ‘Sample Music’ ‘Sample Pictures’ ‘Sample Videos’ ‘Sample Media’ Templates 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.
Each random key is retrieved using a cryptographically secure generator (SystemFunction036). The filled buffer is preprocessed by a simple algorithm:
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:
[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 4, { "v": 1, "gpk": bin(32) CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, "pk": bin(32) 2BB7BD5394B845629C90BB2B43D9655DC9C86347C4C695AB18150D7031B9E41F, }]
Other examples – collected information about the attacked machine:
[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 3, { "s": { "w": { "v": [ 6, 1, false, false, 7601, 1, 0, ], "u": "tester", "p": "TESTMACHINE", }, "c": " Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz", "m": 232, "k": [68486165, 4026598409, 4026991637], }, "i": 12288, "w": null, }]
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:
Appendix https://blog.fortinet.com/2017/02/02/a-closer-look-at-sage-2-0-ransomware-along-with-wise-mitigations – Fortinet about Sage 2.0
This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.“>