kekeo

kekeo is a little toolbox I have started to manipulate Microsoft Kerberos in C (and for fun)

Changelog v2.2.0 20211214

• [internal] display kdc certificate informations

   

• [new] certificate user selection with /certhash

kekeo includes

1. kirbikator is a little tool to convert Kerberos tickets from different formats to another.
   It can be used to inject them in Windows LSA without mimikatzIt is mainly used to convert Golden Tickets, or other various Kerberos tickets from Windows, in a native format on Linux. Usage kirbikator {format} ticket1 ticket2 ...Where {format} is the destination format, this must be one of:
   • ccache – MIT Credential Cache – one ticket per file
   • ccaches – MIT Credential Cache – all ticket(s) in a unique file
   • kirbi – RFC KRB-CRED (#22) – one ticket per file
   • kirbis – RFC KRB-CRED (#22) – all ticket(s) in an unique file
   • lsa – Microsoft LSA API – Pass-the-Ticket for all ticket(s)

   ticket1 ticket2 … can be in MIT Credential Cache or RFC KRB-CRED (#22) format

   Remarks

   • ccache & ccaches are designed for MIT Kerberos or Heimdal Kerberos (Linux, Unix, Mac or Windows with a particular Kerberos stack)
   • kirbi is designed to be used with mimikatz (Windows NT6 or > version)
   • kirbis cannot be used as it is with mimikatz but is usefull to store multiple tickets
   • lsa is only available with Windows NT6 or > version
2. MS14-068 is a Windows vulnerability in the Key Distribution Center (KDC) service. It allows an authenticated user to insert an arbitrary PAC (a structure that represents all user rights) in its Kerberos ticket (the TGT).
   

   https://technet.microsoft.com/library/security/ms14-068.aspx

   In Windows domains, it permits privilege escalation (usually standard user to domain/enterprise admin)

   Technical

   The vulnerability is in the Key Distribution Center (KDC – kdcsvc.dll) of domain controllers. A user can obtain tickets by presenting a Kerberos TGT with an altered PAC.
   Normally the KDC service detects a PAC alteration by verifying its signature (each KDC knows the secret symmetric key to check it)

   The vulnerability: KDC service allows algorithms without keys (like MD4, MD5, SHA1 or CRC32) to be used. It means that any user can forge a PAC without knowing any secret key, and ask the KDC to include it in a ticket.

   Workflow

   1. (AS-REQ) User authenticates to a KDC, asking a TGT without a PAC.
   2. (PAC TIME) User creates a PAC with arbitrary data and seals it with an algorithm without keys (here, MD5).
   3. (TGS-REQ) From its TGT, a user asks a TGS for service krbtgt (TGT-like) with its fake PAC included.
   4. (TGS-REQ) From its TGS, a user asks another TGS for service krbtgt (TGT-like) – if vulnerable, fake PAC will be really signed by KDC here!
   5. (KRB-CRED) From the final TGS, ticket is converted as KRB-CRED structure (to be saved on disk or injected in LSA)

   Step 4. seems to be optional, but is necessary to use a TGT with a PAC well signed with a domain controller not vulnerable (load balancing).

   Arguments

   Standard

   • /domain – the fully qualified domain name of the target (ex: lab.local)
   • /user – the username you want to use as authenticated user (any account allowed to logon is OK, ex: utilisateur)

   Then you can choose between:

   • /password – the password of the user’s account
   • /key – the derived key of the user’s account, it can be RC4_HMAC_NT (NTLM), AES128_CTS_HMAC_SHA1_96 or AES256_CTS_HMAC_SHA1_96

   By default, /key and /password will be used with RC4_HMAC_NT algorithm, but you can specify /aes128 (AES128_CTS_HMAC_SHA1_96) or /aes256 (AES256_CTS_HMAC_SHA1_96)

   Final usage is between:

   • /ticket – optional – file name used to write a ticket(s) on the disk – default is: tgt.kirbi
   • /ptt – optional – Pass The Ticket: no ticket will be written, the first good ticket is injected in LSA (NT6 is needed)

   Automatically recovered

   If not provided, these arguments can be recovered remotely by RPC/CLDAP, in this case: /password is mandatory and /key is not permitted.

   • /sid – optional – the domain‘s SID (ex: S-1-5-21-1644491937-412668190-839522115)
   • /rid – optional – the user‘s relative ID (ex: 1105)
   • /kdc – optional – the DC you want to use for all queries (ex: dc.lab.local), if not provided, the program will select one automatically, then:
     • test all KDC in the domain
     • when saving the ticket in the file: save each successful tickets in separate files, named like %dcshortname%.%filename%.kirbi
     • when Pass The Ticket: inject the first successful ticket in LSA then break the loop
     • print a little report at the end with the number of vulnerable servers vs the total.

   Tuning

   • /groups – optional – relatives id of groups which the user will belong (first is primary group, comma separator) – default is: 513,512,520,518,519 for the well-known Administrator groups.
   • /sids – optional – externals SID (externals to the domain) to add.
     • an interesting SID is S-1-5-21-root forest-519 (Enterprise Admins)
3. PKINIT Mustiness is the opposite of PKINIT Freshness (https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness).It abuses the way Kerberos authenticates users with smartcard/token, by generating AS-REQchallenges for future usages… without needing access to the user secret in this future to decrypt AS-REP.TechnicalPassword/Key authentication (the classic one)
   1. The client gets its symmetric-key (derived from its password or not), usually, RC4/AES128/AES256, can be DES or other
   2. The client creates a timestamp in PA-ENC-TS-ENC
   3. The client encrypts the PA-ENC-TS-ENC structure into a PA_ENC_TIMESTAMP, with its symmetric-key
   4. The client sends an AS-REQ with this PA-DATA (it contains the PA_ENC_TIMESTAMP) to the AS, as a proof of the knowledge of its secret
   5. The AS (KDC on a domain controller in a Windows world,) knows the symmetric-key of the user and can decrypt the timestamp
   6. The AS encrypt a secret part of the TGT (EncKDCRepPart) ticket with the client symmetric-key
   7. The client gets the TGT session key by decrypting the secret part of the TGT with its symmetric-key
   8. The client uses the TGT ticket.

   Here, the client needs to use its secret symmetric-key two times: 3. & 7.

Download

Source: https://github.com/gentilkiwi/