Windows Defender Exploit Guard vs. Unpatched Software and Zero-Day Exploits

hi welcome back right now we've got chad duffy who's gonna talk through windows defender exploit card versus zero day vulnerabilities thanks a lot chad for being here and doing this over to you thanks thanks for having me max um hi everyone my name is chad duffy i am a security engineer at palantir and yeah this talks about windows defender exploit guide and how it can help protect against zero day vulnerabilities uh the reason i wanted to give this talk is that exploit protection is built into windows 10 and up so it can offer significant resistance against zero-day vulnerabilities and that is like if you've got software that a motivated adversary is taking the time to develop

an exploit for and then they go and apply uh use that exploit in your environment it might be that they find or that you find that it actually just crashes that application when they go and use it against you um what's actually more likely to happen though like than not everyone has a motivated adversary targeting them what's more likely is what we saw in some of the talks yesterday where there are these uh exploits being bought and sold on the ins on the dark web and it could be that you've applied exploit guard controls to your software and so it actually fails in your environment while it's working in lots and lots of other environments

um and and you get that for free in windows 10 and up you can just tweak some of the controls apply some extra protections and it could be that an otherwise really reliable exploit fails in your environment and you get some really good telemetry around that um so what i was going to do is um not spend a lot of time clicking through you know this is what it is these are where you click all of that i was going to jump into some demos in just a second um but the thing i wanted to say first is that it is the next version of emmett so if you've dealt with emmett before uh it's the same thing but they've

microsoft's done a great job of putting it into the os uh introducing a whole lot of other controls and also just making it really easy to configure and really easy to understand the auditing and alerting and that sort of stuff um the point i wanted to make on this slide though is that it's super uh straightforward to get started like this afternoon if somehow this tweaks your interest and you you're like wow there's there's some software in our environment that i'm worried about that i think might be the target of of things or it might not be frequently updated or whatever it is um all you need to do is click the start button type the word

exploit and you'll go straight to that first screen shown on the the big picture in this slide and from there you can actually just start tweaking your exploit guide protections on a per process level you can apply them to the whole system so the operating system says like you've got to have this particular protection for for all the applications but the way i recommend it is just to look at the individual program settings and start to protect the things that really present additional risk in your environment the thing i wanted to say though is that it's actually really easy to uh turn this into logging mode so even if you're not prepared to go and put you know

you're really um business critical applications and wrap them in exploit guards straight away after this short demo one thing that you can do is you can just turn on audit settings and those audit settings would allow you to say like for this particular application this exploit guard control would have caused you a problem it would have caused the application to crash and that's the thing like i'll talk about towards the end but that's the thing i'd encourage people to start with so what we'll do today is we will start out with a real exploit against some real software the software happens to be steven bradshaw's bond server application so it is deliberately vulnerable it does have

some vulnerable functions in it but it applies equally to real vulnerable software and i've included some links to real vulnerable software you can test the same approach with in in the resources section but what we'll do is we'll apply the mitigations after we've exploited the software we'll look at how they are successful and where there's still some gaps and then we'll go and apply a different approach to a different um to the same software we'll apply a different exploit guard approach and look at how it can help solve that particular problem as well at the end we'll briefly talk about the other controls because there's a ton of them and the best thing to do is read

the documentation on the microsoft site um and then we'll just talk about the things that i got wrong at palantir because there was a handful of things that i thought i could just go and do that weren't quite the right approach for exploit garden we'll talk about that all right one thing i i will mention is that i won't have time to talk about like how i found that that i could make the application crash which is a good first step as an exploit developer that's called fuzzing and it takes probably like one of the largest chunks of time in developing an exploit but i put this link here like in big bold just in case

you want to jump ahead and see that you could go straight to this link and there are good examples to show you like how to fuzz this application find that it has a vulnerability and then go about exploiting that application all right so i'll switch to a demo machine i'll try and slow my cursor down here just in case it cuts out but what i wanted to show you is that we have some software running here looks to be just some client server application and we have our adversary machine and what we're looking to do is first of all just we'll just prove that it's doing something so we'll just use nc to make a

connection to it uh we know it runs on port 999 and we can just see like this is a real application it does stuff uh we don't really need to care too much about what it's actually doing because what we want to do is make this application crash in a hope that we can then redirect control of that application into some code of our choosing and so what i mean by that is uh we can see it made the connection here it did all the things um let's look at a simple crash for this application we worked out that this trun command we did a small example of tron here we just typed tron 555

but just zooming in really quickly here you can see instead what i figured out is that if i create a string that's just a ton of arbitrary bytes i'm just going to send the letter a and then i append that to the tron command and send it over to the server that probably this this will crash and let's give that a go so we'll say python crash and what we'll probably find is that this will die and that the application over here oh that's not good sorry try this again python crash so hopefully the application has crashed on this site and you can see that it has um what i wanted to show is what that

looks like from the process perspective so that i can demonstrate where exploit guide comes in and so what i'll do i'll just start the same process but this time i'll start it inside the debugger i'll just attach we'll see it start up here we'll just let it go and so i'll just fire off the same thing so all i'm doing is sending through a ton of a's to that tron command and what we're finding on the application side is that that application crashes and so what you can see down here is quite interesting you've got an access violation inside the application it's crashing when it's trying to get to an address if you haven't seen this before 41 is actually

the letter a in hexadecimal so from a exploit development perspective this is super interesting because as of right now we've put arbitrary input onto the instruction pointer or sorry the instruction pointer is pointing to our arbitrary input and right now it's all a's this is rubbish and that's why the application's crashing it's not doing anything useful but from a development perspective as an adversary this is great and what's extra great is that if you look at the stack pointer which is pointing to this 9c8 address down here you can see that this is also our stuff so we've got a situation where we're able to shove a heap of arbitrary input into this process cause it to crash but

also cause it to crash in a way where we have control of the instruction pointer and a common approach here is to then find an instruction that makes sense that's already in the process so i just happen to know and again this is in the resources section how i searched for this instruction but i happen to know that there's a useful instruction here we can see that there's a a jump to esp so you can imagine that instead of a's if i was able to put this address this 6250 11af into the instruction pointer instead of a's what would happen is the instruction pointer is would say this is the next thing i need to execute which is jump

esp well if i jump to esp i'm jumping to that other arbitrary input so you can imagine that instead of shoving a's here if i shoved code into that um that big string that buffer that i've sent into the process i now have really good code execution inside this process and i'll show you that real quick and then we'll come back and look at how exploit guard makes this better let's just start the software and let's uh let's create a listener so i'll just do an nc nlvp on port 443 actually i'll do it over here so we can see it and i'll get rid of this for you sorry for all the junk okay we'll use our second script and

then we'll have a really quick look at it you can see i've got code execution on that target i'm on that machine and do whatever it is that i like and the reason i can do that is we're able to further develop this exploit uh ignore this part for a second but you can see that all i've done is i've figured out instead of three thousand a's if i send 2002 of them and then i carefully put that address of the instruction that i want which is 62 50 11 af and then i give myself some room with some no off instructions at that point i can also send my buffer of badness through to the process and in

this case it's just a reverse shell a windows reverse shell that i automatically generated with msf venom so this looks very complicated here but this is just automatic um it's part of uh incali msm phantom's in there and you can just generate this payload very very quickly there's nothing special about this payload is what i'm trying to say um but an adversary would usually choose their own payload like uh this exploit would be this part and it would be up to the adversary what they put in their buffer it might be that they instead choose to encrypt all your stuff on the machine seems to be very popular at the moment um the point i'm trying to make is that

we've got a really reliable working crash at this point um let me just move that out of the way sorry i can see myself and i can't quite close this that's better um i'm going to really quickly just show the software crashing again so that we can look at exploit guard helping it out so i'll attach once more to our target software i'll let it run and rather than using the full exploit i'm going to go back to the original crash because it's just a really good way to illustrate things all right so there are probably people on this call i know there are definitely moderators on this call that understand that what i just showed you is

uh very unlikely to work in a lot of environments um the reason is that this here our arbitrary code should not be executable it should be readable should be writable but it's data like this is meant to be data it's not meant to be code and so when i redirected control of execution down here this should have crashed and it should have crashed because of a technology called depth uh data execution prevention um and that's been around since windows xp so there's nothing exciting about that and i'm definitely not trying to do a talk about deb i know that that would be quite late in the game what i am trying to show though is that depp has got

really good workarounds now there's a thing called uh return oriented programming you probably see it written as rop and what that means is that adversaries have worked out that while depp says i'm not allowed to execute this stuff right now i can actually go and use windows apis to make that code executable so the one i'm thinking of is the virtual protect there is a function in windows called virtual protect adversaries using rob figured out that they can call this um it's yeah if i try and go down that rabbit hole in a 20-minute talk i'm going to fail badly but they figured out that they can call rob i use rob to call virtual protect they pass in a parameter

that says page execute and now they've marked that memory as executable and then they can just use their payload as normal they've worked around depth because depth's only designed to block non-executable pages but the new the new thing in exploit guard is arbitrary code guard and what that will do is if this function is called from inside a running process it will return status dynamic code blocked and that process would then crash because depth would say well you didn't succeed in marking those pages as executable so you know hit the road let me just show you that really quickly because i know you know time's pretty tight here uh it's in the debugger so i

can't stop it okay ah let's see so we'll we'll type exploit as i said it's as easy as just typing exploit we just find our program edit and all we do is we turn on arbitrary code guard that says no more marking pages is executable a re-enable dep and then we hit apply and now even if i use rop to try and make this thing work if i start that up what we should find is that our really reliable uh exploit should now fail so i've got my listener i fire off the exploit and we get no shell this time nothing's happened the application has crashed it's gone um and there'll actually be an entry in the event log like this isn't

it but it'll say it would have been blocked from generating dynamic code or actually it'll say it had been blocked from generating dynamic code but in the interest of time i just wanted to move forward and just show what we did there is arbitrary code guard can't fix the bug in that application what's happening is the application's allocating a buffer say uh 2000 bytes but we send in 3 000 uh and then it's going it's passing that into the next function that function is then trying to allocate that buffer onto a smaller amount of memory and we're overriding the return address of the the function all of that doesn't matter in the terms of exploit guard but what really matters

is that we can't prevent the bug in the application what we can prevent is anything horrible happening shortly after that we use depth to stop the execution of that code that we're sending in as part of our string and then we use arbitrary code guard to stop um really advanced adversaries from using rob to go and disable or sorry work around depth by enabling the execute bits on those those things let me just show you one more example because it's a little more advanced for the people that are already super aware of depth let's use the same software and just quickly turn off the other controls so we don't step on each other i'm not sure

which order would happen but just to be sure we'll turn that off uh we'll turn on this so the application's running i'm just going to send through another crash just to show you the difference so similar this is just another crash you can see here it's very similar sending through 5000 odd bytes to the gmon instruction instead um but this time oh that's not good i forgot to put in the debugger i'm on fire start the application debugger attach this time what we should find is that it's not as straightforward from the adversary's point of view so if i send that through you can see that the application has crashed sure enough here we go access violation that address

isn't like straight a's this time we don't have you know an immediate override of the instruction pointer or something quite as useful and you can see even here the instruction pointer is not something that we've controlled input for and neither is the stack pointer if we were to jump to the top of the stack pointer like we did last time we'd hit this and things wouldn't go well um this exploits a little bit more clever in the sense that what we've managed to do if we write a good exploit is we're overriding a thing called the structured exception handler in windows this guy's designed to catch the process on the way down so windows allows you to register exception

handlers that if your code doesn't handle the exception windows can do things for you might be writing the event log taking a crash dom could be a few different things you can see what's cool is that we've just overwritten that so if we were able to carefully figure out an address where we could get to our arbitrary code again and start executing our malicious stuff we've got a working exploit again um in in the same process with a different bug in that process i'll just show you it works and then show you that exploit guard can help and then we'll um actually it's number four and move on let's grab a handler oh we have one

oh that's not great

you can see we get our shell again so we have full uh code execution on that machine at this point let's quickly protect that application so we just type exploit we find our application and down here there's a thing called structured exception handler uh overwrite protection this just says if the structured exception handler wasn't there when the process started and someone's fiddled with it that windows should tell that application that things have gone horribly wrong and crash so if i start a handler and i fire off the exploit again we should find no shell and that the application is crashed i need to move quickly i'm almost at time but i just want to show

you that what happened in this case is very similar it's still a buffer it's still a bug in the code exploit guard can't fix that but exploit guard can say like there are particular behaviors that if we see inside a process on windows we should shut that process down because chances are things are going horribly wrong from a security perspective and to give you an idea there are tons of protections and chris jackson wrote an amazing article recently that explains them much better than i can but we looked at arbitrary code guide we looked at dep we looked at sehop we spoke briefly about return-oriented programming saying that if we notice inside a process that you're using

particular apis that's probably a bad sign but the point i'm trying to make is that you can just layer these on to processes that you're scared or that you need to worry about more so not many processes and need needing to load fonts from outside the windows fonts directory for example or not many processors need to load an image from off the network or over the internet and so they might be really easy controls you could add to processors in your environment as well the lessons learned i just wanted to touch on really quickly audit mode i said at the start is amazing uh i don't know if you caught it but in the exploit

guard ui you can just click audit mode and it won't do the thing it won't crash the process it'll just write a windows event if you hit something that looks a little bit sketchy in that process but the problem i hit is that i applied that to the wrong control i used that with arbitrary code guard on slack at one point and slacks are just in time application and so what that means is that slack has behaviors that means it is generating arbitrary code all the time all day and i deployed that to our whole fleet thinking you know slack's common we need to protect it well that was like about a million events into our west pipelines every

hour inside the environment while i made that silly mistake and the point i'm trying to get to is that the best approach is to apply this to a small number of machines first really understand if the controls are working with the logging and then go and deploy them a bit broader don't assume that you can't do any damage at all with audit mode because i did the other thing i'd say is don't overdo it don't think about your top 20 apps and go and apply exploit guard to your top 20 apps think instead about your apps that are at risk so ones that are networked or that are written in non-memory safe languages or ones where

you don't get patches from the vendor very often like think about your top five or six really scary apps protect those first get comfortable and then look to expand exploit guard is the way i would approach it if i have my time again um the last point i want to make is just the group policy is a little odd if you use group policy to apply this stuff it's very easy all you do is you type exploit again you go into the ui that i showed you and at the bottom there's an export button you export and then you just tell group policy where to find that file that is your configuration file if you ever need to remove that you need

to deploy a whole new file that just describes a baseline build in and you can't just rip the policy out is the point i'm trying to make anyway i realized i went too fast rambled a little screwed up a bit please contact me over twitter or on the chat if i can help with this stuff i i definitely don't know everything about it but i spent a lot of time messing about with it and i'd love to help if i can thank you very much awesome thank you this is a topic near and dear to my heart definitely um so yeah there's some questions that are coming in um like you said we did kind of run out

of time so i'm going to thank you once again for coming to besides toronto and giving your talk and continue from there thank you thanks max