Hi.
In this video course, we're going
to talk about Kerberos Delegation.
And Kerberos Delegation is a massive topic on itself.
We'll need really days to cover it completely.
So what we want to achieve with this video lesson,
is to outline the reasons why there is a security
problem with Kerberos Delegation and how to really prevent it.
So let's begin by looking into what is it that the requires
to have Kerberos Delegation.
Why does it exist in the first place?
So by definition, and I have taken it
from the link provided on the slide currently,
Kerberos Delegation enables an application
to access resources which are hosted on another server.
And the most common example, you may say
is when you have a web server, which is internet facing
or user facing and there's a SQL database in the backend.
So what we want to achieve is, we
want the user who is accessing the web server to only
be able to access data for himself on the backend server.
So instead of giving--
with Kerberos Delegation, instead
of giving access to the service account that
is going to perform that connection, and in this case,
it would be access to the entire database, what
we can do is we can use this service account to delegate
the currently logged in user on the web server
and access only that account data in the backend database.
And by doing so, since the service account itself is not
going to have any access to the backend database,
if that account gets compromised there's
going to be no risks to the database you may think.
But then we come into reality and initially, Microsoft
started implementing Kerberos Delegation with a type known
as unconstrained delegation.
And this was introduced very early
when [INAUDIBLE] was created.
And with unconstrained delegation,
you can delegate to any server.
There are no constraints at all.
As long as you're configured to have unconstrained delegation
your account will be able to delegate
another user to anywhere else, any service, any device.
To configure unconstrained delegation,
this is set by setting in the delegation tab of an account,
trust this computer for delegation to any Service.
Now unconstrained delegation, since it
can delegate to anything, is a massive issue
because if you compromise this account
you have delegation rights basically to enter
in your active directory.
And very early again, I believe it was in 2003 released,
Microsoft realized that unconstrained delegation
will have serious security issues
so they released what was called constrained delegation.
And with constrained delegation, this
is a type of delegation which you can configure, again,
on a computer or a user object.
And the constrained part comes here
because you're specifying which account, in which servers
you want to be delegated to.
So in this case, or in the previous example
that we had with the web server and the database,
you said that the user account, the services account
will be delegating only to let's go back in database server
and servers and nothing else.
But again, one account in this case
can have multiple delegations, and you
might end up with one serious account
that an admin may have created 20
different constrained delegations,
and that might give that account access to 20 different servers.
And that, again, can grow really exponentially
if the same servers account is being used
across the entire directory.
And the thing about constrained delegation
is that it really works like magic
and it completely blew my mind the first time I saw it.
I even later on, created a blog post.
That would be the last link on the current slide, where
I'm showcasing how a user with absolutely
no rights in active directory, just
a single delegation towards domain controller on the LDAP
servers allows the user to request a Kerberos
ticket, a valid Kerberos ticket for any user,
without knowing their password.
So imagine you have a user code, test user,
and that test user is configured for constrained delegation
towards the domain controller on the LDAP servers.
That server, or that account can just go and say,
hello domain controller, I am test user.
I want to authenticate to you or to another machine
in this active directory as the account administrator,
and I'm just a delegate so just giving me that Kerberos ticket.
And the domain control will happily
provide that Kerberos ticket of the account administrator
without ever validating that test user knows the password
or has in any way connection with the account administrator.
And again, this can be really bad.
And it's really bad if it's compared to domain controllers.
If it's configured to a member server,
then the worst case scenario is that we can authenticate
as a local administrator or a privileged account
on that single machine.
And you can, of course, login with domain admin.
We did as well.
You can delegate yourself only as domain admin,
but only that one specific machine
is going to trust that you're actually
the domain admin account since you never
provided the password, which you're being delegated to.
And later on, again, Microsoft realized or eventually came
to the conclusion that constrained delegation
can again, pose an issue.
So finally they released what is called resource
based delegation where in this case,
instead of creating the delegation on the user
account's properties or the computer account's properties,
the resource based delegation is defined on the resource
that you're accessing.
So in our initial example, this delegation
would be created on the computer object that
is hosting the SQL database.
So really at the very backend.
The computer itself will decide who to trust for delegation.
And again, with recent research security professionals
have created absolutely amazing tools
that can go and abuse any of these Kerberos Delegation types
and potentially escalate your [INAUDIBLE] into the domain.
What I want to do with these types--
so really what we want to achieve with this presentation
is to understand that Kerberos Delegation can be an issue
and we need to find ways to protect against it.
Unfortunately, we might need to use it in an environment
and there might be really good reasons for that,
and that is fine as long as you manage
to properly protect our environment against delegation.
And we'll talk about protection just in a bit.
But what I want to showcase now, is
I want to show you a demonstration of how we can
abuse unconstrained delegation.
And the reason why I chose this specific demonstration
is because this can be really, really
bad in your entire environment.
This can-- compromising a machine which
is tested for delegation, can result in complete compromising
your active directory, as you'll see in the video.
And in this case, the compromise comes because the printer
or the spooler--
spool server is running on domain controller.
So combining unconstrained delegation
on a server and the principle of service on the domain
controller, can result in complete forest compromise.
And there was some research done where this can actually
work also across forests.
So if you have trust configured between forests,
compromising one forest-- and I'm
using exactly the same scenario as I'm going to demonstrate,
can result in compromising cross forests.
And that can be, again, really bad, as you can imagine.
Let's go to the environment and showcase this demonstration.
Now, my environment currently consists of two servers.
We have a domain controller code.
This is your one.
And we have the server zero one.
Server zero one is configured for unconstrained delegation.
And currently, I am logged in.
Oh, I wanted to type this [INAUDIBLE] Cindy.
I'm currently logged in as the account prod slash slavi.
And this account is low privileged user,
and it only has local administrative rights
on this one sever in my entire domain.
I have somehow managed to compromise this user
and now I'm logged in in that user on server zero one.
So I want to showcase that my account doesn't
have any specific rights.
And the rights that I'm really after at this time
are the ability to perform domain controller replication.
And yes, I'm not a domain controller,
I'm just a user account, but under certain rights
that exist in active directory, you
can configure this domain control replication ability
also to user accounts.
So what I wanted to show here is how we utilize mimikatz.
And mimikatz has built-in ability
to perform this domain controller replication.
And the attack itself is called, dcsync.
So I will utilize mimikatz to try to perform that.
And what I'm expecting to see is that I'll get an error that I
cannot beat, since I'm not a domain controller or I'm not
a user that has those rights.
So now this is interesting.
The command is lsadump dcsync and then
I need to specify user of which account
I want to obtain the NTLM hash of once the replication is
done.
Because when the domain controller
is replicating in between, they're
also replicating NTDS, which contains
the entire active directory, including user password hashes.
So in this case, I can perform the replication
and only extract the password hash of the account
administrator, or really the information
that is associated with this account.
So if I run it, I would get an error.
And this really error comes because I
don't have the necessary rights to perform this action.
So to perform the type we'll use two tools, Rubeus
and SpoolSample.
These two are absolutely amazing.
They're part of every pen-test and red team engagements
that we do.
I think everyone in the security community
is really grateful for the developers of these tools.
They're so widely used, literally everywhere,
and that's because they're really great.
So in my partial compromise that I have just started,
I will start Rubeus, and in the other one I'll run SpoolSample.
So how the attack works.
Because we are talking about unconstrained delegation, what
we're going to notice or what we need to be aware of
is that the computer account will
be storing the credentials that connect to it,
or that are being delegated to it for a very small amount
of time in memory.
But that time is sufficient for an attacker
to extract the Kerberos tickets that are stored in memory.
And what Rubeus has is the ability
to monitor exactly for that.
The command is monitor, and we need
to set an interval of how often we
want this monitoring to happen.
And then we run the tool.
So now every second, since we specified interval one,
every second Rubeus will be checking if someone
has logged into the device.
And if someone did, it will extract the Kerberos ticket
from memory of that user.
And this will be looking for both user connections,
but also for computer connections.
Then we'll move into the second part of this exploitation,
which is the SpoolSample, which is based on a printer
or on the service printer spooler.
And what it's really based on is a short or small bug
that was discovered in that service, where
if you send a specifically crafted request
to the spool Service or the printer service on the machine,
the service would try to attempt to get back to you.
And that authentication happens with the computer account
where the service is running on, since that service
is running a system on that specific machine.
So what SpoolSample dot exe can do
is, if it's pointed to the domain controller which
is what we're going to do now, it
will send a specific custom request of the domain
controller.
And the domain controller will connect back to us
where we'll be able to extract that domain controllers
Kerberos ticket out of memory.
And it's really simple, because these tools are developed
and they're just working out of the box.
So all we have to do really here,
is just run the executable, specify the computer
that we want to connect back to us, which in this case
is this is your one, and specify ourselves.
And we are running on server zero one.
Then we run it.
And what you saw immediately is that Rubeus detected something.
I'll just scroll all the way up and here we will see an event.
ID was detected 4624.
Login attempt from, this is zero one, and the IP address
of the domain controller.
So further down we'll see base64 encoded ticket,
which is the actual Kerberos-- it's a valid Kerberos ticket
of the domain controller.
So let's go forward.
And we'll actually get to use this ticked now.
I need to reformat it since it's multiple lines.
So I'll use Notepad for that.
I will replace the new line and the empty spaces with nothing.
There we go.
Now we have only one line ticket.
So I just copied the ticket.
It's base64 variation of it.
I'm trying to stop Rubeus.
There we go.
So now Rubeus is stopped.
And I have a Kerberos ticket of the domain controller.
So I will again use Rubeus, and this time I'll
specify as the ticket.
Actually, let's first look at what
tickets I have in my session.
If I list my tickets with K list,
I will see that I have tickets for slavi, slavi, slavi,
which is [INAUDIBLE].
What I'm going to do is, I will remove all those Kerberos
tickets.
And if I do K list again, I have no tickets.
Then I'll use Rubeus with the [INAUDIBLE] ticket command
and I'll specify the ticket that I want Rubeus to inject
into memory on my session.
OK, the cover page did not work.
Need to copy it again.
There you go.
So Kerberos will take this base64 ticket, on base648,
and encrypt it into my PowerShell session.
And it gives us information that the ticket
was successfully imported.
If I do K list now, I have one ticket and that ticket
is for the domain controller itself.
So even though I'm not the domain controller,
I managed to obtain a ticket and inject it into my session.
And since I'm at domain controller now,
I can go forward and perform that replication
that we tried to do earlier.
So I will execute mimikatz again.
And the command was--
sorry, the command was samdump dcsync
with the user being administrator.
And it can be really any user.
OK, I think I got the command wrong.
Of course, it is lsadump not samdump.
So lsadump dcsync, the user, administrator.
In this case, we don't get an error.
We actually extract information about the account administrator
and what you're going to see here,
is that we have the password hash of that account.
So we actually are going to be able to perform
offline password tracking against this special hash
or just use this password hash to pass the hash with it.
Or finally, what we can also do is
we can also pass the ticket with the special hash
by again, using Rubeus.
But the point here, is that we can
obtain the password hash of any user in the entire domain.
So essentially, by abusing this unconstrained delegation
and the printer bug, we managed to escalate our privileges
from just having local administrative rights or one
single server, which is tested for unconstrained delegation
into the entire domain, in this case.
And for those of you not aware, we'll discuss it in later topic
again, there's something called golden ticket which
we can abuse to escalate to a forest domination
once we have compromised our domain.
But we'll look into that later.
Point here again, Kerberos Delegation
can be really, really bad.
So what can we do to protect against it?
So each user account has this attribute called,
this account is sensitive and can be delegated.
If this attribute is set, there will
be no tickets stored in memory.
And in the case of constrained delegation,
you cannot just go and say, hello I'm trusted
for delegation, I want a ticket for this account.
As long as this is set, you cannot request a ticket
on behalf of another user.
There's also the protected users group, which special group
in active directory.
It provides a massive amount of protections for users
who are a member of it.
And that's provided by default. The only thing you have to do
is just be a member of this group.
And one of the protections that it provides is that the account
member of this group cannot be delegated.
We'll talk about this group in detail later on
and we'll list all the different protections that it provides.
And then, when you have users and computers that
are configured for delegation, you really
need to go one step forward or further
and ensure that those users and computer accounts are really
protected.
So for computer accounts, really limit the amount
of users who can log into them, ensure
that you have proper patching, and don't really
install any third party tools or any software
that you're not patching, because you might introduce
bugs or exploits, critical exploits that might not
budge against that server.
And regardless of what you do in the rest of your network,
this server will be exposed.
So really limit the attack servers of your device.
Don't install software that is not required in there
and limit the amount of people who have access to that.
Even groups such as users, who have access to all servers
should probably not have access to these delegation servers.
They're very sensitive.
There's a final note.
What I wanted to state is that Kerberos Delegation, which
I already stated multiple times by now,
Kerberos Delegation is a massive issue.
You should not use it if you can.
But if you need to use it, then ensure
that it's properly protected.