No certificate outputted when using the command "setShadowCredentials" about bloodyad HOT 17 CLOSED

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.

from bloodyad.

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.

from bloodyad.

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.

from bloodyad.

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.

from bloodyad.

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

from bloodyad.

Try with f7dc933

from bloodyad.

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.

from bloodyad.

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.

from bloodyad.

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

from bloodyad.

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))

from bloodyad.

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

from bloodyad.

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

from bloodyad.

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.

from bloodyad.

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

from bloodyad.

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

from bloodyad.

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.

from bloodyad.

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.

from bloodyad.