Detecting Kerberoasting

Both the service ticket request and the subsequent use of the (cracked) password are completely normal processes in Active Directory, which makes it very difficult to detect Kerberoasting. You can only detect the initial exploration with either very advanced AD monitoring that analyzes LDAP queries or by turning up AD logging to such an extent that every LDAP query is recorded and then sifting through the resulting event logs. However, the latter approach requires logging to be raised beyond the debug level to the field engineering level, which causes a huge number of log entries and has a negative effect on the performance of your DCs.

The ticket request process is far more interesting as a monitoring target. If the monitoring policy Audit Kerberos Service Ticket Operations is enabled for Success , an ID 4769 event is generated in the Security event log of the domain controller addressed. If you evaluate these events, you can detect, say, users who have nothing to do with the addressed service but have requested and received a ticket for this service, or find out when encryption with the RC4 hash was used, although you want all components to use AES. An above-average frequency of service ticket requests by the same user can also be an indication of Kerberoasting. The coding of the encryption types used in the ticket is documented online [6] and differs from the convention used in the AD msDS-SupportedEncryptionTypes attribute.

Tracing the use of the captured login data might also be possible with audit events. Just as with the ticket request, you need to look for anomalies – service accounts logging in from client computers, use of RC4, access by service accounts to resources that have nothing to do with the service in question, and the like. Without comprehensive security information and event management (SIEM) and security administrators who are confident in their use of the SIEM environment's search and filter engine, preventing Kerberoasting is an almost hopeless endeavor.

Another way of detecting Kerberoasting at an early stage is a service account honeypot. Because the attacker is unable at first glance to distinguish a genuine production account from a created account specifically without production use, they will discover the account during the reconnaissance phase and try to hijack it. You will want to change this account's password at least once and then log in with the account to make it look as if it has been used in the past. When creating the honeypot, stick to the naming conventions applicable in your AD. You can also set adminCount=1 for this account without adding it to a privileged group. The Honeypot account can help you identify Kerberoasting in two ways:

• Event 4769 tells you that a service ticket has been issued for Kerberoasting (Figure 2), but to determine this, you need to monitor the security event log constantly.

Figure 2: Event 4769 contains full details of issuing the TGS.

• If you give the honeypot account a fairly simple and short password, Kerberoasting will succeed and the attacker will use the account to log in. Monitor the attributes of the AD object related to the logon (lastLogon, lastLogonTimestamp, badPwdTime) to detect any use of this account. Although this check requires significantly less overhead than log-based monitoring, you still have to do the work on all domain controllers.

Conclusions

When it comes to Kerberoasting, it is easier for you as part of the defense team to make the attack uneconomical for the attacker than to prevent it through configuration or to discover successful execution after the event. The recommendation is therefore to restrict the use of conventional service accounts and limit their authorizations, including the ability to log in. Enforcing AES encryption and the use of long passwords, which are changed regularly and preferably automatically, makes Kerberoasting an unattractive proposition for attackers.