Taking a look at Kerberos "Golden Ticket" attacks with Mimikatz. As mentioned in the video, here's my DC Sync explanation: • DC Sync Attacks With S... My blog: vbscrub.com
@@vbscrub Can i call KRBTGT account as keberos TGT account instead and still be correct? If exam question ask the name of the account? It means the same, doesn't it?
I finally understand how to use this attack lol...the tip on /ptt and the tip on using the FQDN helped tremendously on understanding why my attempts in the past failed. i wasnt using kerberos authentication.
May I ask one question that I followed the steps and can see admin session using klist, But when I use net use to mount AD's C drive, the username/password is still prompt. Where can I check?
Could you elaborate on the last bit where you say it can't be used using a remote shell please? I'm in that situation in the OSCP labs and I've struggled to understand when I've loaded a ticket how to use it given misc::cmd doesn't work but I guess it would work with gui access. I think this might be the reason. Not sure when we close Mimikatz is the ticket loaded into the reverse shell prompt too....
what I meant was that if you wanted to access files on that same machine you had the reverse shell on, then there's no kerberos authentication going on there becase kerberos only gets used when you access things across the network, so your ticket won't get used in that scenario. Obviously you are technically accessing those files over the network because you're using a reverse shell, but from the shell session's point of view (which is where you have your ticket) they would only be local files. Hope that makes sense. Oh and yeah anything you do in mimikatz is still in the same session as whatever you launched mimikatz from, so any tickets created/imported there still exist there after that. You can use the built in Windows command "klist" to check and see what tickets are cached in your current session wherever you are
I understand that the TGT can be forget easily if you own the nltm hash of the krbtgt user, but what about the session key? i watched your video where you explain kerberos, and in the as-rep, the client gets back the tgt and a session key. Then for the tgs-req the session key obtained in as-rep is used to encrypt some data, so the question is here, when you get the as-rep back, as client, the session key will be encrypted with the clients password, and then this encrypted session key will be used to encrypt the data in the tgs-req. So an attacker can forge the tgt since its encrypted with the krbtgt ntlm hash but how can the attacker forge the session key? he obviously doesnt know the administrator's password, so how is that attack possible?
I believe the password for the krbtgt account is randomly generated by AD during installation and is very long and complex, so it would take an extremely long time to crack (if you could even crack it at all). Having said that, it is possible for admins to reset the password to anything so I guess you could try it just in case they've reset it to something relatively simple, but in reality most of the time its going to be a waste of time.
@VbScrub hi! Just today I read in ms docs that no matter password you set, automatically windows generates a random one with same complexity... hope i help regards from Argentina 😉👋 hope
oh yeah it just defaults to that if you don't specify one. Same with the groups it adds you to (domain admins etc) if you don't specify group SIDs yourself
