Views: 20
TShark VS. Wireshark (Terminal vs. GUI)
TShark is a purpose-built terminal tool based on Wireshark. TShark shares many of the same features that are included in Wireshark and even shares syntax and options. TShark is perfect for use on machines with little or no desktop environment and can easily pass the capture information it receives to another tool via the command line. Wireshark is the feature-rich GUI option for traffic capture and analysis. If we wish to have the full-featured experience and work from a machine with a desktop environment, the Wireshark GUI is the way to go.
Basic TShark Switches
Switch Command | Result |
---|---|
D | Will display any interfaces available to capture from and then exit out. |
L | Will list the Link-layer mediums you can capture from and then exit out. (ethernet as an example) |
i | choose an interface to capture from. (-i eth0) |
f | packet filter in libpcap syntax. Used during capture. |
c | Grab a specific number of packets, then quit the program. Defines a stop condition. |
a | Defines an autostop condition. Can be after a duration, specific file size, or after a certain number of packets. |
r (pcap-file) | Read from a file. |
W (pcap-file) | Write into a file using the pcapng format. |
P | Will print the packet summary while writing into a file (-W) |
x | will add Hex and ASCII output into the capture. |
h | See the help menu |
TShark Basic Usage
tshark -h
which tshark
tshark -D
## Capturing
tshark -i 1 -w /tmp/test.pcap
## Selecting an Interface & Writing to a File
sudo tshark -i eth0 -w /tmp/test.pcap
## Applying Filters
sudo tshark -i eth0 -f "host 172.16.146.2"
Termshark
Termshark is a Text-based User Interface (TUI) application that provides the user with a Wireshark-like interface right in your terminal window.
To start Termshark, issue the same strings, much like TShark or tcpdump. We can specify an interface to capture on, filters, and other settings from the terminal. The Termshark window will not open until it senses traffic in its capture filter. So give it a second if nothing happens.
Wireshark
ORANGE: Summary line of each packet, BLUE: Packet Details window with each packet dissected into different encapsulation layers for inspection and GREEN: Packet Bytes windos with packet contents in ASCII or hex output
Capture Filters
Capture Filters-
are entered before the capture is started. These use BPF syntax like host 214.15.2.30
much in the same fashion as TCPDump.
Capture Filters | Result |
---|---|
host x.x.x.x | Capture only traffic pertaining to a certain host |
net x.x.x.x/24 | Capture traffic to or from a specific network (using slash notation to specify the mask) |
src/dst net x.x.x.x/24 | Using src or dst net will only capture traffic sourcing from the specified network or destined to the target network |
port # | will filter out all traffic except the port you specify |
not port # | will capture everything except the port specified |
port # and # | AND will concatenate your specified ports |
portrange x-x | portrange will grab traffic from all ports within the range only |
ip / ether / tcp | These filters will only grab traffic from specified protocol headers. |
broadcast / multicast / unicast | Grabs a specific type of traffic. one to one, one to many, or one to all. |
Display Filters
Display Filters-
are used while the capture is running and after the capture has stopped. Display filters are proprietary to Wireshark, which offers many different options for almost any protocol.
Common and helpful display filters
Display Filters | Result |
---|---|
ip.addr == x.x.x.x | Capture only traffic pertaining to a certain host. This is an OR statement. |
ip.addr == x.x.x.x/24 | Capture traffic pertaining to a specific network. This is an OR statement. |
ip.src/dst == x.x.x.x | Capture traffic to or from a specific host |
dns / tcp / ftp / arp / ip | filter traffic by a specific protocol. There are many more options. |
tcp.port == x | filter by a specific tcp port. |
tcp.port / udp.port != x | will capture everything except the port specified |
and / or / not | AND will concatenate, OR will find either of two options, NOT will exclude your input option. |
Wireshark Advanced Usage
Plugins
The Statistics and Analyze Tabs
The Statistics and Analyze tabs can provide us with great insight into the data we are examining. From these points, we can utilize many of the baked-in plugins Wireshark has to offer.
Analyze Tab
From the Analyze tab, we can utilize plugins that allow us to do things such as following TCP streams, filter on conversation types, prepare new packet filters and examine the expert info Wireshark generates about the traffic. Below are a few examples of how to use these plugins.
Following TCP Streams
Wireshark can stitch TCP packets back together to recreate the entire stream in a readable format. This ability also allows us to pull data (images, files, etc.
) out of the capture. This works for almost any protocol that utilizes TCP as a transport mechanism.
Alternatively, we can utilize the filter tcp.stream eq #
to find and track conversations captured in the pcap file.
Filter For A Specific TCP Stream
Extracting Data and Files From a Capture
Wireshark can recover many different types of data from streams. It requires you to have captured the entire conversation. Otherwise, this ability will fail to put an incomplete datagram back together.
Display Filters Reference
Complete List: https://www.wireshark.org/docs/dfref/
FTP display filters
Field name | Description | Type | Versions |
---|---|---|---|
ftp-data.command | Command | Character string | 2.6.0 to 4.2.0 |
ftp-data.command-frame | Command frame | Frame number | 2.6.0 to 4.2.0 |
ftp-data.current-working-directory | Current working directory | Character string | 2.6.0 to 4.2.0 |
ftp-data.setup-frame | Setup frame | Frame number | 2.6.0 to 4.2.0 |
ftp-data.setup-method | Setup method | Character string | 2.6.0 to 4.2.0 |
ftp.active.cip | Active IP address | IPv4 address | 1.0.0 to 4.2.0 |
ftp.active.nat | Active IP NAT | Boolean | 1.0.0 to 4.2.0 |
ftp.active.port | Active port | Unsigned integer (16 bits) | 1.0.0 to 4.2.0 |
ftp.command | Command | Character string | 2.6.0 to 4.2.0 |
ftp.command-frame | Command frame | Frame number | 2.6.0 to 4.2.0 |
ftp.command-response.bitrate | Response bitrate | Unsigned integer (32 bits) | 2.6.0 to 4.2.0 |
ftp.command-response.bytes | Command response bytes | Unsigned integer (32 bits) | 2.6.0 to 4.2.0 |
ftp.command-response.duration | Response duration | Unsigned integer (32 bits) | 2.6.0 to 4.2.0 |
ftp.command-response.first-frame-num | Command response first frame | Frame number | 2.6.0 to 4.2.0 |
ftp.command-response.frames | Command response frames | Unsigned integer (32 bits) | 2.6.0 to 4.2.0 |
ftp.command-response.last-frame-num | Command response last frame | Frame number | 2.6.0 to 4.2.0 |
ftp.current-working-directory | Current working directory | Character string | 2.6.0 to 4.2.0 |
ftp.eprt.af | Extended active address family | Unsigned integer (8 bits) | 1.10.0 to 4.2.0 |
ftp.eprt.args_invalid | EPRT arguments must have the form: |||| | Label | 1.12.0 to 4.2.0 |
ftp.eprt.ip | Extended active IP address | IPv4 address | 1.10.0 to 4.2.0 |
ftp.eprt.ipv6 | Extended active IPv6 address | IPv6 address | 1.10.0 to 4.2.0 |
ftp.eprt.port | Extended active port | Unsigned integer (16 bits) | 1.10.0 to 4.2.0 |
ftp.epsv.args_invalid | EPSV arguments must have the form (||||) | Label | 1.12.0 to 4.2.0 |
ftp.epsv.ip | Extended passive IPv4 address | IPv4 address | 1.10.0 to 4.2.0 |
ftp.epsv.ipv6 | Extended passive IPv6 address | IPv6 address | 1.10.0 to 4.2.0 |
ftp.epsv.port | Extended passive port | Unsigned integer (16 bits) | 1.10.0 to 4.2.0 |
ftp.passive.ip | Passive IP address | IPv4 address | 1.0.0 to 4.2.0 |
ftp.passive.nat | Passive IP NAT | Boolean | 1.0.0 to 4.2.0 |
ftp.passive.port | Passive port | Unsigned integer (16 bits) | 1.0.0 to 4.2.0 |
ftp.request | Request | Boolean | 1.0.0 to 4.2.0 |
ftp.request.arg | Request arg | Character string | 1.0.0 to 4.2.0 |
ftp.request.command | Request command | Character string | 1.0.0 to 4.2.0 |
ftp.response | Response | Boolean | 1.0.0 to 4.2.0 |
ftp.response.arg | Response arg | Character string | 1.0.0 to 4.2.0 |
ftp.response.code | Response code | Unsigned integer (32 bits) | 1.0.0 to 4.2.0 |
ftp.response.code.invalid | Invalid response code | Label | 2.4.0 to 4.2.0 |
ftp.response.pwd.invalid | Invalid PWD response | Label | 2.6.0 to 4.2.0 |
ftp.setup-frame | Setup frame | Frame number | 2.6.0 to 4.2.0 |
Miscellaneous
ARP Spoofing & Abnormality Detection
## Display Filter
arp.opcode
Opcode = = 1: This represents all types of ARP Requests
Opcode = = 2: This signifies all types of ARP Replies
To sift through more duplicate records, we can utilize the subsequent Wireshark filter.
arp.duplicate-address-detected && arp.opcode == 2
Identifying The Original IP Addresses
(arp.opcode) && ((eth.src == 08:00:27:53:0c:ba) || (eth.dst == 08:00:27:53:0c:ba))
In this case, we might instantly note that the MAC address 08:00:27:53:0c:ba
was initially linked to the IP address 192.168.10.5
, but this was recently switched to 192.168.10.4
. This transition is indicative of a deliberate attempt at ARP spoofing or cache poisoning.
Additionally, examining the traffic from these MAC addresses with the following Wireshark filter can prove insightful:
eth.addr == 50:eb:f6:ec:0e:7f or eth.addr == 08:00:27:53:0c:ba
Right off the bat, we might notice some inconsistencies with TCP connections. If TCP connections are consistently dropping, it’s an indication that the attacker is not forwarding traffic between the victim and the router.
If the attacker is, in fact, forwarding the traffic and is operating as a man-in-the-middle, we might observe identical or nearly symmetrical transmissions from the victim to the attacker and from the attacker to the router.