>> This is Brady and I guess he's going to talk to you about how I guess Windows likes to have fun with itself. All right. ?	>> [Applause]. ?	>> All right, I guess you guys are a little too excited to watch Windows play with itself. We'll be covering some really interesting stuff today.  First off, I guess a little bit about myself. I started out in the Government space doing a lot of cool stuff there. Like most of you, I'm passionate about security, been doing it ever since I was old enough to get into trouble for it. If any of you have heard of the POS Project, I started that project and currently I'm a founder and principle security consultant at Simon Briggs Security. So throughout this you will see a lot of the techniques and tools that we have developed in conducting penetration tests.  So before we enter the danger zone for you Archer fans out there, I wanted to give you a little bit of background as to what motivated this talk.  Ok. So back when I was in the Government space, I remember talking to some friends in the private sector and they were telling me about some of the difficulties they had and the differences between what a penetration test was and what an actual attack was, or what they were actually trying to defend against, right?  So, you know, fast forward, that was about three or four years ago, fast forward from that point a couple years and that ended up being one of the motivating factors to starting Simon Briggs Security, was to shorten that gap and to combine what an actual attack is with what a penetration test should model after. So that's typically, you know, that's typically the methoDLLogy that we use when conducting penetration tests. So there's still very few covert persistance tools on the market. Right?  A lot of us use Metasploit and I'm a big fan of Meatsploit. I'm definatley not going to badmouth it because I think it's an awesome project. But I think it is important to reduce the reliance that we have on Metasploit. And there's other great projects that do this as well, right. Such as Veil, Veil does it. Cobalt Strike is another great project that does it as well. So anything that we can do to, you know, customize and model assesments and penetration tests after what organizations are actually defending against, I think is a good thing.  So throughout my talk, you will see some of the techniques and the tools that are being released will hopefully help you in doing that. We have a lot to cover.  We're going to first talk a little bit about DLL injection, a new technique for that. A new, actually a few new techniques for persistence, stealthy persistence in a Windows environment. We're going to release throwback and I'll give you some demonstrations with that along with lots of other demos along the way.  So I'm really hoping the demo Gods will be kind to me tonight. So first off, for DLL injection -- ?	>> [Laughter]. ?	>> For DLL injection, you know, for those of us who have had to deal with the Windows API, that's often what it feels like, right?  It's kind of a black box.  It's definitely a black box. Three out of the four APIs there are undocumented, right?  So a lot of the options that we have and we that have to deal with, we have to reverse engineer and look at Microsoft DLLs and try to figure out what Microsoft was thinking when they did things. The only documented one is create thread, but Microsoft is, you know, implemented quite a few restrictions around that with integrity level for processes and things like that.  I have never been able to get NE create thread to work very well. My favorite is RTL create user thread which works really well most of the time.  And then you know, at the bottom you have like NTQAPC thread which can blue screen certain OSs, I think particularly Windows server 2008. And then for the really elite stuff you can do like Code Caving which is also known as the Nebet Shuttle technique but it is extremely difficult to do on 64 bit windows.  So wouldn't it be nice to have another option, you know, besides one that is documented and three that have very little support by Microsoft?  So the new one that I found, it's called add monitor and it's actually a port monitor, it's used to install a port monitor for a printer. There are some advantages and disadvantages of it, but it's still an awesome technique.  It takes three parameters and it injects into it spool SV, you don't have the flexibility of choosing which process to inject into like you do with some of the other APIs. But on the positive side it doesn't require masion architecture, you know typically when you want to inject a 64 DLL you have to be coming from a 64 bit process, otherwise there's a little trickery involved.  So it's super easy to use and in a minute I'll show you the source code and we'll go through a demo, but it takes literally three parameters.  The last one there is the most important one, which is a monitor info 2 structure.  And, again, in a second you'll see what's contained within that. The biggest disadvantage in my mind is the DLL has to be on disk and it requires administrative privileges. So with that, let's check out the DLL injection demo. This one I recorded just because we have a lot of other cool stuff to cover, so --. Okay, so I can't see very well from here, hopefully you can see better than me, but you can see that the first, that the command line argument that we're passing is the name of the DLL we want to inject, right?  The part I just highlighted was the monitor info 2 structure which again has 3 parameters. One is generic name, the second one is just the architecture of the system and then, again, the third one is the DLL name that we are specifying to the command argument. You need the SE low driver privilege, which is, you know, you can easily obtain with admin privileges and the last one you know, you just call the function or the add monitor API with the necessary parameters.  So I guess to prove it's being injected in spool SVI, I wrote it up. Process explorer, there in the background, highlighting spool SV, so when we actually carry out the demo, you'll see that the DLL gets loaded into spool SV.  In this case, the DLL just a test DLL that I wrote. It will do a hash dump on the local system and then it will dump it to debug view.  So it's a pretty basic demo. But as soon as we run it, I'm going to drop back into Process Explorer here so you see the DLL, you should see a gree line up here showing that the DLL got loaded under spool SV. There's the green line so the DLL is running under spool SV right now, it just got loaded.  And now if we check out the debug view that DLL should have dumped out the local -- done a local hash dump.  And you can see it ran from the spool SV process.  So obviously in this case I choose a, you know, the DLL to do a hash dump. In your case, you know, it can basically do whatever you want it to do, whatever you design the DLL to do.  So that's the DLL injection technique. From there -- okay, so from there, I want to talk a little about persistence.  So first of all, there's lots of persistence mechanisms in Windows, but which one do you guys typically use?  Who uses a service, first of all?  Come on you liars, raise your hand.  You all know that you use the service, right?  If you have system privs, that's what you typically use, right, is a service. That what the ATP report by Manual, isn't that what it said? Like 75% of all attacks create installer service, according to my good friend Bryce [laughter]. We do have other options, right. There's run keys, there's SEH tabs, but wouldn't it be nice if we had another option, especially something as simple as dropping a DLL tab disk and creating and creating a registry key and have that be loaded on boot through a system level process. DLL is super stealthy and it, we can design the DLL to do whatever we want. So like I said, there's lots of techniques. The technique that I used to find this, I'm going to talk about three, you know, I don't think that the techniques that I use to find these are new. You know, definitely not, I just used process monitor and in this case, you know, you can see that on the left, I have process monitor, monitor specifically DM ware tools.  And then, you know, I just went through all the processes, had it monitor that process specifically for DLLs that were loaded and then start, well first of all, stop and restarted services one by one to see which DLLs got loaded.  You can see then kind of in the middle it says, name not found.  Well it tried loading the NTDSAPI.DLL [indiscernible] from the WBEN directory before it tried loading it from system 32, so there's a DLL hijacking vulnerability there. So if we drop a DLL into the WBEN folder named NTDSAPI ours will be loaded as that service on boot. So it's kind of a cool technique.  And that actually is one of the techniques that is I'm disclosing right now.  It's kind of a funny story that goes along with this though. The second technique that I had listed, actually I found those probably like three years ago, back when it was ESXI 4.0, 4.1, and I just kind of sat around and didn't do much with them and finally my DEF CON talk comes around and of course being a good hacker I wait until the last minute to actually start testing my stuff and I realize that in EXSI 5.5 they're actually both patched. So I'm pulling a Stewie running around not knowing what the heck to do because both of them get patched. But fortunately I spent a couple hours and found another one which is the NTDSAPI.DLL.  So literally all you have to do is drop that DLL into the WBEN folder within system 32 and it will get loaded at boot time by VEM ware tools service. So obviously the down side is VEM toos has to be installed.  So it's more useful on servers or in a virtual environment. However, we're going to go from good, better, to best.  And right now we're moving on to the best category, okay?  The best is this one. And this is to create persistence in Windows. All you need to do is create a new key at the registry key I specified and then a value within that key named driver and the value of the driver is just the DLL you want to get loaded. You drop the DLL into Windows systems 32 and at boot Windows will load that DLL within the spool SV or the print spooler service. The upside is you can create as many as you want. You want multiple DLL persistence, you create multiple keys each of them with the value of driver, each of them specifying the DLL at boot, you know, as many persistence or DLLs you want to run will be executed by the print spooler. So I think it's time for some demos.  That's enough of me talking. Let's move on to some fun stuff. Oh, wow! That is really big! I was waiting for that. Okay, all right, I think that's close enough, right?  Hopefully everything fits. I tried to resize the font and everything, so - I cannot even see that. Is that administrator?  Okay. I can see why most people don't extend the desktop. Okay. So we're going to -- first off, we'll do the first persistence which is the NTDSAPI.DLL. So that's in demo 2. And - okay, so all we have to do for this one, there's no registry modifications required. We just have to copy that test DLL to see Windows system 32 WBEN and then we'll name it NTDSAPI. Did I type that right?  Anybody see?  NTDSAPI.DLL okay?  All right, so one file is copied.  So that's it. There's no registry modifications necessary. What this DLL does is, it just, it's similar to the first DLL it shows what process loaded it and then dumps some information out to the debug view.  So we're going to reboot. Actually, I'll just type it because it's a little easier. So what I'm going to do is log in as fast as possible because, again, it's being loaded in the system so it doesn't wait for me to log in to execute the back door or the DLL. It's going to execute as soon as the service gets started.  I'm going to log in quick, start up the debug view, and we should see that DLL being executed. Okay, it should say something about what process or what data it's running from and where the DLL is located at. Is that what you are seeing, for those of you that can see it? Ok, so that's the first one, it again requires the VM ware tools are installed.  There are some requirement there, but if it is installed, you have a super stealthy persistence technique in Windows. So now we'll demo the second one. ?	>> Yay! [Applause]. ?	>> The second one, like I said, I think the second one is pretty awesome. It's super stealthy and the best part about them is when you can find logical vulnerabilities within Windows because those are a lot harder to patch.  So what we have here is we have the - there should just be an error message. I code named it error message.  So if we run that, it just take the DLL, like I said it must be in system 32, so we'll go ahead and copy test DLL to see Windows system 32 and we'll call it ErrorMess.DLL. I think I typed that right. So now if we just run Errormess and then just specify the DLL that is in system 32 and then test app that I wrote just asks if you want to load it now?  And we're just going to say no because we're going to reboot the box anyway. Then we shut down.  This is basically the same test DLL and when we reboot, we should have two persistence mechanisms on this box now. So the first persistence should be running out of the VM tools D.  The second persistence that we just installed should be running out spool SV.DXE both of which are system processes. So there's one and it looks like there's the other.  So they are both running as they should. One should be running from VM tools and the other should be running from spool SV. ?	>> [Applause]. ?	>> So -- ?	>> [Applause]. ?	>> So right there we have two, you know, pretty stealthy persistence techniques.  A lot stealthier anyway than installing a service, right, because a service creats all kinds of logs. It's kind of a dirty persistence technique, in my opinion, but it does work. Now let's talk a little bit more about Windows APIs.  I guess as a super quick prep course to throwback, we're going to distinguish between win HTTP and 1 Inet. Those are the two main libraries within Windows that Windows provides you when you want to write a back door.  So win http is intended primarily for services. Win Inet is for user space. So win Inet will automatically pull user settings, it will automatically do like the NTLM authentication.  Has anybody ever had problems getting out of a network that does NTLM authentication using an meterpreter?  ?	>> Yeah ?	>> [Laughter]. ?	>> Anybody else?  Okay, well, the reason why is because there's a certain flag that you have to set, it's called the Internet flag keep connection. And that flag will automatically tell win Inet to do NTLM authentication at the proxy. So something as complex as NTLM authentication, it can easily be enabled just by setting a flag within win Inet. ?	>> [Indiscernible]. ?	>> Oh, great! ?	>> [Laughter]. ?	>> [Applause]. ?	>> I don't - I actually, I don't drink, but I came prepared with Mountain Dew, so. ?	>> [Off mic] ?	>> Oh, okay. ?	>> [Laughter]. ?	>> You just stand there and look pretty. We've got it. ?	>> That's it?  That's all I get?  ?	>> That's all you get. ?	>> Oh, sorry, I'm not used to drinking. ?	>> [Laughter]. ?	>> We're not there yet. ?	>> On a special edition of shot the new, we have a new, in addition to our new speaker, congratulations. ?	>> [Applause]. ?	>> We also have a new attendee, Nikita. Everybody say hello to Nikita. It is very tough to get accepted at DEF CON. Congratulations. How about some love for our new speaker?  ?	>> [Applause]. ?	>> You're done, I've got this. ?	>> Okay. ?	>> [Laughter]. ?	>> I would have done this very differently. ?	>> [Laughter]. ?	>> In fact --. ?	>> [Off mic]. ?	>> There we go. All right.?	>> All right, wait a second, listen this is all crap.  I would have done it differently. You just take it. ?	>> [Laughter]. ?	>> I can't even be on stage with this anymore. ?	>> [Laughter]. ?	>> Who took my alcohol?  ?	>> I have it. ?	>> Okay. ?	>> [Laughter]. ?	>> Okay. Thanks, guys. That was fun! ?	>> [Laughter]. [Applause] ?	>> Okay, so we'll finish talking about the two different HTTPAPIs within Windows. As I was saying, the win Inet one is super easy to use.  Doing something as complex is as MT modification is as simple as adding the correct flag within the API column. It's important to understand the distinction because for throwback, we actually used win HTTP.  You know, based on when doing a penetration test, what's the first thing you want to do?  You get access to a user's work station and from there you want to escalate privileges and run from a service.  So in order to do that, that's why we decided to go the win http route because it's tailored more for services.  So the back door itself is written in C++.  The control panel and the LP portion are written in PHP with MILSQ back.  It was designed for stealth. Like I said, we're trying to converge the penetration test with what an actual attack looks like, so we want to build tools that support that methoDLLogy. So it has persistence built in, both as a DLL and as an EXE.  Here is a kind of a brief overview of how it works.  An attacker, you know, sends a spear fishing email, or you know, however you use your imagination to gain access and infect a user's work station with the throwback executable or the throwback DLL and gets going execution on their box.  Throwback then starts leaking out of their proxy firewall out to their throwback LP, which again is a PHP interface and it has a control panel that we can then send command and control and we can send commands back to the throwback door. You'll notice that there's 2 throwback LPs in this scenario, so you can have it round robin and randomly select one of how ever many LPs you want to configure throwback to call back to. If you want to set it up to ten, then it will randomly select one of the ten to call back to however often you tell it to call back. So here are some other features of throwback. A robust proxy detection. So remember I said that we used win HTTP. So win HTTP doesn't have the robust user proxy settings that win Inet has. So what we ended up doing to get around this was, because it does run from a service, you can impersonate users a lot easier.  So what did was we decided was to mount each user's NT user dot dat file, if it's not able to get out initially, it tries mounting the registry file, looks in their user settings for proxy settings within Internet Explorer and grabs those proxy settings and uses those to try to get out. And it does that for all users that have logged into the box for their proxy settings.  Like I said, you can also set it up to use distributed LPs.  So instead of calling back to the same LP every hour or 15 minutes, you can set it up to call 5 or 10 LPs and it decreases the traffic to each domain.  It also uses the MSGRPC interface to generate MSF payloads which we will be demoing in a minute as well.  It uses RC4 for encrypted communications.  So you can configure this HTTP or HTTPS. Either way the actual payload data is encryped using RC4. It also implements reflective DLL injection. We will be demoing that as well. Reflective DLL injection, you know, from a malware writing perspective is the coolest thing ever.  It just allows you to run other DLLs from memory.  So we will be demoing that as well.  Lastly, the string encryption.  So if someone does grab the binary and starts using reverse engineering on it, all of the strings within throwback, before you put, for example, any of the domains you want to call back to, you have to run it with a, you have to enter them into a python script that spits out an integer array that you then copy into the C file so the strings are not stored in clear text within the binary.  So a lot of you might look at this and say what's the difference between this and the meterpreter?  I don't think anybody would say meterpreter, and I again, I really like meterpreter, but it really doesn't have the best offset, right. So, when you type in meterpreter script it just randomly generates and executable on target. It randomly generates a service whereas this is designed more for stealth and it's not an interactive tool either. meterpreter is for interactive access, interactive shell on a target you have access to. So with that, it doesn't have as much functionality as meterpreter either. It's just more of a bare bones, back door that can provide stealthy persistence access within a network. ?	>> [Applause]. ?	>> We'll be seeing a demo of it. This is the interface, so remember I talked about how there's a control panel written in NPHP? This is how you control all of the different boxes that are calling back.  You can see in this case there are four calling back.  The first three are set back to call back every minute.  The last one is set to call back every ten minutes.  That's changeable. When a target call back you can say, hey, now I want you to call back every four hours.  If you are not going to be being interactive operations for a while, you can change that and modify it. So that's the interface. Again we'll be doing a demo, right now actually, on how to do it. And hopefully I don't feel like doing this to somebody at the end of it. Okay, so what I wanted to do is just kind of run through, you know, when doing an assessment the general flow of an assessment, right?  So here we have a cally VM and I'm going to pull this up here. Hopefully that's big enough so you can kind of see it.  I know I can't see it on that little monitor.  But we're going to be using the exploit. It's an old IE 10 exploit, but we have customized it for this particular version of IE 10 we'll be using.  And we creatively call it two girls, one sploit. ?	>> [Laughter]. ?	>> You know, the rest of the params are pretty basic.  Set it on port 80. It's an IE 10 exploit. The payload is a custom DLL inject payload.  And I think this payload is one of the most underrated payloads in Metasploit. It allows you to use a custom DLL as a payload within Metasploit.  So instead of relying on meterpreter and potentially getting flattened by AV, you can use a custom DLL inject payload and inject whatever DLL, custom DLL you want. So I suppose I probably should have started that up, but that's just within that resource file. So I'm going to start up the resource file there. So that's going to start up the exploit. Okay?  I have a lot of things going on here.  So this is interface. It is available on gethubnow. So we'll log in. You can see there's one box calling back.  It's just a test box.  You can see the last call back was yesterday when I was testing some stuff. So what we're going to do, like I said, is come into here.  The exploit, yep it started by now. So now, you know obviously, it doesn't matter how you deliver the payload, that's not what this is about. This is about, you know, using a custom - using throwback as a custom payload within metasploit. So - and I think that's that. Just slash into HPEXP so that should - so what that's going to do is exploit the browser, obviously. It's going to inject the custom DLL into memory. And so now if we pull this up, we should very shortly see a new box pop up because our DLL was just injected.  ?	>> [Applause]. ?	>> So from here we have another target, we can install persistence on it. At this point we're just a DLL running in memory because of the way that we delivered throwback. If you were to deliver it through macro attack as an executable, then it would automatically install itself, you know, as persistence. So you can do all sorts of stuff. You can run - create a process list, which I think is this second one. Nope, that's not it. Oh, that's actually change call back time, I believe, right?  Change call back time. So that one, actually that one is create task list, I think. I don't know what it is, but whatever it is, we'll run it. ?	>> [Laughter]. ?	>> So you can see we just queued it up, there's now a task waiting for throwback to execute. When it turns pink like that, that means it is currently executing it. So we can come in her and you can see it's picked up the task and then it should return the output from that task. Yep, it was a task list. ?	>> [Applause]. ?	>> So when we have access to a box, what do we want?  Do we want like, you know, do we want this - I mean, we want shells, right?  Isn't that what every wants?  We always want a shell. So one thing we decided to add, you can see it's calling back every minute.  So what we're going to do is, there's a functionality called met creator and what this does is this will generate a metasploit payload, an meterpreter payload and we're going to create a raw one. And let's do, I don't know what that is. I think that's the reverse HTTPEX86. ?	>> [Off mic]. ?	>> HTTPS. Sure, that works. Okay.  And then we're going to go back to our cally box. Let's see what IP this is. And we'll go ahead and kill this because we don't need that any more. What's the IP?  It's like 20.110?  ?	>> [Off mic]. ?	>> All right. Okay, so we'll come back - oh, not that. This. So we want the call back to be 22.168.20.1. I think I did that wrong. Is that right?  And port 443.  Okay, so now we're going to create the payload and what it's going to do is, it's going to use the MSG RPC interface within metasploit to create the shell code to execute this payload in an HTML file.  It's going to create a shell code and it's going to look semi normal.  And then what we'll do is we'll queue up throwback to call back to this HTML file and grab the shell code and it will inject it in the memory so meterpreter will never touch this, it will be running from memory. So once we click "create payload" here and it creates this handy little output folder, so we can just copy that to create our handler. So now we'll come back into here. So one thing that's important to notice is you will notice I changed the exit function to thread instead of process.  That's important because when we inject the shell code into another process and we come out of our meterpreter shell, we don't want it to kill the process, we just want it to kill the thread that we created within that process. So we have our handler listening there. The payload is being generated to that HTML file. So now let's go ahead and queue up the task. That one. It should say, download and implement shell code.  And then the argument in this case is the process ID or the pin we want to inject into. In this case, we're just going to cheat and I'm going to just look in the process list and type one in. We already ran a task list, so, you know, we could just look at the task list, but it's hard for me to see, so -. Okay, so no notepad ++ so we'll inject in notepad ++.  So it's 1460. And then you have to select the target and then submit it. And we should only have to wait, at most, a minute for it to execute it. All right, it looks like it executed it. So if we go back now to our cally box, we have an meterpreter shell in memory. ?	>> [Applause]. ?	>> Okay. So that went well. ?	>> [Laughter]. ?	>> Okay, so going forward like I said, throwback has been published on gethub.  You will see the link in the next slide.  We have used it literally for the last four or five years.  So at this point, you know, I feel it's pretty stable and mature, but, you know, we obviously want to make it a community based project.  We're open to feedback. We're open to other people's ideas on improving it.  And we also like to create modules because it implements the reflective DLL injection. It would be super easy to add a key logger module, cats module, hashtag module, things like that. So in the end, the final shameless plug is if you're interested in this type of writing custom malware, custom back doors, we are actually having or holding a course that focuses especially on this, on throw backing and creating your own malware in Black Hat Europe and Black Hat East Coast later this year. I'm also involved with flex grove IO if you're interested in any spear phishing or things like that. Custom spear phishing attacks, that's another super awesome project. You should check it out, if nothing else. The counts are free. Thank you for attending the talk today. I appreciate your time and have fun at DEF CON. 
	>> [Applause]