What makes .Net malware different from your classical windows malware
When building a .Net executable, source code is not compiled to object code but to an intermediate language called “MSIL” (Microsoft Intermediate Language) which uses JIT (Just-In Time) compile at execution time but the “Common Language Runtime” virtual machine.
The virtual machine (execution environment) is a bit like the Java virtual machine except that the source code can be written in different high level languages like C#, VB.Net or even PowerShell.
As a result, as it is also the case for Java, .Net executables are much easier to reverse to source code than executable written in C++, for example. Such executable must be disassembled and analysed in tools like OllyDBG/Immunity or IDA, mostly at assembly level.
PE executables generated for .Net applications are also a bit different in their “aspect” than other PE executables. For example:
They usually need less imports;
.Net resources are not stored in the resources section of the PE file.
|Regular PE file|
|dotNet PE file|
A dotNet decomplier like ILSpy is nice for non obfuscated files but dnSpy offers much more features, including a debugger. This is a must-have when dealing with advanced malware samples that use encryption like the example below.
First stageAt first sight, the malware is clearly obfuscated
Let's just start debugging starting with the main() function.
We can see that the various encoded strings are being processed one by one:
The result of all these decoding can be retrieved by setting a breakpoint on a return. The returned value happens to be a PE file:
Second stageThe second stage is another layer of obfuscation and protection, including functions to detect some analysis tools like wireshark and sandboxie.
Stage 2 includes a modular configuration:
The various parameters are used in different places of the code. For example, if adequate parameters are set to ‘1’, stage 2 will search for running executables such as Wireshark, Sandboxie or Fiddler and end itself if found:
Some detection is done by looking for process names:
Sandboxie is detected by searching each process for the typical sandboxie DLL name:
Other protections are available (based again on the configuration parameters):
- Disable task manager
- Disable CMD
- Disable UAC
In this case, all those "protection parameters" were set to "0", so no protection is enabled.
The configuration file also holds the key that will be used to decrypt the third stage malware (another embedded resource) using the DeCrypt function:
|Encoded third stage|
|Decoded third stage|
Third stageThe third stage is a RAT with various capabilities likes keylogging and camera control.
It gets resident by setting run keys:
|CnC communication parsing|
|File location & name|
ConclusionInterestingly, a quite similar binary has been documented by malwarebyte (
https://blog.malwarebytes.com/threat-analysis/2016/07/unpacking-yet-another-net-crypter/) but the payload was different.
So maybe the first and second stage are some kind of packer or loader used to distribute various malware.