BSidesROC 2023 Rips, Reps and Revelations - Paul Michaud

just a quick mic check everybody can can hear me okay awesome thank you uh so uh thanks for coming out to check uh check out my talk um rips reps and Revelations uh creating cyber fire drills uh using Atomic red team to Contin continuously test uh our team so a little bit about me um I'm Paul Melle I'm a principal threat Hunter at Red Canary uh I have background in threat hunting purple teaming instant handling and in response um I am a maintainer one of the maintainers of atomic red team an open source library that we'll touch on here in a little bit uh I also co-host a web series with my good friend Mike ha uh it's called

atomics on a Friday um back a few years ago Atomic red team uh had a a webcast on Fridays called Atomic Friday so we kind of brought it back in a different light called atomics on a Friday um so we hosted ourselves so there's no vendors there's no pitches it's just talk and security with a bunch of people um so you can check those out we stream to Twitch and YouTube all the recordings are on YouTube um I have a cat his name is C2 uh he is the softest cat ever our vet even said so um so it's clearly scientifically backed I don't know how this works there we go uh there he is um he's definitely

malware uh we adopted him his name was Kelvin II um so C2 just kind of fit in kind of just worked out that way so it's pretty fun uh you can find me on Twitter at Burning PM so let's kind of overview of what we're talking about today so what are we even doing here how does this come about uh some background um and then we're going to go kind of into the steps so using Atomic red team to actually execute the tests that we're going to U identify why we're going to be testing um how do we approach this so that it's repeatable and simplistic and then kind of some of the revelations like what did

we learn um and if you're a letter KY fan you might recognize some of these uh things that I dropped in as well as some pictures so I hopefully have some fun with that uh so a little bit of background um before threat hunting was a team uh we actually recently just changed name so not too much changed but we are the instant handling team um and a common misconception was that instant handling was kind of like instant response and it's absolutely not so um if you're not familiar with Red Canary we do manage detection response so we identify threats and then we tell the customers about it um where the incident handling team stepped in was after that detection

got published we would tell you how to help guide and advise on remediation what should you care about how do you do it all those types of things so never were actually Hands-On um that changed a little bit we had incident response Partners but we never did incident response ourselves and we're kind of Bridging the Gap with active mediation so these are things right before like things blow up and now you need to call IR um so this is allowing us to respond on your behalf so using EDR platforms to go into live response or remote sell remote shell sessions and clean up those threats um so how does this tie in well instant handling SL threat hunting team was the

one to go build out and Implement act for mediation but that's now Hands-On and we weren't Hands-On um so somebody like me who had a background in security analyst it's been a few years since I did Hands-On remediation responding to threats and some people had backgrounds where that wasn't their thing so we had to figure out a way of okay how do we learn the platforms to respond but how do we identify and learn how to respond to threats themselves so we had to learn the tool but we also had to learn the skills and knowledge to actually respond to it how do we do that so the idea was how do I simply and

consistently provide the team so the instant handling threat hunting team handson response capabilities uh to develop those those skills so in a simplistic term we had the team that had really good and could tell you how to respond to threats we knew all the things to do but now we just had to make sure that we could actually do them so we had to go from this level and take it to the next level so the solution that we came that we came up with was kind of what we approached it with it had to be simple anybody should be able to do this I should be able to go to anybody on the team and say hey it shouldn't rely on to

one person to run these but uh when we create these fire drills we had to be able to give them to somebody um it had to be repeatable so learning um eight EDR platforms and each one varying in their skill what they provide um we had to take the test and be able to run it on both of those so we could identify like how does the uh live response work on platform a versus platform B what are my caveats what are the things I have to pay attention to or limitations of that and the last thing is had to be measurable we had to have clear ways to identify that we are doing the right

things and that it's growing the skills and knowledge of the team so well let's jump into Atomic red team and figure out why it's going to be the solution and how we used it to actually scale it so uh Atomic red team if you're not familiar is an open source library of security tests they're mapped to the miter framework um the original idea of atomic red team was uh we needed to identify data sources so EDR what does it collect and how does it collect it and then where does it go so the test was if I expect process execution to be logged I run a test to create a process if I expect files to be written to disk

and that's what I expect my EDR platform to do and point detection response and collect the files I need to be able to see that so this is where Atomic red team came in um and then now it kind of evolved into detection validation um so if I have an analytic that says I'm looking for Powershell making a network connection I should have a test that runs Powershell making a network connection right um and then it kind of evolved into threat emulation and now we're going to kind of use it in some response training maybe um so let's take a look at what how Atomic is structured to understand how we can use this to

build out fire drills to train the team to learn the tools but also learn response so the structure of atomic is is pretty simple it's just a yaml file that has definitions of certain things one of them being the name like what's the friendly name what do I call it in this case I'm going to create a local schedule task um um each Atomic when you merge a test into GitHub there's a bunch of CI and CD magic that occurs but each test gets a unique goid so test can get rearranged right miter comes out with an update and says we have 10 new sub techniques and a test has to get moved under a new one the order of the test

can change the name of the test can change but the guid always stays the same that is the unique identifier that I can always plug that in and that test will run uh the supported platforms so we have tests that can run on Linux and Mac right think like Python scripts that they're default I can run those um Windows um and we also have support for cloud platforms as well as like gcp AWS Azure and even things like testing um Azure ad then you have input arguments these are custom think variables that I can change and Define so when we create atomics they're very things simple things like um Atomic test 123 is the the task name for a schedule task uh so

we give you the ability to override those so you can actually emulate kind of what a threat does and we'll kind of go into an example of that then we have the executor what is the thing that is actually going to run this in this case it's going to be command prompt uh and then elevation required so there's some test that require you to have an elevated command prompt think like something like a mimik cads where I want to dump credentials standard user can't do it administrative system level that's going to give me the access that I need to go do it so it'll actually tell you like do I need to be required or hire permission then the actual

command and then clean up so one of the things that is like you run the test we also give you the ability to clean it up afterwards so it's you know SP up VM you run the test you collect your data and then you're off so here's kind of another example but now in the middle what you can see is there's dependencies so while like a scheduled task very simple run SC task. XE give it the parameters that you want there's some that say Hey Go download this file or make sure this file exists somewhere on disk that may not be there by default um so what these do is very similar is they go and say Here's the

prere command make sure that thing exists and then if not go get it and then put it there um and then everything else is still the same so there's uh ways to say hey go validate it exists and if not go get it for me so uh in some cases you build custom things like it may not exist or you may have a variation to where you may not want like legitimate Bad Evil running so you create your own um and we structure the uh test so in each uh directory uh we have a source file so things like the PL C files um if there's a like a bat file that actually compiles it for the

fly on the Fly um and then the bin so the bin is the binary so the actual compiled binary and that's usually the thing that is downloaded or is staged somewhere for the test so that's the structure of atomic now some of those you can just go to the atomic uh GitHub repo copy the test paste it into the command prompt and let it rip that's not really scalable and if I want to run a bunch of these and do a lot of validation um we need a way to execute these so we have exe uh Frameworks or executors and the two most common are invoke Atomic red team and atomic operator which is written in

Python and these are basically ways that our code to read the yaml understand it and then go do whatever it says to do so we're going to focus on invoke a little bit because that's kind of what we uh leveraged as we were running our test um it's crossplatform so there's support for Windows Mac and Linux um so on uh Linux and Mac it uses a Powershell core and then on Windows it just uses regular Powershell um it does support local execution but let's say I wanted to run a test on 50 endpoints I can create a Powershell session on 50 endpoints pass that as a parameter and then it will magically go out create

those connections run the the tests on all 50 endpoints and then terminate the sessions and the same works on Powershell core for Linux and Mac where I can just use uh SSH or secure shell some of the parameters we're going to focus on are put arguments and propor input arguments get prerequisites and clean up so let's take a look at what it looks like when we import the Powershell module so if we go to invoke Atomic red team it's a on a repository itself we can then uh install it there's a a great wiki guide that kind of steps you through there's like two commands that you can get in the uh executor framework and all the atomics so it's like a one

liner you just drop it in it does the magic um so in this case we tell it okay in invoke Atomic test is the module that's going to go run the actual command we have the technique ID this knows to go look in a specific directory in our atomics folder and then it knows to read the yaml file inside of that and then there's things like test name where we can give it the explicit test name we saw earlier I in this case I just use the test name but we could also have like test guid so again using those uh programmatic goids and then showing details so basically spit out in the command line what are the things and

then what is it going to look like so kind of in the middle we can see like where we have those custom input arguments kind of shows where they go and then it'll spit out with inputs what's it going to look like when we actually run it and then the actual cleanup command so now let's look at something like getting prerequisites so the prerequisits again are going to say hey do I have anything that needs to exist before this test to run otherwise if I run it and that doesn't exist it's going to fail so in this case we don't have any prerequisites um but maybe I want to override the defaults I can programmatically write a hash table

which we'll look into um and override those and pass it as a parameter or I could say hey prompt me each input argument and either I'll allow the default or maybe hey there's one parameter that I do want to change and it promps me for that and then the cleanup again I just pass the clean up flag and after execution it will go and clean up anything that it did so like in this case creating a schedule task it will go and delete it so that's kind of the overview of atomic right it's the structure and now we have how they work and now we have the executor of how we can actually do them but now let's scale it let's create

some scenarios that we can kind of come across so when we're building plans there's a couple ways we can start um so in like a traditional setting maybe like in traditional stock we're trying to build up the team and build up and continuously make sure that they can respond they have the insights and we're doing it consistently sometimes what happens is we wait for things like purple team engagements or red teams or even tabletops where that's the time where we get our hands on we can do our thing but then we wait maybe six months or a yearly thing for it to occur but that's a long time and it's not giving us potentially we forget all the things

so um we want to provide ways that we can continuously do this in a simplistic manner um so in a traditional sense we want to think about where our concerns is my team really good at responding to fishing but maybe we get later into things like credential theft where maybe they're not too sure of what happens like all a sudden mimik cats runs well what does that mean what happens how do I respond to that what are the things that necessarily I don't necessarily do on the end point but things like res setting credentials what did that user do right so some of that response capability where you have different techniques that are going to require

different responses so we can think about from a technique standpoint or even just a full-blown attack path what is that going to look like and how do we respond to it so where can we pull inspiration from for creating plans well we have things like threat reports open source intelligence and of course previous incidents right so previous in are a great way especially internally like if we did this and we didn't have a great response to it that's a perfect example of build a plan run in a future times and every once in a while maybe you throw in something different um and then how do we build it well we're going to start simple and then we're going to

evolve it over time as we watch and see the skills grow and change we want to keep up with that we want to make it a little more difficult we want to inject some new things maybe uh change it up um we're going to use a little bit of yaml and the invoke Atomic framework and then we're going to schedule it so let's look at some ways that we approach this as we were testing our tools so you have a basic execution flow so we started very simple so think of the nodes as a single thing that occurs uh user opens word Powershell spawns makes a network connection downloads a file runs something else and

then maybe schedules a task right very 1 two 3 4 no hidden secrets there's no gachas it's very straightforward because we want to start to gauge okay this is the bare minimum this is kind of the basic thing where are we at where's the team at what occurs where are some of the pitfalls we identified then after we do that a few times we then approach it a little bit different Maybe we start out the same but now we change it so they don't just get complacent that I know that this is going to occur then this then this so I start to change it up then you get a little bit more interesting maybe I don't tell you how

it got there let's say it evaded some defense and I inject something different right and then I skip the next one and then I give you something else and I can plant those other events along the way but I may not tell you about them or make sure that it avoids a detection or alert so that you have to then as the analyst start to kind of piece it back together right I don't give you a full picture right just like an attack path you don't know the whole thing to start you know bits and pieces and have to build it over time then you can do something like we started to do which was all attacks

don't just stay on one endpoint sometimes if we're good enough and we detect it early enough and we respond quickly we can contain it to that single end point but sometimes you start off on one end point and then it goes and does something else on another and then it goes back to a different one or the same one um so we start to get a little more complex and this is like our Evolution that we did internally as we were testing out the various platforms building the skills and knowledges we started very basic then we started to take that exact same flow but we took away key components and then we started to make a little interesting and start

to throw it across like five or six end points so that's how we kind of built them out but now let's look at an example of how we can take something like a threat report build out an emulation plan and use that as our example of our execution flow so in this case we're using a a defa report is a great example um so we're going to review for the potential to test so each one of these are going to be something that we're going to use along the way in our emulation plan so the first VI are things like disabling Windows Defender uh creating scheduled task and downloading a file adding a user account and then create adding it

to local admins and remote desktop users so just kind of high level we're going to step through so now what we can do is say okay uh in atomic red team is there a test for disabling Windows Defender great thing is there's probably about 25 of them so we have our Bounty uh full amount to choose from things like create a scheduled test we saw an example of that but let's change it up let's tell it instead of maybe launch launching command in that example we saw earlier we now give it a Powershell command that just goes and downloads a text file right we don't need full real malware we just need things that are going to mimic

certain uh procedural things of a threat and then so on and so forth so let's look at an example so this was kind of like the base thing again I needed to run this for a team of 18 consistently across multiple points as we're kind of building out this this new uh offering right so this is kind of stage one like can I run this inow shell in a very basic listic manner which is um provide an override so here's an example as which I mentioned earlier is um if you look at kind of the third line at scheduled task the one below that um I'm not a Powershell Master any means but uh create a parameter called uh I

forgot what that says uh scheduled ARG and then create a hash table so hash tables are basically allowing me to put in multiple uh key pair values and then pass that as a single variable into the command line so in this case uh the second one so we invoke our Atomic test so that's our module we have the technique ID the specific goid and then we're going to pass in the arguments that we want to override and what we do is we say okay well the default Is 2020 if I remember correctly but I want that to execute sooner because it's going to go and run that Powershell command then in the next example uh we kind of

borrowed this right from it and it gets cut off but what it does is I override the arguments to mimic the file names and patterns that were in the threat report so now I'm procedurally trying to map what the threat actor did so it's a little more uh realistic than just saying here here's a bunch of atomic it's atomics everywhere and we kind of all know that right trying to get a little bit more realistic and so we just step through and so we're defining those custom input parameters based on what we saw in the defer report so here's now how we said okay so that's great and a Powershell script that works on one endpoint but I need to

do this on many endpoints so I can get more people Hands-On in a faster capacity so in this case as we mentioned earlier we can use a Powershell in order to create remote sessions in this case we're going to create a variable uh we're going to tell it new power shell sessions and give it the computer names and then prompt me for credentials and I'm going to put those in and then pass that along so it's the exact same script from before but now at the end we tag in uh TX session is the parameter that we're going to use and then pass in the session argument and now when I when it runs it's going to at those specific

points where I say session it's going to go out and on each endpoint that I specified above go and run that specific thing so now I have not just one endpoint with the test and I have to do this three times or five times but I have three in one execution now that's great but again I don't write Powershell I don't expect a lot of people just be able to write Powershell so let's take that idea and let's put it into Atomic well tomic's written in yaml so why can't I just write yaml so it's like what I did so there's basic uh inputs that say like what the emulation plan is what the description is any references and then

uh so we specify the atomics the technique the guid and again any custom input arguments I can put them in there I don't have to put them in there so this is a very simp simple basic yaml schema that we that I wrote for a rapper script which we'll jump into next I'm just kind of identify it so again now what I did was make it so that I can take this yaml file I can give it a Powershell script and then give it to anybody or create you know 20 yaml files and say here you go so there's our repeatability without having to have anybody be expert in pow shell but the ability to then just go and run

these so uh at the end I have links to all the different things but this is just the be snippet of code again I don't write Powershell but this is it so basically look for the ammo file parse out specific points do a couple checks is atomic red team installed obviously if it's not installed we can't run anything so we need that um validate that there's prerequisites so go get those prerequisites again if we're going on remote computers they may not have Atomic red team and they don't need it they just need those specific files that to exist in those specific things where that test is going to want them so automatically go put and Stage those

files for me or whatever and then actually go through and run those tests so invoke was designed to run a single test at a time so what I did was simply just said okay well create a loop that however many tests are in the yaml file just iterate through and then pass them over so now each test is going to run and I don't have to worry about manually running that so not great but it works right it solves the problem so we're kind of there so we have like a minimum file product of I can write some yaml I have a basic script that I can give to anybody on the team and say go run these

create some fire drills for the team so they can practice a response what does that look like so in this example again point to the Powershell script point to the yaml file it's going to run through it's going to check for the uh make sure that atomics exist that Atomic red that invoke is there Step through for any prerequisites in this case a lot of them don't have any I think at the bottom there were a few more um but got truncated off and then the next step is once that's done go and actually execute it so in this case go execute the test download the file go create the new user um create the guest

accounts with adding goes in and that's what the output gets so that's it that ran all the tests and now what we should see is whether we're in case Red Canary we should see events in like a traditional stock you should potentially have a bunch of alerts starting to fire off and that's the indicator for the analyst to say okay like now it's time to go like now based on this go clean up schedule task a new user was created what is my response and how do I respond to that right and you may not know and that's okay um so that's what we did so we created a very simplistic thing that we could just easily repeat um when we

started this I was manually creating these tests by hand so I was creating payloads I was sping up C2 servers I was blasting out and it worked great in the beginning but it didn't scale and it again resulted in a single point of failure so if I was out on vacation for two weeks those fire Joes weren't getting done and it kind of hinder the the team's ability to keep going so what did we learn um so basically we identified areas for improvement and knowledge again we had a lot of different people that were in like myself who hadn't touched and actually done response in probably three years at this point we had some people that never

did like they came from a different vertical in the security industry where they kind of needed to build those skills um the basic response actions were easily picked up so as we started these things like isolating the endpoint or quarantining it deleting files killing uh processes Banning hashes and platforms right kind of some of the basic things to at least get the containment going easy what we also identified was there were specific techniques where knowledge or gaps started to show and one example right like Wy event consumers sometimes that comes across but more commonly things like a scheduled task is the most common the show up from a persistence but occasionally things like wmi event

consumers show UPS well that was like a question well what is this and how do I respond to it um and then again our execution flows uh evolved over time so we started out very basic and we kept that going so we did very simplistic flows um in the phosphorous example a little B more advanced that we did at the end um but again we started with those things like word spawning Powershell downloading a file with a network connection creating schedule task we ran that over and over and again as we had multiple edrs to support we then ran that same test and identified where the gaps were and figured out how we can actually do

it uh so we would keep running the same test and every few weeks we'd run the same test over right like we know what happened and where they were so let's say 80% was done the first time well hopefully the next time we do it it's improved right hopefully it doesn't decrease in in our success rate but it actually improves um and then occasionally we throw in a monkey wrench so one time we created a really Advanced thing mostly for my fun and edification uh we compromised the EDR sensor and basically injected into it and so the security tool now became the threat so what do you do there uh didn't expect anybody to actually do really well with

this it was more again just for fun and just kind of walk through and like what happens when your security cool gets compromised what do you do in that case um so we that one time it was a lot of fun for that one so ideas for measuring success um I is an important key and the idea was not to say like well we did terrible in this and we did terrible that it was again to Baseline the knowledge figure out where we need to spend our time efforts and so that we could then again build the skills um so things like triage actions So based on this plan as the Creator I know that there's going to be things

like 10 files that have to get deleted the end point should be isolated these specific hashes should be banned right so we know kind of some of that initial triage things that we can start to do it um like so if 10 of those existed how did they do did they get eight did they get seven they get five right it's just like initial triage then could they talk about the attack path like how did it start right in the very beginning doing the Bas execution flow A to B to C right it's pretty easy to pick up but as we started to take some things away and leave breadcrumbs did they pick up on it

could they paint the picture in like a two to three sentence thing or even in a 30 second Spiel tell me exactly what happened at a high level right um artifacts again what were the numbers identified because there's instances in our case where things like resetting user exential we couldn't do that the platform couldn't do that right in EDR that's something you go and do in like active directory or your identity uh platform but if those things that we couldn't do but need to get done go pull the emails from the email people's inboxes right go block the domains of the firewall things of that nature um that again you can't do necessarily from the platform but still need to get taken

care of and we started looking at like meantime to remediation average time remediation we Loosely kind of tracked this because not every threat was created equally and not every platform was created equally so in our case it wasn't really fair because if we said well it took 5 minutes this time but it took an hour and a half this time well why well two different platforms two different scenarios two different problems so we kind of loosely gauged it of like how you know what was the average time knowing again some basic math and then assistance um one of the great things about this is that we were divided into three teams with people on each team is that uh nobody was just

kind of left hanging uh pretty much they all spawn up a zoom and then jumped in and there were probably like five people six people on the zoom and so like one person was responding but they could ask questions they could as they came across things like they ask for assistance over time how much assistance did they start asking or were they just able to go for it and kind of start to figure things out so it's kind of an interesting way of just seeing like the the collaboration and then where the growth is occurring so in summary so the idea was to B we needed to Baseline the skills and knowledge we needed a way to have a

simplistic and approachable method to actually run these tests um and then we need to make it repeatable so what we did was we ran six tests a week again we had roughly 17 18 um so we ran two tests on three end points so basically uh one day on let's say Tuesday um we would run a test it would be on three end points so that gave three people a chance the next day on Wednesday we would run a completely different test so that three more people get in Bas and then we'd spread over two days and we have a debrief session spent like half hour 45 minutes here's what happened like here's any questions like what did you guys

think of um and again so we're we're trying to track for Success here again it wasn't to see like oh you guys didn't do well in this but it was just to see where we're at understand the limitations of the platforms put in our process and procedures so that we could uh know um and effectively respond to those threats but we can apply this into like a traditional sock setting right uh you may not have 18 people you may have five or six you may have three but you can have take a report you can run it uh generate some events and get handson so you don't have to wait for those things like the tabletop exercises to validate

your process and procedures or specific things that you may not come across every day like cloud or identity based threats um because com right can do those U we can still spin those up so here are some resources um so Atomic red team. is the website you can do some quick searching there is the GitHub repo um the executor Frameworks uh so invoke Atomic and then Atomic operators actually from swim Lane is the python variation uh atomics on a Friday is the GitHub repo for the emulation tools for the yaml files uh I'll share this out uh it's also publicly available um so some inside scoop uh there are some new features coming and uh

functions within invoke that are going to support and actually be able to natively so you don't have to download like a rapper script and there'll be a standardized yaml schema so we can actually build out a lot of emulation plans have a single repository that are open source emulation plans and then a built-in parameter for actually running these so you don't have to have like 10 things consolidate them all make it really easy right atomics are there why not the emulation plans and why not have an Executor framework like invoke and atomic operator to just natively run these um so it's going to make it a little bit easier so that's in the pipeline some inside scoop um so look

forward to that and that is it so thank you all for coming and letting me ramble about some of the stuff that we did any questions yeah um so right now you have a way of um quering other machines as a group do you have any way of getting a response like when you send out and you open up a power run something Ma you have a way of telling that sucessful or not sucessful yeah great question so is determining if I run a test is that test successful especially when I have not necessarily locally but on remote machines um so there is a logger uh par or function built into invoke and as well as uh

operator um it doesn't necessarily always in certain tests tell you that it was successful or not because there's no way to specically query for that um so some tests do have that capability but some don't and some tests it just kind of hangs it will potentially crash and then you have no way it just says hey I ran it and that's kind of it um so there are some cases where yes you do have that capability and some that you don't um and then there's other tools out there uh that actually have that capability where it'll actually run the test and then it'll basically just like query like okay is that process running cool and then um overtime terminate it

and there are some functionality built into uh invoke that says hey uh have a timeout so if I expect the thing to run and it's not terminating like go terminate it right like as part of the cleanup process um but it won't explicitly say like yes successful or specifically no not in some cases just because of the way that certain tests run good question yes I assume you're running this in your your hydrated test range what about customers is the expectation that they're running it in their ranges as well yeah so uh uh so the question being uh how do customers run these or where are they running them so uh basically spin up a

VM or spin up kind of a lab while some of these most of the tests are very benign while they're not necessarily running malware you may not want mimik hats running on like a a production workstation right so you kind of spin up a few tests um in that capacity uh we have customers that use these as like again in the traditional sense of what it was built for was data source validation did I expect out of 20 tests that for on 20 machines that I had a logging for process execution file rights network connections on my test did I get all 20 right so in that sense and we have cases of we have customers

that are in the small business and medium business that don't have like a full security team but are like hey if I got hit with cubot uh what does that look like and where are my tools they may not have like everything centralized but you can still effectively go look at AV EDR um Endo logs uh event logs Etc so you could actually run this and go validate like did I see this did it get stopped um is it exactly one to one like potential malware or thread actors no but is it giving you at least a starting point and kind of bridging that gap of going you know the crawl walk run aspect sure um so there's that kind of aspect

as well of like how people are using it so there's kind of variations um so hopefully that answered your question a little bit kind of weird end user of this needs to have some admins to the device using Microsoft Defender they'll have to disable it if they're installing of the scripts they before they yeah so uh great point about like excluding certain things um if you run just Defender friendo at home on your laptop and you clone the atomic repo Defender is going to start lighting it up it it catches pretty much all of it and a lot of Ed and AVS do um and again that's more signature based of things like there is a mimic heads binary in

there there's things like Shar pound so these different tools that necessarily bu themselves aren't malicious but can be used in malicious capacities um that that it will pick it up so there are cases where you may have to tune um prevention tools but that's also a good test right if I run this tool and I expect my thing to block it did it actually block it if not why right we all have that golden image and here's the image and I deploy it out and I expect it to work but we all know once you blow uh deploy it out a thousand times that may not be the case on all thousand systems so it's kind of a good

test of not only detection and collection but are my Prevention tools working as I expect it and kind of see that from there question any other questions anything else I can happen no awesome well thank you all again if you have any questions on Atomic red team or any just want to catch up I'll be hanging around for a little bit um thank you again for coming out and let me chat appreciate it