{
	"id": "0682ab75-aa3a-4b74-99cb-542600d92344",
	"created_at": "2026-04-06T00:08:00.414059Z",
	"updated_at": "2026-04-10T03:21:00.020485Z",
	"deleted_at": null,
	"sha1_hash": "e454672551f19b9994d4ad398a616b9ab14963bb",
	"title": "7ev3n ransomware turning ‘HONE$T’",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 459104,
	"plain_text": "7ev3n ransomware turning ‘HONE$T’\r\nBy hasherezade\r\nPublished: 2016-05-05 · Archived: 2026-04-05 20:56:02 UTC\r\n7ev3n ransomware appeared at the beginning of this year. In addition to typical features of encrypting files, it was\r\nblocking access to the system using a fullscreen window, and was difficult to remove. It also became famous\r\nfor demanding an unrealistic price of 13 bitcoins.\r\nAt that time the product looked like in early stage of development, however, the code was showing a potential to\r\nevolve into something smarter in the future. Indeed – the authors decided to actively work on making\r\nimprovements. Currently we are facing an outbreak of a new campaign with an improved version of this\r\nransomware – this time named 7ev3n-HONE$T. Probably the new name refers to the added feature of decrypting\r\ntest files before the payment – as a proof of the authors’ “honesty” in giving files back.\r\nIn this post we will take a look at its evolution.\r\n[UPDATE] See also: decryptors for 7ev3n ransomware\r\nAnalyzed samples\r\n7ev3n (old edition):\r\n8434eea972e516a35f4ac59a7f868453 – main executable\r\na3dfd4a7f7c334cb48c35ca8cd431071 – system.exe\r\nce4120c6b29bc399bcd9b735d3130667 – UAC.exe 64 bit (packed with UPX)\r\n18ba27b27881086d2d9f847b078fac84 – UAC.exe (unpacked)\r\n7a681d8650d2c28d18ac630c34b2014e – UAC.exe – 32 bit (packed with UPX)\r\n5370fc9dcb28f7105c3a4aebaae3f250 – UAC.exe (unpacked)\r\n7ev3n-HONE$T (new edition):\r\n96a3bb6b10e4c6f614c783a7e42fdbcc – main executable\r\n32a56ca79f17fea432250ee704432dfc – payload \u003c- main focus of this analysis\r\n5b5e2d894cdd5aeeed41cc073b1c0d0f – payload 2 (packed with UPX)\r\nd004776ff5f77a2d2cab52232028ddeb – payload 2 (unpacked)\r\n52517f419e78041f8e211428b8820dfb – main executable\r\nd3609b3179b164b0af6845226ac05f70 – payload\r\nBehavioral analysis\r\n73v3n – old version\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 1 of 13\n\nOnce executed, 7ev3n ransomware was installing itself, deleting the clicked copy and silently encrypting files.\r\nThe first symptom that something was wrong was a notification that User Account Control is going to be turned\r\noff, and the system needed to be restarted:\r\nThe malware was not waiting for the next restart, but executing it by its own. Shortly after another notification the\r\nsystem was going to shut down:\r\nOn the next reboot, the attack of that version of 7ev3n ransomware was announced by a big window, covering the\r\nentire desktop and blocking access to the system. It was difficult to bypass. In order to regain the control over the\r\nsystem, the user needed to put some special effort (guidance has been provided, i.e. by BleepingComputer).\r\nThe ransomware installed itself in %LOCALAPPDATA% – the main file is dropped under the name system.exe:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 2 of 13\n\nIn addition, it dropped one more executable: uac.exe – for User Account Controll bypass, using a well-known\r\ntrick with Cabinet files (Akagi) and two bat scripts: del.bat (responsible for deleting the original file) and bcd.bat\r\n– responsible for disabling backup. Content of bcd.bat demonstrated below:\r\nbcdedit /set {current} bootems no bcdedit /set {current} advancedoptions off bcdedit /set {curren\r\nEncryption process\r\nThis ransomware is capable of encrypting files off-line.\r\nEncrypted files had their name changed to .R5A.\r\nPatterns found in the encrypted files (R5A extension) look like two different algorithms have been used for it’s\r\ndifferent chunks.\r\nsquare.bmp : left – original, right encrypted with 7ev3n\r\nEvery file was encrypted with a different key.\r\n73v3n – HONE$T\r\nThe new edition comes with an improved interface. The most important difference is that the authors gave up the\r\nidea of blocking the full desktop of the infected computer. Although the window with ransom demand cannot be\r\nclosed, it is still possible to access other programs. Moreover, the GUI itself has been enriched with features\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 3 of 13\n\nallowing for navigation and getting more information. Similarly to other ransomware, it provides a possibility to\r\ndecrypt a few files for the test.\r\nIn the new edition the price of decryption is only 1 BTC  (in some samples even 0.5) – that is a huge difference in\r\ncomparison to 13 BTC from the previous campaign. The new ransom note offers various models of payment (i.e\r\npossibility to decrypt half of the files for 60% of the original price) and a 20% discount in case of paying full sum\r\nat once. As we can see, the authors learned to be more user-friendly and made a step towards “honesty”.\r\nInstallation folder and dropped files are different than in the previous version (sample 1 BTC):\r\nHowever, this feature depends rather on the particular campaign – in some of the new samples the installation path\r\nis like in the previous edition (sample 0.5 BTC)\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 4 of 13\n\nThis time, the main executable is dropped either as conlhost.exe or as  system.exe (depending on the sample).\r\nAlso, in the same folder, the ransomware creates 2 files with lists of paths:\r\nfiles – containing all the encrypted files\r\ntestdecrypt – containing files that have been chosen as testfiles that can be decrypted for free\r\nThe dropped executable have some unique ID appended to it’s end. It is an array of 34 random characters, with ‘*’\r\nused as a prefix/suffix – format:  ‘*[x00-xff]{34}*’. This key is same on every run for a particular machine.\r\nExample: Left – the sample before being run. Right – the sample that was run and installed on the system:\r\nPersistence is based on a Run registry key:\r\nIn addition to displaying the GUI with ransom note it also drops a TXT file with contact information, that can be\r\nused if – for any reason – the main windows didn’t manage to pop-up:\r\nThe victim ID is the same after every execution on the same machine, so we can be sure that it is not random (it\r\nmay be generated from some local identifiers, i.e. GUID).\r\nEncryption process\r\nThe new version also can encrypt files off-line (no key needs to be downloaded from the server).\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 5 of 13\n\nEncrypted files had their name changed to A.R5A (or, for some of the new samples .R5A –just like in the old\r\nversion). The new feature is that some randomly selected files are given a different extension: .R4A.\r\nJust like in the to the previous edition, patterns found in the encrypted files (R5A extension) look like two\r\ndifferent algorithms have been used for its different chunks.\r\nsquare.bmp : first – original, second- encrypted with 7ev3n-HONE$T, third – encrypted with old 7ev3n.\r\nCompletely different algorithm has been deployed on the files with R4A extension (introduced newly in 7ev3n-HONE$T)\r\nWe can see the patterns of the original file reflected in it’s encrypted content. Such an effect depicts, that file could\r\nhave been encrypted by some block cipher – but as well it can be a custom, XOR-based algorithm.\r\nAlso in this version, every file with R5A extension is encrypted with a different key.\r\nExperiment\r\nFor the purpose of experiments I prepared set of short TXT files, as given below:\r\nThey have been encrypted as following:\r\n1.txt\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 6 of 13\n\n16A.txt\r\nlong_filename.txt\r\nThe file 16M.txt has not been encrypted at all.\r\nWe can see that each end every encrypted file starts with a character ‘M’. After that, there is an encrypted content\r\n– it’s length is the same like the original. However, the same plaintext does not produce the same encrypted\r\ncontent (compare 1.txt and 16A.txt).\r\nThe encrypted content is suffixed with a separator ‘**’ and then the encrypted filename is stored (it’s original\r\nlength is preserved). The last character is always ‘x0A’. Format of the encrypted file can be defined as:\r\nM**x0A\r\nFiles with content length shorter or equal 8 are excluded from the encryption. Similarly, excluded are files which\r\ncontent begins with ‘M’. More details about why it happens, we will find by analyzing the code.\r\nNetwork communication\r\nAlthough the internet connection is not required in the process of encryption, 7even is capable of communicating\r\nwith C\u0026C for the purpose of collecting information about the attacked machines.\r\nDuring beaconing, various information about the current infection are sent. As usual, the victim ID (the same that\r\nis mentioned in the ransom note), wallet ID (hardcoded in the binary), operating system, etc.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 7 of 13\n\nSending statistics from the encryption:\r\nInside 7ev3n (the old version)\r\nThe techniques used by 7ev3n are not very advanced, but yet it is worth to take a look.\r\nAnalyzed files:\r\nsystem.exe (a3dfd4a7f7c334cb48c35ca8cd431071) – main file\r\nuac.exe (7a681d8650d2c28d18ac630c34b2014e)– upx-packed payload\r\nThe main file (system.exe) comes with UAC bypassing tools embedded (32 and 64 bit version – the one that is\r\ndeployed is chosen appropriately for the system). Among strings we can see list of decimal numbers, that need to\r\nbe simply converted into ASCII. Beginning of the new PE in strings of the file:\r\n77 90 144 0 3 0 0 0 4 0 0 0 255 255 0 0 184 0 0 0 0 0 0 0 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0\r\nWe can convert it easily into a binary (i.e by this script) getting as a result 64 bit version of the same UAC\r\nbypassing tool (original is packed by UPX  unpacked version available here).\r\nRegistry manipulation\r\nAdding a registry key indicating that files are encrypted:\r\nREG ADD \"HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion\" /v \"crypted\" /t REG_SZ /d 1 /f\r\nManipulating registry keys – i.e. in order to block the screen:\r\nREG ADD \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" /v \"System\" /t REG_SZ /d\r\nInside 7ev3n-HONE$T\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 8 of 13\n\nThe first layer is a packing: a simple crypter/FUD with an icon added. It’s role is deception: delivering malicious\r\npayload in a way unnoticed by antimalware tools, as well as making it’s analysis harder.\r\nAfter defeating the FUD layer we get the first payload (32a56ca79f17fea432250ee704432dfc). Strings and\r\nimported functions are not obfuscated. We can find the path to the project inside the binary – it suggests that we\r\nare dealing with the variant without UAC bypass (in contrary to the previous version, that had it implemented):\r\nC:UsersadminDesktopnew version with NO UACReleaseWin32Project9.pdb\r\nInside this payload we can find yet another, UPX packed executable: 5b5e2d894cdd5aeeed41cc073b1c0d0f . It is\r\nalso not very well protected and after unpacking it with standard UPX application we get another executable\r\n(d004776ff5f77a2d2cab52232028ddeb) with all the strings and API calls visible.\r\nExecution flow\r\nFirst execution is used just for the purpose of installation.\r\nWhen the sample is deployed, it makes it’s copy into the predefined installation folder (destination may vary for\r\nvarious samples). It drops a batch script that is supposed to delete the initial sample\r\nThe unique, hardware-based ID is written at the end of the executable that has been copied to the destination path:\r\nBelow – the same key – at the end of the installed sample:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 9 of 13\n\nIn the meanwhile,  of the installation, malware sends the beacon to a hardcoded URL.\r\nThen, the new sample is deployed and the initial sample terminates and gets deleted.\r\nThe installed sample is supposed to run the second phase – that encrypt the files. Decision which execution path\r\nshould be deployed (installation, encrypion, or GUI is based on the environment check.\r\nRegistry manipulation\r\nAdding a registry key indicating that files are encrypted:\r\nREG ADD \"HKEY_CURRENT_USERSOFTWARE\" /v \"crypted\" /t REG_SZ /d \"1\"\r\nManipulating other registry keys – related with persistance, status of decrypting etc.\r\nREG ADD \"HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun\" /v \"allkeeper\" /t REG_SZ /d \"\" /\r\nWhat is attacked?\r\nThis ransomware encrypts local drives as well as mapped network shares.\r\nEncrypted extensions are hardcoded in the binary as UNICODE strings:\r\nSummary of all the file extensions that are attacked:\r\nai arw txt doc docm docx zip rar xlsx xls xlsb xlsm jpg jpe jpeg bmp eql sql adp mdf mdb odb odm odp\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 10 of 13\n\nHow does the encryption work?\r\n7ev3n-HONE$T encrypts files in a loop, one by one. It completely changes their names – but at the same time it\r\nstores the previous name (as we know, files that are decrypted have their names recovered).\r\nThe executable comes with 3 hardcoded strings, that are used in the process of encryption. Their exact role will be\r\ndescribed further.\r\nEvery encrypted file have it’s content prefixed with ‘M’. This character is also checked in order to distinguish, if\r\nthe file has been encrypted. If the ‘M’ was found as a first character of the buffer, the file will not be encrypted:\r\nAuthors left a log in the code, leaving no doubt about their intentions, that this character is used as an indicator of\r\nthe encrypted file:\r\nOf course such a check is not giving a precise detection and if it happens that we have a file starting from ‘M’ it\r\nwill not be encrypted.\r\nThis ransomware produce encrypted files by two ways – they can be distinguished by different extensions: .R4A\r\nor .R5A.\r\nAfter deobfuscation we were able to reconstruct both algorithms and notice, that they are custom and not\r\nemploying any strong cryptography.\r\nR4A algorithm turned out to be an XOR with a hardcoded key:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 11 of 13\n\nANOASudgfjfirtj4k504iojm5io5nm59uh5vob5mho5p6gf2u43i5hojg4mf4i05j6g594cn9mjg6h\r\nR5A algorithm is also XOR-based, but not that simple – It have several execution steps:\r\n1. A hardcoded string is scrambled and expanded to a predefined length (in analyzed samples it was 0x10C).\r\nThe algorithm used for scrambling differs from sample to sample.\r\n2. The scrambled key (0x10C byte long)  is XOR-ed with the original file path.\r\n3. The key created in the previous step is used to XOR file content\r\n4. The XORed content is divided to 4 parts, that are processed by 2 different XOR-based algorithms. First and\r\nThird quarter are processed by algorithm I. Second and fourth – by algorithm II. (That’s why we have seen\r\n4 ‘strips’ on the visualized content).\r\nFull reconstruction of the used algorithms you can see here.\r\nAdding appropriate extension to the file name:\r\nAfter encrypting the content, some more data is appended to it. At the beginning – the previously mentioned ‘M’\r\ncharacter – as an indicator that file is encrypted. At the end – a string “**” –  as a separator after which the\r\nencrypted file name of the particular file is stored.\r\nFilename is also encrypted in a very simple way – by XOR with one of the hardcoded keys.\r\nfor R4A:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 12 of 13\n\nANOASudgfjfirtj4k504iojm5io5nm59uh5vob5mho5p6gf2u43i5hojg4mf4i05j6g594cn9mjg6h\r\nfor R5A:\r\nASIBVbhciJ5hv6bjyuwetjykok7mbvtbvtiJ5h6jg54ifj0655iJ5hok7mbok7mbvtvtv6bjfib56j45fkmbvtiJ5hv6bokok7mb\r\nThe encrypted content is saved first to the original file. After that the file is moved under the new name:\r\nConclusion\r\n7ev3n ransomware has been around for quite a while, but till now not many details about its internals have been\r\nrevealed. It turned out to have pretty unexpected features. Although a lot has been told about weakness of\r\nsolutions that are based on custom encryption, there are still some ransomware authors going for it. That’s why it\r\nis worth not making any rushed decisions in paying the ransom. Sometimes the code is obfuscated and finding out\r\nhow it really works takes some time for analysts – but it doesn’t mean that the encryption is really unbreakable.\r\nWork on the full version of the decryptor is in progress. For now you can see the proof-of-concept script (tested on\r\nthis variant): https://github.com/hasherezade/malware_analysis/tree/master/7ev3n\r\nAppendix\r\nhttp://www.bleepingcomputer.com/news/security/7ev3n-ransomware-trashes-your-pc-and-then-demands-13-bitcoins/ – about 7ev3n (the old version)\r\nhttp://www.nyxbone.com/malware/7ev3n-HONE$T.html – about 7ev3n-HONE$T\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/"
	],
	"report_names": [
		"7ev3n-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434080,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e454672551f19b9994d4ad398a616b9ab14963bb.pdf",
		"text": "https://archive.orkl.eu/e454672551f19b9994d4ad398a616b9ab14963bb.txt",
		"img": "https://archive.orkl.eu/e454672551f19b9994d4ad398a616b9ab14963bb.jpg"
	}
}