 So anyway, welcome to Network Nightmare, um, ruling the nightlife between Shutdown and Boot with PixieSploit. I want to take a few minutes, tell you a little bit about myself because most of you probably haven't heard any of my, uh, talks, the other one that I gave once, um, or, um, might not be familiar with me. I've done a lot of development with the Metasploit framework, um, I wrote the new GUI, um, I wrote some, a bunch of different exploits, payloads, um, post exploitation features, stuff like that. I also go by ScriptJunkie, so if you see tools or something like that, uh, that's probably me. Um, I do have a Twitter which, I don't use a whole lot, but you know, there's, there's a lot of peer pressure, I might start using that one more. And, um, you can find my website at ScriptJunkie.us, I run a blog, try to keep that, um, dealing with security research, stuff like that. And, um, if you want to contact me, you can go ahead and do that at ScriptJunkie, look at your keyboard, ScriptJunkie.us. So, first of all, let me give you a brief overview of what this talk is about. So, this is designed with the scenario in mind that you have access to a network somehow. Maybe you've gone and you know, plugged your computer into the network, or maybe you've compromised a system in the LAN, um, you got somebody to go click okay on your signed applet, or exploit their browser, or PDF, or however you did that, and what you need to do is you need to escalate privileges to root, you need to go compromise other systems on the network to get what you want to get. Um, they may be different operating systems, they may be, um, harder. Currently, you may do a lot with, uh, abusing legitimate credentials, so maybe you've gotten credentials from whatever key loggers, or maybe you could escalate privileges and dump hashes. Um, that's an option, but if that isn't working out for you, what you've got to do is you've got to go ahead and somehow use another method to take over this other system. So, you might think that, well, now I'm going to, it's going to come down to, I've got to exploit some service on the other system, but that can be really tough. Um, you might be able to pull off a web service exploitation, but, um, you might have to do, you know, real man's hacking, and go ahead and start fuzzing, do, or do static analysis to try to identify vulnerabilities in some, deeming that, you know, they have running, and, um, try to come up with an exploit for those, and then you're still stuck, because they may have exploit mitigation technologies like DAPASLR, which you've got to try to come up with a way to bypass. And even if you can do that, finally you've got your, uh, session, and you're still running as some limited network service, and you still have to escalate privileges. So, um, it can be a lot of work, and a lot of people don't do that. Well, what if this is, you know, what if there's an easier way, and that's what this is about, since, uh, this talk is really for the lazy hackers, since I know you guys out there are, are pretty lazy. And so the idea here is, why don't we run an offline attack? And so with offline attack, you're probably thinking, um, you know, I'm going to walk up to the system, unplug the hard drive, plug it in my external reader, go read whatever data I want off, or drop whatever I want onto the disk, and it's going to be simple as pie. Um, that's kind of like a variant, another variant would be the evil maid attack. If you're not familiar with the evil maid attack, this is basically how it works. Um, I know a lot of you probably have laptops that you left in your hotel room. I actually paid the hotel maid to go over to each of your rooms, and go plug a USB drive into your laptop, so when you come back, I'm going to have a shell on all your systems. That's basically how that one works. Alright, the other, the other type of offline attack would be, um, you could, uh, from the crypto world, they'd say this would be, uh, rubber hose crypt analysis, and XKCD has illustrated that beautifully for us here. Um, you go ahead and get credentials via, uh, brute force of another kind. So, so there's, there's lots of good ways that you can go ahead and run these offline attacks. There are some problems with them though. Usually you will need physical access to the system, and if, you know, if you happen to be nearby, that's okay, but if you're trying to do a pen test on a company on the other side of the city, state, nation, world, um, that's not going to work, work out. Also, you're very likely to get caught, and since you're actually there, um, by caught it doesn't mean they know your IP address. It means you're in handcuffs. So that's also something that you want to avoid. Um, because jail is not a fun place. It's a place with bars, not a charute. It's, it's very bad. You don't want to be stuck there. Having said that, uh, physical access attacks are still common, not the rubber hose crypt analysis type, but the pen tester walks into a building and goes ahead and plugs in his phone plug or whatever and goes ahead and gets access. So it is still an option. Well that brings us to, uh, the focal point of this talk, which is the, uh, pre-boot execution environment, which is going to provide us with a way of going ahead and taking over lots of other systems on, on a land that we have access to. Um, a couple, a couple of things. This is not a, uh, new vulnerability. This is a protocol insecurity, and it has been around forever. Um, what I'm presenting here is really, uh, new way of exploiting that. I've not seen a lot of security talk on a subject. Um, so let me tell you a little bit about PXE. Intel and, uh, SystemSoft introduced this a long time ago. Um, it's a protocol they produce firmware, which is loaded into most BIOSes to boot from, uh, the network interface card if you have network booting enabled. And since this runs from the BIOS, um, it will provide you with full system control. You can go ahead and, um, run code straight on the processor, access a hard drive, access a hardware, do whatever else you want. Totally bypasses anything on the hard drive, um, if you're booting from the network since the hard drive has never touched, you know, any operating system, any virus, firewalls, all that kind of stuff. The other good part about this is it works no matter what operating system you have. You don't have to, uh, really find out a lot about this system. You can just use, uh, the PXE specification itself which gives you enough to work with. Um, and best of all, it works over the network. So you do not have to be physically at this system to, to run this attack. So, uh, put it, bring it down to, uh, layman's terms. How it works is, you turn off your computer, you know, whatever you do, I know a lot of you have, have a lot of attachment to your computer so you tuck it in at night and, you know, sing it a lullaby, whatever you do. And it, it goes down and then, uh, before, before the operating system boots, when, when that boots up, uh, it notices something, something's a little bit different. Something's a little bit wrong. You might have something that you, uh, didn't really expect there. So, uh, you, you didn't really want this to happen to you. So, makes a good attack though. So the question is, uh, all right, this sounds like a, a cool idea. How, how likely am I to see this? And from what I've seen, I, I'm not aware of any widespread, um, surveys or other measures which tell you how often this thing is available, but just about every system bios that I've seen is capable of booting off the network. And I have seen it left on, um, in this case, uh, what, what I'm talking about is the network boot is set in, it's enabled and set in a higher place in the boot order than the hard drive. What normally happens is, um, the PXE, the system boots, it searches for a PXE server, after a few seconds, times out, gives up and then does a normal hard drive boot. So, I, I'm not saying you're actually using PXE all the time to actually boot, um, it's just left on. And like I said, I've seen that. I've also seen it, um, occasionally enabled when admins, they'll go around, enable this and then use it to, let's say, push out an image and, um, then, then turn it off. Or I've seen it just left off all the time. So, it, it definitely may be something that you encounter. And so, okay, Intel has gone ahead and put this horrible bios level back door into all of our systems. How could they possibly do this to us? Well, my guess at the top is admin reasons for why this would be enabled in an environment would be, um, image deployment would be number one. Um, it's, this is where I've seen it most commonly used, um, just to go ahead and push out images. Um, in a similar vein, this could also be used for system restoration. You know, every time the system boots, it gets a clean image and it's ready to go. Or maybe it's enabled just in case we do want to push out images or do something like this and we just leave it there because it's another feature that we don't have to worry about running around all of our systems to turn back on. Or my favorite PXE, what, what's that? I, I don't know. Alright, so how does PXE work? Um, it follows, um, an extension of DHCP and TFTP protocols. What's going to happen is in the DHCP Discover, the first pack that's going to be sent out, um, on port 67, it's going to have an additional field and option which specifies this is a PXE request. The DHCP server, if it supports that, is going to send back a response saying, here's your IP and here are some PXE specific options saying, yes, um, I've got it. Um, I have a PXE server for you to boot from. Um, and normally it will include a server IP and a file name. So, um, the client will not have to go ahead and do this part. Um, although it can make another request to get the file name. And then what happens is it makes a TFTP download, um, from the TFTP server specified, which, uh, with the file name that was specified downloads that, um, and goes ahead and runs it. That will be the network bootstrap program. It will be, um, loaded up at address 0x7C00 and executed in real mode. So, this gives us a couple difficulties. You might be thinking, awesome, I'll just plug my shell code in and let it fire. Um, but you'll, you'll run into some problems. First of all, it's passive. So, you're going to have to wait for a system to boot to use this. Um, however, in some cases you may be able to send out a wakeonLand packet and make it boot or use a denial of service exploit and make it reboot. Something like that. So, that's not a big issue but, uh, there might be some waiting involved. Um, the, the main big issue or, or one of the, one of the big issues you're going to have, is you're going to have to beat the real DHCP server. So, when it sends out its request, you're going to have to send out your request, um, and, and beat it. Now, for some reason DHCP server is like taking in your IP and saving it to a log file and updating Active Directory and saying hi to the neighbor's dog and all this other stuff. So, I have not found this a difficult race condition to beat but it is something you'll have to take advantage of. At that point you're going to have to, for the forwarding to TFTP part, uh, you will have to have a TFTP server available. This is not a huge deal but once again it's another thing that you're going to have to have and then you'll be executing code. And this is the biggest difficulty hands down. You're going to be executing code basically on the bare metal in real mode. Um, now, you know, some of you is probably, probably like a third of you are thinking, I don't know what real mode is but it sounds terrible and you're right. And, and the other, the other majority of you, or, or most of the rest of you are thinking, I know what real mode is and that sounds terrible and you're right. And so, so there's a very small portion of you who are probably sitting out in the corner somewhere who are thinking, awesome, I love writing bootloaders. I'm going to break out my assembler and start coding up in 1AH instructions and go ahead and own this thing. This is going to be great. Like I said, this talk is for the lazy hackers so we'll, we'll get your head examined later. And, and even if you do want to code up one of these, um, the, the serious issue there is if you want to interact with one particular operating system, you can, without too much difficulty, read a file off NTFS. But then if you want to change something, you may not be able to write that without having a whole lot of drivers. You may not be able to access the whole hard drive. You may not support all the other file systems you want to encounter, etc., etc. So, so that's not something I did. This is a helpful diagram from the PXE specification of what that network bootstrap program is going to need to do. And no, it's not fun. Thankfully, however, there are admin tools which have already been created which can help us do this. Um, the, the problem with that is most of them are not written to be attack tools. Like I said, the biggest use that I've seen is with using PXE as imaging systems. So, um, there are, there are those tools and then there's also PXE Linux. So first of all, imaging systems. Now, imaging systems, you will need these software installed and it does take a lot of time and none of that really matters because this is how imaging works. We're going to take your hard drive and we're going to overwrite it with whatever our image is. So, if you're trying to extract data from a system, if you're trying to compromise a, you know, system and go ahead and pull anything useful off of it, um, if you're trying to, uh, think of it this way, if you're trying to get information from Hiroshima, this is not a good tool. This will not get you the information that you want. This will do this. This is bad. If you're a pentester, your clients will sue you. So don't do that. So that leaves us, uh, with PXE Linux, which is really an awesome tool. Now PXE Linux is a Linux bootloader kind of like ISO Linux or SysLinux to Budaphe, CD or hard drive. And what it will do for us is it will read in a configuration file. Uh, we can have lots of different options, but basically what it's going to do is it's going to pull up a kernel and an NIDRD, which is an initial RAM disk, um, which will be basically an initial file system in memory. I'm going to go ahead and execute whatever program specified there. And, um, so, so that, that is convenient. Now, having said that, although it is nice, it does entail some difficulty. So like I said, we're once again, manually going to have to install all these servers, configure DHCP to forward this to us. Um, and this is, this is difficult to deploy. Most likely we're going to be in the case, um, where we're maybe not sitting with physical access to the LAN, and maybe we've compromised one system there. This, uh, is difficult in and of itself to deploy remotely. Also, uh, the PXE bootable systems that, um, are generally available out there, aren't really written as attack tools, aren't really easy to drop payloads into, and do things like that. Um, however, you can go ahead and, uh, use this for online control. So what online control is, is we're going to take a PXE bootable system on their different Linux live CDs which can be PXE booted. Um, DSL, Tinycore and Nopix are one of those. DSL and Tinycore, um, are really awesome because they're some of the only Linux distributions I know of that can fit entirely within an NNRD. Um, so you won't need anything other than PXE Linux to boot those. Nopix, um, can boot and then connect back via NFS. Um, that will entail some difficulties, uh, which I'll talk about later, but I just stuck with Tinycore because it's fast and small and all self- contained. So this is basically what you're going to do. You're going to take the live CD, remaster it, um, set up some scripts there so that when you boot it via PXE the scripts will auto-run, connect back, and you'll get a shell. So, let's try this out. Let's start this. Alright, so in this case, uh, what I'm doing is I'm starting with a backtrack image and a Tinycore ISO. What you're going to do is you're going to create a folder to extract the ISO into. You're going to create a folder, um, to serve your PXE files from, this is going to be your TFTP server folder, and that's going to have your PXE Linux kernel in it RD and configuration file in it. And then you're going to create a folder in it RD, which you're going to extract the in it RD into, add your scripts, package it back up, and it'll be ready to go. So first thing we do is extract the ISO. Um, I'm making this video available so if you want you can see all the steps necessary to go ahead and do this yourself. Um, as you see in the ISO all we have is ISO Linux, which is a bootloader BZ image, which is a kernel and tinycore.gz, which is the in it RD. And we're going to take the kernel and in it RD, drop it into our PXE folder. And then what we're going to do is we're going to use, uh, the meta-sploit, uh, PXE-sploit server. Um, in this case we're not going to jump right into everything that that has with it. We're just going to use this as an easy to set up, uh, DHCP and TFTP server. And, um, in this case update one is, uh, PXE Linux. Update two is a configuration file. Update three will be the kernel and update four will be the in it RD. So all we have to do is paste those files in here, rename our files to match the meta-sploit names of update four and update three. And then we'll just tell meta-sploit to use our images instead of the, uh, PXE-sploit attack, um, images that it has with it. So at this point, uh, we have, we have tiny core set up to boot from, uh, PXE Linux but we haven't added our script. So what we're going to do is we're going to extract the file system. It is a GZIPT CPIO archive. So thankfully GZIP and CPIO are included with most Linux distributions. As you can see here we've extracted it. It's a typical Linux file system structure. We're going to pick, uh, a script which runs on boot. You could pick any script you want. I just picked one in etsyinit.d and we're going to go ahead and add our shell here right up at the top. Now one concern is when this is run, uh, the network interface might not be up. So we're going to put this in a loop, um, wait a few seconds, in this case 10 seconds. Then we're going to, uh, give ourselves an IP address with ifconfig and then we're going to send ourselves a shell back with netcap. And the IP of the system, this back check system that we're running off of is 101 and, uh, so it'll connect back. And then we'll finish that in a loop and put an ampersand at the end. That's very important because if you don't do this then the init scripts will never run and your system will never boot and you'll be stuck. So we go ahead and save that out. Now we've modified our RAM disk. We're going to pack it back up or we'll use find to send a list of files to cpil, which will go ahead and compress the, or package up the, um, initrd, gzip it and send it back over our file. Now at this point we have all our files ready for, um, the connect back. I started in rpc so I can just fire up the GUI and, uh, that will connect for us. And when that loads, my computer is not very fast. Metasploit comes up. So what we use is the pixysploit auxiliary server. And, uh, there are lots of options we could give it. Most of those will be automatically figured out. It'll figure out your IP, uh, pick a range to start from. The only thing we're going to change is the tftp root so that it serves up our files and then that'll start the tftp and dhcp servers. So at this point we are almost ready to go. What we're going to do is we're going to set up a handler. Uh, we could do this in metasploit but I just did it in a netcat for the connect back shell. And wait for our target system to boot. If you have the mac address you could send a wakeonlamp packet now and get it to boot. So it boots, um, searches for a pxc server. Um, that goes ahead and boots. I'm going to queue up a command to be executed when I get a shell back. It loads the kernel, it loads the nrd and when that happens in just a second, the system will start booting. It starts detecting the hardware. Um, it'll be a few seconds until it is able to access the network card. As you can see tinycora has started and we are waiting for the connect back. And the shell comes back and we've just popped it. As you can see we're running as root. Um, online control live. Um, you can see our file system. At this point what we'll probably want to do is look at the hard drives which are available. Go ahead and mount them. In this case there are a couple of partitions. And let's see what's in this system that we just compromised. Sure enough, this is a fully patched Windows 7 64 bit system. And we have full control over it. And that only took five minutes from start to finish making the entire task. Alright that was fun. So there's some good advantages of online control. First of all, any operating system. We ran entirely from memory. Um, this could have been a Linux system, this could have been a Mac system, it could have been, I don't know does Mac have network boot? But um, it could have been any system. And we have the flexibility to put whatever we want on it, decide what we want to do with it. And we don't have to go ahead and code the whole attack beforehand. Um, now this does have some serious problems. And the first and biggest problem is um, in drivers. When I tried this um, before what I found was only about half the systems I tried, the drivers would work out of the box. What happens is even if uh, in Linux somewhere there's a driver for your car and you might be thinking well Linux has drivers for just about everything. And it does. But that may not be packaged into this tiny, a NITRD that we're sending over to the client. So um, what I found was the connect back was not very reliable. And if you don't get the connect back this gets you um absolutely nothing. The other big problem with this is the fact that when a system is booting, chances are someone just pushed the power button and they're waiting for it to boot up. So while you can disable the X server and make the screen blank or you know show whatever you want to show, the fact is the system is not booting and eventually they're going to get tired and they're going to push the power button and you're going to lose your shell and you're going to be stuck. Um, also with visual indications um, in this case you know a tiny course screen came up and they're going to know something's bad and that's when they go ahead and call the security guys and um, we fail. So there's uh, another way um, that would be with offline code injection. And the fact is we might as well go ahead and code it up because really we're going to do it anyway. Without offline code injection that is dropping our code to be run on boots that we can run as admin or root inside the system as opposed to root outside the system. Um, we're going to need to do that cause say we have to, you know, we'll want to listen for key logs. We're going to have to watch somebody log into something, maybe take a domain admins hash or something like that. There's, there's all kinds of stuff that we're going to want to do that we can't do um, from outside the system. We'll want to be running inside. So on Linux this is not difficult. Um, what we can do is we can take our shell code, we can write it to um, and one of those scripts in etsyinit.d or drop it in a bashrc or any of the other million at bashrc files or we could add a user. Let's say the system has SSH enabled. We can just drop something in etsy password or even add an entry to the authorized SSH keys and we will be ready to roll. In Windows, uh, we have, we have some difficulties which I'll talk about later but I came with a list of seven different ways that you can go ahead and do conjection offline. So that's with bootkits, we can do it with binary planting, with binary swapping, uh, with binary embedding or modification, dll preloading, registry edits or a combination of the above. Now at this point maybe you're thinking ooh but I have bitlocker, true crypt, whatever, um, you can't get me and there, you could use bootkit techniques, um, might be able to bypass some of that stuff but, um, that's not the research direction that I went in and it seemed like a lot of work so we're lazy hackers. Moving on, uh, bootkits, there's a lot of different bootkits which are available. PXE is kind of an ideal way to deliver bootkits because even if you can't, uh, read write certain hardest sectors from within let's say, uh, Vista 764, uh, with a bootkit you don't, you don't have any issue with that with PXE. So there's lots of different bootkits which have been released or been made available or out in the wild or they're on your laptops right now because they may just put them on there. Um, and so, uh, Cinewall is one of them, uh, Stone is another one that was released at Black Hat a couple years ago, uh, Whistler is one TDL, also known as Allureon, also known as TDSS, also known as Just Stop Giving It Names. Um, EI Boot Root is one that was deployed, this is kind of the motivation here, uh, they deployed it with a virus they called the PXE virus, this is as far as I can tell one of the only instances where PXE was used as an attack vector. So they are available and they have some cool features, they have some cool advantages. Um, so first of all you get extra points for skills because it's, uh, it's pretty cool to be able to run a bootkit and get yourself bootkit privileges, you can, um, also end up running stealthily inside this system and it gives you full access. So those are all awesome, awesome things. There are some disadvantages with that, however, uh, bootkits are very operating system specific and if you don't have the right architecture, the right, um, the operating system support, this isn't going to work, so it's going to take a lot of effort to try to maintain that. Also if you're, if you're spawning a rootkit with this, what happens a lot of times is Microsoft will update patch guard, which will then crash your system and, um, that's happened to a lot of the bootkits here, so it takes a lot of work and like I said, we're all lazy heckers so that seems like some difficulty. Uh, one, one illustration for this, the stone bootkit was presented like I said a couple years ago in 2009 with great fanfare that, I don't know if the author's here, but he said, um, he expected this to be the number one bootkit used in 2010 and yet by February 2011, uh, he had released a statement on his website saying stone is out of date, um, go find other projects, it's not going to work, so, um, awesome, awesome projects but not what we're going to run with here. Now an easy way would be with binary planting, so you might be thinking just drop a file in the startup folder and that's right, uh, here are the startup folders for various versions of Windows, so we can just drop our executable in there, um, and that will go ahead and run when somebody logs in. The issue with that is whoever's logging in might not be privileged and we might be stuck with where we likely started, which is just another, uh, user level shell and, um, that doesn't give us the privileges to do what we want, you know, dump our hashes, go on, do whatever else. So we could use the WBEM dot MOF method, which was used by Stuxnet. Um, the problem with that is, um, and Metasploit does have a mix in to do this, um, it's implemented, you can use this as an option in PS exec Metasploit, um, but, uh, it's not compatible with Vista and later, so that's probably not your best bet. Another option would be swapping out binaries, so you take a core system process, which you know is going to run on boot, like services, service host, Wininit, um, CSRSS, uh, and LSAS, any of the core Windows processes which you know are going to run on boot and you put your own executable there, move it to dot back dot exe file or something, and then when Windows boots, it will run your executable, your executable spawns off the real executable and runs whatever payload you have, and then you go ahead and exit out and use, you know, a DLL or other processor or something to swap the executable back. Um, I've tried this, it works awesome, at least on my XP system, it's guaranteed remote code execution, you don't have to wait for a login, it runs you with full privileges, and it's portable, it runs on, uh, you know, different versions of Windows, it's awesome, there's one problem with that, it's kind of a big problem. A lot of these early boot processes are, uh, monitored by the operating system or other boot processes, and if one of them exits, it's going to cause a blue screen, because it knows, oh no, the core component of the system crashed, even if the equivalent process is still running, it's still gonna, uh, throw a blue screen. However, to clean up after yourself and swap the original executable back where it belongs, you will need to exit your running executable. So there's not really any good way you can run around blue screen in the system, unless you leave the system in a perpetually, uh, broken state, um, well it's not really broken, but it's not, it's not going to do what you want it to. Um, so you could move to one of the later boot services, uh, like the principal or spoolsv.exe. Now, these are useful because, um, they're non-critical, so the principal doesn't have to run, it won't blue screen if it exits, um, but the problem with that is, it doesn't have to be enabled. They might have the principal or disabled if this is, you know, maybe a core server or something like that. So it's, it's not as reliable as I would like, but it's still definitely an option for attacking work stations. So that brings us to binary embedding or modification. So one thing you can do is you can take, um, your shellcode and add a new section to the exe, embed it into one of these core boot processes, and then it will run. So, um, I wrote some code in my display, you can go ahead and do that with MSF encoder, MSF Venom now, which is the, the new version. There are some problems with that. Um, you can't straight up do this, because if you have your x86 shellcode and you go ahead and drop that into your x64 process, you will get a crash, which will then give you a blue screen, which will then get you sued. Or, and, uh, the other problem is you might not have one issue. And the big issue is, of course, cleanup. If you still want to clean up after yourself, you still have all the same problems with trying to clean up. So then you might say, okay, well I'll just use DLL preloading. So I'll just take a system DLL, which I know is going to be loaded up, swap it with my own, that will have my shellcode in it, that will do whatever I want it to, um, or maybe I could load it higher in the search list, but the other problem is with the imports, um, this DLL is probably going to be loaded because it's probably going to be used, and you will have to emulate or somehow proxy the DLL calls which are made to that DLL. So this, because it's changes in different versions of Windows, I didn't want to, um, go ahead and mess with the difficulties inherent with that, but this is still an option and it is still available. So you might say, well I'll just put myself in the registry. Well there's the run keys in, um, Microsoft Windows current version in HKLMRCU, and that's reliable. Your executable will get executed. Um, the problem is this is basically the equivalent of a startup folder. It's going to be running as the user. Or you might say, okay, I know I can add a service. Just, um, add something in current version, or a login. Um, there are some differences in the sub keys, um, which, which you have to implement, or the values which you have to implement, but that's a great option. Or, uh, another thing that you could do to work around that difficulty is to edit a service. So you change the bin path to a service that you know is running. You change the start and type to make sure that it runs, and this will work on, you know, different architectures, all different Windows versions. Um, and it is a really, really great idea. Or you could add it to a list of known DLLs, and it will also get run privileged. So there, there are a number of different items that you can use to make this modification. There is one problem with this, however. We are running a Linux image from a Linux in NRD. In order to make registry edits, I'm going to have to use, uh, the library, which if you add a string, and it causes Hive expansion, will give you a warning that this could lead to Hive corruption. Now, if you know about corruption, and you can ask my buddy Blagojevich here, corruption is not something you want to be caught doing. It will land you in jail or sued, which, like we've explained, is not a place you want to be in. So, um, this, this is probably reliable. It will probably work just fine. But on the off chance, uh, that it does cause some serious problems, um, it's not something that maybe you want to do as a pentester. So instead, uh, what I did was a combination of binary swapping and registry editing. So what I did was I swapped a non-essential service, in this case I picked the print spooler, swapped out spoolSV for another executable, and then edited the d-word start key in the registry, which changed the registry size. It's a very simple edit. We'll not give you angry warnings, and we'll make sure that this thing gets run on boot, privileged, reliably, in any version of Windows. So now we are cooking with gas. And, uh, one last part of this is the pivoting part. Um, prior to a couple days ago, uh, the only thing that was available was you still had to install Metasploit, or install TFTP and DHCP servers. Um, what I was able to do was, uh, enable this for pivoting. So what this lets you do is, uh, tackle the systems on a land where you have one system, and this will be run in memory via the interpreter. So there's a couple of different ways you could do this. One would be writing script using, uh, API calls, or the rail gun is one way of doing that. Let's you make arbitrary Windows API calls from the interpreter. Um, or you could do it as a compiled extension. Um, communication, um, over-interpretor happens over packets called TLV packets have type length value. Um, I-I used an extension, uh, so what it was, was an embedded DLL, which then pulls up a reflective loader, basically loads itself in memory without touching the hard disk and then goes ahead and makes the method calls necessary. Um, the-the reason that I didn't do this via a script or a rail gun, which would have been easier, was, uh, a base condition. So you can do this without a custom extension. You know, wait for a DHCP request. The problem is the interpreter would have to then encrypt that, send that to your controlling system, which could be on the other side of the country, which would generate a response, encrypt that, send it, interpreter would get it, decrypt it, send out the response. But at that point, you've probably lost the, uh, race. So I, uh, re-wrote it in C++, um, it's now compiled and happens all on the interpreter and, um, the controlling system will just load that all in memory and, um, it'll be ready to go. So once again, here's our attack recap. Uh, we're gonna go ahead and dynamically generate our payload if we want. Um, the system boots, uh, we could trigger that with Awake on LAN. Um, as for DHCP, DHCP acts, sends it to, uh, TFTP server, which goes ahead, downloads the pixie linux image. That pulls down the configuration file, the kernel and NRD loads it, it reads the hard disk, swaps the binary, edits the registry to make sure it'll be run, then it'll reboot to the operating system. At this point, the pixie, the attack pixie server will not re-serve that client because it wants it to time out and boot from the hard disk, um, rather than try to re-infect it continually. So then, when that boots, the swap DXC will be running inside the system, it'll spawn a real payload, and then clean up after itself. So, let's see how this works. So, what I'm gonna do is I'm just gonna start with Metasploit, I started a handler, in this case, on the foreign LAN, I have a Windows 7 system, I left a thumb drive line around with a shortcut in it. Shortcuts can run whatever, uh, command you want. This particular one will run a VBScript downloady val, which will drop a Metasploit binary. And in comes our interpreter, Shell. So, I now have, uh, Shell running in the interpreter, as you can see, um, um, it's running live here on the system. From the foreign network, what I'm gonna do is I'm gonna run the PixiSploit extension. It's going to load up the extension, load up the four files necessary to serve, and it's gonna issue the commands to start the TFTP and DHCP servers. And we can go ahead and see this in that stat, make sure so you can see they're running on this system. Um, we can set advanced options for which IP to serve back, file name, stuff like that, but we don't really need to. At this point, we have our target system, which is a server, Ubuntu server, um, which has desktop loaded because it's nice. As you can see, there are only a couple of accounts there. It's going to reboot. It's on the same LAN as the Windows 7 server. It's going to pull off the PixiSploit attack real fast, and um, that's gonna give a short message and reboot. That was the, uh, dropped attack, so if you blinked for those, you know, two seconds, it's very easy to miss. Now, it's going to reboot. Again, request a Pixi, uh, server, which is not going to be served, so it'll have to fall back, boot to the hard disk. And at this point, we wait for Ubuntu to load. At least we're not waiting for Windows to load. And... in a few minutes here, that will start up. So we could do this over SSH, but just for the good. What we're gonna do is we're gonna put in Metasploit. If you remember, there was no username for Metasploit. We're gonna put in a password of Metasploit, and sure enough, we are going to log in. Open up Terminal, and sure enough, that's pound sign. We are, uh, running as root. So we have, we added a new UID0 user, and we have now taken full root control of our fully patched Ubuntu system. So at this point, uh, there's probably some of you who are, uh, sysads who are working on the other side of the fence, right? Just great. Look what you did to me. But don't, don't worry yet, because there is, uh, plenty of advice out there. Lots of people willing to help. I'm sure there's lots of people at Symantec who are very intelligent. Um, whoever wrote this article, this may be not one of them. Um, so there's lots of bad advice out there on how to secure PXE. So some of the suggestions which are put forth in the, uh, mitigating risks of PXE are, uh, IP reservations, which is a change on the server side. To be honest, most of these are just changes on the server side. If you remember our typical attack scenario, um, I'm beating your server, so it really doesn't matter what your server's configuration settings are. Um, any change on the server side is not going to make a difference. IP reservations, what that does is that, uh, sets make sure that your machines are always given specific IP addresses. This probably won't help at all. NAC is, um, another option. Well, NAC will probably prevent you from accidentally plugging in something that you didn't want to, but I really haven't seen that as a, uh, big difficulty to a pentester who's got physical access to your switch to plug into. And from the remote attack scenario, where I have a shell running on systems, um, this doesn't do anything. So NAC is also probably unlikely to get you to any, uh, any success here. Pixie force mode is another curious suggestion. This is a change on the server as well. Um, assign specific clients to specific PXC servers. Won't do anything against our attack. And BIOS passwords, um, again won't do anything to our attack. That would only affect someone who's trying to use PXC to compromise a system they have physical access to. And they're trying to manually enable PXC to boot from. I'm curious as to, you know, what attack model has somebody who has, uh, has a computer in their possession and thinks, wow, I'm going to take an ethernet cable, plug it in the back, take my computer, set up a DHCP and TFTP server, configure those to serve PXC and use that to compromise the system, which I'm right here except, oh no, there's a BIOS password, I'm, I'm hoes. So, so, anyway, those, those are advice there, so, so that's one way to fail. Now, you can fail less, um, by at least having something available out there to detect rogue DHCP servers. So you could have, uh, software monitoring, uh, scanning for them or listening for duplicate replies to, uh, requests which are sent out there. Um, there is a possibility someone could use art poisoning to pull off this attack. That would be difficult because you can't art poison them beforehand, you'd have to do it right as they were booting, um, but that is something, you know, another thing that you could check for on the detection side, um, and unregistered clients, um, if somebody was using the plug into the switch, um, style attack, that's, that's one thing. At least hopefully you, you have some, uh, mechanism of detecting anomalies on your network like this. Um, a good idea would be with firewalls or, for example, access control lists on your, uh, Cisco switch to only allow DHCP traffic, um, to and from your server, so not allowing DHCP servers somewhere else. That will be, um, a very good idea for, for protecting this. Now, if you do it based on IP, you might have to watch for art poisoning, but you'll be in, you'll be in a pretty good shape, so, so that's a good idea. A very good idea would be VLAN isolation. Um, if you can, go ahead and isolate, um, all your systems are as many as possible on individual VLANs, so one system can't go ahead and pull off, you know, this isn't the only layer 2 attack of, of course there's art poison routing and all the other kind of stuff that could be done. VLAN isolation would also stop this attack. Um, then you'd forward DHCP traffic somewhere else. A very good idea, and, um, part of the spec that was actually made for security, if I can talk today, was the boot integrity services. So this is an extension to PXE which only runs signed code. So what you'll have to do is you'll have to run around to all of your motherboards and put in a certificate into their boot integrity services. And then you can use PXE and nobody else will be able to, um, will be able to have their network bootstrap program executed unless they have signed it with your private key. So that is a very good and effective way. The problem is it's not necessarily available in a lot of firmware and it's a lot of work to run around and go ahead and pull this out. But if you can pull that off, that is probably the best idea to have, um, PXE running. And the overall best idea goes to turn it off. And with that, um, we might have a couple minutes for questions, um, but in a second, I will let the next speaker start getting set up. Um, if you want to come to the Q&A room for track number one, um, I will be over there for the next probably hour until people stop asking questions. So, um, you can go ahead and find me there.