RC4 (Kerberoast) Detections ​

What is Kerberoasting?!

Kerberoasting is a post-exploitation attack that threat actors, or Offensive Security practitioners will utilize to extract and crack Kerberos service account credentials. They specifically target weak/old encryption method service account passwords.

What can we do!?

Make sure you are logging event code: 4769 in your SIEM, if not that is your prerequisite. Typically this event code is enabled, and it is specific to Domain Controllers typically (remember these can be generated on an on-premise Exchange server)

 

Technical breakdown:

The following guide is assuming you utilize Graylog:

event_code:4769
show top values on field: windows_kerberos_ticket_encryption_type
event_code:4769 AND windows_kerberos_ticket_encryption_type:RC4\-HMAC
This shows the authentication mechanisms that are being logged, that are using that encryption type.
Now we need to review the account(s) associated with these logons, as well as the source IP address(es)
  1. Show top values on the user_name field
    1. You should review each and every single user returned. Ask questions such as:
      1. Can any of these be flipped to AES256?
      2. If not, why not? Note that, take notes! Update a KB article. ‘
    2. Should have some that are yes, they can be. Fix those though.
    3. Eliminating as many RC4 (Kerberoastable) accounts as possible.
  2. For the user account(s) and device(s) left. Make sure you are adhering to a policy that gives the appropriate task to the appropriate service account. If you run 1 service account for all things, then this is not going to be easy. You need to split those out more specific to server(s), service(s), application(s), database(s), etc. Once you have gotten that done, you should really be able to hone in on where these accounts are being utilized from, and what they are utilized for.
  3. You can now start to figure out what normal is.
    1. Where should this account be logging in from?
    2. What device(s) should be the source, and/or destination of this traffic?
    3. Does this account ever fail to login?
    4. How many times a week, day, hour, etc. does this account typically login?
  4. Start setting up alerts for your account(s).
  5. What can we detect with these alerts?
    1. Abuse of the RC4 accounts.
    2. Additional unexpected logins of the accounts that use RC4
    3. If you have to use RC4 + AES, you could also have additional alerts trigger when machines use RC4, that are not your expected ones. This could point out threat actors attempting to do bad stuff.
  6. What if I eliminated all of the RC4s from my environment? This was all useless and Graylog cannot help me here right? Wrong.
    1. Alert on ANY RC4 uses, and attempted uses. Why? Most attackers will try to do “downgrade” attacks against accounts, so if you have both RC4+AES enabled, you can still use RC4, except Windows will prefer AES anytime it can. Which means, the threat actor can attempt to use RC4, either successfully if using both, or unsuccessfully if forcing AES only. This means, anytime these things occur, you should have a very high fidelity alert.