Detect kerberoastable accounts using Test-PasswordQuality

[CamFlyerCH]

I love that enhancement ! Thanks. Question: What is the exact condition to trigger this ? User (or computer accounts) with an supported encryption type to 0 (=RC4) or some value that includes RC4 AND at least one SPN defined ?

[MichaelGrafnetter]

I love that enhancement ! Thanks. Question: What is the exact condition to trigger this ? User (or computer accounts) with an supported encryption type to 0 (=RC4) or some value that includes RC4 AND at least one SPN defined ?

Good question! And you are basically right, these conditions must be met:

SamAccountType -eq User -and
ServicePrincipalName.Count -ge 1 -and
SupportsKerberosAESEncryption -eq $false

I am actually not checking if the value includes RC4, the presence of AES128 or AES256 is enough. Computer accounts and GMSAs are intentionally ignored, as they typically have random passwords. Does it make sense, or should the test be improved?

The feature has just been released in version 4.7, you can test it yourself.

[aseigler]

I am actually not checking if the value includes RC4, the presence of AES128 or AES256 is enough.

Isn't there a downgrade attack possible?

[CamFlyerCH]

On our way to get rid of RC4 we found that almost all service accounts (user accounts to run services like SQL or IIS for example) do not have the msDs-supportedEncryptionTypes set at all. This tells the Kerberos service to create RC4 service tickets. If the server where this service is running on, only has the AES encryptions types enabled (this is our security baseline for member servers), every Kerberos authentication from a client will just fail.

So at least the AES bits must be enabled. I also think if besides the AES bits (decimal 24) the RC4 bit is set (decimal 28) a downgrade attack would be possible. So bad for me would be a not set attribute or all other values that enable RC4.

Our red team demonstrated kerberoasting on an service accounts with a weak password and the msDs-supportedEncryptionTypes not set.

[MichaelGrafnetter]

On our way to get rid of RC4 we found that almost all service accounts (user accounts to run services like SQL or IIS for example) do not have the msDs-supportedEncryptionTypes set at all.

@CamFlyerCH This corresponds with my experience. That's why I decided to include this simple test in DSInternals, even though it can be performed very easily using the built-in ActiveDirectory module.

I am actually not checking if the value includes RC4, the presence of AES128 or AES256 is enough.

Isn't there a downgrade attack possible?

@aseigler Such combination cannot be achieved by just checking the checkboxes in the UI. Nevertheless, I have tried to perform encryption downgrade using a RC4 TGT and I don't think that it is possible to get a ST with session key encrypted using service's RC4 key (NT hash) if AES is also enabled on that service account.

There actually is another known encryption downgrade attack (see Rubeus.exe kerberoast /usetgtdeleg), but this one actually works even for AES-only accounts.

This is the reason why I do not bother testing the RC4 bit if AES bits are present in msDs-supportedEncryptionTypes. But I might be wrong, so the topic is still open to discussion.

[CamFlyerCH]

I tested the "easy" way and downgraded my client to RC4 only and this resulted, that the session key was RC4, but the ticket itself rested at AES. Rubeus uses this LDAP query for detecting the RC4 enabled accounts (Option /rc4opsec) '(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(!msds-supportedencryptiontypes:1.2.840.113556.1.4.804:=24))' I agree with that. But the Rubeus way to still achieve receiving an RC4 ticket is concerning. Even for an AES only configured account the tgtdeleg trick works: https://github.com/GhostPack/Rubeus#tgtdeleg .

[MichaelGrafnetter]

Thanks for confirmation, @CamFlyerCH . So the detection algorithm in DSInternals is the same as in Rubeus with /rc4opsec option. Only the description in the report should be changed so that it does not give admins a false hope, because of the tgtdeleg trick.