I don't know about you, but it's always best if I can actually see and even better lay my hands
on something to be able to understand it better. Now, while we can't lay our hands physically on
this, I can give you a little bit of sneak peek under the hood. I've installed Wireshark on nearly
every system inside of this lab for a specific reason, and part of that is being able to see
the authentication process take place right before our very eyes. Now, I am using Wireshark
on the Ethernet adapter and inside of this lab as well. Thank you, Keith, for setting this up.
You can see the IP and also the VM information on the actual desktop. I don't know how you did it,
probably because you're a wizard and magic at what you do. But what we're taking a look at
primarily is that the client VM that we were just on earlier in this skill, I logged out of it,
and now I'm going to try to log in as the actual administrator. But I also want to make
sure that by clicking on other user that I am signing into the Texas domain.
Now, notice also, as soon as I typed in administrator, zoom in real quick, you see
client-vm. That's because there is a local administrator account named administrator,
and by default, Windows wants to use that local account. In order to make sure that we're logging
onto the domain with administrator, we just type Texas backslash, and then we start going through
and using the password that we have inside of our notes. As I click on this and swap back over to
the here real quick, you can see, boom, we have a lot of traffic going on. Now, I'm going to go ahead
and pause the video here and let this play out as the user logs in, the actual administrator.
Well, never mind. We'll come back over to here and take a look at our actual traffic.
Now, you notice there's not that many packets. This is a very well-isolated network.
I'm going to go ahead and stop here and go over a couple of filters real quick for us.
Now, first, inside of Wireshark, you can generally go up to the display filter,
commands below, by the way, and type in Kerberos, and it auto-fills in for you,
and you should be able to get a display of all the Kerberos actions that just took place along with
on the left side, the actual packets correlating to and from.
And if you pay attention, because I know you did, you can see not only did we get the Kerberos
under protocol KRB5, but look to the right of that, and you'll see some of those requests that
I was mentioning earlier in this skill when we were covering Kerberos authentication.
And now you're starting to see not only the source and destination being, you know,
from the 49 being the domain controller, 52 being that client, you're seeing the whole chain of
events as we went through from beginning into the ticket granting service and all the way through
to the verification. So, the administrator account in our domain setup on that client VM
was able to authenticate using Kerberos, meaning everything was up and great and fantastic.
Now, sometimes, for whatever reason, Kerberos does not work as a filter, and I'm going to have
this command below as well, too, because Kerberos isn't just some magical thing you can pull up.
It has a port number. In fact, it has two, and one of them is tcp.port="88", and then we'll also do a
pipe pipe because we're going to be searching for both of these, udp.port="88". Both tcp and udp88
is Kerberos, and you'll notice that not only did we get that, but we actually got a few more
different types of packets. Now, yes, these are still, like, as you can see here as I zoom in for
you, we have the as-request, the as-rep, and it's under krb5. But now, why are there more packets in
this than there were in the actual Kerberos search itself? Well, that's because not all traffic on
88 in Wireshark gets categorized as Kerberos because the initial connection is over port 88,
but when they start doing their three-way handshake over tcp, then Wireshark can read the headers and
say, ah, that's a Kerberos packet. But prior to that, it may not recognize it. I bring all this up
because this filter right here of tcp.port="88", pipe pipe, udp.port="88", that's still a part of that
Kerberos traffic. So, if you're looking just straight for Kerberos, you may be missing one or
two here and there. So, if you want to search for all three, why not just space pipe pipe Kerberos,
and then you have all of it all together just in case. So, now you can actually go through here
in the actual search results and see from beginning to end all the different packets.
And if you notice starting at packet 73, as I zoom in for you here, that's kind of where we
were at a while ago because this is a perfect demonstration right here. Packet 73, you see a
SYN, SYNACK, and ACK as the three-way handshake for tcp. And then in packet 76, you get the AS
request. So, it did not recognize, Wireshark that is, the packet 73, 74, 75 as being part of Kerberos
because it just didn't have the proper headers in it for Wireshark to determine that. But you
notice in packet 76 and 77, once we got through the three-way handshake for tcp, boom, shakalaka,
it did. And that's why we have krb5 under protocol instead of tcp. Now, to further reinforce our
learning here, and I also have an example that way you can access in case you don't want to go
through the authentication process yourself flipping back and forth, let me move this over
to the right. And you can see on the domain desktop, I have Kerberos packet capture example.
So, everything that we just did here, I have it pulled up for you,
and the filtering commands below this video.