Kerberos hardening: RC4, roasting and golden tickets

Kerberos is the backbone of AD authentication, and its offline-crackable ticket formats make it a favorite target: Kerberoasting and AS-REP roasting turn any domain-joined attacker into a password cracker running against your DC's own responses, while golden and silver tickets let an attacker who's already compromised krbtgt or a service account forge authentication indefinitely. None of this requires a vulnerability — it works against Kerberos exactly as designed when encryption types and account settings are left at legacy defaults.

This guide covers encryption hardening, pre-authentication and SPN hygiene, the krbtgt double-reset procedure, Kerberos armoring, and how to monitor for ticket-forgery abuse.

Enforce AES, disable RC4

Every account (user, computer, and service) has an msDS-SupportedEncryptionTypes attribute controlling which Kerberos encryption types it will accept. Legacy defaults often still permit RC4-HMAC, which is far weaker to crack offline than AES-256.

Check current state domain-wide

# Accounts still permitting RC4, or unset (the KDC then applies its default, which still includes RC4)
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 -or -not $_."msDS-SupportedEncryptionTypes" } |
    Select-Object Name, msDS-SupportedEncryptionTypes

Encryption type bit values: 1 = DES-CBC-CRC, 2 = DES-CBC-MD5, 4 = RC4-HMAC, 8 = AES128, 16 = AES256. A value of 24 means AES128+AES256 only (no RC4/DES) — that's the target state.

Enforce via GPO

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

Check only AES128_HMAC_SHA1 and AES256_HMAC_SHA1 (and Future encryption types if offered). Leave DES and RC4_HMAC_MD5 unchecked.

Set per-account via PowerShell

# Set AES-only (value 24) on a specific service account
Set-ADUser -Identity "svc-sqlreporting" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Bulk-remediate all user accounts still allowing RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 } |
    ForEach-Object { Set-ADUser -Identity $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24} }

Verify

# Confirm no accounts still advertise RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 }
# Should return nothing

# Audit actual ticket encryption in use via Security event log on DCs
# Event ID 4768 (TGT request) / 4769 (service ticket request) — field "Ticket Encryption Type"
# 0x12 = AES256, 0x17 = RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 200 |
    ForEach-Object { [xml]$_.ToXml() } |
    ForEach-Object { $_.Event.EventData.Data | Where-Object Name -eq 'TicketEncryptionType' } |
    Group-Object '#text'

Any 0x17 (RC4) entries after enforcement indicate a client or service still negotiating down — investigate before assuming RC4 is fully eliminated.

Pre-authentication and AS-REP roasting

Kerberos pre-authentication requires a client to encrypt a timestamp with their password-derived key before the KDC issues a TGT — proof of password knowledge before any ticket material is handed out. The DONT_REQ_PREAUTH account flag disables this, letting anyone request an AS-REP for that account without any credential, then crack the returned ticket offline against the account's password. See AS-REP roasting for the conceptual attack path.

# Find accounts with pre-authentication disabled
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
    Select-Object Name, SamAccountName

# Remediate: clear the DONT_REQ_PREAUTH flag
Set-ADAccountControl -Identity "jsmith" -DoesNotRequirePreAuth $false

There is rarely a legitimate reason for this flag outside specific legacy interoperability cases — treat any hit as a finding.

Kerberoasting risk from SPNs on user accounts

Kerberoasting doesn't require any account misconfiguration flag — any authenticated user can request a service ticket for any account with a Service Principal Name (SPN), then attempt to crack the ticket offline. The risk is concentrated on user accounts used as service accounts, because they typically have human-chosen (weaker, reused) passwords, unlike computer accounts, which have long randomized passwords rotated automatically. See Kerberoasting.

# Find user accounts (not computer accounts) with an SPN set
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet |
    Select-Object Name, ServicePrincipalName, PasswordLastSet

Mitigations, in order of effectiveness:

1. Migrate service accounts to Group Managed Service Accounts (gMSAs) — 240-byte (120-character) randomized passwords rotated automatically, immune to practical offline cracking.
2. Where gMSAs aren't supported, use long (25+ character), randomly generated passwords stored in a password vault, never human-memorized.
3. Ensure msDS-SupportedEncryptionTypes is AES-only for every SPN-bearing account — AES-256 tickets are dramatically more expensive to crack than RC4.
4. Add high-value SPN accounts to Protected Users where compatible (see Tier 0 & Privileged Access).

The krbtgt double-reset procedure

The krbtgt account's password derives the key used to sign every Kerberos TGT in the domain. If it's ever compromised — directly or via a DCSync-style extraction — an attacker can forge TGTs (golden tickets) for any user, including ones that don't exist in AD, valid until you rotate the key. See DCSync.

Why two resets, spaced apart: AD keeps both the current and previous krbtgt password hash valid, so a single reset doesn't immediately invalidate tickets forged with the old hash — the DC will still accept them under the "previous password" fallback. You must reset twice, with a gap of at least the maximum Kerberos ticket lifetime (default MaxTicketAge = 10 hours; check your domain's actual MaxTicketAge/MaxRenewAge policy, which may be extended to days), so the first new password fully rotates out of both slots before the second reset is applied.

# Check current ticket lifetime policy first — determines your reset spacing
# Kerberos policy is not an AD attribute; it lives in the Default Domain Policy GPO:
# Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy
[xml]$r = Get-GPOReport -Name "Default Domain Policy" -ReportType Xml
$r.GPO.Computer.ExtensionData.Extension.Account | Where-Object Type -eq 'Kerberos' | Select-Object Name, SettingNumber

# Reset 1
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random>" -Force)

# --- wait at least MaxTicketAge (commonly 10 hours; confirm your domain's value) ---

# Reset 2
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random-2>" -Force)

Use Microsoft's published New-KrbtgtKeys.ps1 script (or equivalent vetted tooling) rather than ad hoc resets in multi-DC environments — it handles replication convergence checks between the two resets so you don't rotate before all DCs have the first change. In a multi-domain forest, repeat this for every domain's krbtgt account, not just the forest root.

Run this rotation on a recurring schedule (many organizations do it quarterly or after any suspected credential compromise), not only as incident response.

Kerberos armoring / FAST

FAST (Flexible Authentication Secure Tunneling), enabled via Kerberos Armoring, wraps the initial AS-REQ exchange in an encrypted, authenticated channel using the requesting computer's own credentials, protecting pre-authentication data and reducing exposure to offline attacks against weak user passwords.

Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring (named Support Dynamic Access Control and Kerberos armoring on Windows Server 2012) — set to Supported on DCs first, then to Fail unarmored authentication requests only once all DCs and clients support it. On clients: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring.

Requires domain functional level 2012 or higher and all DCs updated before enforcing.

Golden and silver tickets: how these mitigations combine

A golden ticket forges a TGT using a stolen krbtgt hash; a silver ticket forges a service ticket using a stolen service account hash, without ever touching the KDC. Neither is a vulnerability to "patch" — they're abuse of legitimate Kerberos trust once a key is stolen. Defense is layered:

• AES-only + Protected Users on Tier 0 and service accounts makes the hashes themselves harder to obtain and harder to crack if exfiltrated.
• krbtgt rotation (above) invalidates any previously forged golden tickets and limits the value of a stolen hash going forward.
• Monitoring for anomalies: TGTs with unusually long lifetimes, tickets for accounts that don't exist, or Event ID 4624/4768 patterns inconsistent with normal logon sources.

# A forged golden ticket never produces a 4768, so 4769s from an account with no matching
# 4768 on any DC are the anomaly to look for. Run this against every DC (or query your SIEM)
# over a window longer than the TGT lifetime (10 h by default): one DC alone gives false positives.
$since  = (Get-Date).AddHours(-12)
$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769; StartTime=$since} |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            Id      = $_.Id
            # 4769 logs user@REALM, 4768 logs the bare name: normalise before comparing
            Account = (($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text' -split '@')[0]
        }
    }
$withTgt = $events | Where-Object Id -eq 4768 | Select-Object -ExpandProperty Account -Unique
$events | Where-Object { $_.Id -eq 4769 -and $_.Account -notin $withTgt } |
    Group-Object Account | Sort-Object Count -Descending | Select-Object Name, Count

What it breaks

• Legacy applications and network appliances (older NAS devices, some backup software, older Linux/Java Kerberos clients, certain SCADA/industrial systems) that only support RC4 will fail authentication once RC4 is disabled domain-wide. Audit Event ID 4769 TicketEncryptionType for 90 days before enforcing to catch these.
• Third-party or older Samba-based file shares may not support AES256 out of the box — verify before cutover.
• The krbtgt double-reset, when properly spaced, has little visible impact because the DC still accepts TGTs signed with the previous key. Resetting twice in quick succession (the incident-response case), or doing the second reset before the first has replicated, invalidates every outstanding TGT in that domain and forces users and services to re-authenticate — schedule a low-impact window and expect a wave of re-logons.
• Kerberos armoring enforcement requires every DC and client OS to support FAST; mixed environments with legacy DCs will break authentication if set to "Fail unarmored authentication requests" prematurely.

Related reading: Tier 0 & Privileged Access for account-level protections, Delegation for how forged tickets combine with delegation abuse, and NTLM & legacy protocols for the authentication layer Kerberos is meant to replace.