Scribd
Upload
2 views

Lab1_Guided

The document provides a detailed guide on analyzing network traffic using Wireshark, focusing on various protocols such as ICMP, ARP, Telnet, HTTP, and FTP. It outlines steps for filtering packets, following TCP streams, and examining conversations to identify live hosts and potential security issues. Additionally, it explains how to extract files and cookies from captured traffic for further analysis.

Uploaded by

quangphan9803
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
2 views

Lab1_Guided

The document provides a detailed guide on analyzing network traffic using Wireshark, focusing on various protocols such as ICMP, ARP, Telnet, HTTP, and FTP. It outlines steps for filtering packets, following TCP streams, and examining conversations to identify live hosts and potential security issues. Additionally, it explains how to extract files and cookies from captured traffic for further analysis.

Uploaded by

quangphan9803
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Analyze Network Traffic

It’s not often you will be looking through packets in a live capture.
Analysis is usually conducted after the fact, such as a SOC Analyst
reviewing a capture file to investigate an alert generated by their
Intrusion Detection or Prevention System (IDS/IPS). That computer
whiz in popular media, lines of program output racing by on their
computer screen? They’re just waiting for the execution to complete
before consulting the logs. Wait until you’ve captured a full
transcription of the network activity, then you can review it on-
demand.

1. In the Wireshark display filter, type icmp and press Enter.

ICMP is the protocol that ping speaks, so this filter is showing


that radical ping party you started your traffic generation
session with.
You can also use some common logical operators in your filter
expressions to include multiple types of traffic.

2. In the Wireshark display filter, change your filter expression to


the following and press Enter:

icmp or arp

ARP is a way of discovering the MAC address of a host with a


given IP. You need to know the target’s MAC address for
delivery on a local network, so you should only see ARP traffic
for hosts in your network (192.168.1.0). Meanwhile, the ICMP
shows delivery to several networks (172.16.0.0 and 10.0.0.0).

Looking at ARP traffic is a good way to discover all live hosts on


a network. Close analysis of these packets can lead to
discoveries of nefarious behaviors such as MAC spoofing, MITM
attacks, and NAC (Network Access Control) failures.
Next up: remote access.

3. In the display filter, change the expression to telnet to view all


telnet traffic.

Remember, you had two telnet sessions here. Can you tell
which is which? Wireshark can, using Streams. You could filter
for streams by entering an expression into the filter bar, but
Wireshark makes it easy for you.

4. In the Packet List pane, right-click on the first packet in the


list, then select Follow > TCP Stream to view only the telnet
packets related to your first session.
Woah, look at this – a full record of that initial exchange you
had with utilserver. Wireshark colors client transmissions in red
and server transmissions in blue to make exchanges easy to
follow.
Here you can see the credentials you used to login, the
commands you issued, and even the contents of the server.txt
file you checked out while you were there! You will also notice
that each letter you input in the terminal was echoed by the
server (e.g., your username: ttuusseerr). This is because the
characters were received by the server, then echoed in your
terminal so you could see what you were typing. An exception
is your password: if you recall, the characters were not
displayed in your terminal, so each letter is only seen once
here.

5. Close the Follow TCP Stream window.


Streams allow you to view specific sessions between hosts.
Wireshark carves out packets related to individual sessions by
looking at information like Source and Destination addresses,
as well as flags set in the packet that indicate the beginning of
a connection (a SYN flag) and the end of a connection (FIN or
RST). If you look at the Info column in the Packet List, you
should see a [SYN] packet at the top of the list. At the bottom,
you should see a [FIN] packet. Furthermore, you should see
Wireshark has colored these SYN and FIN packets as a visual
aid for demarcating the beginning and end of this stream.

You will also notice that after filtering this stream, you can see
fewer telnet packets. This operation excluded that second
telnet session of yours. Neat!

Now that you’ve seen Streams, it's time to check out


Conversations.

6. In the display filter, click the X icon on the right to remove your
current filter expression.

7. Select any packet with 192.168.1.1 (the address of h1) in the


Source column and 172.16.0.1 (the address of webserver) in
the Destination column.

8. Right-click the selected packet and select Conversation


Filter > IPv4 from the context menu.
Look at the filter display—all Wireshark did was say “group all
packets that contain both of these IP addresses.” As you can
see, Conversations are Wireshark’s way of grouping all traffic
passed between two endpoints, regardless of individual
sessions or protocols.

Some protocols are connection-less, so they don’t use SYN and


FIN flags to start and end sessions. In those cases, it’s useful to
begin with a Conversation, and then filter the display to only
the target protocol. One example of a connection-less protocol
is the familiar HTTP. Let's look at that next.

9. In the display filter, append the following to the current filter


expression and press Enter:

and http
This shows any HTTP traffic exchanged by the two hosts in this
conversation. Find an HTTP packet and follow that stream to
see where it gets you.

10. Select and right-click any HTTP packet, then


select Follow > HTTP Stream from the context menu.

Each request for a website is met with a response, and that’s


the extent of HTTP in the stream. A total of one exchange—as
we said, connection-less. However, it’s still handy to get the
exchange in your stream window for easy reading. Remember,
client request is red, server is blue: can you tell what type of
Server is running on webserver?

Take note of the version of Python listed here. You'll need it to


answer one of the questions on the Tasks tab.

11. Close the Follow HTTP Stream window.

Next, you will try out some other HTTP filters. You logged into
that web application, so if HTTP is connection-less, how does
the web application recognize you?

Cookies. Yum.

12. In the display filter, replace the current filter expression


with http.cookie.
Here are all packets that contain the HTTP cookies. A session
cookie was added to your browser as a form of identifying you
with each request, and will be a jumble of alphanumeric
characters. But this application also added an additional cookie
in plain english, and wasn’t removed when you logged out
(pesky trackers…). Can you spot it?

Hint: Expand the Hypertext Transfer Protocol line for each


packet and look for the line beginning with Cookie.

Take note of the cookie (it's wrapped in {brackets}). You will


need this information to answer one of the questions on the
Tasks tab.

You can double-click on a packet to reveal its contents in a


dedicated window. Check out a couple packets and see if you
can find this human-readable cookie. Remember that
Wireshark groups the packets in the order they were received.
Since this cookie wasn’t removed at logout (but the session
cookie was), check out a packet that came after the /logout
request.

Speaking of unwelcome injections, didn’t that site push a file


download to your computer that was quickly deleted? No
problem – Wireshark lets you reconstitute this file from the
packet data. I mean, why wouldn’t it, when you’ve captured
all the bytes passing through the wire?

One exported file coming up, hot off the wire.

13. From the Wireshark menu, select File > Export Objects
> HTTP to open the Export dialog box.

No filter required – this view shows a list of data objects


transferred with HTTP. One of those objects looks juicy, why
don’t you pull that one down and take a closer look.

14. In the Export dialog box, select the HTTP object with a
Filename of download, then click Save.
15. In the Save Object As... dialog box, click Save to save the
file with the default name.

Let’s check out your pull!

16. On the docked menu at the bottom of the screen, click


the Folder icon on the right side, then select h1 > Open
Folder.

17. Double-click the file called download to get a closer look


at your loot.

Score! Unfortunately, Harold’s pain can’t be hidden when a


wire shark is on the job.

Take note of the last two words in this image. You will need
this information to answer one of the questions on the Tasks
tab.

Last step – time to review your file transfer. Return to the


Wireshark window and close the Export dialog box.
18. In the display filer, replace the current filter expression
with ftp and press Enter.

19. Select and right-click any packet and select Follow >
TCP Stream from the context menu.

As before, the full exchange is recounted in red and blue


transmissions. A neat ledger that contains the username and
password in cleartext, as well as the files that were
transferred.

But what about the contents of the file? You can see that, too.
You just need a different filter, because FTP uses a separate
channel for transferring the content of files.
20. Close the Follow TCP Stream window.

21. In the display filter, replace the current expression


with ftp-data and press Enter.

22. Select and right-click the packet that


lists passwords.txt in the Info column, then select Follow >
TCP Stream from the context menu.

Jackpot! You shark, you.

You might also like