SOC Adventures In TiETW

okay so to start off um put your hands up if you're on the blue team or red team in this room keep your hands up if you have no idea what that acronym T was was just on the screen okay great so I'm here with a purpose amazing um so just a bit about me uh being in the blue team about 3 and a half years um generally do security engineering architecture operations um my Twitter handle is there I refuse to call it X it's ridiculous and um I use Arch links ironically so if you're hori you can you can leave um I think I want to preface this by any you know maybe Windows internal gods that might

be in the room to please spare me I am just a simple being so we have bits of Windows internals being mentioned throughout this presentation um I am not the expert on it at all um so I'm going to make some sort of attempts at an agenda um sort of keep myself on track and I'm going to start with a backstory because everyone looks back stories I'll lay the sort of foundation of what we're talking about uh we're going to analyze what data we actually get from our EDR so in this case it's going to be Microsoft endpoint We R over some simple scenarios for what I'm looking at go down the rabbit hole a bit and then draw

some conclusions and the adventure for now um this sort of the long title of what this presentation sort of actually is there so you can sort of get an idea of what's going on that may mean nothing to you or it may have you know just a jump of words or it may mean something um and I'm going to promise now this is I'm going to aim for this not to be yet another EDR evasion detection talk where something insane goes on and nobody can um really like pull anything out of it who sort of average on on blue team and such so you know starting with a back back backstory um I had a a red te c

against organization in 2021 um the ER fell over predictably um and and in effect uh when we were doing instant response and doing the analysis we determined that the malware would utilize process injection as part of its payload and we could sort of see where it was going and and sort of analyze that and during this whole sort of process and in hindsight I started to wonder would redr fall over if any attacker came and actually just use these techniques and then I started to think well what data do we have actually you know available to in in the first place uh and just a quick primer on process injection for those who are aware and in effect it's a way to get

our evil into other processes running our system um so the idea is we can use various techniques which I will be discussing that we can effectively use for detection evasion to sort of hide where the um origin of things are coming from if if trusted process is doing weird things it's much less likely to be detected so you know we want to avoid touching is can we do all these other bits and get our code into so sort of thinking about where you are in the attack sort of um kill chain is we sort of in the execution installation phases so the attackers just got in they maybe poking about a bit they maybe looking to do a few

things and expanding this out and i' I've shamly stalling this from a kind of post on public teaming from Spectre Ops that use the same sort of like rainbow Spectrum I just really like the idea um where sort of in this big Spectrum we're kind of zooming in onto process injection as a technique so you we come from detecting wide array of of things to looking at something very specific um and within this we'll have different commonalities of techniques that Ed some will be more common some will be less common and some may not be picked up so effectively I I sort of looked at this and I said okay well with this specific technique how deep can we go in actually

investigating this can we develop sort of more accurate detections for for this sort of behavior and sort of taking all this into account we have to really look at how does an EDR work anyway so if you look at uh quote unquote official documentation from you know EDR vendors um the picture you sort of gather is generally going to look sort of like this uh it's understandable that EDR vendors do not want to publish their exact internals CU you know attackers can go ahead and um figure out how to evade them but uh some edrs will give you more some won't but this is sort of the the picture that the e v want to

believe um in reality uh this is more contextualized to denifer endpoint we'll pull back various sources of information uh few are going to talk about so C callbacks um use your sort of user mode mechanisms and also event racing Windows U which I also mention uh this information is taken from Falcon for research from the ND internal series which I'm going to mention multiple times presentation it is insanely useful if you use Defender haven't uh looked at MD internals absolutely do and we we'll take all this data uh the black magic component still say is relatively black magic but it's it's usually kind of um you know AI if else infinite you know statement or using Y signatures or we're

doing all sorts of funky things data analysis to determine what is bad and then we might get an alert and we might get some You Know sample export events in defend case we do so just going over a few of these um Kel callbacks pretty much provide a way for us within the Kel as a driver to subscribe to events that we might find interesting so I've sort of categorized this into a few categories but in a nutshell uh when we talking about in this of edrs the categories will be sort of when threads are created when processes are created uh when processes are accessed and another bit so I've kind of nicked a diagram from from forour um s of

detailing this which kind of puts in a nice um visual view for us uh there's also event raing Windows which is a pretty powerful debugging in application Telemetry utility within windows and we get all sorts of information from it depending on the application running what we're we're targeting so in net applications we have that feed in sort of directly to us and we can see function calls class names and we can use this to sort of detect evil so if we see a weird class name s of something weird going on that kind of gets seen by our EDR and we say that looks weird we're going to you know fire detection on that and we can introspect this a bit

with some various open source tools so silk eventually single Windows provides a capability for us to dive into this this is a really useful for Defenders if you're not using it you can use it it's got some built-in features to sort of stream to um Cabana and a few other places or itic um I'm not sure it has a kql or log atics stream plugin so if you're using your big Microsoft house out there that's would be nice to see included um but we can you know kind of get an idea of what's going on so and then additionally we have function hooking so when edrs uh when new processes launch um edrs May tamper with

the kind of call process that occurs within that process so um in a nut shell uh when we have an new processess load it will load the libraries it needs to to work and we can tamper with those libraries to effectively redirect execution flow to the EDR and we can introspect some bits of functions being called what's going on to to get an idea of um is it doing anything malicious and then we have the windows anti W scan interface which will in a similar mechanism will um is it acts as a a library that applications can load to effectively pass um information at run time to the Ed antimalware provider to get scanned um so you know from net 4.8

this pretty much will scan at all assemblies if if we're using net so taking all this into account um we must be pet proof this you have all these features you see all this information inside these processes the main problem with a lot of these techniques is they are we've all been the user land so if you're tampering with a process to get all this information or the process uh the things that write these events are based in the process the process can just control this and you know kind of just circumvent so with with net event tracing Windows if we have AET application which is a popular um attacker tools and tradecraft a lot of stuff is just written in net

nowadays or C shop um if we have eventually some windows enabled the component that will write that information is based in one of the DLS that gets loaded into our process so we can just go ahead tamper with that the specific component was with the event right function in ndl which is a common sort of the lowest level in all processes before we get into the colel space we just make it return immediately or tampo it in other ways we pretty much do the same thing for Amy with how am d is loaded we can just tample with the scan buffer and do a few other things that effectively mean that data just either may get passed

through but it doesn't come back as saying this is malicious to the program so stuff still executes uh and you can kind of see this in most effectively compon like Powershell um you can if you try to invoke mimik cats through a download string or something like that you'll get a block but when you sort of patch Amy you can sort of just do whatever you want and there's no sort of introspection there and then if we're being hooked we can just get unhooked so if we know what the process look like before the hook took place we can just overwrite the EDR hook to go to the function we want to go to um and then we can also there various

mechanisms to we can sort of employ here we can sort of just get fresh copy of ntl and then know what the original process information or the original sort of calls were like and and then just we you know we're good so great we we've just lost all this really valuable tary what do we have left to work with cuz we're going to presume that fret actors are you know patching this stuff out messing this stuff the the user land is is a complete Wasteland it's pretty much Fallout um Fallout 76 so you know it's the worst one um so we have colback still as obviously Kel callbacks occur within the kernel so you can't tamper

with that because it's not in user mode and we also have the kernel mode event tracing from Windows providers so any event tracing where that occurs um where the sort of thing to initialize that is with the kernel it's not sort of can't tamper with it in user mode but we still have that so finally here enters this jumble of strings I had on the screen tiw which stands for Microsoft Windows fret intelligence event tracing for Windows which is a mouthful um the Fret intelligence name is often a bit confusing if you don't know what it is I I talked to an EDR Benders and bits sometimes like um mly at a conference so not the best idea to talk to like the

sales team but they're not just not talking to me about their FR intelligence offerings um so it's FR intelligence of uh potentially abusable apis used by application not for intelligence of how usually think of it um and this pretty much operates at the colel mode so once we get into this kernel space a call will be made to check if we are actually uh logging for intelligence vent windows if we are and the call is a call we you know want to check we can go ahead and get that log so this is obviously amazing for us as Defenders because we have all this juicy data now about um process Behavior so you know we can look at what we can

we can get with e explorer you just pull this off GitHub and sort of dive into your local event tracing Windows Diagnostics and if we look at the FR intelligence component specifically we can see all these features uh these are generally going to be separated in sort of local where the activities occurring within the process and the sort of underscore remote I have a filter on there which is where we're having remote API calls into other processes or Pro from from one process to another we generally interested in remote calls for identifying process

injection so with Microsoft defend for endpoint one thing we have with independent forp point is we have the advanced hunting schema so if you use MD you'll maybe know about this um this provides all sort of Juicy telary and data we can use to roll our own alerts and kind of introspect sort of how bits of the op are working and it provides you know really big useful data so we get different sort of tables and tiw events are actually passed into the device events table so we can take a look and see what we get and per a bit of mapping so generally we can we get um the of Al virtual memory remote API call

we get uh map view Q user APC and SE for context a bit more detailed into sort of how these bits work are coming up but you know that's that's a good range for sort of things that may occur um and yeah so we can also see a few of us in here uh usefulness is debatable but the remote calls are stuff we're mainly interested in and we can also just take a look at what we're missing so we're missing um at least from the events we have in device events um changes to remote memory protection that will occur during the these sort of um person injection potentially um memory reads uh memory rights there is an event for memory

rights to Elsas but nothing else is log so that's under a different different name it used to actually be called wrbm remote but Microsoft changed it because it was kind of confusing so that's now right to memory uh a few other components that can be used for process hollowing which is pretty much where you spawn a new process um carve its guts out and shove your evil in there and then get it to R your evil and then we're missing two for the Fred hijacking component although set Fred context we do have which is used in Fred hijacking so we at least have one of those and that's usually good enough and we can also look at the

defender for endpoint timeline which is pretty much a feature where in Defender endpoint where you can look at the timeline of all sort of events going on with your or you know with a device and there will be generally more data there than there is in the device events tables or the advance hunting tables and we get some other interesting calls and bits here uh also some some bits are missing um keenly um memory remot protect and suspend for it um so we can potentially think about how to pull that out and overall I think we just want to stop a second and say okay what what should we paying attention to so we can

split API calls into sort of mechanisms to get your memory get your evil code into process and ways we can then go ahead and execute it so um map view is a way to sort of map um a sort of shared section of of memory from one process to another you can use to reflect code in process and then virtual allocators s when you want to allocate a new memory region within the process so when we sort of shove our evil into processes um you know we can call either two of these um meth methods and then for execution we can potentially use Fred context if you want to get an existing process and hijack what it's doing we

can create a Fred create Fred being a kernal call back so not tiw but um provides us with some sort mechanism to monitor going on uh and then there's also an asynchronous thread that just waits for the process to become or threads to become like alert able to see what's um going on and then execute that context and more would be nice but we've generally got plenty to to work with now so you know we have all this lovely data what could possibly go wrong and when you sort of dig into this more you realize oh the FR intelligence vacing re provider is protected by uh anti-malware processed light protection or requires a process to have a protection level in

its Access Control lists of antim light so in nutshell when it comes to process protection levels effectively within the sort of us space with Windows um processes can have different protection levels that will kind of imp access controls on uh if you want to you know um dump memory from let's say Defender you can't do that because you do not have the sufficient rights as even system running poers shell to talk to or or kind of hook into Defender um logic because they're protected with a different protection level so yeah this is this is generally very annoying and in order to you access the data we need a early launch anti mware kind of driver with a kind of

corresponding signature and we have to submit our stuff off to Microsoft validation with their H quality labs and do all this stuff uh but essentially as as a as a a poor blue team we're not getting access to this information at least directly without doing some Shenanigans you know we're not an EDR vendor so with all this you think maybe Microsoft now have a have an excellent reason for you know not letting uh standard processor get access to information maybe maybe there some explanation uh well I didn't really reach out to myself directly to sort of get information on this um I took kind of took a quote from a blog that contains some really information use uh

useful information on how the FR intelligence for Windows kind of works within the colel but as it's a quote because as I'm not saying that this hopefully moft can't do me for defamation but it's um it's extremely you know odd how they would limit this to sort of a propriety sort of Co-op program make it all restricted not publish any information about bits and it's also their operating system you know um you know Microsoft have billions but yeah but not going to say any more on that but okay so if we don't have direct access that's that's fine um we can analyze what info we do get so when we get these events food Defender is

going to generally give us the initiating process and the target process information and we don't always get the extended information that the Raw event Windows intelligence gives does sometimes we don't need this sometimes we kind of do need it it's kind of depends on what you're working with uh and that's also you know subject to context defend is not always reliable in actually giving this information so looking at some of the events in the FR intelligence event schema and mapping Defender we generally have calling process information uh create times and Target information and then depending on what we're working with we might have different parameters so um changing of remote memory protection will contain information on

the type of protection changed whether it's read write read execute what address it occurred at uh when we map this over the defender we don't usually get these extended details but what the fender will do is it will use the process start key feature within this log to map these events to process start information and then we can sort of figure out okay what process is this um what was its process file name and what was its path so we we get sort of this this juicy information when we're actually dealing with these events though not having the calling process St key or the process St key information is really annoying for do correlation if we

ever want to marry two events up not having process dark key can get very annoying so I'm not sure why they don't pass it through apparently we're not qualified to be having the process start key given to us but um yeah so that's yeah General analysis of that schema so we think we have all this juicy data we have all this this this lovely content we can use surely everyone who uses mic endpoint is is using this stuff and when I originally was sort of looking at this in 2021 it was pretty baren it's a bit better now but if you kind of look for references on the internet of some of these things specifically um the amount documentation

is you know near non-existent you generally let than 10 results with s Google search it's it's pretty abysmal um currently we have Falcon force and spectr Ops leading the way on the research and components of this and the Falcon force and the tel series amazing as already mentioned read the the internal series and kind of analyzing some of Falcon Force's alerts we can see that um we kind of a lot of what falc forces have developed is about um using a feature within Defender Advanced hunting where we use the file profile function look for remoting calls coming from processes we haven't seen before or was unseen to defender or the signatures unseen to Defender sort of globally and

then we know raise an alert and these alerts are you know often quite low um low effort and very high good very good results low low Source positives so you know we can run that ship up to sheam and job done but um I'm just wondering sort of outside these parameters you know may be um things that go on which means you're not executing from a a random dodgy process maybe you're already inside somewhere through whatever means maybe you're using D search or to hijacking to get into processes so this may not always be the case so how can we look at this and do our own detections outside of these components so you think that

should detect all this stuff perfectly because we have all this juicy data and the reality of that is it just doesn't so this can be variety of reasons mainly sort of global customer tuning you don't want a billion alerts firing out so you know some sometimes it just misses things and we could either find that out through debugging I'm not doing that that's insane or we can just mess around and find out player Defender do our own sort of purple teaming and and figure these bits out so going back to the processing section needes I talked about among them we can have many different sort of combinations variations so you let let's let's dive into some of the these

combinations and know first we sort of have classical um reflective where we just create remote Fred so we allocate a virtual memory space it writes that memory varable code create remote Fred where your code is in that process job done and then we have using uh map view with a Fred hijack which is a lot more convoluted but achieves the same result processed does our evil

Deeds um so we're going to use a combination of testing tools to do this firstly we want some tools that will give us information on what the Frat intelligence for event Windows provider is doing because we'd like to compare it with Defender and see what we could get in an ideal scenario and we're also going to look at um process toing because obviously you we need to test some of this stuff we're going to need to use some tooling to actually simulate these activities and the first stop on on this sort of uh train is going to be the tiw agents so this is a sort of Open Source tool that sort of emulates how edrs

might behave and we'll look at and watch some of these events and you can sort of like y signatures rules look at the sort of process memory that's getting written it's just a nice sort of Base nice sort of project and we're going to sign this with a different project or use it with uh this project called PPL Runner and in a nutshell we can sign our own drivers put Windows into test mode so it lets us do what we want and then get this running on anware process light so we can start doing something this investigation and debugging and then for our injection tools generally this is going to be pull stuff off the off the

internet make sure it works job done um I think one to mention is sharpen hooker is just the universally works amazingly for net applications to patw and AMZ Allin one go and doing hooking so quite nice and we can validate this evasion just have a real time on we go from events being logged to no events being logged and we go from am blocking our application from running to am not blocking application from rning so great we've sort of emulated all those user mode bypasses that we know are subject to just kind of Shing um so first test let's let's go with sort of this this classical create remote Fred mechanism and we go ahead it

win it and C Pops and Defender sees this and we get alert so fair enough moving on to map view and separate context uh we give that a go we see tiw has seen a map view remote and also a set context remote we get that action type into our events then we go look at Defender it sees it we just don't get in alert so the only reason I can sort of fathom again the black magic and optimization tuning has just decided it's not going to alert on that this is not good for us for not being able to just detect this blatantly obvious process injection but we can see the events um interesting enough Defender

will flag this as a cyber data true or a one cyber event which Aggregates a bunch of stuff that um in a nutshell if any finds interest so let's just do it ourself so you know we see set spread context from our API call we're going to join the map view section occuring and we're pretty much just able to determine that pretty easily uh and then we have learn and we can go further with that if we want to perform some extra optimizations depending on um the Fidelity a new own environment so we can just also join information on network events if a remote FR is created or something some activity like this happens and

immediately get a network event is generally indicative that as an attacker we're moving about trying to get our kind of calls and um command and control structure into other processes so if this happens then we immedately get a network call back that's weird so we can Le on that and also one has EV ID free for network connections so depending on what you're using you can maybe sort of translate this logic to your own EDI environment depending on if it gives you this information um and then I do want to a point on when we're doing call mapping with you two or more calls and we're trying to correlate events because we don't have the calling

process start key it's a bit chaotic we can pretty much pick a mix of press ID information Target information ning information device and then do time correlation and if we do all that we generally get a pretty reliable detection um so but it is easier than sort of doing this when we have map view so in my environment I have about 800 end points the only thing that actually uses map view is Firefox and its own child processes I don't know what's going on there but I just sort of assumed okay um if a map view call happens to a process from a process and the image path is both the same we don't care and on the

past um you know seven days in my environment I get nothing in the past 30 days I get free alerts so pretty much for any any red teamers that might be using map view out there um it's really easy to detect depending on your you know environment your mileage may vary but for what Defender doesn't detect we can just detect that pretty easily and I went okay let's let's kind of the scales a bit what about some of SN so we detected set context with map view map view being rare but let's change to allocate virtual memory remote which is a lot more common um we also going to look at just not playing with

Freds also kind of threadless and also asynchronous cues asynchronous cues is actually even defended detector it was actually very easy and I also want to introduce a new category here called sort of the defender Plus+ C I'm calling it but in a nutshell we're just sort of pulling information from the timeline to enrich our alerting so what Defender doesn't give us we can just try try and grab out and we're going to change tools here so to kind of scale a bit more so there's a utility called seitter for um etw research that is really useful and I've switched it because it's um let us kind of stream process in a way that's and get events it's just just more

efficient and I think also considering what we're doing having to resign every time we reboot and do all this stuff with Windows test mode is it's just annoying uh it makes testing more difficult so can we just not use it and you know it turns out we we can in a way um so fun fact for about 3 years there was a exploit within windows that basically bypass process protection entir and Microsoft took AG to fix it and born out of this the auor of SE actually devop a fork where they would use this exploit to elevate their own process to anti mware protection light to get this data so you know obviously that's patched now so we can't really do that

anymore but you know we could have done that on our production environments do you want to use an exploit to get data that may let you do detection engineering better it's it's a gray area but so that's no long thing anymore but we do have the ability to also use vulnerable kernel drivers so we have a utility that exists called the kernel driver utility really it should be called the kernel driver abuse utility but the author of SE lighter um made a p request into this component to add a feature to elevate to antimalware per subsection light and when we compile this and and one this depend doesn't actually care about it it it does seem

to pick it up if if you have potentially unwanted application detections on but it you don't get a detection when you're using this which is a bit weird um it doesn't work if you have um hypervisor code Integrity on and you're using core isolation but elsewise generally seems to be fine and when we sort of um kind of get this and map this process information when we have this data we can pretty much take these these process St keys and sort of build our own um pretty much process analyzer to see what's existing and then just do the image joining ourself so we have all the information and we have the capability now to pull these FR intelligence vent

windows events without having to use test mode and we can just use an exploit and do what we want um to PR much run that and get it into process protection like so we start processing this data um probably still not a good idea to do in production though um for for reason um if you don't have hypervisor code Integrity on you could do it but if you don't have that you probably have bigger problems so you know with all this data what we have to do is just sort of manually map what the process information is and then write a bunch of horrible Powershell features and bits and we can get the FR intelligence data

into our log analytics work spaces and have something sensible to work with and en join that information enrich it as we uh and then considering the sort of other category I introduced which was the sort Defender Plus+ category how are we getting that data so it turns out within the defender timeline when you sort of look at that you can kind of interp the network what what's going on there it's going through an API proxy but there's this component that will tell you the source URL or Source URI that it comes from and effectively comes from what effec is the production defend endpoint sort of service AP so we can just make direct calls to that

and get information back so you can sort of kind pull that timeline information in and get you know what we care about now doing this is a bit dubious um there's no real explicit guidelines around using this and we can try to stick to some established components but it's it's really just kind of me making up new new limits um so if you want to pull all seven event types of interested in we could do TW form over sliding scale it's more kind of use it your own um risk really and we can optimize what data we pull back from this and sort of you know do this in a bit quicker of a sense so

we can use the search field to of look for some of these these events and these protections that we care about and we can also use defend of harvester so you don't need to use or write your own terrible monstrous power scripts or or whatever to pull things back um recently in October uh a new MD internals came out where the F for actually releas a tool that we could just use to do this so very useful use a vendor Che it out contribute to it very nice and then we need to S decide what to pick so I just went for memory protection and resume thread events and okay so we now have a way of correlating

this W data practically we never use it in production environment is useful to see sort of what's going on and we have our Defender Plus+ data grab that we can sort of Agate with bits so let's give this a test so with the virtual ex context we have both these events we'd assume that there' be absolutely no problems it should be PR easy getting all this information and okay fine let's let's take some statistics so um virtual memory mode very common FR context less common so kind of progressing with that let's go run the simulation look what's going on we see that Defender seems to not be able to map the initiating process information for what's going on so

that's that's weird but we still get like another event that's is quite useful that we could potentially sample out and then we take a look at the set for context call we realize it's just not reporting process ID initiating information all and when we look at the actual raw API we see it's just not there which makes mapping it a nightmare then we look at the intelligence Windows do a bit sanity check everything's there it's fine so okay let's try to do time correlation so we have we know what was targeted we just don't know what did it so when we join these events we can sort of try to do time correlation that usually would work um in caveat is that

when these events are shoved into our logs the seate context seems just all be led together and we don't have the time stamp initiating information so we we can't really kind of do time correlation effectively we doing about 30 minute span but not within 5 seconds and I was interested about looking to this so I kind of also did a few other bits I noticed that the in allocate virtual memory was also delivered 10 minutes late exactly each time uh I test this across production environment test both seem to have results so you know you can maybe do some magic on trying to analyze what this difference is and then pull it back to what it should be but um it's

sort of in the air so we can go again on this expand the time correlations 30 minutes what we can do as well with this is pretty much use the sort of past 14-day trick which if you use sentinel you you've probably tied of using this Microsoft Sentinels Max look back is 14 days so in effect we'll look at at the current hour we'll look the past 14 days we'll get rid of everything for the past 14 days and we'll look for just where this happens newly and in in kind of places we haven't reserved it before and we do that and we Implement detection and we get a result so you're able to sort of detect that mileage may vary but

we managed to pull it off um then looking at Fred suspend I did look at this waited a few hours I didn't get anything so I I don't know what happened there but it's there appar a lie and bit of Sanity check on this sort of initiating post information I thought well what if um the device events are just being outrun so or the actual you know it's running too fast for the defender to do something about it and I you know waited ages and still nothing so when this does happen there's a chance with Fender either the initiating process information will just be not existent in this call or there'll be no process information at all you just have

process IDs uh which sucks uh makes correlating these events just awful so I went ahead looked at some statistics some bits how reliable is Defender statistics generally we had some instances where you know we have no initiating info where we'd have no info at all um is generally reliable with everything but set Fred context API call which just had nothing anywhere uh and it also included create remote thread API call which is Kernel call back um so just to see the difference so they should be using a system but it's still not 100% reliable so don't know what's going on there um you know maybe it's a a Tuesday and rainy and that's that's why Defenders just decided not to give

us that information I don't see any reason why it would't give the information we have it so bits me on on why exactly is is occuring the using FR intelligence Ving Windows the result is yes yes we we do we are able to win a monstrous cre to join all this information together and get a examp so um then one of technique I want to mention is kind of using frad list so we've looked at um things that manipulate Fred context and creation of Freds but what about just allocating virtual memory so besides come3 there was a talk called Fred inject by Sir goor and this is pretty much a method to sort of tamper with the memory processes

in order to kind of hook components and um kind inject code and get to run things in a way that just don't involve Creations so not really explaining it here go watch the talk and I went to go get it running seems that Microsoft saw the talk and wrot a detection for it and all I had to do to bypass that was add a no operation in the middle of the the Shell Code it it used and there's no behavioral signatures so I'm good to go uh if we're just using War Defender events this is just part of the text excluding profile app you get one virtual memory API call not very practical if we're using sort of the

defender Plus+ bits um we'll notice that the process information initiating process information or flip for some reason um we can sort of work with that but it's a bit annoying but you know Defender does see this and I've ran this about 710 devices had about 14k of these events occur in the last 24 hours um shoved it into log analytics for insanity and then we can sort of you start working with that data so you know looking at the components we can see you know maybe we could WR some detections based on the region size but you know this could be changed by attackers um some bits with how this this sort of works is at the moment the memory

protection regions will will fluctuate so you kind of get this pattern occurring so you profile that um but what you also can do is just join this information with the um a few few other components um so M protect with allocate within a relative time do some time correlation and I managed to actually get a working alert out that that wasn't too prolific but your marage is going to vary quite heavily on that uh and looking at event racing windows we have Additionally the memory protection sort of um kind of change that occurs we don't get that from the defender but that's also pretty useful and just a quick detour we do actually have local memory protection events in

an action type so but we don't have any information on what the protection change was so there there utility called thew um fluctuation monitor that's been black hat talk and the idea behind that is if you mark a coopay re execute it shouldn't be changed back so if defend if Microsoft actually gave us information on the change of the memory detection we have to sort of implement this ourselves and look for potential sort of malware inside process but we we just don't get that but just want to DET talkers on Tope interesting um Q user APC is ridiculous easy to catch um def call it within 30 minutes got an alert that's great um and

looking at our own environment in the past 90 days I did not see that API call anywhere which is pretty prolific so um or pretty significant so we can just go ahead write alert see that probably even um and then just want a quick mention for the Falcon Force rule sets so looking at virtual memory allocations from unknown processes is generally very reliable low Fidelity past 30 days I have 10 results um so yeah we can go ahead and use that but we want to consider whether we should we probably shouldn't be letting these unknown processes run in the first place so you know we can use we can sort of block that with Defender attack surfice

reduction rules but yeah just a sort of a detour looking at Defender forces components there and you know we can sort of dive into sort of the black magic occurring with in Defender here so within the create remote Fred I thought well what if we just do nothing for 10 minutes and I added it in no no alert so if you're if you're in doubt if you're on the red team just wait 10 minutes before you issue a remote for recreation it should just escape the sort of logic that the defender has set for protecting this stuff easy um so obviously I've talked about kind of a lot I want to make generally Fair EDR veners need to strike a balance

between noise and detections fair enough that some stuff isn't detected and more event processing is higher cost sort of pushes people out the market prices go up um but In fairness for some things it'll just be nice to see these world events because um when you sort of put this in the hands of the sock you're going to get better sort of alerting detection more more fining components uh practicality of using some of these bits hammering the ND service API is probably not a good idea but you could sort of Target effectively mainly doing instant response if you're doing in response few devices pull all the information get into L analytics boom you've got something you can actually process in

insane way that's not going to drive you mad if you if in response with MD scrolling through the timeline you've actually want to throw yourself out the window it's horrible um and you know production we're most not not likely to use col exploits to get tiw it's a bit probably not a good idea as a Defender to be breaking your own systems um but monitoring processes we can sort of get rid of the chaos here so overall if there's anything to sort of take away as as things we should aspire to uh influence on ERS Microsoft Etc um if we had access to this information we could do all sorts of wild Solutions where we

could you know potentially write components scripts bits on end points to sort of inspect this what's going on see these components and do do all this crazy stuff that would let us sort of go into what's getting written memory bits and we can sort of do a lot of cool stuff and why shouldn't EDR Solutions be allowed to you know let you get some of this data so unless the Big B wolf says no but I'm not sure about that um um overall to be continued we could you know use potential ideas so with in Sentinel we have Jupiter notebooks we could do some AI ml buzzwordy stuff analyze all these various calls come up with something

that you know implements some detections with these um we could if you're using Microsoft if you know the stack you hook to logic apps that do weird and wonderful things dump process memory take screenshots do all these one components via open source tooling we can use for in response uh kind really thinking on the sort of sore mindset uh and really concluding it'll be nice if Microsoft could pretty pre um give us access to the data they probably won't but we can we can annoy them um if your sock can't hack the planet how are they going to defend it so you know give you if you have sock you know you sort of time the allocation to sort of um I

wouldn't say reverse engineer the EDR tools because that's definitely against terms and conditions but you inspect how they work find out these components understand thry and events and if you're a red teamer um avoid map view and apq opt for Fred lless because it's very hard to detect and really the tiw it's not actually that scary because no one seems to use it properly or at least Defender doesn't and finally at my end of my ramblings so that's all I had um I don't believe we have time for questions um yeah I believe uh we are we've run a little bit over but yeah no uh give a big hand to [Applause] Luke