 Hey, good afternoon everybody. How are we doing? Let's learn some stuff about PowerShell. So in my day job, I'm mostly a simple country lawyer. But I open up a computer every now and again and I remember the first time I saw PowerShell, I was like hey, this is neat. Somebody said it's more powerful than the old Windows command line and I type in LS and there's my directory listing. I was like oh, this is awesome. I know this. It was like Jurassic Park. And then I'm like what's my IP address? I type if config. It doesn't do anything. And I type IP config. It doesn't do anything. It's like I hate PowerShell. Done with this. Done with this. So along those lines, I like to use some of that power of PowerShell when I'm doing demos and I'm doing things on my own systems, of course. And to my own systems. But it can be kind of frustrating. So what we're going to learn about now, Rich is going to show us some stuff that he's done to make Evil PowerShell a lot easier. So Rich is going to give us a great talk. Let's give him a big hand. All right, thanks for coming out. A lot bigger crowd than I realized here. My name is Rich Kelly. First talk, first time here at DEF CON. So give a little background on myself. Comp side background. Previously I was a comm officer in the Air Force. After I got out, it became a contractor. Did some network engineering, software development. And eventually ended up in security going pen testing, mostly for the government. Most recently, branched out, co-founded a small InfoSec startup out of Virginia. Mostly focused on application pen testing at the moment. And in my spare time I'll occasionally release some sort of utilities that are probably only useful to me and maybe one other person. All right, so why should you care? If you're here you probably already know this already. But the first point is that PowerShell is here to stay. It's going to be on Windows for the foreseeable future. So if you're not using it, and if you're an offensive guy and you're not using it, then you're really just kind of cheating yourself. It's a resource that's there. You don't have to put anything on disk usually. So I'd recommend taking a look at PowerShell. And a lot of the offensive community has been focused on that lately. Also from the defense side, I get the impression that a lot of defenders aren't really aware of how dangerous it can be to give access to PowerShell. I've been on networks where as a regular user I had access to Active Directory functions within PowerShell, which is completely unnecessary. So the more we bring it up, the more secure we can make things. I was also struck by how hard it is to kind of do any sort of post-mortem analysis on any sort of incident that an attacker had used PowerShell. So if you're looking for a research topic, it might be a good area to start focusing in. Okay, so what is the PowerShell weaponization problem? I guess just to put it simply, it's how do you get your PowerShell scripts running on your target machines and effectively get your results back? I think that's probably the most simple way to put it. And it may not be quite obvious, but up until a few months ago it was actually not really that easy to kind of work PowerShell into your workflow. There was a number of scripts and tools and great libraries that came out, but I think there was still kind of this vague understanding of how you would use it on a pen test or a red team engagement. So when I started this project I was just trying to make it easier on myself and enough people I had respect for convinced me to put in for a talk and so here I am. So has this problem been solved? And the answer to that is yes. Certainly in the past couple of months we've had a lot of really interesting and great tools that came out to utilize PowerShell, so the excuses are getting less and less for why you wouldn't use it on a pen test. When I started this the thing that kind of drove me down this path is that there was this kind of fuzzy area where you gain access, do something, use PowerShell and then you know you're good to go. So I think that's where I started trying to fill in the gap. As I mentioned there's a bunch of solutions recently. I think even you know there was one a few days ago that I'll talk about quickly that everybody should check out as well. Alright so briefly I just wanted to go over some of the other ways you can use PowerShell, you can weaponize it. So of course if you have RDP access you can just bring up the PowerShell executable that we all know and love. If you bypass the execution policy you can go ahead and just import your script if you've dropped it to disk. You can copy and paste your function into PowerShell and it's loaded into memory for you to use. More than likely though you're probably using the line on top there which is referred to as the download cradle where you're using a web client to reach out and download a PowerShell script that you've staged on some web server. So the next way is if you have some sort of command shell which is more likely way you probably used it. In this case you can't just drop into a PowerShell interactive console like you would normally. So the nature of PowerShell and the way it works it just made it more difficult to develop that type of payload. So the easy way to get around that was to use the encoded command. So there's a number of utilities that will help you with that. You just encode your script and you pass it as a command line argument to PowerShell executable and it will go ahead and execute that and return some results. That's probably how most of you have probably used PowerShell on most of your tests. If you have an interpreter shell you can use a lot of Metasploit modules that make things around real easy. So you can use the execute PowerShell module. This has been around for a while actually so what's nice about this is you can stage your script on your local attack machine and Metasploit takes care of some of the heavy lifting for you. So it does the encoding in the background and passes it through the interpreter session to execute. I have had a few issues with it. On larger scripts it's occasionally opened up a lot of PowerShell instances and so it was flaky a couple of times. Most recently and I think it was April or May Metasploit merged in the new interactive PowerShell payloads and to be honest if this was around back when I started this I may not have gone down the path of building it. So in this case it is currently in Metasploit and it's got some really nice features. You do get an interactive console. You can also pass it a common delimited string of file paths where all your local scripts are so that once it runs it goes ahead and loads up all the scripts for you. So it's really nice something you can use right now in Metasploit. Then there's cobalt strike. If you have cobalt strike I think this was probably the first really clean solution to the PowerShell weaponization problem that I saw. In this case if you have beacon on a machine and anybody knows me knows I'm a big fan of beacon you can just say PowerShell import give it the path to your local script and then it does the hard work for you sends it across the wire loads it up into memory and you have your functions available there. So if you have cobalt strike this is really easy. So some other options I just wanted to touch on briefly. So you have PowerShell remoting. This is the native capability you have to have it enabled but once it is you can actually just use PowerShell to invoke commands on a remote machine so whether it's enabled by the administrator of the target machine or if you do it once you get on the machine it's a nice feature and you don't have to really install anything. WMI I'm certainly not an expert in WMI but there's going to be a talk tomorrow I recommend you go to. I'm sure it'll tell you everything you ever want to know about offensive WMI. Then of course Empire this is the tool I was released just a couple days ago at B-Sides and it's really kind of a game changer. It's a post exploitation agent implemented in PowerShell. It also has a really nice framework to help you build out modules for that. If you haven't already checked that out I would recommend going to their website and taking a look at that. Okay so I'm already always kind of harping on my clients to give me requirements which is rough sometimes but the requirements for myself was that I wanted a fully interactive remote PowerShell console with the same capabilities as the native PowerShell executable and I also wanted the ability to seamlessly import modules across the wire. I didn't really want to have to stage them and use the web download feature. I just wanted to say import module, give it a path and be done with it. So those were my two requirements when I set out probably last December sometime and working on it off and on proved to be a little more challenging than I thought. Alright so I'm going to attempt a live demo here. We'll see how this works out. Okay so ultimately harness is the actual payload so in this case it's an interactive remote PowerShell console so it's not implemented in PowerShell actually it's implemented in C-sharp so Microsoft has got a lot of functions that you can use to build out your own custom hosts so if you want to dig into the msdn library you can do that. The documentation on it was a little limited so that's why I struggled quite a bit in the beginning but here I'll show you what I have. So I've kind of bundled everything into this Python framework and it's really not the focus, it's almost a separate project but it was an easy way to kind of get the code out to you guys and let you look at it. Ultimately you can integrate the payload into whatever your workflow is. So it's got the usual commands, show, set, things like that. In this case I have a whole lot of modules, like I said it's not the focus. I have a handler and then I also have a number of payloads here so mostly just 86 and 64 bit executable and then also a reflective DLL that you can use to inject into memory and I'll show you that here in a minute too. So if you wanted to use a payload very similar to Metasploit here so in practice you probably wouldn't use the dropper unless you actually had to. You know you try to avoid touching disk when you're on some sort of thing but you just run it like that you get your executable and then it's kind of up to you how you would get it to your target. So in this case I've already kind of dropped it on target and we'll see if we can get a callback but what I really wanted to show you is you don't really need a special handler in this case that will communicate with any socket so in this case see if we can use Netcat and we get a nice callback here so you don't really need anything special to get most of it. This isn't running PowerShell EXE it's an unmanaged payload so if there's some sort of whitelist you can't you've avoided that. The one of the things I also wanted that you don't get in a lot of the interactive payloads is that if you notice in PowerShell you get the multi-line inputs so I really kind of wanted that feature in there I thought it was like a hallmark of having PowerShell so you can do stuff like this now and what it's doing in the background is every time you send it something it's doing a check for whether or not you have any sort of parse errors and once it says that it's clean it goes ahead and executes it so in this case you can you can just print out so this allows you to kind of build functions on the fly you can try to copy and paste in there I'm working on that problem right now the buffers can't keep up with each other but eventually I like to have that problem solved as well alright so that was getting kind of close to my first objective it's not completely it's not completely implemented yet but yeah I'm working through some of the bugs so the next thing I want to show you is if you use the handler built into the framework here you get a little more functionality so you can load the handler here just run it on 80 once again we'll execute it and we get a callback here so so we can interact here so now what you can do is using the server and the client together you can import modules across the wire so in this case built in some custom commands so the only difference is the module it'll try to send it over the wire so this isn't doing a web download this is actually sending it over the same com channel as you're currently using so in this case once you once you've loaded into memory there you can see we have all the functions from the power up available so see if we can do invoke all checks what I have noticed is that it does actually consume a lot of memory when you're doing things like invoke all checks so here we go we got the results back from invoke all checks nothing too exciting here so the next demo I wanted to show you is the reflective payload and in this case rather than tempt the demo gods I wanted to show you a video I apologize if it's too small so in this case you're going to you're going to run your handler like you normally would load up the reflective DLL which wouldn't be possible without building on the awesome work from the unmanaged power shell project and also from the reflective pick project so if you haven't checked those out you should take a look at those as well it really helped out and of course reflective DLLs are built off all the work from Stephen fewer so without those three projects there's no way I could have implemented that myself so now we're going to create a payload in this case a DLL now I've already staged a interpreter callback from here that's running a system so in this case you can actually use the reflective DLL post module and inject it directly into memory so inject it directly into LSAS here okay so it injects into LSAS and it's going to take a minute the 64 bit payload seems to take a little bit to con it get ramped up but eventually you get a callback here running a system anytime now hey there we go so you get a callback and you can just interact with the session like you normally would so now that we're running a system we can do things like invoke meme cats and before you can now import your modules all the way across the wire what I did for any sort of special functions that required handling there's a caret symbol in front of it I was trying to differentiate between the native power shell commands and then the harness commands so in this case I'll import meme cats and just to prove it's actually loaded into memory you can take a look at what the current process ID is running in LSAS so this is very similar to the capability you can get with things like Empire now so it's going to be a lot harder to detect malicious power shell in the future as well so invoke meme cats there we go so you get your results back just like you normally would meme cats you get your password okay so under the hood the payload actually has been compiled with .NET 4.0 I think you could probably compile it down to 3.5 if you actually needed to it does require the system management automation assembly which is where all the internal methods come from to actually build out your own power shell host tested on a number of systems and it should work from Windows 7 on up as far as the server is concerned it's almost like a separate project I did implement it and it requires Python 3.4 but you can build your own very easily the actual listener is using async.io which if you're familiar with that it allows you to run multiple asynchronous processes not processes but tasks in the same thread so in this case all of the sessions are actually running in the same thread so that was kind of another pet project that I implemented there but you could easily implement it in just a regular listener or something like the Metasploit framework so why did I choose Python why not Ruby and I just go ahead and build a Metasploit module and really it was mostly for the learning experience it helped me to actually fill in some gaps that I had and I have a lot more appreciation now for those behind the scenes I also work better in Python than Ruby so no critique there it's just my preference and as I mentioned it should be easy enough to port to Metasploit module the payload is compatible so reflective harness as you saw can be used with DLL injects currently as far as defense I haven't done too much work in this but if you can restrict access to system management automation you can actually you could probably stop these attacks or even monitor any access to system kind of trigger on any sort of malicious use you can also look and see if it's loaded into processes it shouldn't have and then you can you know tell whether there's something that shouldn't be there else that shouldn't have you know a power shell loaded into it also there's new features built into power shell power shell 5.0 actually has a lot of nice logging features and if you were in the red versus blue talk earlier today he went over a lot of really great defense techniques okay so that's all I have a big thanks to you guys for being possible without it thanks for answering my questions thanks for the encouragement so I really appreciate it all the code here is released on github so at the address below and that's my contact information if you have any questions thank you