SOC Analyst Perspective - AS-REP ROASTING

What is AS-REP Roasting?

Keeping it simple: An AS-REP Roasting Attack occurs when an attacker exploits an account that does not require pre-authentication (which is typical in Kerberos authentication). The attacker can then request a TGT for this account without actually confirming they are the actual user.  

Signs of AS-REP Roasting Attack:

Here is where I am at mentally:

• What does pre-authentication look like?

• How do I find an account that does not require pre-authentication?

I am beating a dead horse, but let’s define normal ticket requesting (TGT) activity.

Remember these two terms: Authentication Server Request (AS-REQ) and Authentication Server Reply (AS-REP).

A user sends an initial authentication request (AS-REQ) to the Key Distribution Center (KDC), specifically the Authentication Server in the KDC, as part of a request for the TGT. The authentication request from the user includes important sections such as an encrypted timestamp: the client’s current time value encrypted with a key derived from the user’s password/hash.

Overall, the client is telling the AS, “I am who I say I am”, and the KDC validates against its own records to say, “You are who you say you are”. Next, the Authentication Server Reply (AS-REP) is sent back with the requested TGT. The TGT is encrypted with the krbtgt account’s key. The AS-REP also contains a copy of the session key, which is randomly generated by the KDC and encrypted with a key derived from the user’s password hash. We could spend all day breaking down how keys are encrypted and how Kerberos works, but let’s move on.

Now, let’s define abnormal TGT activity.

With an account that does not require pre-authentication, the user can request a TGT and receive an AS-REP without the KDC performing validation.

Now, the user receives an AS-REP which includes a TGT that is also encrypted with the krbtgt account’s key. The other part of the AS-REP is a  copy of the session key information encrypted with a key derived from the user’s password hash.

Through password guesses, the attacker can try to guess the correct password for decryption. If decryption is successful, the password is then correct.

Afterwards, with a TGT, a user now request Ticket Granting Service tickets (TGS) and get access to services available to them.

Finding Pre-Authentication Disabled Accounts

By default, pre-authentication is enabled in Active Directory environments.

Note, this tactic would be under “Credential Access” for MITRE ATT&CK Framework.

Finding accounts where pre-authentication is disabled is not necessarily the difficult part, especially if you have access to PowerShell and can run LDAP queries. The difficult part is likely avoiding detection.