A Minute of Weak Tickets: Catching Kerberoasting in DC Logs

In Active Directory, a service such as SQL Server runs under an account that has a service principal name (SPN). To reach it, a user asks the domain controller for a Kerberos service ticket, and part of that ticket is encrypted with a key derived from the service account's password. Any authenticated user may ask for a ticket to any SPN, so the request is normal and succeeds.

Kerberoasting (MITRE ATT&CK T1558.003, presented by Tim Medin in 2014) asks for those tickets in bulk and cracks them offline, where no log can see it. RC4 tickets (0x17) are the prize: their key is the account's NT hash, which GPUs test orders of magnitude faster than the salted, iterated AES keys (0x12), so a human-chosen service account password falls quickly. MITRE lists its use by ransomware groups such as Wizard Spider and by APT29 in the SolarWinds compromise.

The domain controller records every ticket as event 4769, and the ticket's encryption is decided by the service account. Microsoft announced that from mid-2026 domain controllers allow only AES by default, with RC4 only where an administrator enables it; Ashgrove kept it on for an old ERP client, so its eight older service accounts, never given an AES setting, still hand out RC4 tickets to anyone, while computer accounts and the gMSA get AES. Microsoft's guidance for this event is to watch for ticket encryption other than 0x11 and 0x12; MITRE adds the shape: one account requesting an unusual number of service tickets in a short period.

• Answering svc_erpbatch. It has exactly as many RC4 tickets as the attacker, but always for one service, svc_sqlerp, every two minutes from the ERP server: a scheduled job on a legacy account, an exception to retire, not an attack. Count distinct services per account, not rows.
• Answering svc_tenable. Five services in fourteen seconds is the vulnerability scanner's credentialed scan: AES tickets, for computer accounts (names ending in $) whose passwords are long, random and rotated, so not worth roasting.
• Answering a.quintero. One RC4 ticket for svc_crm is a user opening the CRM, which still runs under a legacy account. RC4 alone is not the signal.
• Answering a roasted service account. svc_sql, svc_backup and the others are the victims: their tickets were requested. The question asks who requested them.
• Answering the workstation. WKS-0417 (10.20.14.37) is where the requests came from and the machine to isolate, but the tickets were issued to the c.ferrante account.
• Looking for failures. Every row has failure code 0x0: a Kerberoast is made of successful, perfectly valid requests.

Make the tickets worthless to crack, then make the request pattern loud.

• Give every service account AES: set msDS-SupportedEncryptionTypes to 0x18 (AES128 + AES256) and reset its password once so AES keys exist. Then retire the RC4 exception: upgrade the ERP client and let RC4 go, as Microsoft's new defaults intend.
• Move services to group managed service accounts (gMSA): the domain gives them long random passwords and rotates them, so a stolen ticket cannot be cracked. Where that is impossible, use a random password of 25+ characters, as MITRE advises, and rotate it.
• Remove SPNs nobody uses and keep service accounts out of privileged groups such as Domain Admins.
• Enable Audit Kerberos Service Ticket Operations on every domain controller and alert when one account gets RC4 (0x17) tickets for several distinct services within a minute; skip services ending in $ and allowlist known legacy pairs such as svc_erpbatch to svc_sqlerp. A honeypot account with an SPN that nothing uses turns any ticket request for it into a high-confidence alert.
• Respond: reset the passwords of the eight roasted service accounts now (the tickets are already offline), isolate WKS-0417 and investigate the c.ferrante session.