Hi.
In this video lesson, we are going
to talk about Kerberoasting and ASREPRoasting.
Let's look into those two concepts.
Kerberoasting.
Let's look into Active Directory as a whole,
so we can get the complete picture.
In Active Directory, you are required
to set an SPN for a service account.
That service account is going to act as a principal on behalf
of a service.
Now, the way that Active Directory works
is that, by design, you will always
be able to request a Kerberos TGS service for that set
service account.
And the ticket is going to be encrypted with the service
accounts NTLM password hash.
Now, what you could do as an attacker,
is that you can request as many tickets,
essentially, as you can get for users that have an SPN set.
And then try to offline brute force or use
a dictionary attack, trying to crack that ticket.
Essentially, a password brute forcing attack.
If you manage to break the Kerberos ticket,
essentially, open it, that would mean
that you have the password of that service account.
So, really, the success of this attack
depends on the strength of the password of the service account
that has an SPN set.
Extracting this Kerberos TGS is relatively simple,
and there's a lot of tools which can do the job.
For example, on the slide currently,
I have shown a PowerShell command which will go forward
and download from GitHub a tool or a script called
Invoke-Kerberoast, which will execute and output all Kerberos
TGTs that it can extract in the Directory,
and then store it into a file called kerb-Hash0.txt.
This list can be quite lengthy in a big environment.
But of course, you also have the ability
to perform this for a specific set user
or attackers [? covered. ?] It's a attack known
as targeted Kerberoasting.
So, if we get all the tickets, what we can go forward with
is passed into a password cracking tool.
In this case, we used Hashcat.
It could also be just as well John the Ripper
or any other password cracking tool.
And what we can see in here is that the cracking status
of the ticket is that it's cracked.
And in the file called CrackedKerb1,
we can see the actual password in plaintext that was used.
Again, this indicates the password of the service account
that had the SPN that we used to extract Kerberos TGTs--
TGSs, sorry.
Now, this is really only possible the success,
because service accounts tend to have weak passwords.
We will always be able to extract those TGSs,
primarily because that's the way that Active Directory works.
But if service accounts have strong and long passwords
of, say, a hundred characters, then it's
going to be practically impossible to break
that password.
So, one option to prevent Kerberoasting
is that we can use a Group Managed Service Accounts, which
are special accounts that live in Active Directory, where
Active Directory alone manages the passwords of those service
accounts.
So every set days, for example, every 30 days,
the password will automatically be changed and set
to the maximum possible value in Active Directory, which
is 127 characters long.
And that makes it basically impractical
to crack those passwords.
Second solution.
When you have a normal service account,
you should use long password.
Again, 100 character or more is the advice here.
And I'm saying 100 or more, instead of 127,
which is the highest, because with 100 characters or more,
you can choose a buffer value between 100 and 127,
which opens additional cracking spaces that an attacker would
have to go through to guess the password.
Because if we say the password is set to always 100
characters, then they always know
to go and crack 100 characters.
But when there's a buffer between 100 and 127,
it makes the address space completely impractical
to go through.
So generally, Group Managed Service Accounts
are preferred to be used, however, they
have a bunch of limitations and they
tend to work primarily only with Microsoft services.
So if you have an MS SQL or ISS service rank somewhere,
yes, you should definitely go forward and utilize
Group Managed Service Accounts.
But if you have something custom,
the likelihood of the need having to use a normal service
account, is pretty high.
You should definitely go and just
set a long password for that user instead.
The next topic on the list is ASREPRoast.
And, really, this is a very similar attack to Kerberoast.
However, the tickets that we are extracting right now,
are dependent on whether a user has
the attribute Kerberos pre-authentication set or not.
So, no, we're not looking into user accounts or service
accounts with SPN set, but we're looking
to those that have Kerberos pre-authentication not
required.
So we'll end up extracting similar tickets
that we can go forward and try to crack again.
And the cracking of the password, primarily
depends on the strength of the user password.
So the longer the password and the more random
it is, the less likelihood of breaking it.
And, really, if this is a service account that
would require this to be set, there's
no reason for that service account
to have a password of less than 100 characters.
Well, I can think of one reason, and that
is that the service where this account might be used, simply
does not support that long password.
And if that is the case, then my advice
would be that the password should be at least
32 characters or above.
Because then, again, we're entering
other spaces which are impractical to go through
and brute force.
So how do we prevent it?
Well, don't set Kerberos pre-authentication
not required to begin with.
Then this is completely mitigated,
there's no risk of anyone extracting Kerberos tickets
for those users.
But of course, if we need to do it,
then we need to make sure that the passwords are
long and uncrackable.