1

The first step in a kerberoasting attack is to discover Service Accounts via AD enumeration. One way to do so is searching LDAP for any registered SPNs (Service Principal Names). However, from my understanding, service accounts may exist with no SPNs set. This seems to be confirmed here, specifically;

While SPNs are very reliable and informative, they will not produce a comprehensive list of service accounts. Many accounts do not integrate with Kerberos through SPNs and will have no SPN values set.

And indeed, In my enumeration of LDAP I find service accounts, with names such as "svc_webapp1", "svc_program" etc (the description and DN also suggest these are service accounts).

The next step in the attack is to request tickets for said service accounts. However, the only way I'm finding online to request service tickets is via the KerberosRequestorSecurityToken class, i.e.;

System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList '[ServicePrincipalName_to_request_ticket_for_GOES_HERE]'

This requires/assumes the account(s) you want tickets for have SPN(s) set, but the service accounts I have found do not have SPNs registered/set. Is it possible to request tickets for these accounts anyways (possibly via some attribute other then SPN, or some other class)?

1 Answer 1

4

A service ticket is a very specific thing. Active Directory will only let you request service tickets to principals that have SPNs registered because otherwise it's not a service principal as far as Kerberos is concerned. This is for correctness and security reasons.

If services really need to use Kerberos to authenticate to a principal that doesn't have an SPN available to it, it will attempt User-to-User authentication which relies on shuffling the encrypted TGT between users and the KDC, and encrypting the service ticket to the service TGT's session key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .