Kerberos Part 2 – How do I keep it secure and running?

In part one of the blog post we found out what Kerberos is and how it works and why it is crucial for cybersecurity. In part two we will look at Kerberos operation and security issues.

How to keep Kerberos operational?

In Active Directory (AD) there are supporting functions and systems that need to be managed and maintained to keep Kerberos operational.

In AD domain controllers (DCs) are Key Distribution Centers (KDCs) and they and the requesting clients need to have the following functioning correctly: • DNS and NetBIOS name resolution for both the KDC and the client • Replication between DCs o If replication is delayed or fails, this could result in users having access after being deleted/disabled or authentication failures after a password change. • Time must be synchronized between KDCs and clients o This is to prevent replay attack methods

You need to make sure these items and network communications are functioning to keep Kerberos operational.

How can you increase security for Kerberos?

There are methods that attackers can employ to circumvent Kerberos security.

Kerberoasting

Attackers can perform a brute force attack against the user’s password offline leveraging the ASP REP Roasting technique. Accounts are susceptible to this if the following settings are enabled so you will need to monitor for these changes in AD and see which accounts have them already set:

• “Use only Kerberos DES encryption types for this account” account control setting

• Monitor for changes to the “Do not require Kerberos preauthentication” account control setting

Forged tickets – Golden ticket

The way Kerberos authentication works is that any TGT encrypted with the KRBTGT password hash is valid. Therefore, any attacker who can create forged tickets has unlimited access in the domain otherwise known as a Golden Ticket (must have been named by a Willy Wonka fan). This requires using a compromised user account in the domain and getting the KRTBTGT password hash from:

• NTDS.DIT file (the AD database)

• Getting admin creds off a compromised workstation

• Using Mimkatz to get credentials

Some level of compromise must already be achieved to leverage these attacks. They are a way adversaries move laterally and escalate privileges. You need to closely monitor activities on your DCs and watch for access to NTDS.DIT file. Organizations should also implement Microsoft’s Enterprise access model so that privileged accounts only logon to designated systems to perform specific administrative functions which limits where admin creds can be obtained.

There are ways to protect against these and other methods. You can mitigate your risk by:

• Implementing security best practices

• Principle of least privilege

• Complex passwords for service accounts with 30 day rotations

• Hardening permissions and security settings

• Monitoring activity especially for privileged accounts and groups

• Being able to quickly recover from any misconfigurations or unwanted changes

If you would like to see a demo or discuss how Cygna Labs solutions can help, please contact us at sales@cygnalabs.com .