More evil A deep look at Evilnum and its toolset fe shop tor link, bin go dumps

ESET research gives a detailed picture of the operations of the Evilnum group and its toolkit deployed in attacks against carefully chosen targets in the fintech sector
ESET has analyzed the operations of Evilnum, the APT group behind the Evilnum malware previously seen in attacks against financial technology companies. While said malware has been seen in the wild since at least 2018 and documented previously, little has been published about the group behind it and how it operates.
In this article we connect the dots and disclose a detailed picture of Evilnum’s activities. The group’s targets remain fintech companies, but its toolset and infrastructure have evolved and now consist of a mix of custom, homemade malware combined with tools purchased from Golden Chickens, a Malware-as-a-Service (MaaS) provider whose infamous customers include FIN6 and Cobalt Group.
According to ESET’s telemetry, the targets are financial technology companies – for example, companies that offer platforms and tools for online trading. Although most of the targets are located in EU countries and the UK, we have also seen attacks in countries such as Australia and Canada. Typically, the targeted companies have offices in several locations, which probably explains the geographical diversity of the attacks.
The main goal of the Evilnum group is to spy on its targets and obtain financial information from both the targeted companies and their customers. Some examples of the information this group steals include:
According to what we have seen during our investigation, the group has also gained access to IT-related information such as VPN configurations.
Targets are approached with spearphishing emails that contain a link to a ZIP file hosted on Google Drive. That archive contains several LNK (aka shortcut) files that extract and execute a malicious JavaScript component, while displaying a decoy document. These shortcut files have “double extensions” to try to trick the user into opening them, thinking they are benign documents or pictures (in Windows, file extensions for known file types are hidden by default). The contents of one of the ZIP files are shown in Figure 1.
Once a shortcut file is opened (it doesn’t matter which one, as they all do the same thing), it looks in the contents of its own file for lines with a specific marker and writes them to a .js file. Then this malicious JavaScript file is executed and it writes and opens a decoy file with the same name as the shortcut, but with the correct extension. It also deletes the shortcut file. The documents used as decoys are mostly photos of credit cards, identity documents, or bills with proof of address, as many financial institutions require these documents from their customers when they join, according to regulations (this is known as “Know Your Customer”). One such decoy is shown in Figure 2 (blurred for privacy).
These decoy documents seem genuine, and we assume that they have been collected by this group during years of operation. Documents are collected actively in the group’s current operations, as it targets technical support representatives and account managers, who regularly receive these kinds of documents from their customers. The group reuses the documents on different targets, unless the targets are from different regions.
The JavaScript component is the first stage of the attack and can deploy other malware such as a C# spy component, Golden Chickens components or several Python-based tools. The name Evilnum was given to the C# component by other researchers in the past, but the JS component also has been referred to as Evilnum. We have named the group Evilnum as that is the name of their flagship malware, and we’ll refer to the various malware pieces as components. An overview of these is shown in Figure 3.
Each of the various components has its own C&C server, and each component operates independently. The operators of the malware manually send commands to install additional components and use post-compromise scripts and tools if they consider them necessary.
Most servers used by the malware are referenced by IP addresses; domain names have not been used. The only exceptions are the C&C servers used by the Golden Chickens components; malware purchased from a MaaS provider, as we describe later.
Those referenced by an IP address can be split into two groups, based on the hosting provider. The majority of them are hosted with FreeHost, a Ukrainian provider. The rest are hosted in the Netherlands, with Dotsi.
This component communicates with a C&C server and acts as a backdoor without the need for any additional program. However, in most attacks that we have seen, the attackers deployed additional components as they saw fit and used the JS malware only as a first stage.
The first known mention of this JavaScript malware was in May 2018 in this pwncode article . The malware has changed since then and we illustrate these changes in Figure 4.
Differences between version 1.3 and the others are noteworthy, as the server-side code for the C&C was changed and commands are different. In that early version it was not possible to upload files to the C&C, only to download files to the victim’s computer. Also, as new versions appeared, the malware was extended with some Python scripts (see the Post-compromise toolset section) and external tools such as ChromeCookiesView .
Despite the differences, the core functionalities remain the same in all versions, including the retrieval of the C&C server’s address from GitHub, GitLab or Reddit pages created specifically for that purpose. Figure 5 shows an example of a Reddit page that is parsed by the malware to retrieve a C&C address.
This component achieves persistence through the Run registry key and has full backdoor capabilities: it can download and execute binaries, run arbitrary commands or upload files from the victim computer to the C&C server. We will not go into details about the technical aspects of this component, as a good analysis of the latest version was published recently by Prevailion .
In March 2019, Palo Alto Networks described malware with very similar functionality to the JS component, but coded in C#. That version (2.5) obtained the address of its C&C by dividing a number by 666, and was therefore named Evilnum by Palo Alto Networks researchers. Since then there have been new versions of the C# malware, the latest of them being version 4.0, which we first saw in April 2020. The number 666 is not used anymore and the PDB paths of the executables show that the developers call their malware “Marvel”. However, we will continue to name the malware Evilnum to avoid creating confusion.
The latest version comes bundled in an MSI file (Windows Installer) and runs independent of the JS component. Furthermore, it has different C&Cs than the JS component. However, in all cases that we have seen, the C# component was downloaded and executed after the JavaScript malware gained initial access. The structure of this component is shown in Figure 6.
 
When the MSI file is executed, three malicious components, along with some .NET Framework library files, are written to disk in %LOCALAPPDATA%\Microsoft\Mediia. The file copier is the first to be executed and its only purpose is to move the files to another location in %LOCALAPPDATA% (see the Indicators of Compromise section for the folder names). The loader is then executed and it loads and decrypts the contents of the file System.Memmory.dll, which is the actual malicious payload (DLL Agent) for the C# component. AES encryption is used for the DLL and for obfuscation of the strings in the payload. The same key and initialization vector are used to encrypt the strings in all of the different versions.
The IP address of the C&C server is hardcoded and in plain text. A GET request is sent for /Validate/valsrv and if the response body contains the text youwillnotfindthisanywhare, then the server is accepted. Otherwise, a GitLab page is parsed to get the IP address of a second server.
The following capabilities are present in version 4.0:
The commands that can be sent to the malware are:
Version 2.5 was the first documented version of the C# component (first seen by ESET in December 2018). Then we saw v2.7.1 (November 2019), v3 (December 2019) and v4.0 (April 2020). The most important differences between the latest version of the malware and previous ones are:
The JS and C# components are connected to each other: the latter takes screenshots whereas the former doesn’t, but it has code that looks for screenshot files and sends them to its C&C server. The C# component also deletes all files with the .lnk extension in the %LOCALAPPDATA%\Temp folder, cleaning leftovers from the initial compromise by the JS component. So even if the C# component has limited functionalities (it can’t download or upload files), it provides redundancy with a different C&C server and extra persistence in case the JS component is detected or removed from the victim’s computer.
In a small number of cases, the Evilnum group has also deployed some tools purchased from a Malware‑as‑a‑Service provider. This term is used to describe malware authors who offer not only their malicious binaries, but also any necessary infrastructure (such as the C&C servers) and even technical support to their criminal customers.
In this case the MaaS provider is known as Golden Chickens and has other customers (apart from this group), such as FIN6 and Cobalt Group . Older versions of all the components that we describe in the following sections were seen previously, in an attack against eCommerce merchants that Visa attributed to FIN6 in February 2019. We believe that FIN6, Cobalt Group and Evilnum group are not the same, despite the overlaps in their toolsets. They just happen to share the same MaaS provider.
The Golden Chickens tools come as ActiveX components (OCX files) and all of them contain TerraLoader code, which serves as a common loader for the various payloads available to Golden Chickens’ customers. These tools are used by Evilnum as follows:
The TerraLoader code performs several integrity checks before dropping the payload. These checks implement anti-debugging techniques and try to identify anomalies to prevent execution in sandboxed environments. Some of these techniques range from detecting incorrect parameters, filenames and extensions, to detecting hardware breakpoints or identifying specific modules loaded into the subject process. Should these checks all pass, the actual payload is decrypted and executed.
We have seen Evilnum deploy the following Golden Chickens payloads in their attacks:
Researchers from Positive Technologies recently analyzed some tools used by the Cobalt group, including More_eggs version 6.6, which is one of the versions used by Evilnum group. They have a very good analysis of TerraLoader, so we suggest checking their report (section 4).
More_eggs is a JavaScript backdoor that communicates with a C&C server and accepts commands. It has been used in the past by other groups targeting financial companies. Evilnum uses it in conjunction with its homemade backdoors in order to provide redundancy and additional persistence on victim networks.
We have seen Evilnum use 32-bit ActiveX components with TerraLoader code that runs More_eggs versions 6.5, 6.6 and 6.6b – the latest available versions. They do so by dropping msxsl.exe (a command line transformation utility that is a legitimate Microsoft executable) and having it execute the JavaScript code, very similar to what was described in this article by IRIS .
The dropped JavaScript code is generated on the fly by the ActiveX component, and there are some considerations during analysis:
The core functionalities are the same as described in the article linked above, although there is a new command, more_time, not mentioned there. This command is similar to the documented command via_c, which executes its parameter with cmd.exe /v /c . The difference is that it additionally sends the output back to the C&C (via_c only sends whether or not the command succeeded).
Evilnum group also uses 64-bit executables that decrypt and run a Meterpreter instance in memory. The use of Meterpreter gives them flexibility and the ability to run various payloads in a stealthy and extensible way.
The structure of these components and the integrity checks implemented were identified as TerraLoader code. That’s why we refer to these components as TerraPreter. Decompiled code of the main malicious routine is shown in Figure 7.
The routine labeled Dummy calls a series of APIs that don’t do anything. The RC4 function initialization brute-forces the key to use by taking a base string and appending a number to it that is incremented in each iteration. It then decrypts a 16-byte buffer with the candidate key using RC4. If the decrypted buffer matches a hardcoded string, then that candidate key will be the chosen RC4 key for later use. We believe this may be a time-wasting countermeasure against emulators.
After the embedded buffer with the payload is decrypted, the malware will finally set a callback to the GrayStringW API function, pointing to the decrypted buffer. After going through many layers of decoding, Meterpreter’s metsrv.dll is loaded in memory. From this point on, what we see is regular Meterpreter behavior that has not been modified. However, we will continue to describe how communications are performed.
TerraPreter communicates with a C&C server using HTTPS and retrieves a series of commands. C&Cs we have seen contacted are cdn.lvsys[.]com and faxing-mon[.]best. The first one was redirected to d2nz6secq3489l.cloudfront[.]net. Every time a C&C receives a request, it sends different binary data XORed with a random 4-byte key. The malware reads the key to be used for decryption from the first 4 bytes of a 32-byte header that prefixes the encrypted data. Figure 8 shows an example.
The first command sent by the C&C is core_patch_url, which changes the last part of the URL for subsequent requests. Then core_negotiate_tlv_encryption is sent by the C&C, along with its public key. From this point on, messages will be encrypted before they are XORed.
TerraStealer is also known as SONE or Stealer One. It scans for many browsers, email, FTP and file transfer applications, to steal cookies and credentials. One of the binaries we analyzed had logging activated. Part of one such log is shown in Figure 9.
Another component used by this group is a variant of TerraTV. It runs a legitimate TeamViewer application but hides its user interface elements, so that the operators of the malware can connect to the compromised computer undetected.
When executed, TerraTV drops several signed TeamViewer components into C:\Users\Public\Public Documents\57494E2D3850535046373333503532\. The dropped files are shown in Figure 10.
ACTIVEDS.dll is not signed and it is where the malicious code resides. There is a Windows DLL with that same name in the system folder, but since the malicious DLL is in the same directory as the TeamViewer executable, it is found first, and therefore is loaded instead of the Windows DLL. This is known as DLL search order hijacking . This ACTIVEDS.dll hooks several API calls in the TeamViewer executable to hide the application’s tray icon and to capture login credentials. The part of the code where the hooks are set is shown in Figure 11.
The Windows API call DefWindowProcW (called several times by the TeamViewer executable to process messages directed to its main window) is hooked with a routine that writes TeamViewer’s ID and password to the file %APPDATA%\log_CZ72kGqTdU.txt. With these credentials, and TeamViewer running with no visible tray icon or window, the operators of the malware can remotely control the computer, via its GUI, at any time.
The malicious components previously mentioned are frequently extended with several additional tools in the Evilnum group’s arsenal. In most of the compromises we have seen, the attackers utilized publicly available tools, but have also developed some custom scripts. Usually they keep their tools in password-protected archives on their servers and decompress them on a victim’s PC as needed.
The Evilnum group has been operating for at least two years and was active at the time of this writing. It has an infrastructure for its operations with several different servers: one for communications with the JS component, another for the C# component, a different one for storing its tools and exfiltrated data, proxy server, and so on. This group targets fintech companies that provide trading and investment platforms for their customers. The targets are very specific and not numerous. This, and the group’s use of legitimate tools in its attack chain, have kept its activities largely under the radar. Thanks to our telemetry data we were able to join the dots and discover how the group operates, uncovering some overlaps with other known APT groups. We think this and other groups share the same MaaS provider, and the Evilnum group cannot yet be associated with any previous attacks by any other APT group.
A comprehensive list of Indicators of Compromise (IoCs) and samples can be found in our GitHub repository .
For any inquiries, or to make sample submissions related to the subject, contact us at threatintel@eset.com.
Special thanks to Ignacio Sanmillan for his help with the analysis of the Golden Chickens components.
fe shop tor link bin go dumps