Malware Analysis Backdoor.MSIL.Bladabindi-Static Analysis

tim one

Level 21
Thread author
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
SHA256: c97f92b64d4d6bc80ec5e6081897ddf8af138dc39d558d604c6040dd154f8c06
File name: c97f92b64d4d6bc80ec5e6081897ddf8af138dc39d558d604c6040dd154f8c06.exe
Detection ratio: 54 / 56
Analysis date: 2016-11-14 16:28:23 UTC


PORTABLE EXECUTABLE INSPECTION


The malware is a .NET sample, it has an high detection ratio on VT, and it seems to be a Backdoor.MSIL.Bladabindi; but let's see how it behaves on an infected system.
After a deep analysis with PEiD 0.95 we can assume that it has 3 sections: .text, .rsrc, .reloc. The most important file section of the malware is .text because it contains all the instructions executed by the CPU during its execution.
.rsrc instead consists of resources of the sample analyzed and .reloc are the relocation sections.

Cattura.PNG

Cattura1.PNG


You can see the number of file sections and other useful informations about the PE with the following screenshot:

Cattura3.PNG

And in addition you can see the malware is not packed (obfuscated) infact you will see the clear source code analyzed with ILSpy.

Cattura4.PNG


I used PEiD also to perform a dissection of the sample and view its main instructions: for example the OUTSB instruction: which is normally locked and obviously normal users can't call it.
It uses also Jump Zero operation to call another function if a condition is verified.
Infact, after JZ instruction it uses a CMP instruction to compare EAX with 73657922H (Assembly registry cells).

Cattura2.PNG

Then I also retrieved all the strings of the malware, you can see the most interesting and malicious strings with the following screenshots.
In the first screenshot there are strings which are related to connection process of the Backdoor (from the client to the server), by using a TCP protocol, then there are also other malicious strings which are referred to get_Location and bytes operations.

Cattura5.PNG


Furthermore, the sample performs operations and it retrieves info from registry, the current user (with the function get_CurrentUser, get_Registry and Microsoft.Win32).

Cattura6.PNG


I found other interesting strings which you can see here;

Cattura7.PNG


the sample gets info of Machine Name, UserName, info of File System, LastWriteTime, ComputerInfo, and info of OS version, etc.
So we can say the malware gathers a lot of information on our PC and it sends them to a remote server (with specific functions which use TCP connections to the server from the client; later we will see connection on the source code analysis done in ILSpy).
I would state the Backdoor is particularly dangerous because it has the permission to check registry keys (understandable from the string "RegistryKeyPermissionCheck" as you can see in the following screenshot):

Cattura8.PNG


It has the permission also to get access to personal and special folders, maybe to steal personal and sensitive data from the user.
It uses System.Net to call functions related to connection between client and server on TCP protocol.
As you can assume there are "WebClient" to manage this type of web connection surely to send stolen sensitive files.

Cattura9.PNG


In this other screenshot there are other strings which I assumed malicious, because related to security and in particular to cryptography, infact the sample imports .NET libraries like "System.Security.Cryptography", "MD5CryptoServiceProvider", and other suspected functions related to hashing: "HashAlgorithm", "ComputeHash" and it retrieves also the current process, by calling "GetCurrentProcess()" function.
Other interesting strings which I mention here are: "Socket" (it opens a socket when it establish the connection with the remote web server), "getClient", "SocketFlags", which is useful to check Socket state, and finally the keyword of the connection process: "Send".

Cattura10.PNG

Cattura11.PNG


Now we can also examine other strings like "set_SendBufferSize", to specify the maximum size of the buffer for the connection, "set_SendTimeout", "set_ReceiveTimeout", and obviously "Connect" to perform the connection with the server.

Finally the malware calls also functions to get control of the keyboard, maybe to hook keystrokes and button pressed to perform password stealing.
We can see: "Keyboard", "get_Keyboard", "get_ShiftKeyDown", "GetKeyboardState", "GetKeyboardLayout" and others.
But it's interesting the fact that it calls also another executable, maybe a dropped file called "j.exe", and it uses .dll files like "user32.dll" and "avicap32.dll".

Cattura12.PNG

Cattura13.PNG


THE MALWARE CODE

I perfomed the analysis of the source code by using ILSpy.
Initially we can understand that the sample is not encrypted or obfuscated, infact all the source code is avalaible after reversing.
As you can see we can the same functions of keylogging and get AsyncKeyState(int) function.
We can assume that the BackDoor.Bladabindi uses variables which are clearly widely used for the connection function to the web server. For example we have TcpClient variable, Computer (to get info of OS version, architecture, etc.), FileInfo.
Other interesting functions called, which you can see at the top of this screenshot are: GetWindowThreadProcessId, MapVirtualKey.

Cattura15.PNG Cattura16.PNG

Well, in the screenshot below we can see the main functions used by the sample, and also the most dangerous. The malware perform the connection to send stolen data with "connect()" function, then Cam() and capGetDriverDescriptionA, which are probably methods called to gather info and control of driver of the webcam connected to the infected system. Again it uses MD5 (byte[],string) function, it gets as parametres an array of bytes and a string to perform a MD5 checksum. Send and Sendb obviously are methods used to send retrieved files and data by the BackDoor, the Send function gets as parameter a string variable, probably because this string consists of the path of files to send to the web server; so really interesting to analyze and also really easy because the source code is completely open and not encrypted.

Cattura17.PNG

But... Now let's see the source code in more details!

In the screenshots you will see, you will assume that the sample uses some functions and .NET methods to perform keylogging features; and it seems that the malware recognise, via case "else if" structure what key the user have pressed.
You can see in the screenshot the state: "this.Logs += text;", so in practice it logs the keys pressed, recognised with the function I mentioned before.

Cattura24.PNG

You can also assume the sample defines a variable of type TcpClient, initialized to null value, which it will be used for the connection to the server.

Cattura26.PNG
Cattura27.PNG


Another variable (static) of type string is used to recall and execute the dropped .exe file (much suspected): "fares1.exe".
The variable "public static string H = "fares818.ddns.net";" is simply the URL used by the BackDoor to send the stolen files.

Cattura28.PNG


"public static string sf" is a path of the registry key in CurrentVersion\\Run directory to obtain the possibility to set the autorun when booted the OS without user approvation.

Cattura29.PNG


Now we have a function that get description of Camera Driver, probably it uses this type of info to manage the Camera device on the infected machine.

Cattura30.PNG
Cattura31.PNG

Connect function code:

Cattura32.PNG Cattura33.PNG Cattura34.PNG

Then we have a function used to get info of System Drive,

Cattura35.PNG

and the send process of WebClient and also "DownloadData" method (really suspected) maybe to gather data from server to update itself.

Cattura36.PNG


A really interesting sentence is: "OK.Send("MSG",OK.Y, "Executed As" + new FileInfo(text3).getName());" probably to send information to the server of executed files.

Cattura37.PNG

The sample in addition gets registry control and CurrentUser value, by changing it with SetValue("di","!");

Cattura38.PNG

Now, we have a last important thing to say: there is a sentence like "netsh firewall delete allowed program", so probably it also can change and set firewall rules to guarantee its access to the network, for allow exchanging of files and info with the remote server.

Cattura39.PNG

Thank you guys.
 
Last edited:
W

Wave

Thank you for reading,it took a long time to be completed, because I worked on it in my free time. :D
You will always be a Trusted Member in my mind (and a very good friend - one day we will be in Italy, on a beach with hot girls, with the loud grass and music speakers, haha), and you're work is very useful and great. I'm not just saying this, sometimes I give out a sense that my ego is really big and that I can never be educated as I "already know it all", but this isn't true, and I've definitely learnt things from your posts.

Really keep up the great work and your motivation is great (and motivates me also)! :) I am currently working on a thread to share, I will share in our PM soon before I post :)
 

askmark

Level 12
Verified
Top Poster
Well-known
Aug 31, 2016
578
Thanks for the awesomely detailed, but also clearly explained malware analysis.
I didn't even realise tools like IlSpy even existed. It's amazing you can decompile a .NET program so easily. Presumably commercial apps protect themselves from being reverse engineered in this way?

Looking forward to your next analysis!
 
W

Wave

Thanks for the awesomely detailed, but also clearly explained malware analysis.
I didn't even realise tools like IlSpy even existed. It's amazing you can decompile a .NET program so easily. Presumably commercial apps protect themselves from being reverse engineered in this way?

Looking forward to your next analysis!
Programs built with the .NET framework don't compile like native applications (e.g. ASM/C/C++ applications), they work in a similar way to how Java works. With .NET programs there is the CLR (Common Language Runtime) and this is essentially a Virtual Machine for the .NET application, which will be running on byte-code (MSIL - Microsoft Intermediate Language), and the CLR translates these byte-code instructions so they can be understood by the processor, which is why .NET applications run with a JIT (Just In Time) compiler. This means that in theory, any .NET software can be shifted across to any other OS which has the CLR ported over to it - of course the program itself will not work, but it'll still be able to run due to the CLR being ported over to that specific OS). Very similar, in Java, you have the Virtual Machine which will translate for the processor to understand and execute the instructions from the running program.

Since .NET apps are based on the Microsoft Intermediate Language and are not compiled the same way as native applications are, unless packing/obfuscation techniques have been applied to the program executable (*.exe), you can use tools like ILSPY (free and open source) or .NET Reflector to convert the MSIL from the assembly (the PE) back to readable human-understandable code into languages like C#.NET, VB.NET. Due to this, you can take a program built in C#.NET and read it in VB.NET code (and vice-versa, but more of pseudo-core than the original source code), and vice versa. Of course the code given back is not the exact same as the original source code, but it's enough to understand how the program works.

When packing/obfuscation techniques have been applied, it's still not the hardest thing in the world to resolve, since it'll always lead back the trace to the MSIL which can be translated back to readable human-understandable pseudo-code in source format. Therefore, in the case of obfuscation (e.g. where variable names have been obfuscated, class names have been altered, and maybe even the code has been "optimised" to confuse the analyst), you can try to work with de-obfuscation tools such as De4Dot (which is not always supported depending on the obfuscator used/techniques applied). In terms of packing, the sample has to be decrypted somewhere for it to execute, therefore usually debugging the program until it's been decrypted in memory and then dumping to disk (and analysing that newly dumped file for analysis) will work - packers are known for using functions like GetProcAddress (from kernel32.dll) and LoadLibraryA/W (also from kernel32.dll) to link to the functions, so if you analyse a program of a large file size but notice the imports taken from the IAT are very low, but that the sample imports those 2 samples, then it's a sign of packing (you can also check the PE File Header for more signs/calculate the entropy level).

Sometimes depending on numerous factors, you can even get a grasp on how a particular program works just based on its imported and exported functions (and in the terms of the exports, the exported function names may give you an idea on what the program will be doing - however these can also be obfuscated, directly from the source code itself, and this is a method that Microsoft use themselves in some cases to make things more confusing).

For example, if I analyse a device driver from an AV product, the chances are I will find ObRegisterCallbacks, CmRegisterCallbackEx and FltRegisterFilter in the imports (if that specific driver was responsible for self-protection mechanisms). This tells me 3 things: the AV product is using documented and stable methods for self-protection mechanisms, as opposed to more unstable and rootkit practises such as SSDT hooking (only done on x86 systems by some products due to PatchGuard/KPP (Kernel Patch Protection) on x64 systems).

IDA Pro is an amazing and very sophisticated piece of software for reverse engineering overall, native applications for example. And I would recommend it for anyone who is interested in performing malware analysis, or who is trying to reverse any other program (even an AV product if you were determined and had the patience).
 

Dirk41

Level 17
Verified
Top Poster
Well-known
Mar 17, 2016
797
Thank you @Wave and @tim one ! I enjoyed your explanation because ( I hope the other don't misunderstand me , it's my fault since I study other things , but I like reading about security malwares and so on ) when people writes analysis like fisjicldflxjehkcjspshbdodbsisbdkxmsjdidb XD I understand almost nothing .
But you explained in a way that even I inderstand
 
Last edited:
W

Wave

But you explained in a way that even I inderstand
I thought really carefully about how I would word out the explanation so it could be understood by not just people with existent experience in malware analysis, but also people who are just generally interested or getting started in it. It's great to know that someone found it helpful, it just pushes me to do more explanations like the above in the future. Thanks friend :)
 

askmark

Level 12
Verified
Top Poster
Well-known
Aug 31, 2016
578
Programs built with the .NET framework don't compile like native applications (e.g. ASM/C/C++ applications), they work in a similar way to how Java works. With .NET programs there is the CLR (Common Language Runtime) and this is essentially a Virtual Machine for the .NET application, which will be running on byte-code (MSIL - Microsoft Intermediate Language), and the CLR translates these byte-code instructions so they can be understood by the processor, which is why .NET applications run with a JIT (Just In Time) compiler. This means that in theory, any .NET software can be shifted across to any other OS which has the CLR ported over to it - of course the program itself will not work, but it'll still be able to run due to the CLR being ported over to that specific OS). Very similar, in Java, you have the Virtual Machine which will translate for the processor to understand and execute the instructions from the running program.

Since .NET apps are based on the Microsoft Intermediate Language and are not compiled the same way as native applications are, unless packing/obfuscation techniques have been applied to the program executable (*.exe), you can use tools like ILSPY (free and open source) or .NET Reflector to convert the MSIL from the assembly (the PE) back to readable human-understandable code into languages like C#.NET, VB.NET. Due to this, you can take a program built in C#.NET and read it in VB.NET code (and vice-versa, but more of pseudo-core than the original source code), and vice versa. Of course the code given back is not the exact same as the original source code, but it's enough to understand how the program works.

When packing/obfuscation techniques have been applied, it's still not the hardest thing in the world to resolve, since it'll always lead back the trace to the MSIL which can be translated back to readable human-understandable pseudo-code in source format. Therefore, in the case of obfuscation (e.g. where variable names have been obfuscated, class names have been altered, and maybe even the code has been "optimised" to confuse the analyst), you can try to work with de-obfuscation tools such as De4Dot (which is not always supported depending on the obfuscator used/techniques applied). In terms of packing, the sample has to be decrypted somewhere for it to execute, therefore usually debugging the program until it's been decrypted in memory and then dumping to disk (and analysing that newly dumped file for analysis) will work - packers are known for using functions like GetProcAddress (from kernel32.dll) and LoadLibraryA/W (also from kernel32.dll) to link to the functions, so if you analyse a program of a large file size but notice the imports taken from the IAT are very low, but that the sample imports those 2 samples, then it's a sign of packing (you can also check the PE File Header for more signs/calculate the entropy level).

Sometimes depending on numerous factors, you can even get a grasp on how a particular program works just based on its imported and exported functions (and in the terms of the exports, the exported function names may give you an idea on what the program will be doing - however these can also be obfuscated, directly from the source code itself, and this is a method that Microsoft use themselves in some cases to make things more confusing).

For example, if I analyse a device driver from an AV product, the chances are I will find ObRegisterCallbacks, CmRegisterCallbackEx and FltRegisterFilter in the imports (if that specific driver was responsible for self-protection mechanisms). This tells me 3 things: the AV product is using documented and stable methods for self-protection mechanisms, as opposed to more unstable and rootkit practises such as SSDT hooking (only done on x86 systems by some products due to PatchGuard/KPP (Kernel Patch Protection) on x64 systems).

IDA Pro is an amazing and very sophisticated piece of software for reverse engineering overall, native applications for example. And I would recommend it for anyone who is interested in performing malware analysis, or who is trying to reverse any other program (even an AV product if you were determined and had the patience).
Thanks @Wave for the incredibly detailed but also easily understood explanation. I always learn so much from your posts :)
 

DardiM

Level 26
Verified
Honorary Member
Top Poster
Malware Hunter
Well-known
May 14, 2016
1,597
Thank you @Wave and @tim one ! I enjoyed your explanation because ( I hope the other don't misunderstand me , it's my fault since I study other things , but I like reading about security malwares and so on ) when people writes analysis like fisjicldflxjehkcjspshbdodbsisbdkxmsjdidb XD I understand almost nothing .
But you explained in a way that even I inderstand
One day, I will make an analysis of one obfuscated sample, only for you :) (even if I will post it for all members)
 

tim one

Level 21
Thread author
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
You will always be a Trusted Member in my mind (and a very good friend - one day we will be in Italy, on a beach with hot girls, with the loud grass and music speakers, haha), and you're work is very useful and great. I'm not just saying this, sometimes I give out a sense that my ego is really big and that I can never be educated as I "already know it all", but this isn't true, and I've definitely learnt things from your posts.

Really keep up the great work and your motivation is great (and motivates me also)! :) I am currently working on a thread to share, I will share in our PM soon before I post :)
Thanks my friend, the same feelings here! I always say that we are a team, and when we work on this stuff, the substance is the same, so we are a great Team! :)
 

tim one

Level 21
Thread author
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
Thanks for the awesomely detailed, but also clearly explained malware analysis.
I didn't even realise tools like IlSpy even existed. It's amazing you can decompile a .NET program so easily. Presumably commercial apps protect themselves from being reverse engineered in this way?

Looking forward to your next analysis!
Yes some .NET applications use to obfuscate the code to make it not readable, for example by mixing functions and thanks @Wave for your awesome input! ;)
In this case, the code is in clear, so a good educational example :D
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top