Explained: Sage ransomware
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:\Users\tester\AppData\Roaming\FkGtk5ju.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:
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://ift.tt/2ngNkEF
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:
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:
What is attacked?
Sage comes with a long list of the attacked extensions, that is hard-coded in the binary:
dat mx0 cd pdb xqx old cnt rtp qss qst fx0 fx1 ipg ert pic img cur fxr slk m4u mpe mov wmv mpg vob mpeg 3g2 m4v avi mp4 flv mkv 3gp asf m3u m3u8 wav mp3 m4a m rm flac mp2 mpa aac wma djv pdf djvu jpeg jpg bmp png jp2 lz rz zipx gz bz2 s7z tar 7z tgz rar ziparc paq bak set back std vmx vmdk vdi qcow ini accd db sqli sdf mdf myd frm odb myi dbf indb mdb ibd sql cgn dcr fpx pcx rif tga wpg wi wmf tif xcf tiff xpm nef orf ra bay pcd dng ptx r3d raf rw2 rwl kdc yuv sr2 srf dip x3f mef raw log odg uop potx potm pptx rss pptm aaf xla sxd pot eps as3 pns wpd wps msg pps xlam xll ost sti sxi otp odp wks vcf xltx xltm xlsx xlsm xlsb cntk xlw xlt xlm xlc dif sxc vsd ots prn ods hwp dotm dotx docm docx dot cal shw sldm txt csv mac met wk3 wk4 uot rtf sldx xls ppt stw sxw dtd eml ott odt doc odm ppsm xlr odc xlk ppsx obi ppam text docb wb2 mda wk1 sxm otg oab cmd bat h asx lua pl as hpp clas js fla py rb jsp cs c jar java asp vb vbs asm pas cpp xml php plb asc lay6 pp4 pp5 ppf pat sct ms11 lay iff ldf tbk swf brd css dxf dds efx sch dch ses mml fon gif psd html ico ipe dwg jng cdr aep aepx 123 prel prpr aet fim pfb ppj indd mhtm cmx cpt csl indl dsf ds4 drw indt pdd per lcd pct prf pst inx plt idml pmd psp ttf 3dm ai 3ds ps cpx str cgm clk cdx xhtm cdt fmv aes gem max svg mid iif nd 2017 tt20 qsm 2015 2014 2013 aif qbw qbb qbm ptb qbi qbr 2012 des v30 qbo stc lgb qwc qbp qba tlg qbx qby 1pa ach qpd gdb tax qif t14 qdf ofx qfx t13 ebc ebq 2016 tax2 mye myox ets tt14 epb 500 txf t15 t11 gpc qtx itf tt13 t10 qsd iban ofc bc9 mny 13t qxf amj m14 _vc tbp qbk aci npc qbmb sba cfp nv2 tfx n43 let tt12 210 dac slp qb20 saj zdb tt15 ssg t09 epa qch pd6 rdy sic ta1 lmr pr5 op sdy brw vnd esv kd3 vmb qph t08 qel m12 pvc q43 etq u12 hsr ati t00 mmw bd2 ac2 qpb tt11 zix ec8 nv lid qmtf hif lld quic mbsb nl2 qml wac cf8 vbpf m10 qix t04 qpg quo ptdb gto pr0 vdf q01 fcr gnc ldc t05 t06 tom tt10 qb1 t01 rpf t02 tax1 1pe skg pls t03 xaa dgc mnp qdt mn8 ptk t07 chg #vc qfi acc m11 kb7 q09 esk 09i cpw sbf mql dxi kmo md u11 oet ta8 efs h12 mne ebd fef qpi mn5 exp m16 09t 00c qmt cfdi u10 s12 qme int? cf9 ta5 u08 mmb qnx q07 tb2 say ab4 pma defx tkr q06 tpl ta2 qob m15 fca eqb q00 mn4 lhr t99 mn9 qem scd mwi mrq q98 i2b mn6 q08 kmy bk2 stm mn1 bc8 pfd bgt hts tax0 cb resx mn7 08i mn3 ch meta 07i rcs dtl ta9 mem seam btif 11t efsl $ac emp imp fxw sbc bpw mlb 10t fa1 saf trm fa2 pr2 xeq sbd fcpa ta6 tdr acm lin dsb vyp emd pr1 mn2 bpf mws h11 pr3 gsb mlc nni cus ldr ta4 inv omf reb qdfx pg coa rec rda ffd ml2 ddd ess qbmd afm d07 vyr acr dtau ml9 bd3 pcif cat h10 ent fyc p08 jsd zka hbk bkf mone pr4 qw5 cdf gfi cht por qbz ens 3pe pxa intu trn 3me 07g jsda 2011 fcpr qwmo t12 pfx p7b der nap p12 p7c crt csr pem gpg key
In order to access all the files without any interference, Sage searches and terminates any associated processes. Processes are identified by their names:
msftesql.exe sqlagent.exe sqlbrowser.exe sqlservr.exe sqlwriter.exe oracle.exe ocssd.exe dbsnmp.exe synctime.exe mydesktopqos.exe agntsvc.exe isqlplussvc.exe xfssvccon.exe mydesktopservice.exe ocautoupds.exe encsvc.exe firefoxconfig.exe tbirdconfig.exe ocomm.exe mysqld.exe mysqld-nt.exe mysqld-opt.exe dbeng50.exe sqbcoreservice.exe
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.
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.
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* encrypted 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:
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.
Appendix
http://ift.tt/2nAhXbC – 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: http://ift.tt/1R6Y8zL.
The post Explained: Sage ransomware appeared first on Malwarebytes Labs.
from Malwarebytes Labs full article here