{
	"id": "8a178ac4-03c9-4ef3-a0e9-6b6de4a040f0",
	"created_at": "2026-04-06T01:29:23.061336Z",
	"updated_at": "2026-04-10T03:21:12.342466Z",
	"deleted_at": null,
	"sha1_hash": "8d60a519af8f004cafa9d02f36df98758f290163",
	"title": "Explained: Sage ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 715501,
	"plain_text": "Explained: Sage ransomware\r\nBy Malwarebytes Labs\r\nPublished: 2017-03-28 · Archived: 2026-04-06 00:44:22 UTC\r\nSage is yet another ransomware that has become a common threat nowadays. Similarly to Spora, it has capabilities to\r\nencrypt files offline. The malware is actively developed and currently, we are facing an outbreak of version 2.2. of\r\nthis product.\r\nAnalyzed samples\r\n3686b6642cf6a3d97e368590557ac3f2 – JS downloader\r\nd8226b7697524c60eddd22a46b588ff7 – original payload (dropped by the script)\r\n159af0102877e71a1c3f5468bd02a8f3 – unpacked payload\r\nDistribution method\r\nMost often, Sage is dropped by downloader scripts distributed via phishing e-mails (office documents with malicious\r\nmacros or standalone JS files). In the analyzed case, the sample was dropped via a JavaScript file.\r\nBehavioral analysis\r\nAfter being deployed, Sage deletes the original sample and runs another copy, dropped in %APPDATA% (names of\r\nthe dropped files are different for different machines – probably generated basing on GUID):\r\nThe dropped copy deploys itself once again, with a parameter ‘g’. Example:\r\n\"C:UserstesterAppDataRoamingFkGtk5ju.exe\" g\r\nAfter finishing its work, that dropped copy is also being deleted with the help of a batch script dropped in the\r\n%TEMP% folder.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 1 of 17\n\nThe content dropped in %TEMP% is shown on the below picture. We can see the batch scripts and the BMP that is\r\nbeing set as a wallpaper:\r\nSample contents of the batch scripts is given below. As we can see, the ping command is used to delay operations.\r\nJust in case the system gets restarted before the encryption finished, Sage sets a link in the Startup folder, so that it\r\ncan continue after the reboot:\r\nHowever, if the ransomware successfully completed encryption process and deleted itself, the link is left abandoned.\r\nAfter finishing, the wallpaper is changed. In version 2.2 the wallpaper looks very similar to 2.0, except the font is\r\ngreen instead of red:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 2 of 17\n\nAt the end of the execution, the ransom note !HELP_SOS.hta opens automatically:\r\nIn addition to the written information, Sage 2.2 plays a voice message informing about the infection. It is deployed\r\nvia WScript running the default Microsoft voice-to-speech service – just like in the case of Cerber.\r\nSome content is left in %APPDATA%:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 3 of 17\n\nEncrypted files are added to the “sage”extension and their icons are changed:\r\nVisualization of a file – before and after encryption:\r\n“\u003e\r\nFiles with the same plaintext produce different ciphertexts, that leads to the conclusion that each file is encrypted with\r\na new key.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 4 of 17\n\nSage can work well without internet connection, however, if connected it sends data via UDP (similarly to Cerber):\r\nThe traffic is encrypted:\r\nPage for the victim\r\nThe ransom note contains a link to the page for the victim. Encrypted and Base64 encoded key of the\r\nvictim is passed via URL to the server of attackers. Example:\r\nhttp://7gie6ffnkrjykggd.onion/login/AQAAAAAAAAAAv4NRzsVPkfwPPWixq2mqtFwGWlZTeCDpL_BGPyeJFhDA\r\nThe key can be also pasted via field on the website:\r\nKeep in mind that the first login on the page for the victim triggers the timer to start. From this moment, the\r\ncountdown to the price increment is running.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 5 of 17\n\nThe website is protected by a simple captcha and allows for a simple customization – the victim can choose one of\r\nthe supported languages (currently 17):\r\nThe page contains typical information, such as the amount of ransom to be paid and further instructions:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 6 of 17\n\nThe malware allows to test decryption capabilities by permitting the victim to upload some encrypted files (the size of\r\nthe file must be lesser than 15 KB):\r\nHowever, the result is not available instantly:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 7 of 17\n\nAfter some hours, the decrypted version of the uploaded file is indeed available to download:\r\nInside\r\nSage is delivered packed by various crypters. After defeating the first layer we obtain second PE file –\r\nthe malicious core, that is not further obfuscated.\r\nAt the beginning of the execution, Sage generates the Victim ID/key and saves it in the .tmp file dropped in\r\n%APPDATA% folder. Then, it removes backups from the system:\r\nExecuted commands:\r\nvssadmin.exe delete shadows /all /quiet bcdedit.exe /set {default} recoveryenabled no bcdedit.exe /set {\r\nSage enumerates through the files, and if they matched the defined criteria, they are getting encrypted. First, the\r\nmalware creates a file with the same name as the attacked one, but with three dots at the end.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 8 of 17\n\nBoth files coexist in the system until the encrypting is finished.\r\nThen, the original file is deleted and the newly created one – renamed with the extension .sage:\r\nAt the end, only the .sage file is left:\r\nWhat is attacked?\r\nSage comes with a long list of the attacked extensions, that is hard-coded in the binary:\r\ndat mx0 cd pdb xqx old cnt rtp qss qst fx0 fx1 ipg ert pic img cur fxr slk m4u mpe mov wmv\r\nIn order to access all the files without any interference, Sage searches and terminates any associated\r\nprocesses. Processes are identified by their names:\r\nmsftesql.exe sqlagent.exe sqlbrowser.exe sqlservr.exe sqlwriter.exe oracle.exe ocssd.exe d\r\nAs it is common in ransomware, some paths are excluded from the attack. In this case, blacklisted are\r\nnot only system directories, but also others, related to popular games like\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 9 of 17\n\ntmp Temp winnt ‘Application Data’ AppData ProgramData ‘Program Files (x86)’ ‘Program Files’ ‘$Recycle Bin’\r\n‘$RECYCLE BIN’ Windows.old $WINDOWS.~BT DRIVER DRIVERS ‘System Volume Information’ Boot\r\nWindows WinSxS DriverStore ‘League of Legends’ steamapps cache2 httpcache GAC_MSIL GAC_32 ‘GOG\r\nGames’ Games ‘My Games’ Cookies History IE5 Content.IE5 node_modules All Users AppData ApplicationData\r\nnvidia intel Microsoft System32 ‘Sample Music’ ‘Sample Pictures’ ‘Sample Videos’ ‘Sample Media’ Templates Some\r\ncountries (recognized by keyboard layouts) are also excluded from the attack. Below is the function checking if the\r\nselected keyboard layout is present in the system:”\u003e\r\nSystems with the following keyboard layouts are omitted by Sage 2.2: Belarusian, Kazak, Ukrainian, Uzbek, Sakha,\r\nRussian, Latvian.\r\nHow does the encryption works?\r\nSage uses two cryptographic algorithms: Elliptic Curves and ChaCha20. ChaCha20 is used to encrypt\r\ncontent of each file, while ECC is used to protect the randomly generated keys.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 10 of 17\n\nEach random key is retrieved using a cryptographically secure generator (SystemFunction036). The filled buffer is\r\npreprocessed by a simple algorithm:\r\nVictim ID\r\nAt the beginning of the execution, Sage creates a random buffer and encrypts it using ECC. The buffer\r\ncreated in the first round of encryption we will refer as a Victim ID and the output of the next rounds –\r\nas Encrypted Victim ID.\r\nIn the first round, the random value is encrypted using ECC, producing the Victim ID.\r\nIn the second round, the same random value is encrypted using ECC along with another buffer, that is hardcoded in\r\nthe binary. The output is processed in the similar way like the random buffer:\r\nIn the third round, the resulting buffer is again encrypted by ECC – producing the Encrypted Victim ID.\r\nBoth output buffers are kept in the memory of the application and used further (also they are saved in the TMP file\r\ndropped in %APPDATA% folder).\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 11 of 17\n\nThe part highlighted on the screenshot is the Victim ID (after that, next 32 bytes are the Encrypted Victim ID):\r\nThe victim ID is also saved in the ransom note, in Base64* version:\r\n*The character set is slightly modified in comparison to the classic Base64. In order to decode it as Base64 we must\r\nreplace ‘-‘ with ‘+’ and ‘_’ with ‘/’ for example the ID: AQAAAAAAAAAAGwsZ-IAO5_pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA is Base64:\r\nAQAAAAAAAAAAGwsZ+IAO5/pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA\r\nIn addition, the Victim ID is also saved in each and every encrypted file:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 12 of 17\n\nThe Encrypted Victim ID takes part in encrypting file’s content (as a key unique per victim).\r\nFile encryption\r\nAt the beginning of the file encrypting function, a new 32 bytes long key is generated (unique per each file).\r\nThe random number is encrypted with the help of ECC twice:\r\nIndividually – to make the key1 that is stored in the file\r\nAlong with the Encrypted Victim’s ID – to make the key2, used by ChaCha20\r\nAs we can see, the key2 is used to initialize the cryptographic function’s context. ChaCha20 can be recognized by\r\ntypical constants used in the initialization function:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 13 of 17\n\nThe file is encrypted chunk by chunk (the maximal chunk size is 0x20000) with the help of ChaCha20:\r\nAt the end of the file, the first derived key (key1) and some additional data is appended:\r\nAppended data is separated from the encrypted file’s content by two hard-coded markers: 0x5A9EDEAD and\r\n0x5A9EBABE\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 14 of 17\n\nMarkers at the end of the encrypted file:\r\nAfter the first marker Sage stores the following information: Victim ID, Key1, size of the original file.\r\nNetwork communication\r\nSage does not need any data from the CnC in order to work. However, as mentioned before, it may generate some\r\nUDP traffic. It is because it has capabilities to send some data about the attacked system. Depending on the\r\nconfiguration, the data may be sent either via UDP or via HTTP POST request. The data is encrypted before being\r\nsent – also with the help of ChaCha20 algorithm. In the observed case, the ChaCha20 key was a buffer filled with 0\r\nbytes.\r\nExamples of the data sent to the CnC\r\nSage sends the generated keys to the CnC, i.e.:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 15 of 17\n\nCompare with the buffer before encryption:\r\nThe same data is also formatted into a human-readable form, like shown below. However, so far we didn’t observed\r\nany use of this data. It may be some unfinished feature, that will be developed further in new versions of this product.\r\nFormatted equivalent of the above buffer:\r\n[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 4, { \"v\": 1, \"gpk\"\r\nOther examples – collected information about the attacked machine:\r\n[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 3, { \"s\": { \"w\":\r\nAdding icons\r\nInteresting and uncommon feature deployed by Sage is the change of icons for the used datatypes. Padlock icon is\r\nadded to the encrypted files with the .sage extension and the key icon is added to the files with .hta extensions (that\r\nare used for the ransom notes). Icon change is implemented via setting appropriate registry keys:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 16 of 17\n\nConclusion\r\nSage, similar to Spora, uses a complex way of deriving keys. So far, there is no solution that would\r\nallow recovering files without paying the ransom – that’s why we recommend focusing on prevention\r\ninstead.\r\nAppendix https://blog.fortinet.com/2017/02/02/a-closer-look-at-sage-2-0-ransomware-along-with-wise-mitigations  –\r\nFortinet about Sage 2.0\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in\r\nInfoSec. She loves going in details about malware and sharing threat information with the community. Check her out\r\non Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.“\u003e\r\nSource: https://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2017/03/explained-sage-ransomware/"
	],
	"report_names": [
		"explained-sage-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775438963,
	"ts_updated_at": 1775791272,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8d60a519af8f004cafa9d02f36df98758f290163.pdf",
		"text": "https://archive.orkl.eu/8d60a519af8f004cafa9d02f36df98758f290163.txt",
		"img": "https://archive.orkl.eu/8d60a519af8f004cafa9d02f36df98758f290163.jpg"
	}
}