Kerberoasting has become the red team’s best friend over the past several years, with various tools being built to support this technique. However, by failing to understand a fundamental detail concerning account encryption support, we haven’t understood the entire picture. This talk will revisit our favorite TTP, bringing a deeper understanding to how the attack works, what we’ve been missing, and what new tooling and approaches to kerberoasting exist.

1. SpecterOps Webinar Week
Monday – Hunting from Home
Tuesday – Everything You Always Wanted To Know About BloodHound* (*But were afraid to ask)
Wednesday – Kerberoasting Revisited
Thursday – Capability Abstraction: Dumping LSASS
Friday – Remote Team Project Management and Reporting Construction

2. Introduction
• Job: Technical Architect at SpecterOps
• Code: Veil-Framework, Empire, PowerView/PowerUp, BloodHound,
GhostPack
• Cons: DerbyCon, BlackHat, DEF CON, Troopers, ShmooCon
• Training: Adversary Tactics: Red Team Operations, Adversary Tactics:
PowerShell (now open source!), veteran BlackHat trainer
-2-

3. Overview
• Exactly how Kerberoasting works
• msDS-SupportedEncryptionTypes
• Previous Kerberoasting Approaches
• Building a Better Kerberoast With Rubeus
• Defenses (and Kerberoasting OPSEC)
-3-

4. Kerberoasting: The Beginning
Thanks
@timmeddin!
-4-

5. -5-
WMI
computer.domain.com
PowerShell
Remoting
File
Share
SQL
HOST/
HTTP/
HOST/
RPCSS/
CIFS/
MSSQLSvc/
dir computer.domain.comC$
1. Here’s my TGT.
I want a service ticket for:
CIFS/computer.domain.com
2. Service ticket
returned:
CIFS/computer.domain.com
3. Use service ticket:
CIFS/computer.domain.com
domain.com
Domain Controller
Attacker

6. -6-
dir computer.domain.comC$
1. Here’s my TGT.
I want a service ticket for:
CIFS/computer.domain.com
2. Look up which (user or
computer$) account has the
CIFS/computer.domain.com
service principal name
(SPN) registered
3. Encrypt part of the service
ticket with the key of looked-
up account (computer$
here)
4. Target service decrypts
the service ticket w/ shared
computer$ key.
Target service decides
whether to allow access!
computer.domain.com
File
Share
CIFS/
domain.com
Domain Controller
Attacker

7. Kerberoasting 101:Background
• The target service and the domain controller have to share some key
so the service can decrypt the ticket
• For most service principal names (SPNs) this is the computer$
account key/hash
• Computer accounts (by default) have random passwords that every 30 days
• But if the SPN is registered for a user account, we now have a piece of
data that’s encrypted with their key
• Requesting this and cracking offline == Kerberoasting !
-7-

8. Kerberoasting 101: Using the Goods
• If a user account has an SPN registered, the user often:
• has admin privileges on the machine specified in the SPN
• and/or is in other privileged domain groups
• Even if they don’t/aren’t, with the key cracked, we can forge service
tickets as ANY user to the specific service principal name
• This is what “silver tickets” are!
-8-

9. Kerberoasting 101: Why Care
• ANY user can request a service ticket for ANY SPN (by design!)
• This service ticket give us a piece of information encrypted with the
key/hash of the (user) account that backs that SPN
• We only communicate with the DC - no packets are sent to the service
target unless we try to use the requested ticket!
• Translation: if a user has a non-null servicePrincipalName property,
we can crack their password offline (with GPU-accelerated software!)
-9-

10. Kerberoasting 201: Key Encryption Types
• Service tickets (just like TGTs) generally use either
AES256_CTS_HMAC_SHA1_96 (AES256) or RC4_HMAC_MD5
(RC4/NTLM) keys for ticket encryption
• AES encryption was introduced with domain functional level 2008, but RC4 has
been kept for backwards compatibility reasons
• From an offensive perspective, we really want responses encrypted
with RC4, since it’s orders of magnitude faster to crack than AES
-10-

11. Sidenote:Kerberoasting Defenses
• Modern (2008+ functional level) Active Directory domains are
supposed to use AES keys by default for Kerberos exchanges
• So requesting a RC4 service ticket should result in “encryption
downgrade activity”
• But built-in request methods for user-backed SPNs nearly always
return RC4-encrypted service tickets 🤔
-11-

12. Encryption “Downgrade”
-12-

13. msDS-SupportedEncryptionTypes
• Active Directory user/computer account property touched on by Jim
Shaver and Mitchell Hennigan in their DerbyCon 7.0 “Return From
The Underworld” talk
• According to Microsoft’s [MS-ADA2], “The Key Distribution Center
(KDC) uses this information [msDS-SupportedEncryptionTypes] while
generating a service ticket for this account.”
• Translation: this property (on an account with a non-null SPN)
determines the encryption used for service tickets requested for that
account’s SPN(s)
-13-

14. msDS-SupportedEncryptionTypes
• According to MS-KILE 3.1.1.5 the default value for this field is 0x1C
(RC4 | AES128 | AES256 = 28) for Windows 7+ and Server 2008R2+
• However, this property is only set by default on computer accounts
(not user or trust accounts!)
• If this property is not defined (or is set to 0) [MS-KILE] 3.3.5.7 says default
behavior is to use a value of 0x7 (RC4)
-14-

15. However we can set user accounts to
explicitly support AES 128/256
encryption
0x18 (AES128 | AES256 = 24)
-15-

16. -16-
However…
🤔

17. So What?
• There doesn’t seem to be an easy way to disable RC4_HMAC service
ticket requests on user accounts, meaning we can’t “stop” RC4
Kerberoasting
• The reason for this behavior is in case accounts were created in a 2003
functional level domain and haven’t had their passwords changed since
• We can disable RC4 for the entire domain, but this also kills RC4 TGTs, which
isn’t feasible for most environments
• However setting AES support for user accounts at least gives us the
“encryption downgrade” detection back
-17-

18. Kerberoasting Approaches
-18-
External-In
-Need creds (pw/hash) of existing
domain account to first get a TGT so
service tickets can be requested
-More difficult over high latency C2
-But can granularly control all
aspects of the exchange (i.e. RC4)
Domain-Joined Windows Host
-Don’t need credentials, just
execution in a domain user’s context
-Easier over high latency C2
-Built-in request methods don’t let
you control aspects (like encryption
levels) of the exchange

19. Previous Kerberoasting Approaches (Host)
• The previous domain-joined Kerberoasting methods involve using
setspn.exe or .NET’s KerberosRequestorSecurityToken class to request
a service ticket for a target SPN
• The tickets are then carved out of memory (Mimikatz) or extracted
using the .NET methods (PowerView)
• Unintended downside: this will cache a ticket on the requesting
machine for each SPN we roast! (could be hundreds of tickets…)
-19-

20. Downsides of Built-in Ticket Request Methods
• .NET/setspn approaches request/cache dozens (or hundreds) of
service tickets on the attacker host
• .NET’s KerberosRequestorSecurityToken method doesn’t let you
specify encryption levels (RC4 vs AES) for ticket requests
• Since we don’t have a proper TGT, we can’t hard specify RC4 like
Impacket/Metasploit
• Normally, the session key for the TGT is not exportable for non-
elevated contexts, so we can’t get a usable TGT for a regular user
• Or can we…
-20-

21. Obtaining a User’s TGT: The “tgtdeleg” Trick
• @gentilkiwi realized we can request an outgoing service ticket
request for a SPN on an unconstrained delegation server (the domain
controller)
• This results in a delegated TGT for the current user being present in
the AP-REQ in a way we can retrieve it
• Translation: we get a usable TGT for the current user!
-21-

22. Rubeus:Building a Better Kerberoast
• Rubeus implements the structures needed for service ticket
requests/responses
• Rubeus also implements Kekeo’s tgtdeleg trick
• Combined, this allows us to kerberoast while:
• not needing the current user’s key/password
• avoiding caching service tickets on the attacker-controlled host
• specifying RC4 in the service ticket requests
-22-

23. Rubeus:
Kerberoasting Opsec
-23-

24. Kerberoasting Defenses
• Use long passwords for accounts with SPNs, or use a password
vaulting solution to rotate service account passwords
• Still the best solution (in my opinion)
• Check for RC4 encryption in service ticket requests/responses
• Not useful unless the account is explicitly configured for AES
• Detect “anomalous” service ticket requests
• Requires tracking state of all ticket requests in a domain, not a trivial task
• Use of a Kerberoasting “honeypot”
• Talked about by Sean Metcalf – create an account with a non-null SPN and
monitor for any ticket requests (event 4769)
-24-

25. OPSEC: Defeating the Defenses
• Don’t just Rubeus.exe kerberoast the entire domain at once!
• Plan your attack paths first and only Kerberoast necessarily accounts
• Check group membership and other properties of your target before roasting
• Rubeus.exe kerberoast /stats will break down encryption types and password
last set years for kerberoastable users
• Why not just Kerberoast accounts with password last set date prior
to, say, Sean’s blog post J
• Rubeus.exe kerberoast /pwdsetbefore:01-01-2017 /resultlimit:10
-25-

26. Thank you!
• Any Questions?
• https://twitter.com/harmj0y
• Get Rubeus
• https://github.com/GhostPack/Rubeus
• Read More:
• https://posts.specterops.io/kerberoasting-revisited-d434351bd4d1
-26-

27. Monday – Hunting from Home
Tuesday – Everything You Always Wanted To Know About BloodHound* (*But were afraid to ask)
Wednesday – Kerberoasting Revisited
Thursday – Capability Abstraction: Dumping LSASS
Friday – Remote Team Project Management and Reporting Construction
www.specterops.io
@specterops
info@specterops.io