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