 Good morning. You know, one of the great things that I like about the DEF CON, well, besides of the great talks and everything, well, I believe it's the first conference that starts at 10 a.m., right? Yeah, it's great. Well, you know what? I'm having some difficulties sleeping last couple of days due to some jet lag problems. Well, basically, my clock has been shifted about 10 hours. Last night, I woke up at about 3 a.m., well, I thought to myself, it must be a beautiful day. So basically, what are we going to talk about today? We're not going to talk about my jet lag problems. We're going to talk about manage code rootkits. My name is Erzmetullah. I'm a secure software engineer working at to be secure, working as the application security department manager. And what we're going to see today, we're going to see injections into the manage code environment. And basically, we're going to start with a simple example of very trivial questions which goes like this. Well, this is the software engineering 101 class which talks about hello world in Java. Well, basically, what does the following coach do? Supposed to print the string hello world, right? So let's run this code and let's see what happens. So basically, I'm having this class, the hello world, that Java class. So when I'm going to run this class, well, give me this strange behavior. Well, basically, the string that was supposed to be printed, the hello world was printed twice. And the reason for that to happen is that because the internal implementation of the manage code was modified. So the code, basically, what the code is, what the application level code says, not necessarily what it's going to do. And this is a little bit of a problem when we are doing code reviews. Well, when we are doing code reviews, the malicious code might not be at the application level. But this was just a simple example of language modification. We're going to use this example of language modification and take this further and further and that we'll be able to inject root kits into application virtual machine runtimes. And what we're going to talk about today, we're going to start with the manage code environment execution model. We'll start with an overview about that. We're going to talk about manage code root kits and how to implement manage code root kits. What's so special about that? We'll see a couple of demos and a couple of attack scenarios so that we can understand that manage code root kits can be very dangerous and they have their own advantages due to some very interesting techniques. And I'm going to expose to you a tool that I wrote called dotnet-sploit. Well, a dotnet-sploit is a custom language modification tool. It enables you to change and to customize your own version of the dotnet language. Well, it is a general purpose tool. I use it to show the attacks that I have demos for. But basically, you can use it for any purpose you like. You can even take it and it's an open source and customize it to other languages. So, a little bit of background. It all started with the idea of changing the language back in 2008, I played a little bit with the dotnet language modification. Well, soon I realized that it might lead to some very interesting attack. I wrote a paper about it called dotnet-sploit-root-kits-backdose-insidio-framework. I presented it in black at Europe and in Cancer Quest. But dotnet-root-kits was just a case study. So, and people actually thought that there is a problem with the dotnet framework and that the concept that I was talking about was dotnet-specific whether it wasn't. And it was really, really important to me to show you guys the general purpose case so that I'm also going to talk about Java-root-kits today. So I'm taking another language as an example to show you the general case study. So what is the managed code? Well, managed code is code that runs and executes under the management of a virtual machine, an application-level virtual machine. For example, the JVM, the Java JVM, or the dotnet-CLR. Well, think about it as an operating system for applications. So basically this is another language we're talking about, we're not talking about assembly language, but we are talking about a virtual language. We're talking about a high-level, object-oriented intermediate language. Basically it looks like assembly, but it has the characteristics of an object-oriented language. We can create objects and we have classes and inheritance and stuff like that. Well, basically it looks something like this. This is how a Java byte code looks like after disassembling. So as you might see, it looks kind of like an assembly code, but it's not. If I will execute this code, if I give the CPU this kind of code, it will not understand what I'm talking about. The CPU does not understand virtual languages. But basically the magic that has been performed using the virtual machine that translates the high-level intermediate language to the machine-specific assembly code. So that if I'm having an executable, and sorry guys about my graphics, I suck in graphics, but what I wanted to show you here is that the same executable can be run on the different platforms. So we have a Windows machine and a Linux machine and a Mac and mainframe and et cetera, et cetera. But for each machine there is a specific virtual machine. So we have that for Windows, the virtual machine is in blue and for the Linux box is in green and basically what's happened here is that the executable is executed inside the virtual machine that translates the just in time code and gives that to the CPU. So basically the virtual machine acts as a bridge to the CPU. Well, a couple of examples of managed code runtimes. So we're talking about Java, JVM, dotnet framework, the PHP Z Engine, the Flash ActionScript Virtual Machine, the AVM, Python, Dalvik, basically there are lots of languages which are virtual machine based. And today we're going to discuss dotnet and Java as a case studies, basically because there are very common languages. Many projects are written today using dotnet and Java and because their model is very similar and very easy to understand. So a little bit of overview of Java execution model, well, basically we have three layers as opposed to, for example, a code which The quality of the following recording is not up to our usual standards. However, we are releasing this due to the importance of the material presented. It's unmanaged, for example, CRC++ code in which you have the executable which contains compiled code, compiled assembly code and you have the OS. Basically now we're talking about three layers, not two. We have the application, we have the runtime, in our example is the JVM and we have the OS. So when the application source code is compiled and we have a byte code, the class, it is hosted inside the JVM. The JVM loads the class libraries from JAWS based on the name. And well, it generates using a just-in-time compiler a code which is machine specific and this is what the OS, the CPU looks and sees and executes. But the dotnet model is pretty much the same, so on that, now we have assemblies, this is dotnet mutation for compiled code. We're talking about PXC and DLF. And now that the code is being loaded, the libraries has been loaded from the GAC, the global assembly cache. This is where all the low-level methods have been stored. Well, think about it as system calls. Basically, this is where the code is located, this is where functions have been connected. And again, the jitter is generating machine-specific code and this is what the machine looks like. So, what are managed code rootkits, so MCRs? Well, managed code rootkits, this is a user-mode application-level rootkits hidden inside the managed code environment, libraries. Well, I know that most of you guys think about, well, here's a level mode, this is not a kernel-level mode, the kernel-level mode is awesome, well, it can be a level mode with all those many things. Well, there is a couple of great things that you can do in user-mode. In user-mode, well, although you are sacrificing a little bit of hiding, you can do very sophisticated attacks and you can do very sophisticated logical attacks so that the target of the MCRs is the virtual machine that provides the services to the upper-level application. So basically, we are hiding information from the application, not in traditional rootkits but when we are hiding from the OAS or maybe from the CPU or stuff like that, we are hiding it from applications. So the influence that we have is on all of the applications that run on a specific virtual machine and basically what we can do, we can do stuff like regular rootkits, so for example, we can hide files and hide processes and registry keys and stuff like that. It also does very interesting logical advantages of MCRs. The first thing is that it is an overlooked place. No one looks at virtual machines from malicious code. No antivirus, IPSs, IDSs, stuff like that. They understand intermediate language. They don't know if you're writing your malicious code. They do not understand it. Well, basically they can also cannot tell whether your application is doing something wrong. From its point of view, the application can do whatever it wants. So basically they cannot detect those kind of malicious behavior. Well, forensics. Forensics checklist does not cover virtual machines, right? So basically, if forensic guys over here, today you have another place, another place to look for, so that it's not just the operating system binaries that you look for, also for other places. And basically another interesting thing is about developers and developers' spectrums. Now we're talking about malicious developers that they know that their code will be audited and they know that some security guy will go over their own code, maybe looking for backdoors. They will not hide it inside the application level. They will hide it downstairs in a virtual machine. We're also talking about universal word kits. Due to the fact that the virtual machine performed the translation for us, we can write code which is not machine-specific, right? The same code, the same issues code will be translated to the machine-specific instruction set using the virtual machine. This is what I call universal word kits. And we have a large attack surface due to the fact that virtual machines are pre-installed on operating system from fjava and .NET are pre-installed in latest code versions. We can deploy all of, we can, sorry, we can control all of the applications from only one place. Think about a scenario of, for example, the hosting web server in which you are controlling all of the applications' behavior using only one injection. Well, another interesting thing is that the MCRs are becoming part, sorry, the managed code becomes part of the operating system. Microsoft is pushing very hard. So that the .NET will perform more and more things. Let's take an example of .NET PowerShell Commandlets. The last thing is that we can perform some very sophisticated attacks as we're going to today. So when we are talking about language modification and the word kit implementation, basically what we see here is the three layers. We see here the application level, the runtime level, and the OS level. So basically when an application calls some specific runtime method, basically the runtime method, this is the implementation of the runtime method. It is being called and executed. In MCR, we're taking away this method, throwing away, and writing our own implementation. So now when the application calls runtime method, well basically it does something different, right? So when a call comes to this method, well it goes, generates the code, and the system will be hacked. Now one can see that you cannot detect it from the application. If we're talking about an example, and in the beginning we saw the demo of Java, right-line twice towards print line. This is a Java version of printing a string. We can do the same thing in .NET. So basically this is the same code that was able to perform the same string twice. So I'm just giving it here as a reference, but basically this is the original code what I did in order to make everything to print of every string twice. I just doubled the code and the modified code looks like this. So basically I took the same thing and doubled the code. I had to rearrange a little bit the addresses, right? Because basically I had to calculate, and this is a very intensive task. Now I just had to calculate the three lines of code. When we're talking about injections of various sophisticated attacks, a very large amount of code, you have to do a very large amount of calculations. A little bit about the attack scenarios. Well, messing with the sandbox, messing with the application virtual machine usually requires administrator level privileges. And then basically we're talking about two main scenarios. One scenario, this is the scenario of housekeeping attack vector. Now we're talking about post-exploitation attacks in which the attacker has already managed to gain control of the system. Using some other kind of vulnerability, now he has control of the system and now he's thinking, what should I do next? So he can utilize MCRs to his proposal, right? This is another alternative attack vector, so you can use it. But in the second scenario, we're talking about the trusted insider. This is one of the major problems that we're facing today in security, in which those of the people that already have access to the system. Now we're talking about IT managers. We're talking about developers, DPAs. Those guys already have administrator level access. They don't have to steal this access, right? So they can take advantage of it and probably install an MCR. Think about a developer, for example, that is developing a very sensitive finance application. And he knows, for example, that he'll be reviewed and he wants to enter some kind of code that says, hey, if you see my own bank account, well, give me a little bit of links. And those kind of backdobs are very common when we're talking about malicious developers. Implementation techniques can be divided basically to two parts. Well, we have the non-invasive techniques. Those are the ones that are called by design techniques. By design techniques are techniques in which you are not hacking anything, you're just utilizing something which was there by design so that virtual machine lets you change its meaning using its own controls and on a mechanism. For example, AOP, AOP or aspect-oriented programming using dynamic weaving lets you inject code into applications, and configuration modifications. For example, setting an alternative people, class loader, or for example, loading a malicious malicious agent in Java. This is how you do that. And maybe messing with the machine with your own finger in dotnet. You can do that in AOP's techniques, but this is not something which is invasive if the application is queried that the virtual machine knows about it. And what we're going to discuss today that we're going to discuss is invasion techniques in which we are talking about direct notification of the intermediate language code so that the application does not know that something happened. Basically, virtual machine lies to the application. So, and when we're talking about the Java techniques, this is just an example of an invasion technique that many ways of performing the same thing. What I did here is I took the print stream class, this class which implements the print line. I extracted it from RT.java, RT which is the runtime java containing all of the code of the most of the important Java runtime. I extracted it out, disassembled it using jasper disassembled, disassembler, modified the code, recompiled it back, reassembled it back using jasper disassembler and deployed it back into the runtime, right? Well, basically for more information, you can access this site and get some info about it. But the interesting thing is that you can change the language by that and the application. In .NET, well, the concept is pretty much similar but it's a little bit more complicated because in .NET we have the signature mechanism. And in .NET we have a signature called strong name in which all of the assemblies are being, assemblies have their own signatures. So I cannot just take the DLL, change it and put it back in its location because the signatures does not match, right? So what I thought at the beginning, in the beginning of my research, I was thinking about, well, I will just disable the signature mechanism, right? Or I can just find where the operating system is hiding the private key and maybe re-sign it back everything, right? But I found a better way of doing that. And the way of doing it, which is very simple, but it's very funny that how it happens, is that, well, the GAC, this is where the location of the DLL is stored. It is in Siegwindows assembly GAC32. Here you have a directory for each assembly. So for example, MSColelib, which is one of the most important DLLs. MSColelib can have many versions. So each version contains its own directory that says what is the version of the DLLs of here. You see the .NET 2.0 DLL for MSColelib. And this is the signature of it. Well, it turns out that if you take the DLL and put it back to its location in this directory, yeah, this contains the signature, right? It looks at the signature. It says, hey, I need to load the DLL containing this signature while I just load it from there. So it's no signatures of check. And basically what's so funny about this is that, basically, if we look into it, what basically, this mechanism here, even though that there was some signatures checked, we're basically attacking the disabled those anyway, right? So basically the two performance issues that were the verification was disabled. So now all you have to do is just write your DLL to the same location, to the correct location that you want. And the last thing that you want to do is to avoid engine. Engine is a pre-compiled code. So you would like to throw away the cached version of the old code, right? So you just disable the old code, the caching using engine and install, and the previous DLL. Basically from here on, you can remove traces with the engine. Go read the white paper that it has. It contains information about these languages. We've talked about the techniques of changing the dotted language or in the Java language. From now on, we're talking about more generic stuff. Basically one of the important things is that we can extend the language. We can add features to the language. We can add new methods. We can, I call it method of function injection because you're adding new methods to the language. For example, if you want to do the same thing again and again and again, because instead of writing the same code, just wrap your code as a new method, right? And the best parameters to do that. Just call your method. So basically I've implemented a couple of methods. One of them is called send to URL. What it says is that it will send some data from an attacked machine to the attackers of the parameters. It's where to send it. And what is the data? Reverse shell. Please open a reverse shell for me for NIP and also specific stuff that I need to call this function. Hide file, inject class, man in the middle which returns a man in the middle socket. And in key log event handler, all of those are examples of things that can be injected into frontend. But when we're talking about managed code, we usually manage code is implementing object-oriented concepts. And one of the interesting things about object-oriented is that we have the notion of inheritance. So basically if you have a class that you want the class to contain code to extend code of other class, you're just inheriting from the class. And well, all of the classes are inheriting from a class called object. So basically we have something like a tree of the class. And object is the uppermost class. So basically if we want to inject code that will be inherited to all of the classes in the runtime, all we have to do is inject it into objects. And do all other interesting things. For example, we can inject into a subtree, into a branch. For example, let's say that we want to inject only to this subtree. So all we have to do is inject into here. So basically inheritance will do it for us. So we just need to look for it. So a little bit about the development scenario is why we can do many interesting things. And I want to save time to show you some demos. So let's start with the first one. But the first one, here we're talking about stealing the authentication credentials from the runtime authentication mechanism. We're not talking about the application-level authentication code. We're talking about the runtime method, Boolean method that gets from the application-level password and returns back to the typical sensor. So what we're going to see about here is that we're going to inject into an internal authentication method, code that says something like, well, take the username and password that you now have. Well, this is an internal class members. Take it from the class and send it to the attacker using our own send to your class. Right? So we've injected the code into your method and now we are just calling it and saying, well, I want to send you to me the username and password of the user. And let's hear a demo about that. Well, in our demo, we're going to see an attack application. Well, think about a hosting application, a hosting management system in which you have many applications on the same machine. We're attacking all of them at once. So we're talking about a rich bank server, which we have many users and the login page, if this is the login page, this is the login page code. The login page code calls the action of the button click is to call font authentication, authenticate sending the username and password and calling the runtime. So runtime method has been hijacked so that in the end of the original code, we can see a call to send to your event and the data will be sent to the attacker. Well, in this demonstration, we're going to talk about an application in a server called rich bank. Well, rich bank, believe me, that they have lots and lots and lots of money. So this is a place where attackers probably want to attack. So in this application, the application, the low level implementation was being hijacked so that what we're going to see now, we're going to put our user over here and let's have a server. One attacker, well, our attacker, let me just make sure that I'm running on the machine. Look at this. But when the attacker receives the data, data will be written into this directory called receive the input. So I'm going to put my attacker over here. So basically the flow will be something like this. The user will enter his credentials into the application, through the runtime and into the receive the direct, right? This will be the flow. So let's take our input here, my credentials, but I'm going to write something which is wrong, so it is the password is blah blah blah. As I'll look in, take a close look what happens over here. So locked in, well, access is denied. Let's go back. So now let's go. So I can see that the log file says that the user has tried to look in with password blah blah and the user has tried to look in with password blah. So, and this was a demo of hijacking the forms of authentication. If we're talking about another attack on the same method, well, this is another attack vector. Now we're attacking authenticate, but only now we are inserting a backdoor into the authenticate method. So now we're talking about adding this piece of code. This piece of code says, and it's very similar to what developers like to do. It says, if you have some specific magic password, this magic password will let you in into any account that you like, right? And the code says like that, well, if the password is magic, it will let you in. If I will look at the same thing after disassembling it, editing the code, basically injecting this code, assembling it back and the compiling it into C-Shop, so we can have a better look at it, it looks something like this, okay? So this is the if, basically. Now we can add another example that we'll see later on. This is about reverse shelling. And in reverse shell, basically what I did, I took an implementation of Netcat, basically I did it in different ways of doing the same thing. What I did is I took and coded the version of Netcat, pushed it back, the executable into the runtime, and when something is executed and Netcat is being deployed to this and executed. Well, you can do it in very other ways. For example, you can inject it into memory so that you will not have traces, but basically the idea is to execute code when some specific thing happens. And in our example, the code was injected into application run, run is a method that should be called each time an application is executed. Basically this is like a main in a C++ application. And the code that was injected here, well, this is a code that says as we can see, this is a pre-injection code. The code is injected into the beginning of the method. We can see code that says, well, call our own reverse shell method, basically I've injected reverse shell before that, and pass on the parameters that the attacker's machine IP and the port. So this is all the attacker needs to do when reverse shell has already been injected. So that only has to be just pass on the parameters to the stack and we'll see a demo of that later. Crypto attacks. Well, crypto attacks, those attacks are very important and very interesting because crypto, this is something which directly relates to security. And when someone attacks your crypto libraries, basically he's creating a false sense of security. Because you're trusting the crypto libraries and for example, you think that you've done everything correct, so basically if someone, for example, let's talk about some example, some attack scenarios, key fixation, when someone fixate your key, you're thinking that you're crypting with your chosen key, but you're crypting another key. Key stealing, for example, stealing the correct key from inside the crypto class using center URL. Or algorithm downgrading, for example, the application asks for AES implementation, what it gets back is easy crackable test. And an example thought for that is that and if this is the generate key method, this is the method that creates the key for the application, basically what I did is I reversed engineered this method, throw away its own implementation and now I have something that says return always fixated key. Again, from the user point of view, he thinks everything is encrypted. Well, the data looks encrypted, right? If you look at the data, the data, it's looking encrypted, you will decrypt it, everything works fine, but you do not know that your key is not relevant. Well, DNS manipulation. In DNS manipulation, we are talking about taking the user to some place that they didn't want to go to. This is an example Java rootkit in which a code that was injected into the DNS classes so that when a resolving will be performed, for instance, for a server called www.firstquoteserver.com, the resolving will be performed to the attacker's IP, right, to the attacker's machine, www.attacker.com. Basically it looks like this, so if this is the original code of get by name, this is Java's implementation of performing DNS resolving, .NET is get host addresses, basically the same. I've injected the code that's something like this. So now, if the call comes to resolve as, well, I've overwrite if as equals, for example, overwrite as, and return as as to a supposed. I hope that I have a couple of minutes for this demo, so let's start it very soon. This is the code server, this will be hard client. Well, now the victim is supposed to usually run a demonstration. Going to take backtrack. Backtrack is awesome, right? But now we're going to see it twist the backtrack and use it as the victim machine. Think about what happened when you download OS from untrusted sources, right? Guys, stop downloading OS as OS from email bit. Might contain your system might be hacked. So I'm going to use as a victim a Linux machine and the interesting thing is that class that I wrote and it's execute as it's supposed to be on Windows machine, I've deployed the same class on Linux machine, right? So, and this is where a virtual machine comes into place so that my user, let's put it over here and now we're going to perform many the middle attack. So let's take our own attacker and the attacker has his own many the middle server. As you can see, he's waiting for victim. Let's put this guy over here. So, we have separations, different machines guys, different IPs, not cheating. So as you might see, as you can see and take a close look, when I do a connect, connection is supposed to be happened to forex code server to here. Taking close look, you will see that connection will be opened first over here. Well, it might be too fast, but I hope that it works out, connect and it is not the end of it. Well, basically I could have stopped here because taking the user to the wrong place is bad enough, right? But here the attacker's mission was to make and to cheat, to fool the user. And this is where we are talking about a code forex server. So I want to make the user looks like, for example, British pound, it's something which is worth buying this. And well, the user sees that. And they say, hey, great, great, we should British pound. Let's buy a couple of those. Give me 10,000 of those. Great, transaction accepted and the user was fooled. So this is the end of this demo about DNS manipulation. Let's take a look about that. Stealing connection strings, this is something where the application is performing a lot of interesting things. And one of the important things is timing. Well, in timing attacks, your attack is supposed to be executing what some specific thing happens. For example, stealing connection string to databases is supposed to happen when application opens a connection to the database, right? You cannot just put some code in some very general place. You need to do it in some specific place. And I want them to inject code that does something like this. Well, take this dot connection string and send it to the attacker. But the thing is that I cannot inject it into the constructor of the object. I need to inject it into a place that I know that where it is being called, connection string will already be initialized. Where to place to do that is in open. Application called open, which is really initialized. Permanent HTML and JavaScript injection is where the code is being injected into not necessarily code sections, but code templates. For example, HTML blocks, JavaScript blocks, and stuff like that. So we can inject, for example, permanent cross-site scripting. We can perform proxy as many of the middle's defacement attacks. And one of my favorites calls to browser exploitation frameworks, such as ExcessShell, right? You all know ExcessShell, right? You know ExcessShell, guys? Great. ExcessShell. Picking into secure string, this is where we're stealing data from something which is called a secure string. This is a string that contains, this is a string which is encrypted in memory. Well, if the string is encrypted, this is because someone wanted to hide something which is very valuable. Let's steal it from there. And this is the code that can do that, you think we can send to URL. And the last one, we are talking about disabling security mechanisms. Here we're talking about disabling the virtual machine-owned mechanisms such as Java, just, or .NETcast. Basically, if we have some kind of code access security, this is like an ACL, but for code, so that we can say what class can do and what method can call and everything, and stuff like that. Basically, if we take a look at the configuration, the application will not behave according to configuration. Again, if there will be some kind of auditing, security auditing will say, hey, everything is fine, I see this configuration is supposedly, but the application will not behave as it should. Again, false sense of security. But those are just examples. As you can see, sorry, you can implement what you want. If someone hacked your own virtual machine and you can perform other kind of things, then basically this guy is deleted. There are some advanced topics to mention. For example, first platform classes can perform many interesting things. You can deploy classes, the customer classes. You cannot, you don't need to tie the code to the specific machine, to the specific CPU. There are run times like enterprise service bus, web services stacks, application servers, database, stuff like that that already contains virtual machines. As an instance, SQL Server 2005 contends an internal implementation of .NET Framework. You change the database build. And we can also talk about multiple change-root kits or second-order-root kits in which we're having an OS-level-root kit. So, for example, kernel-level-root kit that hides the presence of MCR and MCR height is on the application, right? Remember, MCRs are not targeting the OS, they're targeting the application. And the last thing that I want to talk about, now I'm going to talk about .NET exploits. This is a tool that I wrote in order to, in order to show as a proof of concept that things like this can happen. And basically, .NET exploits is not necessarily a legal tool. .NET exploits is a generic .NET framework language modification tool, so you can perform, you can change basically your language. It's an open-source tool, you can download it, change it, modify it, add models to it. You can even add more languages to .NET exploits. So basically, and you don't necessarily have to run it on Windows, you can actually run it on Linux using a Mono project. Well, .NET exploits contains most of the attacks that I talked today and another couple of examples of download it and play with it a bit. And the concept with .NET exploits is that you're developing a general-purpose models. Modules can be either a function, a function is a general-purpose method. You can, you develop payload. Basically, the separation between payload and method is that you don't necessarily have to mix them together. And references is when you're injecting code that contains .NET exploits that wasn't there before and an item. And an item, it's very interesting because an item is the model that ties them all. An item looks something like this. An item is an XML that describes basically where we want to inject our code. So basically, what is the target DLL? So we can see that we are changing MS code live and this is the location of MS code live. We want to inject, for example, this piece of code. And the location of the code. So this is the hooking point. This is where we want to inject our code. And what is the mode? What is the mode of operation? Whether we want to inject it as a pre-injection, post-injection, or we want it to replace all of the code that was there. And let's see the last demo. The last demo is about .NET exploits, performing a very intensive task of injecting a reverse shell into the .NET framework of own implementation. And the task is that we are performing a conditional reverse shell that only one specific application called sensitive application, right? It's been executed. The reverse shell will be opened back to the attacker. So let's go to our machine, but it's fast because we don't have much time. So I run .NET exploits. Going to load one of the items. There are many items here. I loaded the last one conditional reverse shell and I'm going to start. So now what it will do, now it will go to this directory, take this DLL, perform the compilation of the DLL. After the compiling the DLL, it will inject the function, reverse shell generic. After that, you inject the function called reverse shell private generic. After that, inject the payload, which is conditional reverse shell form, in a mode which is pre-append so that code will be injected in the beginning of the function. Basically, if I wanted it to be executed at the end of the function, all I had to do is change the configuration, right? So now it's in pre-append and after it will finish, it will recompile it back, basically reassemble it back into a DLL. And basically it will generate a new DLL for me so that this DLL will later be used to replace the framework on DLL so that basically now I'm going to change the dotted language so that now the injection will be performed into run. Remember, run is when applications are being executed, run is being called. So now when run will be called, it will check whether the name of the application is in sensitive application. So as it's done its operation, it asked me whether I want to generate deployers. Well, deployers are batch files, this is a deploy and undefloy batch files that will be used in the modified machine. So that, well, we don't need to take dotnet score to do the modified machine. All we have to do is to take the DLL and the batch file. So I'll execute that, yes. And so dotnet score is finished and it's gone. I'm going to ask the attacker side on the shell here. Now I'm going to run the sensitive application to show you that I didn't deploy it yet. So now I'm going to execute sensitive application to show you that nothing happens in a couple of seconds. So, and this is sensitive application, nothing happened. Well, what I'm going to do now, I'm going to deploy the DLL, that's it. Now I'm going to run the same deal, the same executable. And if everything works as fine as supposed to be, every version will be open on the right side. That's it, we are. Scary stuff, right? Someone messes up with the runtime so basically code reviews on a runtime that's been tampered with does not mean anything. You should not trust the runtime. So basically what we can do, I'm calling for action for, for example, antivirus says and host-based IPSs to block runtime tampering attempts. The same kind of behavior that I'm expecting a decent antivirus when, for example, a malicious process tries to, for example, change my host file and the antivirus says, hey, some process is trying to do something to go operating system. I expect this antivirus to tell me that some process is trying to change my manage code environment. ID guides should perform file tampering detectors using, for example, trick wire, but do it using an external machine, auditors, pen testers, forensics, look for your evidence inside virtual machines, know about this kind of shit of things. Developers, you should know that your application is secure and it's the underlying virtual machine, right? Virtual machine vendors, like Microsoft, basically this is not a direct responsibility of them, but although it's not a good solution, they should raise the value to them. It's too damn easy to do. And of course, end users, all of us, we should know about this kind of thing and we should verify our runtimes. Well, for more information about this research, you should look at this page, this is where the slides are, white paper, dotnet exploit tool, source code, basically everything. It's important to mention Ken Thompson who talked about C compiler vectors, he talked, the first guy who talked about the vectoring of the compilers, and Dennis Cruz from the Overse.net group who talked about the dangers of full trust application. Well, to summarize, we all seen that malicious code can be hidden inside the virtual machine, the application of a virtual machine. That's an alternative place for hiding malware. We're not just talking about kernel, BIOS, places like that, talking about other places for vectors. Very interesting attacks can be devised using the techniques like that, so be careful. And well, it does not depend on any specific vulnerability because basically it's not restricted to any machine, to any technology. We're not just talking about dotnet, Java, or stuff like that, but a custom problem, sorry, generic problem we have. And the last thing we saw, dotnet exploit, the generic language modification tool that simplifies the process of dotnet modification. But I want you guys to remember that dotnet exploit is not necessarily an evil tool. I used it as a custom tool. It can be used to modify the framework, but it can also be used to basically modify the framework, create your own version of dotnet framework, generate customized mod frameworks, tiny framework, secure framework, performance framework, stuff like that. So guys, if you have any questions, I'll be right over there at room 104. And thank you very much.