Although organizations have made strides in the security of their on-premises Active Directory environments, password harvesting methods such as the Kerberoasting attack or AS-REP roasting remain prevalent in cyberattacks. Unfortunately, these techniques are not easily fixed with a patch or a configuration change.
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Mitigation requires looking at your overall password process, tackling the challenge of updating service accounts, and ensuring modern encryption algorithms are used for all tickets. Understanding Kerberos attacks begins with understanding the core concepts of the Kerberos authentication flow, which attackers exploit to gain unauthorized access to misconfigured accounts.
Kerberos Overview
Kerberos is the preferred authentication protocol for a modern Active Directory environment. Kerberos authentication is based on a series of tickets which are used to request and grant access to services. In an Active Directory environment, the domain controllers manage the authentication ticket requests and issue service tickets which will be used to access the service. Authentication tickets or Ticket Granting Ticket (TGT) tickets are issued once a client’s identity has been validated with pre-authentication. Once a client is in possession of a TGT, they are then able to request access to services. This is completed via the request for a service ticket via a Ticket Granting Service (TGS) request. Clients then present their Kerberos service ticket to the service, which then decrypts the ticket and provides access if applicable.
KRBTGT Service Account
TGT tickets are encrypted with the password of the Kerberos Ticket Granting Ticket (KRBTGT) service account. The KRBTGT account is a service account which is integral to the Kerberos authentication process. At the time of domain creation (or promotion of a read-only domain controller), the KRBTGT account is created in a disabled state and cannot be enabled. Often it has not had its password changed since initial creation or after the domain functional level was raised to Windows Server 2008. Due to its importance, we recommend the KRBTGT password be rotated on an annual basis. Microsoft has outlined this process in their article AD Forest Recovery – Resetting the KRBTGT password.
If you are unaware of the last time your organization completed this process or have reservations about the KRBTGT password reset process, don’t hesitate to reach out to Ravenswood today. Our Active Directory Health Check & Security Assessment can give you insights into issues related to KRBTGT along with many other vulnerabilities.
Ticket Encryption Types
Kerberos tickets support a variety of encryption types for new and old clients. Microsoft has been making an effort to eliminate the use of older and less secure encryption types, but in my experience many organizations still depend on unsecure encryption to authenticate service accounts for business-critical apps. Windows Server 2008 domain functional level added support for Advanced Encryption Standard AES128 and AES256. Prior to application of KB5021131, RC4-HMAC was the default ticket encryption type for accounts to maintain compatibility with older systems.
Some organizations may have explicitly set this value to RC4-HMAC for a subset of service accounts. These accounts are especially susceptible to attacks due to the weakness of the encryption, coupled with the increased likelihood of weak passwords due to age or compatibility reasons. Jerry Devore’s article Decrypting the Selection of Supported Kerberos Encryption Types is an excellent resource for a deeper dive into this topic.
Kerberos Authentication & Authorization Process
AS-Rep roasting exploits accounts which lack the requirement for pre-authentication, while Kerberoasting exploits the authorization process flow for a legitimate service account. Since this suspicious activity can easily blend in with the normal Kerberos process these attacks can be difficult to detect. To better understand what we are defending against, we can look at the normal Kerberos authentication process steps, which are pre-authentication, authentication and finally authorization.
Pre-authentication
The TGT request includes the timestamp and must be encrypted using the password of the client requesting to protect against relay attacks and provide an extra layer of protection against attacks such as AS-REP roasting. Should pre-authentication fail, a 4771 event will be generated on the domain controller indicating the failure reason and pre-authentication type. In this example the failure was due to providing a wrong password. Microsoft details how to properly audit these failures in their article, 4771: Kerberos pre-authentication failed.
A corresponding KRB5 packet is generated which states an error occurred due to pre-authentication being needed for AS-REQ and failing.
Authentication
Following successful pre-authentication, a client may request authentication by sending an AS-REQ request to the domain controller to request a TGT.
The network capture above shows the AS-REQ request. Including the required Kerberos pre-authentication data, the name of user requesting the TGT, the realm (domain) to which this request is made, requested encryption types and the service requested. In this case the requested service is the KRBTGT Service, since we are requesting a TGT.
If the domain controller can decrypt the password hash of the requesting client a TGT is returned to the client in the AS-REP.
The network capture above shows the resulting AS-REP packet.
This will produce a 4768 event on the issuing domain controller, this event will show the ticket encryption type of the resulting ticket.
Above, the user successfully authenticated and requested a TGT, which was issued and encrypted using the Ticket Encryption Type, AES256-CTS-HMAC-SHA1-96.
Authorization
Following the receipt of a TGT, the client may now try to access services and acquire authorization. The client initiates this process by requesting a TGS ticket from the domain controller. This generates a 4769 event on the domain controller issuing the TGS, and nothing is recorded on the service host as the service is not aware of the TGS request.
In the network capture above, you can see that the user requested a TGS, via a TGS-REQ, to access the CIFS service on the domain controller.
The domain controller then issues a service ticket, which it encrypts with the password of the target service account. The domain controller never checks whether the client has access to the service, as it does not provide authorization for the service request.
Above the domain controller responded in the TGS-REP packet with the resulting service ticket.
The client then presents the TGS to the service to request authorization. Since the service knows its password, it can then decrypt the ticket, it then validates if the client has access to the service and authorizes access if applicable.
AS-REP Roasting: Exploiting Pre-authentication
AS-Rep roasting is the exploitation of accounts which do not require Kerberos pre-authentication. It is advisable that any accounts found with do not require Kerberos pre-authentication be investigated and remediate them as they are susceptible to relay attacks and credential harvesting attacks, especially when combined with the use of older ticket encryption types and weak passwords. This misconfiguration will be more prevalent on older service accounts, which are also more likely to have weak passwords.
While remediating these accounts can be as simple as unchecking a checkbox, their detection can be trickier, as this account option results in a modification of the userAccountControl attribute.
The script below can assist with finding these misconfigured accounts, but to provide real time monitoring tools such as Microsoft Defender for Identity should be implemented.
$Params = @{
Filter = 'userAccountControl -band 4194304'
Properties = 'userAccountControl'
}
Get-ADUser @Params
How is AS-Rep Roasting Performed?
Attackers have a suite of tools to detect accounts susceptible to AS-REP roasting and exploit their weakness, which allows them to gain a foothold in your network and potentially move laterally. These attacks are especially dangerous since they require no authentication and little effort to execute. In the example below, an attacker can make the AS-REQ request for the account BigBadWolf and the domain controller provides the attacker with a TGT in the AS-REP packet encrypted with the password hash of the account. Since the BigBadWolf account did not require pre-authentication, the attacker requires no access to existing credentials to gain this information from the domain. Coupled with the use of weak passwords, attackers are easily able to crack the password hash of the effected accounts and utilize these newly gained credentials to move laterally in the environment.
Kerberoasting: Exploiting Authorization
While AS-REP roasting is an exploitation of the authentication process due to a lack of pre-authentication requirement, Kerberoasting exploits the core process of the Kerberos authorization process. Any user with valid authentication, or a TGT, can request a TGS ticket for any service. This makes Kerberoasting especially difficult to detect and mitigate against, since in most environments these malicious requests blend in with legitimate requests. After attackers have established initial access, they may pivot to this attack to move laterally via the exploitation of a privileged account configured with a Service Principal Name (SPN).
Kerberoasting is classified as a post-exploitation attack, due to the fact it requires a valid account to authenticate and forge Kerberos tickets. Privileged accounts that have been set up with a SPN and use a weak encryption type or weak password are especially susceptible to this attack, as their password hash will decrypt in less time and with less computational effort. Once the attacker has obtained these credentials, the risk of a Golden Ticket Attack increases as they are able to move through an environment in their efforts to gain access to privileged accounts, high-value resources, or sensitive information, including personal identifiable information (PII).
How is Kerberoasting Performed?
Kerberoasting activity can only take place following the acquisition of valid domain credentials. In the example below attackers have compromised the account BigBadWolf and use a tool to coerce a domain controller to provide a TGS, which is encrypted with the password of the privileged account PapaBear. This provides the threat actor with the password hash of this privileged account, which they are then able to crack the password with brute force due to the weakness of the password. This allows the attackers lateral movement using these newly gathered elevated privileges.
The misconfigurations related to Kerberoasting are found in privileged accounts that have unnecessarily been configured with a SPN, valid service accounts which have weak passwords or use of weak encryption types, specifically RC4.
Mitigations
Protecting your Active Directory from Kerberoasting attacks starts with effective Kerberos management, including :
- Rotate the KRBTGT password annually.
- Remove SPNs assigned to privileged accounts.
- Ensure Kerberos pre-authentication is required for all accounts in the directory.
- Audit for use of RC4 ticket encryption types and ensure accounts have AES128/256 enabled.
- Use strong passwords for privileged service accounts and rotate them annually.
- Migrate privileged service accounts to Group Managed Service Accounts (gMSA) when applicable.
Ravenswood’s AD Checklist outlines additional steps required to begin protecting your Active Directory environment.
Conclusion
While Microsoft continues to improve the Kerberos protocol, many organizations need to focus on the beginning steps to detect and mitigate any potentially Kerberoastable accounts, detect the use of weak ticket encryption types, and confirm that pre-authentication is required for all accounts. Andy Schneider provides additional insight into how an Active Directory cleanup can enhance your environment’s security and performance in this article Active Directory Cleanup: Enhancing Security and Performance.
If you need advice on how to detect and mitigate AS-REPRoastable or Kerberoastable accounts in your environment or setup Azure Sentinel to detect use of weak ticket encryption types, don’t hesitate to reach out to Ravenswood today.
