WEBVTT

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


00:00:03.010 --> 00:00:03.970 align:middle line:90%
Hi.

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

00:00:05.770 --> 00:00:09.760 align:middle line:84%
to talk about Kerberoasting
and ASREPRoasting.

00:00:09.760 --> 00:00:12.550 align:middle line:84%
Let's look into
those two concepts.

00:00:12.550 --> 00:00:14.140 align:middle line:90%
Kerberoasting.

00:00:14.140 --> 00:00:16.700 align:middle line:84%
Let's look into Active
Directory as a whole,

00:00:16.700 --> 00:00:19.380 align:middle line:84%
so we can get the
complete picture.

00:00:19.380 --> 00:00:21.210 align:middle line:84%
In Active Directory,
you are required

00:00:21.210 --> 00:00:24.400 align:middle line:84%
to set an SPN for
a service account.

00:00:24.400 --> 00:00:28.620 align:middle line:84%
That service account is going
to act as a principal on behalf

00:00:28.620 --> 00:00:30.280 align:middle line:90%
of a service.

00:00:30.280 --> 00:00:32.610 align:middle line:84%
Now, the way that
Active Directory works

00:00:32.610 --> 00:00:35.850 align:middle line:84%
is that, by design,
you will always

00:00:35.850 --> 00:00:40.620 align:middle line:84%
be able to request a Kerberos
TGS service for that set

00:00:40.620 --> 00:00:42.270 align:middle line:90%
service account.

00:00:42.270 --> 00:00:45.510 align:middle line:84%
And the ticket is going to
be encrypted with the service

00:00:45.510 --> 00:00:48.500 align:middle line:90%
accounts NTLM password hash.

00:00:48.500 --> 00:00:51.080 align:middle line:84%
Now, what you could
do as an attacker,

00:00:51.080 --> 00:00:54.050 align:middle line:84%
is that you can request
as many tickets,

00:00:54.050 --> 00:00:58.820 align:middle line:84%
essentially, as you can get
for users that have an SPN set.

00:00:58.820 --> 00:01:02.600 align:middle line:84%
And then try to offline
brute force or use

00:01:02.600 --> 00:01:06.590 align:middle line:84%
a dictionary attack, trying
to crack that ticket.

00:01:06.590 --> 00:01:09.580 align:middle line:84%
Essentially, a password
brute forcing attack.

00:01:09.580 --> 00:01:12.280 align:middle line:84%
If you manage to break
the Kerberos ticket,

00:01:12.280 --> 00:01:15.190 align:middle line:84%
essentially, open
it, that would mean

00:01:15.190 --> 00:01:20.450 align:middle line:84%
that you have the password
of that service account.

00:01:20.450 --> 00:01:23.440 align:middle line:84%
So, really, the
success of this attack

00:01:23.440 --> 00:01:27.280 align:middle line:84%
depends on the strength of the
password of the service account

00:01:27.280 --> 00:01:29.860 align:middle line:90%
that has an SPN set.

00:01:29.860 --> 00:01:37.750 align:middle line:84%
Extracting this Kerberos
TGS is relatively simple,

00:01:37.750 --> 00:01:41.540 align:middle line:84%
and there's a lot of tools
which can do the job.

00:01:41.540 --> 00:01:43.780 align:middle line:84%
For example, on the
slide currently,

00:01:43.780 --> 00:01:49.420 align:middle line:84%
I have shown a PowerShell
command which will go forward

00:01:49.420 --> 00:01:54.190 align:middle line:84%
and download from GitHub
a tool or a script called

00:01:54.190 --> 00:02:01.480 align:middle line:84%
Invoke-Kerberoast, which will
execute and output all Kerberos

00:02:01.480 --> 00:02:04.360 align:middle line:84%
TGTs that it can extract
in the Directory,

00:02:04.360 --> 00:02:10.870 align:middle line:84%
and then store it into a
file called kerb-Hash0.txt.

00:02:10.870 --> 00:02:14.930 align:middle line:84%
This list can be quite
lengthy in a big environment.

00:02:14.930 --> 00:02:16.780 align:middle line:84%
But of course, you
also have the ability

00:02:16.780 --> 00:02:21.040 align:middle line:84%
to perform this for
a specific set user

00:02:21.040 --> 00:02:25.180 align:middle line:84%
or attackers [? covered. ?]
It's a attack known

00:02:25.180 --> 00:02:29.760 align:middle line:90%
as targeted Kerberoasting.

00:02:29.760 --> 00:02:35.070 align:middle line:84%
So, if we get all the tickets,
what we can go forward with

00:02:35.070 --> 00:02:39.090 align:middle line:84%
is passed into a
password cracking tool.

00:02:39.090 --> 00:02:41.620 align:middle line:90%
In this case, we used Hashcat.

00:02:41.620 --> 00:02:45.060 align:middle line:84%
It could also be just
as well John the Ripper

00:02:45.060 --> 00:02:47.940 align:middle line:84%
or any other password
cracking tool.

00:02:47.940 --> 00:02:53.100 align:middle line:84%
And what we can see in here
is that the cracking status

00:02:53.100 --> 00:02:55.290 align:middle line:84%
of the ticket is
that it's cracked.

00:02:55.290 --> 00:02:59.130 align:middle line:84%
And in the file
called CrackedKerb1,

00:02:59.130 --> 00:03:02.740 align:middle line:84%
we can see the actual password
in plaintext that was used.

00:03:02.740 --> 00:03:06.240 align:middle line:84%
Again, this indicates the
password of the service account

00:03:06.240 --> 00:03:09.910 align:middle line:84%
that had the SPN that we used
to extract Kerberos TGTs--

00:03:09.910 --> 00:03:12.600 align:middle line:90%
TGSs, sorry.

00:03:12.600 --> 00:03:18.200 align:middle line:84%
Now, this is really only
possible the success,

00:03:18.200 --> 00:03:22.730 align:middle line:84%
because service accounts
tend to have weak passwords.

00:03:22.730 --> 00:03:27.760 align:middle line:84%
We will always be able
to extract those TGSs,

00:03:27.760 --> 00:03:31.030 align:middle line:84%
primarily because that's the
way that Active Directory works.

00:03:31.030 --> 00:03:35.530 align:middle line:84%
But if service accounts have
strong and long passwords

00:03:35.530 --> 00:03:37.960 align:middle line:84%
of, say, a hundred
characters, then it's

00:03:37.960 --> 00:03:40.300 align:middle line:84%
going to be practically
impossible to break

00:03:40.300 --> 00:03:43.230 align:middle line:90%
that password.

00:03:43.230 --> 00:03:47.300 align:middle line:84%
So, one option to
prevent Kerberoasting

00:03:47.300 --> 00:03:51.890 align:middle line:84%
is that we can use a Group
Managed Service Accounts, which

00:03:51.890 --> 00:03:54.980 align:middle line:84%
are special accounts that live
in Active Directory, where

00:03:54.980 --> 00:03:58.640 align:middle line:84%
Active Directory alone manages
the passwords of those service

00:03:58.640 --> 00:04:00.690 align:middle line:90%
accounts.

00:04:00.690 --> 00:04:05.060 align:middle line:84%
So every set days, for
example, every 30 days,

00:04:05.060 --> 00:04:07.670 align:middle line:84%
the password will automatically
be changed and set

00:04:07.670 --> 00:04:10.940 align:middle line:84%
to the maximum possible value
in Active Directory, which

00:04:10.940 --> 00:04:13.820 align:middle line:90%
is 127 characters long.

00:04:13.820 --> 00:04:18.110 align:middle line:84%
And that makes it
basically impractical

00:04:18.110 --> 00:04:20.200 align:middle line:90%
to crack those passwords.

00:04:20.200 --> 00:04:21.550 align:middle line:90%
Second solution.

00:04:21.550 --> 00:04:23.320 align:middle line:84%
When you have a normal
service account,

00:04:23.320 --> 00:04:25.090 align:middle line:90%
you should use long password.

00:04:25.090 --> 00:04:29.290 align:middle line:84%
Again, 100 character or
more is the advice here.

00:04:29.290 --> 00:04:33.050 align:middle line:84%
And I'm saying 100 or
more, instead of 127,

00:04:33.050 --> 00:04:36.670 align:middle line:84%
which is the highest, because
with 100 characters or more,

00:04:36.670 --> 00:04:41.000 align:middle line:84%
you can choose a buffer
value between 100 and 127,

00:04:41.000 --> 00:04:44.680 align:middle line:84%
which opens additional cracking
spaces that an attacker would

00:04:44.680 --> 00:04:47.110 align:middle line:84%
have to go through to
guess the password.

00:04:47.110 --> 00:04:49.630 align:middle line:84%
Because if we say the
password is set to always 100

00:04:49.630 --> 00:04:51.460 align:middle line:84%
characters, then
they always know

00:04:51.460 --> 00:04:53.200 align:middle line:90%
to go and crack 100 characters.

00:04:53.200 --> 00:04:56.380 align:middle line:84%
But when there's a buffer
between 100 and 127,

00:04:56.380 --> 00:04:58.840 align:middle line:84%
it makes the address space
completely impractical

00:04:58.840 --> 00:05:00.880 align:middle line:90%
to go through.

00:05:00.880 --> 00:05:03.820 align:middle line:84%
So generally, Group
Managed Service Accounts

00:05:03.820 --> 00:05:06.250 align:middle line:84%
are preferred to be
used, however, they

00:05:06.250 --> 00:05:09.370 align:middle line:84%
have a bunch of
limitations and they

00:05:09.370 --> 00:05:13.520 align:middle line:84%
tend to work primarily only
with Microsoft services.

00:05:13.520 --> 00:05:18.760 align:middle line:84%
So if you have an MS SQL or
ISS service rank somewhere,

00:05:18.760 --> 00:05:21.610 align:middle line:84%
yes, you should definitely
go forward and utilize

00:05:21.610 --> 00:05:23.290 align:middle line:90%
Group Managed Service Accounts.

00:05:23.290 --> 00:05:24.940 align:middle line:84%
But if you have
something custom,

00:05:24.940 --> 00:05:28.540 align:middle line:84%
the likelihood of the need
having to use a normal service

00:05:28.540 --> 00:05:30.140 align:middle line:90%
account, is pretty high.

00:05:30.140 --> 00:05:32.260 align:middle line:84%
You should definitely
go and just

00:05:32.260 --> 00:05:36.430 align:middle line:84%
set a long password
for that user instead.

00:05:36.430 --> 00:05:40.150 align:middle line:84%
The next topic on the
list is ASREPRoast.

00:05:40.150 --> 00:05:44.890 align:middle line:84%
And, really, this is a very
similar attack to Kerberoast.

00:05:44.890 --> 00:05:48.550 align:middle line:84%
However, the tickets that
we are extracting right now,

00:05:48.550 --> 00:05:51.580 align:middle line:84%
are dependent on
whether a user has

00:05:51.580 --> 00:05:55.390 align:middle line:84%
the attribute Kerberos
pre-authentication set or not.

00:05:55.390 --> 00:05:57.970 align:middle line:84%
So, no, we're not looking
into user accounts or service

00:05:57.970 --> 00:06:00.460 align:middle line:84%
accounts with SPN
set, but we're looking

00:06:00.460 --> 00:06:03.460 align:middle line:84%
to those that have Kerberos
pre-authentication not

00:06:03.460 --> 00:06:04.910 align:middle line:90%
required.

00:06:04.910 --> 00:06:07.840 align:middle line:84%
So we'll end up
extracting similar tickets

00:06:07.840 --> 00:06:11.860 align:middle line:84%
that we can go forward
and try to crack again.

00:06:11.860 --> 00:06:14.770 align:middle line:84%
And the cracking of
the password, primarily

00:06:14.770 --> 00:06:17.720 align:middle line:84%
depends on the strength
of the user password.

00:06:17.720 --> 00:06:21.490 align:middle line:84%
So the longer the password
and the more random

00:06:21.490 --> 00:06:25.170 align:middle line:84%
it is, the less
likelihood of breaking it.

00:06:25.170 --> 00:06:28.440 align:middle line:84%
And, really, if this is
a service account that

00:06:28.440 --> 00:06:30.570 align:middle line:84%
would require this
to be set, there's

00:06:30.570 --> 00:06:32.520 align:middle line:84%
no reason for that
service account

00:06:32.520 --> 00:06:35.240 align:middle line:84%
to have a password of
less than 100 characters.

00:06:35.240 --> 00:06:37.020 align:middle line:84%
Well, I can think of
one reason, and that

00:06:37.020 --> 00:06:40.320 align:middle line:84%
is that the service where this
account might be used, simply

00:06:40.320 --> 00:06:42.450 align:middle line:84%
does not support
that long password.

00:06:42.450 --> 00:06:45.060 align:middle line:84%
And if that is the
case, then my advice

00:06:45.060 --> 00:06:47.100 align:middle line:84%
would be that the password
should be at least

00:06:47.100 --> 00:06:49.050 align:middle line:90%
32 characters or above.

00:06:49.050 --> 00:06:50.550 align:middle line:84%
Because then, again,
we're entering

00:06:50.550 --> 00:06:54.150 align:middle line:84%
other spaces which are
impractical to go through

00:06:54.150 --> 00:06:56.670 align:middle line:90%
and brute force.

00:06:56.670 --> 00:06:58.440 align:middle line:90%
So how do we prevent it?

00:06:58.440 --> 00:07:03.173 align:middle line:84%
Well, don't set Kerberos
pre-authentication

00:07:03.173 --> 00:07:04.540 align:middle line:90%
not required to begin with.

00:07:04.540 --> 00:07:06.160 align:middle line:84%
Then this is
completely mitigated,

00:07:06.160 --> 00:07:09.820 align:middle line:84%
there's no risk of anyone
extracting Kerberos tickets

00:07:09.820 --> 00:07:11.330 align:middle line:90%
for those users.

00:07:11.330 --> 00:07:13.240 align:middle line:84%
But of course, if
we need to do it,

00:07:13.240 --> 00:07:15.580 align:middle line:84%
then we need to make sure
that the passwords are

00:07:15.580 --> 00:07:18.542 align:middle line:90%
long and uncrackable.

00:07:18.542 --> 00:07:19.042 align:middle line:90%