Everybody and welcome to the final video of the Cross module.
Now in this video we're going to be going over what happens after the client has interfaced with the
authenticator and got its TGT or ticket generating ticket.
Now if we recall that TGT ticket is signed.
Erm that's that's encrypted by the TGA is secret keys.
So the client hasn't been able to read this ticket this entire time.
Now the client again has the TGIF session key as well.
Client listen three messages at this point once it's finished with the authentication server it will
send encrypted message with the TGIF session key that it already has.
Also known as the authenticator message it'll contain the timestamp and the name of the user.
Next it'll send a plain text response that's not encrypted with the service name that you want to access
as well as the lifetime for the ticket.
Now along with both of these requests it will also send the TGT from the authentication server that
it received before this.
Now at the TGA is are the ticket granting servers this is its turn what it does is it receives the two
messages from the client at first as well as the TGT message itself and it will go and look in the plain
text message which is message number two and it will try to identify if the services available if it's
in the realm also does the user have access to it.
All this happens at this point if it doesn't it kicks back to the user.
Now if it does and everything checks out it will then take the TGT and use its TGA secret key which
is what it was encrypted with before that the client have to decrypt it entirely.
Now once this is done it will extract the TGA session key and then the TGA session key is now used to
decrypt the first message called the authenticator which is again the name and the timestamp.
Now a little behind the scenes before it makes its response like you said it compares the user I.D.
to what the TGA has stored locally it will check the timestamp if there's more than a 2 1 2 minute delay
it'll stop the whole process that it does that just so in case people aren't trying to spoof the traffic
or try to man in the middle trying to get in between the client and the KDE checks the lifetime to make
sure it hasn't passed and then it checks the authenticator was not already sent.
So you can't reset the authenticator again.
You'd have to start the process back and then it checks to see if the I.P. address sent is actually
an IP that's valid.
Now if all of these checks for the TGA is passed it will generate something called the service session
key notices for the service itself.
Now remember how the authentication server had generated a TGA key so the ticket granting servers key
or session keys so that the user can or the client can talk to the TGA yes we're doing the TGA is doing
the same thing for the service.
So it generates a service ticket similar to the TGT but it's encrypted with the service a secret key
again similar to the TGT now this contains the name the service name the client's IP address timestamp
lifetime.
And again the session that the service session key.
So this is going to look very familiar to the TGA.
It's almost a one for one just for the service itself and in the underlying grand scheme of things it's
the same type of ticket.
Now the TGA says response to the client.
It prepares two responses it prepares the First it sends the encrypted service ticket directly to the
client and then it sends an encrypted ticket with the TGIF session key which is what it extracted before.
So now this is how it talks to the client securely.
It provides the service name the timestamp the lifetime and then the service session key which is important
because after that it's the client's turn.
Now the client will need to interface with the service at this point.
Now whatever that is HDP web interface email doesn't matter.
The client receives both of those messages.
It cannot decrypt the service ticket but it can decrypt the second message which has been encrypted
with the TGA session key which has the service name and also the service session I.D. or session key
which is the important part.
With that it will then generate a new authenticator request encrypted with the service with the service
key or service session key.
Now this is similar to what it did up here when talking with the authenticator encrypted encrypted with
the TGIF session key.
Now it's talking to the client so it's encrypting it with a service session key instead.
And then the client will send the service ticket from.
Sorry that's a misspelling there will send the service ticket from the TGA as and the new authenticator
to the service itself.
Now at this point it's up to the service to finish off this bit.
Now it will take and decrypt the service ticket with its service secret key which is what it was encrypted
with and then it extracts the service service session key validates the authenticator and the service
ticket and the user goes through the same process as the TEGA checks the user.
It checks whether tickets lifetime is valid.
So it does all the similar things that the TGT is going to do.
And keep in mind that a service to be able to do this has to be connected in some way to the KDE.
Now this is normally done from a trust.
It also has to support Kurt Ross in general but the service will after everything checks out the service
will send back and authenticator of its own with its own I.D. and its timestamp encrypted with the service
session key.
This is what the client stores and now the client can authenticate to the service.
Now this is a very big process and it can be broken down even further than what we just did.
So take some time read into it more if you need to.
This is more than more than enough for you to understand the process of what takes place.
If you want to attack verbose in a more detailed way you'll have to learn a bit more but when it comes
to light the golden tickets the silver tickets and the past the ticket stuff.
There's a lot of tutorials out there to teach you how to do that and there's a lot of tools out there
to do that for you.
So as long as you understand what you're looking for in the environment you should be able to replay
those types of attacks in whatever environment you're in as long as you understand the process.