Unable to find temporary machine

[Cyb3rC3lt]

Hi there,

Yesterday when I tried this rbcd attack it worked fine when the machine account was added via ntlmrelayx but today when I manually add a machine as shown using addComputer it can't find it to perform the attack. Any advice?

Thank you

[ThePirateWhoSmellsOfSunflowers]

Hi! It works on my lab

Are you sure the computer is really created ? Maybe the default baseDN is not the same between addcomputer and passthecert. If you can, you can try to RDP on the DC to check it. You can also try to turn on verbose mode by using -debug flag.

:sunflower:

[Cyb3rC3lt]

Thanks for checking. I will close for now because this was on a client site and I can't recheck now. I'll reopen if I come across the issue again 👍🏻

[jsdhasfedssad]

Hi,

I have this exact issue as well. I cannot provide any screenshots but I get the same error message. I got the certificate and matching private key from a shadow credential attack and the computer account I am trying to grant delegation rights to I owned earlier by dumping LSASS on it.

Does this error occur before or after the authentication using the certificate and matching private key? Or put in other words, can I exclude authentication/trust issues when I get this error?

Using -debug does not output any additional info.

I can't find the version of passthecert I use but the underlaying Impacket version is 0.10.0.

Update August 14: I've read the DN in the certificate using openssl x509 -in [filename].crt/[filename].pem -text -noout and can see that the DN is the expected one. Therefore this does not seem to be the problem. Regardless, the flags for controling base DN and CN are according to the tool help not applicable for RBCD attacks anyway.

In addition, using the same certificate and private key in order to execute the whoami command fails with "... certificate not trusted..." or similar. This is strange since the DC that issued the certificate and the DC I used to execute the RBCD attack are the same and therefore uses the same CA. The certificate was still valid, two years validity time.

I also noted that the certificate must be PEM encoded (base64 encoded DER encoding) , not DER encoded (binary) only.

[ThePirateWhoSmellsOfSunflowers]

Hi @jsdhasfedssad!

I got the certificate and matching private key from a shadow credential attack

I need to check this but I don't think you can use "shadow certificate" to authenticate with SChannel. Is your certificate signed by the CA ?

This is strange since the DC that issued the certificate

IIRC shadow certificates are not signed by the CA as you generated it locally.

:sunflower:

[jsdhasfedssad]

You are correct! The certificate from the shadow credential attack is issued/signed but not by the CA. My mistake, It is signed by the machine that I wrote the shadow credentials on. This explains the trust error message but it does not explain why I to get the error "account does not exists". Unless the authentication fails first which in turn triggers this.

[ThePirateWhoSmellsOfSunflowers]

but it does not explain why I to get the error "account does not exists"

I think it's because we don't test if the login is successful or not. Thus, the login fails, PassTheCert tries to retrieve the user, an error is thrown then the script interprets this error as "account does not exist" but the real error is more like "your connection is not authenticate so the result is empty".

:sunflower: