Welcome to this week's episode of the Blue Security Podcast.
I'm Andy, your host. I'm Adam, your Co host.
We have two stories for this week.
The first one we're going to talk about Tycoon 2FA and
they're they're back now along with a an attack vector that we
talked about last week, which is device code flow.
Device code flow and they're using it for phishing.
So we'll get into that as our first topic and then we'll
follow up with an exchange 0 day that kind of dropped just a few
days 48 hours after patch Tuesday was released.
And so we'll talk about that and how you can protect your
organization's from the zero day.
And I learned about a new feature.
Well, it's actually not even new, but so if you stick around
to the Exchange, the Exchange story, there's actually a
feature that I learned about as I was researching this that I
didn't know existed, something that is called the Exchange
Emergency Mitigation Service. So we'll talk about that.
But before we get started, let's go with our disclaimer since
we're going to be talking about Microsoft this week.
Andy and I both work for Microsoft in our in our field
security sales. We do the show outside of work.
We're recording this on Sunday, May 17th at about 7:20 PM, so
definitely not during work hours.
And we self fund the show. It's literally a labor of love.
We pay for the hosting, the recording platform, the domain
and everything in between ourselves.
So the opinions you're about to hear expressed are those of Adam
Brewer and Andy Jaw and do not necessarily reflect those of
Microsoft Corporation. And with that, Andy on with the
show. All right, so if you did catch
last week's episode, we broke down device code flow phishing
for the first well, not really for the first time, but we went
into a detail probably it's been a few years since we really
talked about it. But what it is in a nutshell is
when authentication happens on a device that doesn't have an
input method like a keyboard or something like that.
And so you have to flow that authentication from another
device. Think like when you sign into
Netflix or any type of streaming app, YouTube from your phone
that then authenticates to like an Apple TV or a Roku or
something like that, you scan AQR code.
And so that's that Oauth authentication standard is
called device code flow. And so now that particular
attack vector is being used in a campaign with Tycoon 2.
So if you haven't heard of who these guys are, they're one of
the most widespread phishing as a service platforms to emerge
and they were developed by the threat actor Microsoft tracks as
Storm 1747. By mid 20/20 it had accounted
for roughly 62% of all phishing attempts that Microsoft blocked
with campaigns that reached over 500,000 organizations per month
worldwide. So it's a criminal SAS operation
with kits that start as little as $120.00 for 10 days of
access. And that lowers the technical
barrier enough that criminals with very limited technical
expertise can run a sophisticated impersonation
campaign. Microsoft and Europol actually
LED a major takedown in March of 2026 where they seized 330
active domains. But unfortunately, despite all
of the work that Microsoft and Europol did, tycoon 2FA was able
to rebuild brand new infrastructure and then quickly
return to normal activity levels.
Now here's where kind of ties into what we talked about last
week. In late April of 2026 this year,
ecentra threat response unit analyzed a new campaign
combining Tycoon 2 FAS known infrastructure with OA device
authorization grant flow abuse to compromise Microsoft 365
accounts. The account The attack begins
with a phishing e-mail and so it's usually it's disguised as
something like a a vendor invoice reminder and then it
contains a trust Trustify click tracking link.
Now I looked into Trustify and it's a it's a reputable service
that is used all the time and from the threat response unit.
They were unsure why Trustify or how they even started getting
used here. But once the victim clicks on
the link, they're redirected through a Cloudflare domain and
then landing on a malicious payload.
But instead of a fake login page, the campaign uses real
Microsoft login.process@microsoft.com/devicelogin.
So they're using that device code flow in their phishing.
So victims are shown on Microsoft 365 voicemail
notification and then they're instructed to copy a user code
and and put that into the real Microsoft page.
And since they're on genuine Microsoft infrastructure, MFA is
then triggered if you have it enabled.
She should and it's looks completely normal.
And the victim thinks everything is fine.
But what they don't realize is like by approving that prompt,
they're actually granting Oauth access tokens to the attacker
controlled device running in the background.
And so the phishing doesn't really bypass MFA because it
you're just authorizing MFA, but you don't really know what
you're actually authorizing on the back end.
And because Microsoft's authentication broker is a
broker application, that single consent can be exchanged for
tokens that are scoped to exchange a Microsoft Graph
OneDrive without any other user interaction.
So that one time approval does authenticate you to the
Microsoft 365 estate. This is pretty tough to catch
because the Tycoon 2FA kit does contain extensive protections
against research and automated scanning, so it can detect
Selenium, Puppeteer, Playwright, Burp Suite, and then they can
also block security vendors, VPNs, sandbox and AI crawlers.
It's block list contains currently 230 vendor names and
it's constantly updated. So if it thinks that it's
getting analyzed or scanned by a legitimate tool, it actually
just redirects it to a legitimate Microsoft page and
just kind of cuts ties and walks away.
So, you know, this is, I saw this and immediately I was like,
this is another instance. We'd literally just talked about
this last week and you know, this is not a coincidence.
This is a, a trending attack vector.
And you know, the warning flag should be up for you.
And if you don't have mitigations in place, you should
start looking at them and and implementing them as soon as
possible. So as part of our normal
podcast, we'd like to give you actions.
Three things. Number one, we talked about this
last week go and scope conditional access policies to
block device code flow. Obviously, there you might have
some specific use cases. Scope them down into very
narrow, allows for specific people, specific users, specific
devices. Also, while you're there you can
also do a consent policy review. So by default in many tenants,
users can approve low risk Oauth permissions on their own.
Which means that like a convincing phishing prompt like
this can get a user to hand over access without an admin even
knowing about it. So you have a few options here.
When you go in and check for Oauth app consent, you could
require an admin approval for all third party app consents.
You could also restrict self-service consent to only
verified publishers. And you can also enable the
admin consent workflow so that requests don't just fall
silently, they are routed to an admin queue for review.
To be clear, this is different than blocking device code flow.
It doesn't necessarily stop this attack, but it does protect
across a broader category that we're kind of talking about
here, the Oauth phishing, which includes consent phishing
campaigns that don't use device code flow.
But if you're already there in the Enter admin portal, you
might as well double check and make sure that you have this
one. And then finally, user
awareness, right? So everything is on about
training as well. So make sure that you train your
users that they don't personally initiate a log.
If they didn't personally initiate a login like they were
they were actually going to something, then they should
never really approve anything. If if they just get a pop up.
The tell is when device code phishing is always the same.
Someone else started the authentication flow, not you.
So if you didn't, like, go to the app and log in, or you
yourself wanted to log into like Netflix or whatever, like you
didn't start that, then it's probably some sort of malicious
content. Yeah.
So make sure those are our takeaways.
Adam, any thoughts on this particular attack and story?
It is amazing that device code flow is back again and the
advice remains the same. You nailed it perfectly Andy.
This is 1 I would strongly recommend.
You do not need to chase your tail on this.
You have permission from Adam and Andy to run a screen test on
this, Disable it and wait for screaming.
You won't hear any because there are almost no legitimate use
cases for this. Don't e-mail me.
There may be some, I get it, but for the most part this is such a
large risk and the security benefit is so great from
disabling it. I strongly recommend you utilize
screen testing to validate the scenarios in which you need to
unblock this. Just wait for screaming, but
just block it. Work wide.
Do not try to run around and figure out who's using this in
legitimate scenarios 'cause there are almost none.
This just needs to be turned off.
The second one with the O auth consent also.
So first one, by the way, we talked last week, if you didn't
listen last week, real simple, Microsoft does recommend you
disable device code flows in enterprise scenarios.
That's a consumer facing scenario thing.
It's useful to sign into my Xbox.
It's not really useful to sign into my enter ID account.
So second one, the Oauth consent flow, also a coming and growing
attack vector and also one that Microsoft recommends today
should be restricted compared to the default setting.
And again, you've heard us probably talk about the Secure
Future initiative many times on this show.
It's his multi year engineering Sprint.
And one of the goals of that, there are three goals, secure by
default, secure by design and secure operations.
You can complain the default isn't secure today and defaults
take a long time to change. I will acknowledge that it
doesn't mean it's not coming. I would imagine maybe already
modern inter ID tenants do not ship with this enabled for all
users by default. But if you stood up your M365
environment a long time ago it may still be set that way.
So go restrict this, lock it down, limited to admins and that
admin approval flow is probably the right choice at this point.
User awareness. So here's the thing Andy, you
were going through and you were like, I've got three things for
you. And immediately my mind at this
point, I have a huge bias towards fish resistant MFAI.
It's my answer to everything. You bring it up.
I say fish resistant MFA, but you could say, but Adam, this
could still happen with fish resistant MFA.
And you are absolutely correct. A user could be tricked just as
easily into inputting this device code flow, then inserting
their UB key, touching it, going through that process and
authenticating, and then the the attacker still hasn't gained the
same level of access. That is 1000% true.
However, what you're missing is the same benefit we've seen from
moving users to password less technologies.
Users who use password less technologies are more skeptical
when they're asked to provide their password because they
never have to in legitimate scenarios or very rarely, and it
catches their attention enough where they don't respond
positively as much. This is why many, many years
ago, 10 years ago, Microsoft came out with guidance that said
stop making your users sign in all the time.
Let them sign in once and then keep their credentials cashed
and valid. Because the more you make them
sign in, the more you're training them to respond
positively to a fishing attempt. They put in their password all
the time without thinking about it.
They're like the lab rat pushing the button to get the food
pellet. You just train them like Pavlov
and his dogs to automatically oh a prompt pops up, put in my
password. Oh the bell rang, I salivate.
Same idea when you move to fish resistant MFA compared to you.
Let's say you're using. God forbid you're still sending
your users a A6 digit one time passcode through SSI.
Hope not, but maybe you are. Maybe you still have a hardware
tokens that you know generate A1 time passcode.
Maybe you have a software one time passcode.
Either way, if your users are still intimately familiar with
one time passcodes, they don't think anything of a device code
flow that asked them to plug it in to complete some sort of
process. Again, you've trained them to do
this. You've trained them to do it
without thinking about it. It's becomes that Pavlovian
conditioning if you move to fish resistant MFA where I don't ever
deal with one time passcodes anymore for my enterprise login
if I get prompted with one. Well, this is weird.
I don't do this to sign into work.
Maybe my bank makes me do this, but work doesn't.
I'm not going to do this. So even though technically fish
resistant MFA would not prevent this attack, would not block it.
That is true. By implementing it, you are
helping reduce your users in responding positively to these
kinds of attacks. Andy talked about the user
education and that's certainly a portion of it.
But the other portion of it is just not training your users to
do this anymore. Because when we used to make
user sending with passwords all the time, we train them to
respond to phishing attacks. When we make users put in one
time passcodes all the time, we train them to respond to device
code flow attacks, same exact idea.
So get rid of that and now you don't have the training and the
pre training for them to respond to these kind of phishing
attempts. And I'll add like a a sub bullet
as well before we move on is while you're on the subject of
kind of looking at Oauth consent.
If for some reason you hadn't switched that and you were
allowing your users to consent to Oauth, then you probably have
a bunch of applications in your tenant that users have consented
to over the years or however long.
You know, highly permissioned applications, no less.
Yes, absolutely. So, so one thing you can look at
is when you go to Entra, the admin portal, there's a tab on
the left hand side that says enterprise applications.
And all of those enterprise applications are either one O
auth consent or two Federated with Entra.
And so you can go through and you can look at them and it's
pretty easy to see which ones are not all of them.
But you can probably deduce like based on your knowledge of what
applications your enterprise uses, which ones are probably
not part of your enterprise. Like if you're a OneDrive shop
and you see Dropbox there or you're, you know, your box shop
and you see something else, right?
Google Drive or like, for example, I worked at Trek bikes
a long time ago and of course Garmin was a big, you know,
people were using GPS on their bikes to track their, their
rides and some people a lot consented to Garmin using their
corporate e-mail and that showed up.
So you'll be able to see that you'll be able to see the
permissions that it's granted. And if you want to review,
there's also a defender for cloud apps that can look at all
of your highly permissioned Oauth application.
So you can go and review that, or you can do it manually.
If if you just go into the enterprise apps and you can see
which users specifically are assigned, quote UN quote
assigned because they're the ones who authorized it.
And you'll see apps with just like one or two users.
You know, if you have an organization of thousands of
people and only one or two people are using it, it's
probably not an app that's used org wide.
So I had to do this exercise way back in the day.
Before we had a nice tool in Defender for cloud apps that
would give us all of the highly permissioned applications.
But now you can go and check there if you have licenses for
that and then also just kind of go through manually if you need
to. Great call out on the Defender
for cloud apps. One thing I like about it is it
provides a lot of additional context on the prevalence of the
application. So it may be highly
permissioned, but it is a well known common application that
many orgs use. Probably contrasted a lot more
than this highly permissioned Oauth app that has never been
seen before. That may be 1 worth
investigating and potentially revoking.
All right, so moving on to our final story for tonight.
There is an exchange 0 day CVE 202642897 actively bling being
exploited. So this one's a little time
sensitive. If your organization is running
on premise Exchange today, you need to act on this.
There is a tool specifically built for moments like this
which we'll talk about. So First off, the the high level
overview is that Microsoft disclosed a high severity
Exchange Server vulnerability that is being actively exploited
in the wild. The attack vector is cross site
scripting through OWA or Outlook on the web.
An attacker can send a specifically crafted e-mail and
if the recipient opens it in OWA under certain conditions,
arbitrary JavaScript and executes in the browser context.
The attack path does not require authentication or server access,
it just starts with an inbox. And that's what makes this
attack particularly dangerous, because all it takes is sending
someone an e-mail. So we had mentioned that timing
was kind of unfortunate in this case because Microsoft had
shipped Patch Tuesday just 48 hours before the zero day was
disclosed on May 14th. So it arrived too late to be
included in this month's this month's update cycle, and
there's no permanent patch yet. Microsoft assigned ACVSS score
of 8.1 and has confirmed that exploitation has been detected
in the wild, but has not publicly identified any of the
attackers or disclosed the size of the affected organizations.
So 1 interesting note on this with this Patch Tuesday and
we'll talk more about the May 12th Patch Tuesday on next
week's episode because it was notable in a couple of ways.
One being that many of the vulnerabilities in this one's
patch Tuesday, which was larger than normal, Microsoft had said
were came from AI, came from things like Claude Mythos and or
GPT cyber. But anyhow, that's another topic
for another time. One of the key takeaways on
patch Tuesday was there was none of the vulnerabilities in patch
Tuesday were publicly exploited were being exploited in the
wild. So that's also notable that
you've got to be very specific here on patch Tuesday, none of
the vulnerabilities patched on that day had any known public
exploit, but in the wild, yet this one disclosed 2 days later
for Exchange Server has been publicly seen exploited in the
wild. So this again, more more time
sensitive if you're still running Exchange on Prem for
exactly that reason. So just want to point, provide
that point of clarification because these are so close and
because there's been larger than normal discussion on this
month's Patch Tuesday for May 2026 and that there was no
public exploitation, no exploitation in the wild.
This is separate from that and there is active exploitation.
So I wanted to be really clear on that point.
Before we get to specifically the fix, let's talk about the
tool that Microsoft is pointing everyone to.
Because I didn't know what this was until I read it in the
article and then I. Was Andy, before you get into
that, we jump to segment. Also just to clarify, this only
impacts Exchange on premises if you are in the cloud.
If you're on Exchange online in Microsoft 365, you are not
impacted by this. And even if you were impacted,
there's no action for you because being a SAS service,
Microsoft would patch it on your behalf if that were necessary.
But in this case, the only thing customers need to take active
action on is if you are running Exchange Server on premises.
And when I say on premises, I mean an infrastructure you are
solely responsible for. You could still be running
Exchange Server in Azure IAS, in a WSIAS and then you would still
be responsible for it. I don't literally mean a date, a
server you can go hug in your data center, in your building.
I mean one that's fully within your responsibility and control.
So you know that that turn on premises is kind of shifted
meaning over time. So I do have to be extra clear
on that. It just means a server you
control fully. Thank you, Adam.
Yeah, and it does affect Server 20, Exchange Server 2016,
Exchange Server 2019, and Exchange Server Subscription
Edition. So all those versions.
It just wasn't in time for Patch Tuesday for this.
So let's talk about this tool that Microsoft is is pointing
everyone to which again I yes. The one you teased at the top of
the show? Let's hear.
About did not know about this. So Eems I saw this, I was like
what is that? It's the Exchange Emergency
Mitigation Service, and Microsoft introduced this in
September of 2021. Almost five years old.
Yeah, specifically because of hacking groups exploiting the
proxy logon and proxy shell. 0 days I remember talking about
that. I do too.
Yes, on the show we talked about.
And so there were. That particular attack lacked
patches or mitigation at the time of exploitation, so
Microsoft built Eems so that it wouldn't ever happen that way
again. So EEMS runs as a Windows
service on Exchange mailbox servers and uses a cloud based
Office config service which we've talked about to check for
available mitigations every hour.
So when a threat is identified, Microsoft can push a signed XML
mitigation file automatically directed to your Exchange Server
without you having to do anything.
It's not a replacement for security updates, but it is the
closest way to close the door while a patch is being
developed. It was introduced with Exchange
Server 2019 Cumulative Update 11 and Exchange Server 2016
Cumulative Update 2022. So if you're on anything older
than September 2021 C use, you don't have it and you'll need to
mitigate this manually. The good news with Eems is that
it is enabled by default. However, default doesn't mean
that it hasn't been turned off. So you need to go and check and
make sure that it is enabled and enabled for your organization
completely. So from Exchange PowerShell, you
would run the getdash organizationconfig pipe, select
Mitigations enabled, and it should return a value of true.
And then you can confirm that your server can actually reach
the mitigation endpoints and there's a PowerShell test dash
Mitigation service connectivity Dash PS1.
And the successful result will read the mitigation service
endpoint is accessible from this computer.
If it fails and you have a connectivity problem that you
have to resolve, and then you can configure confirm that the
mitigation for this specific CVE has been applied.
So customers with EEMS enabled can verify that the mitigation
for CVE 202642897 which is this one, has been applied by
checking the applied mitigations list.
So you can run the Exchange Health Checker script at AKA
MISS Exchange Health Checker which generates an HTML report
with a dedicated EMS section showing exactly what has been
applied. Now if EMS is disabled or you're
in an air gapped environment, you can apply the mitigations
manually by downloading Exchange on premise mitigation tool OMET
and run it from an Exchange elevated Exchange management
shell targeting all servers with that specific CBE identifier. 1
heads up on side effect is once the mitigation has been applied
the OWA print calendar may not work and inline images may not
display correctly in OWA. Which I know I just read that
and I was like both are pretty minor.
So you can use Outlook Desktop as a workaround until the
permanent patch is in place. CISA did also add this to their
Known Exploited Vulnerabilities catalog on May 15th and has set
a remediation deadline of May 29th for all federal civilian
executive branch agencies. If the federal government is
treating this as a two week deadline then your organization
should really be moving faster than that.
Cause you know we. We know the federal government,
yeah. It was pretty slow, so bottom
line here is check your EMS status today, verify that
mitigation is applied, and then watch for Microsoft's permanent
patch. So when it drops, you should
treat this as an emergency patch and do it right away.
Yeah, great discussion here. I think a good heads up
hopefully. I hate to say this about
something we talked about on the show, but hopefully this doesn't
apply to a lot of you. I would love to hear most of you
are in Exchange online today and have no action to take.
However, I understand some organizations still have
regulatory requirements or other needs that are driving them to
maintain Exchange Server. And if you are, you know what
you need to do. We'll say in general, unless you
have a regulatory need, if it's not some sort of reason like
that, you really shouldn't be running Exchange on Prem
anymore. If you can at all avoid it.
It's just really demanding service to run and maintain and
keep secure, as this kind of points out.
And it's, it's honestly, this is not a Microsoft sales guy
talking. It's it's just someone who cares
about cybersecurity. You're better off not doing it,
in all honesty. Let Microsoft handle it for you
and then go reclaim that saved time to go deliver something
with more value. But this is cool.
Hey, this EEMS system reminds me, Apple has something similar
on Mac OS now where they have a way to deliver like very
emergency patches. And I believe it's through the
same concept of like an XML file that can be delivered without a
reboot very, very, very rapidly. And because it has such little
change surface, it's really easy to test and get out in the wild
very quickly without the risk of some sort of unexpected
degradation in another service as a as a bug in the patch, as
an example. So this is clever.
You love to see anything that allows us to move more quickly
in response to stuff like this. And as a reminder for your
Windows desktop endpoints that your end users use, make sure
you're leveraging Windows Hot Patch today.
Windows Hot Patch enables you to avoid reboots 8 of 12 months out
of the year. I mean, you would only reboot on
the January, the April, the July and the October, yeah, October
patch Tuesdays. And then the rest of them you
just install the patches and no reboot required, which obviously
allows you to move a lot more quickly as well.
So anyway, we can just move faster.
This is always a good reminder on, on how do we close the loop
and gain nimbleness in our, in our patch response, because I
think we're going to have more of this for a while.
We discussed this on previous shows with some of the AI
vulnerability detections that are coming online and expect a
bit of a tidal wave of very high severity vulnerabilities coming.
And so this is a great time to get really sharp on how we patch
and how we stay up to speed and how we stay current because this
tidal wave is coming. And I don't think it'll last
forever, but I do think there's going to be some busy patching
times ahead for the next 612 eighteen months before we kind
of have caught all the obvious low hanging fruit, so to speak.
And and then we're back to a more typical cadence, especially
as code being released in the wild is, is having greater
scrutiny before it ever goes out the door.
So great opportunity here, but also good news that there is a
fix. It may already have been pushed
and all you need to do is validate it's there.
It's a temporary fix. Obviously it comes with a little
bit of heartburn with the image display being disabled and the
print calendar function being disabled in OWA.
You can use the Outlook desktop app as a workaround and soon an
emergency patch will be available and you'll be able to
restore that behavior soon enough.
So for now, that's that's a pretty good answer when the
answer is it's probably already fixed.
Just go check. You love to hear that.
So I think that's that's a great response.
All right, well, that's our show for this week.
Thanks for watching and listening.
As always, our contact information along with the links
to the topics that we talked about will be in the show notes.
If you have any questions or topics you want us to talk about
in the future, just e-mail us. Thanks.
We'll talk to you guys next week.