Subscribe
Share
Share
Embed
Threat Talks is your cybersecurity knowledge hub. Unpack the latest threats and explore industry trends with top experts as they break down the complexities of cyber threats.
We make complex cybersecurity topics accessible and engaging for everyone, from IT professionals to every day internet users by providing in-depth and first-hand experiences from leading cybersecurity professionals.
Join us for monthly deep dives into the dynamic world of cybersecurity, so you can stay informed, and stay secure!
You introduced a new feature
that should make things more secure.
However, with this new feature, you
introduce new security vulnerabilities.
This is exactly what happened
with Bad Successor.
In today's episode of Threat Talk's, a Deep Dive,
we dive deep into this vulnerability.
Let's get onto it. Welcome to Threat Talks.
Let's delve deep into the dynamic world
of cybersecurity.
So with me today is Luca Cipriano,
our CTI and Red Team program lead.
Welcome to the show.
Thank you.
And my name is Rob Maas,
Field CTO at ON2IT.
Luca, this attack all evolves around
domain controllers and service accounts.
Before we get dive into the woods,
about everything involved,
what is a service account?
Yeah.
So a service account is an account
- think about a user account
you will have in your company
your account as a user.
Services, they have the same.
So if a service needs to
perform operations,
they will use a service account.
Think about an SQL service.
They will have an SQL service account.
And that's the account
where you, of course,
you set up the password and you set up
all the permissions that that account has.
If, for example, it needs
to perform operation
on disk or communicate
with processes.
Okay.
But good to mention here is that
the service account is specific for a service.
Yes. But acts like a normal account.
So it has a username, password.
Yes. It's similar to the normal account
but it acts for services. Okay.
Because the new feature introduced in
Windows Server 2025 is the DMSA
account, service account.
Can you explain what the DMSA stands for?
Yeah.
And what it is? That stands for
delegated managed service account.
And it is something that they created,
because well, Windows, Microsoft,
they created it, because
they wanted to improve security
on a normal service account.
Back in the days when you
created your service account,
you had this account,
you created a really long password.
Or maybe you just kept that
password always, for a long time.
With DMSA, they wanted
to create a way to migrate
those service accounts,
to a managed service account.
So in that case, for example,
the password will be automatically
generated, the password
gets automatically rotated.
And also, the retrieval of the
credentials via Kerberos.
So you don't have configuration files.
And also, I mean, this way they aimed
on improved security hygiene.
So this sounds like a lot of good things
when it comes to security.
Yes. So it's improved..
It should be an improvement.
So I want to migrate immediately,
of course, to these DMSA accounts.
How does it work?
How do I do the migration?
Yeah.
Well, so, first of all, you need to
create this DMSA account, right?
Then once you create the DMSA account,
you need to tell to the DMSA,
what is the successor for,
for the service account,
let's say again, the SQL service.
So you say that this going to be the
the new service account
for the SQL service that we had before.
And then you need to initiate
the migration. The migration,
basically what it will do, it will
transfer all the permissions,
the SPNs, all the details of that service account
to this new managed service account.
And once the migration is completed,
it will disable the old service account.
And the service will start
o use this DMSA instead.
DMSA can be used by one or more machines,
so it can be delegated to several machines
if the service needs to be used
by different computers.
And then, at that point,
basically the migration is completed.
Okay.
So, if I explain this in, for me
at least, simpler steps. Yes.
Is it like migrating a phone?
So I have a new phone that needs
all the settings of the old phone,
but while I'm migrating,
the old one still needs to take calls.
Yes. So I install an application.
I do the migration.
Once the migration is done,
everything is on my new phone.
And automatically the old
phone will be disabled?
Yes, exactly.
So you can receive your phone calls
and use it until the application has
completed the migration.
Okay, so and apparently in whole
this process, there was a vulnerability.
Or maybe there is.
Yes. Well, it has been patched.
But we'll talk about that later.
Bu yeah, there is a vulnerability.
So, first of all, in order to
exploit this vulnerability,
the victim organization needs
to have at least one,
Windows 2025 server used
as a domain controller.
So these are the prerequisites.
So we are now talking about the attacker,
exploiting the vulnerability.
Yes, indeed.
And the first prerequisite is a
Windows Server 2025. Exactly. Yes.
Are there any other? Yes.
So, in general the migration
can be completed
only by an administrator.
And only an administrator can create the
MSAs into the service account container.
But if the attacker controls the domain user
that has privileges like create all child
objects within any OU,
they can create a DMSA
in that specific OU.
So that is something that they need too.
Okay.
A lot of terminology here. It's a complex.
Yeah. So what are OU?
So OU is an organizational
unit and is mainly,
it is like a container,
where you can create within,
for example, users or computers accounts
or service accounts, this kind of thing.
So you can compare it a bit
like a folder on a Windows system.
Yes. Exactly.
A folder that contains
all the users. Okay.
And then the second term
you used was child objects. Yes.
That means that that specific user
can create objects, such as,
for example, users within OU,
or within an organizational unit.
Okay.
So as an attacker, I need to
have access to the domain
controller, or at least within
the domain you need to -
You need to have a domain user.
A domain user, okay, a domain user,
which has to create child
objects permissions.
Yes. And it should be then a Windows
Server 2025, the domain controller.
At least one of the domain controller
within the organization. Okay.
So let's assume I have that I have
these rights and I have that account.
What are the next steps I then take?
Yes.
So it is similar to what we explained
before in the normal process.
But this time you create the DMSA,
in the OU where you have the
right privileges.
And what you need to do at this
point, you need to just change
the values of the attributes of the DMSA,
to tell, of course, which user
this DMSA is the successor for.
And then you just need
to change the attribute
that is related to the migration
to number two, which means
migration completely succeeded.
So you don't need to really
start the migration, but
you just need to change the attribute
as if it was migrated already.
Okay.
And that means that the
attacker, if I have these
create child objects, is enough
to create a DMSA account.
Yes. When you have create child object,
you can create users
and you can create also,
for example, a machine user.
And that, we’ll see later,
that you can use it to retrieve...
It that very common, that let's say
normal users have these permissions?
So this vulnerability was found
by researcher Akamai, and they
have estimated that 91%
of organizations have
unprivileged user with
this kind of privilege.
That sounds like quite a lot.
Yeah. It’s quite often.
So if I take it back to my previous
example with the phones, that more
or less means I can buy a new phone
if I have the rights to it.
Yes. Which most people will have.
And then I just pick a random phone
that I want to migrate,
maybe I want - Like mine, for example.
Yeah, for example, your phone. Yes.
I start the migration.
I don't have to, but I can also say,
I'm done with the migration-
You don't actually do the migration,
but you say, hey,
the migration has been done,
and then you get all all the privileges.
So it sounds like a very easy attack.
Yes. Because, in general, also as an
unprivileged user, what you will do,
you will point that your DMSA
is the successor of a domain admin.
Yeah.
So you get all the right. And then you get
all the rights of the domain admin.
Okay.
So, I assume this, everything
worked out correctly.
So I have now a new
managed service account.
With administrative privileges.
Is there anything else I need to do?
Well, like, for example,
if you want to do,
if you want to perform an attack and
actually do something, you need
to request the tickets, for example.
So one of the things is also that,
of course, you have generic writing on the
OU and these kind of accounts
are used by machines.
So you're going to, you will have
createda machine account that has
the rights to retrieve the credential
from this service because, of course,
machines accounts use those services.
And then you can request a TGT,
so a ticket granting ticket, to the KDC,
which is the key distribution center
of the domain controller,
and then you will get a ticket
that has the domain admin in this case,
because my DMSA
is the successor of the domain admin.
Yeah, and you need to create this ticket
because, with the new service accounts,
they are more secure, they have
a rotating password as you said. Yes.
So yeah, maybe you can guess
the password, but chances are really low.
Really, really low. But so in that case,
you can just use a ticket, load it
in memory, and then you can
perform action as a domain admin.
So if you have the ticket, you can do
everything as an administrator.
Yes, indeed.
So, with the TGT, then
the ticket granting ticket,
you can request TGS,
so you can send the
ticket granting service requests,
and then you can access services
with the target user privileges.
It is a bit like, think about,
you go to the...
About the TGT, is like think about
a hotel, like you go to a hotel.
It's all inclusive.
And then they have like,
for example, a spa or a gym, etc.
and then you go to the reception
and you ask a TGT, so you get
one of those wristbands
that they give you, so
they know that you are part of the hotel,
that you're guests of the hotel, and then,
the TGS is like, with that wristband,
I go to the reception
and I get another wristband
that it tells me, hey, I do have access
to the sauna or to the wellness.
And then with the TGS,
I can go to the wellness.
Okay, so instead of showing my
password every time or showing
my order - Exactly. - The wristband is enough.
The wristband, that is my ticket.
And they know that I have access there.
As you already mentioned, briefly,
is that Microsoft did patch this problem.
Yes. But you also mentioned a bit
that there are still post patch problems.
Well, I mean, yeah, they're a bit limited.
So, but still it can be abused.
So Microsoft patched this one, and now
a full migration needs to happen
for the DMSA to be actually taking
all the privileges from the,
well, become the actual successor.
So it's not a one way anymore.
But, also the target needs to say
that it has been migrated.
So at this point,
the attacker needs to have
the right privileges on both
the DMSA, but also the target.
So in this case, if I want to do
like a domain admin, then
I will need to have the right access,
right permission on the domain admin.
So that makes it not so bad anymore
because I need to control,
both the users that I want to migrate.
If I compare this with the phones
and I want to migrate your phone,
I can say on this end, it's done,
the migration is done.
But I also need to do it on your phone.
Well, yeah, you can, indeed,
well, it needs to actually happen.
The migration.
You need to really actually
perform the migration.
Before you could only
just change the value.
But now you actually need to
perform the migration. Okay.
But also I need to check it on your phone.
That is is done.
That it’s been done. Yes.
And, this, of course, it will limit
the impact, but it will still
create some kind of stealthy attack path,
because like, for example,
what you can do inside,
if I have generic right on your user
and I want to get, for example,
something that you have access to.
At this point, I don't need to reset your password
or do something that is a bit more noisy.
But I can just do this migration,
and then I get the same privileges.
So if you have permissions to do so,
then, it's quite silent.
It's a bit, it can be a bit more
stealthy, in general. So.
Okay.
So we now know all the
steps involved, what...
And we also know that the attacker needs
to have kind of an initial access,
or at least a user account
within the domain.
Yes, it's a privilege escalation path, so.
How can we defend against this?
Well, of course, the first thing is, patch it.
Because then the impact is very limited.
So, install the patch.
Of course, try to limit the permission
of the users who can create
child, objects, you know, does your
user really need to do that?
This is something that-
Yeah, you said a very high number,
but I can imagine that
most users don't create
other objects within the-
No, in general. No.
So limit the permissions.
And then also the person that can
create and modify the DMSAs,
in the OUs that we talked [about] before,
and of course,
one thing that you can do
always is, logging and alert.
Of course, you can get
logging on the creation
of new DMSAs, because I
assume that you're not going
to create DMSAs on a daily basis anyway.
Or on the changes on the attributes.
So create some logging that alerts
you on the changes off the-
Yeah, so that if it is being used,
that your SOC
or at least someone gets informed-
Gets an alert that somebody created it,
or somebody changed the
values or the attributes.
Yeah.
And then, while it's not
part of the attack itself,
you should also try, of course, to limit
the attack to your domain controller, to
your environment for external attackers.
They already need to have a user account.
I mean, they need to have domain user, so.
They are probably already somewhere inside...
They have a user. So they have initial foothold.
Okay.
Would you say that Bad Successor is now
maybe the biggest Active Directory attack
that you have in your toolbox or?
Well, I mean, well, first of all,
it affects the Windows Server 2025.
I mean, you need to have
one as domain controller.
So it also depends on
how many companies have
a Windows Server 2025
as a domain controller.
And of course, it depends on how many,
well, companies have patched the issue.
But for sure it is, a really, a relatively
easy and fast escalation
could be to domain admin.
So it is, for sure, a good tool in the toolbox.
Yeah, so an extra tool in your toolbox.
Yes, indeed.
Okay. Yeah.
With that, I think, we can come
to an end, at least on Bad Successor.
Yes, indeed.
So for you listeners, as
you just heard from Luca,
if you have Windows Sserver 2025,
make sure that you have patched
the system and also make sure that users
don't have access to create child objects,
that will really limit the attack
surface for this specific attack.
And with that, I want to
thank you for tuning in.
And if you like what you saw,
then please like and subscribe.
It helps us spread the word further,
and I hope to see you next time.
And with that, thank you, Luca. Thank you.
Thank you for listening to Threat Talks,
a podcast by ON2IT cybersecurity
and AMS-IX. Did you like what you heard?
Do you want to learn more?
Follow Threat Talks to stay up to date
on the topic of cybersecurity.