How To Attack A SIEM - Daniel Crossley

the others and the talk is seem escape and evade over to you thank you very much can you guys hear me now okay perfect all right well first of all thank you for coming along I know that we're competing with the bar and this is the last session so we appreciate everyone making yet to come along today um so the topic for today or the object should I say of today is talking about seam tools but what we want to be focusing on is what you could do to potentially evade the detections in a seam tool so we're going to be talking about some of the shortcomings in seam tools when it comes to threat detection

but let me maybe kind of state that three of us up here we still think that the seam is a very very useful tool right but as long as it is constrained to what we call very very tightly defined use cases and what this means is that you having a tily defined use case means that you and your company understand what the seem to does and doesn't do and also crucially can help you control the costs because you've ever dealt with outside of a scene the cost is a very very significant factor so specifically we're going to be talking about uh seen deployment profiles from an evasion perspective I think it's important to understand the

likely deployment and what that looks like uh things like agent Interruption disrupting the log source and then also ruled bypass finally we to hand over the guy here for some closing thoughts so I think some introductions might be in order first of all my name is Daniel I am the pre-sales director at Vectra AI before this I worked at logarithm if you've ever dealt with seam tools you might have heard of logorithm I was there for about 4 years before that I was at mcafe where I was the the seam specialist for pre-sales the Enterprise security manager if you've ever heard of that and then actually before that I work for an australian-based seam vendor

called Huntsman which is still around so me today I have Mr n that's my name um I didn't get the memo about the stupid photographs so mine's quite professional on the uh the slide um I work in Professional Services been doing it for about 12 13 years now um specifically in mdor and instant response um prior to where I currently work um I was very much focused on endpoint forensics um and I'm also joined by hello my name is Guy Kramer um so yeah my background is 1 years um as a um practitioner and and consultant in security operations building improving socks uh for government and Commercial entities around the world for um various companies such as Cap Gemini Rolls-Royce

and uh and and then arite don't shoot me um until a couple of months ago when I decided to um go on my own and set up my own advisory company to to help customers um so so yeah basically SE Ops veteran and um and and people process technology which is where I'm going to sort of fit into this as well um so first of all what we're going to talk about is a real life example most of you will be aware of what happened in 2017 with Cloud Hopper so ap10 uh or the pla uh where they were actively targeting uh manage service providers to be able to get through um to some of their end

customers and they were using this as a mechan ISM to obviously get hold of um intellectual property uh to be able to disrupt um customer operations now at the time I was working for a company who is actually impacted by um the breach of one of the larger msps um so what the attackers would doing we're compromising uh the mssp getting on a jump box and then from a jump box into a client environment and then I I was one of the ones using the Sim tools within that customer to be able to identify and track the activity and then we actually flagged it up to the mssp at the time which was a really interesting

conversation um so yeah at that point in time there hadn't really been much done in that area what we are seeing with what's happening at the moment um I was at um cyber threat 24 on Monday Tuesday this week with the ncsc in Sans um and you know record a future they were giving a talk around how actually China was the largest um adversar sorry adversarial uh threat that we've got at the moment even more than than uh Russia reason being because within China they've had half of the GDP go away uh they've had a number of um other changing factors which affects the amount of power that they have and the reason why they are so Keen now now to

be able to Target and focus on potentially supply chain and and mssp still is they're trying to build up their economic value by um our investment in the green energy so previously they' taken or targeted Germany where there was a lot of investment in solar power and that's why all of a sudden you then started seeing on AliExpress a load of solar power inverters and everything else well um now we're probably going to see um China f focusing on any sort of green energy and obviously with the Investments by the government um we' seeing plenty going into to Green energy as well as the S uh the uh Space Race uh which actually China publicly released that

they're going to start space program this year so there's only going to be even more Focus um on attacks similar to the original uh Cloud Hopper more and more so so this is where although these msps are providing Services it still need needs to be something that individual organizations need to be able to account for that risk in case that mssp is compromised um so you know in in terms of what it is that they were trying to to to do as I say it's mainly about say stealing intellectual property so that they can take the patents or whatever and designed and been able to recreate those um but also any sort of sensitive data that could be of interest um do

that and then I shall H over to my colleague cool thank you very much uh guys so I guess maybe let's start so who in the room feels like that they are very familiar with Sim tools put your hands up okay so there's a couple for the benefit of everyone in the room let's let's talk about some Concepts first like let's tie this back to sim or bring this back to sim what is a Sim first of all again bear with me security information event manager it's generally where you shovel all your logs okay traditionally it's been like one of the core threat detection tools for the sock for many many decades and I think

the idea of centralizing your logs for security purposes has always been a good one now Sim vendors love that because log volumes never never go down they only ever go up which means that the licensing cost goes up because Sims are almost always licensed based on the amount of logs that you shovel in there Sim vendors will also purport to say that they do other use cases like threat detection which we're going to talk about about and also threat management which they often do uh generally fairly well as well okay so that's what a Sim does the three main the three main uses for Sim log management threat detection and threat management and when it comes

to sim deployments there's many different types I think if we break this down and look at this like I said from an evasion perspective I think it's useful to understand what the likely deployment looks like because that gives us an understanding of the likely configuration of the Sim okay so you've obviously got smaller deployments and this is probably probably pretty obvious but I'll I'll I'll go through it anyway smaller deployments and we've seen many of those right and you know we're talking about situations where you might have very very basic log sources and that could be coupled with very very basic out of the box correlation rules and in in a lot of instances the alerts

that are raised by the Sim are probably not all picked up as well okay so that would be a smaller deployment now obviously Converse to that you've got larger deployments things like Banks and they would have a dedicated Sim engineering team so these are the Sims that you know quite naturally would be much more highly tuned C custom correlation rules custom detections and they would be managing their detections much more closely than a smaller deployment the other type of deployment is like a a situation where you might have a large organization that uses an outsourced uh potentially tier one socks so this is common as well right and you know not all sock providers ERS not all

tier one outsourced providers are are are similar but a lot of them what they would do is they would take the same set of correlation rules are the same set of alerts which we're going to talk about in a bit and they would overlay them across all their customer base and that's how they scale that's what they would generally do but I I think it's important to understand um first of all if you're in that situation understand what the logic is behind those rules and whether or not they are fit to reducing the risk of your of your company but from an evasion perspective it could be useful to understand that because it's highly likely that they could be using

some set some kind of publicly available outof thebox correlational and a lot of them are actually published online so let's dive into maybe just touch on some deployment profiles yeah so there's I suppose there there's three different types of kind of customer that we see we see the the small the medium and the large um of course you do see different customers different stages of life cycle and but in general when you work with a small customer they have a very specific set of problems versus what a large customer would have um on the screen here you can kind of see a breakdown of like the common use cases a customer would have starting off with just

compliance moving up towards like the sock usage all the way through to hunting for the the large kind of scale deployments um each one of those then will have their own unique challenges I said um we've worked with small organizations who uh have a very small environment very small footprint they can get logs quite easily it's typically you know cheaper to deploy easier to deploy it's based usually in SAS and I can get that data and we can see their environment pretty easily problem with them generally is a process element where they have not proper in 24x7 they haven't got the people the training uh issues like that inside their environment if we move up to scale um

we've worked also with very very large organizations I can think of one specific example from last year where an organization around 25,000 people um was very well deployed good visibility uh using a seam tool and they had a fairly major breach inside uh one of their Ms um this organization that we work with we feed into their seam as like one kind of source of information for them but in this specific instance they found that there was no visibility uh from the seeing platform itself when it came down to it it was very much about a data issue right because when it comes to these very large deployments getting the right data is extremely difficult for

those environments um so again you got to think about the kind of environment that you're working in if you are working in the seam site if you're a red teamer think about what you're targeting and those specific use cases and issues they might come across cuz they're going to be different for each deployment thank you Nile so let's pivot now and let's talk a bit more about seam tools specifically looking at the architecture so this is just an example Microsoft Sentinel very very common seam I think the main difference between Cloud seams and previous on premise seams like logorithm in arite is that the the log processing pipeline see there's a lot of components that go into

a seam right in a cloud seam it's a bit more streamlined in the sense that you've usually got agents on this side so if you've got if you've got Services if you've got servers on premise they would typically have agents installed that collect the logs and then they send that in this case via Defender for cloud but to a log analytics workspace if you're using Sentinel and then Sentinel sit alongside that okay other Cloud seams would have very similar architectures so from an evasion perspective if you're looking to evade specifically the detections in a seam there's some very obvious things that are highlighted here one of them being the agents and the other one being that

connection uh that the agent between the agent and the actual Sim right so uh talking more a bit more about log sources themselves in order for a Sim to work you need to be able to get logs into it as I said from the perspective of what we're talking about here an agent is something that sits on the server that collects The Local Host logs and uh sorry there's a bit of echo there uh but there are other ways so for Sentinal what you need is this thing called the AMA the Azure monitor agent uh and this is a fairly new seeing Microsoft have deated the MMA which is the Microsoft monitoring agent and you

need to have a server joined to as your Arc but then what that does is that collects the host logs on the Windows server and then sends them into your log analytics workspace uh there are other log collection mechanis mechanisms as well so CIS log API is very common for cloud sources uh but you can also have flat file now when it comes to seam processing any kind of issue with the collectors or the log processing pipeline leads to MISD detections and you know in our experience we've seen that many times haven't we right where alarms don't trigger because the log Source sto logging the agent went offline um or any or any manner of

things happened in that time okay so you know to talk about evasion right let's talk more about log Source disruption uh as I said MISD detections due to processing issues is a common issue with seam so if we were deliberately looking to do this some very very basic strategies could be to disable the Sim agent so go after the agent right so it might look something like this disable the Sim agent if this is a Windows machine disable the Sim agent perform some kind of action clear the windows of an log and then restart the agent very often there's some kind of heartbeat mechanism right built into it where it would alert if an agent goes offline

very often there is some kind of alarm which often isn't turned on in my experience in our experience where if a log Source if a log Source goes offline an alarm should be raised but because of the noise level of that I think that we often find that that is not often enabled right another way is to suspend the windows of end log perform the action and then unsuspend the Windows Event log so just a a very quick uh overview shall we say demo of what this would look like here what we're doing is creating a local user in order to generate in an event and what that does is that creates an event in the good old

Windows Event Viewer still knocking around evid 4720 this machine is joined to Sentinel so of course we you know to Microsoft credit the the the log appears there almost straight away in all the tests that I've ever done um so what we're doing is we we generate the log and now we're looking and and the log appears in Sentinel and now we're looking at disrupting the agent there wasn't actually a clear way a process that I could find anyway you guys might know something different but actually killing those kind of funny processors seemed to stop the AMA and then of course if we go ahead and create the user uh we still get the evid

4720 as you'll see we go back to the Windows Event log let's filter refresh but then what we do now so we get 4720 again but then you click clear log and that clears the that clears the log you'll notice that there's one left there which you'll see in a second right of course we don't get 4720 because the the event log is cleared right but you do get this other log which you'll see 110 it's called Windows Event log cleared so agent has restarted within the heartbe period we get no 4720 and then but we do get a in a second yeah there we go 110 which is Windows Event log cleared I actually

don't think I think that's a pry good scenario to set up for the SE on 112 110 uh you don't you shouldn't often get that event ID in a production environment um but the presence of it would indicate something malicious going on okay but what if we wanted to avoid that being written completely so it appears that there are ways still ways shall we say this tool is a couple of years old now what it does it suspends threads that are associated with the Windows Event log service so the Windows Event log service is still running but if we run this tool it purportedly suspends the threads so logs don't get written remember what we're trying to do

is evade detection by the seam by disrupting the actual agent itself but we're doing it in a way that avoids the heartbeat alerting okay so what I just showed you like a red team or someone could create a local user and then completely cover their tracks right and if the events don't make it to the seam the usefulness of the seam in a subsequent incident response scenario is very very limited because the logs aren't there right so here's another quick video just showing that tool in action we create a local user uh just add the username password we get 4720 uh sorry 4720 again I to speed that up a bit we see that login

Sentinel but then we run if we run our Phantom tool you can see that the Windows Event log is still running we create a local user again and then nothing's written to the event log not even one one0 so in this way you could almost completely hide your tracks on a Windows machine by suspending the Windows Event log in like I said that that tool seemed to be fairly available uh it was a couple years old but it still worked so let's move on and uh just talk about cloud like I said earlier API based and cloud-based log sources are very common in the seam these days obviously a lot of people especially here in the UK using cloud services so I

think cloud-based log sources are very important to have in the seam but it's also important to understand that the cloud logs can be disrupted as well right so a quick test we've actually got a tool that we can run this one's called hird the link is down below uh what this is is a is a cloud security testing tool and it can perform techniques in a cloud environment that would potentially be performed by a red team or or even a threat actor so in this case what we can do is suspend the logging or set a policy to disable resource logging in aour and the idea of this being that you run something like this like this halir tool you perform

these techniques like suspending uh logging on an Azure resource but you're doing it in a controlled way and uh and what you're doing is you're trying to figure out if you're going to get any if any alerts are raised is the sock notified of this if not then you've identified a gap you know because actually disabling Cloud logging I think is going to be a very quite a big thing you know from here on in so let's move on I'm going to Pivot a little bit just touch on paing if you're familiar with seams you'll know what I'm talking about paing is very very common it's what underpins a lot of what goes on in the Sim and what I'm talking about

when we when we're talking about paing is applying a regular expression to a a a a string like a log line and what the regular expression does it pulls out the interesting bits of information and those those bits of information is usually what underpins the reports uh the dashboards and also the rules as well okay so if the paing rule is not if the paing is not set up correctly then often times things just aren't going to work and your detection may not fire so that's one of the first things to check I'd say the common log sources are very often well supported by seams these days but when you get to less common log

sources and often custom log sources as well the paing coverage in our experience is just not that great right it can be complex and expensive to maintain paing rules but um but it's important to note that you know it's a problem for seam deployments I think um you know and probably will continue to be right so you know just just be wary of paing issues as they relate to to rules which I think we'll move to right now so let's let's pivot and talk about seam rules in a bit more detail cool so so um we talked a about the data and getting the data into the seam uh something the actual agent itself but one of the key

parts are the most important part once you have the data inside there is getting the rules to actually trigger on the behaviors you want to trigger on um the question is like where do these rules Come From well in a lot of places that we work with h generally the rules are coming from the seam vender themselves and these rules are typically not very robust right they're usually pretty basic and so it ends up happening with those more mature customers that they kind of figur this out over time we done red teams with different organiz ation they have to kind of augment their capabilities with new rules so they either go to third parties or they have

the teams internally start creating those rules and when I was doing the research for this I was actually going directly to like Chronicles GitHub page Splunk has a fantastic page you can go on to it gives information with actual rules themselves um but today someone pointed out a brand new website to me uh it's called control Compass it's actually fantastic if you do want to figure out about the coverage for your specific MIT techniques or what your vendor is providing to you check this website out and you can see exactly what's inside your

environment um okay so with this in mind let's take a look at actual rule itself so in this example um I just look at chronicle chronicle uses Yar rules and on the screen here you see an example of a y Rule and this one was directly pulled from um chronicle's own GitHub page now you might notice it's looking for cal. exi which is not typically a very malicious process um however uh this is actually a sample that they give you cuz a lot of red teams do use this as part of the testing Frameworks that they have at the very top you'll have kind of the details about it so if you're new to rules you can kind of see

what the mod technique it is that's trying to pick up you can see some links to what exactly uh information it might have used to generate the rule and then below this you can see exactly what the rule is in this case it's a regular expression just looking for calculate exi uh from two different sources either from the event ID of uh 4 688 or uh type one which is under the uh event ID you also have um it's looking for basically lot inside of the usual location for cized to execute from um so again a very simple uh example but what was interesting from looking through all these rules is that uh in most seam

vendors over 40% were using these kind of process-based uh detections I was quite surprised myself about this I thought it'd be kind of more robust or more kind of interesting uh rules but a lot of them are just based off this specific event ID over 40% as I said um and again just highlighting here what the the PRI is that really matters if you are trying to figure out the rule itself so you're probably thinking there must be kind of more robust rules right well again from the research I've been doing uh not really right you might find rules where it's more generic like for example if you're trying to dump credentials from a domain controller

they might just put all the different processes together into one single rule and call that um you know dumping or potential potential data dumping from the domain controller um but again in general you're not going to find find very robust rules and you also find rules that have command line arguments or they are part of the rule itself um if you do find those ones they're extremely easy to evade which I'll just talk about now in a second so once You' can identify the SC that's being used inside your target environment or if you're on the blue team side TR to figure out your weaknesses um you have to figure out how would you actually go

and evade that well there's a multitud of different ways you can do it um the most common way you do see is actually just moving the binary from its uh usual path right this going to have varant degree of success and it might have dependencies where you can't just move it easily and or you might be able to relocate it and then run it if you can the command X is pretty easy to do that with um from there you could also try to indirectly invoke it and by that I mean like not running it directly from its uh its process location and maybe run it in memory which will not actually have a log file created in the first place and

with par shell you can run like powerit you can run a reflect P injection this is a fairly common one for red teams and it's all the time no log file about that if there is a command line um this is again very easy to obate because you can actually go in and modify the command line arguments uh again bypassing the rules logic fairly straightforward I'm going to show you some examples of that in a second the last part to this is you could actually disable the logging itself as you already talked about um this one I'll talk about in a second in a slide or two but again it's going to be some challenges with doing that

itself when I was testing this I went through some examples of testing it I was using Splunk for the example Splunk is just fairly easy to spin up up as a as a lab environment all self-contained in the same system and uh it's free to to do with it as well um I also leveraged uh just some information for chronicle on their website when it comes to bypassing the command line arguments um I found some fantastic research where this exact problem has been identified by multiple different vendors out there as well as some researchers there's other good talks about this um but I couldn't really summarize it P I saw this specific slide as you can see here with

this you have the evasion types you have insertion substitution omission reordering and uh recording so the idea here is that you look at the exact logic as I've shown you in the rule itself you figure out exactly what it is that it's trying to look for in the command line and then you figure out what can actually be executed in most cases in a command line you could either like reorder the way in which you're executing the the binary or you can like put quotation marks for example in a command line all these very simple tricks will all the time bypass same rules so you might be thinking okay well I have rules in place in my scam to

identify when there is um specific like logs that have been changed or cleared on the actual uh process itself or on the endpoint uh that is true most seams I looked at have these rules in place but generally they're either informational or they're very low um uh sorry low uh priority not very high priority so you can use that to your advantage right um one of the things that you could do is you could run tools like WT util that can actually stop the processing uh of a specific event or an event going back or being created and again in my example for Splunk there was a rule for this but the nice thing about this was it was a

command line argument just put quotation marks around it and again you can buy pass up pretty easily I noce red team is in this room I don't know you guys have done this I've seen this multiple times being used and eily getting passed so again these are not complicated rules to get pass they're very very simple to default ones what else I find interesting and I think we to keep in mind here is that you know all the research I was doing around this and looking at the rules they're all the rules I could see on the public pages right either on GitHub or on splunk's own page for chronicle and Chronicle is interesting to me because

it's a fairly new one and it's getting interaction in the field we see a lot of customers deploying it um there was uh one one specific laring problem there was practically no rules around par shell which kind of surprised me so it got me thinking there's there's two things that could be happening here um one is either they are using another set of rules that we don't see publicly at say for chronicle that's probably very likely right like a lot of vendors out there will be showing you the default set they're freely to use but probably charging the customers for a second set of um of rules the second part of this is they're probably relying

on a edor agent to give them the details back to the m or back to the seam itself right and that's kind of one of the key points here is that the default rules and default logging that you can use for the seam might not be sufficient you need to have that other source of data coming into your seam to probably get good visibility into things like uh Parell the last point I want to make here is around the uh par shell so par shell I just love it because it's used by most adversaries and it will typically use it for many different stages of the attack but if you look in Splunk which has been around a lot

longer than Chronicle and you look at the actual rule set there was about 152 at the time when I was doing this and one of the key things here was the data sources right if if you actually break down where the data is coming from one of the key parts coming from is event uh block logging in Parell now this isn't fantastic log if you have enabled in endpoints that's great you got really good visibility but again in our experience most customers don't actually enable this because of the cost involved in logging it and obviously you know it's going to take a lot of data for them so that's 1002 103 was it 103 rules

in total already gone if you don't to scrip loock logging the second part you might notice there is they're relying on crowd strike as well so as I mentioned the EDR becomes a really important part to get visibility into things like par shell on the seam side yeah I was going to say there actually you know it's probably worth calling out here that most of the deployments that we've seen actually don't have any kind of command line logging in the seam right so cismon can be a very a very valuable log Source in the seam as with Powershell script block logging but there's a reason why people don't do it and that is because it's very costly especially if you got

thousands of servers and also you've got the EDR to do that as well right but I I actually have seen deployments where there is process creation logs so here's a a bit of advice if you're familiar with the windows audit policy there is a thing in there that is uh audit process creation success and failure right that would create evid 468 every single time a process is created I have seen production environments large ones as well where that was intermittently enabled across the server State and actually there is another setting with 4688 as well and that is include the command line so without the command line it's actually in my opinion it's useless like for instance you all

you would see is cmd.exe in the log if you include the command line you get cmd.exe plus the the actual you know the arguments so you know like malware would invoke cmd.exe it's very easy to tell from the command line if it's suspicious or not right so actually I would say to you if you've got 4688 enabled check you've got command line and check if you've got any rules there set up and if you actually need it because I think if you've got it enabled you could actually reduce your login G quite significantly in fact I think you could you could reduce your login G to your seam quite significantly by just doing a review of

your overall Windows audit policy so that's if there's one thing you're going to do like after this I'd say review your windows audit policy because in my experience Windows event logs is like not the not the most but it's the one of the second or third highest log volume sources in a seam right the first is often firewall logs and the other thing I'd say while I'm on that note actually the other thing I'd say about firewall logs do you actually need them in your seam if you've got them in your seam do you actually need them in there that would be my question to you what are the use cases you've got for firew war logs

most of the time it's just single bad IP address match which actually is not that useful because often times you can do that in the firewall anyway firewall threat events are useful to put in the seam but actual firewall logs tend to take up quite a lot of the volume like the and you pay quite a lot of money for them so what I would say is like question do you need them in the Sim if you need to retain them for compliance purposes you can often store them in like 40 manager or Panorama depending on the firew that you've got right so have a think about that come speak to us afterwards if you want more about that

particular point but back to the talk here right so let's let's so now that we know about Sim rules right so we know that very often um process command line is is not logged in the seam but most of the outof thebox rules are related to process command line right so make sure that you're aware of that when you're assessing your detection coverage but let's talk more about the rules that are in and working you've got logs you've got logs for and that's bypass right bypassing those rules if you're looking to evade them now the thing with Sim detection rules is that they're very often very static so most of them if you kind of you know this is why I said

before you want to lift the lid on the rules that you've got enabled or the rules that are provided to you because very often they're they're just just um some kind of threshold based which is common okay um and it can be very effective in in some cases but if you wanted to evade them then you just fly under that threshold okay so the the other some other thoughts on rules in general from what we've seen most of the SIM diplom have got several hundred rules enabled and actually the customer doesn't always know what they do you know they might have been enabled a couple of years ago uh they're not commented no one tests them that kind of

thing so you know reviewing your sim correlation rules is always a good uh activity to do because that aligns with the use cases that I me mentioned earlier but also reviewing the correlation rules understands where you might have shortcomings with regards to uh thresholds right so overall you know the for The Sims that we've seen anyway bar a few that are very very well maintained by Sim engineering teams there is a minimal detection coverage and easy to bypass kind of techniques let me give you an example right so I think this is a good example because it's a very very basic attack but it seems to be very very um effective right in fact Microsoft was victim to this uh

earlier this year and that is password spray in entra ID right so obviously I guess most of you who does any anyone not use entro ID for their users right there might be some knocking around yeah there's a few we spoke to a few earlier like Google workspace and stuff like that but by and large I'd say the majority of uh clients that we work with use enter ID right and that means that you know you can log in from anywhere right um and this what we're looking at here on the on that side is the correlation rule or the The Sentinel analytic rule from The Sentinel gith repo uh for detecting password spray in

enter ID and it's very very long right but you can see from the very start what the thresholds are it's quite it's quite simplistic I guess what it's looking for is five failed logins to enter ID um over the course of 20 minutes uh over the past one day from the same IP address okay so what a password spray is is when you try the same password across multiple different accounts and the reason you do that is so you don't lock out the account cuz you know if you type if you type your password in wrong too many times the account gets locked out so you don't want the account to be locked out so you try the same password

uh obviously you don't know what the password is going to be but you're relying on the users uh one of the users having some kind of common password but if you're if if you've got 10,000 users for instance uh there is a pretty good chance that at least one or two of them could be using some pretty basic common password right so that's where password spraying attack uh could be could be leveraged um so and also like I said knowing the deployment profile of the Sim which is what we talked about before would give us an understanding of the likelihood that this rule would be tuned okay so just doing some pretty basic testing in entra ID again back to this

hird tool very useful by the way right check it out uh you can run past spraying attack in enter ID we've got some test users by the way so obviously you want to be doing this in a controlled manner but running password spraying attack against 200 odd enter ID users using a weit of 3 seconds it tries 3 seconds tries the next account tries the next tries the next account that would clearly uh trigger the password spraying analytic in Sentinel because we are over the thresholds but something as basic as as tuning uh sorry uh setting our tool hird to wait 300 seconds in between attempts means that we're trying a password we're trying four passwords

every 20 minutes right and uh that flies under the threshold and subsequently the um Sentinal analytic rule obviously does not trigger okay so password spraying I think is a good example of correlation rule uh logic subversion and uh I think interestingly enough uh Microsoft do provide password spraying detections if you're familiar in entra ID identity protection right but those users were P2 enabled maybe it was just the way I was doing it it didn't trigger right that time anyway I have seen it trigger before but um again lifting the lid a little bit on the Microsoft enter ID ident protection password spray detection right that um that says to me that the it's fairly basic cuz what I

think they look for is a is a they look at the password complexity first of all and I think they trigger password spraying on that and then also they look at the IP The Source IP address and if it's been involved in multiple filed logins so I guess what I'm saying is there's there's not a lot in my opinion from what I've seen anyway from what we've seen in the testing we've done doesn't seem to be a lot of password spring protection in ID so you're down to the correlation rule in Sentinel which if you're using the default one which looks looks really long and it's very tempting just to take that and import it and say you got coverage of

password spraying it's very easy to subvert the logic by just you know running four passwords every 20 minutes okay so um I think what what the the key Point here is that uh a multi-layered detection approach I think is key because you know yes there are other controls in enter ID for instance if if a password spray is um is successful obviously you've got MFA and you got conditional access right and I think it's important to understand what controls you've got because if you don't have MFA right obviously you know that's a big risk right but what controls have you got in place to uh to cover you if one of them were to fail um I think with that let's pivot

back to guy you want to just give some final kind of thoughts on uh advice and mitigations on everything we talked about maybe you can just open up the questions thanks thank you um so yeah we we've heard from from Dan and now there about a couple of different or quite a few different techniques that that can be used now just to reiterate that we're not saying Sim isn't useful anymore um I think it is a very useful tool but it needs to be used in the correct Manner and needs to be treated with respect as well now what what is it you can do to try and uh mitigate some of these risks so there's three areas really that you I

would suggest that you focus on so first one is uh specifically around threat modeling so any system that you have in an Enterprise environment or or to be honest a small business as well realistically you should be using some threat modeling techniques whether you're using something that's well known like stride Etc or whatever although some of those can be sort of a bit more daunting and overwhelming in terms of the amount of effort that you have to put in it whether you've got something that's more bespoke within an organization of how you model that risk or whether it's something more lightweight like like pastor but effectively you know you should be working through your the Security

Experts right what's it going to look to the rest of the organization if um people in your your company know that actually your simol your primary security tool has being circumvented right they're going to lose trust in the detections and the capabilities that you're providing to the customer um or to to the company um so you know thinking about we were talking before about agents um are um attackers able to maybe increase the the um the log VivoCity of the um logs community so we mentioned before about firewall logs they can be very CH chatty or DNS maybe for example they increase the level of verbosity that's logging on those devices and actually it makes you hit the threshold

for the licensing for your sim some Sim vendors will still log it some will say cut off and we won't let you have any more logs come in um from a licensing perspective but actually from a hardware and performance perspective maybe it can't handle the additional throughput which means you would lose your visibility through to if it was a cloud environment potentially um if you're having additional logs coming into Sentinel for example um yes it would accept store the logs in then you're going to pay a lot of money as as long as you got enough to pay for it so do you have the additional controls in place to be able to circumvent that um

and you know what detection mechanisms have you got that can adequately mitigate that so that's why we move on to use case definition um the the people who were with me uh this morning in the workshop are probably sick of me talking about this but you know threat modeling should feed into the use cases that you're building whether it's an hybrid of a bottomup approach so for the logs that you've already got going into SIM what are the maximum valuable um alerts that you can get out of it but also actually a top down approach so almost a hybrid of when you speaking to the organization and looking at the risk Reger what are the top risks that you're

trying to mitigate against and are you actually providing suff sufficient mitigation against them um so there was a financial institution that I was working with who had a l devops teams um they were constantly pushing out updates to a service platform or SAS space platform that they were delivering um however there was no communication between the devops team and the SE Ops Team so although devops were F to push out the their new release um with still containing vulnerabilities in it that were uh potentially um vulnerabilities that a specific track actor who's already Target tting them um was able to to utilize they still did that um but actually we managed to work together and

get the devops teams and the SE Ops teams to do some threat modeling in the future and now it's a lot better because they can actually provide some at least detective capabilities to resolve that um and then finally moving on to continuous Improvement um so architectur is always changing uh within a customers environment um it becomes kind of organic as well as uh techniques obviously for attackers and it's important that you know we update the some logic Etc to be able to cope with that as well as vendors who are feeding in logs or you know for the logs to be passed with new event IDs and new things that you could be using within uh Sim so

continuous Improvement is an important part of that as well um so in essence um believe that we should still be using sin um it's just that we need to um you know as we would put best practice on to other people who aren't in security that we we need to be doing ourselves to better protect ourselves um and just to be aware of it um and for the organizations who do Outsource some of their risk effectively by using a manage service provider just some of the things that you should be thinking of in terms of the contract that you have in place with that external provider um that's that's all I wanted oh I had

to to cover on this piece so what we're going to do is is is move on to if there's any questions that anybody has yes oh sorry I didn't sorry I didn't see you were saying no in the background um right we're getting these ones we're getting these ones right so um the bar we we we'll meet you in the bar and we'll talk about it there um thank you very much everybody