No certificate outputted when using the command "setShadowCredentials"

[jsdhasfedssad]

Hi. Thank you for this tool and all your help!

According to the help output of the command "setShadowCredentials" not only should shadow credentials be written on a target account but those should then also be used to request a certificate. However, it seems no certificate is outputted. Is this part still to be implemented?

Also, which filter can I use with the command "getObjectAttributes" in order to verify that shadow credentials has indeed been removed? Actually, I have the same question related to disabling the flag "DONT_REQ_PREAUTH".

[CravateRouge]

I forgot to update the help for setShadowCredentials and you guessed the parameters almost correctly but enable is not a boolean for some reasons but a string. So you have to use True and not true (it's case sensitive).
The help update has been done on 3371f2d.

Filters used with getObjectAttributes are LDAP filters so for this one it will be msDS-KeyCredentialLink.

The flag DONT_REQ_PREAUTH is part of the attribute UserAccountContro but it's binary.

[jsdhasfedssad]

I updated and tested again. I also checked the value of "msDS-KeyCredentialLink" afterwards. I still don't get a certificate and it seems there is no shadow credentials written on the object.

[CravateRouge]

Error is on me, I forgot to put enable before outfilePath. Btw setShadowCredentials domainuser1 is enough, you don't need to add True cert.txt except if you want to have cert.txt as name for your certificate.

[jsdhasfedssad]

It still does not work. No certificate file is written and as far as I can tell no shadow credentials have been written either.

[CravateRouge]

Try with f7dc933

[jsdhasfedssad]

Super! Now the shadow credentials are written and the certificate and matching private key is outputted. I can also remove the shadow credentials afterwards.

I was excited when I saw that you had implemented this feature. The reason is that I have been struggling with a similar scenario related to the certified pre-owned attack on ADCS. I can write the shadow credentials and then request the certificate. The problem occurs after that when a TGT must be requested. In that scenario PKINITtools is also used but in that case and now when using your tool the same error occurs. See below. Several months ago I submitted a ticket regarding this on the Github page for the tool but to this date there has been no reply. Nor has the tool been updated. I understand that you may not care but I would be thankful if you could take a look at the error and perhaps point me to a solution? As of now I am forced to use Rubeus on Windows to request the TGT something I want to avoid.

[CravateRouge]

Could you use this version of minikerberos and show me the error output again?
The main branch has a bug to display some kerberos errors.

[jsdhasfedssad]

Thank you! I have updated minikerberos but I get the same error.

[CravateRouge]

According to your error message you don't use my tweaked version. I changed super(Exception, self).__init__('%s Error Code: %d Reason: %s ' % (extra_msg, self.errorcode.value, self.errormsg.value)) into super(Exception, self).__init__('%s Error Name: %s Detail: "%s" ' % (extra_msg, self.errorcode.name, self.errormsg))

[jsdhasfedssad]

OK. I installed your version as per the instructions. How can I ensure I use your version?

[CravateRouge]

Dirty fix: replace minikerberos with my minikerberos repo into your path /root/pentest/virtual_env_pkinittools/lib/python3.9/site-packages
It should work.

[jsdhasfedssad]

I can't get this to work. The path "/root/pentest/virtual_env_pkinittools/lib/python3.9/site-packages" does not exist. Creating the path and copying your minikerberos into it does not help. Nor does updating the PATH variable to various locations. I also installed PKINITTools again into a different virtual environment which also did not help.

[jsdhasfedssad]

I managed to get it to use your minikerberos now. I think...

[CravateRouge]

So now we have a better understanding of your error!
First thing first, are you sure that your AD supports Windows Hello? You tried the exact same thing on this AD with Rubeus and it works?
If it works with rubeus we may have an issue with the certificate content see:
https://stackoverflow.com/questions/58393943/create-certificates-for-pkinit-based-kerberos-login-on-active-directory
In this case an issue to this repo could be interesting: https://github.com/p0dalirius/pydsinternals

[jsdhasfedssad]

Regarding Windows Hello. I have not actively configured that. I use a standard installation of Windows Server 2019. More or less unpatched. I did find https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-issues which states that Windows Hello was broken in Server 2019. I will try to patch my servers but first I must somehow find more disk space :)

Regarding the Stack Overflow link. I will look into this. I was not aware that I actively had to configure PKINIT auth in Windows... Are you saying that using PKINITTools requires ADCS to also be installed? I have that but it is not installed on any of the DCs.

There is also fortra/impacket#1101 which looks similar to the Stack Overflow link.

Specterops also mentions this error in their certfied pre-owned whitepaper at https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf on page 111. However, I have not configured those registry keys in my environment since I want that to be vulnerable.

[CravateRouge]

I did some test of my own and didn't see any issues. setShadowCredentials with PKINIT works like a charm:


Could you try to perform the attack with Rubeus and tell me if it succeed?

As stated in the specterops post you need a Windows Server 2016 Functional Level in Active Directory and a digital certificate for Server Authentication installed on the Domain Controller.
To check the functional level you can do:

python bloodyAD.py -u john.doe -d bloody -p Password512! --host 192.168.10.2 getObjectAttributes 'CN=Schema,CN=Configuration,DC=bloody,DC=local' objectVersion

If you don't have an AD CS on the domain it's already a hint that there is no certificate on the DC to perform the PKINIT with Kerberos.

[jsdhasfedssad]

I managed to fix the error! Somehow the domain group Domain Controllers did not have any rights on the CA certificate itself. I added the group, gave it the required rights and restarted the ADCS service.