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