 A good morning. So everybody that's like from the middle half of the room, if you all want to come up a little bit, there's going to be some of the slides here that got some code on it. Codes got really tiny text. I know my eyesight isn't that good that far back, so try to do the favor to you all to come up a little bit forward so you can see what's going on. With that, here's topper. Awesome. Well, thanks for having me. This is actually my first time speaking at DevCon and my first time attending, and I am blown away at the caliber of this community. I'm glad to be a part of it, so thank you for coming to the talk. So this is hijacking arbitrary dot net application control flow, and I'm going to show you how to essentially screw up some dot net applications. So before I get into the meat, who am I? I'm a security researcher right now at Intel. Previously I was doing security research down in Ashland, Oregon at Southern Oregon University with a great group of people, several of which are in the audience, so thanks for the support. I've also done a little bit of security training. Most recently I co-led a talk on dot net hacking at the new developers conference in Oslo, Norway, and then I occasionally blog and occasionally tweet. So overview. Dot net. Why the hell do any of us care about hacking dot net applications? Well, like I said, I was at the new developers conference in Oslo, Norway, and 80% of the attendees there were dot net developers, and there's constant jobs up online for dot net development within enterprise. They're building enterprise level applications, SQL databases, fingerprint readers, et cetera. So there's a big market for dot net developers, but there's not really people attacking dot net. So because of that, I'm going to go through runtime attacks in the dot net framework, so doing things like manipulating the just in time compilation process, manipulating things at the machine code level. I'm going to show you how easy it is to modify control flow in dot net applications, taking branches and call instructions and changing them arbitrarily to things that you control to essentially do something different in the application. That's evil. And then I'm going to show you machine code editing in dot net. This is not really a common practice being taken place right now. A lot of people are doing like ILD compilation and then changing bytes at the I.L. level, and these are all on disk attacks. So I'm going to take that a step further and go down to the machine code. And then I'm going to show you how easy it is to manipulate the managed heap, which is the mechanism that dot net uses to store all instantiated objects. So it's actually unprotected, so we can go through it and rip off objects that are currently instantiated and utilize them ourselves. So that's essentially why we're here. I'm releasing tools with this presentation, gray frost and gray storm, which I'm going to be demoing. This is a pretty demo heavy presentation. And then we're using dot net to attack. Not many people are operating in this space, which I'll get to, and I think it's pretty freaking cool. And then of course we're using objects on the managed heap, which isn't really something that's been too much done before, and I think you're really going to enjoy it. So when I talk about CLR attacks, or the common language runtime, essentially I'm talking about the actual runtime. So you have a process running on your machine, say for example a C application, and that's the process. In dot net there's a level underneath that, which is called the CLR, and that's essentially its own little container for that dot net instance. So it's essentially inception. You're running a process inside of another process. So there's two main versions of the CLR. There's version two and version four. And commonly when you're building attack payloads for C sharp, you have to worry about your target application. But I'm going to show you how we don't have to worry about that anymore because I took care of some of the work and now we can use any payload and not care about what version we're running in. Also with the CLR, that's essentially where the managed heap is living because it's this runtime concept where objects are being stored. So that's essentially a part of attacking the CLR. If we keep diving down into what makes up a dot net process, we have these things called app domains, which are essentially these giant containers for running code and they contain the actual executable that we're running and all of the DLLs that we're running and those things are called assemblies. So essentially within an app domain, which there could be more than one, but it's not really common, and utilizing that commonality when I go through gray frost, it makes a little bit more sense. But essentially because of this, we're able to control all loaded code and if we have access to the CLR itself, we can manipulate the just-in-time compilation process. So when we're attacking with assembly or ASM, since assembly is an overloaded term now in dot net, since it's also a module like a DLL or an executable, we can go through and manipulate the actual resources of those things. Go through, edit the method tables, call in with actual machine code in dot net to go through structures and enumerators that you're not typically allowed to be doing in the dot net framework, but machine code makes possible. And then of course we're attacking methods just purely at the machine code level. So here's kind of a little bit of a layout of the runtime, if that didn't really make sense to you. So again, you have your process, you have the CLR and app domains, you have your assemblies and then it's like any other language. You have objects with properties, fields and instance methods and you have classes that contain static methods and the core logic of your application. So now that we have an idea of what a dot net process looks like and what these tools are actually going to be doing, I'm just going to jump right into them instead of boring you with more details about dot net because we all know how to read. So gray frost and gray storm are two different tools but they're acting in tandem for the purpose of this. Gray frost is going to be a DLL that you inject into your target application and this is going to act as a bootstrapping process to bind our payload into the dot net CLR and I'll go through that in more detail. And then gray storm is the payload that I'm delivering with gray frost. Gray storm is going to be an in memory attack reconnaissance tool written in C sharp that attacks dot net. So gray frost in detail. Gray frost is our payload delivery system. It's essentially a C plus plus DLL that acts as a dot net CLR bootstrapper. So what that means is it's going through and figuring out what methods it needs to call within MS query which is the main dot net CLR DLL. So it goes through there and it calls a bunch of methods that create or inject into the 4.0 CLR runtime. However, because I mentioned there were two different versions of the CLR that we needed to worry about, version two and version four. This payload delivery system also has the capability to pivot into the 2.0 runtime if needed. This is what gives us the mechanism to not care about what our target application is actually running and we can just insert an arbitrary payload like gray storm. Gray frost is also going to contain the raw payload in a byte array. So that's once it goes through its bootchapping process and it's in the proper version of the CLR, it's going to fire our payloads void main. And it does this in two rounds. The first round is essentially what I'm calling gray frost CPP. This is the DLL bootstrapping process and then after that process finishes we're running gray frost C sharp which is inevitably going to fire our C sharp payload. So graphically this is going to look like this for round one which is gray frost CPP. We have our dot net process running. This could be on a box that we have physical access to, remote access to. It doesn't matter because all we need to do is do DLL injection. So you can utilize metasploit, utilize a tool that I'm going to show you called gray dragon. It doesn't matter just inject the DLL however you see fit. Once gray frost C++ is spinning up in that target application it pivots down into mscory.dll, calls the needed methods and instantiates the CLR. And then it pivots into gray frost C sharp which at this point we're in the proper version of the CLR 4.0. So we have our dot net process with gray frost C sharp running in it. We're in the right version of the CLR so our payloads void main gets fired and now our payloads running in tandem with that process. If we have to pivot between runtimes because our target application is running the CLR version 2.0 which you might think is not that common because 4.0 is the newest and greatest thing but developers are lazy so a lot of things are still 2.0 unfortunately. But it's not much more of a step. I've done the work for you. You just have to utilize the delivery system. So after injection and after it pivots down into mscory and fires the first round of gray frost C sharp, gray frost C sharp realizes that your app domain's name is default. If it's labeled as default this means that the target application isn't actually running an app domain because it will normally have a name associated with it that's not just default and I'm making default when I inject. So gray frost C sharp comes back into gray frost C plus plus. We pivot down into mscory, do a little bit of cleanup and then fire gray frost C sharp once again in the proper version of the CLR. So that's gray frost in a nutshell. Like I said it's being open sour so you can go through and read the code of how all of that is made possible. But let's get into gray storm which is the payload I'm delivering with gray frost. So gray storm is our reconnaissance and in memory attack payload. It has several features that are going to be attacking .NET both at the assembly level and at the run time level. So we're going to be able to do things like attack the .NET just in time compiler. If you're not familiar with just in time compilation it essentially means that when you hit compile button on whatever IDE you're using you're not generating runnable machine code. You're generating something at least in the .NET framework called IL code or an intermediate level language and at run time that IL code gets jitted or just in time compiled down into the actual machine code that's going to be ran by the CPU for that particular method. We're also going to be able to with gray storm attack .NET at the ASM level. So I'm going to show you how easy it is to rip pointers off of methods that are already just in time compiled, view their assembly instructions and then override and pure. And then I'm also going to show you and demonstrate how easy it is to roll your own assembly payloads and you can even utilize Metasploit payloads but there's subtle differences between the two that I'll go over. And then of course we're going to be able to utilize objects on the managed heap. So usage of gray storm. I'm going to start off by talking about controlling the just in time compiler. So essentially when you have just in time compilation in the .NET framework when something like method A is calling into method B. Method B contains a method table that has a thing that I'm calling the just in time compilation stub and that contains an address to where the IL code and where the machine code is going to be generated at JET. So because we know this and because Microsoft chose to leave in the framework all of this stuff unprotected, we can go through and grab those tables overriding with anything we want and essentially control the just in time compiler. With this said, if something has already been just in time compiled that we're wanting to attack, this is not possible and you're going to be needing to do something at the machine code level or wait for something to get garbage collected because at that point something is going to be just in time compiled again because the .NET framework made room for something else. So graphically this is going to look like this in the demo. Method A is going to call method B and then method B would initially call into the method B JET stub but what we can do is we can just take a hacker method with a hacker method JET stub, redirect method B to the hacker method JET stub and now method A is going to call hacker method instead. So I'm going to open up a target application right now. This is a pretty cool little markdown editor for Windows since I'm not running Linux because it's new right now. So here's gray dragon. This is a remote DLL injector. I think it's cool for demo purposes because it has this cute little crosshairs that you can drag over to your target application and then I've done a little bit of editing where it's going to automatically select what version of gray frost I need to inject because this payload delivery system is also going to account for the differences in 32 and 64 bit target applications. So once I do inject this is going to inject gray frost into this markdown pad program and then it's going to go through the whole entire boot shopping process that I described and spin up gray storm. So I just injected it, it did the boot shopping process and now I'm running gray storm and it's running in the 4.0 version of the CLR. Now before I go through and actually attack the just-in-time compiler I'm going to do a quick run-through of what this application is. You can see over on the left side that this is inside of the main app domain and you're seeing all of the assemblies within that domain such as the main executable markdown pad and all of the DLLs it needs. So you can keep pivoting down further and further into each of these. You can go to something like markdown pad 2 app, look at what methods it contains. Do things like dump the assembly so I can see the raw machine code for that method after it's just-in-time compiled. Look at the IL code for the thing. It shows me where the address of that machine code is so if I want to do something like attach this application in Windows D-bag, hit a break point, I can now break point on methods which is a little bit easier than having to track them down. But essentially let's just go through and now attack this just-in-time compilation process. There's a licensed feature in markdown pad 2 that allows you to export something to a PDF and currently I have a license for it so I'm able to do this easily. I want to change that feature and I want to insert my own method there. So because I don't want to wait for the just-in-time compiler to do garbage collection I'm going to close out of that application because I just forced a JIT. I'm going to reopen the target application. I'm going to drag my crosshairs back over it, inject back in, and then I'm going to come over here to my dynamic C-sharp window. This is going to allow us to compile new code on the fly which I've already prepared. Essentially I'm going to pop up a message box that says owned and return false because I actually don't want a license for this application anymore. So I'm going to paste that here. I'm going to hit compile and now it's over here in my methods list and I can fire it to make sure it works and oh look it says owned. Awesome. So if I come back over here and trace down and mark down pad 2 there's something here called licensing helper and then there's a boolean validate license so I'm just going to right click it and say replace method with custom C-sharp and it says oh look replacing with DEF CON. So now I'll come back over here to file export PDF and now I got owned and I don't have a license anymore. So that's attacking something before it's been just-in-time compiled. If you want to attack something and you don't want to do what I did and restart your application or wait you can do things at the machine code level. So in dot net there's both far and relative calls and you can just take because I showed you how easy it is to dump that machine code and I'll show you how easy it is to overwrite that machine code. Just figure out what call instructions are going to whatever method it's actually calling and then just replace them and change them. So this is a way to attack something after JIT when you don't want to wait because you're lazy or you want to do something right now and not wait. And of course we know if we read the Intel manual that calculating a relative call address at runtime is a little bit difficult but there's source code on the repo where you can read this and how I've made it easy with a simple method call. So now we get into actual machine code payloads. So utilizing reflection which is just a namespace in dot net that allows you to see things like all of those assemblies, all of the app domains and metadata about specific methods. One of the things that lets us see is actually where that machine code has been just in time compiled to and it's left unprotected in memory. So we can just take it and change it. So we can create cute little payloads to do things like steal stack parameters. Say we see a method of interest that's taking in a password. Steal that password, send it off to your email server and then return the password back to the application and you just stole some stuff. You can do things like change events. So a mouse click isn't a mouse click anymore. It does this other stuff behind the scenes and then the mouse click, it's really up to your imagination. The most quick approaches to doing this are doing things like changing truths to false and false to truths because developers are awesome and that they modulate code really, really, really well. So there's always this low hanging branch of a return true with something like a password or a license check. So password validation can now be bypassed really easily at run time. So it can key in licensing validation. In some instances SQL sanitization can even be bypassed if it's just returning down. Has this thing been sanitized yet? Yes or no? Oh, it has been. I'll just pass it along to the server. There's also a couple of dot net security mechanisms that I won't name. But you can rip them apart and destroy them, grab things off the heap like agent objects, etc. Steel stack parameters, do whatever and rip apart security at the assembly level. And then really we're just overriding logic and we're hackers so update mechanisms are always juicy. So graphically this is going to look like this. Assume that you have this Boolean verify license that takes some parameters. It does some checks to make sure you have a valid license. After JIT it produces some disgusting assembly code that you're not going to want to disassemble and make sense of. So just return one and now the developer actually wrote return true. So let's demo that. So I'm going to open up gray dragging again and I'm going to open up Windows PowerShell ISC which is a little scripting environment for PowerShell developers. So you can do things like paying level three which is not actually going to work because I'm not connected to the DEF CON wireless because screw that. So I'll drag my cross is back into that application. It recognizes that it's a 32 bit application so I'll inject. Here's gray storm once again and notice that this time it's in the version 2.0 of the CLR. So this application is running in an older .NET version but gray frost accounted for that. So within this application there's this run script button. So I'm going to go find it. So I know that it's in this Microsoft PowerShell GP PowerShell assembly and then if I keep pivoting down there's this thing in PowerShell tab and it's void execute script. So this method right here if I dump the assembly is doing all of that manipulation to actually run whatever is in that text box. I can look at the IL code. I can disassemble it if I wanted to. In order to do that I'd have to inject a bengine.dll which is an open source disassembler but to save time I'm not going to go through that. You can when you download and use all of these tools for fun. So I'm going to come over here to show you how easy it is to roll a metasploit payload. So I'm going to log into my Kali Linux box and I'm going to show you that I have an alias setup called Defcon that's just generating an MSF Venom payload to pop a calculator. So I'll go and run that and of course we all know this takes a little bit of time because I'm encoding it and what not but once it finishes I now have a payload that'll pop a calculator. So I'll come over here, I'll drag over it and I'll copy it and then I'll come back over here to gray storm. I'll go to the shellcode tab which has a couple of payloads that I'm including such as just a simple return true, a return false and an MSF calculator payload but I'm not going to use that one because I just made one. So I'll come over here to the shellcode editor, paste my payload, I'm going to name it Defcon and then it has no offset hook which there's a blog post on you can see what that means and then I'll create the shellcode. So now I have this Defcon Metasploit payload and I can say fire it and now if I come back over here and I still have this execute script method selected and I say dump assembly you can see that that has just changed to the Metasploit payload. So if I come back over here to Windows PowerShell ISC and hit run script I popped a calculator. So that's utilizing machine code payloads you can roll your own you can use Metasploit and the most important thing to know is if you want to use a Metasploit payload or roll your own there's a change in the portable environment block that caused me a lot of headache. In the portable environment block if you've ever written shellcode you know that you need to if you want to use other Microsoft API calls that you need to find out the base address of kernel32.dll to do things like get proc address and load library and that's commonly the third entry in the in memory order module listing however in .NET applications it's the fourth so you have to change your one line of code in your machine code payload to actually account for that difference and if you're using a Metasploit payload I recommend making sure that they're doing this as well otherwise you're going to crash your target application and if you're doing this on some enterprise level thing you're going to have a bad time because somebody's going to catch you. So that brings us to object hunting in memory. So now we've done things attacking the just in time compiler, attacking things at the machine code level but what about it runtime? What about getting things off of the managed heap? So if you're not familiar with the managed heap like I said it's the storage point for all .NET runtime objects such as things that are being instantiated by the application things that the user is doing and then occasionally the garbage collector will come through and remove dead objects and make room etc but we don't really care about how it works we're just going to manipulate the crap out of it. So when we do object hunting in memory what we need to realize and what a lot of C sharp developers when you tell them this they're confused is that there's a lot of pointers in .NET and objects are actually pointers to an instance of that object on the managed heap. This object instance contains metadata about that particular object such as what fields and properties are currently set on it and it points to a method table. This method table tells the object instance what method instantiated this thing and all objects of the same type share the same method table. So we're going to utilize that knowledge and a signature. So we're going to utilize reflection to start off with so we can instantiate an object that we're interested in. We're going to utilize an object hunting signature that I created and then we're going to win. So in order to do this there's a six step methodology that you're going to need to take as an attacker trying to rip objects off of the managed heap. It's somewhat inspired by the way the volatility guys do pool tag scanning in memory so I utilized an approach similar to that for these techniques. But essentially step one is we're going to construct an object and find the location of the managed heap. While reflection gives us the ability to look at things like what address is machine code running at for a particular method. This isn't the case with the managed heap and we need to use a little bit of trickery to get the framework to tell us where this thing actually is at runtime. And we also need to construct a reference object so we can go through and figure out things like what the method table is for all of these objects. Step two is we're going to signature that instantiated type so we're just going to use a little bit of machine code to parse that structure that the object instance is and rip off some particular things that we care about. And then step three is we're essentially going to do a brute force approach to scan the managed heap for other object pointers that are the same as this object that we're interested in. And then step four we're going to convert those object pointers back into raw objects which when you do this something pretty cool happens and then profit. So step one is we're going to construct an object so essentially utilizing reflection we're able to go through and parse through all of the app domains, all of the assemblies and all of the constructors for a particular class and we can just call that constructor without actually knowing anything about it and we can instantiate anything. There are some objects that will actually take complex object types as arguments but we don't really need to care about that because we don't want to utilize this object. We just want to have one to reference so we can just nullify all arguments in a constructor and the .NET framework will still construct it for us and then we'll be able to use it how we need to. So then what we're going to do is once we have an instantiated object we're going to build a stack frame and you can see up at the top of the diagram here that I actually have the raw object that I just instantiated and it has a pointer associated with it. This pointer is hidden behind the scenes in the object type though so with a little bit of stack manipulation which you can go and read the gist for this we know already that this object points to the location of the managed heap which really could be anywhere, it could be at the top, it could be at the bottom, it could be somewhere in the middle which is why we're going to need to do somewhat of a brute forcing approach in memory but we're going to move that object down into the end pointer location and now we have the actual pointer to that object and the pointer of the managed heap. So now that we have an actual object created with an address of the managed heap we're going to signature that instantiated type. So object instances like I said contain a method table pointer back to the corresponding type that instantiated them and in 32 bit this is byte zero through three so we're just going to grab that and we're also going to grab the instant size of this object. This is going to allow us when we're going down the managed heap we don't need to do a brute forcing approach by jumping four or eight bytes we can just start jumping the size of each object until we reach the bottom to save some time. And then there's a subtle difference in 64 bit primarily just the size of a pointer but that's all taken care of as well. So then now that we have an object and we've signature it it's time to scan the managed heap. So like I said this is somewhat of an approach to how the volatility guys do pool tag scanning. So the way that they typically do things is they'll brute force through memory with a specific structure and enumerate on top of memory that structure to make sure that the thing that they're looking for matches whatever piece of memory they found. So I do this by incrementing down the managed heap by the size of the object that I rip off of each objects method table. I grabbed the instant size off of all of them and I just start skipping down. And when I find one that matches the instantiated object that I created from before I grabbed that pointer. So now I have a listing of all pointers of objects that I care about. However, if I want to go up the managed heap I have to just scan linearly up it either by four eight byte increments, handle a little bit of access violation type errors but it's a decent signature right now. If somebody has a better approach submit me a pull request and let's make it even better. So now we have other object pointers. So now we're going to convert all of those object pointers back into actual objects. So here's a little bit of code to show this. You can see that there's unsafe code which actually allows you to do pointer manipulation in dot net. However, what a lot of people say is this is actually a compile check. If you're compiling dot net and you're trying to do unsafe code it'll be like whoa, that's not cool. Are you sure you want to do this and you have to explicitly allow it. However, in memory when you're injecting into an application that didn't allow this to compile time it doesn't matter because it's not a run time check so who cares. So essentially we're building a stack again. We're going to have our reference object that we're putting these pointers back into right now it's set to system dot end pointer and then we have an address that we grabbed off of the managed heap to another object. So all we're simply going to do is move that pointer lower on the stack and put it over that reference and then what's magic about dot net is when you give an object a pointer to another object it'll just reference the instantiated object for you and now you have a new reference object to something that was already on the managed heap. So this is how we're able to now go through instantiate an object scan the managed heap for all other objects of that type and then utilize them. So now we're going to learn all the things about an application. So what I'm going to do here is I'm going to open up a fingerprint reader software that shipped on all laptops of a specific manufacturer that wouldn't be named. I'm going to inject once again grayfrost64.dll and open up gray storm. So now what I'm doing is I'm going to open up the GUI a little bit more. Notice I'm not a GUI developer. I'm a hacker so the GUI is not too great so not many hacker tools have good GUI so I'm not too upset about it. But essentially this method editor functionality it's going to show you all objects and then all objects instance methods and fields and properties and then on the left I'm going into the qlclr.user class and I'm going to the constructor. The constructor is taking two complex object types which is a passport and an infinitive object. However like I said you can just nullify those so I just added two nulls and called that constructor and you can see that this thing has a lot of instance methods. One of those instance methods is get the Windows password so I hit get all objects and as you can see I didn't actually get an object. That's because I haven't yet validated that I'm who I say I am with this application so I just swipe my finger and logged in and now I'm calling that constructor once again. I'm going to get all objects off of the managed heap now that there should be one on there. I'll open up qlclr user, go to the properties field and now you can see that I have a plain text system Windows password, Hunger Games Rocks because who doesn't love Jennifer Lawrence. So now we have all of these superpowers and things. Never before have we been able to go through the managed heap on the dotnet runtime and grab objects that we're interested in. So we can go through and essentially construct any object we want and grab any object we want of that type. It's common that things like crypto objects are stored on the managed heap that actually have in a field or in a property the key that's being used, the salt that's being used. So just go through find those things and then if you want to be sneaky change them to keys that you have so everything being sent off to the database is encrypted and they're never going to be able to access which ha ha. And then of course those instance methods for an object you can just actually go through and call them. You can call them with arguments if you really want to. Say in the instance of that constructor it took two different object types. You can just start building a chain, find those types on the managed heap, grab them and then use those objects in a constructor's argument path. The possibilities are really endless and up to you as an attacker. So yeah, yeah, yeah this is a GUI where hackers GUI suck. Well all of these can be all of these payloads can be automated. So Grayfrost is just the injector platform. It's just a DLL. It doesn't matter what your payload is. So you can use just a Python script like autofrost which is which I'm including. Give it a C sharp payload that does automation of something behind the scenes, grabbing stuff off the managed heap, changing machine code instructions, attacking the jitter and injected into a target application and just have it run. So automations is loved so I'm going to go through and attack that fingerprint reader once again and show you that I'm not crapping you and you can actually automate stuff. So I'm going to swipe my finger and authenticate with this application, grab Gray Dragon, inject Grayfrost which at this point is actually an automated version of this payload, inject it and Hunger Game Still Rocks. So when it comes down to constructing attack chains, it's actually relatively easy to attack .NET applications due to the nature of this just-in-time compilation process. So if you've done any sort of .NET work or if you've played along with challenges such as the FireEye Flare On Challenge which actually had a couple of .NET decompiling challenges to recover their email keys, you can just throw something into an ILD compiler and actually look at a higher level C sharp source code representation because of how easy it is to generate C sharp source code back from I.L. So you can utilize this sort of functionality to locate meaningful objects that you might want to steal off of the managed key for a particular application and then find methods, fields, properties of interest that you can attack at the machine code level or the just-in-time compilation manipulation level. And then of course like I mentioned there's a little bit of debugging functionality thrown in here and the fact that I'm giving you the address of constructors and the address of methods that you're interested in. You can just take those and throw them in a debugger and breakpoint at them. In the case of that fingerprint reader I had no idea what specific event triggered that object to appear on the managed key so I just set breakpoints everywhere until something happened. If I wouldn't have done that I would have never figured it out so this is incredibly useful if you have a little bit of time and you actually want to say this application I want to pwn it. And then because this is a DLL you can just utilize something like DLL hijacking and put this Grayfrost DLL on disk and every time that application spins up force it to load it and then you don't have to worry about things like attacking the just in time compiler and waiting for garbage collection because it does it the second the application is loaded. Furthermore say you want to do something like every time a SQL object appears on the heap I want to grab it and send it off to my server. You can do this by just placing a payload on disk utilize DLL hijacking and now every single object on the managed heap is yours. This also opens up a whole new avenue of hybridization of .NET and machine code level of tax that haven't been possible before. So a lot of what I did when I manipulate the managed heap is actually calling into raw machine code to do things like parse all of those structures. So you can now utilize this technique to do even more complicated things that haven't been possible before. You can also do things because we're at a higher level coding space than say C or machine code and that it's incredibly easy to use things like crypto libraries. So just encrypt your .NET payload within Grayfrost or within the actual payload. Call off to your web server make something super hard for reverse engineer to actually find because of how easy it is to reverse engineer .NET. Don't make it that way for him give him hell. And then you can also do this at the machine code level two just include a machine code payload in your application encrypt it do some sophisticated hackery techniques to make it incredibly hard to find you and then fire your payload. And then the payload system why use it? Well for starters C sharp is an incredibly easy language to learn. Like I said at the NDC conference that I was at none of these guys really even understood the power of reflection or that there were actually pointers in the .NET framework and these guys do it every day. So it's incredibly easy to use C sharp and it's incredibly easy to build payloads and malware in C sharp. And because of these techniques and the Grayfrost platform you can just run this in pretty much any application you want. Because the Grayfrost DLL creates or injects the 4.0 CLR you can actually inject this thing into a C application a Python application and spin up the .NET framework inside of that which you may want to do but the real purpose is attacking .NET but that could be something cool and trickery that would blow somebody's mind. And of course I showed you that the low and high level gap is relatively easy and that I was able to utilize machine code level attacks and C sharp level attacks. So now people that code and C sharp and people that code and assembly can drink beer together and be friends instead of hating each other which I think is cool. So you should get involved with this .NET hacking space and read the code and contribute to it because it's really small right now. In the research I did there were hardly any tools that were referenceable. Nobody was attacking things like the managed heap and most tools are actually just attacking a world of warcraft which on some of these forms people are getting freaking owned and pissed off in like caps lock rage quitting cause they actually invest in security. Good job Blizzard. And then there's lots of PowerShell which is really just a subset of .NET which is cool but it's it's powerful but I think this stuff has good practicality if you want to get into it. And then of course a lot of this was inspired by previous DevCon talks specifically 18 and 19 by a good friend of mine John McCoy who set the groundwork for all of this. So in conclusion I've shown you now that arbitrary .NET applications can be injected and changed at runtime and also opened up a whole entire new avenue for .NET attack possibilities. These tools support automation and they're on GitHub go get them contribute to them submit some pull requests ask me questions and if you do have questions you can come up here afterwards I'll be hanging around till tomorrow because I'm dumb and booked bad flights hit me up on Twitter and there's two white papers on your CD and on my blog so read those if you have even further questions and thank you for listening.