Previous articles demonstrated how to compromise Windows, establishing an initial foothold in the environment. Its time to step it up a gear and hack Active Directory's preferred authentication protocol, Kerberos. Prior to compromising Active Directory we need to understand how Kerberos works.
In simple terms Kerberos is an authentication protocol allowing you, as the user to mutually authenticate and consume resources on the Windows Active Directory Domain. Kerberos is the preferred authentication mechanism, Kerberos will fall back to NTLM, which is less secure, when its not possible to establish Kerberos, for example connecting to a resource via IP.
Kerberos communicates over UDP and TCP port 88.
At no point is a password passed or travels over the network, instead symmetric encryption based on a shared secret is used. The users password or NTLM hash is the users 'Secret Key', the Domain Controller can derive the users secret key as it has access to the users NTLM hash, this is the shared secret.
The KDC (Key Distribution Center) is an integral part of all Windows Domain Controllers. The KDC provides 2 functions the Authentications Service (AS) and the Ticket Granting Service (TGS). The KDC runs under the identity of the KRBTGT service account and is responsible for handling all signing and encryption of all Kerberos tickets.
The AS is responsible for for the initial authentication and distributing the Ticket Granting Ticket (TGT).
The TGS provides the authentication service for validating the TGT and subsequently distributing Service Tickets.
Simplified Kerberos Ticket Exchange
User enters credentials on a client
Client send pre-authentication to the KDC
KDC validates user and sends back TGT and Logon Session Key encrypted with the users secret key
The Client decrypts the Logon Session Key and then extracts the TGT
Client send the KDC a request to access a service.
KDC replies with a new Service Ticket and new Service Session Key
The Client decrypts the Service Session Key with the Logon Session Key
The Client sends the Service Ticket to the Server and is decrypted with the Service's secret key
The Server responds granting access to the user.
Simply Kerberos Ticket Exchange (Graphical)
Detailed Kerberos Ticket Exchange
0. User logs on with Username and Password
Creds > Winlogon.exe > Secur32.dll > Local Security Authority (Lsasrv.dll > Spnego.dll > Kerberos.dll) >>>> LSA of the DC > KDC AS
When a User enters their credentials, the credentials are passed to the Client for processing and its in fact the Client making the initial and subsequent requests to the KDC. Its the client that has the secure channel and not the user.
1. Kerberos authentication service request (KRB_AS_REQ)
Client requests ticket from the KDC (AS) by sending the following info:
Users Authentication (Pre-Authentication) request
Timestamp (encrypted with users NTLM password hash and converted to a symmetric Users Secret Key)
TGT Service Request (clear text)
Client Principal name
2. Kerberos authentication service response (KRB_AS_REP)
KDC (AS) decrypts the timestamp with the Users Secret Key, as this is also known to the KDC
KDC (AS) validates the user request and replies with the TGT and Logon Session Key
Logon Session Key (encrypted with the Users Secret Key)
Ticket Granting Ticket (TGT) (encrypted with the KRBTGT Secret Key)
Logon Session Key
Expiry date and time = 10 hours
PAC File (Privilege Attribute Certificate) Data Structure contains authorization data controlling access to resources. For an interactive logon the following fields are required:
The client decrypts the Logon Session Key with the Users Secret Key
The client extracts the TGT from the decrypted Logon Session Key
3. Kerberos ticket-granting service (TGS) request (KRB_TGS_REQ)
When a user requires access to a SMB Share, Exchange, SQL Server etc, a request to the KDC (TGS) for a separate Service Ticket and Session Key is made, based on the Service Principal Name.
Service Name of SQL Server (SPN)
TGT (encrypted with the KRBTGT Secret Key)
Authenticator data (username and timestamp) (encrypted with the Logon Session Key)
The KDC (TGS) decrypts TGT with its Secret Key and extracts the users Logon Session Key
The KDC (TGS) decrypts the Authenticator Data with the Logon Session Key.
4. Kerberos ticket-granting service (TGS) response (KRB_TGS_REP)
KDC (TGS) replies with the Ticket Granting Service ticket and a new Service Session Key for accessing the SQL Server
The Service Principal Name (SPN) (encrypted with Logon Session Key)
TGS ticket (encrypted with the Service Accounts Secret Key)
Service Session Key
Users Authenticator data
Expiry date and time = 10 hours
Service Session Key (encrypted with Logon Session Key)
The client decrypts the Service Session Key with the Logon Session Key
5. Kerberos application server request (KRB_AP_REQ)
Client sends Authenticator Data and TGS ticket to the SQL Server
Authenticator data (username and timestamp) (encrypted with the Service Session Key)
TGS Ticket (encrypted with the Service Accounts Secret Key)
Service Session Key
Users Authenticator Data
Service Account Password
Users Group membership
The SQL Server Service decrypts the TGS Ticket with its secret key and extracts the Users Authenticator Data
The SQL Server validates Group Membership and assigns the appropriate permissions.
6. Kerberos application server response (KRB_AP_REP)
The SQL Server Service responds by encrypting the Time from Users Authenticator Data with the Service Session Key
Time Stamp (Encrypted with the Service Session Key)
The client decrypts the Time Stamp with the Service Session Key and access's the SQL Server
The client then uses the Service Session Key to perform all further communication until the session key expires.
In most cases the Server Service will accept the TGS Ticket without any further validation with the Domain Controller.
Detailed Kerberos Ticket Exchange (Graphical)