Walking the Bifrost:

An Operator's Guide to Heimdal &

Kerberos on macOS

Cody Thomas
Objective By The Sea 3.0
March 2020
 WHO AM I?
Cody Thomas - @its_a_feature_
● Operator / Instructor at SpecterOps
● Open Source Developer
○ Apfell – Red Team C2 Framework
○ Bifrost – Kerberos Manipulation
○ Orchard – Open Directory Access
○ GitHub: https://github.com/its-a-feature
 OVERVIEW
● Brief intro to Kerberos
○ What is it / How does it work / Why do we care?

● Attacking Active Directory Kerberos from macOS

○ Credential Storage / Theft

○ Common Attacks

● Other Kerberos details on macOS

○ LKDC
KERBEROS INTRODUCTION
A brief overview
 KERBEROS 101
● What is Kerberos?
○ Authentication mechanism invented by MIT in 1980s
○ Designed for use on insecure networks
○ Uses math and cryptography to provide strong guarantees
○ Based on a client/server model - stateless
○ Uses ASN.1/DER encoding of data
○ Scoped to ‘realms’ of authentication
● Many implementations
○ Traditional MIT (with plugins)
○ Windows
○ macOS
 KERBEROS 101 – AUTH STEPS
1. Client and Key Distribution Center (KDC) have shared secret
○ Think of the KDC like an all-knowing PKI management server

2. Client makes a request to the Authentication Server (AS) to be

authenticated with the shared secret – i.e. an AS-REQ
○ AS forwards request to the KDC, typically these are the same machine

3. AS responds with a ticket to the krbtgt SPN and encrypts a portion

with the krbtgt hash. This ticket is called a Ticket Granting Ticket
(TGT). This is an AS-REP.
○ The TGT proves you are who you say you are to the KDC because of the
encrypted portion
○ Think of this like a new username/password combination
 KERBEROS 101 – AUTH STEPS
4. Client presents their TGT to the Ticket Granting Service (TGS) and
requests to speak to a specific service – i.e. TGS-REQ

5. TGS responds with a ticket to the service and encrypts a portion with
the service account’s hash (another shared secret)
○ This is a TGS-REP. The ticket is a Service Ticket
6. Client presents Service Ticket to the service and requests services

7. Service checks ticket to determine if the client is authorized for access

○ Service validates the ticket due to the shared secret the service has with the KDC
 KERBEROS 101 - EXTRAS
● The KDC is bound to a ‘realm’ that it knows about
○ In Windows, this is the Fully Qualified Domain Name (FQDN) of AD

○ Technically, can be anything though

● Tickets have expiration times
○ Tickets can potentially be renewed or revoked
● Services are requested via Service Principal Name (SPN)
○ A combination of the service and the computer that hosts the service
○ Must be an exact match (no IP addresses, use hostnames)
 KERBEROS – WHY CARE?
As a Red Teamer:
● User passwords only get you so far
○ Sometimes hard to get on macOS
● Kerberos tickets are just as valuable
● Potentially less protected
● More moving pieces makes
it harder to change

As a Blue Teamer:
● More authentication logs for correlation
● More credential material to track
● You might be using it and not even know it
WINDOWS ACTIVE DIRECTORY & HEIMDAL
A case study in Windows attacks from a macOS perspective
 WHAT / WHO IS HEIMDAL?
• Heimdall in Norse Mythology guards the Bifrost (rainbow road) in
Asgard (where Thor, Loki, Odin, etc live)
• Heimdal is Apple’s slightly tweaked implementation of Kerberos

• We’ll cover those differences

as we go along

• This is Marvel’s version ->

 HOW TO USE HEIMDAL
• macOS has a Kerberos framework we can import into XCode

• Throughout these slides we’ll use these API calls in Objective C

• There are other implementations out there in scripting languages
• According to Apple, all 3rd party scripting languages should be removed
soon TM, so we should pretend they’re already gone from a Red Team
perspective
• We will manually craft the network traffic to TCP port 88

• We will use the user TEST\test_lab_admin in the test.lab.local

domain on the spooky.test.lab.local computer
HOW TO USE HEIMDAL
 STAGE 1 – THE SHARED SECRET
1. Client and Key Distribution Center (KDC) have shared secret

• In Windows, you don’t send your password around, you use a hash
• Active Directory knows this hash, not your plaintext password
• AD knows many hashes of your password to be able to support a wide
range of system versions

• We need to convert our password to a hash, but what kind?

• RC4, AES128, AES256, DES3, etc
 STAGE 1 – THE SHARED SECRET
• Heimdal has us covered:
krb5_c_string_to_key(context, ENCTYPE, &password, &salt, &newKey);
• ENCTYPE
• ENCTYPE_ARCFOUR_HMAC – unsalted NTLM
• ENCTYPE_AES128_CTS_HMAC_SHA1_96 – salted AES128
• ENCTYPE_AES256_CTS_HMAC_SHA1_96 – salted AES256
• Salt?
• If normal account: DOMAINFQDNusername
• If computer account: DOMAINFQDNhostusername.domainfqdn

• RC4 hashes are so enticing because they’re not unique across domains and are
easier to crack
STAGE 1 – THE SHARED SECRET
• If you’re curious how to
get your computer$
shared secret, you can
reveal it with admin
credentials from the
SYSTEM Keychain
• Found under
/Active Directory/
NETBIOS Name
• Also found via dscl
(Open Directory)
STAGE 1 – THE SHARED SECRET
 STAGE 1.5 – SAVING HASHES
• What if you can’t be bothered to keep typing your password each
time to generate that shared secret?
• Keytabs
• A table of keys associated with various accounts
• System generated (/etc/krb5.keytab)
• Your system has one for hashes of its own computer$ account
• Need to be root to access
• User generated
• Users can generate their own at any time (yikes!)
 STAGE 1.5 – SAVING HASHES
• [[ Bifrost keytab dump ]] Backing account for VNC is
spooky$

Same hash we generated

manually with Bifrost
 STAGE 1 ATTACKS
• If you compromise the user’s plaintext password:
• You can generate their shared secret and continue the rest of the
process
• If you compromise the user’s / computer$ shared secret (hash):
• You can continue the process because the plaintext is only used to
generate the shared secret
• Typically called “Over-Pass-The-Hash” or “Pass-The-Hash” in windows
depending on if you’re messing with LSASS
• If you get the user’s RC4 secret, you can attempt to crack it
• This allows you to “be” that user/account
 STAGE 2 – AS-REQ
FOR TGT

• Sending a request to the

Authentication Server (AS) for a
TGT
• Uses ASN.1 Encoding for structure
• Need to prove we know the secret
from stage 1 somewhere
• PADATA section for this called
PADATA-ENC-TIMESTAMP
• You guessed it, we’ll encrypt a
timestamp with the hash as proof
 STAGE 2 – AS-REQ FOR TGT
• Remember: it all boils down to a ticket request with a few things:
• Who we are
• Proof of who we are
• What service we want a ticket for
• In this section, we request a ticket (TGT) that can be used with the Ticket
Granting Service (TGS)
• We say who we are and prove it with the encrypted timestamp
• TGT requests have a Service Principal of krbtgt for the realm
STAGE 2 – AS-REQ FOR TGT
 STAGE 2 – ATTACKS

• Note: in pure MIT Kerberos we don’t do this encryption

• Any user requests a TGT for any other user. The resulting TGT is
encrypted with the target user’s shared secret (hash).
• The idea being that only the right user can decrypt.
• Very trusting
• This is the idea behind AS-REP roasting
• This requirement can be added to MIT Kerberos with a PKINIT plugin.
 STAGE 3 – AS-REP WITH TGT
• AS and KDC validate what was sent:
• Does the user requested exist?
• And is it active?
• Is this KDC authoritative over the requested realm?
• Does the KDC have a hash for that user of the requested type?
• Using that user’s hash, can the KDC decrypt that encrypted timestamp?
• Is that encrypted timestamp within the past 5 min?
• If KDC answered YES to all the above, success! We can get a TGT
• If KDC answered NO to any, we get a KRB_ERROR reply with why
• Many legit reasons for this*
STAGE 3 – AS-REP
WITH TGT
• AS-REP repeats a lot of our
request information
• The protocol is stateless, so it
repeats a lot
• Element 5 is the TGT
• That contains our information
encrypted with the krbtgt hash
• Element 6 is special
• That contains a blob encrypted
with our shared secret
 STAGE 3 – AS-REP
WITH TGT
• Decrypted section contains
valuable information:
• New session key
• Lifetime of TGT
• TGT usage flags
• Renewable, forwardable, etc
 STAGE 3.25 – WHERE DOES THE
TGT GO?
• macOS stores tickets in a format called ccache (credential cache)
• By default, these ccache entries are managed by a KCM
• In normal Kerberos land this is referred to as API storage
• We transparently interface with a daemon process to access the tickets
• Each ccache is assigned a random UUID
• There’s one principal (the client)
• There can be multiple tickets
• You can have multiple ccaches and swap between them
• You can also force save these ccaches to files on disk (yikes!)
 STAGE 3.25 – WHERE DOES THE
TGT GO?
• [[ Bifrost ticket dump ]]
 STAGE 3.5 – TICKET PORTABILITY
• What if you want to take a ticket from one computer and use it on
another?
• No worries! Kerberos is stateless and doesn’t track where tickets are
used or generated
• We can use the Kirbi format to save all the necessary info
• Stores information from the AS-REP
• I.E. the TGT and that special encrypted data
• Saves it in a new Application 22 in ASN.1
STAGE 3.5 – TICKET PORTABILITY
 STAGE 3.75 –
PASSING TICKETS
• How do we import these tickets
we’ve converted to Kirbi?
• We convert them to krb5 cred
entries (i.e. ccache)
• We need to resolve the desired
ccache name
• Or create a new ccache entry
• Add them to list within the
ccache
 STAGE 3.75 – PASSING TICKETS
• [[ Bifrost ptt]]
 STAGE 3 – ATTACKS
• If the krbtgt hash is stolen, create your own AS-REP (i.e. TGT)
• The ‘Golden Ticket’
• Dump user’s tickets from KCM and impersonate them
• Ticket Theft
• Request Tickets for another user and crack the response
• AS-REP Roast
 STAGE 4 –
TGS-REQ FOR
SERVICE TICKET
• Similar process to Stage 2, just
different material
• Requesting a ticket to a service
(not krbtgt)
• Usually something like CIFS
for access to the file system
• Using our TGT as proof of
identity instead of encrypted
timestamp
• More encrypted timestamps and
checksums, but with session
key
 STAGE 4 – TGS-REQ FOR
SERVICE TICKET
• Any user with a valid TGT can request a Service Ticket to any
service
• Remember, there’s no authorization checks happening here, only
authentication
• Services must have a backing Service Principal Name (SPN) in
Kerberos
• i.e. cifs/spooky.test.lab.local is a SPN
• These must be requested exactly as they are registered within
Kerberos, otherwise they won’t be found
• Can request a service ticket and specify any encryption scheme
 STAGE 5 – TGS-REP WITH
SERVICE TICKET
• TGS and KDC validate what was sent:
• Can the krbtgt hash decrypt the embedded TGT?
• Was that TGT created with the past 20 min?
• if so, assume still valid
• If not, validate the information in it, since it might have changed
• Does the requested SPN exist?
• Is there an associated account and shared secret the KDC knows?
• If yes to all of the above, success! You get a service ticket!
• If no to any, you get a KRB_ERROR and a reason why
 STAGE 5 – TGS-REP WITH
SERVICE TICKET
• Almost the same structure as the AS-REP
• Element 5 is special:
• This is the Service Ticket
• Notice the enctype here is RC4 when we requested
AES256
• The last piece in this element is a blob encrypted
with the service account’s shared secret
• It contains information about the client requesting
access
• Element 6 is special:
• This is data about the Service Ticket
• This is encrypted with our session key
 STAGE 5 – TGS-REP
WITH
SERVICE TICKET
• Decrypted section contains
valuable information:
• The lifetime of the ticket
• New session key
• This matches the encryption
type used with the Service’s
shared secret
• Usage flags
 STAGE 5.25 – WHERE DOES THE
SERVICE TICKET GO?
• All tickets are automatically saved to the default ccache
• This means Service Tickets and the TGT are in the same place
• [[ ticket dump with service tickets ]]
 STAGE 5 - ATTACKS
• If you know the shared secret of the service account, you can make
your own Service Tickets to that service
• i.e. ‘Silver Tickets’
• If you use a valid TGT and request Service Tickets in RC4, then you
can try to crack the associated account’s password
• i.e. ‘Kerberoasting’
HEIMDAL WITHOUT ACTIVE DIRECTORY
The macOS local key distribution center
I DON’T HAVE AD, WHAT NOW?
• Fear not! You’re still using
Heimdal
• Starting with OSX 10.5,
Apple introduced “Back To
My Mac (BTMM)”
• The goal was to allow users
to directly connect to other
mac devices to share
screens, mount volumes, or
perform remote
management
• You can see these options
in the “Sharing” settings
 HOW?
• Apple said that starting in 10.14 Mojave that BTMM is no longer
included, but the components are still there and leveraged
• So, when you remotely connect to a mac with a local account, what’s
happening?
• You’re using Heimdal to authenticate, get tickets, and access resources
• Select services open the Kerberos port (88)
• But there’s no AD and no “Domain”, so what’s happening?
 LOCAL KEY DISTRIBUTION
CENTER
• On your computer’s first boot, the system
generates a self-signed certificate
• com.apple.kerberos.kdc
• This certificate is stored in the System Keychain
• The “realm” for this Heimdal instance is based on
the SHA-1 hash of this certificate

LKDC:SHA1.B58C56AD77898DE69AAEFD22A538D6EDDE
FF8D47
COM.APPLE.KERBEROS.KDC

• /System/Library/LaunchDaemons/
com.apple.Kerberos.kdc.plist

• Can see this launch daemon running

or not on your box to see if you’re
sharing any of the listed services

• Can use launchctl to see if this

daemon is running
 LKDC - SERVICES
• /etc/krb5.keytab
• Stores the keys for the various system services offered by Kerberos (must be root)

• 4 default services with LKDC:

• afpserver
• cifs
• vnc
• Host
• SPNs of the form:
• Service/realm
• Service Tickets use this shared
secret!!
 LKDC – _KRBTGT HASHES
• /usr/libexec/configureLocalKDC
• Generates a new com.apple.kerberos.kdc certificate (idempotent)
• If a new one is generated, updates the /etc/krb5.keytab with new Realms
• This also updates the _krbtgt hashes stored in the local Salted
AES256 Open Directory
Hash Node
• dscl . read /Users/_krbtgt KerberosKeys

AES128 Salted Hash

des3-cbc-sha1-kd
 LKDC – AS-REQ1
• Now let’s say we want to mount a volume on another mac, but we
don’t know that mac’s LKDC realm and we don’t know the full shared
secret, just the plaintext password
• Make an AS-REQ for a generic
realm:
• WELLKNOWN:COM.APPLE.LKDC
• Kerberos responds with generic
error specifically to call out real
realm
 LKDC – PA-FX-COOKIE
• We now know the realm, we still don’t know the shared secret
• The LKDC uses the Secure Remote Protocol (SRP) for this
• It’s a method of key exchange based on crypto
• It’s integrated into the Kerberos implementation
• Kerberos is stateless though?
• RFC613 added a way to manage state within Kerberos:
• PA-FX-COOKIE (133) can be passed with other PADATA fields
• Same area as our PA-ENC-TIMESTAMP
• We need to capture and relay this with every request to keep state
 LKDC – USER PASSWORDS
• Ok, we have a way to keep state and we know the realm, but we still
need to get that shared secret
• Passwords on macOS aren’t saved in plaintext, instead they’re passed
through a PBKDF2 function to generate a new, longer password
• You can see your ShadowHashData by looking into your Open
Directory Local Node as root – Using Orchard (OSS) or built in:
dscl . read /Users/itsafeature ShadowHashData
Verifier is based on user’s password
LKDC –
V=gx SHADOWHASHDATA
where x = H(s | H( I | “:” | P ) )
• Salted-SHA512-PBKDF2
• Many iterations (80k+) with a
salt.
• Designed to be slow and unique
• Used when you sign in

• SRP-RFC5054-4096-
SHA512-PBKDF2
• This is the server-side shared
secret for Kerberos traffic
• This is called the “Verifier”
 LKDC – AS-REQ2
• We can make a slightly modified
AS-REQ again, this time
specifying the real realm of the
remote LKDC

• Notice that we still aren’t doing

anything to prove we are who we
say we are
 LKDC – AS-REP2
• We finally we’re starting the
SRP process

• We need to track that we’ve

started, so we’ll start getting
those PA-FX-COOKIES

• To generate the client-side secret, need to pass the plaintext user

password, this 16-Byte salt, and the number of iterations into a PBKDF2
function with SHA512 to generate a 4096Bit key
• This comes from the group: SRP-RFC5054-4096-SHA512-PBKDF2
 LKDC – TICKETS AND STORAGE
• With a few more requests back-and-forth AS-REQ requests, we can
successfully generate a new shared key between both parties
without transmitting any credential material (just sending big
numbers)

• We can then treat this TGT like any other normal TGT and use it to
request Service Tickets like normal for the remote mac

• What gets stored in our credential cache though?

 LKDC – CCACHE ENTRIES

Normal Kerberos
So What’s this??
LKDC – CCACHE ENTRIES

Plaintext Password!!

Associated Remote
Username

Remote Computer Name

 LKDC - ATTACKS
• If you get the user’s password
• You can do everything manually / normally and impersonate the user
• If you get the _krbtgt hash
• You can generate your own TGT as anybody to the LKDC
• Same as a ‘Golden Ticket’, but just to that Mac
• If you get the hashes from /etc/krb5.keytab
• You can impersonate anybody to those services
• Same as ‘Silver Ticket’, but in this case it might as well be a ‘Golden Ticket’
• Stealing the user’s SRP Verifier
• You can brute-force try to crack the user’s password
 LKDC - ATTACKS
• If you get the user’s KerberosKeys Open Directory Attribute
• dscl . read /Users/itsafeature KerberosKeys
• You can try to decrypt the AES256, AES128, or des3-cbc-sha1 (INTEGER 16 in
ASN.1 encoding) keys to get the user’s plaintext password

AES256 Salted Hash

Salt
 LKDC - SUMMARY
• You’re running Heimdal on your macOS computer.
• How often do you change your password?
What about your _krbtgt password?
What about your computer’s password?
• LKDC should not come into play if you’re AD joined
• Realistically, it just doesn’t come into play with AD users
• Still comes into play with local user accounts
• The tickets in your ccache are flushed periodically
• LKDC tickets are flushed when you’re no longer using the them
• i.e. unmount that shared drive, disconnect VNC, etc
 THANK YOU – QUESTIONS?
• Bifrost
• https://github.com/its-a-feature/bifrost
• Will release updated code for LKDC interaction
• Still need to add in Silver/Golden ticket generation
• Blog on the topic with video demo:
• https://posts.specterops.io/when-kirbi-walks-the-bifrost-4c727807744f
• Using a captured hash to get a TGT, inject ticket, get a CIFS service ticket, then
mounting a remote share with those tickets