This is an etype-inventory lab, not a ticket-cracking note. Target is a fake lab domain LAB.INTERNAL where most principals speak AES-256 and one leftover service account still advertises RC4. Goal: klist the encryption types on a TGT and a service ticket, dump msDS-SupportedEncryptionTypes, and show the GPO Network security: Configure encryption types allowed for Kerberos as I set it in the lab. I do not request an RC4 TGS to crack, I do not overwrite krbtgt, I do not pass-the-hash.

1Figure 1. Advertised etypes are intent. 4769 Ticket Encryption Type is what the KDC actually issued.
2account / GPO advertised etypes
3        ->  AS or TGS negotiation
4        ->  ticket enc-part under chosen etype
5klist -e  and  4769  0x12=AES256  0x17=RC4  0x03=DES

Lab layout

1labs/etype_lab/
2  klist.txt
3  getad-etypes.txt
4  gpo.txt
5  4768-4769.txt

Domain LAB.INTERNAL. User labuser (AES). Service svc-legacy (RC4 still in supported types — the finding). DC dc01.lab.internal. Isolated. SIDs [REDACTED].

Artifact: klist encryption types

Windows, after a normal logon and a hit to HTTP/web01.lab.internal:

 1C:\lab> klist
 2Current LogonId is 0:0x[REDACTED]
 3
 4Cached Tickets: (2)
 5
 6#0>     Client: labuser @ LAB.INTERNAL
 7        Server: krbtgt/LAB.INTERNAL @ LAB.INTERNAL
 8        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 9        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent
10        Start Time: 8/8/2023 10:12:04 (local)
11        End Time:   8/8/2023 20:12:04 (local)
12        Renew Time: 8/15/2023 10:12:04 (local)
13        Session Key Type: AES-256-CTS-HMAC-SHA1-96
14        Cache Flags: 0x1 -> PRIMARY
15        Kdc Called: dc01.lab.internal
16
17#1>     Client: labuser @ LAB.INTERNAL
18        Server: HTTP/web01.lab.internal @ LAB.INTERNAL
19        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
20        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent
21        Session Key Type: AES-256-CTS-HMAC-SHA1-96
22        Kdc Called: dc01.lab.internal

Both tickets AES-256-CTS-HMAC-SHA1-96. Session key type matches. That is the desired row.

Linux klist -e (MIT/Heimdal/SSSD — flag exists on MIT):

1$ klist -e
2Ticket cache: FILE:/tmp/krb5cc_[REDACTED]
3Default principal: labuser@LAB.INTERNAL
4
5Valid starting     Expires            Service principal
608/08/23 10:12:04  08/08/23 20:12:04  krbtgt/LAB.INTERNAL@LAB.INTERNAL
7        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
808/08/23 10:12:11  08/08/23 20:12:04  HTTP/web01.lab.internal@LAB.INTERNAL
9        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

skey is the session key; tkt is the ticket enc-part. Both AES-256 here. An rc4-hmac on either column for this user is a finding. A des-cbc-md5 is an incident.

Supported etypes table

Wire numbers I keep next to 4768/4769 Ticket Encryption Type:

EtypeNameLab policy
1des-cbc-crcrefuse
3des-cbc-md5refuse
17aes128-cts-hmac-sha1-96allow
18aes256-cts-hmac-sha1-96allow (preferred)
23rc4-hmacexception list only
24rc4-hmac-exprefuse

msDS-SupportedEncryptionTypes on the account is a bitmask, not the wire number. Bits I actually decode:

BitMaskMeaning
00x1DES-CBC-CRC
10x2DES-CBC-MD5
20x4RC4-HMAC
30x8AES128
40x10AES256
50x20AES256 SK (newer)
1PS C:\lab> Get-ADUser labuser, svc-legacy -Properties msDS-SupportedEncryptionTypes |
2            select SamAccountName, 'msDS-SupportedEncryptionTypes'
3
4SamAccountName msDS-SupportedEncryptionTypes
5-------------- -----------------------------
6labuser                                 24
7svc-legacy                               4

24 = 0x18 = AES128 | AES256 — labuser is clean. 4 = 0x4 = RC4-HMAC only — svc-legacy is the leftover. I do not then ask the KDC for an RC4 TGS for that account to “see if it works”. 4769 already tells me when it does.

Computer objects, same attribute:

1PS C:\lab> Get-ADComputer WEB01, DC01 -Properties msDS-SupportedEncryptionTypes |
2            select Name, msDS-SupportedEncryptionTypes
3Name  msDS-SupportedEncryptionTypes
4----  -----------------------------
5WEB01                            28
6DC01                             28
7# 28 = 0x1C = RC4|AES128|AES256  (common default; RC4 still advertised)

Default computer 0x1C still includes RC4. That is why a domain-wide GPO is required; attribute stamps on users are not enough.

GPO: Network security: Configure encryption types allowed for Kerberos

Path I click in the lab GPMC:

1Computer Configuration
2  -> Policies
3    -> Windows Settings
4      -> Security Settings
5        -> Local Policies
6          -> Security Options
7            -> Network security: Configure encryption types allowed for Kerberos

Lab GPO LAB-Kerb-Etypes linked at OU=workstations,DC=lab,DC=internal and at OU=servers,DC=lab,DC=internal. Checkboxes:

1DES_CBC_CRC          : disabled
2DES_CBC_MD5          : disabled
3RC4_HMAC_MD5         : disabled     # workstation/server OU
4AES128_HMAC_SHA1     : enabled
5AES256_HMAC_SHA1     : enabled
6Future encryption types: enabled

Registry the GPO writes (exported from a lab workstation after gpupdate /force):

1Windows Registry Editor Version 5.00
2
3[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
4"SupportedEncryptionTypes"=dword:00000018

0x18 = AES128 | AES256. Same number as labuser’s AD attribute. DES bits off. RC4 bit off in this OU.

Exception OU OU=legacy-appliances,DC=lab,DC=internal keeps 0x1C (RC4|AES128|AES256) with an owner and a kill date on the GPO comment. svc-legacy lives there. I do not widen the domain default to make that account happy.

1C:\lab> gpresult /h gp.html
2C:\lab> findstr /i "encryption types" gp.txt
3Network security: Configure encryption types allowed for Kerberos
4  AES128_HMAC_SHA1, AES256_HMAC_SHA1
5  Winning GPO: LAB-Kerb-Etypes

4768 / 4769: ground truth of negotiation

 1Event 4768  A Kerberos authentication ticket (TGT) was requested.
 2Account Information:
 3  Account Name:        labuser
 4  Account Domain:      LAB.INTERNAL
 5Ticket Options:        0x40810010
 6Result Code:           0x0
 7Ticket Encryption Type: 0x12          # 18 = AES256
 8Pre-Authentication Type: 2            # PA-ENC-TIMESTAMP
 9Client Address:        ::ffff:10.0.10.50
10Certificate Information: -

1Event 4769  A Kerberos service ticket was requested.
2Account Name:          labuser@LAB.INTERNAL
3Service Name:          HTTP/web01.lab.internal
4Ticket Encryption Type: 0x12          # AES256
5Failure Code:          0x0

SIEM query I actually keep (not a cracker):

1# any DES
2EventID=4768 OR EventID=4769
3Ticket Encryption Type IN (0x1, 0x3)
4# => page immediately
5
6# RC4 for privileged / krbtgt
7EventID=4768 OR EventID=4769
8Ticket Encryption Type=0x17
9Account Name IN (Administrator, lab-da, krbtgt, *_admin)

I pulled one 4769 for svc-legacy from last week’s lab traffic (app talking to the leftover). Redacted:

1Event 4769
2  Account Name:          svc-legacy@LAB.INTERNAL
3  Service Name:          krbtgt
4  Ticket Encryption Type: 0x17        # RC4 — expected until the exception dies
5  Failure Code:          0x0

That line is why the account is on the exception list. The fix is AES on the principal + password/key reset so an AES key exists, then drop RC4 from the GPO. I do not “verify” by offline-guessing the RC4 ticket.

Mitigation

  1. Discover: export msDS-SupportedEncryptionTypes; SIEM-summarize 4768/4769 etypes for 30 days.
  2. Stamp AES (0x18 or 0x10) on users/computers/service accounts. gMSA where it fits.
  3. GPO: disable DES everywhere; disable RC4 at domain level once the exception OU is the only RC4 left.
  4. Reset passwords / keys after etype changes so AES keys are actually populated (long-lived service accounts especially).
  5. Trusts: review accepted etypes with partner forests. A trust that still allows DES is a forest finding.
  6. klist on a DA workstation showing RC4 is a policy failure the same day, not a Kerberos inevitability.

Rollout I used in this lab:

1Inventory  ->  Pilot AES-only OU (workstations)  ->  servers  ->  block DES
2                 ->  exception OU for svc-legacy (owner, expiry)
3                 ->  block RC4 domain-wide when that OU is empty

What I file after this lab

  • klist: TGT and HTTP/web01 both AES-256-CTS-HMAC-SHA1-96
  • Table: etype 18 AES256, 23 RC4, 1/3 DES
  • AD: labuser msDS-SupportedEncryptionTypes=24; svc-legacy=4 (RC4 only)
  • GPO: Network security: Configure encryption types allowed for Kerberos → AES128+AES256, registry 0x18
  • 4768/4769 for labuser: Ticket Encryption Type 0x12; svc-legacy 4769 0x17 on the exception list
  • Out of scope: RC4 ticket cracking, krbtgt reset as a trick, pass-the-hash

Commands appendix

1klist
2klist -e
3Get-ADUser labuser,svc-legacy -Properties msDS-SupportedEncryptionTypes
4Get-ADComputer WEB01 -Properties msDS-SupportedEncryptionTypes
5gpresult /h gp.html
6wevtutil qe Security /q:"*[System[(EventID=4769)]]" /c:5 /f:text
7# registry after gpupdate:
8reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters