 All right, I am really excited to introduce Alexandre again. He spoke in my track last year and did a bang up job. Last year it was his first time speaking at any kind of big conference at all. Since then he's gone on quite the world tour. He went to China, he went to hack in the box. He spoke in Europe and now he's back here to speak again. Let's give Alexandre a big round of applause. Have a good time, my friend. Thank you so much. Yeah. Hello, guys. Good afternoon. Let's talk about .NET Mob Reversing. It's a pretty easy talk. I think so. I'm a secret research. Here is our agenda about my presentation. Here you have my last presentations on confidence to death from China. Hack in the box, I'm Mr. Dan. In death com last year, I recommend you take some time to read it. In the last line, you'll see my tool, my personal 3-H tool. Mobile tool. If you have some free time, you can test it. Let's start. There are lots of people here. Honestly, once again, I was expecting 10 or 12 people. Because most malware analysts don't like .NET malware. Basically, malware analysts, while analyzing .NET malware, are concerned to unpack a binary from memory or find the encryption routine in a .NET malware or even to the equipped resources embedded in this kind of malware. But according to my experience, .NET malware can be so challenging because sometimes advanced authors, advanced malware authors try to modify the .NET malware, the application directly in the intermediate language. And I've been checking and analyzing some mirrors in .NET, which try to attack the .NET runtime. So it's recommended to learn a bit more on intermediate language and some information about metadata in .NET runtime. Most of the time, we find .NET malware around the world. And we have basically a native code, sorry, .NET managed code, load a native code on the memory. This is the common scenario. But sometimes things can be worse. Sometimes things can be a bit more complicated. You see, this is a real case that I faced some month ago. The suspect received an email, click on the link, drop a first dropper, this dropper fed a first payload on the Internet. This payload is composed by two pieces. One piece is a native code. The other piece is an encrypted managed code. This first piece in native language, in native code, is injected into another process, in a remote process. Once this code is injected, this code load the first managed code, the equipped load, this managed code fed a second stage from the Internet. The second stage is the real payload and the infection starts. So things can be harder than usual case. And I try to show it in pictures here. I don't need to show it again how to make injections. Injection is so easy. I try to show it here in these slides. These slides are kind of refresh about injections. I won't explain it because it's pretty easy. But as I mentioned, things can be different. For example, I told you that usually I have a managed code loading a native code into the memory. But sometimes, sometimes things are the inverse. I have a native code loading a managed code into the memory. In this case, for example, I use the CLR create instance to get an interface named ICLR method host. From this interface, I use the get runtime to get another interface named ICLR runtime info. From this interface, I use a new method named get interface to load the runtime. Afterwards, I use the execute application to activate the domain. I start the runtime using the start method. And finally, I use the executing the full application domain to start the real application, the real infection, the real payloads. As you know, a .NET framework is composed by a runtime, CLR, and some libraries. More authors can write memories using different languages such as C-sharp, F-sharp, VB.NET, and so on. Basically, these sorts of codes are compiled into a common language infrastructure and finally run by the CLR. We have several excellent tools to analyze .NET networks. I try to list some of them here. I use them daily in my daily job. Personally, I also use some additional tools that I try to show you here in red. These are great tools to analyze .NET networks and reverse some of them. And of course, you must know that most .NET networks use some kind of packers or crypters. So I try to show you some of them here and pay attention that the last one, VM Protect 3.40 was released, I believe, one or two weeks ago and now it includes .NET obfuscation. When you are working with .NET malware, you must try to remember that most of them are using obfuscators and obfuscators can. Obfuscating the control flow, these obfuscator try to rename methods, attributes, classes, and so on. Some of them encode all of the strings, of course, try to encode and obfuscate the cross-reference. It's so complicated to analyze this kind of code while you're using any kind of obfuscators. So it's very important that you know about that. When I'm analyzing .NET malware, usually I see the same functions loaded, they payload. In this case, I try to show it in green here. Assembled.load, Assembled.load file, and method.info.invoke is almost, almost, almost the same thing. Most times we see a kind of reflection approach and when you see a reflection approach, you will see a sequence similar to that. I'm using load or load file, followed by get type, get method, and invoke the method. Reflections is so used during .NET malware, so it's a very common approach. Another approach, another possible approach, is using get assembly name plus get type, get method, invoke again. As most malware have been using resources, or these .NET malware try to hide some data or payload into resources. You see sequences like this running pink, find resources, size of resources, and so on. Sometimes you see other sequences like this one in orange when malicious .NET assembly is trying to load some external DLL. All of these approach are based on trying to load something in runtime to evade your static analysis. Here I'm showing you a first very basic malware. I open in dnspy. We have the entry point there in green. I click on the entry point. I find a class named the Parable Buffer Cache Event Source. Inside this class, I see the main function and at the bottom, I see our potential malicious function named target invocation exception. Following this function, I see that this very special function is trying to load an assembly. This function are using a URL to load this assembly, but in this case the web link comes from several attributes. For example, I took one, the first one, and I checked that this attribute is being set by garing a new assembly using get execute assembly here at bottom. This function is trying to read a resource. This resource is encrypted. When you decrypt the resource, you see P is executable. Each of these variables are related to a resource that represents a possible or potential malicious native code. Here I'm showing the same code, but using intermediate language as it's similar. You see the main function, the endpoint. You see at right, our function, our malicious function. We have a token. A token is that number zero six. This token works a kind of index inside a metadata table named member reference table there. And when I try to follow it, I find our function here at bottom and more details are expanded. As you see, implementation flags are IL, intermediate language, and manage because I'm handling a managed code. This is a manifest. A manifest in this case is a file that wrap up everything. In this case, you can see the assembly name. You can see several managed resources related to embedded resources at bottom. You can see further information about this malware. As I mentioned before, this point, this malware is using reflection to load malicious contents at runtime. So you can see here several calls to get execute assembly methods in several points in this intermediate language code. Sometimes you are facing bit harder .NET malware in this malware brings some encrypted resources so you can use the NSPy or other to drop these resources, decrypted, and using reflexes. Reflex is a kind of plugin. You can add the original code and load the resource, the equipped resource to analyze the malware. In this case, you must remove the old references because the old references are reference, the equipped resource. So in this case, you drop the resource, decrypted, delete the original .NET malware, load it again, and that's it. You can analyze your .NET malware using this technique. Of course, it's always recommended to know a bit more intermediate language and, of course, metadata. I think that about 90% of case .NET malware or .NET malware authors trying to insert some malicious code in our initializers or finalizers. In this case, for example, usually I try to check every class constructor to find our unpacker, or the quipter, or any kind of hooking code. It's very usual, for example, in the last few weeks, I've been seeing several .NET malware trying to compromise the jit. In this case, these special malware, these special advanced malware, trying to hook this function, sorry, compile methods to compromise the jit. In this case, when the jit generates the native code, these special malware can hide or encrypt user code in runtime. For example, in this case, I try to see the class constructor. There, usually, I find some hooking code. These hooking codes try to compromise the compile methods, and by using this trick, the malware can hide or encrypt the user code. It's a very clever technique. There are other .NET details here. Most .NET malwares bring some very important metadata. So, metadata basically are information about classes, attributes, members. Usually, you will get very valuable information from metadata. A .NET application, as you see, is composed by a managed executable and a managed code. It's not so hard to analyze this kind of code, but you need to have some guidelines to do that. For example, a managed code is composed by a IP header, of course, CLR header, metadata, and intermediate language. In this case, I have the compiler here. I have the managed models. I have the resource files that are compiled to a final version composed by a manifest, a managed models, and a resource file. In using pictures, you see that a .NET header is composed by P header, CLR header, CLR data, and native code. And at the right side, you can see the same picture put in a detailed view. Metadata is very important because there I can find very valuable things and information. Metadata in this case is composed by definition tables, reference tables, and manifest table. There are several tables inside of these classes. And you should remember that all the .NET malware infection tried to use one of these tricks, or code manipulation inside the class constructor, or FAP analyzer, tried to load some, a method in function, a function, or use a component. So the tricks are the same, always the same. Here is a second case, a bit more complicated case. This is a real .NET malware. I'm showing here the intermediate language and the metadata information. As you see, you see the name, type the reference table. You see the method name in this case men and the flags. In this case, I'm using the iodesk to show this screen. As you see, the real managed code is so small, less than 5%. Metadata is so important because, as I told you, describe some information about members, attributes, properties, classes, and so on. This metadata is organized by using a kind of relational database. And it's so interesting because you see, I have a table. One, two, three, four, five slots. Each slot is dedicated to a class. Each slot tells me which methods belong to this class. At right. These metadata are organized in name streams and classified in metadata heaps and metadata tables. Metadata heaps is so easy because there are only concern is about strings. So a string heap is more important for us. And inside these six name streams, we have hash US is related to user strings and hash dash is a kind of uncompressed metadata stream. I believe that these two ones are the most important. When I talk about metadata table, we have several tables which is almost impossible to remember every table. You see, I list all the tables here. And since here works using a token. A token is a kind of structure composed by four bytes. The first byte determines the table. The remaining three bytes tell us the role inside this table. Here I show some statistic information about metadata. And at bottom, I show some user strings that I commented about the name of strings. Intermediate language in .NET is a kind of ASME language based on stack. So you see instructions. Load something onto stack or pop something from stack. You see a very usual application or two named NGIN. NGIN is executable to compile intermediate language code into a native code. It's so easy to do that. But the last three years I've seen several hours trying to attack the .NET framework. In this case these kind of infections are a bit more complicated. We have several kinds of .NET measures. But assemblies are classified in private assemblies and shared assemblies of course. You should remember that most malware samples try to hide some malicious content and resources. Hide by encrypting or obfuscate something. Some .NET malware tries to download an external assembly from somewhere. And other .NET malware are based on multi-file assemblies. In this case it's a bit more complicated because these authors try to compose the .NET assembly and split over multiple files to evade the defenses. It's so easy to generate a multi-file .NET malware. For example I show you here how easy it is. I compile for example a hooking.cs model. I compile an injection.cs and using a main program named defcon.cs I generate a library named malwarelib here. It's so easy to do that. Of course this operation does several metadata tables but it's normal. We have a real manifest about our second malware. You see some .NET models being loaded at bottom. Some external reference to assemblies. In this case our assembly is a strong assembly because it is signed by a private key from somewhere. The second screen here you see the driver the assembly name. You see several custom attributes. You see that the signature is using SAG SAJ1 you see several managed resources being used and at bottom you see that the real name of this malware is Mikrotik realtechdriver.se I show you here how to compile a final executable in C-sharp. It's pretty easy. You have a key pair you can sign this assembly by using this procedure here at bottom. After signing this .NET assembly you can see the public key there in red. During some infections I've seen native codes trying to copy a .NET assembly to GAC. GAC means global assembly cache. In this case the author was trying to execute the native code copy the managed code to GAC because other pieces of this malware would use the shared assembly in the GAC to continue the infection. It's a kind of second stage. It's pretty easy to copy to that because you can use GAC filter there in orange or you can use the MICU package to do that. Of course to copy anything to GAC you need to have a key pair to sign your .NET assembly. If you don't have one you can use the only the public key and try to delay signing. In this case you will sign the .NET assembly only use the public key. To do that you can follow this procedure. You can add some resources by using slash resource. You can add some references by using slash reference. It's pretty easy. Of course I don't have enough time here to show you how to explain every single instruction in intermediate language. So I left some slides here showing it important instruction in intermediate language. I don't have enough time to do that unfortunately. And here I show you a real, real malware is the same malware so I try to comment several lines. Of course you must know about C-sharp to understand this code. Here we don't have anything different from a C-sharp code but the names and the keywords are a bit different. You have a public class, you have a private class you have a facility class you have a constructor here C-sharp, you have some private fields we have some stack reservation there, max stack you have several operations load things to stack and pop things from stack you have a custom a custom instance here at bottom you have private class you have a invocation of a native code in the middle here you see a invoke implementation here trying to call a method code you have here at bottom a local variable being initialized with zeros we have a try cat structure so it's so similar to a C-sharp code I try to comment several lines here to help you later you have for example here our dotnet malware are interested in get our keystrokes you see in this case malware is trying to hook some keyboard operations as you see the dotnet malware is trying to hook the key-down event and key-up event so it's a kind of keylogger at bottom here we have some event declaration in this case our dotnet malware is trying to subscribe some functions on this event at bottom key-down at up key-up and finally our dotnet malware not malware using aggregate to invoke this event so easy to do that several constructions being called here finally I found the decryption function this function is responsible for decrypting several strings from this malware as you see I try to comment line by line or the most line here you can try to monitor all DLLs load from the GAC by using FuzzLock or even process monitor but as I told you some advanced malware try to compromise the dotnet framework try to insert some hookings even try to compromise the GIT so it's this kind of malware are more dangerous here at bottom I show you the complete procedure for example I can copy a DLL from GAC modify recompile to the native code and copy back again to the GAC it's so easy pretty easy to do that of course nothing is so simple to do that I need to I need to have sign assembly as I don't have the private key from the Microsoft it's so complicated to do that other approach it would be to re-sign all the dotnet framework it's so hard to do that I can try to copy the modified DLL to GAC but if some applications or services are using this DLL it's not possible I can try to force a reboot to make this copy and even that I get it to do that I need to force my current applications using this modified DLL so in this case I need to uninstall and remove the native code from the native directory case meet show a very interesting way to do that case meet show a very nice trick by copying by dropping assembly to GAC dot DLL to force applications using my modified DLL I can try to for example I have a register composed by two entries one entry is pointed to the assembly code the other entry is pointed to the native code in this case I try to change the second entry to point to my modified DLL is another approach here some dot net malware try to compromise services try to introduce some hooking in GIT some dot net DLL try to load external assemblies so there are several tricks of course I've been using winder back to analyze this kind of dot nut malware using an extension like slsx and here I show you a complete approach for example here I load the extension sls sls dot DLL I found the native entry point disassembly the entry point I found the PE entry point there by using dump bin I try to display the pointer and finally I find the core easy man function by disassembly I can dump the domain in this case I see the system domain I see the share domain I see our domain from our malware I see several calls to external assemblies visual base sitting the DLLs I list some manage reception I can try to switch the track for example in this case I switch to track zero I dump the domain stack trace here our dot net malware at bottom I list some manage tracks by using the tracks here as you see you can see that tracks tracks 0, 2, 5, 10 and fourth thing are manage tracks all of them are managed by garbage collector I list the native the native stack at bottom using key n I pick up an entry there I check that if this address belongs to the GT code yes in this case belongs I pick up the method description reference I disassemble it so we have the disassembly function here I check the manage stack again I pick up object address I check again if this address belongs to the GT yes again I dump the method description information here I pick up the class reference at top I dump the class structure information I found the I found that this specific class has six methods 28 instance fields and five static fields I can check one of these fields for example in this case a value type field by using dump VC I found a hash table class composed by several several fields here at right I dump the method table information I dump the method table information again but detail the output as you see several methods some of them compiled I dump information about a specific model I found the assembly reference I dump the assembly information I found the parent domain information I dump the domain information at bottom it's pretty easy to do that of course here here is a bit more complicated finally I found the method table structure and the structure here I found some interesting classes possible malicious classes possible malicious classes I take one testprint.client I dump some information from these classes as you see there are several methods there I pick up one I dump the class and it's very interesting because there I found some fields in English Portuguese and German language I I took the German one to check the information as you see this part wasn't executed by Jit because at bottom is Jit the null so I tried to put a breakpoint to a future execution I dump it again all of the stack objects I saw a function using an array I dump this array this array is composed by an element that in this case is a structure as you see at bottom I dump it okay that's the same slide I check the heap information I check any kind of references to these objects by using GC root references from references from the stack from the handle tables I check the finalize heap to find something interesting I check the find and handled because some mirrors cause strong heap fragmentation I check again again some problems with locks and deadlocks locks and deadlocks I try to find a string inside the heap the managed heap at bottom I dump the mirror from memory and finally finally I check the thread environment block I dump some strings from there I found some nice strings at bottom I dump all of the heap I found some classes I took one keyboard hook and so nice I dump methods from these classes there are several methods I took the last one try to disassemble in intermediate language try to dump all strings from the memory related to this method and it's nice I found several urls related to banks so this is a kind of Trojan banker I I'm leaving some break points for you here these are very nice break points to test together some additional information and I test the url in virus total by using overview I can see that is a malicious site and I test the domain and I found several related things several malicious things associated to this domain it was a very long presentation I know about that if you want I can expand details for you thank you so much to the DEF CON staff as usual for you who reserved some time have a nice day thank you