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.
Today we're going to be talking about two things.
The first topic is going to be Apple Lockdown mode and how
Apple released some statistics and stuff about how lockdown
mode has actually never had a successful attack against it.
And so we'll we'll get into that.
And then the second one is about this whole phantom device attack
where Intra ID or Azure AD, whatever, you know, that's a lot
of the articles actually say Azure AD, which I thought was
kind of funny. Yeah, I saw that too.
But it's intra ID and, and how there was a PRT token that was
minted and bypass conditional access.
And so that was all the rage. I saw that some chatter on
Twitter and and certainly internally there's some folks
asking about it as well as customers.
So wanted to go through that attack and how it happened and
how you can mitigate it. Before we get started, since
we're going to be talking about Microsoft, Adam, you want to
kick it off with a quick disclaimer?
Yeah. And Andy and I both work for
Microsoft and Field Security sales.
We do this show outside of work. We're recording this Sunday
night about 7:30 PM local time and we self fund the show.
We do not accept accept sponsorships or any other
income. This is purely a labor of love
and we put our while it's behind it.
So that said, 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, on with the show. OK, so let's talk about Apple
Lockdown mode. I know that we have mentioned
this before on the show, but let's just highlighted real
quick in case you are unfamiliar with it.
Lockdown mode is something that is built into the iOS operating
system. It is opt in, so it's not
enabled by default, but it is a system hardening feature that
was introduced by Apple in 2022 specifically for high risk
individual. So think like if you're press in
like or like ACEO or maybe you know, C-Suite of a major
company, probably like anyone in high level government, those are
the people who probably would look at this.
If you're working in a sensitive area or have some sort of
secrets that you need to guard, these are the folks that are
more susceptible and probably should look at it.
It's really not for the average user, although it is available
for anyone to use and certainly like at organizations where you
might think about this, this is something that you can enable
for your users. So what it does is it
dramatically shrinks the iPhones attack surface and the number of
entry points that cyber criminal can exploit.
It will disable and restrict features that are commonly
abused in like spyware attacks, and also force attackers to
develop far more complex and expensive techniques to even
attempt a compromise on the phone.
Apple designed it in direct response to commercial spyware
vendors like the NSO Group, which they make the software
Pegasus. If you've heard of that
intellectual which makers of Predator and Paragon solutions
who sell government grade hacking tools capable of
silently compromising iPhones. So why are we talking about
this? Well, Ale has confirmed that
after four years of this feature being around that no one using
lockdown mode has been successfully hacked by spyware.
Or at least that they know of, I should say.
And, and of course, like they're monitoring this pretty closely.
So I, I would take Apple at its word for this one.
Apple spokesperson Sarah O'Rourke stated that they were
not aware of any successful mercenary spyware attacks
against a lockdown mode enabled device.
And that's really a meaningful milestone here.
Apple has sent spyware compromise notifications to
users in over 150 countries, so they really do have visibility
into this threat. And independent researchers at
Citizen Lab have documented at least 2 cases where Lockdown
mode actively blocked spyware attacks, once against Nso's
Pegasus and once against Predator.
And then in one more other document case, security
researchers at Google found that spyware simply bailed out of its
attack attempt when it detected lockdown mode.
So attackers basically gave up rather than risk exposure.
Apple's cybersecurity expert Patrick Wardle, call it one of
the most aggressive consumer facing hardening features ever
shipped. So if you're thinking about
using this, and again, we've we've talked about this before,
but just kind of highlighting the trade-offs if you were to
enable it. And This is why it's really not
for everyone, but most message attachment types are blocked.
So iMessage becomes a lot more limited.
Any attachments beyond images are stripped.
Link previews in messages are also disabled.
So you'll need to copy and paste links manually into your
browser. Webkit, which is so far as
rendering engine features are restricted.
Some websites might not even load correctly at all.
Wired connections to computers or accessories are blocked.
When the iPhone is locked, configuration profiles cannot be
installed, which prevents certain MDM management, Mobile
device management enrollment. Now we've mentioned this before,
but it is worth noting that if the device is enrolled in MDM
and then you enable lockdown mode, it will keep the MDM
profile. However, when you enable
lockdown mode, no additional MDM profiles can be added to the
phone. So it's preventing any other,
which is a common, you know, easy attack vector is just, you
know, send someone a link and roll the phone and then you
know, then you have it under management can do what you want.
And then a couple of things like incoming FaceTime calls from
unknown contacts are blocked and shared albums are removed from
photos and new shared album invite invitations are blocked.
So there is some trade off and and that is definitely felt if
you're just a normal user. Well, for example, like if
you're a journalist covering a war zone, Aceover defense
contractor or like a dissident activist, that friction might be
worth it. So if you're in a high risk
role, this is something that you would definitely want to look
at. You just go to the settings
under privacy and security and enable lockdown mode.
It'll have some, you know, text, give you the the highlights of
exactly what we told you, the trade-offs.
And then you'll you'll make yourself much less inviting
target for cyber attackers, Patrick.
Wardle is that dude. He is the guru of Apple
cybersecurity hosts the objective by the sea conference
cybersecurity conference targeted at just Apple operating
systems. Former champ employee friend of
friend of the show Matthew Ward is is friends with Patrick and
can speak to his chops. So when he says quote, it's one
of the most aggressive consumer facing hardening features ever
shipped. He's not kidding, but a very
effective, right. So there are significant
trade-offs from a lot of these quality of life improvements
we're comfortable with. But you can really limit a tax
surface by giving those up and it makes really intelligent
trade-offs as to what those are. It's amazing how much
cybersecurity attacks surface we just naturally accept for these
quality of life improvements as opposed to have any more
hardened operating system. But Apple gives you that choice.
And Andy, I think you mentioned a lot of the personas where this
makes sense. I'd extend it.
If you're in the C-Suite and you're a Fortune 100 company,
you should have this turned on. I am sure.
I have no doubt Satya Nadella, our CEO at Microsoft has this
turned on his iPhone as an example as well.
He should. Sam Altman should have this
turned on on his iPhone, even though he's not maybe Fortune
100 yet. I mean, being open AI, it's
important gig. There's lots of people this
targets. If you're also a tinfoil hat
aficionado, this is available to you as well.
But you know, a great feature, love it when that choice is put
in the hands of users and great cybersecurity posture is
available with literally a flip of the switch.
So well done to Apple. We complement them on their
cybersecurity chops all of the time.
There was a stupid and inaccurate meme for a very long
time that Apple was only secure because it wasn't popular.
Obviously, today, with the very large popular popularity of iOS
and its derivative operating systems, that's no longer a
valid criticism. It turns out Apple's just good
at cybersecurity. So, you know, credit where
credit's due. And then, you know, going back
to the quote from Apple spokesperson Sarah O'Rourke,
Apple doesn't lie when they speak publicly and they tend to
do less of what I call corporate weasel language than a lot of
other orgs where they will say something that is, if you parse
it like an attorney, factual but not really honest.
Apple doesn't do that. They kind of say what they mean.
And so when Apple just comes out and says they're not aware of
any successful mercenary spyware attacks against a lockdown mode
enabled Apple device, that's what they mean.
Now, again, there are qualifiers in that statement.
They're specifically saying mercenary spyware.
It's not mercenary spyware. I mean, you can make that
distinction. You can also say they're not
aware. Well, they can't talk about it
if they're not aware of it. So of course, there could be a
text they're not aware of. Fine, Sure, you could poke holes
in that statement, but if you just take it at face value, it's
still impressive. So hey, well done, Apple.
You know, we talked about kind of doom and gloom sometimes in
cybersecurity a lot. It's great to acknowledge where
we're getting things right and where things are going well.
So well done to them. OK, so on to our second topic or
second and final topic here. There was a lot of talk about
this whole phantom device attack, so let's kind of dive
into it before we get started. This deals with something called
the PRT, which is the primary refresh token.
So I want to take a few moments to just talk about what the PRT
is. Essentially, it's an extremely
powerful authentication artifact that is in Windows or Azure.
It's like a master key to your identity.
And so when Windows, when a Windows device is joined to
Azure AD or Enter ID today, it gets issued a PRT.
That token is then. Hold on, before you go further,
I want to clarify because the way you worded it is open to
interpretation so I'll just be crystal clear.
PRT supply both to hybrid join as well as enter join devices.
Both scenarios you get PR TS issued to the device.
So if you are hybrid joined, which if you're not familiar
with means you're still on premises domain joined to Active
Directory domain services and then you also have kind of a
registration, not a full join to enter ID as well.
That's hybrid join. And then there's also just enter
join, which means your primary and only device identity is tied
to enter ID. There is no relationship with
Active Directory domain services on premises, it's a cloud joined
device. Effectively both scenarios get
PR TS. Just wanted to clarify that
continue. Correct.
So what I should should have said it's it's also if an ENTRA
registered device happens because ENTRA registered devices
also get PRTS. So it's an artefact that lives
anytime you've authenticated successfully on a device to
ENTRA, whether it's joined or or registered, the device will get
a PRT. And so that that's issued, it
sits on the device is then used to obtain access tokens for your
cloud resources like Office 365, SharePoint, Azure, so on and so
forth without you having to re authenticate each time.
Very different than like a browser because it's it's
similar to like a token that gets issued in the browser, like
a session token, which then you would exchange for access
tokens. But this one sits at the device
level so specific to Windows. And it's the mechanism that's
that really is responsible for single sign on across any
Microsoft service on a Windows device.
The PRT does carry a cryptographic device claim.
So it says like this is access coming from a trusted compliant
device. Conditional access policies can
use those claims to decide whether or not to allow access
or deny access. And in a normal, healthy
environment, the PRT is hardware bound, which means that it's
stored on the TPM chip, which makes it extremely difficult to
steal or fake. So the problem here is what
happens if you can generate a PRT for a fake device.
And I'm going to nitpick one thing.
A PRT does not say a device is compliant.
OK, that's fair. This is where like being precise
with the language matters and we'll get into this more a
little bit as we go through it. Sometimes there's misconceptions
around a registered device, a recognized device that's part of
our organization is not equivalent to is compliant and
we'll we'll unpack that later. But I just want to put him pin
in that one point. APRT could say this device is
from your organization and you can trust it, but it doesn't say
this is past point in time at a station right now.
All of these variables that you're looking for are set to
this way. The PRT itself doesn't do that.
So we'll, we'll unpack that more in a moment, but I just want to
put a pin in that point. And it's, it's easy to slip on
the language there and, and we'll figure out, you'll
understand why in a little bit. So it's a little teaser for us.
We go through the rest of this. Yeah.
Thank you for that call out. That is absolutely correct
there. OK And then the other thing I
wanted to touch on is device code flow because that was also
abused in this attack. So if you haven't heard about
device code flow, just a real quick explanation of what that
is. It's Oauth 2.0 authentication
that originally was designed for devices that can't easily
display a browser or accept keyboard input.
So a really good way to just understand this is like when you
authenticate to Netflix for like your Apple TV and that has like
a QR code. Disney Plus, Paramount Plus,
Hulu, you name it, all of that. HBO Max, all of them
authenticate with that. Device code flow, Yep.
And so that also works for Microsoft because like, you
know, there used to be like Surface devices or really any
device, there's like a, there's a Oauth standard that allows you
to authenticate to Microsoft services on a device that you
can't type or you can't, you know, have a browser display so
that you can go login. So for example, then you can
like generate a short code and say go to
microsoft.com/devicelogin. Then they go to their phone, you
know, go to that and bring up the browser and then it flows
that authentication over to the device like the TV or signage or
something. But then we'll log them in.
There's a security risk to this because this flows target from
the device registration service endpoint rather than the
standard token endpoint, meaning conditional access policies that
normally guard the logins on the device don't automatically
intercept it on the new device, that is.
And then secondly, it's heavily abused in phishing.
So an attacker can generate the device code themselves, then
send a convincing e-mail to a victim, and then the e-mail will
then the victim will then enter the code thinking that they're
verifying the account, and the attacker's machine then receives
the access token. So in this attack that we're
gonna be talking about, device code flow was the pivot where
the authentication path that conditional access wasn't
blocking, which then opened the door to everything else.
So let's talk about the attack chain and why everyone was like,
well, conditional access was bypassed and you know, there's a
bug or whatever it is, right? And so there were some
researchers from Holler sell Sideris that conducted an
authorized red team operation against a production tenant with
over 16,000 users and 78 conditional access policies.
They did start with a single set of valid credentials.
So that's kind of important, which is usually the kind that
is available on a criminal market or something like that
for a few $100. But with that they were able to
achieve full global administrator access.
And how did they do that? Well, first they, they tried the
direct authentication, they tried the stolen credentials,
which was blocked via conditional access.
So that did it's job. But then they pivoted using
Oauth flow. So the the standard resource
owner, now password credentials ROPC grant was also blocked.
But the device code flow which targets the device registration
and service endpoint rather than the normal token endpoint was
not intercepted. So the tenant that they attacked
actually did have a policy specifically designed to block
device code flow. This is part of intra
conditional access. There's a check box for device
code flow and you can just check that as a condition and then the
access you can block. But in this case it was sitting
in report only mode, so it logged the attempt, but it
didn't do anything else so the token was actually obtained.
Coincidentally, this is also kind of the same entry vector
that Storm 2372, which is a suspected Russian state aligned
threat actor has been exploiting at scale since August 2024.
And they target governments, defense contractors, healthcare
and critical infrastructure in Europe and North America.
So once they had the valid token.
Let's just pause there because I, I'm going to, yeah, every
time you go through these, I'm going to pipe in and say, OK,
device code flow should be blocked.
If you are not blocking it for every possible scenario except
carve outs for only the scenarios where you must leave
it enabled, go and do turn off this podcast.
Go and block it right now. Like listeners, like I'm going
to keep jumping and I'm like, this is bad.
Go fix this. Here's your first one.
Device code flow blocked unless you must have it and only
allowed for scenarios you had it, had the organization done
that. And this is in Microsoft
documentation. This is documented as Microsoft
recommends you disable this. The attack does not continue.
So there's your first chance to prevent this attack.
Continue, Andy. OK.
Yeah, thanks. Thanks for jumping in there.
Yeah. Well, I just want to hit them as
we go instead of after in this case.
Great, I love it. So once they have that valid
token, because, you know, device code flow wasn't blocked, they
were able to hit the Device Registration Service API and
that's called the DRS. The DRS validates the token, but
it does not verify that the caller is a real Windows
machine. So it's just the token itself.
And so using a single command on a Linux laptop with no physical
hardware, no TPM chip, no admin approval, they were able to
register a completely fake phantom device.
So enter ID issued a fully signed certificate and private
key indistinguishable from legitimate corporate endpoint.
So what should have happened is, you know, in general you can
enable MFA for device registration, so.
If I try to register a new device under a user, it will
prompt me for MFA and the users. This organization again had a
policy requiring MFA for device registration, but again it was
in report mode, report only mode, so it logged the
registration would have blocked nothing.
OK, here I'm jumping in again. You just hit it, but I want to
clarify this point a little more.
There is a setting, an enter ID where you can say require MFA
for device registrations to do an enter ID registration or an
enter ID join. That is the second layer of
protection. The first layer should just be
you don't allow anyone to authenticate ever without multi
factor authentication. So to be clear, Microsoft's
guidance is absolutely you should do MFA 100% of the time
no matter what. And if you're going to ignore
that, then at least let me implore you require MFA for all
device registrations. Somebody should not be able to
enroll a device with just a username and password.
That should never ever be allowed.
And so there is your second opportunity to block this
required MFA org wide or at a bare minimum, if nothing else,
if you can't go get MFA deployed tomorrow, turn on MFA for device
registration tomorrow. And I don't care if you break
stuff at that point like it should absolutely positively be
on. There's your second chance now
to block this attack. And while this doesn't
necessarily block the attack, it does give some warning, which I
would say just as a like a sub bullet here, you should have
some sort of notification when a new device is registered under a
user. So at Microsoft, whenever I
register a new device, I get an e-mail and my manager gets an
e-mail. And it's standard security
practice now to, for the manager to verify, obviously, like I'm
a, I'm a, you know, security technical guy.
So I'm tinkering with devices and joining them all the time
and re wiping. And so my managers getting these
emails, I just normally preemptively like send them the
e-mail and say, Hey, this was me on a Saturday, just, you know,
re wiping my device or whatever, right?
I explain what it is too. I give a little context.
Yeah. And so, but if if I don't say
anything that the standard SOP is for the manager to e-mail the
employee and say, hey, what happened here?
Is this you? So that's just kind of another
checks and balance type of deal. And in fact, I think it was
what's the security company that Google acquired that does all
the. Mandiant.
Mandiant, yeah. So Mandiant I think was hacked a
few years ago or something like that.
And the reason why they even went into the investigation was
the attackers registered a device and they had an e-mail
sent to that employee and the employee was like, I didn't
register a device. And they kicked off the
investigation and that's how they found out that they were
hacked. And so this is this is important
here. So obviously require MFA and
then a sub bullet. Even if you do that, you should
have some sort of notification which would might trick up strip
some flags that you would know. So now that they had the phantom
device certificate that was issued, the researchers were
able to request a primary refresh token, the PRT, which
emulates what Windows does during a normal user sign up.
And that PRT was then they saved it in a plain text file on the
Linux desktop. So when they exchange for an
access token, the token carried the the user, the password and
the device ID claim, which was the cryptographic proof that the
conditional access uses to evaluate device trust.
Those same credentials were then triggered on a direct login,
then sailed through every policy required compliant or enter a
joint device. So I I want to pause there.
Yeah, I knew you wanted to. Because and and I read the
Sedaris report. And by the way, this has been
reposted and paraphrased by all these junkie cybersecurity blogs
with a billion ads on them. I went and read the actual HOWL
or cell report, and this part is a little unclear.
But this is where I want to add a little more commentary as well
because I think I know what happened here and they're
playing a little bit with the language, I think, and being a
little imprecise. So I'm going to be very precise.
There are two options when you configure a conditional access
policy that are relevant in this case.
There's more options but I'm focusing on 2/1 of them says
require hybrid join device, one of them says require compliant
device and those seem very similar and they're even right
next to each other on the list. They could not be more different
and this is what I was earlier in the conversation.
Require hybrid join device is just looking for that primary
refresh token with that cryptographic proof of device
trust that the device is hybrid joined.
So all it's checking is are you and does the device respond and
say yes I am joined to your domain and I've received a
primary refresh token I am a trusted device.
It is explicitly not checking the device compliance that is a
different thing. It is point in time attestation.
It is substantially weaker from a trust perspective then require
compliant device. So just want to put that out
there. I believe this tenant was
configured for that based on my read through of the Howler cell
report. It's a little unclear, but I
think the tenant was configured for require hybrid join device.
I don't believe it was set to require compliant device because
require compliant device. What that is looking for is, is
this device enrolled in Intune? Is there a compliance policy
assigned to the device? Has it successfully completed
the compliance policy? Does it show all green check
marks effectively? Often times you can configure
there to be some sort of grace period where the device won't
get kicked off if it's not compliant until a certain number
of hours have passed. You allow some time for
evaluation of that compliance policy to complete when a device
is initially enrolled. They don't talk about that at
all in this reporting, but that certainly could be a risk as
well where a device gets enrolled and is able to do
something before it's determined, hey, this isn't even
a Windows device, this is Linux. Like what's going on here, But
compliant device is the one that will look for like what is the
current risk profile defender for endpoint?
Is BitLocker enabled? Is the password a certain
length? Is the version number this or
greater? Is this feature turned on?
Is that feature enabled? So on and so forth.
That's what a compliance policy is.
So I believe what they're saying here, and again, this is
unclear. This tenant was not configured
for compliance evaluation being required to authenticate.
It was configured for hybrid join.
And a lot of people in their minds see those as these are the
same thing. They're not.
The other thing I want to point out, and this also trips people
up all the time, there is no conditional access policy for
require, enter, join. There's no way to check for that
at all. Maybe there is a way to check
for it, I shouldn't say in speaking such absolutes, but
from a conditional access perspective, that's not what you
look for you at that point if it's enter joined, you're
checking the Intune compliance and enter join.
Remember that's the fully cloud joined model, not that hybrid
model where you have the on premises join and the cloud
registration component. So that's what I think happened.
Little unclear. Andy, you can go through the
rest of the story, but I think also potentially now this is
where there's little shade of grey.
I think an opportunity to harden your posture because most
organizations today, I think are still configured for require
hybrid join device, whereas I would much rather see you
require compliant device. Compliant device is ongoing
point in time attestation. That device could be healthy and
then it could become unhealthy. And when it becomes unhealthy,
it gets evicted from the tenant. You know, temporarily like you
lose your access until you remediate the thing that's not
compliant. So it's much more powerful
versus point in time attestation.
At one point we trusted this device.
And by the way, a lot of competitive ID PS I'm looking at
an octave direction. They're all point in time at a
station. Their device trust model is I
have dropped a cert on this device.
I now trust it forever. As long as that cert is there, I
don't really care about the health of the device.
And that's where Entra and Intune are differentiated.
Is that ongoing at a station? But a lot of orgs even to this
day still are not available availing themselves to it.
So even if you're still like we're still a configuration
manager shop SCCM till it the heat death of the universe,
fine. You can still enable Co
management with Intune and you can still delegate some
compliance checking to Intune, or you can still keep compliance
checks in configuration manager and just make Intune aware of
them with Co management as well. There's different options for
configuring that, but either way you should move to this model of
looking for compliant device as opposed to just point in time at
a station. At this point, there's really
kind of you're running out of reasons not to, but it's it's
unclear, but I'd be willing to bet if this tenant were
configured with require compliant device, this also
potentially stops this attack here.
That's my opinion. That part's a little unclear and
it's because most people are just not super fluent in the
minutia and differences here. But you, dear listener, now are
because you listen to the Blue Security Podcast.
Yeah, I looked at multiple reports on this and what you're
saying is correct. And I think the reason why it's
confusing is because a lot of the reporting uses the word
compliant and how I minced it in the beginning.
Just like like you're when you use the word compliance, it
means there's a compliance policy.
But if you are just checking for a hybrid joined, that doesn't
actually trick trigger a compliance check.
It just checks the conditional access policy and it says, Hey,
you're good here and you're good to go.
I, I like to equate that to, I use like an analogy of like a,
like a concert, right? Like I'm checking my
credentials, I have a ticket, I go into the concert and that's,
that's it. Like that's the, that's the
hybrid join. I, I check to see if I have a
ticket, I'm in. That's it.
The compliance check is like, OK, well, now I'm inside the
concert and I try to do some bad things, right?
Like maybe I get too drunk. Well, then the security guard
comes and, and says, hey, you're, you're doing some bad
stuff. I'm going to toss you out.
And so that's that continuous attestation, which is a
compliant device where we're continually checking like, hey,
OK, you're a little bit drunk. OK, that's fine.
You're low risk right now. But all of a sudden you, you
start to get really, really drunk.
Now you're high risk. OK, now we're going to kick you
out. Right.
I like the analogy. Absolutely perfect.
Yeah. You scan the ticket, you're in
like we let you in. And and if you're at, you know,
some festival where they're not really enforcing much of
anything, but that's basically what require hybrid join is
doing. You have a ticket, you're good.
And, and I have no doubt based on everything these folks have
reported at Sedaris and Hallersall, I have no doubt they
were able to mint a PRT that said, yeah, I'm hybrid join, let
me in. OK.
You know, that's, that's why that's a weaker control and it
shouldn't be your only control. You should be full fully aware
it's a weak control. And, and this is where, you
know, bigger picture, just thinking about where do you
invest your effort from a cybersecurity perspective?
And you know, we, we need to finish walking through the, the
tech chain. So I'm sorry for jumping in here
and going on a tangent, but if my guidance to you is require
MFA for device registration, disable device code flows, you
should really move away from hyper join and move to cloud
join. You should really move to Intune
compliance check as your entry ID conditional access policy.
How much effort do you go spend engineering like ways to ensure
that it's a Windows device that is stating that it's doing these
things? How much engineering effort do
you go pour into that because it's all opportunity cost.
If you're doing that in hardening a scenario that I have
advised you is not a high confidence, high security
scenario, that is opportunity cost away from investing in
modern attacks that can hit even well configured, well managed
tenants where they're doing everything right.
And I think I'd rather have it over there where you're, you're
defending against state-of-the-art attacks, not
attacks where you've left, you left the back door open, you
left the key under the mat, you did all these things you
shouldn't do. And then I'm trying to like
build additional barriers there. I don't know if that makes
sense. So you know, I get you can
nitpick some of this and be like, well, the device
registration service shouldn't do this now it probably
shouldn't, you're right. But how much engineering effort
do you put into that when really we shouldn't have anyone
enrolling devices that we have not done 2 factor authentication
on kind of thing. So anyhow, let's continue with
the attack chain here. Yeah.
So one thing that they did after they had the the PRT token
claimed the device claimed they ran a tool, a road Recon which
was able to enumerate the entire tenant.
So they were able to enumerate all the users, the groups, the
devices and also all the full conditional access policies
which they were able to see that there were 57 policies enabled,
14 in report only mode and seven disabled.
And two of those report only policies which we talked about
would have stopped this attack in its tracks.
And possibly maybe my 3rd 2. Right.
And so they did, you know, this is where the, the reporting and
kind of the nuance kind of meet where they talked about
defeating into an MDM compliance.
But we, we kind of went through that where if it was requiring
compliant device, that's actually a little bit different
because if you're just requiring hybrid join, which they did
here, you basically bypass the any type of compliance policy
check on the Intune side. That's different.
If you were using like Mecum or something like that and you had
a compliant check there and it's being managed there.
But this is again, where there's a nuance of hybrid join is
essentially an on premise join device.
It is a domain join device. It is not a cloud device.
And so that gets into also some of the, the, the later attack
here, but you can't require an into.
I mean, technically you can, but if your CA policy, your
conditional access policy is just requiring hybrid join, then
it doesn't actually check a compliance policy.
So you know, there, some of the reporting says they ran a
compliance check and it does all this querying and making sure
the stuff is enabled. But if it's just hybrid join and
that's all you're requiring, it doesn't look at a compliance
policy. Or maybe they have it configured
where it was in conditional access policies.
Who can do and OR logic? You can pick do I want and
logic? Do I want or logic?
Possibly they had it configured for OR logic where it is either
hybrid joined or compliant with Intune.
And they're like, well, we're solving both bases.
You know, if someone is, is hybrid joined and on premises,
you know, then they get in and if they're cloudy, then they get
in this way again, that's where I articulate that's not good
design and you don't want to do, and if you're starting to move
to some enter join devices because they're not hybrid join.
So then they would fail that policy.
And I get that. But that's where the, or is the
risk of, well, I can just say I'm hybrid join and I can opt
out of it. And, and I bet that's how it was
configured because they do talk about how in Intune, when it ran
its compliance check, the device just said, well, that doesn't
apply to me. And then it was able to instead
of being labeled non compliant, it was just not applicable.
And if that is true, if there's a way to get to this point and
trick in TuneIn that way, maybe that should, should have some
potential redesign down the road.
Again, it get you get down the path of maybe it's more
important to put the security earlier in the chain, right.
If you're already this far down, you're better off hardening
earlier in the attack that often times Microsoft will take that
stance. There's been some other examples
recently where there have been reported disagreements on
software development. I'll just say, and the Microsoft
response has been, yeah, by that point, it doesn't matter.
Like it if it's that compromise, yeah, we're not really worried
about that scenario because it is so far down the compromise
chain. The solution is prevent the
compromise here, here or here before you get to that point.
At that point, you know what? What's, what's the point here?
So there could be some of that going on too.
So, you know, I think you'll hear more reporting.
As of Friday afternoon, there were not any talking points
posted on this. I'm on our internal forum.
The final thing that was kind of the the killing blow was as part
of the enumeration, it exposed A structural misconfiguration
which is very common in a lot of hybrid environments.
There were 255 on premise Active Directory accounts that held
privileged directory roles in the cloud, including two global
admins and a privileged role administrator.
This is something that Alex Weinhardt put out a blog back in
2020. So this has been standing
guidance for almost 6 years now. Do not sync any on premise
accounts in privileged roles to the cloud.
So your cloud accounts should admins should be separate cloud
admins, your on premise privileged roles like global
domain admin and you know whatever should also be just on
premise accounts. And so one of those
misconfigurations could also include because it's hybrid
joined and it is a domain, you know joined device you're
authenticating using domain accounts and so and those
accounts get cached whenever you log in.
So they might be sitting as cached credentials on the device
itself. But either way this has been
standing guidance don't sync privileged roles from on Prem to
the cloud. And so they did that and so
really they were able to compromise 1 synced on premise
privileged account, then assign the privileged authentication
admin role to the attacker controlled account, use that
role to reset a synced global admin password, then sign in as
the global admin and down they have complete tenant takeover.
So, you know, a lot of different things went wrong here, but I
think this is a pretty common scenario for a lot of
organizations out there. So you made me think of when you
were just talking about that and absolutely.
So again, actionable guidance, we're all about it on this show.
What is your actionable guidance?
No privilege to sync accounts. All of your privileged accounts
should be mastered and enter ID in our cloud only.
But while you were talking about that, you made me think of
something else to something else is actually I kept mentioning
there are multiple ways to stop this.
The one like assumption that all of this conversation had that we
didn't even touch on Andy was that the user's password was
compromised. We just assumed that it's a
stipulated fact of this whole attack chain.
Well, let's talk about that for a second.
Couple of things. Number one, you can enable
password hash synchronization and with enter ID protection, we
will notify you if we find those credentials leaked on the dark
web, send you a high, you know, high confidence alert.
And you can configure so that the next time the user signs in,
they're automatically forced to self remediate by doing a
self-service password reset and providing 2 factors that are not
their password to reset that password and eliminate the
compromise. OK.
It's not clear if that was done or not, but just so you're
aware, there are ways to remediate and prevent that
because a lot of this conversation is, ah, you know,
passwords are a dime a dozen on the dark web.
You can buy one for 50 bucks, maybe not even that much.
Sure, there are ways to help mitigate that.
The other thing is, you know, if your users just don't use their
passwords very often, they're really hard to get fished.
I, I know you're sick of hearing this, dear listeners on this
show, but literally, if you try to fish Andy and I on our
Microsoft corporate credentials, you can't because I don't know
what it is. I haven't used my password in
years. And now we've completed the
migration to fish fish resistant MFA to where I never, I mean,
I'm done putting my password because you cannot sign into
stuff without fish resistant MFA.
It's a requirement. So there's your other
preventative stuff. If your users don't know what
your password is, it can't get fished.
And none of this attack happens because that was like the whole
assumed first step. And I forgot about that part.
Like if you are password list also, all of this risk goes
away. Like there's your like third or
fourth possibility to block this as well.
And I forgot about that and you brought it up at the very end.
So I'm sorry I'm hitting that late, but it's also an important
point. This whole attack chain just
starts off with, well, we have the user's password.
Yeah, you know, OK, it's even, we've taken it even a step
further in the fact that like I used to have my Microsoft
password stored in a password vault, my corporate password,
right. Like I, I said it day one and I
haven't looked at it since they released something to us that
said, hey, we're taking a step further.
We're just going to change your password to some random, you
know, 9000 character password in AD now and and you won't even
know it. But they did that.
I never saw that. Yeah, yeah, that there was a
message that came out and they just said, hey, oh, and by the
way, like you don't need this anymore.
We're just going to change it to something crazy that you don't
even know. So I won't ever know my on
premise password ever again at Microsoft.
OK, well, there you go. I mean, but it's just funny that
that was so assumed of like, well, of course we have their
password. Like, you know, Oh well, what
can we do about that? Boy, I don't know, what can we
do about that? All of this stops if you don't
have a password to get fished too, by the way.
So again, Speaking of like, where are we investing our
engineering resources? Well, where are you investing
your engineering resources listeners, you know, and and IT
shops around the world because I've kind of taken this attitude
of and, and I, I'm not saying this to be snarky, but when
customers knock on my door, like, Hey, what should I do
about this thing? Like, have you rolled out fish
resistant MFA? No, OK, why don't you put your
effort there? Like it's, it's my like almost
knee jerk answer to everything. Roll out fish resistant MFA.
That's the answer. Like it solves so many things.
Just I I know it's hard, that it's worth doing.
There's no bigger bang for your buck.
Anyhow. I get on the soapbox all the
time. I'll stop.
Yeah. So just to wrap things up, we
kind of went through this as we talked about the attack chain,
but some actionable insights #1 enforce conditional access
policy to block device code flow #2 require MFA for ENTRA device
registration. Number three, don't sync your on
premise users into privileged cloud roles #4 obviously do an
audit of all of your conditional access policies.
Anything that's in report only mode.
That's all it is. It's just going to log the
attempt. So make sure that if it's
something that you want to enforce, start enforcing it.
Do a test group, roll it out, and then turn it on for all of
your users. If that's something that's in a
critical category, like one of these two things that should
have been done here and then #5 start requiring compliant
devices. So use instead of the hybrid
joined in conditional access policy, force device compliance.
Now that will, if you're kind of still in the hybrid join phase,
that may take some time, but that's something worth what like
I'm saying, it's worth your engineering effort.
It's worth your time to move to that because it is continuous
device attestation rather than hey, you have a hybrid joined
device and that's it. Well, and it's reusable.
It's reusable when you move to requiring device compliance as a
hybrid join device, guess what, that's your only option when you
move to cloud join anyway. So you would have had to do the
engineering effort then. So it's not like it's dead end
engineering effort. It is future state engineering
effort that you get to do early and then you pull that effort
out of the project to move to cloud join, which if you're, you
know, you need to be doing this well, but that way a lot of orgs
get really wound up. And it's, it's one of the first
shows we ever did and we did several on it.
Andy, early in our, you know, our 2020 years on the show, we
talked about enter join devices and people get wound up and make
it more complicated than it is pulling that effort forward on
getting to device compliance chucking as part of your CA
policies. Doing that early is a great move
because that is not complexity with the cloud.
Join, move to enter, join then, and then when you do that, it's
an easier lift. So I actually recommend doing
that. It's the right order of
operations. All right, a lot of information
here today. Hopefully you stuck around cuz
man, this was a great show overall.
So thanks for listening and watching.
As always, our contact information along with the links
that we used for our notes and our show 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.