GetUserSPNs: you can now specify another base DN

[the-useless-one]

Hello @asolino,

I added the possibility to specify another base DN when interrogating the DC. This way, if you have a trust relationship between Domains A and B, you can use a user from domain A to get kerberos tickets from a domain B DC.

Cheers,

Y

[Edit] Hmm, actually this PR only enables you to list SPNs cross-domain, but not to request TGS cross-domain. Right now, you get a Kerberos SessionError: KDC_ERR_WRONG_REALM(Reserved for future use) error message. I'll try and fix it!

[asolino]

This is a good idea @the-useless-one, let me know when you have it fixed and I'll go ahead and review/merge. Thanks!

[the-useless-one]

Ok, I added the possibility to request TGS cross-domain. Here's what happens when a user from domain A wants a TGS for a service in domain B:

• user_A asks for a TGT to KDC_A, and is given one
• user_A asks for a TGS to service_B to KDC_A, using the TGT from the first step. KDC_A notices that the TGS request is for a service outside of its jurisdiction, and so create a referral TGS, encrypted with an interdomain key.
• user_A sends this referral TGS to KDC_B. KDC_B decrypts, using the interdomain key, and gives user_A a final TGS for service_B

To implement this, I had to modify the kerberosv5.py file. The last if block in the getKerberosTGS checks if the domain returned in the TGS is the same as the domain of the KDC. If it's not, it changes the domain, but still interrogate the same KDC. In our case, this means that the referral TGS is sent back to KDC_A, when it should be sent to KDC_B. I just modified the else clause, so that our referral TGS is correctly sent to KDC_B.

However, I did not find a way to determine which KDC to interrogate base on the referral TGS. For now, I just put kdcHost = domainB, and we hope that it will resolve to a KDC for the second domain. Kind of a dirty fix, but it works for now, so ¯\_(ツ)_/¯

I encourage you to test the PR, it works fine on my end in a prod environment, and it even seems to work with Kerberos authentication (which means I didn't break everything).

The nice thing with the recursion in getKerberosTGS is that if you have a chain of interdomain trust, it should be resolved automatically. So if you have domain A <-> domain B <-> domain C, you could get Kerberoast hashes of SPN in domain C, with credentials from domain A (at least, that's what I understand from this documentation. This was not tested because it's not implemented in the prod environment I'm using for testing.

Hope this proves helpful, cheers!

Y

[asolino]

Thanks for the PR @the-useless-one. I want to be sure the changes in kerberosv5.py does not break anything. Will let you know soon.

[the-useless-one]

Great, thanks a lot! Just so you know, I was still able to generate TGT with ticketer.py, and to authenticate using Kerberos with the different examples scripts (wmiexec.py, smbexec.py, etc.)

[asolino]

Thanks for checking those things @the-useless-one.

What I'm mostly concerned are the -dc-ip switches available in many Impacket script (alongside -k of course). That use case is very popular (in particular when no DNS resolution is available).

Have you tried that one?

[the-useless-one]

Hmm, I did try it with the GetUserSPNs.py example, but not with other one. Could you give me a use case you want me to try? I still have a couple of hours of assignment left.

[asolino]

Sorry I didn't answer you before @the-useless-one... too much stuff on my plate..

I want to be sure that, for example, wmiexec.py -k -dc-ip <KDC/DC IP Address> DOMAIN/username@targetHost works.

[asolino]

I'm starting to look at this @the-useless-one...

There's something confusing (and probably my fault). dc-ip is meant to be used when Kerberos is selected in order to contact the KDC. I'm assuming the KDC is in the same server/s of the DC/s.

Adding a kdc-ip generates a confusion here.

To be continued..

[mubix]

In what format is BaseDN specified? I've tried this a couple of ways and it hasn't seemed to work for me.

[the-useless-one]

Hi @mubix,

the -base-dn is supposed to be the active directory domain name in its long form (i.e. the Kerberos realm name):

$ GetUserSPNs.py domain1.local/user1:password1 -kdc-ip $domain1_dc_ip -base-dn domain2.local -dc-ip $domain2_dc_ip -request

It's well possible that there are still some errors. Please, post the details here so that I can correct them. Thanks!

[the-useless-one]

@asolino, sorry I didn't respond to your comment. After answering @mubix's question, I do realize that having -kdc-ip and -dc-ip is kind of confusing. The thing is, in order to request a TGS from domainB through a cross-domain trust with a domainA account, you must first request a TGS to your KDC of domainA. Hence the new -kdc-ip parameter. It may not be the best name. What's more, the KDC of domainA could be determined with the credentials information, so there might not be a need for a -kdc-ip.

Finally, I still don't have a solution for my "dirty fix" of using kdcHost=domainB in kerberosv5.py when faced with a referral ticket. Since this touches your implementation of the Kerberos protocol (specifically the request of a TGS cross Kerberos-trust), it is a sensitive subject. If you want to discuss this outside of the Github comment, let me know. I'm @​theuselessone on Wire, or you can drop me an email at yannick *at* meheut *dot* org.

As you said, to be continued...

[0xdeaddood]

As #521 was merged (that includes cross-domain support in GetUserSPNs.py), and there are a couple of opened tickets related to referral-tickets features (#315 and #541), I think we can close this one and continue discussing there.