CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutSign UpSign In
rapid7

CoCalc provides the best real-time collaborative environment for Jupyter Notebooks, LaTeX documents, and SageMath, scalable from individual users to large groups and classes!

GitHub Repository: rapid7/metasploit-framework
Path: blob/master/documentation/modules/auxiliary/admin/kerberos/keytab.md
Views: 1904

Keytab

The modules/auxiliary/admin/kerberos/keytab module provides utilities for interacting with MIT keytab files, which can store the hashed passwords of one or more principals.

Discovered keytab files can be used to generate Kerberos Ticket Granting Tickets, or bruteforced offline.

Keytab files can be also useful for decrypting Kerberos traffic using Wireshark dissectors, including the krbtgt encrypted blobs if the AES256 password hash is used - which is described in more detail below.

Actions

The following actions are supported:

  1. LIST - List the entries in the keytab file [Default]

  2. ADD - Add a new entry to the keytab file

  3. EXPORT - Export known Kerberos encryption keys from the database

Scenarios

List

msf6 auxiliary(admin/kerberos/keytab) > run keytab_file=./example.keytab Keytab entries ============== kvno type principal hash date ---- ---- --------- ---- ---- 1 18 (AES256) [email protected] 56c3bf6629871a4e4b8ec894f37489e823bbaecc2a0a4a5749731afa9d158e01 1970-01-01 01:00:00 +0100 [*] Auxiliary module execution completed

Add

Adding an entry using a known password hash/key which has been extracted from a Domain Controller - for instance by using the auxiliary/gather/windows_secrets_dump module:

msf6 auxiliary(admin/kerberos/keytab) > run action=ADD keytab_file=./example.keytab principal=krbtgt realm=DEMO.LOCAL enctype=AES256 key=e1c5500ffb883e713288d8037651821b9ecb0dfad89e01d1b920fe136879e33c [*] modifying existing keytab [+] keytab entry added to ./example.keytab

Adding entries using a specified password:

msf6 auxiliary(admin/kerberos/keytab) > run action=ADD keytab_file=./example.keytab principal=Administrator realm=DEMO.LOCAL enctype=ALL password=p4$$w0rd [*] modifying existing keytab [*] Generating key with salt: DEMO.LOCALAdministrator. The SALT option can be set manually [+] keytab entry added to ./example.keytab

Export

Export Kerberos encryption keys stored in the Metasploit database to a keytab file. This functionality is useful in conjunction with secrets dump

# Secrets dump msf6 > use auxiliary/gather/windows_secrets_dump msf6 auxiliary(gather/windows_secrets_dump) > run smbuser=Administrator smbpass=p4$$w0rd rhosts=192.168.123.13 ... omitted ... # Kerberos keys: Administrator:aes256-cts-hmac-sha1-96:56c3bf6629871a4e4b8ec894f37489e823bbaecc2a0a4a5749731afa9d158e01 Administrator:aes128-cts-hmac-sha1-96:df990c21c4e8ea502efbbca3aae435ea Administrator:des-cbc-md5:ad49d9d92f5da170 Administrator:des-cbc-crc:ad49d9d92f5da170 krbtgt:aes256-cts-hmac-sha1-96:e1c5500ffb883e713288d8037651821b9ecb0dfad89e01d1b920fe136879e33c krbtgt:aes128-cts-hmac-sha1-96:ba87b2bc064673da39f40d37f9daa9da krbtgt:des-cbc-md5:3ddf2f627c4cbcdc ... omitted ... [*] Auxiliary module execution completed # Export to keytab msf6 auxiliary(gather/windows_secrets_dump) > use admin/kerberos/keytab msf6 auxiliary(admin/kerberos/keytab) > run action=EXPORT keytab_file=./example.keytab [+] keytab saved to ./example.keytab Keytab entries ============== kvno type principal hash date ---- ---- --------- ---- ---- 1 1 (DES_CBC_CRC) [email protected] 3e5d83fe4594f261 1970-01-01 01:00:00 +0100 1 17 (AES128) ADF3\[email protected] 967ccd1ffb9bff7900464b6ea383ee5b 1970-01-01 01:00:00 +0100 1 3 (DES_CBC_MD5) ADF3\[email protected] 62336164643537303830373630643133 1970-01-01 01:00:00 +0100 1 18 (AES256) [email protected] 56c3bf6629871a4e4b8ec894f37489e823bbaecc2a0a4a5749731afa9d158e01 1970-01-01 01:00:00 +0100 1 17 (AES128) [email protected] df990c21c4e8ea502efbbca3aae435ea 1970-01-01 01:00:00 +0100 1 3 (DES_CBC_MD5) [email protected] ad49d9d92f5da170 1970-01-01 01:00:00 +0100 1 1 (DES_CBC_CRC) [email protected] ad49d9d92f5da170 1970-01-01 01:00:00 +0100 1 18 (AES256) [email protected] e1c5500ffb883e713288d8037651821b9ecb0dfad89e01d1b920fe136879e33c 1970-01-01 01:00:00 +0100 1 17 (AES128) [email protected] ba87b2bc064673da39f40d37f9daa9da 1970-01-01 01:00:00 +0100 1 3 (DES_CBC_MD5) [email protected] 3ddf2f627c4cbcdc 1970-01-01 01:00:00 +0100 ... omitted ... [*] Auxiliary module execution completed

Decrypting Kerberos traffic in wireshark

The Kerberos protocol makes use of encrypted values which will show as an opaque blob of hex characters in Wireshark. Configuring Wireshark with a Keytab file can decrypt these values automatically.

For instance in a TGS-REQ request within Wireshark, the cipher below is encrypted using the user account's password and is not human readable:

tgs-req pvno: 5 msg-type: krb-tgs-req (12) padata: 1 item PA-DATA pA-TGS-REQ padata-type: pA-TGS-REQ (1) padata-value: 6e82044730820443a003020105a10302010ea20703050000000000a38203c6618203c230… ap-req pvno: 5 msg-type: krb-ap-req (14) Padding: 0 ap-options: 00000000 ticket authenticator etype: eTYPE-ARCFOUR-HMAC-MD5 (23) cipher: 0bbb6dbc29413df5905d45c97a3d05239bd609326ff4a410f47048c3f4e22c3ea8003985… ^^^^^^^^^^^^^^ Value encrypted using the user account's password

The easiest way to decrypt these opaque blobs is to generate a Keytab file with Metasploit using the secretsdump scenario above or similar. After generating a keytab file in the Wireshark GUI go to Edit -> Preferences -> Protocols -> KRB5 and modify the following options:

  • Set try to decrypt Kerberos blobs to true

  • Set the Kerebros keytab file to the keytab file generated by your domain controller

After confirming the new settings - the previously encrypted which were signed with the user's password, and the decryptable session key should be viewable in Wireshark.

For example the previous TGS-REQ authenticator blob is now decrypted in the Wireshark UI. Wireshark on Linux may not show the decrypted packet information in the packet details pane, instead it appears as a separate tab in the packet bytes pane:

tgs-req pvno: 5 msg-type: krb-tgs-req (12) padata: 1 item PA-DATA pA-TGS-REQ padata-type: pA-TGS-REQ (1) padata-value: 6e82044730820443a003020105a10302010ea20703050000000000a38203c6618203c230… ap-req pvno: 5 msg-type: krb-ap-req (14) Padding: 0 ap-options: 00000000 ticket authenticator etype: eTYPE-ARCFOUR-HMAC-MD5 (23) cipher: 0bbb6dbc29413df5905d45c97a3d05239bd609326ff4a410f47048c3f4e22c3ea8003985… Decrypted keytype 23 usage 7 using learnt encASRepPart_key in frame 475 (id=475.1 same=0) (f161f360...) # ... authenticator authenticator-vno: 5 crealm: ADF3.LOCAL cname name-type: kRB5-NT-PRINCIPAL (1) cname-string: 1 item CNameString: a cusec: 303247 ctime: 2022-04-10 15:21:31 (UTC) ^^^^^^^^^^^^^^ authenticator value now decrypted using the previously generated keytab file

If you have exported the krbtgt account to the keytab file - Wireshark will also decrypt the TGT ticket itself. If not - Wireshark will generate warnings about being unable to decrypt the TGT ticket which is signed using the krbtgt account.

Additional details: https://wiki.wireshark.org/Kerberos

If you are on a Windows domain controller it is possible to use the ktpass program to generate keytab files:

ktpass /crypto All /princ Administrator@DEMO.LOCAL /pass p4$$w0rd /out demo.keytab /ptype KRB5_NT_PRINCIPAL

It is easier to use the Metasploit module, but if you do use ktpass - be aware of the following issues:

  • If the password contains $ it is easier to run the ktpass command in cmd rather than powershell to avoid unexpected variable substitution

  • If there is a Missing keytype 18 warning for etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) in Wireshark - verify that the principal name is correct within the ktpass generation command

    • This should match the initial AS-REQ KRB ERROR salt, found in krb-error -> edata -> ETYPE-INFO2-ENTRY -> salt

Common Mistakes

Invalid REALM/PRINCIPAL/SALT

When generating a keytab with a password, a salt is generated by default from the principal and realm unless one is explicitly provided. For Windows Active Directory environments, these values are case-sensitive. The realm should be upper case, and the principal is case-sensitive.

When the SALT is not explicitly provided a salt will be generated that follows the Windows naming convention, for instance:

REALM.EXAMPLEAdministrator