This blog post demonstrates how to use tshark to investigate signs of malicious activity found in a .pcap, or packet capture, file. For this tutorial, I will be using an analysis exercise provided by Brad from


  • Tools: wget,mv,unzip,tshark,sort,uniq,sha256sum,md5sum,whois,date,grep
  • Malware .pcap file: 2018-10-31-traffic-analysis-exercise.pcap


Use wget to download the .pcap file.


Once downloaded, unzip the .pcap and supply the correct password when prompted. As of right now, the About page says the correct password is infected. Yet, check the page for yourself if it doesn’t work for some reason.

[] 2018-10-31-traffic-analysis-exercise.pcap password:
  inflating: 2018-10-31-traffic-analysis-exercise.pcap

Now, rename the .pcap so it’s easier to feed to tshark.

mv 2018-10-31-traffic-analysis-exercise.pcap malware.pcap

What are we investigating?

The analysis exercise we will be using includes the questions below. During our investigation, we must answer all of these and provide a handful of artifacts as evidence.

Questions to answer

  1. What is the date and time of the malicious activity (in GMT or UTC)?
  2. What is the account name or username from the infected Windows computer?
  3. What is the host name of the infected Windows computer?
  4. What is the MAC address of the infected Windows computer?
  5. What are the SHA256 file hashes for any malware from the pcap?
  6. What type of infection this is?


First, let’s enumerate our network environment by listing all participants of unique conversations within our .pcap file.

tshark -r malware.pcap -T fields -e ip.addr | sort | uniq,,		# interesting,,,,,,,,,,,,,,,,,,,,,,,,,,

It appears there are two IP addresses worth looking into: and According to RFC 1918, both fall into a private IP address block - meaning they are not allowed on the open Internet and therefore must be part of the local area network (LAN) we’re investigating.

# Private, non-routable IP addresses according to RFC 1918        -  (10/8 prefix)      -  (172.16/12 prefix)     - (192.168/16 prefix)

Personally, I would make the assumption is our victim Microsoft (MS) Windows computer while is another local node of some sort. Yet, let us prove this assumption by filtering for DNS query packets with .107 as the source address. The resulting output will show .107 probing its DNS server, which is commonly performed prior to authenticating with a domain and/or communicating with HTTP servers.

tshark -r malware.pcap -t ud -Y 'ip.src== and udp.port==53'
3 2018-10-31 15:33:05.385536 →   DNS 128 Standard query 0x0e3d SRV
4 2018-10-31 15:33:05.387261 →   DNS 128 Standard query 0xe1a1 SRV
7 2018-10-31 15:33:05.392557 →   DNS 92 Standard query 0xad1f A
9 2018-10-31 15:33:05.392558 →   DNS 92 Standard query 0xad46 A
82 2018-10-31 15:33:05.687645 →   DNS 133 Standard query 0xdac4 SRV
144 2018-10-31 15:33:05.771571 →   DNS 118 Standard query 0xa9a8 SRV
158 2018-10-31 15:33:05.804818 →   DNS 133 Standard query 0xb5e8 SRV
234 2018-10-31 15:33:08.192352 →   DNS 81 Standard query 0xab1b A
242 2018-10-31 15:33:09.028340 →   DNS 92 Standard query 0x5151 A
244 2018-10-31 15:33:09.031149 →   DNS 83 Standard query 0x41d0 A
284 2018-10-31 15:33:10.920842 →   DNS 78 Standard query 0x8b81 A isatap.localdomain
289 2018-10-31 15:33:11.494498 →   DNS 134 Standard query 0xfe17 SRV
291 2018-10-31 15:33:11.496791 →   DNS 103 Standard query 0xf00e SRV
409 2018-10-31 15:33:13.132481 →   DNS 76 Standard query 0x7a1c A
410 2018-10-31 15:33:13.190487 →   DNS 88 Standard query 0x43e1 SOA
412 2018-10-31 15:33:13.194711 →   DNS 156 Dynamic update 0xd2a9 SOA CNAME AAAA A A
969 2018-10-31 15:34:29.482516 →   DNS 73 Standard query 0x65cd A
3438 2018-10-31 15:35:06.565274 →   DNS 91 Standard query 0x6f18 A
3441 2018-10-31 15:35:06.670419 →   DNS 90 Standard query 0x9e8c A
3443 2018-10-31 15:35:06.757945 →   DNS 97 Standard query 0x6d97 A
3445 2018-10-31 15:35:06.844506 →   DNS 97 Standard query 0x1a7e A
3447 2018-10-31 15:35:06.930897 →   DNS 95 Standard query 0x9a5d A
4638 2018-10-31 15:35:44.961584 →   DNS 81 Standard query 0xec9f A
4710 2018-10-31 15:36:10.531884 →   DNS 128 Standard query 0x5b5f SRV
5366 2018-10-31 15:44:10.544124 →   DNS 92 Standard query 0x5132 A
5732 2018-10-31 15:45:45.017734 →   DNS 68 Standard query 0x3012 A
5735 2018-10-31 15:45:45.145342 →   DNS 71 Standard query 0xb9ed A
5901 2018-10-31 15:45:45.832657 →   DNS 78 Standard query 0x2b30 A

With this output, we can now begin deducing a number of things. For example, we see is exclusively used by to resolve multiple IP addresses (meaning .4 is a DNS server on the LAN). We also see a few queries for SRV records which are used in identifying which nodes are serving various applications. Take frame #3 for instance. It shows .107 looking to find a Domain Controller (DC) for the domain.

Looking down further at frame #412, we also see a single Dynamic update for a SOA record. Use the following command to dissect it.

tshark -r malware.pcap -Y 'frame.number==412' -V
Frame 412: 156 bytes on wire (1248 bits), 156 bytes captured (1248 bits)
Ethernet II, Src: HewlettP_2a:96:0a (00:50:8b:2a:96:0a), Dst: Dell_fc:e2:99 (00:06:5b:fc:e2:99)
Internet Protocol Version 4, Src:, Dst:
User Datagram Protocol, Src Port: 53785, Dst Port: 53
Domain Name System (query)
    Zone type SOA, class IN
            [Name Length: 16]
            [Label Count: 2]
            Type: SOA (Start Of a zone of Authority) (6)
            Class: IN (0x0001)
    Prerequisites type CNAME, class NONE
            Type: CNAME (Canonical NAME for an alias) (5)
            Class: NONE (0x00fe)
            Time to live: 0
            Data length: 0
    Updates type AAAA, class ANY
            Type: AAAA (IPv6 Address) (28)
            Class: ANY (0x00ff)
            Time to live: 0
            Data length: 0 type A, class ANY
            Type: A (Host Address) (1)
            Class: ANY (0x00ff)
            Time to live: 0
            Data length: 0 type A, class IN, addr
            Type: A (Host Address) (1)
            Class: IN (0x0001)
            Time to live: 1200
            Data length: 4

Answering questions #3 and #4
The Dynamic update is giving its MAC address (00:50:8b:2a:96:0a) and hostname (Headless-PC) to the local DNS server. Which is good - more information on “what” may be infected. Yet, we still need some kind of overt confirmation as well as the date, time, and type of malicious activity.

Search the .pcap for HTTP requests using the command sentence below.

tshark -r malware.pcap -t ud -Y 'ip.src== and http'
418 2018-10-31 15:33:13.292583 →  HTTP 151 GET /ncsi.txt HTTP/1.1 
679 2018-10-31 15:34:11.876501 → HTTP 128 GET /startr.ack HTTP/1.1 
974 2018-10-31 15:34:29.799102 → HTTP 257 GET /plain/clientip HTTP/1.1 
3370 2018-10-31 15:34:54.016747 → HTTP 405 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/81/ HTTP/1.1 
3533 2018-10-31 15:35:27.712881 → HTTP 340 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/83/ HTTP/1.1 
4644 2018-10-31 15:35:45.125617 → HTTP 251 GET / HTTP/1.1 
5165 2018-10-31 15:36:11.105720 → HTTP 280 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/90 HTTP/1.1 
6109 2018-10-31 15:45:45.982930 → HTTP 193 GET /roots/dstrootcax3.p7c HTTP/1.1

The first HTTP request (frame #418) could be of interest as it is only a few frames away from the previous DNS query we analyzed. Yet, it’s actually benign as Microsoft systems are typically configured with a service called Network Connectivity Status Indicator (NCSI). NCSI is used to get information about your network and then, download a web page to confirm connectivity (it’ll display a Yellow triangle if it fails).

The second HTTP request however (frame #679), is not benign. Let’s download a .csv file containing a list of known malicious IP addresses to search it for the HTTP server at

curl > blacklist.csv
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 14.8M  100 14.8M    0     0  8644k      0  0:00:01  0:00:01 --:--:-- 8639k
grep blacklist.csv 
"72453","2018-10-30 17:23:02","","offline","malware_download","Trickbot",""

Answering questions #1 and #6
Great! This proves is an external source of distribution for malware called “Trickbot.” Therefore, frame #679 in our .pcap file identifies 2018-10-31 15:34:11 UTC as the date & time of malicious activity. Not to mention, frame #679 also indicates start.ack as the indicator of compromise (IOC).

Now, we’ll export the malware from our .pcap to a directory called evidence, hash it using sha256sum (to take its “fingerprints”), and then, see if its been seen elsewhere.

tshark -r malware.pcap --export-objects http,evidence

Answering questions #5
You will find other artifacts in your evidence directory, but let’s focus on startr.ack. Run both sha256sum and md5sum.

sha256sum evidence/startr.ack
396223eeec49493a52dd9d8ba5348a332bf064483a358db79d8bb8d22e6eb62c evidence/startr.ack
md5sum evidence/startr.ack
2e335d2d0916114dc56407dbc427ebf5  evidence/startr.ack

Again, with the malware’s hash values in-hand, we’ll ask our friends Team Cymru to search their Registry and tell us the last time (if ever) they saw this sample as well as a percent average for anti-virus products detecting it. Team Cymru specializes in threat intelligence and analyzing malicious Internet activity.

whois -h 2e335d2d0916114dc56407dbc427ebf5
2e335d2d0916114dc56407dbc427ebf5 1545568500 NO_DATA

It appears there’s NO_DATA available for the AV detection metric. Nonetheless, use the following command to make sense of the “last seen” timestamp.

date -d @1545568500 
Sun Dec 23 07:35:00 EST 2018 # timestamp for when Trickbot was last seen

Answering question #2
Now, to find out who downloaded the malware. Seeing as this is a MS Windows environment, let’s filter our .pcap file for packets with as the source address, kerberos as the protocol, and grep for CNameString. Kerberos is a protocol used to internally authenticate users onto a domain. The Kerberos field CNameString contains Client Name “Character string” values.

RFC 4120 - The Kerberos Network Authentication Service (V5) explains, “This field contains the name part of the client’s principal identifier.” In their entirety, Principal Identifers for user clients are comprised of a username & domain. An example would look like this:

Lastly, filtering for usernames this way instead of using kerberos.CNameString shows the value from each frame instead of displaying every frame containing the field kerberos.CNameString (think show me versus tell me).

tshark -r malware.pcap -Y 'ip.src== and kerberos' -V | grep CNameString
CNameString: headless-pc$
CNameString: headless-pc$
CNameString: headless-pc$
CNameString: headless-pc$
CNameString: ichabod.crane
CNameString: ichabod.crane

Success! It appears ichabod.crane is now the suspect in our investigation. Let’s take a step back and filter for frames containing this username for reference.

tshark -r malware.pcap -t ud -Y 'kerberos.CNameString==ichabod.crane'
500 2018-10-31 15:33:27.098248 →   KRB5 291 AS-REQ
508 2018-10-31 15:33:27.137685 →   KRB5 371 AS-REQ
510 2018-10-31 15:33:27.138631 → KRB5 224 AS-REP
522 2018-10-31 15:33:27.142123 → KRB5 132 TGS-REP
536 2018-10-31 15:33:27.189280 → KRB5 262 TGS-REP
567 2018-10-31 15:33:27.725585 → KRB5 246 TGS-REP
603 2018-10-31 15:33:27.763775 → KRB5 246 TGS-REP
615 2018-10-31 15:33:27.765637 → KRB5 110 TGS-REP


  1. What is the date and time of the malicious activity (in GMT or UTC)?
    2018-10-31 15:34:11
  2. What is the account name or username from the infected Windows computer?
  3. What is the host name of the infected Windows computer?
  4. What is the MAC address of the infected Windows computer?
  5. What are the SHA256 file hashes for any malware from the pcap?
  6. What type of infection this is?
    Trickbot malware