Hi.
In this video lesson, we are going
to be talking about Krbtgt and Golden tickets.
Or actually, the agenda will include discussion about Krbtgt
and also will demonstrate how to reset
the password of this account the right way,
by using the recommended Scripts by Microsoft.
So Krbtgt is a disabled account, which
exists by default in all Active Directory domains.
This account cannot be deleted, cannot be renamed.
Now, you might be wondering, why does it exist if it's disabled?
Well, this account is being used as a service
account for the Key Distribution Center service.
And as such, this account is used to sign and encrypt
all Kerberos tickets in the environment, and that is vital.
Because if you were to compromise the password
hash of this account, you can create your own Kerberos
tickets.
And not just that you can write your own Kerberos tickets,
you can go even a step further and create a ticket
for a nonexistent user.
And because it's signed by Krbtgt,
if you have compromised it, then any device in the environment
would trust that this is an actual valid user.
And you can go a step further.
You can create a Kerberos ticket for a nonexistent user,
assign it enterprise admin rights,
and everything will trust that this user is actually legit
and that that user has those privileges.
So the identity, or rather the identity of this Krbtgt account
is very important to be protected.
And the ability to create those tickets with any right
that you desire is known as Golden ticket,
because essentially get a golden ticket
to access anything you want.
Resetting the password of this Krbtgt password
is therefore highly recommended.
Because if an attacker would obtain the password hash,
they will have the ability to constantly create
their own tickets whenever they desire.
So they don't even have to compromise your accounts
anymore, they can connect to any device
with nonexistent or existent accounts
by the creation of their own tickets.
Now, to reset the password of Krbtgt,
you can just right click on the account,
reset password, and do it.
But this is really not the recommended way.
Because in a multi domain controller--
If your domain contains multiple domain controllers, which
is most likely the case, the replication process
might take some time to go through.
And in that case, it might cause issues
because some of the Kerberos tickets
would have already been issued with the previous password.
And that's partially true.
Because of how critical this account
is, also a ticket signed with the password n minus one
will be accepted by devices.
But instead, the right way to really reset
the password of this account is to use the recommended scripts
that Microsoft provides on TechNet.
I have a link on the slides at the bottom.
If you use these slides--
Sorry.
If you use these scripts, they will not just
reset the password, but they will also force replication.
And then they will verify that the replication has finished
and all domain controllers now have the correct password
of this account.
So it's really good to go forward with those scripts
and use them to reset the password.
Fun fact and something that you might be wondering about
is, if we reset the password with the script,
do we specify the new password in command line,
or where do we pass it?
Well, actually, we never really specify the password.
Because this account is so critical to the way that Active
Directory works, or the trust in Active Directory, what
Microsoft does is that they don't want anyone
to be able to set the password.
So whenever I try to change the password,
they're going to intercept the password change call,
and set the password to something random, anyway.
So even if I try set the password to password one,
Microsoft will intercept that call
and change the real password to something completely random.
Because in reality, no one needs to ever know this password.
Only the domain controller or the server
which is using this user account will
need to know the password hash to be able to encrypt tickets
with it.
So the password will be completely random,
even if you try to set it to something that you know.
So if you want to set it manually, it doesn't matter.
The script that I'm talking about
will set it to something random, and it
will be intercepted anyway and changed
to something a lot more random.
Now, what I want to demonstrate is,
how to use these scripts to go forward and change
the password of Krbtgt.
Now, I'm not sure if you noticed in all the slides previously,
but I mentioned that the passwords--
If we were to compromise the password of this account,
needs to be changed twice.
That is because n minus one password
will continue to operate to prevent already issued tickets
from breaking and having everyone to reauthenticate.
But imagine when you're in a state of a full compromise,
where an attacker has gained domain admin privileges,
and we're assuming that they have the password
hash of Krbtgt.
The real way to really kick them out is to reset--
Not to kick them out, but one of the actions
we have to take during an instance response
with the full compromise, if we can't rebuild our directory
from scratch, we have to change the password of every user
and the password of Krbtgt has to be changed twice.
Let's go to the environment and utilize the scripts.
I'm now running on a domain controller,
and I have just downloaded the script
from the URL which is provided in the link as part
of the slides.
I'll go forward and extract this Zip file.
Inside the Zip file, we'll see two documents, or rather
two files.
The first one is documentation of how
to get, or guide how to run the partial script.
And the second one is the partial script itself.
I'll start PowerShell as an administrator,
and I'll execute the current execution--
Sorry.
I will bypass the current execution policy, in order
to be able to execute scripts.
I can do that by typing PowerShell -exec bypass.
Now, I will run the script, which was just downloaded,
and it will start execution already.
Now, what is interesting is, before it starts executing,
it asks us, in which mode do you wish to run the script.
It has Informational mode, Simulation mode,
and Reset mode.
Because changing the Krbtgt password is so vital,
this script provides the ability to first gather information.
Is this even possible?
Is it possible, and how does replication
actually work in the environment.
It will simulate only your application
without changing it.
And if you perform mode one and two without any issues,
if the two doesn't discover anything,
then you can go forward and run mode three,
which is the actual Reset mode.
So let's start with mode one, which is only informational.
To go forward, execute certain checks.
It will ensure that everything that
is required to change the password
is part of our environment.
And eventually, what we can see on the screen,
is that all the checks were passed and were green
everywhere.
Let's execute the script again, and this time,
specify that we want to do it in mode two.
Now, it will do the same checks and it will also
force replication.
And replication, in this case, we
have only one domain controller, so replication is not
going to take any time.
But in your organization, your enterprise environment,
this might take a couple minutes.
So bear with it.
And here we will just press Y, because we want to proceed.
And it will also tell us the total time
it took for this execution.
And it's quite instant since we have
only one domain controller, which is the one
that we are running.
Now, we didn't really get any red flags or anything
that we should be aware of, so we are going to go forward.
Start the script, and run it in mode three.
This mode, it will actually reset the password of Krbtgt.
But before resetting it, it's going
to give us this red warning, saying,
hey, the next step is crucial, are you really certain
that you want to do this?
Yes, we are certain.
We will go forward and do it.
And then we go--
The password was changed and replication was forced.
Everything should now be in place.
Resetting the password once should not cause any issues.
And if you want to reset it a second time immediately,
then I can assure you, you're going to see issues.
There needs to be some time for the entire replication process
to finish.
And especially because there are tickets
which are already issued from n minus one password
and n minus two.
At that point, if you set it again,
some tickets will be invalidated,
and that will cause issue in the environment.
During instant response, I had to reset this password twice
in a short window of about 15 minutes between the resets,
because we were in an active state trying to kick attackers
out of the network.
That did cause some issues for a certain amount of time.
Maybe one to two hours or so, we had issues logging
into some systems.
And that's something you should be really aware of if you
want to do the second reset.
The normal recommended time span is about 24 hours
after the first one, you can go forward
and reset without causing any issues in the directory.
So this was it.
Running the script was really easy and quite informative.
And it's much better than doing it
the manual way, where you're going to reset
the password by yourself.
And if you were to actually go that way,
you can see the Krbtgt account in the Users
organizational unit by default. You can, of course, reset
the password from here.
But again, this is not the recommended way to do it.
You should definitely use the scripts instead.