Running head: LIVE DATA CAPTURE 1

Live Data Capture

Mawadda S. Abuhamda

University of Advancing Technology

Author Note

Here is my report about the data capture I performed on my computer.

LIVE DATA CAPTURE 2

I used Wireshark to perform a live data capture of my Windows 10 Home computer. I

captured data for a few minutes while doing things for school and work. One thing I had open

was a VPN connection to a virtual machine for my work. There were a lot of TCP packets

because of that and a lot of TLSv1 Application Data packets. The application packets were from

my work’s IP to my IP. The TCP packets were from my IP to my work’s IP. I recognized the

destination IP, which further confirmed that it was from the VM I had open for work.

I also noticed a packet from a source IP of 74.125.137.189. The destination was my IP

address. I wanted to see what it belonged to, so I pinged it. I got a reply, so I decided to type it

into my web browser. It turned out to be Google’s homepage. The packet right after it was a

packet with a source IP of my address and a destination IP of Google. They were both UDP

packets. When I opened the packets, I saw that the source port for the first one was 443 and the

destination port was 65091. I remember learning about ephemeral ports, so I knew that the

destination port wouldn’t be 443 even though the connection is secure. The second packet, which

was from my computer to Google, had a source port of 65091 and a destination port of 443,

which just showed that the connection was continuing. There were many other packets with

Google’s IP as either the source or destination in my capture. I didn’t visit Google’s homepage at

all, so I think the packets were just the result of me using Google Chrome as my browser.

There were a few interesting-looking packets called TCP retransmission packets. I

researched them and found out that if a TCP packet is lost or damaged the first time, it

retransmits again. The packet right after that was a D-SACK packet, which means that it notified

the sender of the retransmission. There were also a few TCP spurious retransmission packets

which means that the receiver acknowledged that it received the packets, but not before the

sender resent them.

LIVE DATA CAPTURE 3

There were also two TCP packets from Slack to my IP and from my IP to Slack. I almost

always have Slack open on my computer.

There were also many packets that used the QUIC protocol, which is a protocol designed

by Google to connect Google Chrome users to Google servers faster.

Some useful things I noticed in general about Wireshark is that it shows you the exact

time and date that individual packets were captured. It also shows you the time between a packet

and the one right before it. These things can be very helpful during investigations.
LIVE DATA CAPTURE 4

References

Jasper. (2015, June 4). TCP SACK in capture shows range of previous segments instead of

subsequent. Retrieved from Wireshark: https://osqa-

ask.wireshark.org/questions/42878/tcp-sack-in-capture-shows-range-of-previous-

segments-instead-of-subsequent

JavaTpoint. (n.d.). TCP Retransmission. Retrieved from JavaTpoint:

https://www.javatpoint.com/tcp-retransmission

Luttgens, J. T., Pepe, M., & Mandia, K. (2014). Incident Response & Computer Forensics, Third

Edition. McGrawHill Education.

Reprakash, A. (2015, April 10). What are TCP Spurious Retransmissions? Retrieved from IT

Blogtorials: https://ithitman.blogspot.com/2015/04/what-are-tcp-spurious-

retransmissions.html