Malware Analysis Trojan MSIL/Injector - static

[LabZero]

MD5: 08aebd590a43b2906ba678860c2b7f4c
SHA1: 16e216d541165313bd2ddf5e77a2079bd94588e3
SHA256: e9ca3f54aa5ccc3d97503435da2cc5dfb26f4c68623c3970a20fa9e86cd8d4f1

Firstly I used PEiD for identify the malware, it is a .NET file, and the linker version is 8.0.

File sections:

The entropy is clearly packed, as you can see in the screenshot below, that it shows also that the fast check give "packed".

With PEiD you can see the strings inside the portable executable, in this screenshot there are the strings, that I flagged as malicious; in particular "kernel32.dll", infact in one of the functions of the code there is a -dll import- of this .dll file.
This is suspicious because with the use of kernel32.dll there could be a low level and deep infection on the OS.
Another suspicious string that I found while the analysis was "Marhsal", and this was present also in the code, used by some functions. Marshaling is the act of taking data from the environment you are in and exporting it to another environment. In the context of .NET, marhsaling refers to moving data outside of the app-domain you are in, somewhere else.
In the malware there are also strings referred to bytes operations, like "WriteByte" and "ReadByte", these operations can be intrusive and dangerous, especially because this PE works on low level (for kernel import).

The malware uses mscoree.dll and there are in addition some strings clearly encrypted/obfuscated, as you can see in this screenshot:

Here below are the PE details:

...but the most interesting part of this analysis is this:

The malware uses this function, which the name is obfuscated, to marshaling bytes read from another function; this operation is done in a loop, and it means that the malware operates on all bytes got from the function called before the loop.
A repeated code line in the source is "object.Equals(null,null);", this command is for verify the equality of two objects, but in this case the objects passed as parametres are null.

Marhsal is used also on a function, which is called in the code line below.

In this screenshot you can see the [DllImport] of kernel32.dll
And it is initialized a variable called VirtualProtect, which is static and external, and it is used also in another function, look that it returns an output of type uint (unsigned integer)

Below is the usage of the variable called "VirtualProtect".

Look especially at the return function and that the VirtualProtect output; so the output of VirtualProtect is returned by this function.

Here below is another function, that uses another time Marshal feature; in particular the function "AllocHGlobal", which takes as parameter the length of an attribute variable.

The malware initializes also some byte arrays, this is one of them:

The other arrays contains lots of elements(bytes), used for write/read bytes operations.

Malware references:

 

[DardiM]

Thanks for your post, very interesting

If I well understand what you explained :

In the main function :

- calls a function (and sub-function) that allocate memory, gives it "execute, read-only, or read/write" access (PAGE_EXECUTE_READWRITE access : 64u => x40) , and return a pointer to it (saving the precedent access value on uint num).
- writes in this location the content of JDqxMeJQJV (array of bytes)
- converts the pointer to this location in a delegate (a reference type that can be used to encapsulate a named or an anonymous method) and save it in bTzaXsnJFIxb
(then JDqxMeJQJV correspond to, like you said, a function moved, that will be call later)

and later :
- converts the delegate bTzaXsnJFIxb to a pointer to above function
- calls this function with bTzaXsnJFIxb();

Am I right ?

Proceeding this way should make the functions used less easily readable / understandable on static analysis, a good method
I suppose a lot of important functions used by this malware are called the same way.

Please, can you post a screen of JDqxMeJQJV array (if it contains data, in static analysis) ?
Is this a long array ?

I would like to see what it looks like

 

[LabZero]

Thanks for your post, very interesting

If I well understand what you explained :

In the main function :

- calls a function (and sub-function) that allocate memory, gives it "execute, read-only, or read/write" access (PAGE_EXECUTE_READWRITE access : 64u => x40) , and return a pointer to it (saving the precedent access value on uint num).
- writes in this location the content of JDqxMeJQJV (array of bytes)
- converts the pointer to this location in a delegate (a reference type that can be used to encapsulate a named or an anonymous method) and save it in bTzaXsnJFIxb
(then JDqxMeJQJV correspond to, like you said, a function moved, that will be call later)

and later :
- converts the delegate bTzaXsnJFIxb to a pointer to above function
- calls this function with bTzaXsnJFIxb();

Am I right ?

Proceeding this way should make the functions used less easily readable / understandable on static analysis, a good method
I suppose a lot of important functions used by this malware are called the same way.

Please, can you post a screen of JDqxMeJQJV array (if it contains data, in static analysis) ?
Is this a long array ?

I would like to see what it looks like

When we statically analyze a malware, it is often difficult to be sure. In this case part of the code is encrypted/obfuscated and you have to work on what you have, so it becomes a subjective analysis. But, what you're saying basically confirms my interpretation of the analysis.
Unfortunately, at the end of each test, I delete the VM session and restore a clean snapshot, so to post other screenshots, I should redo all the work...

@DardiM it would be interesting, when you have time, you analyze this malware by trying to comment other code, and compare our results

 

[DardiM]

When we statically analyze a malware, it is often difficult to be sure. In this case part of the code is encrypted/obfuscated and you have to work on what you have, so it becomes a subjective analysis. But, what you're saying basically confirms my interpretation of the analysis.
Unfortunately, at the end of each test, I delete the VM session and restore a clean snapshot, so to post other screenshots, I should redo all the work...

@DardiM it would be interesting, when you have time, you analyze this malware by trying to comment other code, and compare our results

I think you have shown the most important

 

[HexMh1]

EP check: packed
How to unpack?

 

[HexMh1]

EP check: packed

How to unpack?