AS-REP roasting is a form of attack on the Kerberos authentication protocol that takes advantage of a known weakness in the protocol that can be exploited during initial authentication with a Key Distribution Center (KDC). AS-REP roasting allows a malicious actor to retrieve the password hash of any Kerberos user accounts that have the Do not require Kerberos preauthentication option enabled.
AS-REP roasting attacks can be launched from a variety of post-exploitation toolkits including Mimikatz, Rubeus, PowerShell and more. Consult the documentation for those tools for the commands needed to conduct an AS-REP attack.
Elements of a AS-REP roasting attack
Done manually, an AS-REP roasting attack consists of the following steps:
- Obtain access to a domain as an authenticated user. (Elevated permissions are not required.)
- Use an LDAP filter or tools like PowerView’s Get-DomainUser feature to crawl the domain and identify user accounts with the Do not require Kerberos preauthentication option enabled.
- Identify target account or accounts.
- Request a Kerberos Ticket Granting Ticket (TGT) from the Key Distribution Center in the name of a target account. The KDC will respond with the TGT for the account, without requiring the account password as a pre-authentication.
- Using a tool like Wireshark, extract the user’s password hash from the AS-REP packet. It can be found in the enc-part section of the packet.
- Use a tool like HashCat or John the Ripper to extract a plaintext password from the captured hash.
- Authenticate using the cracked password.
AS-REP roasting attacks are powerful “offline” attacks, in which hashed data captured from authentication sessions is cracked out of band using tools like Hashcat or Jack the Ripper. Importantly: AS-REP attacks do not required elevated permissions to carry out; any authenticated user account will work. Like other “roasting” attacks (i.e. kerberoasting), AS-REP attacks work best with weak passwords: short, with low entropy and created using an older hashing algorithm.
AS-REP is a Kerberos message type that refers to an "Authentication Service" (AS) response message. It is transmitted between a kerberos server and client as part of the exchange of credentials needed to access a service. To generate an AS-REP message, first, the kerberos client asks to Kerberos Domain Controller (KDC) for a Ticket Granting Ticket (TGT) and a session key that are needed to obtain credentials for other services.
After the ticket granting ticket has been issued, the service ticket can be requested. That involves two messages: an AS_REQ sent from the client to the kerberos server and an AS_REP, which is sent in response to the AS_REQ.
The AS-REP message contains the TGT and a session key which is used to request access to the intended service. The session key is encrypted with the requesting user’s password. AS-REP attacks are designed to extract and crack the session key, revealing the requesting account's password."
What Makes AS-REP Attacks Unique
AS-REP attacks work on Kerberos Authentication Tickets (TGTs) and do not require the attacker to know the password for the account they are attempting to compromise. Indeed: AS-REP roasting is a method by which an attacker can obtain the password for a target account, provided the Kerberos preauthentication feature is disabled for that account.
As indicated above, AS-REP roasting attacks work only on a subset of accounts with the Do not require Kerberos preauthentication option enabled. Modern, Kerberos 5 environments - properly configured - should provide little opportunity for AS-REP attacks. That’s because Kerberos 5 requires pre-authentication for all user accounts. Furthermore, newer Kerberos deployments use the stronger AES256-CTS-HMAC-SHA1-96 encryption method in the AS-REP rather than the older ARCFOUR-HMAC-MD5/RC4 encryption, complicating if not preventing offline cracking of the hash.
That said, disabling pre-authentication is not proof of malicious behavior. Pre-authentication may, for example, be disabled for backward compatibility with Kerberos 4 libraries. However, accounts with this option enabled should be a red flag and prompt an internal investigation of why this non-default behavior is enabled.
Detection and Mitigation of AS-REP Roasting Attacks
The best mitigation defenders have at their disposal against AS-REP roasting is to enforce robust password policies for service accounts. Organizations should mandate long, complicated passwords (25 or more characters) that are changed frequently. Length and complexity frustrates offline cracking efforts. Furthermore, frequent password rotation, say at 30-day intervals, narrows the window of time attackers have to crack long hashes.
Deploying Honey Accounts
As with Kerberoasting, detection of AS-REP roasting attacks requires logging and monitoring of activity. One way to make sure such activity gets noticed is with the use of so-called “honey accounts,” which work in a similar fashion to network honeypots: enticing advanced attackers doing reconnaissance through Active Directory with believable sounding service names. Once compromised, however, these accounts do nothing but trigger an alert if they are used to login or generate a service ticket request.
Technology such as Qomplx’s monitors for telltale signs of AS-REP roasting attacks, such as AS-REQ and AS-REP events in conjunction with unusual combinations of events like 4768 (TGT requested) followed by an invalid password credential (4625).
Beyond that, QOMPLX:CYBER’s Privilege Assurance product reduces the likelihood of AS-REP attacks by using analytics to highlight high risk accounts with pre-auth disabled and by alerting when new accounts are identified with pre-auth is disabled.
About this Series
This is the latest in a series of posts we are calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving the malicious campaigns that QOMPLX front line staff encounters in our work with customers.