7ev3n ransomware turning ‘HONE$T’
By hasherezade
Published: 2016-05-05 · Archived: 2026-04-05 20:56:02 UTC
7ev3n ransomware appeared at the beginning of this year. In addition to typical features of encrypting files, it was
blocking access to the system using a fullscreen window, and was difficult to remove. It also became famous
for demanding an unrealistic price of 13 bitcoins.
At that time the product looked like in early stage of development, however, the code was showing a potential to
evolve into something smarter in the future. Indeed – the authors decided to actively work on making
improvements. Currently we are facing an outbreak of a new campaign with an improved version of this
ransomware – this time named 7ev3n-HONE$T. Probably the new name refers to the added feature of decrypting
test files before the payment – as a proof of the authors’ “honesty” in giving files back.
In this post we will take a look at its evolution.
[UPDATE] See also: decryptors for 7ev3n ransomware
Analyzed samples
7ev3n (old edition):
8434eea972e516a35f4ac59a7f868453 – main executable
a3dfd4a7f7c334cb48c35ca8cd431071 – system.exe
ce4120c6b29bc399bcd9b735d3130667 – UAC.exe 64 bit (packed with UPX)
18ba27b27881086d2d9f847b078fac84 – UAC.exe (unpacked)
7a681d8650d2c28d18ac630c34b2014e – UAC.exe – 32 bit (packed with UPX)
5370fc9dcb28f7105c3a4aebaae3f250 – UAC.exe (unpacked)
7ev3n-HONE$T (new edition):
96a3bb6b10e4c6f614c783a7e42fdbcc – main executable
32a56ca79f17fea432250ee704432dfc – payload <- main focus of this analysis
5b5e2d894cdd5aeeed41cc073b1c0d0f – payload 2 (packed with UPX)
d004776ff5f77a2d2cab52232028ddeb – payload 2 (unpacked)
52517f419e78041f8e211428b8820dfb – main executable
d3609b3179b164b0af6845226ac05f70 – payload
Behavioral analysis
73v3n – old version
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 1 of 13

Once executed, 7ev3n ransomware was installing itself, deleting the clicked copy and silently encrypting files.
The first symptom that something was wrong was a notification that User Account Control is going to be turned
off, and the system needed to be restarted:
The malware was not waiting for the next restart, but executing it by its own. Shortly after another notification the
system was going to shut down:
On the next reboot, the attack of that version of 7ev3n ransomware was announced by a big window, covering the
entire desktop and blocking access to the system. It was difficult to bypass. In order to regain the control over the
system, the user needed to put some special effort (guidance has been provided, i.e. by BleepingComputer).
The ransomware installed itself in %LOCALAPPDATA% – the main file is dropped under the name system.exe:
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 2 of 13

In addition, it dropped one more executable: uac.exe – for User Account Controll bypass, using a well-known
trick with Cabinet files (Akagi) and two bat scripts: del.bat (responsible for deleting the original file) and bcd.bat
– responsible for disabling backup. Content of bcd.bat demonstrated below:
bcdedit /set {current} bootems no bcdedit /set {current} advancedoptions off bcdedit /set {curren
Encryption process
This ransomware is capable of encrypting files off-line.
Encrypted files had their name changed to .R5A.
Patterns found in the encrypted files (R5A extension) look like two different algorithms have been used for it’s
different chunks.
square.bmp : left – original, right encrypted with 7ev3n
Every file was encrypted with a different key.
73v3n – HONE$T
The new edition comes with an improved interface. The most important difference is that the authors gave up the
idea of blocking the full desktop of the infected computer. Although the window with ransom demand cannot be
closed, it is still possible to access other programs. Moreover, the GUI itself has been enriched with features
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 3 of 13

allowing for navigation and getting more information. Similarly to other ransomware, it provides a possibility to
decrypt a few files for the test.
In the new edition the price of decryption is only 1 BTC  (in some samples even 0.5) – that is a huge difference in
comparison to 13 BTC from the previous campaign. The new ransom note offers various models of payment (i.e
possibility to decrypt half of the files for 60% of the original price) and a 20% discount in case of paying full sum
at once. As we can see, the authors learned to be more user-friendly and made a step towards “honesty”.
Installation folder and dropped files are different than in the previous version (sample 1 BTC):
However, this feature depends rather on the particular campaign – in some of the new samples the installation path
is like in the previous edition (sample 0.5 BTC)
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 4 of 13

This time, the main executable is dropped either as conlhost.exe or as  system.exe (depending on the sample).
Also, in the same folder, the ransomware creates 2 files with lists of paths:
files – containing all the encrypted files
testdecrypt – containing files that have been chosen as testfiles that can be decrypted for free
The dropped executable have some unique ID appended to it’s end. It is an array of 34 random characters, with ‘*’
used as a prefix/suffix – format:  ‘*[x00-xff]{34}*’. This key is same on every run for a particular machine.
Example: Left – the sample before being run. Right – the sample that was run and installed on the system:
Persistence is based on a Run registry key:
In addition to displaying the GUI with ransom note it also drops a TXT file with contact information, that can be
used if – for any reason – the main windows didn’t manage to pop-up:
The victim ID is the same after every execution on the same machine, so we can be sure that it is not random (it
may be generated from some local identifiers, i.e. GUID).
Encryption process
The new version also can encrypt files off-line (no key needs to be downloaded from the server).
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 5 of 13

Encrypted files had their name changed to A.R5A (or, for some of the new samples .R5A –just like in the old
version). The new feature is that some randomly selected files are given a different extension: .R4A.
Just like in the to the previous edition, patterns found in the encrypted files (R5A extension) look like two
different algorithms have been used for its different chunks.
square.bmp : first – original, second- encrypted with 7ev3n-HONE$T, third – encrypted with old 7ev3n.
Completely different algorithm has been deployed on the files with R4A extension (introduced newly in 7ev3n-HONE$T)
We can see the patterns of the original file reflected in it’s encrypted content. Such an effect depicts, that file could
have been encrypted by some block cipher – but as well it can be a custom, XOR-based algorithm.
Also in this version, every file with R5A extension is encrypted with a different key.
Experiment
For the purpose of experiments I prepared set of short TXT files, as given below:
They have been encrypted as following:
1.txt
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 6 of 13

16A.txt
long_filename.txt
The file 16M.txt has not been encrypted at all.
We can see that each end every encrypted file starts with a character ‘M’. After that, there is an encrypted content
– it’s length is the same like the original. However, the same plaintext does not produce the same encrypted
content (compare 1.txt and 16A.txt).
The encrypted content is suffixed with a separator ‘**’ and then the encrypted filename is stored (it’s original
length is preserved). The last character is always ‘x0A’. Format of the encrypted file can be defined as:
M**x0A
Files with content length shorter or equal 8 are excluded from the encryption. Similarly, excluded are files which
content begins with ‘M’. More details about why it happens, we will find by analyzing the code.
Network communication
Although the internet connection is not required in the process of encryption, 7even is capable of communicating
with C&C for the purpose of collecting information about the attacked machines.
During beaconing, various information about the current infection are sent. As usual, the victim ID (the same that
is mentioned in the ransom note), wallet ID (hardcoded in the binary), operating system, etc.
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 7 of 13

Sending statistics from the encryption:
Inside 7ev3n (the old version)
The techniques used by 7ev3n are not very advanced, but yet it is worth to take a look.
Analyzed files:
system.exe (a3dfd4a7f7c334cb48c35ca8cd431071) – main file
uac.exe (7a681d8650d2c28d18ac630c34b2014e)– upx-packed payload
The main file (system.exe) comes with UAC bypassing tools embedded (32 and 64 bit version – the one that is
deployed is chosen appropriately for the system). Among strings we can see list of decimal numbers, that need to
be simply converted into ASCII. Beginning of the new PE in strings of the file:
77 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
We can convert it easily into a binary (i.e by this script) getting as a result 64 bit version of the same UAC
bypassing tool (original is packed by UPX  unpacked version available here).
Registry manipulation
Adding a registry key indicating that files are encrypted:
REG ADD "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion" /v "crypted" /t REG_SZ /d 1 /f
Manipulating registry keys – i.e. in order to block the screen:
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "System" /t REG_SZ /d
Inside 7ev3n-HONE$T
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 8 of 13

The first layer is a packing: a simple crypter/FUD with an icon added. It’s role is deception: delivering malicious
payload in a way unnoticed by antimalware tools, as well as making it’s analysis harder.
After defeating the FUD layer we get the first payload (32a56ca79f17fea432250ee704432dfc). Strings and
imported functions are not obfuscated. We can find the path to the project inside the binary – it suggests that we
are dealing with the variant without UAC bypass (in contrary to the previous version, that had it implemented):
C:UsersadminDesktopnew version with NO UACReleaseWin32Project9.pdb
Inside this payload we can find yet another, UPX packed executable: 5b5e2d894cdd5aeeed41cc073b1c0d0f . It is
also not very well protected and after unpacking it with standard UPX application we get another executable
(d004776ff5f77a2d2cab52232028ddeb) with all the strings and API calls visible.
Execution flow
First execution is used just for the purpose of installation.
When the sample is deployed, it makes it’s copy into the predefined installation folder (destination may vary for
various samples). It drops a batch script that is supposed to delete the initial sample
The unique, hardware-based ID is written at the end of the executable that has been copied to the destination path:
Below – the same key – at the end of the installed sample:
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 9 of 13

In the meanwhile,  of the installation, malware sends the beacon to a hardcoded URL.
Then, the new sample is deployed and the initial sample terminates and gets deleted.
The installed sample is supposed to run the second phase – that encrypt the files. Decision which execution path
should be deployed (installation, encrypion, or GUI is based on the environment check.
Registry manipulation
Adding a registry key indicating that files are encrypted:
REG ADD "HKEY_CURRENT_USERSOFTWARE" /v "crypted" /t REG_SZ /d "1"
Manipulating other registry keys – related with persistance, status of decrypting etc.
REG ADD "HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun" /v "allkeeper" /t REG_SZ /d "" /
What is attacked?
This ransomware encrypts local drives as well as mapped network shares.
Encrypted extensions are hardcoded in the binary as UNICODE strings:
Summary of all the file extensions that are attacked:
ai arw txt doc docm docx zip rar xlsx xls xlsb xlsm jpg jpe jpeg bmp eql sql adp mdf mdb odb odm odp
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 10 of 13

How does the encryption work?
7ev3n-HONE$T encrypts files in a loop, one by one. It completely changes their names – but at the same time it
stores the previous name (as we know, files that are decrypted have their names recovered).
The executable comes with 3 hardcoded strings, that are used in the process of encryption. Their exact role will be
described further.
Every encrypted file have it’s content prefixed with ‘M’. This character is also checked in order to distinguish, if
the file has been encrypted. If the ‘M’ was found as a first character of the buffer, the file will not be encrypted:
Authors left a log in the code, leaving no doubt about their intentions, that this character is used as an indicator of
the encrypted file:
Of course such a check is not giving a precise detection and if it happens that we have a file starting from ‘M’ it
will not be encrypted.
This ransomware produce encrypted files by two ways – they can be distinguished by different extensions: .R4A
or .R5A.
After deobfuscation we were able to reconstruct both algorithms and notice, that they are custom and not
employing any strong cryptography.
R4A algorithm turned out to be an XOR with a hardcoded key:
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 11 of 13

ANOASudgfjfirtj4k504iojm5io5nm59uh5vob5mho5p6gf2u43i5hojg4mf4i05j6g594cn9mjg6h
R5A algorithm is also XOR-based, but not that simple – It have several execution steps:
1. A hardcoded string is scrambled and expanded to a predefined length (in analyzed samples it was 0x10C).
The algorithm used for scrambling differs from sample to sample.
2. The scrambled key (0x10C byte long)  is XOR-ed with the original file path.
3. The key created in the previous step is used to XOR file content
4. The XORed content is divided to 4 parts, that are processed by 2 different XOR-based algorithms. First and
Third quarter are processed by algorithm I. Second and fourth – by algorithm II. (That’s why we have seen
4 ‘strips’ on the visualized content).
Full reconstruction of the used algorithms you can see here.
Adding appropriate extension to the file name:
After encrypting the content, some more data is appended to it. At the beginning – the previously mentioned ‘M’
character – as an indicator that file is encrypted. At the end – a string “**” –  as a separator after which the
encrypted file name of the particular file is stored.
Filename is also encrypted in a very simple way – by XOR with one of the hardcoded keys.
for R4A:
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 12 of 13

ANOASudgfjfirtj4k504iojm5io5nm59uh5vob5mho5p6gf2u43i5hojg4mf4i05j6g594cn9mjg6h
for R5A:
ASIBVbhciJ5hv6bjyuwetjykok7mbvtbvtiJ5h6jg54ifj0655iJ5hok7mbok7mbvtvtv6bjfib56j45fkmbvtiJ5hv6bokok7mb
The encrypted content is saved first to the original file. After that the file is moved under the new name:
Conclusion
7ev3n ransomware has been around for quite a while, but till now not many details about its internals have been
revealed. It turned out to have pretty unexpected features. Although a lot has been told about weakness of
solutions that are based on custom encryption, there are still some ransomware authors going for it. That’s why it
is worth not making any rushed decisions in paying the ransom. Sometimes the code is obfuscated and finding out
how it really works takes some time for analysts – but it doesn’t mean that the encryption is really unbreakable.
Work on the full version of the decryptor is in progress. For now you can see the proof-of-concept script (tested on
this variant): https://github.com/hasherezade/malware_analysis/tree/master/7ev3n
Appendix
http://www.bleepingcomputer.com/news/security/7ev3n-ransomware-trashes-your-pc-and-then-demands-13-bitcoins/ – about 7ev3n (the old version)
http://www.nyxbone.com/malware/7ev3n-HONE$T.html – about 7ev3n-HONE$T
About the author
Unpacks malware with as much joy as a kid unpacking candies.
Source: https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n-ransomware/
Page 13 of 13