WEBVTT 00:00:10.560 --> 00:00:12.859 Welcome to another episode of the Everyday Defender 00:00:12.859 --> 00:00:15.380 podcast. Super excited to be recording again. 00:00:15.519 --> 00:00:18.440 My name is Chris Goosen and I am joined as always 00:00:18.440 --> 00:00:21.300 by my friend from the Netherlands, Koos. Hey, 00:00:21.320 --> 00:00:23.579 Chris. Good morning. How are you doing? Doing 00:00:23.579 --> 00:00:26.339 well. Hey, it's been a month since we last saw 00:00:26.339 --> 00:00:28.120 each other. Can you imagine? Can you believe 00:00:28.120 --> 00:00:30.120 that it's been a month? Crazy. That's really 00:00:30.120 --> 00:00:33.460 crazy. That's really crazy. It feels like last 00:00:33.460 --> 00:00:36.170 week or something like that. Yeah. man it really 00:00:36.170 --> 00:00:39.130 does hey um i'm still trying to get my sleep 00:00:39.130 --> 00:00:42.070 back back on track which is wild right that i've 00:00:42.070 --> 00:00:44.609 been i've been home now for you know i don't 00:00:44.609 --> 00:00:46.070 know three four weeks and i'm still trying to 00:00:46.070 --> 00:00:47.810 get my sleep back on track after that trip that 00:00:47.810 --> 00:00:50.609 trip completely messed up my my sleeping patterns 00:00:50.609 --> 00:00:54.750 um which is a very strict procedure when it comes 00:00:54.750 --> 00:00:57.210 to getting my sleep back on track so i try to 00:00:57.210 --> 00:00:59.189 sleep a little bit on the plane back to europe 00:00:59.189 --> 00:01:02.030 and then i really want to stay awake that first 00:01:02.030 --> 00:01:04.209 day so i actually planned a birthday party of 00:01:04.209 --> 00:01:06.609 a friend of mine and we went to that party so 00:01:06.609 --> 00:01:08.930 i'm i was sure i wasn't going to sit on a couch 00:01:08.930 --> 00:01:11.950 and fall asleep during the day to keep up all 00:01:11.950 --> 00:01:15.049 the way until the night and then keep stick to 00:01:15.049 --> 00:01:18.030 my regular schedule immediately and it seems 00:01:18.030 --> 00:01:20.760 to work for me Yeah, fair enough. Yeah, I actually, 00:01:20.799 --> 00:01:23.859 I got home on a Monday morning and I worked on 00:01:23.859 --> 00:01:25.739 that day. So I went straight from the airport 00:01:25.739 --> 00:01:28.200 at 6am to, well, I didn't go to the office, but 00:01:28.200 --> 00:01:31.700 I came here and logged on to work. So I did try 00:01:31.700 --> 00:01:34.340 and stay awake all day too, but man, it hasn't 00:01:34.340 --> 00:01:41.280 helped. Anyway, in today's episode, one big topic, 00:01:41.340 --> 00:01:44.659 I guess, right? We're looking at Defender XDR, 00:01:44.840 --> 00:01:47.709 the attack disruption feature. And I know this 00:01:47.709 --> 00:01:48.870 is something that you've been really sort of 00:01:48.870 --> 00:01:51.750 digging into and you're quite excited about. 00:01:51.870 --> 00:01:54.409 So I figured, you know, let's have a conversation 00:01:54.409 --> 00:01:56.469 about this and sort of tell the good folks what 00:01:56.469 --> 00:02:00.150 this is all about and how it's matured and developed, 00:02:00.310 --> 00:02:01.730 right? Because it's not a brand new thing. It's 00:02:01.730 --> 00:02:03.750 been around for a little while, hasn't it? That's 00:02:03.750 --> 00:02:06.010 true. I think this is one of the most exciting 00:02:06.010 --> 00:02:09.550 features, part of Defender XDR. So I think it 00:02:09.550 --> 00:02:12.050 deserves its own podcast episode, to be honest. 00:02:12.729 --> 00:02:15.810 Yeah, you're right. Attack Disruption is around. 00:02:15.969 --> 00:02:19.150 It released somewhere in 2023. I don't know the 00:02:19.150 --> 00:02:22.090 exact month, to be honest. So it's already here 00:02:22.090 --> 00:02:25.430 for, let's say, two years. But obviously, Microsoft 00:02:25.430 --> 00:02:28.530 is adding new and new features and new capabilities 00:02:28.530 --> 00:02:32.569 and scenarios to it. And I really saw some really 00:02:32.569 --> 00:02:37.949 impressive demos last couple of months, and I 00:02:37.949 --> 00:02:40.669 wrote some blogs about it. So that's why I thought, 00:02:40.729 --> 00:02:44.080 well, We should put some effort in this and share 00:02:44.080 --> 00:02:46.460 it with the world because I think this is a prime 00:02:46.460 --> 00:02:50.860 example of how all the different defenders, so 00:02:50.860 --> 00:02:54.479 to speak, can work together in a great way. So 00:02:54.479 --> 00:02:56.620 what it actually does, it attacks disruption 00:02:56.620 --> 00:03:00.800 like the name suggests. It is meant to disrupt 00:03:00.800 --> 00:03:05.460 an attack while it is taking place. So normally 00:03:05.460 --> 00:03:09.960 your security product, a regular EDR or antivirus 00:03:09.960 --> 00:03:13.210 would... work something like we saw certain events 00:03:13.210 --> 00:03:16.330 here's the evidence please investigate it and 00:03:16.330 --> 00:03:19.189 respond to this and microsoft wants to move away 00:03:19.189 --> 00:03:21.250 from this more and more and they want to provide 00:03:21.250 --> 00:03:24.629 actual protection and stop the attackers in their 00:03:24.629 --> 00:03:27.129 threats when they're active and that's what attack 00:03:27.129 --> 00:03:31.750 disruption is all about yeah and i i can see 00:03:31.750 --> 00:03:36.939 i can see why um you know you mentioned um how 00:03:36.939 --> 00:03:38.979 all the defenders work together right and i can 00:03:38.979 --> 00:03:41.699 see you know i've been saying for a while that 00:03:41.699 --> 00:03:44.080 we're in this world now where we have you know 00:03:44.080 --> 00:03:46.460 we used to have um this mentality of like best 00:03:46.460 --> 00:03:49.280 of breed where organizations wanted to go out 00:03:49.280 --> 00:03:51.759 and buy the best product in each sort of domain 00:03:51.759 --> 00:03:53.879 right you bought the best av from that vendor 00:03:53.879 --> 00:03:55.979 you bought the best other tool from that vendor 00:03:55.979 --> 00:03:58.599 um but i think we're we're in this world of like 00:03:58.599 --> 00:04:00.960 best of platform now where you've got to be able 00:04:00.960 --> 00:04:03.319 to look at a vendor that has a platform that 00:04:03.319 --> 00:04:05.379 that supports all of these things and and so 00:04:05.379 --> 00:04:07.879 i'm you know i can see when you say all the defenders 00:04:07.879 --> 00:04:09.539 working together i can kind of see where this 00:04:09.539 --> 00:04:12.840 might be going as far as we've got signals from 00:04:12.840 --> 00:04:15.159 you know an endpoint product we've got signals 00:04:15.159 --> 00:04:18.040 from other um defender products all kind of working 00:04:18.040 --> 00:04:20.240 to to disrupt something that that might be going 00:04:20.240 --> 00:04:22.899 on in the environment Yeah, and that's also a 00:04:22.899 --> 00:04:25.300 bit good that you touch on this. It's also a 00:04:25.300 --> 00:04:27.819 part of the confusion sometimes because Microsoft 00:04:27.819 --> 00:04:31.300 talks about Defender XDR as if it is a single 00:04:31.300 --> 00:04:35.300 product you can buy. but it's actually the encompassing 00:04:35.300 --> 00:04:38.500 platform containing all the different security 00:04:38.500 --> 00:04:41.939 products you have to buy separately or buy E5 00:04:41.939 --> 00:04:44.379 and you'll get all of them, but you have to set 00:04:44.379 --> 00:04:46.540 them up individually. And that's also what I 00:04:46.540 --> 00:04:50.600 wanted to touch on on today's episode. It is 00:04:50.600 --> 00:04:53.279 enabled by default, but it is best practice to 00:04:53.279 --> 00:04:57.220 make sure that everything's set up properly according 00:04:57.220 --> 00:05:01.560 to best practices to work most optimally. Yeah, 00:05:01.579 --> 00:05:04.240 so like you said, it combines a lot of the signals 00:05:04.240 --> 00:05:08.060 from all of the different Defender products. 00:05:08.459 --> 00:05:11.720 Well, not all of them right now, but again, Microsoft 00:05:11.720 --> 00:05:17.959 is expanding on that every time. When you read 00:05:17.959 --> 00:05:21.019 into this, you always come across a lot of the 00:05:21.019 --> 00:05:23.639 marketing mumbo -jumbo, I would say. But some 00:05:23.639 --> 00:05:26.259 of these terms Microsoft uses, I really like. 00:05:26.300 --> 00:05:28.339 So I wanted to, with a little bit of a nod, I 00:05:28.339 --> 00:05:32.220 did put them in the show notes. So Microsoft 00:05:32.220 --> 00:05:35.980 talks about... When they do things in real time, 00:05:36.160 --> 00:05:39.399 they're talking about at machine speed. I find 00:05:39.399 --> 00:05:43.920 that a very interesting wording. And they want 00:05:43.920 --> 00:05:46.779 to stress that they only apply attack disruption 00:05:46.779 --> 00:05:49.720 when they're very confident. So high confidence 00:05:49.720 --> 00:05:53.279 signals, of course, because you want to prevent 00:05:53.279 --> 00:05:56.259 further damage. But on a false positive, you 00:05:56.259 --> 00:05:59.879 might include damage without an attack, right? 00:06:00.500 --> 00:06:04.879 So I think that's important. so it works through 00:06:04.879 --> 00:06:08.060 some some separate separate stages so you have 00:06:08.060 --> 00:06:10.360 the detection part again where you correlate 00:06:10.360 --> 00:06:13.560 all the different uh signals and in a high confidence 00:06:13.560 --> 00:06:17.360 incident then they want to correlate those uh 00:06:17.360 --> 00:06:20.240 signals because for example something the fan 00:06:20.240 --> 00:06:23.259 of identity saw on the identity part and something 00:06:23.259 --> 00:06:25.579 that the fan of our endpoint saw on an endpoint 00:06:25.579 --> 00:06:29.779 might not always be uh uh correlated together 00:06:29.779 --> 00:06:32.579 right the the not might not be the same attack 00:06:32.579 --> 00:06:34.970 so they need to correlate that and then they 00:06:34.970 --> 00:06:37.529 use something they call intent recognition. So 00:06:37.529 --> 00:06:40.069 they have all kinds of scenarios predefined. 00:06:40.290 --> 00:06:45.189 They don't tell much about what kind of scenarios 00:06:45.189 --> 00:06:48.930 are supported for obvious reasons, but they have. 00:06:49.590 --> 00:06:52.410 apparently done a lot of research in this to 00:06:52.410 --> 00:06:56.870 identify certain, well, familiar attacks they 00:06:56.870 --> 00:07:00.629 saw on different organizations or in their own 00:07:00.629 --> 00:07:03.870 environments. And also they're using the organization's 00:07:03.870 --> 00:07:06.569 attack paths. So we talked about this a little 00:07:06.569 --> 00:07:08.990 bit earlier. Defender XDR can show you attack 00:07:08.990 --> 00:07:12.490 paths. So your vulnerable machines or... how 00:07:12.490 --> 00:07:16.089 everything's linked together in a graph, so to 00:07:16.089 --> 00:07:18.110 speak. And they actually use that information 00:07:18.110 --> 00:07:22.269 to see, okay, when something happens on this 00:07:22.269 --> 00:07:24.810 part of the graph and then the next link is touched, 00:07:25.129 --> 00:07:28.410 it might be an attack happening because those 00:07:28.410 --> 00:07:32.129 two are linked together. Yeah, and then actually 00:07:32.129 --> 00:07:36.629 the attack disruption takes place and it tries 00:07:36.629 --> 00:07:39.709 to identify compromised assets. So for example, 00:07:39.709 --> 00:07:43.790 users, devices, mailbox, apps. So this already 00:07:43.790 --> 00:07:45.889 gives away a little bit of what products are 00:07:45.889 --> 00:07:48.410 used in the back to determine what Microsoft 00:07:48.410 --> 00:07:51.509 calls the blast radius. And it's also a great 00:07:51.509 --> 00:07:54.250 marketing term. I really like when they use it. 00:07:54.600 --> 00:07:57.560 You don't want it to happen, but when people 00:07:57.560 --> 00:08:00.519 talk about blast radius, I'm thinking about explosions 00:08:00.519 --> 00:08:06.300 and bank heists and whatnot. So once they determine 00:08:06.300 --> 00:08:10.240 the blast radius, they know what compromised 00:08:10.240 --> 00:08:12.959 assets are part of the attack, and then they 00:08:12.959 --> 00:08:17.620 can in real time block these, contain these, 00:08:17.740 --> 00:08:23.949 and prohibit further actions. um yeah and obviously 00:08:23.949 --> 00:08:27.069 microsoft will tell you that it is ai powered 00:08:27.069 --> 00:08:29.750 because everything is ai powered nowadays right 00:08:29.750 --> 00:08:33.070 that's right that's right i can imagine they 00:08:33.070 --> 00:08:35.929 use a lot of machine learning algorithms to to 00:08:35.929 --> 00:08:39.490 uh detect certain patterns uh but everything 00:08:39.490 --> 00:08:42.110 machine learning is nowadays called ai i guess 00:08:42.110 --> 00:08:44.370 so well fair enough but you know i think what's 00:08:44.370 --> 00:08:46.750 interesting here is so you know during the sort 00:08:46.750 --> 00:08:49.159 of detection phase here they they stress and 00:08:49.159 --> 00:08:51.500 when you read the microsoft documentation on 00:08:51.500 --> 00:08:55.259 this as well high confidence is is continuously 00:08:55.259 --> 00:08:58.399 stressed right and i imagine that that's because 00:08:58.399 --> 00:09:01.039 they are looking at multiple things that are 00:09:01.039 --> 00:09:03.500 happening in multiple places and being able to 00:09:03.500 --> 00:09:05.100 like you said correlate them together to say 00:09:05.100 --> 00:09:07.179 okay well we know for sure that if we see this 00:09:07.179 --> 00:09:09.539 thing happening on the endpoint and this thing 00:09:09.539 --> 00:09:12.259 happening on the identity um and this perhaps 00:09:12.259 --> 00:09:15.159 this other um thing happening we know that those 00:09:15.159 --> 00:09:17.320 things go together in a particular type of attack 00:09:17.840 --> 00:09:20.980 um and and that's how they know for sure right 00:09:20.980 --> 00:09:22.980 the height the high confidence and i if i remember 00:09:22.980 --> 00:09:25.299 correctly from from some documentation i read 00:09:25.299 --> 00:09:27.120 they they actually have a number that they put 00:09:27.120 --> 00:09:29.980 to it right for high confidence like 90 99 .5 00:09:29.980 --> 00:09:33.220 or something like that um yeah they say 99 percent 00:09:33.220 --> 00:09:37.000 uh so they they will also tell you less than 00:09:37.000 --> 00:09:39.519 one percent of false positives so they are right 00:09:39.519 --> 00:09:43.610 above 99 but they don't specify any uh A decimal 00:09:43.610 --> 00:09:46.830 number there. But indeed, they want to stress 00:09:46.830 --> 00:09:50.169 that only when they're very confident, then they 00:09:50.169 --> 00:09:53.129 go into action. And they actually use all of 00:09:53.129 --> 00:09:56.269 the telemetry in your environment. So when you're 00:09:56.269 --> 00:09:58.870 still in control, so when Microsoft decides to 00:09:58.870 --> 00:10:01.470 perform actions as part of the tech disruption. 00:10:02.330 --> 00:10:04.950 The incidents and alerts are also in your incident 00:10:04.950 --> 00:10:07.309 page, right? And they will tag that incident 00:10:07.309 --> 00:10:10.649 attack disruption to let the SOC analyst know 00:10:10.649 --> 00:10:13.850 that Microsoft was involved in some of the response 00:10:13.850 --> 00:10:16.769 as part of the incident. But you are still in 00:10:16.769 --> 00:10:20.019 control and Microsoft will. will pay attention 00:10:20.019 --> 00:10:23.860 to the telemetry data following up an attack 00:10:23.860 --> 00:10:26.700 disruption action to see how the SOC responds. 00:10:27.139 --> 00:10:30.299 So if attack disruption, for example, disables 00:10:30.299 --> 00:10:33.259 a user and the SOC immediately re -enables the 00:10:33.259 --> 00:10:35.440 user again, that might be useful information 00:10:35.440 --> 00:10:38.940 to Microsoft to learn for next attacks to even 00:10:38.940 --> 00:10:42.960 improve that number to a higher one. Now, for 00:10:42.960 --> 00:10:45.360 someone who hasn't... been across this or come 00:10:45.360 --> 00:10:47.519 across this before this might sound really scary 00:10:47.519 --> 00:10:49.580 because you're thinking in your mind right now 00:10:49.580 --> 00:10:53.080 the environment is just doing its thing it's 00:10:53.080 --> 00:10:55.080 just doing stuff without me knowing right and 00:10:55.080 --> 00:10:58.120 i guess that's kind of fair in that they are 00:10:58.120 --> 00:11:00.539 stepping in and they are taking disrupting attacks 00:11:00.539 --> 00:11:04.659 right before you can but these these um the scenarios 00:11:04.659 --> 00:11:08.080 where attack disruption occurs they are very 00:11:08.080 --> 00:11:10.720 very sort of stiff right there are very specific 00:11:10.720 --> 00:11:14.480 scenarios that microsoft have worked on where 00:11:14.480 --> 00:11:17.200 they've over time they've they've they've uh 00:11:17.200 --> 00:11:19.879 i guess identified these specific scenarios whether 00:11:19.879 --> 00:11:21.820 we know they're high risk but they've also been 00:11:21.820 --> 00:11:24.539 able to identify all of the related signals and 00:11:24.539 --> 00:11:27.179 actions and stuff you know events and incidents 00:11:27.179 --> 00:11:30.639 that happen and so they know when they see all 00:11:30.639 --> 00:11:33.220 of these things it makes up for example uh you 00:11:33.220 --> 00:11:35.539 know a business email compromise attack and and 00:11:35.539 --> 00:11:37.879 they know then how to get it right um what are 00:11:37.879 --> 00:11:40.159 those What are those? There are a few of them. 00:11:40.240 --> 00:11:42.139 It's like three or four of them. This BEC is 00:11:42.139 --> 00:11:44.580 one of them. What are the other ones? Yeah, human 00:11:44.580 --> 00:11:47.059 -operated ransomware is one of the examples. 00:11:47.379 --> 00:11:50.799 And there were a couple of scenarios, adversary 00:11:50.799 --> 00:11:52.720 in the middle, of course, password spray attacks. 00:11:52.940 --> 00:11:55.740 But again, they don't disclose every single scenario. 00:11:55.879 --> 00:11:58.360 These are just examples they put in the documentation, 00:11:58.399 --> 00:12:02.389 just to stress that they are basing them. upon 00:12:02.389 --> 00:12:06.370 some hypotheses they created up in advance, but 00:12:06.370 --> 00:12:08.590 they will not disclose all of the details because 00:12:08.590 --> 00:12:11.049 then you might know how to work around them. 00:12:12.509 --> 00:12:16.289 But yes, it is a valid point. So based on these 00:12:16.289 --> 00:12:19.190 scenarios, they try to do the correlation. And 00:12:19.190 --> 00:12:22.590 again, even if you are that 1 % or less than 00:12:22.590 --> 00:12:27.110 1 % scenario and a tech disruption did contain 00:12:27.110 --> 00:12:30.139 a device or user or whatever, there might be 00:12:30.139 --> 00:12:33.440 impact but i think the trade -off is if it was 00:12:33.440 --> 00:12:36.440 a real attack the impact would have been much 00:12:36.440 --> 00:12:39.759 larger than just an inconvenience for for a couple 00:12:39.759 --> 00:12:42.740 of users right yeah yeah that's fair that's fair 00:12:42.740 --> 00:12:47.059 enough and but but but uh i i know uh the larger 00:12:47.059 --> 00:12:50.139 the the organization is the more uh stressful 00:12:50.139 --> 00:12:53.559 they get about these kinds of topics so um when 00:12:53.559 --> 00:12:56.100 i saw the fan of endpoints being enrolled in 00:12:56.100 --> 00:12:59.559 in larger corporates i know they didn't like 00:12:59.559 --> 00:13:03.340 the uh automation part of it to start with to 00:13:03.340 --> 00:13:06.500 to contain certain processes for example so when 00:13:06.500 --> 00:13:08.940 you run a malicious powershell script to do some 00:13:08.940 --> 00:13:11.899 process injection in a different executable uh 00:13:11.899 --> 00:13:14.539 defender endpoints might act on that by killing 00:13:14.539 --> 00:13:18.559 those processes for example um and again if there's 00:13:18.559 --> 00:13:20.559 a false positive there your application might 00:13:20.559 --> 00:13:24.159 crash or something like that um and and larger 00:13:24.159 --> 00:13:27.299 companies want to disable those features and 00:13:27.299 --> 00:13:29.080 they see the more small smaller companies really 00:13:29.080 --> 00:13:31.340 liking these features because, well, first of 00:13:31.340 --> 00:13:34.259 all, they don't have the capacity on the security 00:13:34.259 --> 00:13:37.000 department to actually look into all of these 00:13:37.000 --> 00:13:41.090 individual signals 24 seven. And also Microsoft 00:13:41.090 --> 00:13:45.169 has a lot of nice examples. And I actually put 00:13:45.169 --> 00:13:47.750 a couple of them in the show notes on our website 00:13:47.750 --> 00:13:50.629 where they have a business email compromise and 00:13:50.629 --> 00:13:54.309 an adversary in the middle attack in one kill 00:13:54.309 --> 00:13:56.990 chain. A real world example where you see that 00:13:56.990 --> 00:14:00.710 after five hours after the initial breach, the 00:14:00.710 --> 00:14:03.529 SOC was able to respond. And with attack disruption, 00:14:03.830 --> 00:14:08.509 a couple of steps earlier, much time was won. 00:14:09.029 --> 00:14:12.330 during the same attack. So you can't be as quick, 00:14:12.470 --> 00:14:15.610 I guess, as attack disruption in this regard. 00:14:16.330 --> 00:14:18.169 Yeah, fair enough. So what are the things? So 00:14:18.169 --> 00:14:21.470 when we talk about disrupting the attack, right, 00:14:21.509 --> 00:14:26.450 this is where, you know. Defender actually steps 00:14:26.450 --> 00:14:28.970 in and says, hey, this device doesn't look good. 00:14:29.090 --> 00:14:32.509 We're going to contain this device in some way, 00:14:32.529 --> 00:14:34.350 or this user account seems to be compromised. 00:14:34.470 --> 00:14:36.649 We're going to disable the user account. That's 00:14:36.649 --> 00:14:39.129 the things that we're talking about when we talk 00:14:39.129 --> 00:14:41.970 about actual actions that are being performed. 00:14:42.700 --> 00:14:44.659 Yeah, that's true. So there are actually now 00:14:44.659 --> 00:14:47.659 a couple of respond actions currently supported. 00:14:47.799 --> 00:14:50.460 And again, I can imagine Microsoft will expand 00:14:50.460 --> 00:14:53.019 on this in the future. But right now, they can 00:14:53.019 --> 00:14:55.139 do something like a device contain, which is 00:14:55.139 --> 00:14:59.659 a device isolation in the FANFA endpoint. Something 00:14:59.659 --> 00:15:03.440 relatively new is the user contain, which is 00:15:03.440 --> 00:15:07.159 different than a disable user. So Microsoft FANFA 00:15:07.159 --> 00:15:11.120 XDR could decide to disable a user using Entry 00:15:11.120 --> 00:15:15.009 ID. And... defender identity to disable the use 00:15:15.009 --> 00:15:17.830 of both in the cloud and on the on -premises 00:15:17.830 --> 00:15:20.830 environment at the same time which also prevents 00:15:20.830 --> 00:15:24.950 a lag in sync time right so they disable them 00:15:24.950 --> 00:15:28.029 immediately on both ends but they also support 00:15:28.029 --> 00:15:30.710 something they call a contain user and this is 00:15:30.710 --> 00:15:33.230 something that can be done on the endpoints so 00:15:33.230 --> 00:15:36.009 i'm actually referring to a blog post of a former 00:15:36.009 --> 00:15:39.090 colleague of mine jeffrey he's from the netherlands 00:15:39.090 --> 00:15:41.149 and he writes a lot about defender endpoints 00:15:41.149 --> 00:15:43.360 and he figured figured out a way to simulate 00:15:43.360 --> 00:15:46.120 attack disruption so this is really useful and 00:15:46.120 --> 00:15:48.539 interesting to try out in your lab environment 00:15:48.539 --> 00:15:51.639 and he has it all documented in his blog post 00:15:51.639 --> 00:15:54.960 how you can can reenact this this attack and 00:15:54.960 --> 00:15:57.320 what's interesting is that the Defender for Endpoint, 00:15:57.500 --> 00:16:01.639 separately from Defender for Identity, are acting 00:16:01.639 --> 00:16:05.480 to different degrees. So containing a user on 00:16:05.480 --> 00:16:08.700 the endpoint actually means that a certain user 00:16:08.700 --> 00:16:11.460 is not allowed anymore to connect to that machine, 00:16:11.659 --> 00:16:14.360 while the account might still be active. And 00:16:14.360 --> 00:16:16.259 this is done to prevent lateral movement, for 00:16:16.259 --> 00:16:19.580 example. So when Microsoft suspects a user account 00:16:19.580 --> 00:16:22.240 being used for lateral movement, but is not 100 00:16:22.240 --> 00:16:24.980 % sure right to disable the user, go ahead to 00:16:24.980 --> 00:16:27.899 disable the user. It might deploy a policy across 00:16:27.899 --> 00:16:30.220 all of the managed Defender for Endpoint clients 00:16:30.220 --> 00:16:33.159 to make sure that that user cannot do an RDP 00:16:33.159 --> 00:16:35.419 connection any longer, for example. And it's 00:16:35.419 --> 00:16:37.340 actually leveraged a group policy on the local 00:16:37.340 --> 00:16:40.919 machine to achieve this. Okay, wow. So it actually 00:16:40.919 --> 00:16:44.220 reaches in and does that sort of config during... 00:16:44.220 --> 00:16:47.120 Okay, that's pretty cool. Yeah, and that's why 00:16:47.120 --> 00:16:50.879 they call it contain user, contrary to disable 00:16:50.879 --> 00:16:53.799 user, so that the user is contained in a single 00:16:53.799 --> 00:16:57.360 place. And they also recently added third -party 00:16:57.360 --> 00:16:59.960 support with SAP. So this is the first third 00:16:59.960 --> 00:17:03.720 -party response action. So when you configure 00:17:03.720 --> 00:17:07.579 SAP through Microsoft Sentinel correctly, they 00:17:07.579 --> 00:17:09.839 can, for example, contain a compromised asset 00:17:09.839 --> 00:17:15.819 by locking suspicious SAP users when they detect 00:17:15.819 --> 00:17:18.259 a financial process manipulation or something 00:17:18.259 --> 00:17:22.920 like that. And again, I can imagine more actions 00:17:22.920 --> 00:17:26.690 will follow in the future. Now, I can imagine 00:17:26.690 --> 00:17:30.950 there'll be folks who think about this and go, 00:17:31.029 --> 00:17:33.349 okay, well, this is great for my regular user 00:17:33.349 --> 00:17:36.769 environment where I have information workers 00:17:36.769 --> 00:17:40.430 and frontline workers perhaps, but there may 00:17:40.430 --> 00:17:44.089 be certain user accounts or certain things that 00:17:44.089 --> 00:17:47.930 I want to avoid or exclude from this process. 00:17:48.289 --> 00:17:50.210 We have the capability to do that, don't we? 00:17:51.289 --> 00:17:53.569 Yeah, so that's why it's important to also make 00:17:53.569 --> 00:17:56.069 sure that you follow some configuration steps. 00:17:56.309 --> 00:18:00.509 And Microsoft did detail these in their documentation. 00:18:00.789 --> 00:18:02.549 And that's something I wanted to touch on on 00:18:02.549 --> 00:18:06.289 today's episode as well. So again, attack disruption 00:18:06.289 --> 00:18:09.150 is enabled by default, but it relies on certain 00:18:09.150 --> 00:18:11.789 components being set up. And one of the things 00:18:11.789 --> 00:18:15.170 you can do indeed is exclude certain device groups, 00:18:15.250 --> 00:18:19.309 for example, so that you exclude entire. uh devices 00:18:19.309 --> 00:18:21.910 in in of a certain category in your environment 00:18:21.910 --> 00:18:24.970 and you can also exclude users in in the fan 00:18:24.970 --> 00:18:28.150 of identity in this case but again you have to 00:18:28.150 --> 00:18:30.609 be careful right there's a trade -off there because 00:18:30.609 --> 00:18:33.109 if you would say well my domain controllers they 00:18:33.109 --> 00:18:35.230 are very important i want to exclude them for 00:18:35.230 --> 00:18:37.289 any of these actions well this might also be 00:18:37.289 --> 00:18:39.809 the place where people try to attack and steal 00:18:39.809 --> 00:18:43.549 your credentials right so microsoft does not 00:18:43.549 --> 00:18:47.549 advise you to exclude anything So that is best 00:18:47.549 --> 00:18:50.970 practice, but there will surely be environments 00:18:50.970 --> 00:18:56.670 who think differently of this. Yeah, that's fair. 00:18:56.849 --> 00:18:59.190 I think everyone has some uniqueness in their 00:18:59.190 --> 00:19:01.109 environment, right, where you've got to be able 00:19:01.109 --> 00:19:02.890 to address it. So it's nice to have the feature, 00:19:02.990 --> 00:19:05.069 but I think very important warning, as you said, 00:19:05.150 --> 00:19:07.930 right, is don't sort of be tempted to just go 00:19:07.930 --> 00:19:10.740 and find the... the most important things in 00:19:10.740 --> 00:19:12.859 your environment and exclude them because those 00:19:12.859 --> 00:19:14.539 most important things are also going to be the 00:19:14.539 --> 00:19:17.640 you know the richest target for for the bad bad 00:19:17.640 --> 00:19:21.730 folks Yeah, and I saw a session from Eyal. He's 00:19:21.730 --> 00:19:25.990 a PM from Israel on attack disruption. And he 00:19:25.990 --> 00:19:29.670 actually mentioned that although the false positive 00:19:29.670 --> 00:19:32.769 rate is less than 1%, customers are actually 00:19:32.769 --> 00:19:36.549 asking him if attack disruption can be even a 00:19:36.549 --> 00:19:39.410 little bit more aggressive. So customers are 00:19:39.410 --> 00:19:41.910 apparently letting them know, some of them at 00:19:41.910 --> 00:19:44.869 least, that they would accept a few more false 00:19:44.869 --> 00:19:47.829 positives as a trade -off that attack disruption. 00:19:48.039 --> 00:19:51.480 does more in practice in reality. That's interesting. 00:19:51.660 --> 00:19:54.980 Yeah, that is interesting. Yeah, so according 00:19:54.980 --> 00:19:57.579 to Microsoft, they are currently disrupting 40 00:19:57.579 --> 00:20:00.400 ,000 incidents a month. And that's also a crazy 00:20:00.400 --> 00:20:04.900 number, I guess. Well, yeah. I mean, it's crazy 00:20:04.900 --> 00:20:06.279 to think that there's that many things that are 00:20:06.279 --> 00:20:09.460 being... There's that many environments that 00:20:09.460 --> 00:20:12.099 have this deployed and where this is actually 00:20:12.099 --> 00:20:14.180 making a difference. Can you imagine how many 00:20:14.180 --> 00:20:17.019 environments there are? overall where this isn't 00:20:17.019 --> 00:20:19.240 deployed and they don't have that telemetry right 00:20:19.240 --> 00:20:22.059 so it just shows you the scary sort of state 00:20:22.059 --> 00:20:25.700 of the of the internet in general and and man 00:20:25.700 --> 00:20:27.980 it's it's all over the place isn't it yeah and 00:20:27.980 --> 00:20:30.319 companies might not yet be aware of the fact 00:20:30.319 --> 00:20:32.619 that the tech disruption did anything in their 00:20:32.619 --> 00:20:37.039 environment just yet so i would also invite people 00:20:37.039 --> 00:20:39.400 to look in their current environment going to 00:20:39.400 --> 00:20:42.160 the advanced hunting page in the security .microsoft 00:20:42.160 --> 00:20:45.779 .com portal and run a hunting query I put in 00:20:45.779 --> 00:20:48.599 the show notes where you can see if there are 00:20:48.599 --> 00:20:52.099 any incidents with the label attack disruption 00:20:52.099 --> 00:20:55.019 on there in the past. So again, there might have 00:20:55.019 --> 00:20:57.359 been certain steps already taken for you without 00:20:57.359 --> 00:21:01.809 you noticing it. So back to the configuration 00:21:01.809 --> 00:21:05.150 part. So Defender for Endpoint, again, like I 00:21:05.150 --> 00:21:08.329 said, it relies on a couple of things. And one 00:21:08.329 --> 00:21:11.150 of the things is also the device discovery. So 00:21:11.150 --> 00:21:14.190 as you might know, Chris, Defender for Endpoint 00:21:14.190 --> 00:21:17.529 is able to discover devices in the same network, 00:21:17.630 --> 00:21:20.690 which might not be onboarded with Defender for 00:21:20.690 --> 00:21:23.369 Endpoint. And this is a really important factor 00:21:23.369 --> 00:21:26.809 for tech disruption to work. So for example, 00:21:26.809 --> 00:21:30.069 when a unmanaged device in the network network 00:21:30.069 --> 00:21:32.690 is compromised and something somebody tries to 00:21:32.690 --> 00:21:35.130 move laterally from an unmanaged device into 00:21:35.130 --> 00:21:38.289 a managed device it is important to understand 00:21:38.289 --> 00:21:40.380 that well it's important to know that Defender 00:21:40.380 --> 00:21:42.680 needs to be aware of that unmanaged device in 00:21:42.680 --> 00:21:45.059 the first place to detect that lateral movement. 00:21:45.359 --> 00:21:47.400 And that's why you need to go into the settings 00:21:47.400 --> 00:21:50.720 and enable device discovery and put it on the 00:21:50.720 --> 00:21:53.180 standard mode. And some companies might have 00:21:53.180 --> 00:21:56.759 switched it to a lower setting, basic in this 00:21:56.759 --> 00:21:59.420 case. Well, I would advise everybody to put it 00:21:59.420 --> 00:22:02.400 back into standards. And it already gives you 00:22:02.400 --> 00:22:04.759 very valuable information of what devices you 00:22:04.759 --> 00:22:06.619 might have missed during the onboarding, right? 00:22:07.359 --> 00:22:11.130 Yeah, okay. Very good. I always see companies 00:22:11.130 --> 00:22:15.589 struggling with maintaining a 100 % compliance 00:22:15.589 --> 00:22:18.789 rate across all of their devices. And I think 00:22:18.789 --> 00:22:22.670 device discovery is a great example. And there's 00:22:22.670 --> 00:22:24.529 also a hunting query I put in the show notes, 00:22:24.609 --> 00:22:27.190 which you can run to list all of the discovered 00:22:27.190 --> 00:22:32.049 devices, including the last seen timestamp and 00:22:32.049 --> 00:22:35.900 by which other. device, that unmanaged device 00:22:35.900 --> 00:22:38.880 was seen. So it helps you pinpoint also what 00:22:38.880 --> 00:22:41.630 party or an environment and which network. the 00:22:41.630 --> 00:22:45.130 device was seen. And this is also to work against, 00:22:45.230 --> 00:22:48.089 let's say, malicious devices being plugged into 00:22:48.089 --> 00:22:50.930 a network, right? So if somebody goes into as 00:22:50.930 --> 00:22:53.750 a printer mechanic, for example, we've all seen 00:22:53.750 --> 00:22:56.349 the examples and plugs in a Raspberry Pi or whatnot 00:22:56.349 --> 00:23:01.150 in some of the outlets, that device will be discovered 00:23:01.150 --> 00:23:06.430 by other endpoints if this is enabled. Okay. 00:23:07.740 --> 00:23:09.779 Another thing that's important is that you have 00:23:09.779 --> 00:23:12.720 to run the latest tense agent. So this is the 00:23:12.720 --> 00:23:14.599 actual agent running on the endpoint from the 00:23:14.599 --> 00:23:17.319 fan of endpoints. And I also included a hunting 00:23:17.319 --> 00:23:19.740 query in the show notes, which you can run to. 00:23:20.380 --> 00:23:23.019 get a list of all the endpoints which might still 00:23:23.019 --> 00:23:26.559 have an older sense agent so that you know that 00:23:26.559 --> 00:23:28.740 you need to take a closer look at this. It might 00:23:28.740 --> 00:23:31.859 be good practice to create a detection or a dashboard 00:23:31.859 --> 00:23:36.140 with this query to keep an eye on this to make 00:23:36.140 --> 00:23:37.839 sure everything's up to date. Sometimes these 00:23:37.839 --> 00:23:41.180 automatic updates fail for some reason, and it's 00:23:41.180 --> 00:23:43.859 good to make sure that everything's up to date, 00:23:43.880 --> 00:23:47.630 right? Yeah, yeah. Yeah, these KQL queries that 00:23:47.630 --> 00:23:49.309 you've included in the show notes are going to 00:23:49.309 --> 00:23:51.410 be really, really useful for folks. So folks, 00:23:51.509 --> 00:23:53.150 you know, definitely make sure you pay attention 00:23:53.150 --> 00:23:55.369 to the show notes. We've mentioned it before 00:23:55.369 --> 00:23:58.029 on the show as well as a lot of effort goes into 00:23:58.029 --> 00:24:00.970 the show notes. And these are very much, you 00:24:00.970 --> 00:24:03.109 know, standalone blog posts on their own, really, 00:24:03.170 --> 00:24:06.210 if you, you know, so definitely pay attention 00:24:06.210 --> 00:24:08.970 there. There's some really helpful nuggets been 00:24:08.970 --> 00:24:11.529 supplied there. Thank you. Thanks for the effort 00:24:11.529 --> 00:24:14.029 there. Yeah, welcome. Yeah. So sometimes I'm 00:24:14.029 --> 00:24:15.890 struggling with the whole concept of a podcast, 00:24:16.130 --> 00:24:18.869 right? So I want to share stuff. I want to show 00:24:18.869 --> 00:24:21.890 people some screenshots of settings. And now 00:24:21.890 --> 00:24:23.910 I'm just able to talk about it. But at least 00:24:23.910 --> 00:24:26.150 we have the show notes to put in some evidence 00:24:26.150 --> 00:24:29.990 and actually some helpful queries in there. Yeah. 00:24:30.299 --> 00:24:32.480 Yeah, we promise we won't be breaking out the 00:24:32.480 --> 00:24:36.740 PowerPoints on this show ever. But the show notes 00:24:36.740 --> 00:24:40.539 will be there. They're always going to be as 00:24:40.539 --> 00:24:44.579 comprehensive as we can make them. Yeah. Yeah, 00:24:44.599 --> 00:24:47.180 so next up, something you need to configure is 00:24:47.180 --> 00:24:49.299 the Fennifer identity. So again, we mentioned 00:24:49.299 --> 00:24:52.019 also the very important part of attack disruption 00:24:52.019 --> 00:24:54.759 because your identities, well, a lot of companies 00:24:54.759 --> 00:24:56.720 still have their on -premises Active Directory 00:24:56.720 --> 00:24:59.960 and users might live there. There might be domain 00:24:59.960 --> 00:25:03.599 admin groups you want to monitor closely to make 00:25:03.599 --> 00:25:05.880 sure that when new users are added to that, for 00:25:05.880 --> 00:25:10.380 example, you get an alert. So Microsoft wants 00:25:10.380 --> 00:25:14.019 you to enable the Fennifer identity. part of 00:25:14.019 --> 00:25:16.920 attack disruption and you have actually have 00:25:16.920 --> 00:25:21.319 two ways of performing actions on the actual 00:25:21.319 --> 00:25:24.000 domain controllers and maybe chris you can you 00:25:24.000 --> 00:25:25.880 can elaborate a little bit more into this because 00:25:26.359 --> 00:25:28.539 Local Active Directory, it's been a while since 00:25:28.539 --> 00:25:32.200 I touched that. By default, a sensor is using 00:25:32.200 --> 00:25:35.940 the local system account, which might not, well, 00:25:36.019 --> 00:25:39.279 it's the default, but Microsoft advises you that 00:25:39.279 --> 00:25:41.619 you have the ability to use a, what they call 00:25:41.619 --> 00:25:44.599 a GMSA account, a Group Managed Service account, 00:25:44.720 --> 00:25:49.500 right, instead. But they stress that if you configure 00:25:49.500 --> 00:25:51.619 that and the account does not exist anymore, 00:25:51.839 --> 00:25:53.819 then obviously Defender for Identity will no 00:25:53.819 --> 00:25:56.869 longer work correctly. Yeah, it's an interesting 00:25:56.869 --> 00:26:02.430 one. I think the GMSAs are interesting because 00:26:02.430 --> 00:26:05.549 back in the day when we created service accounts 00:26:05.549 --> 00:26:08.650 in AD, folks just created a user account, gave 00:26:08.650 --> 00:26:11.230 it domain admins, gave it a long password, and 00:26:11.230 --> 00:26:13.490 off they went. That was just how it was done. 00:26:14.940 --> 00:26:16.539 the group managed service accounts are just a 00:26:16.539 --> 00:26:20.059 way to have the Windows operating system manage 00:26:20.059 --> 00:26:23.140 those service accounts right for you. And you 00:26:23.140 --> 00:26:25.500 don't have to worry about a password that has 00:26:25.500 --> 00:26:28.420 to be changed by a user or anything like that. 00:26:28.480 --> 00:26:32.839 But honestly, I very rarely see these used correctly. 00:26:33.319 --> 00:26:38.170 Really? uh active directory assessments for for 00:26:38.170 --> 00:26:41.690 customers um you know more often than not they're 00:26:41.690 --> 00:26:43.390 they're not using them or they're only using 00:26:43.390 --> 00:26:46.029 them for a very select small amount of of things 00:26:46.029 --> 00:26:48.630 so um yeah it'd be interesting it's interesting 00:26:48.630 --> 00:26:51.349 i would imagine that in most scenarios the uh 00:26:51.349 --> 00:26:53.329 the local system account is probably what is 00:26:53.329 --> 00:26:56.490 going to be used here for for the sensor yeah 00:26:57.279 --> 00:27:01.559 Yeah, so is the GMSA, is that a cloud of the 00:27:01.559 --> 00:27:04.519 on -prem equivalent of a managed identity in 00:27:04.519 --> 00:27:07.400 Azure then, I guess, in EntryD? Yes, I guess 00:27:07.400 --> 00:27:10.079 that's probably, that is a good way to put it. 00:27:10.119 --> 00:27:12.420 Yeah, absolutely. Yeah, so I can imagine on -prem 00:27:12.420 --> 00:27:16.059 applications need to support GMSA specifically 00:27:16.059 --> 00:27:18.680 to be able to work with them, right? That's right, 00:27:18.859 --> 00:27:21.059 yeah. So a lot of third parties don't always 00:27:21.059 --> 00:27:23.099 work so well, you know, when you look at third 00:27:23.099 --> 00:27:26.480 party things. So, yeah, no, that's a good call 00:27:26.480 --> 00:27:29.599 out. Yeah. Yeah, Microsoft also stresses that 00:27:29.599 --> 00:27:32.019 you want to make sure that all of your sensors 00:27:32.019 --> 00:27:35.539 in MDI, Defender for Identity, are healthy. So 00:27:35.539 --> 00:27:37.859 Microsoft Defender for Identity really relies 00:27:37.859 --> 00:27:40.619 heavily on auditing policies because they need 00:27:40.619 --> 00:27:43.000 all of the audit events from Active Directory 00:27:43.000 --> 00:27:45.400 to come in on the domain controllers to be logged, 00:27:45.599 --> 00:27:48.400 to be picked up by the agent, to send to the 00:27:48.400 --> 00:27:51.599 Defender for Identity platform to be pre -processed. 00:27:51.599 --> 00:27:54.599 And as part of the Defender for Identity onboarding, 00:27:54.640 --> 00:27:57.789 you go through documentation telling... you exactly 00:27:57.789 --> 00:28:00.710 what kind of auditing policies you need to enable 00:28:00.710 --> 00:28:04.049 on your domain controllers. But we see some configuration 00:28:04.049 --> 00:28:06.890 drift there with customers sometimes for, well, 00:28:06.890 --> 00:28:09.750 they touch policies, they rearrange them, they 00:28:09.750 --> 00:28:11.670 make changes to them, unassign them, I don't 00:28:11.670 --> 00:28:13.809 know what they do. But for some reason, all of 00:28:13.809 --> 00:28:15.730 a sudden, your audit policies are not being logged 00:28:15.730 --> 00:28:18.150 anymore. And then Defender for Identity gets 00:28:18.150 --> 00:28:21.710 an unhealthy sensor. So you can check the status 00:28:21.710 --> 00:28:24.109 of these sensors in the portal to make sure that 00:28:24.109 --> 00:28:25.769 all of the domain controllers are still configured 00:28:25.769 --> 00:28:29.509 as they should. You know, there's a lot that 00:28:29.509 --> 00:28:31.029 goes on behind the scenes there, right, with 00:28:31.029 --> 00:28:33.529 these sensors, grabbing all of those alerts and 00:28:33.529 --> 00:28:35.390 then processing them and sending them up. So, 00:28:35.390 --> 00:28:37.789 you know, it's worth making sure that things 00:28:37.789 --> 00:28:40.289 are working as they should, you know, and not 00:28:40.289 --> 00:28:42.710 just sort of setting them and walking away from 00:28:42.710 --> 00:28:45.309 it because it's, yeah, there's a lot going on 00:28:45.309 --> 00:28:48.609 behind the scenes. Yeah, I really like this approach 00:28:48.609 --> 00:28:53.559 where Microsoft... collect a lot of the logs 00:28:53.559 --> 00:28:56.819 or raw logs, so to speak, into their own workspace 00:28:56.819 --> 00:28:59.640 or whatever storage they have in the back end 00:28:59.640 --> 00:29:02.319 and just provide you the alerts and the incidents 00:29:02.319 --> 00:29:06.160 that they correlate out of it. And well, we touched 00:29:06.160 --> 00:29:08.039 on Microsoft Sentinel a couple of times, and 00:29:08.039 --> 00:29:09.980 this is one of the topics I like to speak about 00:29:09.980 --> 00:29:14.500 a lot. And I see companies still. having a desire 00:29:14.500 --> 00:29:17.019 to collect all of the raw logs from all domain 00:29:17.019 --> 00:29:19.079 controllers and all kinds of network appliances. 00:29:19.420 --> 00:29:21.700 And I'm like, okay, so you're trying to recreate 00:29:21.700 --> 00:29:24.779 your own Microsoft definitive identity, so to 00:29:24.779 --> 00:29:27.559 speak, right? By collecting them and doing your 00:29:27.559 --> 00:29:29.779 own detections on them. And I think what Microsoft 00:29:29.779 --> 00:29:32.160 does is really, really useful because they have 00:29:32.160 --> 00:29:35.140 the power of the numbers, right? They have so 00:29:35.140 --> 00:29:39.319 much telemetry and data. It's probably unlikely 00:29:39.319 --> 00:29:42.140 that you're able to come up with better detection. 00:29:42.220 --> 00:29:45.960 than they do. So, yeah. But that's why they rely 00:29:45.960 --> 00:29:51.890 this much on the audit logs. Defender for cloud 00:29:51.890 --> 00:29:54.009 apps is also covered. There are a couple of steps 00:29:54.009 --> 00:29:56.329 in the show notes. Again, linking to Microsoft 00:29:56.329 --> 00:29:58.750 documentation. You have to make sure that the 00:29:58.750 --> 00:30:01.150 cloud app, Defender for cloud app is connected 00:30:01.150 --> 00:30:05.130 to Microsoft 365 through connector. App governance 00:30:05.130 --> 00:30:08.269 should be turned on. And also in Defender for 00:30:08.269 --> 00:30:13.130 Office 365, there are a couple of key points 00:30:13.130 --> 00:30:17.329 like some auditing requirements again. And also 00:30:17.329 --> 00:30:20.049 safe links policy needs to be present. Some details 00:30:20.049 --> 00:30:22.589 like that. And again, without setting this up, 00:30:22.789 --> 00:30:25.769 attack disruption might still work for endpoint 00:30:25.769 --> 00:30:28.849 and identity related. But you want to cover as 00:30:28.849 --> 00:30:31.390 much as possible by making sure all of these 00:30:31.390 --> 00:30:33.829 products are enabled and configured in a proper 00:30:33.829 --> 00:30:35.470 way. Yeah. If you think about it, I mean, the 00:30:35.470 --> 00:30:38.210 way to do, for example, the business email compromise 00:30:38.210 --> 00:30:41.369 scenario, right? Really, you need to be able 00:30:41.369 --> 00:30:42.849 to look at the mailboxes. You need to be able 00:30:42.849 --> 00:30:45.930 to look at things that are events that are happening 00:30:45.930 --> 00:30:49.079 within the mailbox, which means, you know. exchange 00:30:49.079 --> 00:30:51.799 online is a is a pretty big requirement here 00:30:51.799 --> 00:30:53.619 and and being able to get to the unified audit 00:30:53.619 --> 00:30:56.700 log and all of those types of things yeah so 00:30:56.700 --> 00:30:59.339 i can imagine you still come across some customers 00:30:59.339 --> 00:31:02.480 with with actual running their own exchange right 00:31:02.480 --> 00:31:05.880 maybe on premises or in the clouds yeah look 00:31:05.880 --> 00:31:08.720 um i haven't it's been a while since i've i've 00:31:08.720 --> 00:31:10.859 had any customers who are running exchange server 00:31:10.859 --> 00:31:13.849 in the cloud um it has happened and i've seen 00:31:13.849 --> 00:31:16.589 some pretty large deployments of it but um yeah 00:31:16.589 --> 00:31:18.950 there still are those folks who are on um exchange 00:31:18.950 --> 00:31:21.769 on -prem you know exchange server uh in their 00:31:21.769 --> 00:31:25.009 own data center and you know there's um we know 00:31:25.009 --> 00:31:27.210 that uh exchange uh what are they calling it 00:31:27.210 --> 00:31:28.990 subscription edition is is going to be due out 00:31:28.990 --> 00:31:31.950 sometime at the end of the year i think um and 00:31:31.950 --> 00:31:33.829 there's not a lot of time for folks who are on 00:31:33.829 --> 00:31:37.470 16 and 19 to be getting ready for that upgrade 00:31:37.470 --> 00:31:43.119 so um Yeah, we feel for those folks, but very 00:31:43.119 --> 00:31:46.720 often their place and where they are now is based 00:31:46.720 --> 00:31:48.619 on some technical debt and decisions that they've 00:31:48.619 --> 00:31:51.819 made, right? But yeah, for this to work, really, 00:31:51.900 --> 00:31:54.900 you need to be online. Exchange Online is where 00:31:54.900 --> 00:31:57.660 you want to be if you want to take advantage 00:31:57.660 --> 00:32:01.059 of this capability. Yeah, so customers are still 00:32:01.059 --> 00:32:03.920 running Exchange 2016. That sounds crazy to me. 00:32:03.980 --> 00:32:07.720 They had a couple of years to migrate away from 00:32:07.720 --> 00:32:10.779 that, right? yeah that's right and um you know 00:32:10.779 --> 00:32:13.619 hey exchange 2013 is still still around as well 00:32:13.619 --> 00:32:15.380 there are a lot of customers that are still running 00:32:15.380 --> 00:32:17.740 that so i don't want to know i actually heard 00:32:17.740 --> 00:32:20.579 from a customer a a couple of weeks ago which 00:32:20.579 --> 00:32:22.359 we helped with a completely different project 00:32:22.359 --> 00:32:25.279 but they they they finalized migrating away from 00:32:25.279 --> 00:32:28.380 lotus notes a couple of months ago so i was like 00:32:28.380 --> 00:32:30.500 oh that's still around as well and that's great 00:32:30.500 --> 00:32:34.609 yeah yeah i'm sure you know all these things 00:32:34.609 --> 00:32:37.609 are there are all these bespoke places all over 00:32:37.609 --> 00:32:39.809 all over that are that still have you know many 00:32:39.809 --> 00:32:42.009 of these these crazy things i haven't i think 00:32:42.009 --> 00:32:46.349 the last time i saw notes myself was 2019 maybe 00:32:46.349 --> 00:32:48.789 was probably the last time i saw i saw lotus 00:32:48.789 --> 00:32:51.900 notes but hey i'm sure that still exists Yeah, 00:32:51.940 --> 00:32:53.619 we all know how it goes, especially with the 00:32:53.619 --> 00:32:56.380 larger corporations. They have a lot of history 00:32:56.380 --> 00:32:58.799 and a lot of legacy applications for the same 00:32:58.799 --> 00:33:01.059 reason. But it's really hard to protect those 00:33:01.059 --> 00:33:03.599 environments because they have this stuff running 00:33:03.599 --> 00:33:07.339 around like Exchange 2013. I can imagine it's 00:33:07.339 --> 00:33:10.000 not safe to have that exposed to the internet 00:33:10.000 --> 00:33:13.599 any longer, right? Yeah, no, you wouldn't want 00:33:13.599 --> 00:33:16.359 to. Hey, you know, it's difficult, right? Because 00:33:16.359 --> 00:33:19.839 I think... i you know i know of organizations 00:33:19.839 --> 00:33:22.960 that are still trying to get off 2013 right um 00:33:22.960 --> 00:33:25.380 and you know they those types of projects can 00:33:25.380 --> 00:33:27.420 take years if they're a very large environment 00:33:27.420 --> 00:33:32.740 um but also you know yeah it's it's perhaps that's 00:33:32.740 --> 00:33:34.480 a conversation for the for a different episode 00:33:34.480 --> 00:33:37.180 right is is the perils of of old software but 00:33:37.180 --> 00:33:40.539 uh no i i see what you're saying for sure yeah 00:33:41.210 --> 00:33:45.390 Yeah, so lastly, I want to touch on notifications. 00:33:45.609 --> 00:33:49.549 So we did touch on customers might be fearsome 00:33:49.549 --> 00:33:52.950 of Microsoft interrupting and actually going 00:33:52.950 --> 00:33:58.789 to take action on certain response. But you can 00:33:58.789 --> 00:34:01.569 enable notifications on these actions. So it 00:34:01.569 --> 00:34:04.410 might be a good idea in general to configure 00:34:04.410 --> 00:34:07.329 a notification whenever a device is isolated, 00:34:07.430 --> 00:34:10.369 for example. so that a certain team gets an email 00:34:10.369 --> 00:34:13.449 that that that that is that did happen and it 00:34:13.449 --> 00:34:15.869 might be sock analyst doing it manually but it 00:34:15.869 --> 00:34:17.829 might also be caused by attack disruption and 00:34:17.829 --> 00:34:20.610 now at least you know that somebody deliberately 00:34:21.599 --> 00:34:24.219 isolated a device, for example. Same goes with 00:34:24.219 --> 00:34:27.800 contain user, disable user. So when you go into 00:34:27.800 --> 00:34:32.500 the portal, you can go to settings and you have 00:34:32.500 --> 00:34:35.960 a notification option with a pull down menu where 00:34:35.960 --> 00:34:38.460 you can actually select which kind of actions 00:34:38.460 --> 00:34:41.639 should trigger a notification alert. And then 00:34:41.639 --> 00:34:44.199 at least you can, well, maybe sleep a little 00:34:44.199 --> 00:34:47.260 bit more easily knowing that the text disruption 00:34:47.260 --> 00:34:49.780 is fully enabled. But whenever it does something 00:34:49.780 --> 00:34:52.429 that... can really be impactful in your environment. 00:34:52.530 --> 00:34:54.530 At least there's also an email going out to certain 00:34:54.530 --> 00:34:57.269 teams. And it also makes sure that, for example, 00:34:57.429 --> 00:35:00.610 when a tech disruption disables a user and a 00:35:00.610 --> 00:35:03.530 SOC analyst is not aware of that and the server 00:35:03.530 --> 00:35:06.650 desk, for example, gets a call by somebody not 00:35:06.650 --> 00:35:08.869 being able to log in any longer and the server 00:35:08.869 --> 00:35:11.489 desk just re -enables the account again and the 00:35:11.489 --> 00:35:14.489 attacker can abuse it again, right? So notification 00:35:14.489 --> 00:35:17.489 paths, I think, are very useful to consider as 00:35:17.489 --> 00:35:19.800 well. yeah because also i mean someone might 00:35:19.800 --> 00:35:23.400 not be in the console looking at the the alerts 00:35:23.400 --> 00:35:25.539 and stuff at that time right so yeah i can i 00:35:25.539 --> 00:35:27.980 can see how that would be super important yeah 00:35:27.980 --> 00:35:30.260 especially because these actions uh can be very 00:35:30.260 --> 00:35:33.289 impactful right so So in the show notes, I put 00:35:33.289 --> 00:35:36.769 some links to a lot of documentation on Microsoft, 00:35:36.949 --> 00:35:40.869 some configuration guides, but also, again, a 00:35:40.869 --> 00:35:43.050 shout out to my former colleague, Jeffrey Appel. 00:35:43.170 --> 00:35:45.809 He writes a lot about Defender for Endpoint. 00:35:45.949 --> 00:35:48.570 I think whenever you Google anything on Defender 00:35:48.570 --> 00:35:52.550 for Endpoint, I think sometimes he comes up even 00:35:52.550 --> 00:35:56.550 higher than Microsoft's documentation. He also 00:35:56.550 --> 00:35:58.449 wrote about attack disruption, and if you want 00:35:58.449 --> 00:36:02.159 to try out the simulation he wrote. He has written, 00:36:02.340 --> 00:36:07.059 he makes use of Mimikots and Impacket, which 00:36:07.059 --> 00:36:13.199 are red teaming tools to manipulate certain credentials 00:36:13.199 --> 00:36:17.179 and cached credentials. You can go read along 00:36:17.179 --> 00:36:20.780 and try it out yourself and see a tech disruption 00:36:20.780 --> 00:36:25.800 in action. Yeah, those are super useful resources 00:36:25.800 --> 00:36:30.590 there, Kost. I think, Jeffrey's stuff. I've come 00:36:30.590 --> 00:36:32.929 across a lot of his stuff in the past. So yeah, 00:36:32.949 --> 00:36:36.050 he puts a lot of effort into his post. He writes 00:36:36.050 --> 00:36:39.150 old school blog posts with screenshots and all 00:36:39.150 --> 00:36:41.289 the rest of it. So it's really, really useful 00:36:41.289 --> 00:36:43.489 stuff to read. So very cool. Yeah. And the technical 00:36:43.489 --> 00:36:46.329 guys like you and me really like the stuff. I 00:36:46.329 --> 00:36:49.289 wonder sometimes how it's possible that Jeffrey 00:36:49.289 --> 00:36:52.650 has more than 24 hours in a day because he's 00:36:52.650 --> 00:36:55.670 cranking out his blog posts sometimes on a weekly 00:36:55.670 --> 00:36:58.670 basis. Yeah. Yeah. Hey, there are a few people 00:36:58.670 --> 00:37:01.110 in now. In our community, they're like that, 00:37:01.150 --> 00:37:02.650 right? You kind of wonder. I was just thinking 00:37:02.650 --> 00:37:06.190 today that, you know, wondering if Meryl Fernandez 00:37:06.190 --> 00:37:08.889 ever sleeps because he also seems to be everywhere 00:37:08.889 --> 00:37:12.329 all at once. Also a prime example. Yeah, yeah. 00:37:14.530 --> 00:37:17.690 That's super useful, the attack disruption stuff. 00:37:17.769 --> 00:37:19.969 I think this is really valuable information. 00:37:20.030 --> 00:37:21.630 Thanks for kind of running through it here. I 00:37:21.630 --> 00:37:25.150 think, you know, really is. if you've got a e5 00:37:25.150 --> 00:37:27.190 and you have this capability you know there's 00:37:27.190 --> 00:37:28.989 very little for you to do to be able to take 00:37:28.989 --> 00:37:31.690 advantage of this and you know chances are it's 00:37:31.690 --> 00:37:34.269 probably saved your bacon already right um i 00:37:34.269 --> 00:37:36.170 think for for a lot of folks if you if you didn't 00:37:36.170 --> 00:37:38.250 know about it but you have all of these capabilities 00:37:38.250 --> 00:37:40.789 enabled it may have already been working for 00:37:40.789 --> 00:37:43.090 you and you just you know you haven't uh you 00:37:43.090 --> 00:37:45.309 haven't realized it so i'm really useful information 00:37:45.309 --> 00:37:49.820 to kind of talk through Yeah, and if you do not 00:37:49.820 --> 00:37:53.199 have E5 just yet and you're up for renewal on 00:37:53.199 --> 00:37:57.880 your existing EDR or antivirus solution. I really 00:37:57.880 --> 00:38:01.679 think it's useful to consider moving to Microsoft 00:38:01.679 --> 00:38:04.179 Security Stack. So like we mentioned earlier, 00:38:04.320 --> 00:38:07.239 if your identities live in Okta and you use CrowdStrike 00:38:07.239 --> 00:38:09.760 as EDR and you have a different AV solution and 00:38:09.760 --> 00:38:12.519 you have, I don't know, Exchange on -prem, all 00:38:12.519 --> 00:38:15.340 of this nice fancy stuff will not work for you 00:38:15.340 --> 00:38:20.599 or at least not in the full coverage mode. So 00:38:20.599 --> 00:38:24.559 I think Microsoft has a really interesting feature 00:38:24.559 --> 00:38:28.039 in this way. all of their tools work together 00:38:28.039 --> 00:38:31.340 so i would really uh stress consider switching 00:38:31.340 --> 00:38:34.219 uh perhaps even to uh to this because you cannot 00:38:34.219 --> 00:38:36.599 achieve this without different products yeah 00:38:36.599 --> 00:38:38.460 yeah and i think it goes back to that as i said 00:38:38.460 --> 00:38:40.460 in the beginning right sort of best of platform 00:38:40.460 --> 00:38:43.099 type uh scenario where it really makes a lot 00:38:43.099 --> 00:38:45.179 of sense to have all your eggs in this really 00:38:45.179 --> 00:38:49.349 large basket Yeah, I know companies also are 00:38:49.349 --> 00:38:52.250 a little bit scared of the idea. Vendor lock 00:38:52.250 --> 00:38:55.449 -in is a thing for a couple of years now already. 00:38:56.570 --> 00:39:01.090 You had a community project prepared, Chris. 00:39:01.090 --> 00:39:03.389 Yes, I was just about to say, moving on to community 00:39:03.389 --> 00:39:06.489 project. Honestly, I think this is a very topical 00:39:06.489 --> 00:39:08.730 community project because it really does touch 00:39:08.730 --> 00:39:11.269 nicely and go nicely with what we've just talked 00:39:11.269 --> 00:39:16.000 about, right? there's a microsoft mvp and i think 00:39:16.000 --> 00:39:19.000 he's based in the uk uh called mezbauden and 00:39:19.000 --> 00:39:21.920 he's put together a powershell script that uh 00:39:21.920 --> 00:39:25.679 helps administrators you know identify um and 00:39:25.679 --> 00:39:28.199 and respond to security incidents in exchange 00:39:28.199 --> 00:39:32.019 online right um you know he refers to it as a 00:39:32.019 --> 00:39:34.179 microsoft 365 security incident investigation 00:39:34.179 --> 00:39:37.480 tool which is quite a quite a mouthful um but 00:39:37.480 --> 00:39:39.519 really it's very much focused on on exchange 00:39:39.519 --> 00:39:44.440 online and and what's great about this is It 00:39:44.440 --> 00:39:46.579 allows you to quickly investigate, you know, 00:39:46.579 --> 00:39:48.059 if you've had an incident in your environment, 00:39:48.199 --> 00:39:51.780 you can use the script to look for those sort 00:39:51.780 --> 00:39:53.940 of indicators of compromise. Right. So very often 00:39:53.940 --> 00:39:56.340 if I've worked with a customer where they've, 00:39:56.340 --> 00:39:57.980 you know, they've had a business email compromise. 00:39:59.500 --> 00:40:02.760 you know, incident happen and they don't have 00:40:02.760 --> 00:40:04.679 to attack disruption, which has disabled the 00:40:04.679 --> 00:40:08.139 account for them. You know, generally what happens 00:40:08.139 --> 00:40:11.019 is when a bad actor gets into a mailbox, they 00:40:11.019 --> 00:40:13.440 do a bunch of things, right? So, you know, one 00:40:13.440 --> 00:40:15.619 of those things is almost always they're going 00:40:15.619 --> 00:40:19.019 to go create, you know, inbox rules, things that 00:40:19.019 --> 00:40:22.619 will remove sent items immediately or auto forward 00:40:22.619 --> 00:40:24.980 attachments onto them, things like that to try 00:40:24.980 --> 00:40:27.199 and keep their, you know, their foothold and 00:40:27.199 --> 00:40:30.079 retain persistence in the environment. Those 00:40:30.079 --> 00:40:32.320 types of things, they'll mess around with mailbox 00:40:32.320 --> 00:40:35.139 permissions and grant themselves access to things 00:40:35.139 --> 00:40:38.420 or what have you. And what his script does, and 00:40:38.420 --> 00:40:41.000 I love this because it's a one -stop shop tool 00:40:41.000 --> 00:40:44.679 for looking at these types of incidences, is 00:40:44.679 --> 00:40:48.880 it uses the Exchange PowerShell module. So it's 00:40:48.880 --> 00:40:52.440 doing some stuff with the audit logs in Exchange 00:40:52.440 --> 00:40:55.659 Online, and it's using Graph. as well to go and 00:40:55.659 --> 00:40:58.400 um you know look for these types of indicators 00:40:58.400 --> 00:41:01.000 of compromise so the the six that he's got listed 00:41:01.000 --> 00:41:03.739 um that he that he kind of looks for is malicious 00:41:03.739 --> 00:41:07.219 inbox rules which we've talked about um you know 00:41:07.219 --> 00:41:09.679 unusual email volume if all of a sudden the mailbox 00:41:09.679 --> 00:41:12.639 starts spamming email out um things like that 00:41:12.639 --> 00:41:15.820 uh permission changes to mailboxes right if you've 00:41:15.820 --> 00:41:18.500 got you know ceo mailboxes and stuff like that 00:41:18.500 --> 00:41:20.159 and all of a sudden delegates get added to it 00:41:20.159 --> 00:41:22.099 that type of thing you know that's potentially 00:41:22.099 --> 00:41:26.639 a red flag um you know uh um critical email deletion 00:41:26.639 --> 00:41:28.760 detection and then he's got export monitoring 00:41:28.760 --> 00:41:30.900 as well right and again if you've got you know 00:41:30.900 --> 00:41:33.920 a help desk mailbox or some other you know um 00:41:33.920 --> 00:41:36.500 you know heavily uh guarded mailbox that all 00:41:36.500 --> 00:41:38.420 of a sudden starts dumping all its mail right 00:41:38.420 --> 00:41:41.039 um you know that could potentially be a an indicator 00:41:41.039 --> 00:41:43.840 of compromise so i i really like what he's done 00:41:43.840 --> 00:41:46.079 here put a lot of stuff together in in sort of 00:41:46.079 --> 00:41:49.130 a single um tool that you can kind of you get 00:41:49.130 --> 00:41:52.010 from github and and and and run and i think he's 00:41:52.010 --> 00:41:54.210 he's made it modular so you can actually you 00:41:54.210 --> 00:41:56.489 know run the individual checks separately or 00:41:56.489 --> 00:41:59.349 you can run the tool to do things um i would 00:41:59.349 --> 00:42:01.090 you know props to him for doing that i think 00:42:01.090 --> 00:42:02.590 this goes really well with the discussion we've 00:42:02.590 --> 00:42:07.590 just had on on um uh this attack disruption and 00:42:07.590 --> 00:42:10.550 just generally attacks And yeah, if you're an 00:42:10.550 --> 00:42:13.250 Exchange administrator in Exchange Online, I 00:42:13.250 --> 00:42:15.690 would highly suggest you take a look. I've got 00:42:15.690 --> 00:42:18.510 a link in the show notes to the GitHub repo for 00:42:18.510 --> 00:42:21.510 this. And obviously, yeah, of course, if you 00:42:21.510 --> 00:42:24.630 like it or you think there's something missing 00:42:24.630 --> 00:42:26.590 or you want to provide feedback, feel free to 00:42:26.590 --> 00:42:30.150 get in touch with Mesbah and shoot him a note. 00:42:30.610 --> 00:42:33.300 Yeah. yeah thanks for creating this ms bar and 00:42:33.300 --> 00:42:36.460 uh it's a little bit like advanced hunting but 00:42:36.460 --> 00:42:38.679 then on your exchange audit logs right so we 00:42:38.679 --> 00:42:41.400 touched on hunting in the past so it might be 00:42:41.400 --> 00:42:43.679 good practice to make this part of your uh hunting 00:42:43.679 --> 00:42:46.940 strategy yeah very very cool stuff so wanted 00:42:46.940 --> 00:42:49.099 to share that there's also a really large blog 00:42:49.099 --> 00:42:51.179 post which i actually haven't linked to but on 00:42:51.179 --> 00:42:55.400 the um uh the practical 365 blog he actually 00:42:55.400 --> 00:42:58.119 breaks it down in you know really deep detail 00:42:58.119 --> 00:43:02.260 but I've got a link to his own blog and his Git 00:43:02.260 --> 00:43:06.480 repository here, so you can find him. And yeah, 00:43:07.059 --> 00:43:10.539 with that, I think that hopefully brings us to 00:43:10.539 --> 00:43:13.219 the end of hopefully a very interesting and fascinating 00:43:13.219 --> 00:43:18.079 sort of threat -related show. I hope people found 00:43:18.079 --> 00:43:21.000 it informative. Yeah, absolutely. We're always 00:43:21.000 --> 00:43:25.519 open to feedback. Please feel free to reach out 00:43:25.519 --> 00:43:28.420 to us if there's anything specific you want us 00:43:28.420 --> 00:43:31.440 to talk about or to catch up with. Sadly, we 00:43:31.440 --> 00:43:33.719 don't have any more in -person events coming 00:43:33.719 --> 00:43:37.440 up in the near future, but we'll continue to 00:43:37.440 --> 00:43:40.880 do these every month as we have been. We've always 00:43:40.880 --> 00:43:42.900 got plenty of things that we want to talk about 00:43:42.900 --> 00:43:46.699 and not enough time. Microsoft keeps us busy 00:43:46.699 --> 00:43:49.639 with new products and features every week, right? 00:43:50.099 --> 00:43:54.139 That's right. So, yes, thanks again for listening. 00:43:54.300 --> 00:43:56.579 Please feel free to like, subscribe, shoot us 00:43:56.579 --> 00:43:58.460 a note if there's something that's on your mind. 00:43:58.519 --> 00:44:00.940 And we look forward to your company on the next 00:44:00.940 --> 00:44:03.389 episode. because thank you i know you've got 00:44:03.389 --> 00:44:05.449 to kick off your day so really appreciate you 00:44:05.449 --> 00:44:07.690 joining me early in the morning and uh yeah i'm 00:44:07.690 --> 00:44:09.489 not sure if you noticed but the sun is shining 00:44:09.489 --> 00:44:11.670 a little bit brighter this time uh this time 00:44:11.670 --> 00:44:13.769 of year so it's actually becoming a little bit 00:44:13.769 --> 00:44:16.690 of summer uh over here so finally the dark days 00:44:16.690 --> 00:44:19.510 are are over i guess yeah we're getting them 00:44:19.510 --> 00:44:21.550 here now it's gonna be it'll be dark probably 00:44:21.550 --> 00:44:23.610 20 minutes from now it'll be it'll be fully dark 00:44:23.610 --> 00:44:26.349 outside here so we'll trade we'll try places 00:44:26.349 --> 00:44:28.909 for the next six months enjoy your evening i'm 00:44:28.909 --> 00:44:31.809 going and jump into my car drive to the office 00:44:31.809 --> 00:44:33.550 cool see you next time