So now we've got date, time down to seconds.
Well, that's kind of useful.
That's a lot of decimals still.
You might have seen before, down here, we can go automatic,
or I just want seconds.
I'm not going to do more with tenths of seconds.
It's already in order, so seconds is fine.
Hour, minute, seconds-- yes, all these things
happened very quickly.
That's computers.
That's what happens.
So our time, we've got our source IP--
what I like to do is align this one right and this one right.
And what we're going to add in here--
we've got source IP and destination IP.
We're going to edit columns, so column preferences,
and brought up columns.
Click on this guy twice, get new columns, and going
to call this source port and this one destination port
or just dest port.
That works.
And right now, it just says number, but there we go.
This one is the destination port,
and we'll leave it unresolved.
And source port, let's go with that, just destination port,
neither resolved nor unresolved.
And then let's reorder them--
so source, source port, destination, destination port.
Bingo.
So I put addresses to the right, ports to the left,
address to the right and port to the left.
There we go.
OK.
So now you've got 192.112.112.2 port 5284, the ephemeral port,
going to 443.
So guess which one is the web server,
the one where the destination port is
443, kind of useful now.
This follows a format we're used to, at least if you've
been working with network practice for a while,
IP then port.
That's how Netcat works.
That's how many things are going to work.
It's IP address then port.
And then we've got protocol, and this is just generic protocol.
You can see it gets into some detail down here, HTTP.
We've got packet length, and I like to align that center.
That way, it leaves a gap for what our packets are.
And then you can see details of the packets.
Neat.
All right.
So those are our fields, like this one's a--
where's a good GET request--
just GET request for the web page.
Well, what is happening?
Starts at frames, goes up by protocols, if you will.
Think of a reverse of your TCP/IP.
So frame is going to cover our interface.
All right, physical error, so Ethernet I. And then,
in here, we have got Ethernet II.
So [INAUDIBLE],, what is our actual connection.
OK?
Then what's working at that layer, our NIC, and our NIC
has a Mac address.
So that is us, our source.
And then our destination tells you what kind it is,
and you can keep diving into this info.
And you might be wondering what all this is down here.
This is the packet.
Some of this stuff, the hex dump,
doesn't make any sense in ASCII.
But over here, you can see there is some information that makes
sense, and then encoded data.
So as I go through this whole frame
and see if anything actually matters--
and it's not going to on that one
because it doesn't actually have anything to do with the packet.
The packet begins with our physical address.
So where is it going?
Where is it coming from?
Does that makes sense?
Those are the beginning, that's that header for that layer.
It breaks down a little bit and what the protocol is,
and that is that header.
So then we get to TCP/IP or internet protocol, IP address,
so our internet layer.
And this has some header information,
a lot of header information actually,
but eventually, it gets to our IP addresses, our source
and our destination.
And this is what they break up to in hex out of the bits.
And guess what.
We don't need to spend a lot of time looking at the bits,
but I just wanted to show you how this correlates to that.
And dive in a little more, our transmission control error,
more header information in bits.
And that's not what I'm doing in this course.
I mean, you could look at what flags are set.
So this was a ACK push, kind of makes sense for an HTTP GET.
The rest, it's just acknowledging receipt
and pushing more information, more header information.
It finally gets to the data.
So we've got HTTP data and it's a GET request.
So that was all of our headers for 0, 1, 2, 3
physical internet transmission.
And everything else is kind of going
to be up here in your data layer, TCP/IP instead of OSI
model, if you will, and just some really basic information.
Truth be told, this stuff makes the most sense in the hex dump.
It's almost plain text because it's HTTP instead of HTTPS.
And that's kind of the breakdown.
So what else do we want to do here?
Well, this is a GET request.
That's neat.
What does it do?
Well, we went to a website, and that
makes a whole conversation.
What we can do--
I right-clicked, go into follow, and you go
to TCP stream or HTTP stream.
Let's do HTTP stream because it's an HTTP request.
And it got a 302 found, which is a redirect.
Kind of makes sense.
What did it send back?
Nothing.
What we can do here, in this follow,
you could look at one side of the conversation
or the other or the entire conversation.
And right now, it's displaying in ASCII,
but you could put it in raw and it's what?
[INAUDIBLE]
Click the hex dump, not super helpful.
None of this is really [INAUDIBLE]..
What it did do is, when we follow the TCP stream,
it pulled out that whole stream.
It put in a display filter.
This stream is TCP stream 3005, and so it is only
displaying the packets related to that stream.
Down here, you can see we captured 8,800 packets
and we're only displaying 10 of them.
So we didn't get rid of anything.
We're just choosing what to display up here
in the display field.
To get rid of that, see everything else,
just hit the X. What's neat is it's going to keep history.
So if you're like, oh, I want to go back,
there's no back button.
What you can do is you can get rid of filters
or you can reapply filters, and it takes you
back to where you were.
Well, what if we want to just look at one type of stream?
Did you see the layout for that follow?
I'll pull it back up--
Tc's.stream eq 3005.
I didn't tell it that when I did the right-click, follow, HTTP
stream.
It applied that filter.
Well, let's find something that we
know is going to work better.
All right, get rid of that.
Let's look at some of this information.
This is from our scan.
Did I sort something funny?
Yes, I did.
My bad.
Let's start from the beginning.
Let's follow this TCP stream from our first.
See this is packet number one.
Let's see what it did.
Something that doesn't make any sense whatsoever.
This is encrypted traffic.
When you have it set to ASCII and it looks like this,
it's encrypted traffic.
So let's just filter out that stream.
Now it's doing a not TCP stream equals 0.
OK?
Well, what about this one?
That's nothing.
Sometimes you can just keep filtering.
These are going to be ARP scans, so they
don't have a conversation.
ARP is not TCP.
That's why, when we looked at hierarchy, it didn't count,
because ARP works at level two.
It's just IP addresses and Mac addresses.
Let's apply a filter ourselves, and not ARP.
As I was typing, you could see it is going to kind of guess
and give me things to choose.
So let's go with that.
Did you see it's red, that whole bar right now?
It means, if I try to run this, it won't.
Even over here, it's got a little do not, not
allowed sign.
I finish that P, it turns green.
And if I hit Enter, it did not display all of the ARP packets.
We can even go back.
Right now, we're looking at 8,116.
If I go to the one before that, 8,642.
That was the change, lost like 500 ARP packets
from our host scan.
Now we've also got a mess of ACK resets.
What if we got rid of and TCP?
Is that' going to work or is that
going to get rid of everything?
Thought so, OK.
Now it takes us to the ICMP, because again, we did TAC SN
so it included a ping scan.
After it did our ARP scan, it did a ping scan.
And we also see this EDP, probably because, when it saw--
oh, probably one of the scripts also
ran EDP checking for something.
Cool, so that's how we can play with some display filters.
But while that was kind of useful,
let's really dive into display filters.
So over here, we've got this plus sign.
It says, add a display filter button.
And we can get into preferences, but you
can create a specific display filter
and name it something, save it, have it for later.
I think it would be kind of useful.
That's all.
There we go, display filter expression.
I right-clicked the field, pulled it up.
There are, I think, 600,000 different display filters
on the Wireshark website.
There's so many different types of filters.
You can filter by any sort of network traffic
that can be ingested and breaking it up in any way
you want.
It's kind of a mess.
But one of the easiest ones, IP addresses--
so many IP addresses.
If you wanted something specific,
you could come into here, dig through, and figure out
how to create what it is you want,
and then it will apply it.
That's not going to match anything because I kind of just
made it up.
What is most useful, IP address.
So ip.addr.
because I'm following what it shows there,
equals equals 192.0.2.1.
So it found things with the IP address 192.0.2.1,
which I'm not exactly seeing.
But what we can do is search, and it should take us
to what we're looking for.
Sorry.
So it found things that applied to that.
What would make the most sense is 112.112., so we get 3.
This is all the traffic that applied to 192.112.112.3.
There's some scan information, and then finally, some talking.
So we did pull up a website eventually.
We got a 302 found.
And then what it did is it sent another ACK, FIN, ACK.
Eventually, should have returned-- there we go, 200 OK.
Let's follow this TCP stream.
So got to login.php.
That was redirected.
That's why we got the 302.
It redirected.
That returned a 200 OK, an API reply saying
that, hey, this does exist.
And it returned a text/HTML doc.
We did it in a browser, so it interpreted the HTML
and actually showed you something,
but this is what it looks like.
And if you know HTML, this makes some sense.
But hey, this is it.
There's an image in here, bee_1.png.
Now, that in and of itself, it says there to look for it,
but I don't think we're going to find it in this.
Instead, we should see it in the next exchange
asking to send that image.
And you could sit and dig through
and try to read this data, or we have an object.
We have an image.
We know we have an image because we saw it in the browser.
But you could just see what other images altogether
are in this capture.
Go to HTTP, and there is info in here.
These are text, text, text, text, text,
text, and that can be useful.
Here is an image.
This one's a favicon for Microsoft.
There should also be a bee.
It might be showing up as nothing.
Let's save it all.
Let's put it on the desktop in a folder.
Because otherwise, we'll have to sift
through a lot on our desktop.
I keep saving stuff there and--
I've been saving things in roots.
I'm in root.
There we go.
It's there.
Why is it not here?
Well, that's trippy.
I'm not going to try to make sense of that.
All right.
Well, we pulled all those objects into our machine
and we were able to save them from Wireshark.
That was what I was trying to get at,
that we were able to take the objects and save them.
Then you go through and try to see what they all mean.
So that is how we can use Wireshark
to look at some traffic.
Let's start a clean one.
Still have this one open.
Let's make some traffic.
That's not going to resolve, but it tried to.
All right, let's stop capturing there, follow some streams,
see if there's anything.
Nope, that was all encrypted.
And that should be because, yes, HTTPS.
Let's show the difference if we look at .3.
I guess we could leave that.
So all this traffic looks like nothing
when we follow a TCP stream because it's
over HTTPS, which is encrypted.
And did we capture--
should have captured the TLS handshake.
OK, it's just playing with me now.
It's toying with me.
We'll continue this one without saving or capture,
and let's capture this one-- it is not encrypted--
or .3.
Oh, and that's definitely why we didn't get objects before.
Capturing on the wrong eth interface, rookie mistake.
I should know better than that.
There we go.
Capture on the right interface.
That'll help your analysis go much better.
OK.
So we got a GET request to the login page,
and let's follow that.
It's really straightforward.
It downloaded the same thing we saw before, clicked around,
and it pulled up--
it's also got the CSS.
Clicked on new user.
That brought up something.
I clicked on info.
That brought up a new page, pulled up training.php.
It's great.
If I filter out this whole stream,
it should show you have more new stuff.
This is JavaScript or turned JavaScript.
Guess what.
JavaScript is not human readable here.
It's got to be interpreted [INAUDIBLE]..
But hey, it triggered GET some images,
and looks like some images were got, and that makes sense.
So that's what we're looking at here,
a whole bunch of images getting sent across.
Let's go look at those.
Perhaps.
I feel silly.
Oh, kill the filter.
No, I'm just being silly.
All right, pulled over the HTML pages, the CSS, the JavaScript.
But this one, it's not going to give us any of the images.
That's fine.
These are things that you can play with in Wireshark,
and I'll quit without saving.
And that's how we can intercept traffic and compare
some HTTP to HTTPS.
I know that was kind of a longish lab.
It was all over the place a little bit
and thank you for hanging in there with me.
Hopefully you got something out of that,
you got used to Wireshark.
If you haven't played with Wireshark, get in there,
play with it, enjoy it, have fun,
and get used to it because it can be used greatly.
We're going to do most of the rest of this in command line
in TShark just to simplify it, streamline.
And unless you're doing an investigation
or you're just playing around, it's
more likely you're going to run some scripts utilizing things
in command line instead of actually working
in Wireshark itself, especially if you're working remotely.
Some of the things that we're doing--
you're sniffing traffic.
And listening to someone else's traffic
is way easier to do with a quiet sensor.
And if you don't have to have a GUI running Wireshark,
if you can just have a tcpdump getting that information
and sending it back, looking at it, again,
in command line in something like TShark,
the command line version of Wireshark--
it's the same tool, just how you interact
with it instead of the GUI--
can be quite useful.
And we will dive into that in the next labs.