Redline Stealer - Malware Analysis Lab

Overview

Part 1: Dumping Dynamically Loaded Payloads

Let’s take a look at a recent sample of the .NET based malware known as Redline Stealer. We will cover some techniques on how to identify the malware and reverse engineer it. Taking a recent sample uploaded to malshare.

• Source: Malshare.com

First off we obtain this sample with a particular SHA256 hash:

Starting Host IOC: 3bd982f82a1b2f074b02fe7cc7413f1e083f19108ae2612b2b5a741a9858f7f4

Examining the binary at a glance we can see it is a 32-bit .NET assembly with an original name of BaseChannelObjectWithPropert.exe which is masquerading as a product called Change Detector.

In addition, examining this with PE-bear shows that it has a PDB string of the following:

C:\Users\Administrator\Desktop\Client\Temp\vXjAsidxjf\src\obj\x86\Debug\BaseChannelObjectWithPropert.pdb

Given this is a .NET executable, we can examine this in dnSpy. At a glance this binary appears interesting as it only has a few imports including the Diagnostics and Reflection classes. Although these may be legitimate, it does lead me to begin to think this may use unmanaged code or injection.

Looking into the main program entry point we can find that this is executing a new instance of it’s ‘MainForm()’ class.

Examining this we see it is retrieving a public method called ‘K67WB7wrc’ using the reflection class which will be loaded dynamically at runtime by using ‘GetMethod’. This is leveraging a Custom Binder and CLR to run the code.

By debugging using dnSpy with a breakpoint before this is invoked, we can see that it is attempting to run dynamically loaded code with an original name of “H5lJ05BU7EajaXhAma.c0MIdh5giS0KIBpS0s” (Namespace+Name) that resolves to a module called ‘Cerbera.dll’.

Stepping into each function for a brief period we begin to see that this is passed 3 parameters when invoked.

4576656E74526567697374726174696F6E546F6B656E4C69737457697468436F
6D73497A496B6C6E74
ChangeDetector

Eventually we make it to ‘K67WB7wrc’ attempting to be invoked which causes Cerbera.dll hosting this to be decompiled in dnSpy. Of interest is that the code is heavily obfuscated, but we do see reference to raw assembly being loaded.

To ensure we can further analyse this module without many issues, we can use dnspy’s ‘Modules’ window to dump the Cerbera DLL directly from memory.

After this, by setting a breakpoint on the raw assembly load, and running the program, it will first cause the thread to sleep, before hitting our breakpoint. At this point we have another module in memory loaded under the ‘rawAssembly’ variable and can view this in a memory window.

We can also save this entire memory region to another DLL file on disk.

At this stage we have 2 new DLLs to analyse, Cerbera, and one I’ve labeled ‘Stage2’. The SHA256 of these files are as follows:

SHA256 (Cerbera.dll): 840BE1D54AC08FDEC3556B93FF92AF7E2F6D7C909A7606C59C5AC777670E2742
SHA256 (Stage2.dll): 6EEE2F6A6FDEF5EEA8D485A86E69697335F42882FB90E54A472AA99ACFD1736D

Part 2: Investigating Cerbera and Stage2

Taking a look at Cerbera and Stage2, both appear to be .NET based DLL files.

Opening these in dnSpy reveal they have the original file names of ‘Cerbera.dll’ which was already known, and ‘IVectorView.dll’ (with version information 1.9.0.0); however, the decompiled code is quite obfuscated.

Using de4dot we can see if there’s any known obfuscator in use on these binaries.

de4dot -d Cerbera.dll Stage2.dll

Because these are either using an unsupported obfuscator or not obfuscated, this prints “Unknown obfuscator”.

Moving back to the debugging, bny using a combination of stepping into and stepping out of methods (F11 and SHIFT + F11)…

MORE TBA