Hijacking Arbitrary .NET Application Control Flow
Timzen, Topher
Allen, Ryan
This speech will demonstrate attacking .NET applications at runtime. I will show how to modify running applications with advanced .NET and assembly level attacks that alter the control flow of any .NET application. New attack techniques and tools will be released to allow penetration testers and attackers to carry out advanced post exploitation attacks. This presentation gives an overview of how to use these tools in a real attack sequence and gives a view into the .NET hacker space. Topher Timzen has had a research emphasis on reverse engineering malware, incident response and exploit development. He has instructed college courses in malware analysis and memory forensics while managing a cybersecurity research lab. Focusing on .NET memory hijacking, he has produced tools that allow for new post exploitation attack sequences. Topher is currently a Security Researcher at Intel.
 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 Toper. Awesome. Well thanks for having me. This is actually my first time speaking at DEF CON 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 the 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 run time, essentially I'm talking about the actual run time. 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 run time 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 Grayfrost and Graystorm are two different tools but they're acting in tandem for the purpose of this. Grayfrost 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 Graystorm is the payload that I'm delivering with Grayfrost. Graystorm is going to be an in memory attack reconnaissance tool written in C sharp that attacks dot net. So Grayfrost in detail. Grayfrost 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 Graystorm. Grayfrost is also going to contain the raw payload in a byte array. So that's once it goes through its bootstrapping 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 Grayfrost CPP. This is the DLL bootstrapping process. And then after that process finishes we're running Grayfrost 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 Grayfrost 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 Grayfrost C++ is spinning up in that target application it pivots down into MSCORI.DLL, calls the needed methods and instantiates the CLR. And then it pivots into Grayfrost 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 Grayfrost 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 MSCORI and fires the first round of Grayfrost C sharp, Grayfrost 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 Grayfrost C sharp comes back into Grayfrost C++. We pivot down into MSCORI, do a little bit of cleanup and then fire Grayfrost C sharp once again in the proper version of the CLR. So that's Grayfrost in a nutshell. Like I said it's being open source so you can go through and read the code of how all of that is made possible. But let's get into Graystorm which is the payload I'm delivering with Grayfrost. So Graystorm 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 Graystorm 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 Graystorm. 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 JIT. 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, overwrite them 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 JIT stub. But what we can do is we can just take a hacker method with a hacker method JIT stub, redirect method B to the hacker method JIT 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 cross hairs 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 bootstrap and process that I described and spin up Gray storm. So I just inject the bootstrap and 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 license 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 jet. I'm going to reopen the target application. I'm going to drag my cross hairs back over it and 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 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 markdown 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 dev 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 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 trues to false and false to trues 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.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, et cetera, steal 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. 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 B engine.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 DEF CON 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 will 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 shell code 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 shell code editor, paste my payload, I'm going to name it DEF CON 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 shell code. So now I have this DEF CON 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 ISE 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 shell code 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 is 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 at 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 the 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 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 run time. 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's 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 object's method table. I grab 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 grab 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 8 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.NET. However what a lot of people say is this is actually a compile check. If you're compiling.NET and you're trying to do unsafe code it will 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 at 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.inpointer. 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.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 and 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 would 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 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 in plain text. 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 super powers and things. Never before have we been able to go through the managed heap on the dot net run time 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 their database is encrypted and they're never going to be able to access which haha. 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 payloads can be automated. So Gray Frost 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 auto frost 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 love 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 Gray Frost which at this point is actually an automated version of this payload, inject it and Hunger Games still rocks. So when it comes down to constructing attack chains, it's actually relatively easy to attack dot net applications due to the nature of this just in time compilation process. So if you've done any sort of dot net work or if you've played along with challenges such as the fire I flare on challenge which actually had a couple of dot net decompiling challenges to recover their e-mail 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 IL. So you can utilize this sort of functionality to locate meaningful objects that you might want to steal off of the managed heap for particular application. And then find methods, fields, properties of interest that you can attack at the machine code level or 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. So you can just take those and throw them in a debugger and break point at them. In the case of that fingerprint reader, I had no idea what specific event triggered that object to appear on the managed heap so I just set break points 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 point 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 too. 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 in C sharp and people that code in 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 World of Warcraft, which on some of these forms people are getting freaking owned and pissed off in caps lock rage quitting because 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 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 run time 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 until 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.
 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 Toper.  Awesome. Well thanks for having me. This is actually my first time speaking at DEF CON 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 the 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 run time, essentially I'm talking about the actual  run time. 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 run time 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 Grayfrost and Graystorm are two  different tools but they're acting in tandem for the purpose of this. Grayfrost 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 Graystorm is the payload that I'm delivering with Grayfrost. Graystorm is going to be an  in memory attack reconnaissance tool written in C sharp that attacks dot net. So Grayfrost in  detail. Grayfrost 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 Graystorm. Grayfrost is also  going to contain the raw payload in a byte array. So that's once it goes through its bootstrapping  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 Grayfrost CPP. This  is the DLL bootstrapping process. And then after that process finishes we're running Grayfrost 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 Grayfrost 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  Grayfrost C++ is spinning up in that target application it pivots down into MSCORI.DLL, calls  the needed methods and instantiates the CLR. And then it pivots into Grayfrost 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  Grayfrost 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 MSCORI and fires the first round of Grayfrost C sharp, Grayfrost 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 Grayfrost C sharp comes back into  Grayfrost C++. We pivot down into MSCORI, do a little bit of cleanup and then fire Grayfrost C  sharp once again in the proper version of the CLR. So that's Grayfrost in a nutshell. Like I  said it's being open source so you can go through and read the code of how all of that is made  possible. But let's get into Graystorm which is the payload I'm delivering with Grayfrost. So  Graystorm 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 Graystorm 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 Graystorm. 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 JIT. 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, overwrite them 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 JIT stub. But what we can do is we can just take a hacker method with a hacker method  JIT stub, redirect method B to the hacker method JIT 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 cross hairs 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  bootstrap and process that I described and spin up Gray storm. So I just inject the  bootstrap and 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 license 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 jet. I'm going to reopen the target application.  I'm going to drag my cross hairs back over it and 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 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 markdown 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 dev 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 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 trues to false and false to trues 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 .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, et cetera, steal 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. 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 B engine.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 DEF CON  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 will 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 shell code  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 shell code editor, paste my payload, I'm going to name it  DEF CON 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 shell code. So now I have this DEF CON 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 ISE 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 shell code 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 is 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 at 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 the  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 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 run time. 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's 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 object's method table. I grab 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 grab 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 8 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 .NET. However what a lot of people say is this is actually a compile check. If you're compiling .NET and you're trying to do unsafe code it will 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 at 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.inpointer.  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.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 and  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 would 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 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 in plain text. 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 super powers and things. Never before have we been able to go  through the managed heap on the dot net run time 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 their database is encrypted and they're never going to  be able to access which haha. 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 payloads can be  automated. So Gray Frost 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 auto frost 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 love 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 Gray Frost which at this point is actually an automated version of  this payload, inject it and Hunger Games still rocks. So when it comes down to constructing  attack chains, it's actually relatively easy to attack dot net applications due to the nature of  this just in time compilation process. So if you've done any sort of dot net work or if you've  played along with challenges such as the fire I flare on challenge which actually had a couple of  dot net decompiling challenges to recover their e-mail 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 IL. So you can utilize this sort of  functionality to locate meaningful objects that you might want to steal off of the managed heap for  particular application. And then find methods, fields, properties of interest that you can attack  at the machine code level or 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.  So you can just take those and throw them in a debugger and break point at them. In the case of  that fingerprint reader, I had no idea what specific event triggered that object to appear on the  managed heap so I just set break points 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 point 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 too. 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 in C sharp and people that code in 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 World of Warcraft, which on some of these forms people are getting freaking owned  and pissed off in caps lock rage quitting because 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 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  run time 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 until 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.
DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_0_1319.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_1320_1955.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_1956_4259.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_4260_4883.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_4884_6203.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_6204_8063.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_8064_8567.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_8568_9563.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_9564_11603.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_11604_12599.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_12600_12863.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_12864_13499.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_13500_14111.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_14112_14195.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_14196_14339.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_14340_16463.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_16464_16523.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_16524_17951.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_17952_18191.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_18192_18527.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_18528_22175.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_22176_23327.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_23328_23435.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_23436_25967.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_25968_28067.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_28068_28127.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_28128_28271.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_28272_30167.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_30168_32147.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_32148_32219.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_32220_33659.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_33660_33983.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_33984_34535.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_34536_37727.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_37728_38723.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_38724_39875.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_39876_40055.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_40056_42647.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_42648_44027.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_44028_44567.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_44568_44675.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_44676_46967.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_46968_47075.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_47076_47159.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_47160_48671.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_48672_48815.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_48816_49535.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_49536_49595.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_49596_49643.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_49644_50159.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_50160_50255.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_50256_50555.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_50556_53351.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_53352_54959.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_54960_56807.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_56808_58043.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_58044_58919.png DEF_CON_23_-_Topher_Timzen_and_Ryan_Allen_-_Hijacking_Arbitrary_NET_Application_Control_F_gatYe_oriJ_58920_58958.png
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 Toper. Awesome. Well thanks for having me. This is actually my first time speaking at DEF CON 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 the 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 run time, essentially I'm talking about the actual run time. 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 run time 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 Grayfrost and Graystorm are two different tools but they're acting in tandem for the purpose of this. Grayfrost 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 Graystorm is the payload that I'm delivering with Grayfrost. Graystorm is going to be an in memory attack reconnaissance tool written in C sharp that attacks dot net. So Grayfrost in detail. Grayfrost 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 Graystorm. Grayfrost is also going to contain the raw payload in a byte array. So that's once it goes through its bootstrapping 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 Grayfrost CPP. This is the DLL bootstrapping process. And then after that process finishes we're running Grayfrost 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 Grayfrost 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 Grayfrost C++ is spinning up in that target application it pivots down into MSCORI.DLL, calls the needed methods and instantiates the CLR. And then it pivots into Grayfrost 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 Grayfrost 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 MSCORI and fires the first round of Grayfrost C sharp, Grayfrost 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 Grayfrost C sharp comes back into Grayfrost C++. We pivot down into MSCORI, do a little bit of cleanup and then fire Grayfrost C sharp once again in the proper version of the CLR. So that's Grayfrost in a nutshell. Like I said it's being open source so you can go through and read the code of how all of that is made possible. But let's get into Graystorm which is the payload I'm delivering with Grayfrost. So Graystorm 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 Graystorm 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 Graystorm. 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 JIT. 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, overwrite them 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 JIT stub. But what we can do is we can just take a hacker method with a hacker method JIT stub, redirect method B to the hacker method JIT 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 cross hairs 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 bootstrap and process that I described and spin up Gray storm. So I just inject the bootstrap and 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 license 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 jet. I'm going to reopen the target application. I'm going to drag my cross hairs back over it and 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 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 markdown 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 dev 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 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 trues to false and false to trues 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.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, et cetera, steal 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. 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 B engine.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 DEF CON 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 will 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 shell code 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 shell code editor, paste my payload, I'm going to name it DEF CON 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 shell code. So now I have this DEF CON 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 ISE 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 shell code 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 is 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 at 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 the 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 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 run time. 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's 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 object's method table. I grab 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 grab 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 8 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.NET. However what a lot of people say is this is actually a compile check. If you're compiling.NET and you're trying to do unsafe code it will 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 at 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.inpointer. 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.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 and 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 would 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 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 in plain text. 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 super powers and things. Never before have we been able to go through the managed heap on the dot net run time 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 their database is encrypted and they're never going to be able to access which haha. 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 payloads can be automated. So Gray Frost 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 auto frost 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 love 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 Gray Frost which at this point is actually an automated version of this payload, inject it and Hunger Games still rocks. So when it comes down to constructing attack chains, it's actually relatively easy to attack dot net applications due to the nature of this just in time compilation process. So if you've done any sort of dot net work or if you've played along with challenges such as the fire I flare on challenge which actually had a couple of dot net decompiling challenges to recover their e-mail 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 IL. So you can utilize this sort of functionality to locate meaningful objects that you might want to steal off of the managed heap for particular application. And then find methods, fields, properties of interest that you can attack at the machine code level or 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. So you can just take those and throw them in a debugger and break point at them. In the case of that fingerprint reader, I had no idea what specific event triggered that object to appear on the managed heap so I just set break points 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 point 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 too. 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 in C sharp and people that code in 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 World of Warcraft, which on some of these forms people are getting freaking owned and pissed off in caps lock rage quitting because 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 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 run time 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 until 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.
this is hijacking arbitrary dot net application control flow. And I'm going to show you how to security researcher right now at Intel. modify control flow in dot net applications, presentation. And then we're using dot net to Grayfrost. Graystorm is going to be an in memory into the 4.0 CLR runtime. However because I attacking.NET both at the assembly level and at we can just take a hacker method with a hacker collection, I'm going to close out of that my dynamic C sharp window. This is going to allow I'm not going to use that one because I just made compiler, attacking things at the machine code address is machine code running at for a flare on challenge which actually had a couple of can attack at the machine code level or just in and malware in C sharp. And because of these techniques and the Grayfrost platform, you can to utilize machine code level attacks and C sharp were hardly any tools that were referenceable.