1 00:00:06,680 --> 00:00:10,360 Welcome to the Blue Security Podcast, a weekly podcast for 2 00:00:10,360 --> 00:00:13,600 information security defenders where we bring you discussions 3 00:00:13,600 --> 00:00:16,960 on best practices, tools, and implementation for enterprise 4 00:00:16,960 --> 00:00:19,200 security. Now here are your hosts for 5 00:00:19,200 --> 00:00:21,800 today's show, Andy JA and Adam Brewer. 6 00:00:24,440 --> 00:00:27,440 Welcome to this week's episode of the Blue Security Podcast. 7 00:00:27,600 --> 00:00:31,160 I'm Andy, your host. I'm Adam, your Co host. 8 00:00:31,840 --> 00:00:34,160 Today we're going to be talking about two things. 9 00:00:34,160 --> 00:00:39,200 The first topic is going to be Apple Lockdown mode and how 10 00:00:39,200 --> 00:00:43,080 Apple released some statistics and stuff about how lockdown 11 00:00:43,080 --> 00:00:46,840 mode has actually never had a successful attack against it. 12 00:00:46,920 --> 00:00:48,440 And so we'll we'll get into that. 13 00:00:48,440 --> 00:00:53,720 And then the second one is about this whole phantom device attack 14 00:00:54,080 --> 00:00:58,040 where Intra ID or Azure AD, whatever, you know, that's a lot 15 00:00:58,040 --> 00:01:00,280 of the articles actually say Azure AD, which I thought was 16 00:01:00,280 --> 00:01:02,240 kind of funny. Yeah, I saw that too. 17 00:01:02,960 --> 00:01:07,520 But it's intra ID and, and how there was a PRT token that was 18 00:01:07,520 --> 00:01:10,160 minted and bypass conditional access. 19 00:01:10,160 --> 00:01:12,720 And so that was all the rage. I saw that some chatter on 20 00:01:12,720 --> 00:01:15,560 Twitter and and certainly internally there's some folks 21 00:01:15,560 --> 00:01:17,360 asking about it as well as customers. 22 00:01:17,360 --> 00:01:20,720 So wanted to go through that attack and how it happened and 23 00:01:20,720 --> 00:01:24,800 how you can mitigate it. Before we get started, since 24 00:01:24,800 --> 00:01:27,200 we're going to be talking about Microsoft, Adam, you want to 25 00:01:27,200 --> 00:01:29,280 kick it off with a quick disclaimer? 26 00:01:29,720 --> 00:01:32,720 Yeah. And Andy and I both work for 27 00:01:32,720 --> 00:01:34,920 Microsoft and Field Security sales. 28 00:01:34,920 --> 00:01:37,480 We do this show outside of work. We're recording this Sunday 29 00:01:37,480 --> 00:01:42,080 night about 7:30 PM local time and we self fund the show. 30 00:01:42,240 --> 00:01:45,400 We do not accept accept sponsorships or any other 31 00:01:45,400 --> 00:01:47,840 income. This is purely a labor of love 32 00:01:47,880 --> 00:01:50,440 and we put our while it's behind it. 33 00:01:50,680 --> 00:01:53,600 So that said, the opinions you're about to hear expressed 34 00:01:53,600 --> 00:01:57,040 are those of Adam Brewer and Andy Jaw and do not necessarily 35 00:01:57,040 --> 00:01:59,320 reflect those of Microsoft Corporation. 36 00:01:59,640 --> 00:02:03,920 And with that, on with the show. OK, so let's talk about Apple 37 00:02:03,920 --> 00:02:07,120 Lockdown mode. I know that we have mentioned 38 00:02:07,120 --> 00:02:10,280 this before on the show, but let's just highlighted real 39 00:02:10,280 --> 00:02:12,400 quick in case you are unfamiliar with it. 40 00:02:12,720 --> 00:02:16,760 Lockdown mode is something that is built into the iOS operating 41 00:02:16,760 --> 00:02:19,000 system. It is opt in, so it's not 42 00:02:19,000 --> 00:02:24,360 enabled by default, but it is a system hardening feature that 43 00:02:24,360 --> 00:02:29,440 was introduced by Apple in 2022 specifically for high risk 44 00:02:29,440 --> 00:02:33,440 individual. So think like if you're press in 45 00:02:33,440 --> 00:02:39,320 like or like ACEO or maybe you know, C-Suite of a major 46 00:02:39,320 --> 00:02:43,520 company, probably like anyone in high level government, those are 47 00:02:43,520 --> 00:02:46,440 the people who probably would look at this. 48 00:02:46,440 --> 00:02:50,480 If you're working in a sensitive area or have some sort of 49 00:02:50,480 --> 00:02:52,800 secrets that you need to guard, these are the folks that are 50 00:02:52,800 --> 00:02:55,360 more susceptible and probably should look at it. 51 00:02:55,360 --> 00:02:59,280 It's really not for the average user, although it is available 52 00:02:59,320 --> 00:03:04,200 for anyone to use and certainly like at organizations where you 53 00:03:04,200 --> 00:03:07,440 might think about this, this is something that you can enable 54 00:03:07,440 --> 00:03:11,560 for your users. So what it does is it 55 00:03:11,560 --> 00:03:15,800 dramatically shrinks the iPhones attack surface and the number of 56 00:03:15,800 --> 00:03:19,920 entry points that cyber criminal can exploit. 57 00:03:20,040 --> 00:03:22,440 It will disable and restrict features that are commonly 58 00:03:22,440 --> 00:03:26,920 abused in like spyware attacks, and also force attackers to 59 00:03:26,920 --> 00:03:31,240 develop far more complex and expensive techniques to even 60 00:03:31,240 --> 00:03:33,720 attempt a compromise on the phone. 61 00:03:34,480 --> 00:03:38,000 Apple designed it in direct response to commercial spyware 62 00:03:38,000 --> 00:03:42,240 vendors like the NSO Group, which they make the software 63 00:03:42,240 --> 00:03:43,880 Pegasus. If you've heard of that 64 00:03:44,120 --> 00:03:47,560 intellectual which makers of Predator and Paragon solutions 65 00:03:47,560 --> 00:03:49,880 who sell government grade hacking tools capable of 66 00:03:49,880 --> 00:03:53,160 silently compromising iPhones. So why are we talking about 67 00:03:53,160 --> 00:03:56,160 this? Well, Ale has confirmed that 68 00:03:56,160 --> 00:04:01,000 after four years of this feature being around that no one using 69 00:04:01,000 --> 00:04:04,480 lockdown mode has been successfully hacked by spyware. 70 00:04:05,040 --> 00:04:07,200 Or at least that they know of, I should say. 71 00:04:08,120 --> 00:04:10,800 And, and of course, like they're monitoring this pretty closely. 72 00:04:10,800 --> 00:04:13,440 So I, I would take Apple at its word for this one. 73 00:04:13,440 --> 00:04:16,360 Apple spokesperson Sarah O'Rourke stated that they were 74 00:04:16,360 --> 00:04:19,279 not aware of any successful mercenary spyware attacks 75 00:04:19,279 --> 00:04:21,839 against a lockdown mode enabled device. 76 00:04:22,079 --> 00:04:25,080 And that's really a meaningful milestone here. 77 00:04:25,440 --> 00:04:28,160 Apple has sent spyware compromise notifications to 78 00:04:28,160 --> 00:04:33,360 users in over 150 countries, so they really do have visibility 79 00:04:33,360 --> 00:04:36,680 into this threat. And independent researchers at 80 00:04:36,680 --> 00:04:39,720 Citizen Lab have documented at least 2 cases where Lockdown 81 00:04:39,720 --> 00:04:43,520 mode actively blocked spyware attacks, once against Nso's 82 00:04:43,520 --> 00:04:45,360 Pegasus and once against Predator. 83 00:04:46,200 --> 00:04:49,360 And then in one more other document case, security 84 00:04:49,360 --> 00:04:52,480 researchers at Google found that spyware simply bailed out of its 85 00:04:52,480 --> 00:04:55,800 attack attempt when it detected lockdown mode. 86 00:04:55,960 --> 00:04:59,760 So attackers basically gave up rather than risk exposure. 87 00:04:59,840 --> 00:05:03,880 Apple's cybersecurity expert Patrick Wardle, call it one of 88 00:05:03,880 --> 00:05:08,040 the most aggressive consumer facing hardening features ever 89 00:05:08,040 --> 00:05:10,440 shipped. So if you're thinking about 90 00:05:10,440 --> 00:05:13,000 using this, and again, we've we've talked about this before, 91 00:05:13,000 --> 00:05:16,360 but just kind of highlighting the trade-offs if you were to 92 00:05:16,360 --> 00:05:19,160 enable it. And This is why it's really not 93 00:05:19,160 --> 00:05:23,480 for everyone, but most message attachment types are blocked. 94 00:05:23,480 --> 00:05:26,040 So iMessage becomes a lot more limited. 95 00:05:26,080 --> 00:05:28,440 Any attachments beyond images are stripped. 96 00:05:28,440 --> 00:05:31,480 Link previews in messages are also disabled. 97 00:05:31,480 --> 00:05:34,320 So you'll need to copy and paste links manually into your 98 00:05:34,320 --> 00:05:37,480 browser. Webkit, which is so far as 99 00:05:37,480 --> 00:05:39,440 rendering engine features are restricted. 100 00:05:39,440 --> 00:05:42,120 Some websites might not even load correctly at all. 101 00:05:42,480 --> 00:05:45,440 Wired connections to computers or accessories are blocked. 102 00:05:45,440 --> 00:05:49,360 When the iPhone is locked, configuration profiles cannot be 103 00:05:49,360 --> 00:05:53,200 installed, which prevents certain MDM management, Mobile 104 00:05:53,200 --> 00:05:56,600 device management enrollment. Now we've mentioned this before, 105 00:05:56,600 --> 00:06:02,000 but it is worth noting that if the device is enrolled in MDM 106 00:06:02,800 --> 00:06:07,720 and then you enable lockdown mode, it will keep the MDM 107 00:06:07,720 --> 00:06:11,440 profile. However, when you enable 108 00:06:11,440 --> 00:06:16,360 lockdown mode, no additional MDM profiles can be added to the 109 00:06:16,360 --> 00:06:18,760 phone. So it's preventing any other, 110 00:06:18,760 --> 00:06:21,960 which is a common, you know, easy attack vector is just, you 111 00:06:21,960 --> 00:06:25,080 know, send someone a link and roll the phone and then you 112 00:06:25,080 --> 00:06:27,120 know, then you have it under management can do what you want. 113 00:06:27,360 --> 00:06:30,320 And then a couple of things like incoming FaceTime calls from 114 00:06:30,320 --> 00:06:33,720 unknown contacts are blocked and shared albums are removed from 115 00:06:33,720 --> 00:06:36,840 photos and new shared album invite invitations are blocked. 116 00:06:36,840 --> 00:06:41,680 So there is some trade off and and that is definitely felt if 117 00:06:41,680 --> 00:06:44,720 you're just a normal user. Well, for example, like if 118 00:06:44,720 --> 00:06:48,360 you're a journalist covering a war zone, Aceover defense 119 00:06:48,360 --> 00:06:53,560 contractor or like a dissident activist, that friction might be 120 00:06:53,560 --> 00:06:56,200 worth it. So if you're in a high risk 121 00:06:56,200 --> 00:06:59,680 role, this is something that you would definitely want to look 122 00:06:59,680 --> 00:07:01,040 at. You just go to the settings 123 00:07:01,040 --> 00:07:03,560 under privacy and security and enable lockdown mode. 124 00:07:03,560 --> 00:07:07,560 It'll have some, you know, text, give you the the highlights of 125 00:07:07,560 --> 00:07:09,520 exactly what we told you, the trade-offs. 126 00:07:09,520 --> 00:07:13,880 And then you'll you'll make yourself much less inviting 127 00:07:13,880 --> 00:07:16,880 target for cyber attackers, Patrick. 128 00:07:16,880 --> 00:07:21,720 Wardle is that dude. He is the guru of Apple 129 00:07:21,720 --> 00:07:26,680 cybersecurity hosts the objective by the sea conference 130 00:07:26,680 --> 00:07:29,440 cybersecurity conference targeted at just Apple operating 131 00:07:29,440 --> 00:07:32,560 systems. Former champ employee friend of 132 00:07:32,720 --> 00:07:36,320 friend of the show Matthew Ward is is friends with Patrick and 133 00:07:36,320 --> 00:07:39,720 can speak to his chops. So when he says quote, it's one 134 00:07:39,720 --> 00:07:42,520 of the most aggressive consumer facing hardening features ever 135 00:07:42,520 --> 00:07:44,640 shipped. He's not kidding, but a very 136 00:07:44,640 --> 00:07:48,480 effective, right. So there are significant 137 00:07:48,480 --> 00:07:51,480 trade-offs from a lot of these quality of life improvements 138 00:07:51,480 --> 00:07:55,240 we're comfortable with. But you can really limit a tax 139 00:07:55,240 --> 00:07:59,120 surface by giving those up and it makes really intelligent 140 00:07:59,120 --> 00:08:02,480 trade-offs as to what those are. It's amazing how much 141 00:08:02,480 --> 00:08:06,680 cybersecurity attacks surface we just naturally accept for these 142 00:08:06,680 --> 00:08:09,200 quality of life improvements as opposed to have any more 143 00:08:09,200 --> 00:08:11,920 hardened operating system. But Apple gives you that choice. 144 00:08:11,920 --> 00:08:14,720 And Andy, I think you mentioned a lot of the personas where this 145 00:08:14,720 --> 00:08:16,560 makes sense. I'd extend it. 146 00:08:16,560 --> 00:08:19,520 If you're in the C-Suite and you're a Fortune 100 company, 147 00:08:19,520 --> 00:08:22,040 you should have this turned on. I am sure. 148 00:08:22,520 --> 00:08:25,720 I have no doubt Satya Nadella, our CEO at Microsoft has this 149 00:08:25,720 --> 00:08:27,640 turned on his iPhone as an example as well. 150 00:08:27,640 --> 00:08:29,400 He should. Sam Altman should have this 151 00:08:29,400 --> 00:08:32,559 turned on on his iPhone, even though he's not maybe Fortune 152 00:08:32,559 --> 00:08:34,600 100 yet. I mean, being open AI, it's 153 00:08:34,600 --> 00:08:37,200 important gig. There's lots of people this 154 00:08:37,200 --> 00:08:39,440 targets. If you're also a tinfoil hat 155 00:08:39,440 --> 00:08:41,600 aficionado, this is available to you as well. 156 00:08:41,600 --> 00:08:45,920 But you know, a great feature, love it when that choice is put 157 00:08:45,920 --> 00:08:49,520 in the hands of users and great cybersecurity posture is 158 00:08:49,520 --> 00:08:52,120 available with literally a flip of the switch. 159 00:08:52,520 --> 00:08:55,280 So well done to Apple. We complement them on their 160 00:08:55,280 --> 00:08:57,080 cybersecurity chops all of the time. 161 00:08:57,560 --> 00:09:00,600 There was a stupid and inaccurate meme for a very long 162 00:09:00,600 --> 00:09:03,480 time that Apple was only secure because it wasn't popular. 163 00:09:03,920 --> 00:09:08,160 Obviously, today, with the very large popular popularity of iOS 164 00:09:08,160 --> 00:09:10,440 and its derivative operating systems, that's no longer a 165 00:09:10,440 --> 00:09:13,360 valid criticism. It turns out Apple's just good 166 00:09:13,360 --> 00:09:15,760 at cybersecurity. So, you know, credit where 167 00:09:15,760 --> 00:09:18,080 credit's due. And then, you know, going back 168 00:09:18,080 --> 00:09:21,840 to the quote from Apple spokesperson Sarah O'Rourke, 169 00:09:21,840 --> 00:09:26,200 Apple doesn't lie when they speak publicly and they tend to 170 00:09:26,200 --> 00:09:29,840 do less of what I call corporate weasel language than a lot of 171 00:09:29,840 --> 00:09:33,280 other orgs where they will say something that is, if you parse 172 00:09:33,280 --> 00:09:37,080 it like an attorney, factual but not really honest. 173 00:09:37,520 --> 00:09:39,960 Apple doesn't do that. They kind of say what they mean. 174 00:09:40,360 --> 00:09:42,920 And so when Apple just comes out and says they're not aware of 175 00:09:42,920 --> 00:09:46,000 any successful mercenary spyware attacks against a lockdown mode 176 00:09:46,000 --> 00:09:48,240 enabled Apple device, that's what they mean. 177 00:09:48,680 --> 00:09:51,160 Now, again, there are qualifiers in that statement. 178 00:09:51,800 --> 00:09:53,960 They're specifically saying mercenary spyware. 179 00:09:54,800 --> 00:09:56,920 It's not mercenary spyware. I mean, you can make that 180 00:09:56,920 --> 00:09:59,080 distinction. You can also say they're not 181 00:09:59,080 --> 00:10:01,560 aware. Well, they can't talk about it 182 00:10:01,560 --> 00:10:03,760 if they're not aware of it. So of course, there could be a 183 00:10:03,760 --> 00:10:06,760 text they're not aware of. Fine, Sure, you could poke holes 184 00:10:06,760 --> 00:10:09,040 in that statement, but if you just take it at face value, it's 185 00:10:09,040 --> 00:10:11,000 still impressive. So hey, well done, Apple. 186 00:10:11,040 --> 00:10:13,480 You know, we talked about kind of doom and gloom sometimes in 187 00:10:13,480 --> 00:10:17,040 cybersecurity a lot. It's great to acknowledge where 188 00:10:17,040 --> 00:10:19,240 we're getting things right and where things are going well. 189 00:10:19,240 --> 00:10:23,400 So well done to them. OK, so on to our second topic or 190 00:10:23,400 --> 00:10:26,560 second and final topic here. There was a lot of talk about 191 00:10:26,560 --> 00:10:29,800 this whole phantom device attack, so let's kind of dive 192 00:10:29,800 --> 00:10:33,280 into it before we get started. This deals with something called 193 00:10:33,280 --> 00:10:36,360 the PRT, which is the primary refresh token. 194 00:10:36,440 --> 00:10:40,800 So I want to take a few moments to just talk about what the PRT 195 00:10:40,800 --> 00:10:43,400 is. Essentially, it's an extremely 196 00:10:43,400 --> 00:10:47,920 powerful authentication artifact that is in Windows or Azure. 197 00:10:48,000 --> 00:10:51,000 It's like a master key to your identity. 198 00:10:51,280 --> 00:10:55,680 And so when Windows, when a Windows device is joined to 199 00:10:55,680 --> 00:11:00,240 Azure AD or Enter ID today, it gets issued a PRT. 200 00:11:00,240 --> 00:11:03,360 That token is then. Hold on, before you go further, 201 00:11:03,920 --> 00:11:07,400 I want to clarify because the way you worded it is open to 202 00:11:07,400 --> 00:11:09,400 interpretation so I'll just be crystal clear. 203 00:11:09,800 --> 00:11:15,760 PRT supply both to hybrid join as well as enter join devices. 204 00:11:16,480 --> 00:11:19,720 Both scenarios you get PR TS issued to the device. 205 00:11:19,720 --> 00:11:22,320 So if you are hybrid joined, which if you're not familiar 206 00:11:22,320 --> 00:11:25,520 with means you're still on premises domain joined to Active 207 00:11:25,520 --> 00:11:29,720 Directory domain services and then you also have kind of a 208 00:11:29,720 --> 00:11:33,680 registration, not a full join to enter ID as well. 209 00:11:33,800 --> 00:11:36,920 That's hybrid join. And then there's also just enter 210 00:11:36,920 --> 00:11:42,320 join, which means your primary and only device identity is tied 211 00:11:42,320 --> 00:11:45,360 to enter ID. There is no relationship with 212 00:11:45,360 --> 00:11:48,360 Active Directory domain services on premises, it's a cloud joined 213 00:11:48,360 --> 00:11:50,600 device. Effectively both scenarios get 214 00:11:50,600 --> 00:11:52,240 PR TS. Just wanted to clarify that 215 00:11:53,000 --> 00:11:54,000 continue. Correct. 216 00:11:54,040 --> 00:11:59,040 So what I should should have said it's it's also if an ENTRA 217 00:11:59,040 --> 00:12:02,960 registered device happens because ENTRA registered devices 218 00:12:03,000 --> 00:12:06,880 also get PRTS. So it's an artefact that lives 219 00:12:06,880 --> 00:12:10,560 anytime you've authenticated successfully on a device to 220 00:12:10,560 --> 00:12:15,680 ENTRA, whether it's joined or or registered, the device will get 221 00:12:15,680 --> 00:12:18,920 a PRT. And so that that's issued, it 222 00:12:18,920 --> 00:12:24,880 sits on the device is then used to obtain access tokens for your 223 00:12:24,880 --> 00:12:29,720 cloud resources like Office 365, SharePoint, Azure, so on and so 224 00:12:29,720 --> 00:12:33,360 forth without you having to re authenticate each time. 225 00:12:34,280 --> 00:12:38,520 Very different than like a browser because it's it's 226 00:12:38,520 --> 00:12:41,400 similar to like a token that gets issued in the browser, like 227 00:12:41,400 --> 00:12:45,080 a session token, which then you would exchange for access 228 00:12:45,080 --> 00:12:48,080 tokens. But this one sits at the device 229 00:12:48,080 --> 00:12:52,040 level so specific to Windows. And it's the mechanism that's 230 00:12:52,400 --> 00:12:55,960 that really is responsible for single sign on across any 231 00:12:55,960 --> 00:12:58,280 Microsoft service on a Windows device. 232 00:12:58,400 --> 00:13:02,760 The PRT does carry a cryptographic device claim. 233 00:13:02,760 --> 00:13:07,200 So it says like this is access coming from a trusted compliant 234 00:13:07,200 --> 00:13:09,360 device. Conditional access policies can 235 00:13:09,480 --> 00:13:12,280 use those claims to decide whether or not to allow access 236 00:13:12,280 --> 00:13:15,320 or deny access. And in a normal, healthy 237 00:13:15,320 --> 00:13:19,520 environment, the PRT is hardware bound, which means that it's 238 00:13:19,520 --> 00:13:23,360 stored on the TPM chip, which makes it extremely difficult to 239 00:13:23,360 --> 00:13:27,640 steal or fake. So the problem here is what 240 00:13:27,920 --> 00:13:32,560 happens if you can generate a PRT for a fake device. 241 00:13:32,640 --> 00:13:34,160 And I'm going to nitpick one thing. 242 00:13:34,160 --> 00:13:37,840 A PRT does not say a device is compliant. 243 00:13:38,080 --> 00:13:42,880 OK, that's fair. This is where like being precise 244 00:13:42,880 --> 00:13:45,360 with the language matters and we'll get into this more a 245 00:13:45,360 --> 00:13:49,160 little bit as we go through it. Sometimes there's misconceptions 246 00:13:49,160 --> 00:13:54,080 around a registered device, a recognized device that's part of 247 00:13:54,080 --> 00:13:58,560 our organization is not equivalent to is compliant and 248 00:13:58,560 --> 00:14:02,000 we'll we'll unpack that later. But I just want to put him pin 249 00:14:02,000 --> 00:14:06,000 in that one point. APRT could say this device is 250 00:14:06,000 --> 00:14:10,920 from your organization and you can trust it, but it doesn't say 251 00:14:11,080 --> 00:14:14,160 this is past point in time at a station right now. 252 00:14:14,240 --> 00:14:17,120 All of these variables that you're looking for are set to 253 00:14:17,120 --> 00:14:20,440 this way. The PRT itself doesn't do that. 254 00:14:20,440 --> 00:14:22,800 So we'll, we'll unpack that more in a moment, but I just want to 255 00:14:22,800 --> 00:14:26,080 put a pin in that point. And it's, it's easy to slip on 256 00:14:26,080 --> 00:14:28,480 the language there and, and we'll figure out, you'll 257 00:14:28,480 --> 00:14:31,840 understand why in a little bit. So it's a little teaser for us. 258 00:14:31,840 --> 00:14:33,520 We go through the rest of this. Yeah. 259 00:14:33,520 --> 00:14:36,120 Thank you for that call out. That is absolutely correct 260 00:14:36,120 --> 00:14:38,480 there. OK And then the other thing I 261 00:14:38,480 --> 00:14:42,200 wanted to touch on is device code flow because that was also 262 00:14:42,200 --> 00:14:45,040 abused in this attack. So if you haven't heard about 263 00:14:45,040 --> 00:14:48,880 device code flow, just a real quick explanation of what that 264 00:14:48,880 --> 00:14:51,600 is. It's Oauth 2.0 authentication 265 00:14:51,760 --> 00:14:55,480 that originally was designed for devices that can't easily 266 00:14:55,480 --> 00:14:58,520 display a browser or accept keyboard input. 267 00:14:58,880 --> 00:15:03,480 So a really good way to just understand this is like when you 268 00:15:03,920 --> 00:15:07,600 authenticate to Netflix for like your Apple TV and that has like 269 00:15:07,600 --> 00:15:10,440 a QR code. Disney Plus, Paramount Plus, 270 00:15:10,440 --> 00:15:13,440 Hulu, you name it, all of that. HBO Max, all of them 271 00:15:13,760 --> 00:15:16,800 authenticate with that. Device code flow, Yep. 272 00:15:17,120 --> 00:15:21,240 And so that also works for Microsoft because like, you 273 00:15:21,240 --> 00:15:24,120 know, there used to be like Surface devices or really any 274 00:15:24,120 --> 00:15:29,000 device, there's like a, there's a Oauth standard that allows you 275 00:15:29,000 --> 00:15:34,360 to authenticate to Microsoft services on a device that you 276 00:15:34,360 --> 00:15:37,720 can't type or you can't, you know, have a browser display so 277 00:15:37,720 --> 00:15:40,560 that you can go login. So for example, then you can 278 00:15:40,560 --> 00:15:42,640 like generate a short code and say go to 279 00:15:42,640 --> 00:15:46,840 microsoft.com/devicelogin. Then they go to their phone, you 280 00:15:46,840 --> 00:15:49,760 know, go to that and bring up the browser and then it flows 281 00:15:49,760 --> 00:15:54,160 that authentication over to the device like the TV or signage or 282 00:15:54,160 --> 00:15:56,360 something. But then we'll log them in. 283 00:15:56,360 --> 00:16:00,440 There's a security risk to this because this flows target from 284 00:16:00,440 --> 00:16:03,640 the device registration service endpoint rather than the 285 00:16:03,640 --> 00:16:06,720 standard token endpoint, meaning conditional access policies that 286 00:16:06,720 --> 00:16:11,320 normally guard the logins on the device don't automatically 287 00:16:11,320 --> 00:16:13,400 intercept it on the new device, that is. 288 00:16:13,440 --> 00:16:16,120 And then secondly, it's heavily abused in phishing. 289 00:16:16,120 --> 00:16:19,120 So an attacker can generate the device code themselves, then 290 00:16:19,120 --> 00:16:22,320 send a convincing e-mail to a victim, and then the e-mail will 291 00:16:22,320 --> 00:16:25,080 then the victim will then enter the code thinking that they're 292 00:16:25,080 --> 00:16:29,760 verifying the account, and the attacker's machine then receives 293 00:16:29,760 --> 00:16:33,560 the access token. So in this attack that we're 294 00:16:33,560 --> 00:16:36,600 gonna be talking about, device code flow was the pivot where 295 00:16:36,600 --> 00:16:39,040 the authentication path that conditional access wasn't 296 00:16:39,040 --> 00:16:42,440 blocking, which then opened the door to everything else. 297 00:16:42,480 --> 00:16:47,440 So let's talk about the attack chain and why everyone was like, 298 00:16:47,440 --> 00:16:51,440 well, conditional access was bypassed and you know, there's a 299 00:16:51,440 --> 00:16:54,920 bug or whatever it is, right? And so there were some 300 00:16:54,920 --> 00:16:58,920 researchers from Holler sell Sideris that conducted an 301 00:16:58,920 --> 00:17:02,560 authorized red team operation against a production tenant with 302 00:17:02,560 --> 00:17:08,160 over 16,000 users and 78 conditional access policies. 303 00:17:08,160 --> 00:17:11,359 They did start with a single set of valid credentials. 304 00:17:11,480 --> 00:17:14,640 So that's kind of important, which is usually the kind that 305 00:17:14,640 --> 00:17:19,119 is available on a criminal market or something like that 306 00:17:19,119 --> 00:17:22,720 for a few $100. But with that they were able to 307 00:17:22,720 --> 00:17:26,119 achieve full global administrator access. 308 00:17:26,400 --> 00:17:29,680 And how did they do that? Well, first they, they tried the 309 00:17:29,680 --> 00:17:32,080 direct authentication, they tried the stolen credentials, 310 00:17:32,480 --> 00:17:34,560 which was blocked via conditional access. 311 00:17:34,560 --> 00:17:38,840 So that did it's job. But then they pivoted using 312 00:17:38,840 --> 00:17:42,440 Oauth flow. So the the standard resource 313 00:17:42,440 --> 00:17:47,120 owner, now password credentials ROPC grant was also blocked. 314 00:17:47,120 --> 00:17:51,080 But the device code flow which targets the device registration 315 00:17:51,080 --> 00:17:54,360 and service endpoint rather than the normal token endpoint was 316 00:17:54,360 --> 00:17:57,640 not intercepted. So the tenant that they attacked 317 00:17:57,640 --> 00:18:01,600 actually did have a policy specifically designed to block 318 00:18:01,680 --> 00:18:04,800 device code flow. This is part of intra 319 00:18:04,800 --> 00:18:08,160 conditional access. There's a check box for device 320 00:18:08,160 --> 00:18:11,640 code flow and you can just check that as a condition and then the 321 00:18:11,640 --> 00:18:15,440 access you can block. But in this case it was sitting 322 00:18:15,440 --> 00:18:19,760 in report only mode, so it logged the attempt, but it 323 00:18:19,760 --> 00:18:23,040 didn't do anything else so the token was actually obtained. 324 00:18:23,200 --> 00:18:26,240 Coincidentally, this is also kind of the same entry vector 325 00:18:26,240 --> 00:18:30,680 that Storm 2372, which is a suspected Russian state aligned 326 00:18:30,680 --> 00:18:35,840 threat actor has been exploiting at scale since August 2024. 327 00:18:35,880 --> 00:18:40,160 And they target governments, defense contractors, healthcare 328 00:18:40,160 --> 00:18:43,360 and critical infrastructure in Europe and North America. 329 00:18:43,440 --> 00:18:46,600 So once they had the valid token. 330 00:18:46,720 --> 00:18:49,480 Let's just pause there because I, I'm going to, yeah, every 331 00:18:49,480 --> 00:18:52,480 time you go through these, I'm going to pipe in and say, OK, 332 00:18:52,520 --> 00:18:54,560 device code flow should be blocked. 333 00:18:55,000 --> 00:18:58,200 If you are not blocking it for every possible scenario except 334 00:18:58,440 --> 00:19:00,720 carve outs for only the scenarios where you must leave 335 00:19:00,720 --> 00:19:03,680 it enabled, go and do turn off this podcast. 336 00:19:03,680 --> 00:19:06,200 Go and block it right now. Like listeners, like I'm going 337 00:19:06,200 --> 00:19:08,440 to keep jumping and I'm like, this is bad. 338 00:19:08,440 --> 00:19:10,160 Go fix this. Here's your first one. 339 00:19:10,160 --> 00:19:14,400 Device code flow blocked unless you must have it and only 340 00:19:14,400 --> 00:19:18,080 allowed for scenarios you had it, had the organization done 341 00:19:18,080 --> 00:19:20,120 that. And this is in Microsoft 342 00:19:20,120 --> 00:19:22,800 documentation. This is documented as Microsoft 343 00:19:22,800 --> 00:19:25,480 recommends you disable this. The attack does not continue. 344 00:19:25,520 --> 00:19:27,520 So there's your first chance to prevent this attack. 345 00:19:28,000 --> 00:19:29,240 Continue, Andy. OK. 346 00:19:29,360 --> 00:19:31,160 Yeah, thanks. Thanks for jumping in there. 347 00:19:31,360 --> 00:19:33,120 Yeah. Well, I just want to hit them as 348 00:19:33,120 --> 00:19:35,240 we go instead of after in this case. 349 00:19:35,680 --> 00:19:38,320 Great, I love it. So once they have that valid 350 00:19:38,320 --> 00:19:42,320 token, because, you know, device code flow wasn't blocked, they 351 00:19:42,320 --> 00:19:46,040 were able to hit the Device Registration Service API and 352 00:19:46,240 --> 00:19:49,320 that's called the DRS. The DRS validates the token, but 353 00:19:49,320 --> 00:19:52,840 it does not verify that the caller is a real Windows 354 00:19:52,840 --> 00:19:55,680 machine. So it's just the token itself. 355 00:19:56,400 --> 00:20:00,240 And so using a single command on a Linux laptop with no physical 356 00:20:00,240 --> 00:20:03,960 hardware, no TPM chip, no admin approval, they were able to 357 00:20:03,960 --> 00:20:07,000 register a completely fake phantom device. 358 00:20:07,480 --> 00:20:11,600 So enter ID issued a fully signed certificate and private 359 00:20:11,600 --> 00:20:15,720 key indistinguishable from legitimate corporate endpoint. 360 00:20:16,240 --> 00:20:20,720 So what should have happened is, you know, in general you can 361 00:20:20,720 --> 00:20:24,360 enable MFA for device registration, so. 362 00:20:24,880 --> 00:20:29,640 If I try to register a new device under a user, it will 363 00:20:29,640 --> 00:20:34,320 prompt me for MFA and the users. This organization again had a 364 00:20:34,320 --> 00:20:39,320 policy requiring MFA for device registration, but again it was 365 00:20:39,360 --> 00:20:43,840 in report mode, report only mode, so it logged the 366 00:20:43,840 --> 00:20:46,240 registration would have blocked nothing. 367 00:20:46,240 --> 00:20:49,520 OK, here I'm jumping in again. You just hit it, but I want to 368 00:20:49,520 --> 00:20:50,880 clarify this point a little more. 369 00:20:50,880 --> 00:20:55,440 There is a setting, an enter ID where you can say require MFA 370 00:20:55,440 --> 00:20:58,680 for device registrations to do an enter ID registration or an 371 00:20:58,680 --> 00:21:02,200 enter ID join. That is the second layer of 372 00:21:02,200 --> 00:21:04,360 protection. The first layer should just be 373 00:21:04,360 --> 00:21:08,160 you don't allow anyone to authenticate ever without multi 374 00:21:08,160 --> 00:21:11,600 factor authentication. So to be clear, Microsoft's 375 00:21:11,600 --> 00:21:15,480 guidance is absolutely you should do MFA 100% of the time 376 00:21:15,480 --> 00:21:17,640 no matter what. And if you're going to ignore 377 00:21:17,640 --> 00:21:21,400 that, then at least let me implore you require MFA for all 378 00:21:21,400 --> 00:21:23,720 device registrations. Somebody should not be able to 379 00:21:23,720 --> 00:21:26,400 enroll a device with just a username and password. 380 00:21:26,440 --> 00:21:28,600 That should never ever be allowed. 381 00:21:28,600 --> 00:21:30,760 And so there is your second opportunity to block this 382 00:21:30,760 --> 00:21:36,000 required MFA org wide or at a bare minimum, if nothing else, 383 00:21:36,000 --> 00:21:39,320 if you can't go get MFA deployed tomorrow, turn on MFA for device 384 00:21:39,320 --> 00:21:41,080 registration tomorrow. And I don't care if you break 385 00:21:41,080 --> 00:21:44,000 stuff at that point like it should absolutely positively be 386 00:21:44,000 --> 00:21:45,960 on. There's your second chance now 387 00:21:45,960 --> 00:21:48,000 to block this attack. And while this doesn't 388 00:21:48,000 --> 00:21:53,720 necessarily block the attack, it does give some warning, which I 389 00:21:53,720 --> 00:21:57,760 would say just as a like a sub bullet here, you should have 390 00:21:57,760 --> 00:22:02,760 some sort of notification when a new device is registered under a 391 00:22:02,760 --> 00:22:06,520 user. So at Microsoft, whenever I 392 00:22:06,520 --> 00:22:10,480 register a new device, I get an e-mail and my manager gets an 393 00:22:10,480 --> 00:22:13,280 e-mail. And it's standard security 394 00:22:13,280 --> 00:22:18,040 practice now to, for the manager to verify, obviously, like I'm 395 00:22:18,040 --> 00:22:20,760 a, I'm a, you know, security technical guy. 396 00:22:20,760 --> 00:22:23,960 So I'm tinkering with devices and joining them all the time 397 00:22:23,960 --> 00:22:26,000 and re wiping. And so my managers getting these 398 00:22:26,000 --> 00:22:28,840 emails, I just normally preemptively like send them the 399 00:22:28,840 --> 00:22:32,240 e-mail and say, Hey, this was me on a Saturday, just, you know, 400 00:22:32,760 --> 00:22:35,120 re wiping my device or whatever, right? 401 00:22:35,320 --> 00:22:37,840 I explain what it is too. I give a little context. 402 00:22:38,320 --> 00:22:40,960 Yeah. And so, but if if I don't say 403 00:22:40,960 --> 00:22:46,240 anything that the standard SOP is for the manager to e-mail the 404 00:22:46,240 --> 00:22:48,320 employee and say, hey, what happened here? 405 00:22:48,320 --> 00:22:50,360 Is this you? So that's just kind of another 406 00:22:50,760 --> 00:22:53,680 checks and balance type of deal. And in fact, I think it was 407 00:22:53,760 --> 00:22:58,600 what's the security company that Google acquired that does all 408 00:22:58,600 --> 00:22:59,760 the. Mandiant. 409 00:23:00,000 --> 00:23:02,760 Mandiant, yeah. So Mandiant I think was hacked a 410 00:23:02,760 --> 00:23:04,560 few years ago or something like that. 411 00:23:04,560 --> 00:23:07,640 And the reason why they even went into the investigation was 412 00:23:07,960 --> 00:23:11,640 the attackers registered a device and they had an e-mail 413 00:23:11,640 --> 00:23:14,600 sent to that employee and the employee was like, I didn't 414 00:23:14,600 --> 00:23:17,160 register a device. And they kicked off the 415 00:23:17,160 --> 00:23:19,200 investigation and that's how they found out that they were 416 00:23:19,200 --> 00:23:21,600 hacked. And so this is this is important 417 00:23:21,600 --> 00:23:24,200 here. So obviously require MFA and 418 00:23:24,200 --> 00:23:26,640 then a sub bullet. Even if you do that, you should 419 00:23:26,680 --> 00:23:30,120 have some sort of notification which would might trick up strip 420 00:23:30,120 --> 00:23:34,880 some flags that you would know. So now that they had the phantom 421 00:23:34,880 --> 00:23:38,200 device certificate that was issued, the researchers were 422 00:23:38,200 --> 00:23:41,760 able to request a primary refresh token, the PRT, which 423 00:23:41,760 --> 00:23:45,880 emulates what Windows does during a normal user sign up. 424 00:23:46,360 --> 00:23:49,600 And that PRT was then they saved it in a plain text file on the 425 00:23:49,600 --> 00:23:52,840 Linux desktop. So when they exchange for an 426 00:23:52,840 --> 00:23:59,320 access token, the token carried the the user, the password and 427 00:23:59,320 --> 00:24:02,560 the device ID claim, which was the cryptographic proof that the 428 00:24:02,560 --> 00:24:05,200 conditional access uses to evaluate device trust. 429 00:24:05,200 --> 00:24:08,840 Those same credentials were then triggered on a direct login, 430 00:24:08,840 --> 00:24:12,280 then sailed through every policy required compliant or enter a 431 00:24:12,280 --> 00:24:14,680 joint device. So I I want to pause there. 432 00:24:14,680 --> 00:24:19,240 Yeah, I knew you wanted to. Because and and I read the 433 00:24:19,240 --> 00:24:21,440 Sedaris report. And by the way, this has been 434 00:24:21,440 --> 00:24:25,000 reposted and paraphrased by all these junkie cybersecurity blogs 435 00:24:25,000 --> 00:24:28,720 with a billion ads on them. I went and read the actual HOWL 436 00:24:28,720 --> 00:24:31,320 or cell report, and this part is a little unclear. 437 00:24:31,760 --> 00:24:34,560 But this is where I want to add a little more commentary as well 438 00:24:34,560 --> 00:24:37,480 because I think I know what happened here and they're 439 00:24:37,480 --> 00:24:39,600 playing a little bit with the language, I think, and being a 440 00:24:39,600 --> 00:24:43,520 little imprecise. So I'm going to be very precise. 441 00:24:43,680 --> 00:24:47,160 There are two options when you configure a conditional access 442 00:24:47,160 --> 00:24:49,520 policy that are relevant in this case. 443 00:24:49,520 --> 00:24:52,440 There's more options but I'm focusing on 2/1 of them says 444 00:24:53,240 --> 00:24:58,280 require hybrid join device, one of them says require compliant 445 00:24:58,320 --> 00:25:02,520 device and those seem very similar and they're even right 446 00:25:02,520 --> 00:25:05,920 next to each other on the list. They could not be more different 447 00:25:06,680 --> 00:25:09,600 and this is what I was earlier in the conversation. 448 00:25:10,320 --> 00:25:14,560 Require hybrid join device is just looking for that primary 449 00:25:14,560 --> 00:25:19,120 refresh token with that cryptographic proof of device 450 00:25:19,120 --> 00:25:22,520 trust that the device is hybrid joined. 451 00:25:22,520 --> 00:25:25,880 So all it's checking is are you and does the device respond and 452 00:25:25,880 --> 00:25:29,960 say yes I am joined to your domain and I've received a 453 00:25:29,960 --> 00:25:33,200 primary refresh token I am a trusted device. 454 00:25:33,920 --> 00:25:39,240 It is explicitly not checking the device compliance that is a 455 00:25:39,240 --> 00:25:42,800 different thing. It is point in time attestation. 456 00:25:42,840 --> 00:25:49,360 It is substantially weaker from a trust perspective then require 457 00:25:49,360 --> 00:25:52,720 compliant device. So just want to put that out 458 00:25:52,720 --> 00:25:54,200 there. I believe this tenant was 459 00:25:54,200 --> 00:25:58,160 configured for that based on my read through of the Howler cell 460 00:25:58,160 --> 00:26:00,440 report. It's a little unclear, but I 461 00:26:00,440 --> 00:26:03,920 think the tenant was configured for require hybrid join device. 462 00:26:04,440 --> 00:26:08,760 I don't believe it was set to require compliant device because 463 00:26:09,040 --> 00:26:13,560 require compliant device. What that is looking for is, is 464 00:26:13,560 --> 00:26:16,520 this device enrolled in Intune? Is there a compliance policy 465 00:26:16,520 --> 00:26:20,680 assigned to the device? Has it successfully completed 466 00:26:20,720 --> 00:26:23,480 the compliance policy? Does it show all green check 467 00:26:23,480 --> 00:26:27,120 marks effectively? Often times you can configure 468 00:26:27,400 --> 00:26:30,320 there to be some sort of grace period where the device won't 469 00:26:30,320 --> 00:26:34,080 get kicked off if it's not compliant until a certain number 470 00:26:34,080 --> 00:26:35,960 of hours have passed. You allow some time for 471 00:26:35,960 --> 00:26:39,640 evaluation of that compliance policy to complete when a device 472 00:26:39,640 --> 00:26:42,480 is initially enrolled. They don't talk about that at 473 00:26:42,480 --> 00:26:45,800 all in this reporting, but that certainly could be a risk as 474 00:26:45,800 --> 00:26:48,640 well where a device gets enrolled and is able to do 475 00:26:48,640 --> 00:26:51,400 something before it's determined, hey, this isn't even 476 00:26:51,400 --> 00:26:54,800 a Windows device, this is Linux. Like what's going on here, But 477 00:26:54,800 --> 00:26:57,600 compliant device is the one that will look for like what is the 478 00:26:57,600 --> 00:27:00,240 current risk profile defender for endpoint? 479 00:27:00,240 --> 00:27:02,760 Is BitLocker enabled? Is the password a certain 480 00:27:02,760 --> 00:27:04,680 length? Is the version number this or 481 00:27:04,680 --> 00:27:06,600 greater? Is this feature turned on? 482 00:27:06,600 --> 00:27:08,520 Is that feature enabled? So on and so forth. 483 00:27:08,800 --> 00:27:10,320 That's what a compliance policy is. 484 00:27:10,480 --> 00:27:13,960 So I believe what they're saying here, and again, this is 485 00:27:13,960 --> 00:27:16,320 unclear. This tenant was not configured 486 00:27:16,320 --> 00:27:20,200 for compliance evaluation being required to authenticate. 487 00:27:20,440 --> 00:27:22,200 It was configured for hybrid join. 488 00:27:22,480 --> 00:27:24,560 And a lot of people in their minds see those as these are the 489 00:27:24,560 --> 00:27:26,320 same thing. They're not. 490 00:27:26,600 --> 00:27:29,720 The other thing I want to point out, and this also trips people 491 00:27:29,720 --> 00:27:34,440 up all the time, there is no conditional access policy for 492 00:27:34,440 --> 00:27:37,920 require, enter, join. There's no way to check for that 493 00:27:38,880 --> 00:27:40,560 at all. Maybe there is a way to check 494 00:27:40,560 --> 00:27:42,600 for it, I shouldn't say in speaking such absolutes, but 495 00:27:42,600 --> 00:27:45,760 from a conditional access perspective, that's not what you 496 00:27:45,760 --> 00:27:49,080 look for you at that point if it's enter joined, you're 497 00:27:49,080 --> 00:27:51,720 checking the Intune compliance and enter join. 498 00:27:51,720 --> 00:27:55,120 Remember that's the fully cloud joined model, not that hybrid 499 00:27:55,120 --> 00:27:58,480 model where you have the on premises join and the cloud 500 00:27:58,480 --> 00:28:02,280 registration component. So that's what I think happened. 501 00:28:02,320 --> 00:28:04,120 Little unclear. Andy, you can go through the 502 00:28:04,120 --> 00:28:07,800 rest of the story, but I think also potentially now this is 503 00:28:07,800 --> 00:28:09,120 where there's little shade of grey. 504 00:28:09,840 --> 00:28:12,760 I think an opportunity to harden your posture because most 505 00:28:12,760 --> 00:28:16,920 organizations today, I think are still configured for require 506 00:28:16,920 --> 00:28:20,720 hybrid join device, whereas I would much rather see you 507 00:28:21,160 --> 00:28:25,160 require compliant device. Compliant device is ongoing 508 00:28:25,160 --> 00:28:29,080 point in time attestation. That device could be healthy and 509 00:28:29,080 --> 00:28:32,480 then it could become unhealthy. And when it becomes unhealthy, 510 00:28:32,480 --> 00:28:35,080 it gets evicted from the tenant. You know, temporarily like you 511 00:28:35,080 --> 00:28:38,280 lose your access until you remediate the thing that's not 512 00:28:38,280 --> 00:28:41,280 compliant. So it's much more powerful 513 00:28:41,560 --> 00:28:43,880 versus point in time attestation. 514 00:28:43,880 --> 00:28:45,520 At one point we trusted this device. 515 00:28:45,880 --> 00:28:48,840 And by the way, a lot of competitive ID PS I'm looking at 516 00:28:48,840 --> 00:28:51,360 an octave direction. They're all point in time at a 517 00:28:51,360 --> 00:28:53,160 station. Their device trust model is I 518 00:28:53,160 --> 00:28:54,600 have dropped a cert on this device. 519 00:28:54,600 --> 00:28:57,560 I now trust it forever. As long as that cert is there, I 520 00:28:57,560 --> 00:28:59,360 don't really care about the health of the device. 521 00:28:59,800 --> 00:29:01,880 And that's where Entra and Intune are differentiated. 522 00:29:01,880 --> 00:29:06,160 Is that ongoing at a station? But a lot of orgs even to this 523 00:29:06,160 --> 00:29:08,960 day still are not available availing themselves to it. 524 00:29:09,400 --> 00:29:11,840 So even if you're still like we're still a configuration 525 00:29:11,840 --> 00:29:15,640 manager shop SCCM till it the heat death of the universe, 526 00:29:16,080 --> 00:29:18,320 fine. You can still enable Co 527 00:29:18,320 --> 00:29:21,760 management with Intune and you can still delegate some 528 00:29:22,200 --> 00:29:25,720 compliance checking to Intune, or you can still keep compliance 529 00:29:25,720 --> 00:29:29,280 checks in configuration manager and just make Intune aware of 530 00:29:29,280 --> 00:29:31,640 them with Co management as well. There's different options for 531 00:29:31,640 --> 00:29:35,320 configuring that, but either way you should move to this model of 532 00:29:35,320 --> 00:29:38,800 looking for compliant device as opposed to just point in time at 533 00:29:38,800 --> 00:29:40,800 a station. At this point, there's really 534 00:29:40,800 --> 00:29:43,440 kind of you're running out of reasons not to, but it's it's 535 00:29:43,440 --> 00:29:46,440 unclear, but I'd be willing to bet if this tenant were 536 00:29:46,440 --> 00:29:49,680 configured with require compliant device, this also 537 00:29:49,680 --> 00:29:51,320 potentially stops this attack here. 538 00:29:51,640 --> 00:29:54,640 That's my opinion. That part's a little unclear and 539 00:29:54,640 --> 00:29:58,200 it's because most people are just not super fluent in the 540 00:29:58,320 --> 00:30:01,800 minutia and differences here. But you, dear listener, now are 541 00:30:01,800 --> 00:30:03,840 because you listen to the Blue Security Podcast. 542 00:30:04,640 --> 00:30:09,520 Yeah, I looked at multiple reports on this and what you're 543 00:30:09,520 --> 00:30:11,880 saying is correct. And I think the reason why it's 544 00:30:11,880 --> 00:30:15,760 confusing is because a lot of the reporting uses the word 545 00:30:15,760 --> 00:30:18,360 compliant and how I minced it in the beginning. 546 00:30:18,360 --> 00:30:21,160 Just like like you're when you use the word compliance, it 547 00:30:21,160 --> 00:30:22,600 means there's a compliance policy. 548 00:30:23,080 --> 00:30:27,760 But if you are just checking for a hybrid joined, that doesn't 549 00:30:27,760 --> 00:30:30,440 actually trick trigger a compliance check. 550 00:30:30,560 --> 00:30:33,960 It just checks the conditional access policy and it says, Hey, 551 00:30:33,960 --> 00:30:36,240 you're good here and you're good to go. 552 00:30:36,240 --> 00:30:39,800 I, I like to equate that to, I use like an analogy of like a, 553 00:30:39,800 --> 00:30:42,160 like a concert, right? Like I'm checking my 554 00:30:42,160 --> 00:30:45,520 credentials, I have a ticket, I go into the concert and that's, 555 00:30:45,640 --> 00:30:47,880 that's it. Like that's the, that's the 556 00:30:47,920 --> 00:30:50,080 hybrid join. I, I check to see if I have a 557 00:30:50,080 --> 00:30:51,520 ticket, I'm in. That's it. 558 00:30:52,240 --> 00:30:54,880 The compliance check is like, OK, well, now I'm inside the 559 00:30:54,880 --> 00:30:56,800 concert and I try to do some bad things, right? 560 00:30:56,800 --> 00:30:59,680 Like maybe I get too drunk. Well, then the security guard 561 00:30:59,680 --> 00:31:02,120 comes and, and says, hey, you're, you're doing some bad 562 00:31:02,120 --> 00:31:03,560 stuff. I'm going to toss you out. 563 00:31:03,680 --> 00:31:06,840 And so that's that continuous attestation, which is a 564 00:31:06,840 --> 00:31:10,480 compliant device where we're continually checking like, hey, 565 00:31:10,480 --> 00:31:13,680 OK, you're a little bit drunk. OK, that's fine. 566 00:31:13,680 --> 00:31:16,320 You're low risk right now. But all of a sudden you, you 567 00:31:16,320 --> 00:31:17,880 start to get really, really drunk. 568 00:31:17,880 --> 00:31:20,040 Now you're high risk. OK, now we're going to kick you 569 00:31:20,040 --> 00:31:20,600 out. Right. 570 00:31:20,600 --> 00:31:22,560 I like the analogy. Absolutely perfect. 571 00:31:22,560 --> 00:31:24,240 Yeah. You scan the ticket, you're in 572 00:31:24,240 --> 00:31:27,640 like we let you in. And and if you're at, you know, 573 00:31:27,640 --> 00:31:29,960 some festival where they're not really enforcing much of 574 00:31:29,960 --> 00:31:33,480 anything, but that's basically what require hybrid join is 575 00:31:33,480 --> 00:31:35,400 doing. You have a ticket, you're good. 576 00:31:35,720 --> 00:31:38,520 And, and I have no doubt based on everything these folks have 577 00:31:38,520 --> 00:31:41,560 reported at Sedaris and Hallersall, I have no doubt they 578 00:31:41,560 --> 00:31:44,720 were able to mint a PRT that said, yeah, I'm hybrid join, let 579 00:31:44,720 --> 00:31:47,520 me in. OK. 580 00:31:47,760 --> 00:31:50,760 You know, that's, that's why that's a weaker control and it 581 00:31:50,760 --> 00:31:54,480 shouldn't be your only control. You should be full fully aware 582 00:31:54,480 --> 00:31:58,080 it's a weak control. And, and this is where, you 583 00:31:58,080 --> 00:32:01,680 know, bigger picture, just thinking about where do you 584 00:32:01,680 --> 00:32:04,240 invest your effort from a cybersecurity perspective? 585 00:32:04,480 --> 00:32:07,440 And you know, we, we need to finish walking through the, the 586 00:32:07,480 --> 00:32:09,320 tech chain. So I'm sorry for jumping in here 587 00:32:09,320 --> 00:32:14,680 and going on a tangent, but if my guidance to you is require 588 00:32:14,680 --> 00:32:19,560 MFA for device registration, disable device code flows, you 589 00:32:19,560 --> 00:32:21,840 should really move away from hyper join and move to cloud 590 00:32:21,840 --> 00:32:24,880 join. You should really move to Intune 591 00:32:24,880 --> 00:32:28,640 compliance check as your entry ID conditional access policy. 592 00:32:29,200 --> 00:32:33,520 How much effort do you go spend engineering like ways to ensure 593 00:32:33,520 --> 00:32:36,640 that it's a Windows device that is stating that it's doing these 594 00:32:36,640 --> 00:32:39,080 things? How much engineering effort do 595 00:32:39,080 --> 00:32:41,920 you go pour into that because it's all opportunity cost. 596 00:32:41,920 --> 00:32:45,840 If you're doing that in hardening a scenario that I have 597 00:32:45,840 --> 00:32:49,000 advised you is not a high confidence, high security 598 00:32:49,000 --> 00:32:52,560 scenario, that is opportunity cost away from investing in 599 00:32:52,560 --> 00:32:56,960 modern attacks that can hit even well configured, well managed 600 00:32:56,960 --> 00:32:58,920 tenants where they're doing everything right. 601 00:32:59,400 --> 00:33:02,000 And I think I'd rather have it over there where you're, you're 602 00:33:02,000 --> 00:33:04,400 defending against state-of-the-art attacks, not 603 00:33:04,400 --> 00:33:07,240 attacks where you've left, you left the back door open, you 604 00:33:07,240 --> 00:33:09,120 left the key under the mat, you did all these things you 605 00:33:09,120 --> 00:33:10,800 shouldn't do. And then I'm trying to like 606 00:33:10,800 --> 00:33:13,960 build additional barriers there. I don't know if that makes 607 00:33:13,960 --> 00:33:16,840 sense. So you know, I get you can 608 00:33:16,840 --> 00:33:18,400 nitpick some of this and be like, well, the device 609 00:33:18,400 --> 00:33:20,400 registration service shouldn't do this now it probably 610 00:33:20,400 --> 00:33:23,640 shouldn't, you're right. But how much engineering effort 611 00:33:23,640 --> 00:33:26,640 do you put into that when really we shouldn't have anyone 612 00:33:26,640 --> 00:33:29,640 enrolling devices that we have not done 2 factor authentication 613 00:33:29,640 --> 00:33:32,880 on kind of thing. So anyhow, let's continue with 614 00:33:32,920 --> 00:33:34,120 the attack chain here. Yeah. 615 00:33:34,120 --> 00:33:38,000 So one thing that they did after they had the the PRT token 616 00:33:38,080 --> 00:33:42,360 claimed the device claimed they ran a tool, a road Recon which 617 00:33:42,360 --> 00:33:44,760 was able to enumerate the entire tenant. 618 00:33:44,760 --> 00:33:47,160 So they were able to enumerate all the users, the groups, the 619 00:33:47,160 --> 00:33:50,920 devices and also all the full conditional access policies 620 00:33:51,200 --> 00:33:54,320 which they were able to see that there were 57 policies enabled, 621 00:33:54,320 --> 00:33:56,920 14 in report only mode and seven disabled. 622 00:33:56,920 --> 00:34:00,160 And two of those report only policies which we talked about 623 00:34:00,160 --> 00:34:04,040 would have stopped this attack in its tracks. 624 00:34:04,800 --> 00:34:07,680 And possibly maybe my 3rd 2. Right. 625 00:34:07,840 --> 00:34:11,480 And so they did, you know, this is where the, the reporting and 626 00:34:11,480 --> 00:34:14,920 kind of the nuance kind of meet where they talked about 627 00:34:14,920 --> 00:34:17,000 defeating into an MDM compliance. 628 00:34:17,000 --> 00:34:20,120 But we, we kind of went through that where if it was requiring 629 00:34:20,120 --> 00:34:22,400 compliant device, that's actually a little bit different 630 00:34:22,480 --> 00:34:26,440 because if you're just requiring hybrid join, which they did 631 00:34:26,440 --> 00:34:31,960 here, you basically bypass the any type of compliance policy 632 00:34:31,960 --> 00:34:34,760 check on the Intune side. That's different. 633 00:34:34,760 --> 00:34:36,800 If you were using like Mecum or something like that and you had 634 00:34:36,800 --> 00:34:38,760 a compliant check there and it's being managed there. 635 00:34:38,760 --> 00:34:43,360 But this is again, where there's a nuance of hybrid join is 636 00:34:43,360 --> 00:34:45,800 essentially an on premise join device. 637 00:34:45,800 --> 00:34:48,639 It is a domain join device. It is not a cloud device. 638 00:34:48,639 --> 00:34:52,360 And so that gets into also some of the, the, the later attack 639 00:34:52,360 --> 00:34:55,440 here, but you can't require an into. 640 00:34:55,440 --> 00:34:58,560 I mean, technically you can, but if your CA policy, your 641 00:34:58,560 --> 00:35:02,440 conditional access policy is just requiring hybrid join, then 642 00:35:02,440 --> 00:35:04,840 it doesn't actually check a compliance policy. 643 00:35:04,840 --> 00:35:07,880 So you know, there, some of the reporting says they ran a 644 00:35:07,880 --> 00:35:10,720 compliance check and it does all this querying and making sure 645 00:35:10,720 --> 00:35:13,720 the stuff is enabled. But if it's just hybrid join and 646 00:35:13,720 --> 00:35:16,120 that's all you're requiring, it doesn't look at a compliance 647 00:35:16,120 --> 00:35:19,360 policy. Or maybe they have it configured 648 00:35:19,360 --> 00:35:22,280 where it was in conditional access policies. 649 00:35:22,280 --> 00:35:25,920 Who can do and OR logic? You can pick do I want and 650 00:35:25,920 --> 00:35:27,600 logic? Do I want or logic? 651 00:35:28,080 --> 00:35:32,080 Possibly they had it configured for OR logic where it is either 652 00:35:32,080 --> 00:35:34,680 hybrid joined or compliant with Intune. 653 00:35:35,440 --> 00:35:37,280 And they're like, well, we're solving both bases. 654 00:35:37,280 --> 00:35:40,040 You know, if someone is, is hybrid joined and on premises, 655 00:35:40,120 --> 00:35:42,920 you know, then they get in and if they're cloudy, then they get 656 00:35:42,920 --> 00:35:47,160 in this way again, that's where I articulate that's not good 657 00:35:47,160 --> 00:35:51,440 design and you don't want to do, and if you're starting to move 658 00:35:51,480 --> 00:35:53,880 to some enter join devices because they're not hybrid join. 659 00:35:53,880 --> 00:35:55,360 So then they would fail that policy. 660 00:35:55,360 --> 00:35:57,800 And I get that. But that's where the, or is the 661 00:35:57,800 --> 00:36:00,400 risk of, well, I can just say I'm hybrid join and I can opt 662 00:36:00,400 --> 00:36:03,240 out of it. And, and I bet that's how it was 663 00:36:03,240 --> 00:36:07,800 configured because they do talk about how in Intune, when it ran 664 00:36:07,800 --> 00:36:10,800 its compliance check, the device just said, well, that doesn't 665 00:36:10,800 --> 00:36:14,280 apply to me. And then it was able to instead 666 00:36:14,280 --> 00:36:17,720 of being labeled non compliant, it was just not applicable. 667 00:36:17,720 --> 00:36:21,080 And if that is true, if there's a way to get to this point and 668 00:36:21,080 --> 00:36:24,280 trick in TuneIn that way, maybe that should, should have some 669 00:36:24,320 --> 00:36:26,000 potential redesign down the road. 670 00:36:26,000 --> 00:36:30,560 Again, it get you get down the path of maybe it's more 671 00:36:30,560 --> 00:36:33,000 important to put the security earlier in the chain, right. 672 00:36:33,000 --> 00:36:36,800 If you're already this far down, you're better off hardening 673 00:36:36,800 --> 00:36:41,280 earlier in the attack that often times Microsoft will take that 674 00:36:41,280 --> 00:36:43,360 stance. There's been some other examples 675 00:36:43,360 --> 00:36:46,440 recently where there have been reported disagreements on 676 00:36:47,760 --> 00:36:51,240 software development. I'll just say, and the Microsoft 677 00:36:51,240 --> 00:36:54,360 response has been, yeah, by that point, it doesn't matter. 678 00:36:54,360 --> 00:36:57,200 Like it if it's that compromise, yeah, we're not really worried 679 00:36:57,200 --> 00:37:01,240 about that scenario because it is so far down the compromise 680 00:37:01,240 --> 00:37:03,240 chain. The solution is prevent the 681 00:37:03,240 --> 00:37:06,240 compromise here, here or here before you get to that point. 682 00:37:06,240 --> 00:37:08,680 At that point, you know what? What's, what's the point here? 683 00:37:08,840 --> 00:37:10,600 So there could be some of that going on too. 684 00:37:10,600 --> 00:37:12,600 So, you know, I think you'll hear more reporting. 685 00:37:12,600 --> 00:37:15,880 As of Friday afternoon, there were not any talking points 686 00:37:15,880 --> 00:37:17,920 posted on this. I'm on our internal forum. 687 00:37:18,040 --> 00:37:21,840 The final thing that was kind of the the killing blow was as part 688 00:37:21,840 --> 00:37:25,720 of the enumeration, it exposed A structural misconfiguration 689 00:37:25,720 --> 00:37:28,640 which is very common in a lot of hybrid environments. 690 00:37:29,120 --> 00:37:33,000 There were 255 on premise Active Directory accounts that held 691 00:37:33,000 --> 00:37:36,600 privileged directory roles in the cloud, including two global 692 00:37:36,600 --> 00:37:38,880 admins and a privileged role administrator. 693 00:37:39,080 --> 00:37:42,320 This is something that Alex Weinhardt put out a blog back in 694 00:37:42,320 --> 00:37:44,160 2020. So this has been standing 695 00:37:44,160 --> 00:37:49,720 guidance for almost 6 years now. Do not sync any on premise 696 00:37:50,000 --> 00:37:53,760 accounts in privileged roles to the cloud. 697 00:37:53,760 --> 00:37:57,320 So your cloud accounts should admins should be separate cloud 698 00:37:57,360 --> 00:37:59,840 admins, your on premise privileged roles like global 699 00:38:00,400 --> 00:38:04,440 domain admin and you know whatever should also be just on 700 00:38:04,440 --> 00:38:06,280 premise accounts. And so one of those 701 00:38:06,280 --> 00:38:09,640 misconfigurations could also include because it's hybrid 702 00:38:09,640 --> 00:38:14,880 joined and it is a domain, you know joined device you're 703 00:38:14,880 --> 00:38:19,560 authenticating using domain accounts and so and those 704 00:38:19,800 --> 00:38:22,200 accounts get cached whenever you log in. 705 00:38:22,200 --> 00:38:26,320 So they might be sitting as cached credentials on the device 706 00:38:26,320 --> 00:38:29,000 itself. But either way this has been 707 00:38:29,000 --> 00:38:32,200 standing guidance don't sync privileged roles from on Prem to 708 00:38:32,200 --> 00:38:34,400 the cloud. And so they did that and so 709 00:38:34,520 --> 00:38:38,640 really they were able to compromise 1 synced on premise 710 00:38:38,640 --> 00:38:42,280 privileged account, then assign the privileged authentication 711 00:38:42,280 --> 00:38:45,640 admin role to the attacker controlled account, use that 712 00:38:45,640 --> 00:38:49,320 role to reset a synced global admin password, then sign in as 713 00:38:49,320 --> 00:38:52,800 the global admin and down they have complete tenant takeover. 714 00:38:53,720 --> 00:38:58,560 So, you know, a lot of different things went wrong here, but I 715 00:38:58,560 --> 00:39:02,760 think this is a pretty common scenario for a lot of 716 00:39:03,640 --> 00:39:06,280 organizations out there. So you made me think of when you 717 00:39:06,280 --> 00:39:08,400 were just talking about that and absolutely. 718 00:39:08,400 --> 00:39:11,400 So again, actionable guidance, we're all about it on this show. 719 00:39:11,400 --> 00:39:12,640 What is your actionable guidance? 720 00:39:12,640 --> 00:39:17,120 No privilege to sync accounts. All of your privileged accounts 721 00:39:17,120 --> 00:39:20,120 should be mastered and enter ID in our cloud only. 722 00:39:20,480 --> 00:39:22,760 But while you were talking about that, you made me think of 723 00:39:22,760 --> 00:39:26,120 something else to something else is actually I kept mentioning 724 00:39:26,360 --> 00:39:27,840 there are multiple ways to stop this. 725 00:39:28,320 --> 00:39:32,160 The one like assumption that all of this conversation had that we 726 00:39:32,160 --> 00:39:35,680 didn't even touch on Andy was that the user's password was 727 00:39:35,680 --> 00:39:38,000 compromised. We just assumed that it's a 728 00:39:38,000 --> 00:39:40,440 stipulated fact of this whole attack chain. 729 00:39:40,720 --> 00:39:42,400 Well, let's talk about that for a second. 730 00:39:42,760 --> 00:39:45,040 Couple of things. Number one, you can enable 731 00:39:45,040 --> 00:39:48,960 password hash synchronization and with enter ID protection, we 732 00:39:48,960 --> 00:39:51,600 will notify you if we find those credentials leaked on the dark 733 00:39:51,600 --> 00:39:55,440 web, send you a high, you know, high confidence alert. 734 00:39:55,480 --> 00:39:59,040 And you can configure so that the next time the user signs in, 735 00:39:59,040 --> 00:40:01,840 they're automatically forced to self remediate by doing a 736 00:40:01,840 --> 00:40:04,720 self-service password reset and providing 2 factors that are not 737 00:40:04,720 --> 00:40:08,240 their password to reset that password and eliminate the 738 00:40:08,240 --> 00:40:09,640 compromise. OK. 739 00:40:10,560 --> 00:40:12,800 It's not clear if that was done or not, but just so you're 740 00:40:12,800 --> 00:40:15,480 aware, there are ways to remediate and prevent that 741 00:40:15,640 --> 00:40:17,480 because a lot of this conversation is, ah, you know, 742 00:40:17,480 --> 00:40:19,560 passwords are a dime a dozen on the dark web. 743 00:40:19,560 --> 00:40:22,640 You can buy one for 50 bucks, maybe not even that much. 744 00:40:23,160 --> 00:40:26,440 Sure, there are ways to help mitigate that. 745 00:40:26,440 --> 00:40:30,320 The other thing is, you know, if your users just don't use their 746 00:40:30,320 --> 00:40:33,440 passwords very often, they're really hard to get fished. 747 00:40:34,200 --> 00:40:37,200 I, I know you're sick of hearing this, dear listeners on this 748 00:40:37,200 --> 00:40:40,120 show, but literally, if you try to fish Andy and I on our 749 00:40:40,120 --> 00:40:43,200 Microsoft corporate credentials, you can't because I don't know 750 00:40:43,200 --> 00:40:45,520 what it is. I haven't used my password in 751 00:40:45,520 --> 00:40:47,600 years. And now we've completed the 752 00:40:47,600 --> 00:40:52,160 migration to fish fish resistant MFA to where I never, I mean, 753 00:40:52,160 --> 00:40:54,600 I'm done putting my password because you cannot sign into 754 00:40:54,600 --> 00:40:56,720 stuff without fish resistant MFA. 755 00:40:56,720 --> 00:40:59,640 It's a requirement. So there's your other 756 00:40:59,640 --> 00:41:02,120 preventative stuff. If your users don't know what 757 00:41:02,120 --> 00:41:04,240 your password is, it can't get fished. 758 00:41:04,240 --> 00:41:07,560 And none of this attack happens because that was like the whole 759 00:41:07,560 --> 00:41:10,320 assumed first step. And I forgot about that part. 760 00:41:10,800 --> 00:41:14,760 Like if you are password list also, all of this risk goes 761 00:41:14,760 --> 00:41:16,720 away. Like there's your like third or 762 00:41:16,720 --> 00:41:19,680 fourth possibility to block this as well. 763 00:41:19,680 --> 00:41:22,200 And I forgot about that and you brought it up at the very end. 764 00:41:22,200 --> 00:41:25,040 So I'm sorry I'm hitting that late, but it's also an important 765 00:41:25,040 --> 00:41:26,960 point. This whole attack chain just 766 00:41:26,960 --> 00:41:29,000 starts off with, well, we have the user's password. 767 00:41:29,360 --> 00:41:33,360 Yeah, you know, OK, it's even, we've taken it even a step 768 00:41:33,360 --> 00:41:37,640 further in the fact that like I used to have my Microsoft 769 00:41:37,640 --> 00:41:40,320 password stored in a password vault, my corporate password, 770 00:41:40,320 --> 00:41:43,040 right. Like I, I said it day one and I 771 00:41:43,040 --> 00:41:46,640 haven't looked at it since they released something to us that 772 00:41:46,640 --> 00:41:49,680 said, hey, we're taking a step further. 773 00:41:49,680 --> 00:41:52,480 We're just going to change your password to some random, you 774 00:41:52,480 --> 00:41:56,960 know, 9000 character password in AD now and and you won't even 775 00:41:56,960 --> 00:41:58,760 know it. But they did that. 776 00:41:58,760 --> 00:42:01,240 I never saw that. Yeah, yeah, that there was a 777 00:42:01,240 --> 00:42:03,800 message that came out and they just said, hey, oh, and by the 778 00:42:03,800 --> 00:42:05,920 way, like you don't need this anymore. 779 00:42:05,920 --> 00:42:08,320 We're just going to change it to something crazy that you don't 780 00:42:08,320 --> 00:42:11,280 even know. So I won't ever know my on 781 00:42:11,280 --> 00:42:14,200 premise password ever again at Microsoft. 782 00:42:14,680 --> 00:42:17,640 OK, well, there you go. I mean, but it's just funny that 783 00:42:17,640 --> 00:42:20,040 that was so assumed of like, well, of course we have their 784 00:42:20,040 --> 00:42:22,400 password. Like, you know, Oh well, what 785 00:42:22,400 --> 00:42:25,080 can we do about that? Boy, I don't know, what can we 786 00:42:25,080 --> 00:42:29,520 do about that? All of this stops if you don't 787 00:42:29,520 --> 00:42:32,120 have a password to get fished too, by the way. 788 00:42:32,120 --> 00:42:35,080 So again, Speaking of like, where are we investing our 789 00:42:35,080 --> 00:42:38,160 engineering resources? Well, where are you investing 790 00:42:38,160 --> 00:42:41,240 your engineering resources listeners, you know, and and IT 791 00:42:41,240 --> 00:42:45,200 shops around the world because I've kind of taken this attitude 792 00:42:45,200 --> 00:42:49,480 of and, and I, I'm not saying this to be snarky, but when 793 00:42:49,600 --> 00:42:51,280 customers knock on my door, like, Hey, what should I do 794 00:42:51,280 --> 00:42:53,520 about this thing? Like, have you rolled out fish 795 00:42:53,520 --> 00:42:56,360 resistant MFA? No, OK, why don't you put your 796 00:42:56,360 --> 00:42:58,680 effort there? Like it's, it's my like almost 797 00:42:58,680 --> 00:43:01,880 knee jerk answer to everything. Roll out fish resistant MFA. 798 00:43:01,880 --> 00:43:06,000 That's the answer. Like it solves so many things. 799 00:43:06,000 --> 00:43:09,040 Just I I know it's hard, that it's worth doing. 800 00:43:09,080 --> 00:43:10,360 There's no bigger bang for your buck. 801 00:43:10,520 --> 00:43:11,960 Anyhow. I get on the soapbox all the 802 00:43:11,960 --> 00:43:12,600 time. I'll stop. 803 00:43:12,720 --> 00:43:15,160 Yeah. So just to wrap things up, we 804 00:43:15,160 --> 00:43:18,000 kind of went through this as we talked about the attack chain, 805 00:43:18,000 --> 00:43:21,720 but some actionable insights #1 enforce conditional access 806 00:43:21,720 --> 00:43:27,040 policy to block device code flow #2 require MFA for ENTRA device 807 00:43:27,040 --> 00:43:30,880 registration. Number three, don't sync your on 808 00:43:30,880 --> 00:43:36,240 premise users into privileged cloud roles #4 obviously do an 809 00:43:36,240 --> 00:43:38,960 audit of all of your conditional access policies. 810 00:43:38,960 --> 00:43:41,160 Anything that's in report only mode. 811 00:43:41,160 --> 00:43:43,000 That's all it is. It's just going to log the 812 00:43:43,000 --> 00:43:44,640 attempt. So make sure that if it's 813 00:43:44,640 --> 00:43:47,600 something that you want to enforce, start enforcing it. 814 00:43:48,000 --> 00:43:51,400 Do a test group, roll it out, and then turn it on for all of 815 00:43:51,400 --> 00:43:52,960 your users. If that's something that's in a 816 00:43:52,960 --> 00:43:55,960 critical category, like one of these two things that should 817 00:43:55,960 --> 00:44:01,200 have been done here and then #5 start requiring compliant 818 00:44:01,200 --> 00:44:04,640 devices. So use instead of the hybrid 819 00:44:05,160 --> 00:44:09,320 joined in conditional access policy, force device compliance. 820 00:44:09,480 --> 00:44:14,120 Now that will, if you're kind of still in the hybrid join phase, 821 00:44:14,120 --> 00:44:17,920 that may take some time, but that's something worth what like 822 00:44:17,920 --> 00:44:20,440 I'm saying, it's worth your engineering effort. 823 00:44:20,440 --> 00:44:24,480 It's worth your time to move to that because it is continuous 824 00:44:24,680 --> 00:44:29,760 device attestation rather than hey, you have a hybrid joined 825 00:44:29,760 --> 00:44:33,040 device and that's it. Well, and it's reusable. 826 00:44:33,160 --> 00:44:36,960 It's reusable when you move to requiring device compliance as a 827 00:44:36,960 --> 00:44:40,720 hybrid join device, guess what, that's your only option when you 828 00:44:40,720 --> 00:44:43,240 move to cloud join anyway. So you would have had to do the 829 00:44:43,280 --> 00:44:46,400 engineering effort then. So it's not like it's dead end 830 00:44:46,400 --> 00:44:48,760 engineering effort. It is future state engineering 831 00:44:48,760 --> 00:44:52,200 effort that you get to do early and then you pull that effort 832 00:44:52,560 --> 00:44:55,480 out of the project to move to cloud join, which if you're, you 833 00:44:55,720 --> 00:44:59,400 know, you need to be doing this well, but that way a lot of orgs 834 00:44:59,400 --> 00:45:01,640 get really wound up. And it's, it's one of the first 835 00:45:01,640 --> 00:45:03,800 shows we ever did and we did several on it. 836 00:45:03,800 --> 00:45:08,400 Andy, early in our, you know, our 2020 years on the show, we 837 00:45:08,400 --> 00:45:12,360 talked about enter join devices and people get wound up and make 838 00:45:12,360 --> 00:45:15,760 it more complicated than it is pulling that effort forward on 839 00:45:15,760 --> 00:45:19,480 getting to device compliance chucking as part of your CA 840 00:45:19,480 --> 00:45:22,040 policies. Doing that early is a great move 841 00:45:22,400 --> 00:45:24,960 because that is not complexity with the cloud. 842 00:45:24,960 --> 00:45:28,400 Join, move to enter, join then, and then when you do that, it's 843 00:45:28,400 --> 00:45:31,600 an easier lift. So I actually recommend doing 844 00:45:31,600 --> 00:45:33,400 that. It's the right order of 845 00:45:33,400 --> 00:45:36,520 operations. All right, a lot of information 846 00:45:36,520 --> 00:45:39,720 here today. Hopefully you stuck around cuz 847 00:45:39,720 --> 00:45:42,240 man, this was a great show overall. 848 00:45:42,240 --> 00:45:44,960 So thanks for listening and watching. 849 00:45:44,960 --> 00:45:48,320 As always, our contact information along with the links 850 00:45:48,320 --> 00:45:52,440 that we used for our notes and our show will be in the show 851 00:45:52,440 --> 00:45:54,400 notes. If you have any questions or 852 00:45:54,400 --> 00:45:57,720 topics you want us to talk about in the future, just e-mail us. 853 00:45:58,280 --> 00:45:59,400 Thanks. We'll talk to you guys next 854 00:45:59,400 --> 00:46:04,000 week. Thank you for listening to the 855 00:46:04,000 --> 00:46:06,840 Blue Security Podcast. Please check out the show notes, 856 00:46:06,840 --> 00:46:09,680 catch up on episodes you may have missed, and subscribe so 857 00:46:09,680 --> 00:46:11,400 you don't miss any future episodes. 858 00:46:11,400 --> 00:46:16,080 Find Andy on Twitter at a Jaw Zero and Adam at AJ Brewer. 859 00:46:16,320 --> 00:46:17,920 See you at our next episode.