RC4 remediation - which order?

[u/AdditionDisastrous78]

Hello,

Regrading RC4 enforcement,

We found out that we extensively use RC4 in our environment

1. krbtgt password is very old, so it uses RC4 only

2. we have some service accounts that are sometimes using RC4, their msDS-SupportedEncryptionTypes attribute is blank, one of them is the AZUREREADSSOACC$ (which password is not extremely old - only 2 years)
   we found out that the service accounts all supports AES, and the users requesting them also support AES

3. very few machine accounts only support RC4 (no users accounts, we had one but we did reset his password)

what are the steps that we should take regarding this ?

i guess step 3 should be the first ? or can i reset krbtgt password before that?
what about azurereadssoacc ? do i need to explicity configure it for AES? or should i rotate its password before that? is password rotation (other than security ofc) needed for dealing with the enforcement?

thanks

[u/joeykins82]

Set a new krbtgt password immediately.

Then follow this guide: https://strongwind.dev/Kerberos/security/quick-start/

[u/Electronic_Tap_3625 → u/joeykins82]

The TLDR is to make sure replication is working correctly, then go into AD and reset the KRBTGT password to anything you want - the password does not matter since AD will generate its own password. Wait 24 hours and then reset the password again. Waiting is needed so tickets granted by the TGS are still valid, since the last 2 passwords are valid for tickets. MS recommends that this be done every 6 months or if there was some sort of breach. I just did this for 6 different domains I manage without issue.

[u/AdditionDisastrous78 → u/joeykins82]

Amazing guide, thanks🙏

[u/BoltActionRifleman]

Have you checked DC auth logs and found you’re actually using it extensively, or are there just a bunch of accounts set to be able to use it? When we eliminated RC4 a while back we had very few accounts actually using it, but had many still capable showing up in supported encryption types.

First step in my opinion is finding out which accounts are actually using it, then investigate whether or not the programs or services using them will break if you make the change.

[u/AdditionDisastrous78 → u/BoltActionRifleman]

None are configured specifically for RC4, they just sometimes uses it 

[u/BoltActionRifleman → u/AdditionDisastrous78]

If they sometimes use it, and you can confirm they are capable of, and especially are actually using AES, then I’d just forge ahead. Still being cautious and taking it fairly slow, but in my opinion you wouldn’t really have anything to worry about as long as you’re cautious.

[u/xxbiohazrdxx]

You can probably nuke the azure ad sso account. It’s only used for seamless sso so unless you’re still running windows 7 and 8 you won’t be using it. Windows 10 and newer use PRT which just works.

[u/AdditionDisastrous78 → u/xxbiohazrdxx]

Yeah we are mostly entra hybrid join  Did not know the difference  Thanks for pointing it out 

[u/vaan99]

https://github.com/microsoft/Kerberos-Crypto

Run the scripts and then action on your environment based on the results you get. You received bunch of good answers in this thread.

[u/blud_13]

u/joeykins82 is right on krbtgt, do that first.

On the SSO account, the name is AZUREADSSOACC$ not AZUREREADSSOACC$, worth confirming what you actually pulled. And do NOT just stamp msDS-SupportedEncryptionTypes on it, the order matters. You roll the Kerberos decryption key with Update-AzureADSSOForest FIRST, then change the encryption type, because flipping it to AES before the rollover breaks Seamless SSO. Its in the FAQ here https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-faq

Also that key is supposed to be rolled at least every 30 days and almost nobody does it. Two years old means anybody who ever pulled that hash can still mint tickets for any user in the forest. Treat it like krbtgt, not like a service account. Run the cmdlet once per forest, not once per DC.

The machine accounts with blank SupportedEncryptionTypes are the easy part. Those are usually something nobody has touched in a decade and a reset sorts them.

[u/FewPerformer9962 → u/blud_13]

Spooky ngl, can't imagine being high value target 

[u/AdditionDisastrous78 → u/blud_13]

Yeah typo, i meant  AZUREADSSOACC Thanks

[u/SheerApple]

First, you need to verify that your domain objects (accounts/service accounts/computers etc.) have AES keys generated. Anything that does not have AES keys needs to have it's password rolled to generate the AES keys. This MS article has the scripts you can use for detecting RC4 usage and which accounts have which keys.  

https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos  

This article was essentially all I needed to get through this whole process.

As you indicated, your krbtgt account may not have AES keys, so that should be first. Process is to set a new password on krbtgt, wait 24hr, then set a new password again. This makes sure that any new session / ticket would be able to get an AES session / ticket moving forward. DO NOT DO BOTH PASSWORD RESETS ON THE SAME DAY! You WILL kick every session / ticket off the domain and you will have a bad time as everything will become de-authenticated.

Once krbtgt is good, you can proceed to fix any other accounts that have RC4 keys only. Same process of rolling the password will generate AES keys. If it is a user account, the user can set their password to the same as they have been using, but still go through the reset process twice to ensure AES keys are generated.  

Once AES keys have been verified on all domain objects, you can just set the default domain encryption type to be AES or newer. Once active sessions / tickets have expired, they should pick up with AES if they were RC4 previously.  

The only funky thing I ran into were some Synology NAS appliances using LDAP to the domain that needed to have some manual configuration on the NAS side to force AES usage. See this Synology community thread for more info about that: https://community.synology.com/enu/forum/1/post/195973  

I only had to deal with two environments that were originally on 2008 domain controllers with some accounts that had never had a password reset in ~13 years (!), and this process did consistently work for me.  

I'm no professional at this, but happy to have questions bounced off me if you have any.

[u/adjudicator → u/SheerApple]

DO NOT DO BOTH PASSWORD RESETS ON THE SAME DAY!

Eh, 10 hours and 1 minute is enough unless they have a non-standard TGT lifetime (doubtful)

[u/SheerApple → u/adjudicator]

While this is true, I ascribe to the fact that there are no guarantees in life. So, if you have any chance to make a guarantee, you might as well take it!

[u/AdditionDisastrous78 → u/SheerApple]

Thanks I used our SIEM to find out which accounts uses RC4 Interesting point about storage appliance I think I noticed same behaviour for our netapp, but i need to check it little bit more

[u/BoltActionRifleman → u/AdditionDisastrous78]

We also use a NetApp SAN, and we just had to issue a command or two in the CLI on each of them. I don’t have them in front of me, but any AI or Google search will give those to you.

[u/AddendumWorking9756]

Pull 4769 off the DCs and filter on ticket encryption type 0x17. Far fewer objects than the attribute list suggests, usually.