Module 7 Lab - Kerberos Deep Dive

In this lab we are going to move from the realm (that was a pun) of theory as reenacted by Athena and Euripides to what Kerberos looks like on the wire (it is quite similar to the play). Remember Kerberos predates ssl and will likely be here awhile within the corporate enterprise.

Prerequisites

  • Get a working AD/DS Environment

AD01

  • Up and Running from the Windows Admin Center Lab
  • Make sure that you have some standard Domain Users

FS01

  • Joined to yourname.local
  • On LAN

WKS1

  • Joined to your domain
  • On LAN
  • DHCP is a nice touch but not required
  • Network connectivity between WKS1 and FS01

Demo Videos

Tasks

  1. Configure a Shared Folder on FS01
    • e.g. (\fs01\yourname-share) with a file in it called yourname-kerberos.txt
    • Lots of ways to set it up - try WAC or Powershell for a new twist
  2. Access your xubuntu-lan system and install Wireshark
  3. Begin a wireshark capture on xubuntu-lan

Note

Your LAN switch has been configured to allow promiscuous network capture. In a real environment, this would take a little more work on your part.

  1. On wks01, login to the Domain as the new normal domain user
  2. Navigate/map to you file share on FS01 \\yourserver\\yourname-share
  3. Stop and filter the Capture.

Deliverable 2. Find the initial AS-REQ packet from workstation to domain controller and provide a screenshot that shows the realm (domain) and the KRB5-NT-PRINCIPAL (user).

Deliverable 3. The second kerberos packet should indicate a KRB Error concerning preauthentication. Windows wants extra information to be provided, specifically a timestamp that is encrypted with the sender’s secret key. Find the first AS-REQ packet in your pcap and provide a screenshot similar to the one below that shows the encrypted time-stamp.

Deliverable 4. Find the first AS-REP reply from the server (has the ticket!). Expand the ticket portion. The first Ticketenc-part is encrypted with the server’s secret key It contains the session key and TGT. The second portion is encrypted with the client key and represents a copy of the session key. Provide a screenshot similar to the one below.

Deliverable 5. In that same packet in the padata section, the server provides a salt for the client to use to decrypt the encrypted portion of the packet. What is the specific salt? Provide a screenshot. If you don’t know what a salt is with regard to cryptography, google that.

Deliverable 6. Find the first TGS-REQ Packet which represents our actual login request. Drill down until you see the ticket (encrypted by the server’s secret key) and the authenticator (encrypted with the client’s session key). Take a screenshot similar to the one below. The client is requesting a Ticket Granting Ticket for the kerberos service itself.

Deliverable 7. The next kerberos communication should be the TGS-REP (Ticket Granting Service Response) that provides a ticket for the workstation (wks-hermione) or client as opposed to the user (hermione in the examples). The host itself is a kerberos principal with its own secret key known only by the domain controller and itself. Provide a screenshot showing the sname-string similar to the one below.

Deliverable 8. Just before a valid SMB2 session is setup between the client and the file server, there should have been a TGS-REQ to the domain controller and a TGS-REP from the domain controller to the client. Provide a screenshot that shows the sname-string as part of the request body similar to the one below. If you don’t know what cifs is, google that.

Deliverable 9. Ask your windows 10 client to display its kerberos tickets using klist. You should have a ticket for cifs/fs01. Provide a screenshot similar to the one below.

Deliverable 10. Does Kerberos use Secret Key Cryptography (Symmetric) or Public Key Cryptography (Asymmetric)?

Kerberos uses Symmetric Secret Keys

Info

Kerberos has been around for nearly 30 years and has been implemented in Windows for the last 20 years. It is an example of a complex security protocol that still has issues. One of these is the creation and malicious use of so-called “Golden Tickets” combined with hash passing. Elevated access to the Domain Controller, even once can expose these tickets to an attacker.