WEBVTT

00:00:00.000 --> 00:00:03.560 align:middle line:90%


00:00:03.560 --> 00:00:04.220 align:middle line:90%
Hi.

00:00:04.220 --> 00:00:05.840 align:middle line:84%
In this video
lesson, we are going

00:00:05.840 --> 00:00:09.230 align:middle line:84%
to be talking about
Krbtgt and Golden tickets.

00:00:09.230 --> 00:00:13.040 align:middle line:84%
Or actually, the agenda will
include discussion about Krbtgt

00:00:13.040 --> 00:00:15.830 align:middle line:84%
and also will
demonstrate how to reset

00:00:15.830 --> 00:00:18.830 align:middle line:84%
the password of this
account the right way,

00:00:18.830 --> 00:00:21.680 align:middle line:84%
by using the recommended
Scripts by Microsoft.

00:00:21.680 --> 00:00:24.830 align:middle line:84%
So Krbtgt is a
disabled account, which

00:00:24.830 --> 00:00:28.050 align:middle line:84%
exists by default in all
Active Directory domains.

00:00:28.050 --> 00:00:31.130 align:middle line:84%
This account cannot be
deleted, cannot be renamed.

00:00:31.130 --> 00:00:35.360 align:middle line:84%
Now, you might be wondering, why
does it exist if it's disabled?

00:00:35.360 --> 00:00:38.240 align:middle line:84%
Well, this account is
being used as a service

00:00:38.240 --> 00:00:41.060 align:middle line:84%
account for the Key
Distribution Center service.

00:00:41.060 --> 00:00:45.410 align:middle line:84%
And as such, this account
is used to sign and encrypt

00:00:45.410 --> 00:00:50.450 align:middle line:84%
all Kerberos tickets in the
environment, and that is vital.

00:00:50.450 --> 00:00:53.240 align:middle line:84%
Because if you were to
compromise the password

00:00:53.240 --> 00:00:56.760 align:middle line:84%
hash of this account, you
can create your own Kerberos

00:00:56.760 --> 00:00:57.565 align:middle line:90%
tickets.

00:00:57.565 --> 00:01:00.540 align:middle line:84%
And not just that you can write
your own Kerberos tickets,

00:01:00.540 --> 00:01:04.730 align:middle line:84%
you can go even a step
further and create a ticket

00:01:04.730 --> 00:01:06.540 align:middle line:90%
for a nonexistent user.

00:01:06.540 --> 00:01:09.260 align:middle line:84%
And because it's
signed by Krbtgt,

00:01:09.260 --> 00:01:12.740 align:middle line:84%
if you have compromised it, then
any device in the environment

00:01:12.740 --> 00:01:17.060 align:middle line:84%
would trust that this
is an actual valid user.

00:01:17.060 --> 00:01:20.000 align:middle line:90%
And you can go a step further.

00:01:20.000 --> 00:01:24.020 align:middle line:84%
You can create a Kerberos
ticket for a nonexistent user,

00:01:24.020 --> 00:01:26.030 align:middle line:84%
assign it enterprise
admin rights,

00:01:26.030 --> 00:01:29.870 align:middle line:84%
and everything will trust that
this user is actually legit

00:01:29.870 --> 00:01:32.890 align:middle line:84%
and that that user
has those privileges.

00:01:32.890 --> 00:01:39.540 align:middle line:84%
So the identity, or rather the
identity of this Krbtgt account

00:01:39.540 --> 00:01:43.020 align:middle line:84%
is very important
to be protected.

00:01:43.020 --> 00:01:47.110 align:middle line:84%
And the ability to create
those tickets with any right

00:01:47.110 --> 00:01:49.860 align:middle line:84%
that you desire is
known as Golden ticket,

00:01:49.860 --> 00:01:51.900 align:middle line:84%
because essentially
get a golden ticket

00:01:51.900 --> 00:01:55.090 align:middle line:90%
to access anything you want.

00:01:55.090 --> 00:01:57.920 align:middle line:84%
Resetting the password
of this Krbtgt password

00:01:57.920 --> 00:02:00.820 align:middle line:90%
is therefore highly recommended.

00:02:00.820 --> 00:02:04.180 align:middle line:84%
Because if an attacker would
obtain the password hash,

00:02:04.180 --> 00:02:07.300 align:middle line:84%
they will have the ability
to constantly create

00:02:07.300 --> 00:02:10.060 align:middle line:84%
their own tickets
whenever they desire.

00:02:10.060 --> 00:02:12.520 align:middle line:84%
So they don't even have to
compromise your accounts

00:02:12.520 --> 00:02:14.920 align:middle line:84%
anymore, they can
connect to any device

00:02:14.920 --> 00:02:18.370 align:middle line:84%
with nonexistent or
existent accounts

00:02:18.370 --> 00:02:20.950 align:middle line:84%
by the creation of
their own tickets.

00:02:20.950 --> 00:02:24.070 align:middle line:84%
Now, to reset the
password of Krbtgt,

00:02:24.070 --> 00:02:25.900 align:middle line:84%
you can just right
click on the account,

00:02:25.900 --> 00:02:27.640 align:middle line:90%
reset password, and do it.

00:02:27.640 --> 00:02:30.160 align:middle line:84%
But this is really not
the recommended way.

00:02:30.160 --> 00:02:33.302 align:middle line:84%
Because in a multi
domain controller--

00:02:33.302 --> 00:02:36.580 align:middle line:90%


00:02:36.580 --> 00:02:39.640 align:middle line:84%
If your domain contains multiple
domain controllers, which

00:02:39.640 --> 00:02:43.060 align:middle line:84%
is most likely the case,
the replication process

00:02:43.060 --> 00:02:45.070 align:middle line:84%
might take some
time to go through.

00:02:45.070 --> 00:02:46.840 align:middle line:84%
And in that case, it
might cause issues

00:02:46.840 --> 00:02:50.350 align:middle line:84%
because some of the
Kerberos tickets

00:02:50.350 --> 00:02:53.530 align:middle line:84%
would have already been issued
with the previous password.

00:02:53.530 --> 00:02:55.660 align:middle line:90%
And that's partially true.

00:02:55.660 --> 00:02:59.032 align:middle line:90%


00:02:59.032 --> 00:03:00.670 align:middle line:84%
Because of how
critical this account

00:03:00.670 --> 00:03:05.905 align:middle line:84%
is, also a ticket signed
with the password n minus one

00:03:05.905 --> 00:03:08.960 align:middle line:90%
will be accepted by devices.

00:03:08.960 --> 00:03:10.940 align:middle line:84%
But instead, the right
way to really reset

00:03:10.940 --> 00:03:14.750 align:middle line:84%
the password of this account is
to use the recommended scripts

00:03:14.750 --> 00:03:17.120 align:middle line:84%
that Microsoft
provides on TechNet.

00:03:17.120 --> 00:03:19.490 align:middle line:84%
I have a link on the
slides at the bottom.

00:03:19.490 --> 00:03:21.660 align:middle line:90%
If you use these slides--

00:03:21.660 --> 00:03:22.220 align:middle line:90%
Sorry.

00:03:22.220 --> 00:03:24.770 align:middle line:84%
If you use these scripts,
they will not just

00:03:24.770 --> 00:03:30.230 align:middle line:84%
reset the password, but they
will also force replication.

00:03:30.230 --> 00:03:32.960 align:middle line:84%
And then they will verify that
the replication has finished

00:03:32.960 --> 00:03:35.540 align:middle line:84%
and all domain controllers
now have the correct password

00:03:35.540 --> 00:03:36.690 align:middle line:90%
of this account.

00:03:36.690 --> 00:03:39.860 align:middle line:84%
So it's really good to go
forward with those scripts

00:03:39.860 --> 00:03:42.710 align:middle line:84%
and use them to
reset the password.

00:03:42.710 --> 00:03:45.350 align:middle line:84%
Fun fact and something that
you might be wondering about

00:03:45.350 --> 00:03:48.320 align:middle line:84%
is, if we reset the
password with the script,

00:03:48.320 --> 00:03:51.110 align:middle line:84%
do we specify the new
password in command line,

00:03:51.110 --> 00:03:53.030 align:middle line:90%
or where do we pass it?

00:03:53.030 --> 00:03:56.050 align:middle line:84%
Well, actually, we never
really specify the password.

00:03:56.050 --> 00:03:58.850 align:middle line:84%
Because this account is so
critical to the way that Active

00:03:58.850 --> 00:04:02.960 align:middle line:84%
Directory works, or the trust
in Active Directory, what

00:04:02.960 --> 00:04:05.450 align:middle line:84%
Microsoft does is that
they don't want anyone

00:04:05.450 --> 00:04:07.220 align:middle line:90%
to be able to set the password.

00:04:07.220 --> 00:04:09.110 align:middle line:84%
So whenever I try to
change the password,

00:04:09.110 --> 00:04:12.380 align:middle line:84%
they're going to intercept
the password change call,

00:04:12.380 --> 00:04:14.600 align:middle line:84%
and set the password to
something random, anyway.

00:04:14.600 --> 00:04:17.180 align:middle line:84%
So even if I try set the
password to password one,

00:04:17.180 --> 00:04:18.640 align:middle line:84%
Microsoft will
intercept that call

00:04:18.640 --> 00:04:21.140 align:middle line:84%
and change the real password
to something completely random.

00:04:21.140 --> 00:04:24.960 align:middle line:84%
Because in reality, no one needs
to ever know this password.

00:04:24.960 --> 00:04:28.680 align:middle line:84%
Only the domain
controller or the server

00:04:28.680 --> 00:04:31.010 align:middle line:84%
which is using this
user account will

00:04:31.010 --> 00:04:34.220 align:middle line:84%
need to know the password hash
to be able to encrypt tickets

00:04:34.220 --> 00:04:36.050 align:middle line:90%
with it.

00:04:36.050 --> 00:04:38.330 align:middle line:84%
So the password will
be completely random,

00:04:38.330 --> 00:04:41.390 align:middle line:84%
even if you try to set it
to something that you know.

00:04:41.390 --> 00:04:44.030 align:middle line:84%
So if you want to set it
manually, it doesn't matter.

00:04:44.030 --> 00:04:45.560 align:middle line:84%
The script that
I'm talking about

00:04:45.560 --> 00:04:48.110 align:middle line:84%
will set it to
something random, and it

00:04:48.110 --> 00:04:50.490 align:middle line:84%
will be intercepted
anyway and changed

00:04:50.490 --> 00:04:52.970 align:middle line:90%
to something a lot more random.

00:04:52.970 --> 00:04:54.770 align:middle line:84%
Now, what I want
to demonstrate is,

00:04:54.770 --> 00:04:57.650 align:middle line:84%
how to use these scripts
to go forward and change

00:04:57.650 --> 00:04:59.630 align:middle line:90%
the password of Krbtgt.

00:04:59.630 --> 00:05:02.870 align:middle line:84%
Now, I'm not sure if you noticed
in all the slides previously,

00:05:02.870 --> 00:05:05.186 align:middle line:84%
but I mentioned
that the passwords--

00:05:05.186 --> 00:05:07.940 align:middle line:84%
If we were to compromise the
password of this account,

00:05:07.940 --> 00:05:09.590 align:middle line:90%
needs to be changed twice.

00:05:09.590 --> 00:05:12.050 align:middle line:84%
That is because n
minus one password

00:05:12.050 --> 00:05:16.550 align:middle line:84%
will continue to operate to
prevent already issued tickets

00:05:16.550 --> 00:05:20.360 align:middle line:84%
from breaking and having
everyone to reauthenticate.

00:05:20.360 --> 00:05:24.770 align:middle line:84%
But imagine when you're in a
state of a full compromise,

00:05:24.770 --> 00:05:28.370 align:middle line:84%
where an attacker has gained
domain admin privileges,

00:05:28.370 --> 00:05:30.380 align:middle line:84%
and we're assuming that
they have the password

00:05:30.380 --> 00:05:31.970 align:middle line:90%
hash of Krbtgt.

00:05:31.970 --> 00:05:34.745 align:middle line:84%
The real way to really
kick them out is to reset--

00:05:34.745 --> 00:05:37.250 align:middle line:90%


00:05:37.250 --> 00:05:39.140 align:middle line:84%
Not to kick them out,
but one of the actions

00:05:39.140 --> 00:05:40.932 align:middle line:84%
we have to take during
an instance response

00:05:40.932 --> 00:05:45.500 align:middle line:84%
with the full compromise, if
we can't rebuild our directory

00:05:45.500 --> 00:05:49.130 align:middle line:84%
from scratch, we have to change
the password of every user

00:05:49.130 --> 00:05:53.250 align:middle line:84%
and the password of Krbtgt
has to be changed twice.

00:05:53.250 --> 00:05:57.750 align:middle line:84%
Let's go to the environment
and utilize the scripts.

00:05:57.750 --> 00:05:59.870 align:middle line:84%
I'm now running on
a domain controller,

00:05:59.870 --> 00:06:01.490 align:middle line:84%
and I have just
downloaded the script

00:06:01.490 --> 00:06:05.150 align:middle line:84%
from the URL which is
provided in the link as part

00:06:05.150 --> 00:06:06.080 align:middle line:90%
of the slides.

00:06:06.080 --> 00:06:10.260 align:middle line:84%
I'll go forward and
extract this Zip file.

00:06:10.260 --> 00:06:13.200 align:middle line:84%
Inside the Zip file, we'll
see two documents, or rather

00:06:13.200 --> 00:06:13.990 align:middle line:90%
two files.

00:06:13.990 --> 00:06:16.530 align:middle line:84%
The first one is
documentation of how

00:06:16.530 --> 00:06:20.370 align:middle line:84%
to get, or guide how to
run the partial script.

00:06:20.370 --> 00:06:22.910 align:middle line:84%
And the second one is the
partial script itself.

00:06:22.910 --> 00:06:26.010 align:middle line:84%
I'll start PowerShell
as an administrator,

00:06:26.010 --> 00:06:29.230 align:middle line:84%
and I'll execute the
current execution--

00:06:29.230 --> 00:06:29.730 align:middle line:90%
Sorry.

00:06:29.730 --> 00:06:32.670 align:middle line:84%
I will bypass the current
execution policy, in order

00:06:32.670 --> 00:06:34.320 align:middle line:90%
to be able to execute scripts.

00:06:34.320 --> 00:06:37.590 align:middle line:84%
I can do that by typing
PowerShell -exec bypass.

00:06:37.590 --> 00:06:42.570 align:middle line:84%
Now, I will run the script,
which was just downloaded,

00:06:42.570 --> 00:06:46.350 align:middle line:84%
and it will start
execution already.

00:06:46.350 --> 00:06:49.980 align:middle line:84%
Now, what is interesting is,
before it starts executing,

00:06:49.980 --> 00:06:54.030 align:middle line:84%
it asks us, in which mode do
you wish to run the script.

00:06:54.030 --> 00:06:57.300 align:middle line:84%
It has Informational
mode, Simulation mode,

00:06:57.300 --> 00:06:59.070 align:middle line:90%
and Reset mode.

00:06:59.070 --> 00:07:03.300 align:middle line:84%
Because changing the Krbtgt
password is so vital,

00:07:03.300 --> 00:07:07.980 align:middle line:84%
this script provides the ability
to first gather information.

00:07:07.980 --> 00:07:11.410 align:middle line:90%
Is this even possible?

00:07:11.410 --> 00:07:13.840 align:middle line:84%
Is it possible, and
how does replication

00:07:13.840 --> 00:07:15.290 align:middle line:84%
actually work in
the environment.

00:07:15.290 --> 00:07:16.990 align:middle line:84%
It will simulate
only your application

00:07:16.990 --> 00:07:18.190 align:middle line:90%
without changing it.

00:07:18.190 --> 00:07:22.870 align:middle line:84%
And if you perform mode one
and two without any issues,

00:07:22.870 --> 00:07:25.000 align:middle line:84%
if the two doesn't
discover anything,

00:07:25.000 --> 00:07:28.300 align:middle line:84%
then you can go forward
and run mode three,

00:07:28.300 --> 00:07:30.380 align:middle line:90%
which is the actual Reset mode.

00:07:30.380 --> 00:07:34.750 align:middle line:84%
So let's start with mode one,
which is only informational.

00:07:34.750 --> 00:07:38.095 align:middle line:84%
To go forward, execute
certain checks.

00:07:38.095 --> 00:07:40.000 align:middle line:84%
It will ensure that
everything that

00:07:40.000 --> 00:07:41.740 align:middle line:84%
is required to
change the password

00:07:41.740 --> 00:07:43.540 align:middle line:90%
is part of our environment.

00:07:43.540 --> 00:07:47.140 align:middle line:84%
And eventually, what we
can see on the screen,

00:07:47.140 --> 00:07:50.050 align:middle line:84%
is that all the checks
were passed and were green

00:07:50.050 --> 00:07:51.880 align:middle line:90%
everywhere.

00:07:51.880 --> 00:07:54.460 align:middle line:84%
Let's execute the script
again, and this time,

00:07:54.460 --> 00:07:57.730 align:middle line:84%
specify that we want
to do it in mode two.

00:07:57.730 --> 00:08:00.100 align:middle line:84%
Now, it will do the same
checks and it will also

00:08:00.100 --> 00:08:02.450 align:middle line:90%
force replication.

00:08:02.450 --> 00:08:07.580 align:middle line:84%
And replication,
in this case, we

00:08:07.580 --> 00:08:09.830 align:middle line:84%
have only one domain controller,
so replication is not

00:08:09.830 --> 00:08:11.030 align:middle line:90%
going to take any time.

00:08:11.030 --> 00:08:14.060 align:middle line:84%
But in your organization,
your enterprise environment,

00:08:14.060 --> 00:08:15.750 align:middle line:84%
this might take
a couple minutes.

00:08:15.750 --> 00:08:17.335 align:middle line:90%
So bear with it.

00:08:17.335 --> 00:08:21.570 align:middle line:84%
And here we will just press
Y, because we want to proceed.

00:08:21.570 --> 00:08:24.820 align:middle line:84%
And it will also tell
us the total time

00:08:24.820 --> 00:08:29.530 align:middle line:90%
it took for this execution.

00:08:29.530 --> 00:08:31.120 align:middle line:84%
And it's quite
instant since we have

00:08:31.120 --> 00:08:33.070 align:middle line:84%
only one domain controller,
which is the one

00:08:33.070 --> 00:08:34.590 align:middle line:90%
that we are running.

00:08:34.590 --> 00:08:37.299 align:middle line:84%
Now, we didn't really get
any red flags or anything

00:08:37.299 --> 00:08:40.840 align:middle line:84%
that we should be aware of,
so we are going to go forward.

00:08:40.840 --> 00:08:43.659 align:middle line:84%
Start the script, and
run it in mode three.

00:08:43.659 --> 00:08:48.280 align:middle line:84%
This mode, it will actually
reset the password of Krbtgt.

00:08:48.280 --> 00:08:50.320 align:middle line:84%
But before resetting
it, it's going

00:08:50.320 --> 00:08:53.180 align:middle line:84%
to give us this red
warning, saying,

00:08:53.180 --> 00:08:57.190 align:middle line:84%
hey, the next step is crucial,
are you really certain

00:08:57.190 --> 00:08:59.030 align:middle line:90%
that you want to do this?

00:08:59.030 --> 00:09:00.100 align:middle line:90%
Yes, we are certain.

00:09:00.100 --> 00:09:02.680 align:middle line:90%
We will go forward and do it.

00:09:02.680 --> 00:09:04.130 align:middle line:90%
And then we go--

00:09:04.130 --> 00:09:07.780 align:middle line:84%
The password was changed
and replication was forced.

00:09:07.780 --> 00:09:10.060 align:middle line:84%
Everything should
now be in place.

00:09:10.060 --> 00:09:14.320 align:middle line:84%
Resetting the password once
should not cause any issues.

00:09:14.320 --> 00:09:18.010 align:middle line:84%
And if you want to reset it
a second time immediately,

00:09:18.010 --> 00:09:22.630 align:middle line:84%
then I can assure you,
you're going to see issues.

00:09:22.630 --> 00:09:27.370 align:middle line:84%
There needs to be some time for
the entire replication process

00:09:27.370 --> 00:09:28.030 align:middle line:90%
to finish.

00:09:28.030 --> 00:09:29.697 align:middle line:84%
And especially because
there are tickets

00:09:29.697 --> 00:09:33.250 align:middle line:84%
which are already issued
from n minus one password

00:09:33.250 --> 00:09:34.330 align:middle line:90%
and n minus two.

00:09:34.330 --> 00:09:36.520 align:middle line:84%
At that point, if
you set it again,

00:09:36.520 --> 00:09:38.050 align:middle line:84%
some tickets will
be invalidated,

00:09:38.050 --> 00:09:40.810 align:middle line:84%
and that will cause
issue in the environment.

00:09:40.810 --> 00:09:46.120 align:middle line:84%
During instant response, I had
to reset this password twice

00:09:46.120 --> 00:09:51.400 align:middle line:84%
in a short window of about 15
minutes between the resets,

00:09:51.400 --> 00:09:54.340 align:middle line:84%
because we were in an active
state trying to kick attackers

00:09:54.340 --> 00:09:55.510 align:middle line:90%
out of the network.

00:09:55.510 --> 00:09:59.590 align:middle line:84%
That did cause some issues
for a certain amount of time.

00:09:59.590 --> 00:10:04.620 align:middle line:84%
Maybe one to two hours or
so, we had issues logging

00:10:04.620 --> 00:10:05.515 align:middle line:90%
into some systems.

00:10:05.515 --> 00:10:07.890 align:middle line:84%
And that's something you should
be really aware of if you

00:10:07.890 --> 00:10:09.420 align:middle line:90%
want to do the second reset.

00:10:09.420 --> 00:10:12.870 align:middle line:84%
The normal recommended
time span is about 24 hours

00:10:12.870 --> 00:10:14.970 align:middle line:84%
after the first one,
you can go forward

00:10:14.970 --> 00:10:20.230 align:middle line:84%
and reset without causing
any issues in the directory.

00:10:20.230 --> 00:10:21.170 align:middle line:90%
So this was it.

00:10:21.170 --> 00:10:24.100 align:middle line:84%
Running the script was really
easy and quite informative.

00:10:24.100 --> 00:10:25.690 align:middle line:84%
And it's much
better than doing it

00:10:25.690 --> 00:10:29.170 align:middle line:84%
the manual way, where
you're going to reset

00:10:29.170 --> 00:10:31.330 align:middle line:90%
the password by yourself.

00:10:31.330 --> 00:10:33.580 align:middle line:84%
And if you were to
actually go that way,

00:10:33.580 --> 00:10:37.320 align:middle line:84%
you can see the Krbtgt
account in the Users

00:10:37.320 --> 00:10:40.570 align:middle line:84%
organizational unit by default.
You can, of course, reset

00:10:40.570 --> 00:10:41.600 align:middle line:90%
the password from here.

00:10:41.600 --> 00:10:44.320 align:middle line:84%
But again, this is not the
recommended way to do it.

00:10:44.320 --> 00:10:47.250 align:middle line:84%
You should definitely
use the scripts instead.

00:10:47.250 --> 00:10:48.091 align:middle line:90%