Kerberos
Kerberos is a computer network authentication protocol that verifies the identities of users or hosts.
Kerberos is an authentication protocol, not authorization. So it only identified users who provide a password, but it does not validate to which resources or services this user has access. Once authenticated is can access services. This access is based on tickets, that expire over time.
Kerberos uses UDP or TCP, which sends data in cleartext. Kerberos is responsible for providing encryption and uses ports: UDP/88 and TCP/88.
Kerberos works with using tickets. Those tickets are delivered to users to perform serveral actions.
-
TGS or Ticket Granting Service, used to authenticate against a service, encrypted with service key.
-
TGT or Ticket Granting Ticket, is presented to KDC to request tickets or TGSs and is encrypted with KDC key.
The user logs on send authenticator, their password is converted to an NTLM hash, which is used to encrypt the TGT ticket. Using current timestamp and cleartexst username. Also called pre-authentication, is not mandatory but enabled by default.
KDC generates temporary session key which is used for further exhanges. It will wait for the TGT user requested and contains user info and copy session key which is now protected by the user’s key.
User received response with TGT protected by KDC’s key and session key. Next step is to request a Service Ticket (ST) or TGS ticket with a TGS-REQ message. In this request it contains the name of the service which is the Service Principal Name or SPN. The TGT they just received and the authenticator.
The KDC will verify the TGS request by checking the session key in the TGT. After validation the TGS-REP message is send with a new session key for exchanges between the user and a service. TGS contains name of service, user info from TGT, copy session key.
The user decrypts user/service sessions key from the TGS-REP which they can read, unlike the TGS ticket which is encrypted with service secret key. To acces the service it sends the TGS and authenticator which is done by the service using the user/service session key.
Service receives TGS Ticket and authenticator encrypted with users/service session key. A copy of user/service session key is found in the TGS ticket for the service to validate the authenticator with the session key. Service can then read info about user, group memberships and if authentication is succesfull the response is a AP-REP message with ecrypted timestap of extraced session key.
Authentication Service (AS)
Ticket-Granting Service (TGS)
Application Request (AP)
If you login to a webserver or SERVER A credentials are authenticated but if that SERVER A needs to acces a database on SERVER B on your behalf it cannot forward them to SERVER B without the right configuration. This can occur working with Evil-WinRM.
Attack againt service accounts that allows offline password cracking. It needs a valid domain user account and password. A SPN is added when a service registered, its an alias to AD account. Service accounts are utilized with these SPNs but its common to see them tied to User Accounts.
A TGS or Service Ticket requested for all available service is encrypted with a service account’s secret key but these are usually 120 chars random passwords, practically impossible to bruteforce. However sometimes there are services executed by user accounts, user accounts passwords are set by humans and more likely to be cracked. SPN accounts use RC4 encryption, but AES is also possible.
Looking for user accounts exposing a service and thus has a SPN. Either using an ldap filter in a powershell script:
Or using powerview
Kerberos allows a user to authenticate to a services and use it. Kerberos delegation enables that service to authenticate to another services as that user.
-
Unconstrained Delegation: Allows a service to impersonate a user when accessing another service which is very dangerous. An administrator with
SeEnableDelegationPrivilege
can set this on a account, a service account cannot modify itself to add this option. -
Constrained Delegation: Here the service has the right to impersonate to a user based on a list of services like a Webserver can only relay authentication to DB Server for SQL/HOST/CFS.
-
Resource-Based Constrained Delegation: This delegation is based on resource level, any account on a rusted list has the right to delegate authentication to access the resource. The resource has the right to modify its trusted list. Any service account can modify the trusted list to allow account to delegate authentication to themselves.
Unconstrained Delegation
Allows a service to request access to any other service on behalf of the user.
Service can request access to any service on behalf of user
Constrained Delegation
Limits the services a delegate can request access to on behalf of the user.
Limited to pre-configured service list and uses (S4U2Proxy)
Resource-Based Constrained Delegation
Allows the resource owner to control which services can delegate access to it.
Resource decides which accounts can delegate to it.
Kerberos extension that allows a service to impersonate a user when requesting acces to another resource. S4U2Proxy is used for delegation, where a service acts on behalf of a user.
When a user authenticates using NTLM, not kerberos it doesn’t get a TGS ticket and so the S4U2Proxy can’t act on behalf. S4U2Self is kerberos extension that allows the service to request a TGS ticket for itself on behalf of the user.
Printer Bug is a vulnerability in the MS-RPRN protocol which is used for managing print jobs and printers. This bug can trick a server into authenticating to another machine over SMB.
Need to compromise an account with TRUSTED_FOR_DELEGATION and GenericWrite to update its SPN list.
Unlike unconstrained, constrained delegation acts on behalf of users but only to specific services that have been allowed. Its more secure and restrictive. For a example a user logging in to a financial application where the backend database server applies permissions instead of the account permissions .
A service account needs Kerberos-constrained delegation enabled so a user’s ticket is used to acces a database.
A TGS Ticket contains an unencrypted part which contains the SPN of the request service. This can be modified and the request will still be valid. In constrained delegation. Using S4U2Proxy we can obtain valid TGS tickets on behalf of users. This way we a valid TGS ticket is obtained for a SPN which is for a service account.
If the constrained delegation allows protocol transition we can impersonate to be anyone. Using S4U2Self which allows a service to obtain a forwardable service ticket to itself on behalf of any user.
RBCD is delegation based allowing delegation settigns to be configured on the target service instead of the service account being used to access resources.
Every machine account has an NTLM hash, the hash of the computer represented as SYSTEM$. The NTLM hash acts as a pre-shared key or PSK between domain and workstations. The PSK is used to sign TGS. This ticket is less powerfull than Golden as it can only access that single machine.
To forge a silver ticket you need: NTLM password for Service account or Machine account, SID of domain, target host, SPN, arbitrary username and group information.
A pass the ticket attack does not touch LSASS which is Sekurlsa::LogonPasswords. When attacking kerberos a failure to create a sacrificial process can result in taking down a service. This happens because of overwiting an existing logon session and require a service restart or machine reboot when it loses its ticket.