Welcome to the Blue Security Podcast, a weekly podcast for
information security defenders where we bring you discussions
on best practices, tools, and implementation for enterprise
security. Now here are your hosts for
today's show, Andy JA and Adam Brewer.
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 on 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, Kun Tu FA was able to rebuild brand new
infrastructure and then quickly return to normal activity
levels. Now here's where it kind of ties
into what we talked about last week.
In late April of 2026. This year East Central Threat
Response Unit analyzed a new campaign combining Tycoon 2 FAS
known infrastructure with OWA 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 is 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 control 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 on 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, VPN, 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 analysed 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 trending attack
vector. And you know, the warning flags
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 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
request 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 intra 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 login 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 scream 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 because there are almost done.
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 and Tri D 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 passwordless 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 phishing 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 pallet.
You just train them like Pavlov and his dogs to automatically,
oh a prompt pops up, put in my password, the bell rang, I
salivate. Same idea when you move to fish
resistant MFA compared to let's say you're using.
God forbid you're still sending your users a A6 digit one time
passcode through SMSI. 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 asks 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'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 sign in 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 your, 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
Oauth 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 applications. 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 can trusted a lot more than this highly permissioned
Oauth app that has never been seen before.
That may be 1 worth investigating and potentially
revoke. All right, so moving on to our
final story for tonight, there is an Exchange Zero 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 on 1st off the the high level overview is that Microsoft is
closed 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 then
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 their 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 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 hog 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.
Don't want you teased at the top of the show?
I 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, wow. 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 on the show, 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 direct it 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 US, you don't have it and you'll need to
mitigate this manually. The good news with EMS is that
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 Get Dash Organization config 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 CMS enabled
can verify that the mitigation for CBE 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 you 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. SISA 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 actors You know.
We know the federal. Government.
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, tame that save time to go deliver
something with more value. But this is cool.
Hey, this EEMS system reminds, 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 is 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.
Thank you for listening to the Blue Security Podcast.
Please check out the show notes, catch up on episodes you may
have missed, and subscribe so you don't miss any future
episodes. Find Andy on Twitter at a Jaw
Zero and Adam at AJ Brewer. See you at our next episode.