This blog post will provide an analysis of the malicious Redline Infostealer payloads which have been taken from a real life malware incident, responded to and triaged by the ThreatSpike SOC team. This analysis will be broken down to demonstrate, describe and explain the various stages of the attack chain.

Overview:

  • We shall begin by looking at the zip the user had downloaded and extracted from a malicious website. Once extracted, we have a folder that contains a >700MB executable along with another folder that contains various miscellaneous .admv files (benign). The initial executable acts as a loader for a second-stage payload. When the user executes the Rufus.exe, an initial process will load and proceed to download a DLL from an attacker-controlled web server.
  • Once downloaded, the initial process creates a powershell process that executes an encoded powershell command to suspend the activity in the session for a specified period of time. During this time, a DLL is downloaded from a web server and is loaded into the memory of the initial process.
  • The DLL seems to be a variant of PureCrypter injector. It contains an encoded embedded resource, which once decoded is the redline infostealer executable. After the sleep process has finished, the initial process kills itself after creating two new child processes. This resource is then injected into one of the processes “Applaunch.exe”, that will persist and the information stealer will run inside of this process.
  • Lastly, the infostealer will use the Applaunch process to beacon out to the c2 server using the net.tcp c2 framework. It is also capable of remote execution to download additional files and execute remote commands.

We can break down this analysis into 5 distinct sections in the attack chain:

  • Initial archive analysis
  • Rufus loader
  • DLL injector
  • Redline infostealer analysis
  • Beaconing to the c2 server

In part 1 of this blog, we will look into the initial archive, the “Rufus” loader and the DLL injector.

Initial Archive analysisInitial Archive analysis

The zip archive “rufus-3.19.zip“ is the initial file that is downloaded by the user onto the computer. From the triage conducted, the user had downloaded the zip from a website that the threat actor created to impersonate the Rufus website. It is common for threat actors to create websites that will mimic commonly used and sought-after software in order to get users to install their malware.

It is likely that the threat actors were abusing Yahoo’s ad network by purchasing ad space for popular keywords (such as “rufus”). This exploits the very common human behaviour to open up a browser and do a quick search to get to the website you want, without entering the full URL.

Figure 1: An example of a website that attempted to impersonate rufus.ie

The trojan zip file, with a size of 4MB, when decompressed contains an executable named Rufus.exe with a file size of 734MB. This is an immediate warning sign, since most executable files are not this large. Once analysed with a hex editor, we can see that the attackers have used consecutive bytes of 0x30 as padding in between the executable and the signature to increase the size of the file. The main reasoning behind this is to evade AV detection as well as prevent analysis by sandboxes and malware analysis tools, since many would not be able to process such a large file. Removing this padding trims our file into a valid PE with a size of 63MB.

Figure 2: Padding of 0x30 bytes to inflate the PE.

We begin by opening the inflated file in Pe-bear and take a look at the raw size diagram to see that the .txt, .rsrc and .reloc sections cannot be seen relative to the size of empty bytes added.

Figure 3: The raw size of sections in the padded Rufus.exe Figure 4: The raw size of sections in the trimmed Rufus.exe

Rufus loader

The Rufus.exe file from above uses Smartassembly for obfuscation combined with possibly another unknown obfuscator. Smartassembly is a sophisticated obfuscator and is used by many organisations as a means to protect IP of a .NET executable.

Figure 5: We can open the PE in DIE to observe whether it has been packed or obfuscated in any way Figure 6: Overview of loader insider CFF explorer.

The file signature of this PE fails code integrity checks (due possibly to an error from the malware authors) and can be used as a simple detection opportunity.

From the screenshot below, it appears to be obfuscated using Smartassembly. In particular, the attackers used the version SmartAssembly 8.1.0.4892.

Figure 7

We can still deobfuscate many techniques using Smartassembly using tools such as de4dot, although there are some techniques that will be more resistant.

To start the dynamic analysis via debugging in dnSpy, we start off with loader code entry point:

Figure 8: Rufus.exe entry point

The key functionality of the Rufus.exe is:

  • To create and manage the child processes, required later on
  • Unpack and create the legitimate Rufus executable to run as a process
  • To download the second-stage payload of the DLL which will be used to host and inject the Redline Stealer malware

The second stage payload is downloaded when the Rufus.exe process creates a HTTP request to an attacker-controlled webserver, with an IP address based in Belgium.

The URL is:
hxxp://45[.]143[.]201[.]7/typedef.struct_WIN32_MEMORY_RANGE_ENTRY2_Ydoybbga[.]jpg

The file impersonates a jpg file in order to appear less suspicious. However, this is a regular technique used by several variants of Redline Stealer in the past.

The screenshot below shows how the loader is using HttpWebRequest along with the “Uri” variable which is equal to the URL of the second-stage payload. Once executed, this will create a HttpRequest to download.

Figure 9

Next, we will utilise the webClient and DownloadData methods to download the injector DLL into the memory of the initial process. This is so that the DLL can be loaded into the process to perform its injection later on in the chain. This technique of loading the DLL is in fact done using the open source software Netloader. Netloader is used to “load any C# binary from file path or URL, patching AMSI and unhooks ETW”.

Figure 10

The initial Rufus loader employs various obfuscation techniques and complexity. It does this using Smartassembly and perhaps other obfuscators. A few techniques that have been used are:

  • Compression and encryption of managed resources
  • Changing the names of methods and fields (“Name mangling”)
  • Removal of unnecessary metadata
  • Encoding of strings used in the loader

In order for the downloaded DLL to be dynamically linked to the Rufus process and allow the attackers to invoke its methods, the use of reflection is required; since the DLL code is not in the build process. This is done by utilising the “System.Reflection” namespace.

Reflection is useful in the following scenarios:

  • When it is necessary to access attributes in your program’s metadata
  • For examining types and in an assembly
  • Building new types at run time
  • For performing late binding, accessing methods on types created at run time

Below, we can see Rufus.exe using the mscorlib.dll to specify the URI of the dropper and the file path of the rufus executable on the machine.

Figure 11

Rufus executable downloads and loads the DLL in its memory under the name Zostmhmmqw via Netloader.

Figure 12

Very shortly after, the DLL file is downloaded from the URL. The initial process file pauses the program by creating a powershell child process that runs an encoded powershell command “powershell.exe -enc UwB0AGEAcgB0AC0AUwBsAGUAZQBwACAALQBzACAAMgAwAA==”.

This decodes to “Start-Sleep -s 20”.

This command suspends the activity in the session for 20 seconds. This is necessary in order for the Redline Stealer to be injected into the chosen process.

After the 20 seconds have passed, the powershell.exe process is killed. The Rufus.exe process will then create two new child processes: Kgcxsxcxhacdareyrufus-3.19.exe (Rufus application) and Applaunch.exe (used for injection and connecting with c2) before the initial process is also killed.

Figure 13: Process tree

The child process Kgcxsxcxhacdareyrufus-3.19.exe is in fact a legitimate Rufus executable and will open. Upon calculating the SHA256 hash, it is identical to the legitimate Rufus application.

Once the payload has been downloaded, the Rufus application will also automatically open for the user to interact with the GUI for Rufus 3.19.1911. The Rufus application is a popular utility used by many businesses to help format and create bootable USB flash drives, such as USB/pendrive.

The reasoning behind this is so that, to an unsuspecting user who has just clicked on the malicious executable, it will appear as though it is indeed the real Rufus application with the same functionality. Therefore, the user may not report this to the security team at all.

It should be noted that the behaviour of an executable, created by another executable and then run automatically is suspicious.

Figure 14

DLL injector

This payload, although downloaded as “typedef.struct_WIN32_MEMORY_RANGE_ENTRY2_Ydoybbga.jpg”, is named Zostmhmmqw.dll and is written in .NET language and obfuscated with SmartAssembly. Its main purpose is to deliver the Redline Infostealer Payload, by injecting into a newly created process.

After both static and behavioural analysis, as well as comparing this DLL with multiple instantiations of known PureCrypter injectors, it appears as though this DLL is also built using PureCrypter injector as a template. The PureCrypter payload, a popular loader among many cybercriminal gangs, is currently being sold for $109.00 for a 3-month subscription.

Figure 15: PureCrypter is currently being sold for $109.00 for a 3-month subscription

The DLL is loaded by the initial process, which executes itself again and then replaces the current thread context with the downloaded DLL. The initial process then creates a child process “Applaunch.exe”, which the DLL uses to inject the Redline Infostealer payload from its resources. The DLL can hook into Windows API functions to collect user credentials after being loaded by Rufus.exe to write bytes to particular virtual addresses for modules user32.dll and nsi.dll.

It can also interact with the Windows Registry to collect information about the system, configuration and software that has been installed. It can read software policies to get information about the OS and hardware of the machine such as version, patches, architecture and more.

The downloaded DLL had all of its individual bytes reversed, a simple technique used for obfuscation and so the executable reversed the bytes before loading the DLL into its memory. To help analyse the behaviour, the tool de4dot was used to help with deobfuscation and renaming some variables.

After some manual reviewing of the decompiled C# code, we can see (Figure 16) that there is an embedded resource payload (named Fjtiuzuykcjfgbijyop and stored with the resource named “Zostmhmmqw.Properties.Resources.resources) with an offset of 0x00158533. This payload is used by the DLL to inject into the newly created process Applaunch.exe.

Figure 16: Resources section in DLL

Using a similar technique as before, seen on (Figure 17, line 11), the DLL reverses the payload which gives us an archive, it will then gunzip the archive to obtain the Redline Infostealer and then load the payload as an assembly with Assembly.load. It will then proceed to invoke its entry point (Figure 17, line 21)

Figure 17

The injector DLL uses multiple persistence techniques. One example being the use of the Startup module to delay the execution of the injector.

Figure 18

This module also allows persistence to be established for the DLL through RunKeys, Winlogon or Shell Folders.

Figure 19

The DLL contains a resource named costura.protobuf-net.dll.compressed within the resources section. When decompressed, we have the protobuf-net.dll. This is another open-source tool, available on GitHub, used as a “contract based serializer for .NET code”. It is used for object serialisation and deserialization of the PE.

The four other resources are all encrypted or encoded and are called in the execution of the DLL when they are decrypted and either used as libraries, used for execution in memory or injected into processes.

You can see the use of serialisation and deserialization within memory using protobuf-net below:

Figure 20 Figure 21

The above is a screenshot showing how the DLL looks without using any deobfuscation techniques.

We will now have a look into some of the key functionality of this DLL:

The DLL uses iCryptotransform interface to perform cryptographic functions, including performing application-defined tasks that allow freeing, releasing or resetting unmanaged resources. This can be seen below by noticing the use of the method Dispose() combined with the IDisposable() interface- which is specifically designed to provide a mechanism for releasing unmanaged resources.

Figure 22

The DLL makes use of encryption to evade Antivirus software such as encrypting strings and variable names. The encryption key, IV and specification of block size is all contained within the Encryption module (see Figure 23).

Figure 23

Below, we can see that AES is also being used as a symmetric encryption algorithm to encrypt certain resources and variable names. This is also used to add an additional layer of obfuscation and to make it more difficult for an analyst or automated system to read.

Figure 24

The DLL also contains an anti-debugging class designed to identify an analysis environment. This is done using CheckRemoteDebuggerPresent and cataloguing classes that have been loaded (Figure 25).

Figure 25

The following class gives this payload the ability to start a process. This is in order to create a new process to inject its payload to.

Figure 26

There is also a class which has the capability to delete files, registry subkeys and processes.
To delete files, the class first gets the file or directory using the Environment.GetFolderPath and Directory.GetFiles method and converts the file into the text variable, it will then use the method File.Delete(text) to delete the file.

To delete processes, the class uses the method Process.GetProcesses and stores the process in the variable process. It will then use the process.Kill() command to kill the process.

Figure 27

Similarly, to delete a registry subkey value, the class uses the method registrykey.DeleteValue(name).

Figure 28

This marks the conclusion of the first part of this blog, where we looked at the initial archive, the downloader executable and the DLL injector.

In part 2, we'll take a look at the final Redline Infostealer payload, reverse engineer a few key components of the infostealer, investigate all of its functionalities and then look at the C2 framework being used to communicate with the C2 server as well as how attackers are able to execute remote commands post-exploitation. Then finally we will outline some detection and reducing attack surface opportunities.