1 00:00:00,040 --> 00:00:02,720 Welcome to this week's episode of the Blue Security Podcast. 2 00:00:02,840 --> 00:00:05,800 I'm Andy, your host. I'm Adam, your Co host. 3 00:00:06,440 --> 00:00:08,320 We have two stories for this week. 4 00:00:08,320 --> 00:00:12,000 The first one we're going to talk about Tycoon 2FA and 5 00:00:12,000 --> 00:00:17,080 they're they're back now along with a an attack vector that we 6 00:00:17,080 --> 00:00:20,440 talked about last week, which is device code flow. 7 00:00:20,760 --> 00:00:23,920 Device code flow and they're using it for phishing. 8 00:00:24,360 --> 00:00:27,840 So we'll get into that as our first topic and then we'll 9 00:00:27,840 --> 00:00:32,119 follow up with an exchange 0 day that kind of dropped just a few 10 00:00:32,600 --> 00:00:36,680 days 48 hours after patch Tuesday was released. 11 00:00:37,040 --> 00:00:39,560 And so we'll talk about that and how you can protect your 12 00:00:39,560 --> 00:00:42,320 organization's from the zero day. 13 00:00:42,760 --> 00:00:45,400 And I learned about a new feature. 14 00:00:45,400 --> 00:00:48,040 Well, it's actually not even new, but so if you stick around 15 00:00:48,040 --> 00:00:51,400 to the Exchange, the Exchange story, there's actually a 16 00:00:51,400 --> 00:00:54,400 feature that I learned about as I was researching this that I 17 00:00:54,400 --> 00:00:58,440 didn't know existed, something that is called the Exchange 18 00:00:58,440 --> 00:01:01,560 Emergency Mitigation Service. So we'll talk about that. 19 00:01:01,560 --> 00:01:04,640 But before we get started, let's go with our disclaimer since 20 00:01:04,640 --> 00:01:06,880 we're going to be talking about Microsoft this week. 21 00:01:07,720 --> 00:01:11,440 Andy and I both work for Microsoft in our in our field 22 00:01:11,440 --> 00:01:14,160 security sales. We do the show outside of work. 23 00:01:14,280 --> 00:01:18,960 We're recording this on Sunday, May 17th at about 7:20 PM, so 24 00:01:18,960 --> 00:01:20,560 definitely not during work hours. 25 00:01:20,840 --> 00:01:23,800 And we self fund the show. It's literally a labor of love. 26 00:01:23,800 --> 00:01:27,240 We pay for the hosting, the recording platform, the domain 27 00:01:27,240 --> 00:01:28,800 and everything in between ourselves. 28 00:01:28,960 --> 00:01:32,080 So the opinions you're about to hear expressed are those of Adam 29 00:01:32,080 --> 00:01:35,440 Brewer and Andy Jaw and do not necessarily reflect those of 30 00:01:35,440 --> 00:01:38,080 Microsoft Corporation. And with that, Andy on with the 31 00:01:38,080 --> 00:01:40,600 show. All right, so if you did catch 32 00:01:40,600 --> 00:01:44,400 last week's episode, we broke down device code flow phishing 33 00:01:44,400 --> 00:01:48,000 for the first well, not really for the first time, but we went 34 00:01:48,000 --> 00:01:52,080 into a detail probably it's been a few years since we really 35 00:01:52,080 --> 00:01:55,760 talked about it. But what it is in a nutshell is 36 00:01:55,760 --> 00:02:00,040 when authentication happens on a device that doesn't have an 37 00:02:00,040 --> 00:02:03,200 input method like a keyboard or something like that. 38 00:02:03,200 --> 00:02:06,000 And so you have to flow that authentication from another 39 00:02:06,000 --> 00:02:08,680 device. Think like when you sign into 40 00:02:08,680 --> 00:02:13,400 Netflix or any type of streaming app, YouTube from your phone 41 00:02:13,400 --> 00:02:16,840 that then authenticates to like an Apple TV or a Roku or 42 00:02:16,840 --> 00:02:18,720 something like that, you scan AQR code. 43 00:02:18,720 --> 00:02:23,240 And so that's that Oauth authentication standard is 44 00:02:23,320 --> 00:02:27,000 called device code flow. And so now that particular 45 00:02:27,000 --> 00:02:31,200 attack vector is being used in a campaign with Tycoon 2. 46 00:02:31,720 --> 00:02:34,400 So if you haven't heard of who these guys are, they're one of 47 00:02:34,400 --> 00:02:39,480 the most widespread phishing as a service platforms to emerge 48 00:02:39,480 --> 00:02:43,280 and they were developed by the threat actor Microsoft tracks as 49 00:02:43,280 --> 00:02:49,680 Storm 1747. By mid 20/20 it had accounted 50 00:02:49,680 --> 00:02:54,400 for roughly 62% of all phishing attempts that Microsoft blocked 51 00:02:54,760 --> 00:02:59,720 with campaigns that reached over 500,000 organizations per month 52 00:03:00,240 --> 00:03:03,760 worldwide. So it's a criminal SAS operation 53 00:03:04,160 --> 00:03:09,480 with kits that start as little as $120.00 for 10 days of 54 00:03:09,480 --> 00:03:11,880 access. And that lowers the technical 55 00:03:11,880 --> 00:03:16,960 barrier enough that criminals with very limited technical 56 00:03:16,960 --> 00:03:20,400 expertise can run a sophisticated impersonation 57 00:03:20,440 --> 00:03:24,200 campaign. Microsoft and Europol actually 58 00:03:24,200 --> 00:03:29,520 LED a major takedown in March of 2026 where they seized 330 59 00:03:29,520 --> 00:03:33,120 active domains. But unfortunately, despite all 60 00:03:33,120 --> 00:03:37,520 of the work that Microsoft and Europol did, tycoon 2FA was able 61 00:03:37,520 --> 00:03:40,560 to rebuild brand new infrastructure and then quickly 62 00:03:40,560 --> 00:03:43,000 return to normal activity levels. 63 00:03:43,680 --> 00:03:47,560 Now here's where kind of ties into what we talked about last 64 00:03:47,560 --> 00:03:51,280 week. In late April of 2026 this year, 65 00:03:51,640 --> 00:03:55,640 ecentra threat response unit analyzed a new campaign 66 00:03:56,120 --> 00:04:01,720 combining Tycoon 2 FAS known infrastructure with OA device 67 00:04:01,720 --> 00:04:07,160 authorization grant flow abuse to compromise Microsoft 365 68 00:04:07,200 --> 00:04:10,240 accounts. The account The attack begins 69 00:04:10,240 --> 00:04:14,320 with a phishing e-mail and so it's usually it's disguised as 70 00:04:14,320 --> 00:04:17,800 something like a a vendor invoice reminder and then it 71 00:04:17,800 --> 00:04:22,200 contains a trust Trustify click tracking link. 72 00:04:22,200 --> 00:04:26,040 Now I looked into Trustify and it's a it's a reputable service 73 00:04:26,040 --> 00:04:29,520 that is used all the time and from the threat response unit. 74 00:04:29,520 --> 00:04:33,280 They were unsure why Trustify or how they even started getting 75 00:04:33,280 --> 00:04:36,280 used here. But once the victim clicks on 76 00:04:36,280 --> 00:04:39,720 the link, they're redirected through a Cloudflare domain and 77 00:04:39,720 --> 00:04:41,760 then landing on a malicious payload. 78 00:04:41,760 --> 00:04:46,600 But instead of a fake login page, the campaign uses real 79 00:04:46,600 --> 00:04:50,960 Microsoft login.process@microsoft.com/devicelogin. 80 00:04:51,560 --> 00:04:55,040 So they're using that device code flow in their phishing. 81 00:04:55,040 --> 00:04:58,360 So victims are shown on Microsoft 365 voicemail 82 00:04:58,360 --> 00:05:01,480 notification and then they're instructed to copy a user code 83 00:05:01,480 --> 00:05:04,760 and and put that into the real Microsoft page. 84 00:05:04,760 --> 00:05:08,840 And since they're on genuine Microsoft infrastructure, MFA is 85 00:05:08,840 --> 00:05:11,400 then triggered if you have it enabled. 86 00:05:11,520 --> 00:05:14,160 She should and it's looks completely normal. 87 00:05:14,160 --> 00:05:15,880 And the victim thinks everything is fine. 88 00:05:15,880 --> 00:05:19,360 But what they don't realize is like by approving that prompt, 89 00:05:19,360 --> 00:05:22,960 they're actually granting Oauth access tokens to the attacker 90 00:05:22,960 --> 00:05:25,000 controlled device running in the background. 91 00:05:25,920 --> 00:05:29,600 And so the phishing doesn't really bypass MFA because it 92 00:05:30,000 --> 00:05:32,720 you're just authorizing MFA, but you don't really know what 93 00:05:32,720 --> 00:05:34,480 you're actually authorizing on the back end. 94 00:05:35,000 --> 00:05:37,360 And because Microsoft's authentication broker is a 95 00:05:37,360 --> 00:05:40,960 broker application, that single consent can be exchanged for 96 00:05:40,960 --> 00:05:45,280 tokens that are scoped to exchange a Microsoft Graph 97 00:05:45,400 --> 00:05:48,080 OneDrive without any other user interaction. 98 00:05:48,080 --> 00:05:52,440 So that one time approval does authenticate you to the 99 00:05:52,440 --> 00:05:57,400 Microsoft 365 estate. This is pretty tough to catch 100 00:05:57,400 --> 00:06:03,560 because the Tycoon 2FA kit does contain extensive protections 101 00:06:03,560 --> 00:06:07,240 against research and automated scanning, so it can detect 102 00:06:07,520 --> 00:06:11,160 Selenium, Puppeteer, Playwright, Burp Suite, and then they can 103 00:06:11,160 --> 00:06:15,600 also block security vendors, VPNs, sandbox and AI crawlers. 104 00:06:15,600 --> 00:06:19,680 It's block list contains currently 230 vendor names and 105 00:06:19,680 --> 00:06:23,960 it's constantly updated. So if it thinks that it's 106 00:06:23,960 --> 00:06:27,840 getting analyzed or scanned by a legitimate tool, it actually 107 00:06:27,840 --> 00:06:30,760 just redirects it to a legitimate Microsoft page and 108 00:06:30,760 --> 00:06:33,480 just kind of cuts ties and walks away. 109 00:06:33,920 --> 00:06:37,320 So, you know, this is, I saw this and immediately I was like, 110 00:06:37,320 --> 00:06:40,480 this is another instance. We'd literally just talked about 111 00:06:40,480 --> 00:06:43,640 this last week and you know, this is not a coincidence. 112 00:06:43,640 --> 00:06:46,120 This is a, a trending attack vector. 113 00:06:46,480 --> 00:06:50,640 And you know, the warning flag should be up for you. 114 00:06:50,640 --> 00:06:54,360 And if you don't have mitigations in place, you should 115 00:06:54,360 --> 00:06:57,160 start looking at them and and implementing them as soon as 116 00:06:57,160 --> 00:07:00,360 possible. So as part of our normal 117 00:07:00,440 --> 00:07:02,720 podcast, we'd like to give you actions. 118 00:07:03,200 --> 00:07:05,840 Three things. Number one, we talked about this 119 00:07:05,840 --> 00:07:10,120 last week go and scope conditional access policies to 120 00:07:10,120 --> 00:07:13,960 block device code flow. Obviously, there you might have 121 00:07:13,960 --> 00:07:18,240 some specific use cases. Scope them down into very 122 00:07:18,240 --> 00:07:22,560 narrow, allows for specific people, specific users, specific 123 00:07:22,560 --> 00:07:25,400 devices. Also, while you're there you can 124 00:07:25,400 --> 00:07:29,760 also do a consent policy review. So by default in many tenants, 125 00:07:30,040 --> 00:07:34,240 users can approve low risk Oauth permissions on their own. 126 00:07:34,720 --> 00:07:37,720 Which means that like a convincing phishing prompt like 127 00:07:37,720 --> 00:07:42,640 this can get a user to hand over access without an admin even 128 00:07:42,640 --> 00:07:45,440 knowing about it. So you have a few options here. 129 00:07:45,960 --> 00:07:49,360 When you go in and check for Oauth app consent, you could 130 00:07:49,360 --> 00:07:53,000 require an admin approval for all third party app consents. 131 00:07:53,880 --> 00:07:57,960 You could also restrict self-service consent to only 132 00:07:58,040 --> 00:08:00,920 verified publishers. And you can also enable the 133 00:08:00,960 --> 00:08:03,960 admin consent workflow so that requests don't just fall 134 00:08:03,960 --> 00:08:07,640 silently, they are routed to an admin queue for review. 135 00:08:08,000 --> 00:08:11,760 To be clear, this is different than blocking device code flow. 136 00:08:12,200 --> 00:08:15,400 It doesn't necessarily stop this attack, but it does protect 137 00:08:15,400 --> 00:08:18,680 across a broader category that we're kind of talking about 138 00:08:18,680 --> 00:08:22,360 here, the Oauth phishing, which includes consent phishing 139 00:08:22,360 --> 00:08:24,600 campaigns that don't use device code flow. 140 00:08:24,880 --> 00:08:27,960 But if you're already there in the Enter admin portal, you 141 00:08:27,960 --> 00:08:30,720 might as well double check and make sure that you have this 142 00:08:30,720 --> 00:08:33,039 one. And then finally, user 143 00:08:33,039 --> 00:08:36,200 awareness, right? So everything is on about 144 00:08:36,200 --> 00:08:38,039 training as well. So make sure that you train your 145 00:08:38,039 --> 00:08:40,520 users that they don't personally initiate a log. 146 00:08:40,520 --> 00:08:44,159 If they didn't personally initiate a login like they were 147 00:08:44,159 --> 00:08:46,280 they were actually going to something, then they should 148 00:08:46,280 --> 00:08:49,720 never really approve anything. If if they just get a pop up. 149 00:08:49,800 --> 00:08:53,400 The tell is when device code phishing is always the same. 150 00:08:53,400 --> 00:08:57,320 Someone else started the authentication flow, not you. 151 00:08:57,320 --> 00:09:00,240 So if you didn't, like, go to the app and log in, or you 152 00:09:00,440 --> 00:09:03,560 yourself wanted to log into like Netflix or whatever, like you 153 00:09:03,560 --> 00:09:07,560 didn't start that, then it's probably some sort of malicious 154 00:09:07,840 --> 00:09:08,760 content. Yeah. 155 00:09:08,760 --> 00:09:10,640 So make sure those are our takeaways. 156 00:09:10,680 --> 00:09:14,320 Adam, any thoughts on this particular attack and story? 157 00:09:14,680 --> 00:09:18,640 It is amazing that device code flow is back again and the 158 00:09:18,640 --> 00:09:20,960 advice remains the same. You nailed it perfectly Andy. 159 00:09:20,960 --> 00:09:22,960 This is 1 I would strongly recommend. 160 00:09:23,640 --> 00:09:25,440 You do not need to chase your tail on this. 161 00:09:25,960 --> 00:09:29,440 You have permission from Adam and Andy to run a screen test on 162 00:09:29,440 --> 00:09:32,200 this, Disable it and wait for screaming. 163 00:09:32,640 --> 00:09:36,360 You won't hear any because there are almost no legitimate use 164 00:09:36,360 --> 00:09:38,320 cases for this. Don't e-mail me. 165 00:09:38,320 --> 00:09:41,960 There may be some, I get it, but for the most part this is such a 166 00:09:41,960 --> 00:09:44,800 large risk and the security benefit is so great from 167 00:09:44,800 --> 00:09:48,000 disabling it. I strongly recommend you utilize 168 00:09:48,000 --> 00:09:50,720 screen testing to validate the scenarios in which you need to 169 00:09:50,720 --> 00:09:53,320 unblock this. Just wait for screaming, but 170 00:09:53,320 --> 00:09:54,560 just block it. Work wide. 171 00:09:54,560 --> 00:09:57,880 Do not try to run around and figure out who's using this in 172 00:09:57,880 --> 00:09:59,720 legitimate scenarios 'cause there are almost none. 173 00:09:59,920 --> 00:10:01,160 This just needs to be turned off. 174 00:10:01,880 --> 00:10:06,360 The second one with the O auth consent also. 175 00:10:06,920 --> 00:10:09,560 So first one, by the way, we talked last week, if you didn't 176 00:10:09,560 --> 00:10:13,120 listen last week, real simple, Microsoft does recommend you 177 00:10:13,120 --> 00:10:15,680 disable device code flows in enterprise scenarios. 178 00:10:15,680 --> 00:10:17,960 That's a consumer facing scenario thing. 179 00:10:18,200 --> 00:10:19,920 It's useful to sign into my Xbox. 180 00:10:20,320 --> 00:10:22,720 It's not really useful to sign into my enter ID account. 181 00:10:22,880 --> 00:10:29,800 So second one, the Oauth consent flow, also a coming and growing 182 00:10:29,800 --> 00:10:33,160 attack vector and also one that Microsoft recommends today 183 00:10:33,560 --> 00:10:35,960 should be restricted compared to the default setting. 184 00:10:35,960 --> 00:10:38,800 And again, you've heard us probably talk about the Secure 185 00:10:38,800 --> 00:10:40,680 Future initiative many times on this show. 186 00:10:40,680 --> 00:10:42,720 It's his multi year engineering Sprint. 187 00:10:43,320 --> 00:10:46,680 And one of the goals of that, there are three goals, secure by 188 00:10:46,680 --> 00:10:49,160 default, secure by design and secure operations. 189 00:10:50,080 --> 00:10:54,000 You can complain the default isn't secure today and defaults 190 00:10:54,000 --> 00:10:56,400 take a long time to change. I will acknowledge that it 191 00:10:56,400 --> 00:11:00,840 doesn't mean it's not coming. I would imagine maybe already 192 00:11:01,040 --> 00:11:03,840 modern inter ID tenants do not ship with this enabled for all 193 00:11:03,840 --> 00:11:06,760 users by default. But if you stood up your M365 194 00:11:06,760 --> 00:11:09,240 environment a long time ago it may still be set that way. 195 00:11:09,720 --> 00:11:13,400 So go restrict this, lock it down, limited to admins and that 196 00:11:13,400 --> 00:11:16,920 admin approval flow is probably the right choice at this point. 197 00:11:16,920 --> 00:11:19,200 User awareness. So here's the thing Andy, you 198 00:11:19,200 --> 00:11:21,160 were going through and you were like, I've got three things for 199 00:11:21,160 --> 00:11:23,200 you. And immediately my mind at this 200 00:11:23,200 --> 00:11:26,640 point, I have a huge bias towards fish resistant MFAI. 201 00:11:26,640 --> 00:11:28,920 It's my answer to everything. You bring it up. 202 00:11:28,920 --> 00:11:33,120 I say fish resistant MFA, but you could say, but Adam, this 203 00:11:33,120 --> 00:11:35,240 could still happen with fish resistant MFA. 204 00:11:35,240 --> 00:11:39,640 And you are absolutely correct. A user could be tricked just as 205 00:11:39,640 --> 00:11:44,160 easily into inputting this device code flow, then inserting 206 00:11:44,160 --> 00:11:47,040 their UB key, touching it, going through that process and 207 00:11:47,040 --> 00:11:49,960 authenticating, and then the the attacker still hasn't gained the 208 00:11:49,960 --> 00:11:52,920 same level of access. That is 1000% true. 209 00:11:53,440 --> 00:11:57,400 However, what you're missing is the same benefit we've seen from 210 00:11:57,400 --> 00:11:59,600 moving users to password less technologies. 211 00:12:00,280 --> 00:12:03,760 Users who use password less technologies are more skeptical 212 00:12:04,160 --> 00:12:06,800 when they're asked to provide their password because they 213 00:12:06,800 --> 00:12:10,520 never have to in legitimate scenarios or very rarely, and it 214 00:12:10,520 --> 00:12:12,640 catches their attention enough where they don't respond 215 00:12:12,640 --> 00:12:16,040 positively as much. This is why many, many years 216 00:12:16,040 --> 00:12:19,160 ago, 10 years ago, Microsoft came out with guidance that said 217 00:12:19,480 --> 00:12:22,080 stop making your users sign in all the time. 218 00:12:22,120 --> 00:12:24,840 Let them sign in once and then keep their credentials cashed 219 00:12:24,840 --> 00:12:27,000 and valid. Because the more you make them 220 00:12:27,000 --> 00:12:29,200 sign in, the more you're training them to respond 221 00:12:29,200 --> 00:12:31,720 positively to a fishing attempt. They put in their password all 222 00:12:31,720 --> 00:12:33,080 the time without thinking about it. 223 00:12:33,400 --> 00:12:35,760 They're like the lab rat pushing the button to get the food 224 00:12:35,760 --> 00:12:38,400 pellet. You just train them like Pavlov 225 00:12:38,640 --> 00:12:42,200 and his dogs to automatically oh a prompt pops up, put in my 226 00:12:42,200 --> 00:12:44,720 password. Oh the bell rang, I salivate. 227 00:12:44,760 --> 00:12:49,280 Same idea when you move to fish resistant MFA compared to you. 228 00:12:49,280 --> 00:12:52,080 Let's say you're using. God forbid you're still sending 229 00:12:52,080 --> 00:12:56,200 your users a A6 digit one time passcode through SSI. 230 00:12:56,480 --> 00:13:00,000 Hope not, but maybe you are. Maybe you still have a hardware 231 00:13:00,000 --> 00:13:02,880 tokens that you know generate A1 time passcode. 232 00:13:02,880 --> 00:13:04,920 Maybe you have a software one time passcode. 233 00:13:05,360 --> 00:13:08,000 Either way, if your users are still intimately familiar with 234 00:13:08,000 --> 00:13:10,880 one time passcodes, they don't think anything of a device code 235 00:13:10,880 --> 00:13:14,080 flow that asked them to plug it in to complete some sort of 236 00:13:14,080 --> 00:13:17,240 process. Again, you've trained them to do 237 00:13:17,240 --> 00:13:18,440 this. You've trained them to do it 238 00:13:18,440 --> 00:13:21,120 without thinking about it. It's becomes that Pavlovian 239 00:13:21,120 --> 00:13:25,640 conditioning if you move to fish resistant MFA where I don't ever 240 00:13:25,640 --> 00:13:28,960 deal with one time passcodes anymore for my enterprise login 241 00:13:29,280 --> 00:13:32,320 if I get prompted with one. Well, this is weird. 242 00:13:32,440 --> 00:13:34,240 I don't do this to sign into work. 243 00:13:34,480 --> 00:13:37,400 Maybe my bank makes me do this, but work doesn't. 244 00:13:37,800 --> 00:13:42,400 I'm not going to do this. So even though technically fish 245 00:13:42,400 --> 00:13:45,600 resistant MFA would not prevent this attack, would not block it. 246 00:13:45,640 --> 00:13:48,600 That is true. By implementing it, you are 247 00:13:48,600 --> 00:13:51,880 helping reduce your users in responding positively to these 248 00:13:51,880 --> 00:13:54,520 kinds of attacks. Andy talked about the user 249 00:13:54,520 --> 00:13:56,680 education and that's certainly a portion of it. 250 00:13:57,000 --> 00:14:00,160 But the other portion of it is just not training your users to 251 00:14:00,160 --> 00:14:02,320 do this anymore. Because when we used to make 252 00:14:02,320 --> 00:14:04,920 user sending with passwords all the time, we train them to 253 00:14:04,920 --> 00:14:07,720 respond to phishing attacks. When we make users put in one 254 00:14:07,720 --> 00:14:10,880 time passcodes all the time, we train them to respond to device 255 00:14:10,880 --> 00:14:13,080 code flow attacks, same exact idea. 256 00:14:13,480 --> 00:14:16,520 So get rid of that and now you don't have the training and the 257 00:14:16,520 --> 00:14:18,760 pre training for them to respond to these kind of phishing 258 00:14:18,760 --> 00:14:21,840 attempts. And I'll add like a a sub bullet 259 00:14:21,880 --> 00:14:26,760 as well before we move on is while you're on the subject of 260 00:14:26,760 --> 00:14:29,800 kind of looking at Oauth consent. 261 00:14:31,960 --> 00:14:35,000 If for some reason you hadn't switched that and you were 262 00:14:35,000 --> 00:14:40,720 allowing your users to consent to Oauth, then you probably have 263 00:14:40,760 --> 00:14:45,920 a bunch of applications in your tenant that users have consented 264 00:14:45,920 --> 00:14:47,560 to over the years or however long. 265 00:14:47,680 --> 00:14:50,040 You know, highly permissioned applications, no less. 266 00:14:50,040 --> 00:14:53,360 Yes, absolutely. So, so one thing you can look at 267 00:14:53,360 --> 00:14:57,400 is when you go to Entra, the admin portal, there's a tab on 268 00:14:57,400 --> 00:14:59,960 the left hand side that says enterprise applications. 269 00:15:00,040 --> 00:15:04,000 And all of those enterprise applications are either one O 270 00:15:04,000 --> 00:15:07,080 auth consent or two Federated with Entra. 271 00:15:07,080 --> 00:15:09,880 And so you can go through and you can look at them and it's 272 00:15:09,880 --> 00:15:13,520 pretty easy to see which ones are not all of them. 273 00:15:13,520 --> 00:15:17,320 But you can probably deduce like based on your knowledge of what 274 00:15:17,320 --> 00:15:20,640 applications your enterprise uses, which ones are probably 275 00:15:20,640 --> 00:15:24,800 not part of your enterprise. Like if you're a OneDrive shop 276 00:15:24,800 --> 00:15:28,600 and you see Dropbox there or you're, you know, your box shop 277 00:15:28,600 --> 00:15:30,040 and you see something else, right? 278 00:15:30,040 --> 00:15:33,680 Google Drive or like, for example, I worked at Trek bikes 279 00:15:33,840 --> 00:15:37,200 a long time ago and of course Garmin was a big, you know, 280 00:15:37,200 --> 00:15:41,000 people were using GPS on their bikes to track their, their 281 00:15:41,000 --> 00:15:45,960 rides and some people a lot consented to Garmin using their 282 00:15:45,960 --> 00:15:48,280 corporate e-mail and that showed up. 283 00:15:48,280 --> 00:15:50,760 So you'll be able to see that you'll be able to see the 284 00:15:50,760 --> 00:15:53,480 permissions that it's granted. And if you want to review, 285 00:15:53,480 --> 00:15:58,640 there's also a defender for cloud apps that can look at all 286 00:15:58,640 --> 00:16:01,840 of your highly permissioned Oauth application. 287 00:16:01,840 --> 00:16:04,240 So you can go and review that, or you can do it manually. 288 00:16:04,240 --> 00:16:07,200 If if you just go into the enterprise apps and you can see 289 00:16:07,200 --> 00:16:10,400 which users specifically are assigned, quote UN quote 290 00:16:10,400 --> 00:16:12,680 assigned because they're the ones who authorized it. 291 00:16:13,440 --> 00:16:15,480 And you'll see apps with just like one or two users. 292 00:16:15,480 --> 00:16:18,160 You know, if you have an organization of thousands of 293 00:16:18,160 --> 00:16:20,720 people and only one or two people are using it, it's 294 00:16:20,720 --> 00:16:23,680 probably not an app that's used org wide. 295 00:16:23,680 --> 00:16:26,760 So I had to do this exercise way back in the day. 296 00:16:26,760 --> 00:16:29,720 Before we had a nice tool in Defender for cloud apps that 297 00:16:29,720 --> 00:16:34,000 would give us all of the highly permissioned applications. 298 00:16:34,400 --> 00:16:37,520 But now you can go and check there if you have licenses for 299 00:16:37,520 --> 00:16:40,120 that and then also just kind of go through manually if you need 300 00:16:40,120 --> 00:16:41,960 to. Great call out on the Defender 301 00:16:41,960 --> 00:16:44,480 for cloud apps. One thing I like about it is it 302 00:16:44,480 --> 00:16:47,200 provides a lot of additional context on the prevalence of the 303 00:16:47,200 --> 00:16:48,960 application. So it may be highly 304 00:16:48,960 --> 00:16:52,640 permissioned, but it is a well known common application that 305 00:16:52,640 --> 00:16:55,480 many orgs use. Probably contrasted a lot more 306 00:16:55,480 --> 00:16:57,920 than this highly permissioned Oauth app that has never been 307 00:16:57,920 --> 00:17:00,240 seen before. That may be 1 worth 308 00:17:00,240 --> 00:17:02,040 investigating and potentially revoking. 309 00:17:02,360 --> 00:17:05,760 All right, so moving on to our final story for tonight. 310 00:17:06,000 --> 00:17:14,560 There is an exchange 0 day CVE 202642897 actively bling being 311 00:17:14,560 --> 00:17:16,760 exploited. So this one's a little time 312 00:17:16,760 --> 00:17:19,560 sensitive. If your organization is running 313 00:17:19,560 --> 00:17:23,319 on premise Exchange today, you need to act on this. 314 00:17:23,359 --> 00:17:26,079 There is a tool specifically built for moments like this 315 00:17:26,079 --> 00:17:30,120 which we'll talk about. So First off, the the high level 316 00:17:30,120 --> 00:17:33,480 overview is that Microsoft disclosed a high severity 317 00:17:33,480 --> 00:17:37,080 Exchange Server vulnerability that is being actively exploited 318 00:17:37,080 --> 00:17:39,640 in the wild. The attack vector is cross site 319 00:17:39,640 --> 00:17:43,720 scripting through OWA or Outlook on the web. 320 00:17:43,720 --> 00:17:47,240 An attacker can send a specifically crafted e-mail and 321 00:17:47,240 --> 00:17:51,280 if the recipient opens it in OWA under certain conditions, 322 00:17:51,800 --> 00:17:55,560 arbitrary JavaScript and executes in the browser context. 323 00:17:56,080 --> 00:17:59,960 The attack path does not require authentication or server access, 324 00:17:59,960 --> 00:18:03,040 it just starts with an inbox. And that's what makes this 325 00:18:03,480 --> 00:18:07,640 attack particularly dangerous, because all it takes is sending 326 00:18:07,640 --> 00:18:12,760 someone an e-mail. So we had mentioned that timing 327 00:18:12,760 --> 00:18:16,880 was kind of unfortunate in this case because Microsoft had 328 00:18:16,880 --> 00:18:20,760 shipped Patch Tuesday just 48 hours before the zero day was 329 00:18:20,760 --> 00:18:25,200 disclosed on May 14th. So it arrived too late to be 330 00:18:25,200 --> 00:18:29,120 included in this month's this month's update cycle, and 331 00:18:29,120 --> 00:18:33,760 there's no permanent patch yet. Microsoft assigned ACVSS score 332 00:18:33,760 --> 00:18:37,920 of 8.1 and has confirmed that exploitation has been detected 333 00:18:37,920 --> 00:18:40,920 in the wild, but has not publicly identified any of the 334 00:18:40,920 --> 00:18:45,280 attackers or disclosed the size of the affected organizations. 335 00:18:45,760 --> 00:18:49,360 So 1 interesting note on this with this Patch Tuesday and 336 00:18:49,360 --> 00:18:53,480 we'll talk more about the May 12th Patch Tuesday on next 337 00:18:53,480 --> 00:18:56,920 week's episode because it was notable in a couple of ways. 338 00:18:56,920 --> 00:19:00,680 One being that many of the vulnerabilities in this one's 339 00:19:00,680 --> 00:19:03,680 patch Tuesday, which was larger than normal, Microsoft had said 340 00:19:03,680 --> 00:19:07,320 were came from AI, came from things like Claude Mythos and or 341 00:19:07,320 --> 00:19:10,160 GPT cyber. But anyhow, that's another topic 342 00:19:10,160 --> 00:19:12,680 for another time. One of the key takeaways on 343 00:19:12,680 --> 00:19:16,720 patch Tuesday was there was none of the vulnerabilities in patch 344 00:19:16,720 --> 00:19:19,320 Tuesday were publicly exploited were being exploited in the 345 00:19:19,320 --> 00:19:21,920 wild. So that's also notable that 346 00:19:22,240 --> 00:19:25,680 you've got to be very specific here on patch Tuesday, none of 347 00:19:25,680 --> 00:19:29,000 the vulnerabilities patched on that day had any known public 348 00:19:29,000 --> 00:19:32,960 exploit, but in the wild, yet this one disclosed 2 days later 349 00:19:32,960 --> 00:19:36,200 for Exchange Server has been publicly seen exploited in the 350 00:19:36,200 --> 00:19:40,120 wild. So this again, more more time 351 00:19:40,120 --> 00:19:42,120 sensitive if you're still running Exchange on Prem for 352 00:19:42,120 --> 00:19:44,600 exactly that reason. So just want to point, provide 353 00:19:44,600 --> 00:19:47,880 that point of clarification because these are so close and 354 00:19:47,880 --> 00:19:50,600 because there's been larger than normal discussion on this 355 00:19:50,600 --> 00:19:54,520 month's Patch Tuesday for May 2026 and that there was no 356 00:19:54,520 --> 00:19:57,040 public exploitation, no exploitation in the wild. 357 00:19:57,360 --> 00:20:00,600 This is separate from that and there is active exploitation. 358 00:20:01,160 --> 00:20:02,840 So I wanted to be really clear on that point. 359 00:20:03,280 --> 00:20:07,160 Before we get to specifically the fix, let's talk about the 360 00:20:07,160 --> 00:20:10,200 tool that Microsoft is pointing everyone to. 361 00:20:10,200 --> 00:20:14,280 Because I didn't know what this was until I read it in the 362 00:20:14,280 --> 00:20:16,360 article and then I. Was Andy, before you get into 363 00:20:16,360 --> 00:20:20,000 that, we jump to segment. Also just to clarify, this only 364 00:20:20,000 --> 00:20:22,960 impacts Exchange on premises if you are in the cloud. 365 00:20:22,960 --> 00:20:25,880 If you're on Exchange online in Microsoft 365, you are not 366 00:20:25,880 --> 00:20:28,680 impacted by this. And even if you were impacted, 367 00:20:28,680 --> 00:20:31,520 there's no action for you because being a SAS service, 368 00:20:31,840 --> 00:20:35,040 Microsoft would patch it on your behalf if that were necessary. 369 00:20:35,200 --> 00:20:38,560 But in this case, the only thing customers need to take active 370 00:20:39,080 --> 00:20:42,720 action on is if you are running Exchange Server on premises. 371 00:20:42,720 --> 00:20:45,960 And when I say on premises, I mean an infrastructure you are 372 00:20:45,960 --> 00:20:48,400 solely responsible for. You could still be running 373 00:20:48,400 --> 00:20:53,240 Exchange Server in Azure IAS, in a WSIAS and then you would still 374 00:20:53,240 --> 00:20:56,200 be responsible for it. I don't literally mean a date, a 375 00:20:56,200 --> 00:20:59,760 server you can go hug in your data center, in your building. 376 00:21:00,080 --> 00:21:03,400 I mean one that's fully within your responsibility and control. 377 00:21:03,680 --> 00:21:07,320 So you know that that turn on premises is kind of shifted 378 00:21:07,320 --> 00:21:09,840 meaning over time. So I do have to be extra clear 379 00:21:10,000 --> 00:21:11,680 on that. It just means a server you 380 00:21:11,680 --> 00:21:13,840 control fully. Thank you, Adam. 381 00:21:14,280 --> 00:21:18,800 Yeah, and it does affect Server 20, Exchange Server 2016, 382 00:21:18,960 --> 00:21:22,560 Exchange Server 2019, and Exchange Server Subscription 383 00:21:22,560 --> 00:21:24,760 Edition. So all those versions. 384 00:21:24,840 --> 00:21:28,640 It just wasn't in time for Patch Tuesday for this. 385 00:21:28,640 --> 00:21:32,920 So let's talk about this tool that Microsoft is is pointing 386 00:21:32,920 --> 00:21:35,880 everyone to which again I yes. The one you teased at the top of 387 00:21:35,880 --> 00:21:36,720 the show? Let's hear. 388 00:21:36,720 --> 00:21:40,080 About did not know about this. So Eems I saw this, I was like 389 00:21:40,400 --> 00:21:43,800 what is that? It's the Exchange Emergency 390 00:21:43,800 --> 00:21:47,400 Mitigation Service, and Microsoft introduced this in 391 00:21:47,400 --> 00:21:50,480 September of 2021. Almost five years old. 392 00:21:50,840 --> 00:21:55,240 Yeah, specifically because of hacking groups exploiting the 393 00:21:55,240 --> 00:21:58,840 proxy logon and proxy shell. 0 days I remember talking about 394 00:21:58,840 --> 00:21:59,920 that. I do too. 395 00:21:59,960 --> 00:22:01,680 Yes, on the show we talked about. 396 00:22:01,960 --> 00:22:04,440 And so there were. That particular attack lacked 397 00:22:04,440 --> 00:22:07,280 patches or mitigation at the time of exploitation, so 398 00:22:07,280 --> 00:22:11,160 Microsoft built Eems so that it wouldn't ever happen that way 399 00:22:11,160 --> 00:22:14,240 again. So EEMS runs as a Windows 400 00:22:14,800 --> 00:22:20,080 service on Exchange mailbox servers and uses a cloud based 401 00:22:20,080 --> 00:22:23,400 Office config service which we've talked about to check for 402 00:22:23,400 --> 00:22:25,720 available mitigations every hour. 403 00:22:26,320 --> 00:22:30,800 So when a threat is identified, Microsoft can push a signed XML 404 00:22:30,800 --> 00:22:35,320 mitigation file automatically directed to your Exchange Server 405 00:22:35,320 --> 00:22:37,000 without you having to do anything. 406 00:22:37,880 --> 00:22:41,360 It's not a replacement for security updates, but it is the 407 00:22:41,360 --> 00:22:44,800 closest way to close the door while a patch is being 408 00:22:44,800 --> 00:22:47,400 developed. It was introduced with Exchange 409 00:22:47,400 --> 00:22:52,920 Server 2019 Cumulative Update 11 and Exchange Server 2016 410 00:22:53,360 --> 00:22:59,040 Cumulative Update 2022. So if you're on anything older 411 00:22:59,040 --> 00:23:03,800 than September 2021 C use, you don't have it and you'll need to 412 00:23:03,800 --> 00:23:08,600 mitigate this manually. The good news with Eems is that 413 00:23:08,600 --> 00:23:12,360 it is enabled by default. However, default doesn't mean 414 00:23:12,360 --> 00:23:15,840 that it hasn't been turned off. So you need to go and check and 415 00:23:15,840 --> 00:23:20,240 make sure that it is enabled and enabled for your organization 416 00:23:20,280 --> 00:23:22,560 completely. So from Exchange PowerShell, you 417 00:23:22,560 --> 00:23:26,760 would run the getdash organizationconfig pipe, select 418 00:23:26,760 --> 00:23:31,280 Mitigations enabled, and it should return a value of true. 419 00:23:31,800 --> 00:23:34,760 And then you can confirm that your server can actually reach 420 00:23:34,760 --> 00:23:39,560 the mitigation endpoints and there's a PowerShell test dash 421 00:23:39,560 --> 00:23:42,560 Mitigation service connectivity Dash PS1. 422 00:23:42,560 --> 00:23:46,640 And the successful result will read the mitigation service 423 00:23:46,640 --> 00:23:48,800 endpoint is accessible from this computer. 424 00:23:48,960 --> 00:23:51,920 If it fails and you have a connectivity problem that you 425 00:23:51,920 --> 00:23:55,240 have to resolve, and then you can configure confirm that the 426 00:23:55,240 --> 00:23:58,640 mitigation for this specific CVE has been applied. 427 00:23:58,640 --> 00:24:03,120 So customers with EEMS enabled can verify that the mitigation 428 00:24:03,120 --> 00:24:07,880 for CVE 202642897 which is this one, has been applied by 429 00:24:07,880 --> 00:24:09,760 checking the applied mitigations list. 430 00:24:10,160 --> 00:24:13,760 So you can run the Exchange Health Checker script at AKA 431 00:24:14,000 --> 00:24:18,920 MISS Exchange Health Checker which generates an HTML report 432 00:24:18,920 --> 00:24:22,400 with a dedicated EMS section showing exactly what has been 433 00:24:22,400 --> 00:24:26,600 applied. Now if EMS is disabled or you're 434 00:24:26,600 --> 00:24:29,080 in an air gapped environment, you can apply the mitigations 435 00:24:29,080 --> 00:24:33,040 manually by downloading Exchange on premise mitigation tool OMET 436 00:24:33,320 --> 00:24:36,520 and run it from an Exchange elevated Exchange management 437 00:24:36,520 --> 00:24:40,600 shell targeting all servers with that specific CBE identifier. 1 438 00:24:40,680 --> 00:24:45,800 heads up on side effect is once the mitigation has been applied 439 00:24:46,520 --> 00:24:50,360 the OWA print calendar may not work and inline images may not 440 00:24:50,360 --> 00:24:53,080 display correctly in OWA. Which I know I just read that 441 00:24:53,080 --> 00:24:54,640 and I was like both are pretty minor. 442 00:24:54,640 --> 00:24:58,360 So you can use Outlook Desktop as a workaround until the 443 00:24:58,360 --> 00:25:02,720 permanent patch is in place. CISA did also add this to their 444 00:25:02,720 --> 00:25:06,640 Known Exploited Vulnerabilities catalog on May 15th and has set 445 00:25:06,640 --> 00:25:10,760 a remediation deadline of May 29th for all federal civilian 446 00:25:10,760 --> 00:25:14,600 executive branch agencies. If the federal government is 447 00:25:14,600 --> 00:25:17,200 treating this as a two week deadline then your organization 448 00:25:17,200 --> 00:25:18,920 should really be moving faster than that. 449 00:25:18,920 --> 00:25:22,520 Cause you know we. We know the federal government, 450 00:25:22,560 --> 00:25:26,760 yeah. It was pretty slow, so bottom 451 00:25:26,760 --> 00:25:30,680 line here is check your EMS status today, verify that 452 00:25:30,680 --> 00:25:34,120 mitigation is applied, and then watch for Microsoft's permanent 453 00:25:34,120 --> 00:25:36,360 patch. So when it drops, you should 454 00:25:36,360 --> 00:25:39,040 treat this as an emergency patch and do it right away. 455 00:25:39,320 --> 00:25:42,320 Yeah, great discussion here. I think a good heads up 456 00:25:42,320 --> 00:25:45,400 hopefully. I hate to say this about 457 00:25:45,400 --> 00:25:47,360 something we talked about on the show, but hopefully this doesn't 458 00:25:47,360 --> 00:25:50,120 apply to a lot of you. I would love to hear most of you 459 00:25:50,120 --> 00:25:54,440 are in Exchange online today and have no action to take. 460 00:25:54,440 --> 00:25:56,960 However, I understand some organizations still have 461 00:25:57,360 --> 00:26:00,600 regulatory requirements or other needs that are driving them to 462 00:26:00,600 --> 00:26:04,400 maintain Exchange Server. And if you are, you know what 463 00:26:04,400 --> 00:26:07,400 you need to do. We'll say in general, unless you 464 00:26:07,400 --> 00:26:11,320 have a regulatory need, if it's not some sort of reason like 465 00:26:11,320 --> 00:26:14,040 that, you really shouldn't be running Exchange on Prem 466 00:26:14,040 --> 00:26:15,560 anymore. If you can at all avoid it. 467 00:26:15,560 --> 00:26:19,360 It's just really demanding service to run and maintain and 468 00:26:19,360 --> 00:26:22,120 keep secure, as this kind of points out. 469 00:26:22,120 --> 00:26:25,960 And it's, it's honestly, this is not a Microsoft sales guy 470 00:26:25,960 --> 00:26:27,600 talking. It's it's just someone who cares 471 00:26:27,600 --> 00:26:30,480 about cybersecurity. You're better off not doing it, 472 00:26:30,480 --> 00:26:32,840 in all honesty. Let Microsoft handle it for you 473 00:26:33,120 --> 00:26:36,720 and then go reclaim that saved time to go deliver something 474 00:26:36,720 --> 00:26:38,800 with more value. But this is cool. 475 00:26:38,800 --> 00:26:43,280 Hey, this EEMS system reminds me, Apple has something similar 476 00:26:43,280 --> 00:26:46,720 on Mac OS now where they have a way to deliver like very 477 00:26:46,720 --> 00:26:48,560 emergency patches. And I believe it's through the 478 00:26:48,560 --> 00:26:52,120 same concept of like an XML file that can be delivered without a 479 00:26:52,120 --> 00:26:57,320 reboot very, very, very rapidly. And because it has such little 480 00:26:57,480 --> 00:27:00,800 change surface, it's really easy to test and get out in the wild 481 00:27:00,800 --> 00:27:04,520 very quickly without the risk of some sort of unexpected 482 00:27:04,520 --> 00:27:08,040 degradation in another service as a as a bug in the patch, as 483 00:27:08,040 --> 00:27:10,200 an example. So this is clever. 484 00:27:10,280 --> 00:27:13,160 You love to see anything that allows us to move more quickly 485 00:27:13,160 --> 00:27:15,920 in response to stuff like this. And as a reminder for your 486 00:27:15,920 --> 00:27:20,440 Windows desktop endpoints that your end users use, make sure 487 00:27:20,440 --> 00:27:22,400 you're leveraging Windows Hot Patch today. 488 00:27:22,920 --> 00:27:26,760 Windows Hot Patch enables you to avoid reboots 8 of 12 months out 489 00:27:26,760 --> 00:27:28,800 of the year. I mean, you would only reboot on 490 00:27:28,800 --> 00:27:36,560 the January, the April, the July and the October, yeah, October 491 00:27:36,560 --> 00:27:38,680 patch Tuesdays. And then the rest of them you 492 00:27:38,680 --> 00:27:41,680 just install the patches and no reboot required, which obviously 493 00:27:41,680 --> 00:27:43,760 allows you to move a lot more quickly as well. 494 00:27:43,760 --> 00:27:45,840 So anyway, we can just move faster. 495 00:27:45,840 --> 00:27:48,760 This is always a good reminder on, on how do we close the loop 496 00:27:48,760 --> 00:27:52,560 and gain nimbleness in our, in our patch response, because I 497 00:27:52,560 --> 00:27:55,680 think we're going to have more of this for a while. 498 00:27:55,680 --> 00:27:58,120 We discussed this on previous shows with some of the AI 499 00:27:58,120 --> 00:28:01,200 vulnerability detections that are coming online and expect a 500 00:28:01,200 --> 00:28:05,000 bit of a tidal wave of very high severity vulnerabilities coming. 501 00:28:05,440 --> 00:28:09,320 And so this is a great time to get really sharp on how we patch 502 00:28:09,320 --> 00:28:12,800 and how we stay up to speed and how we stay current because this 503 00:28:12,800 --> 00:28:15,280 tidal wave is coming. And I don't think it'll last 504 00:28:15,280 --> 00:28:19,080 forever, but I do think there's going to be some busy patching 505 00:28:19,080 --> 00:28:23,600 times ahead for the next 612 eighteen months before we kind 506 00:28:23,600 --> 00:28:27,680 of have caught all the obvious low hanging fruit, so to speak. 507 00:28:27,760 --> 00:28:31,120 And and then we're back to a more typical cadence, especially 508 00:28:31,120 --> 00:28:33,600 as code being released in the wild is, is having greater 509 00:28:33,600 --> 00:28:35,600 scrutiny before it ever goes out the door. 510 00:28:35,600 --> 00:28:40,320 So great opportunity here, but also good news that there is a 511 00:28:40,360 --> 00:28:42,040 fix. It may already have been pushed 512 00:28:42,040 --> 00:28:43,920 and all you need to do is validate it's there. 513 00:28:43,960 --> 00:28:46,320 It's a temporary fix. Obviously it comes with a little 514 00:28:46,320 --> 00:28:49,800 bit of heartburn with the image display being disabled and the 515 00:28:49,800 --> 00:28:51,960 print calendar function being disabled in OWA. 516 00:28:52,680 --> 00:28:57,040 You can use the Outlook desktop app as a workaround and soon an 517 00:28:57,040 --> 00:28:59,040 emergency patch will be available and you'll be able to 518 00:28:59,040 --> 00:29:01,040 restore that behavior soon enough. 519 00:29:01,080 --> 00:29:04,440 So for now, that's that's a pretty good answer when the 520 00:29:04,440 --> 00:29:06,440 answer is it's probably already fixed. 521 00:29:06,440 --> 00:29:08,400 Just go check. You love to hear that. 522 00:29:08,400 --> 00:29:10,680 So I think that's that's a great response. 523 00:29:11,160 --> 00:29:13,440 All right, well, that's our show for this week. 524 00:29:13,640 --> 00:29:15,840 Thanks for watching and listening. 525 00:29:15,840 --> 00:29:19,840 As always, our contact information along with the links 526 00:29:19,840 --> 00:29:23,600 to the topics that we talked about will be in the show notes. 527 00:29:23,600 --> 00:29:26,560 If you have any questions or topics you want us to talk about 528 00:29:26,560 --> 00:29:29,520 in the future, just e-mail us. Thanks. 529 00:29:29,520 --> 00:29:30,600 We'll talk to you guys next week.