The document outlines a week of webinars hosted by SpecterOps, focusing on topics like kerberoasting, adversary tactics, and remote project management. It delves into the mechanics of kerberoasting, including how to exploit service tickets and the various encryption types used in Active Directory. Additionally, it suggests defenses against kerberoasting and introduces tools like Rubeus to enhance offensive capabilities while minimizing exposure and footprint.

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