Chewing on Malware Packet Captures

Table of Contents

• Requirements
• Setup
• What are we investigating?
• Analysis
• Review
• References

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 malware-traffic-analysis.net.

Requirements

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

Setup

Use wget to download the .pcap file.

wget https://www.malware-traffic-analysis.net/2018/10/31/2018-10-31-traffic-analysis-exercise.pcap.zip

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

unzip 2018-10-31-traffic-analysis-exercise.pcap.zip

Archive:  2018-10-31-traffic-analysis-exercise.pcap.zip
[2018-10-31-traffic-analysis-exercise.pcap.zip] 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?

Analysis

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

10.100.9.107,10.100.9.255
10.100.9.107,10.100.9.4		# interesting
10.100.9.107,151.101.184.193
10.100.9.107,173.171.132.82
10.100.9.107,176.58.123.25
10.100.9.107,192.35.177.64
10.100.9.107,224.0.0.22
10.100.9.107,224.0.0.252
10.100.9.107,23.62.239.8
10.100.9.107,255.255.255.255
10.100.9.107,34.233.102.38
10.100.9.107,37.120.182.208
10.100.9.107,42.115.91.177
10.100.9.107,46.173.214.185
10.100.9.107,51.68.170.57
10.100.9.107,82.222.40.119
10.100.9.4,10.100.9.107
151.101.184.193,10.100.9.107
173.171.132.82,10.100.9.107
176.58.123.25,10.100.9.107
192.35.177.64,10.100.9.107
23.62.239.8,10.100.9.107
34.233.102.38,10.100.9.107
37.120.182.208,10.100.9.107
42.115.91.177,10.100.9.107
46.173.214.185,10.100.9.107
51.68.170.57,10.100.9.107
82.222.40.119,10.100.9.107

It appears there are two IP addresses worth looking into: 10.100.9.4 and 10.100.9.107. 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.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Personally, I would make the assumption 10.100.9.107 is our victim Microsoft (MS) Windows computer while 10.100.9.4 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==10.100.9.107 and udp.port==53'

3 2018-10-31 15:33:05.385536 10.100.9.107 → 10.100.9.4   DNS 128 Standard query 0x0e3d SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.halloweenjob.com
4 2018-10-31 15:33:05.387261 10.100.9.107 → 10.100.9.4   DNS 128 Standard query 0xe1a1 SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.halloweenjob.com
7 2018-10-31 15:33:05.392557 10.100.9.107 → 10.100.9.4   DNS 92 Standard query 0xad1f A halloweenjob-dc.halloweenjob.com
9 2018-10-31 15:33:05.392558 10.100.9.107 → 10.100.9.4   DNS 92 Standard query 0xad46 A halloweenjob-dc.halloweenjob.com
82 2018-10-31 15:33:05.687645 10.100.9.107 → 10.100.9.4   DNS 133 Standard query 0xdac4 SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.halloweenjob.com
144 2018-10-31 15:33:05.771571 10.100.9.107 → 10.100.9.4   DNS 118 Standard query 0xa9a8 SRV _ldap._tcp.Default-First-Site-Name._sites.halloweenjob.com
158 2018-10-31 15:33:05.804818 10.100.9.107 → 10.100.9.4   DNS 133 Standard query 0xb5e8 SRV _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.halloweenjob.com
234 2018-10-31 15:33:08.192352 10.100.9.107 → 10.100.9.4   DNS 81 Standard query 0xab1b A wpad.halloweenjob.com
242 2018-10-31 15:33:09.028340 10.100.9.107 → 10.100.9.4   DNS 92 Standard query 0x5151 A Halloweenjob-DC.halloweenjob.com
244 2018-10-31 15:33:09.031149 10.100.9.107 → 10.100.9.4   DNS 83 Standard query 0x41d0 A isatap.halloweenjob.com
284 2018-10-31 15:33:10.920842 10.100.9.107 → 10.100.9.4   DNS 78 Standard query 0x8b81 A isatap.localdomain
289 2018-10-31 15:33:11.494498 10.100.9.107 → 10.100.9.4   DNS 134 Standard query 0xfe17 SRV _ldap._tcp.Default-First-Site-Name._sites.Halloweenjob-DC.halloweenjob.com
291 2018-10-31 15:33:11.496791 10.100.9.107 → 10.100.9.4   DNS 103 Standard query 0xf00e SRV _ldap._tcp.Halloweenjob-DC.halloweenjob.com
409 2018-10-31 15:33:13.132481 10.100.9.107 → 10.100.9.4   DNS 76 Standard query 0x7a1c A www.msftncsi.com
410 2018-10-31 15:33:13.190487 10.100.9.107 → 10.100.9.4   DNS 88 Standard query 0x43e1 SOA Headless-PC.halloweenjob.com
412 2018-10-31 15:33:13.194711 10.100.9.107 → 10.100.9.4   DNS 156 Dynamic update 0xd2a9 SOA halloweenjob.com CNAME AAAA A A 10.100.9.107
969 2018-10-31 15:34:29.482516 10.100.9.107 → 10.100.9.4   DNS 73 Standard query 0x65cd A ip.anysrc.net
3438 2018-10-31 15:35:06.565274 10.100.9.107 → 10.100.9.4   DNS 91 Standard query 0x6f18 A 112.146.66.173.zen.spamhaus.org
3441 2018-10-31 15:35:06.670419 10.100.9.107 → 10.100.9.4   DNS 90 Standard query 0x9e8c A 112.146.66.173.cbl.abuseat.org
3443 2018-10-31 15:35:06.757945 10.100.9.107 → 10.100.9.4   DNS 97 Standard query 0x6d97 A 112.146.66.173.b.barracudacentral.org
3445 2018-10-31 15:35:06.844506 10.100.9.107 → 10.100.9.4   DNS 97 Standard query 0x1a7e A 112.146.66.173.dnsbl-1.uceprotect.net
3447 2018-10-31 15:35:06.930897 10.100.9.107 → 10.100.9.4   DNS 95 Standard query 0x9a5d A 112.146.66.173.spam.dnsbl.sorbs.net
4638 2018-10-31 15:35:44.961584 10.100.9.107 → 10.100.9.4   DNS 81 Standard query 0xec9f A checkip.amazonaws.com
4710 2018-10-31 15:36:10.531884 10.100.9.107 → 10.100.9.4   DNS 128 Standard query 0x5b5f SRV _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.halloweenjob.com
5366 2018-10-31 15:44:10.544124 10.100.9.107 → 10.100.9.4   DNS 92 Standard query 0x5132 A HALLOWEENJOB-DC.halloweenjob.com
5732 2018-10-31 15:45:45.017734 10.100.9.107 → 10.100.9.4   DNS 68 Standard query 0x3012 A ident.me
5735 2018-10-31 15:45:45.145342 10.100.9.107 → 10.100.9.4   DNS 71 Standard query 0xb9ed A i.imgur.com
5901 2018-10-31 15:45:45.832657 10.100.9.107 → 10.100.9.4   DNS 78 Standard query 0x2b30 A apps.identrust.com

With this output, we can now begin deducing a number of things. For example, we see 10.100.9.4 is exclusively used by 10.100.9.107 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 halloweenjob.com 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: 10.100.9.107, Dst: 10.100.9.4
User Datagram Protocol, Src Port: 53785, Dst Port: 53
Domain Name System (query)
    Zone
        halloweenjob.com: type SOA, class IN
            Name: halloweenjob.com
            [Name Length: 16]
            [Label Count: 2]
            Type: SOA (Start Of a zone of Authority) (6)
            Class: IN (0x0001)
    Prerequisites
        Headless-PC.halloweenjob.com: type CNAME, class NONE
            Name: Headless-PC.halloweenjob.com
            Type: CNAME (Canonical NAME for an alias) (5)
            Class: NONE (0x00fe)
            Time to live: 0
            Data length: 0
    Updates
        Headless-PC.halloweenjob.com: type AAAA, class ANY
            Name: Headless-PC.halloweenjob.com
            Type: AAAA (IPv6 Address) (28)
            Class: ANY (0x00ff)
            Time to live: 0
            Data length: 0
        Headless-PC.halloweenjob.com: type A, class ANY
            Name: Headless-PC.halloweenjob.com
            Type: A (Host Address) (1)
            Class: ANY (0x00ff)
            Time to live: 0
            Data length: 0
        Headless-PC.halloweenjob.com: type A, class IN, addr 10.100.9.107
            Name: Headless-PC.halloweenjob.com
            Type: A (Host Address) (1)
            Class: IN (0x0001)
            Time to live: 1200
            Data length: 4
            Address: 10.100.9.107

Answering questions #3 and #4
The Dynamic update is 10.100.9.107 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==10.100.9.107 and http'

418 2018-10-31 15:33:13.292583 10.100.9.107 → 23.62.239.8  HTTP 151 GET /ncsi.txt HTTP/1.1
679 2018-10-31 15:34:11.876501 10.100.9.107 → 46.173.214.185 HTTP 128 GET /startr.ack HTTP/1.1
974 2018-10-31 15:34:29.799102 10.100.9.107 → 37.120.182.208 HTTP 257 GET /plain/clientip HTTP/1.1
3370 2018-10-31 15:34:54.016747 10.100.9.107 → 173.171.132.82 HTTP 405 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/81/ HTTP/1.1
3533 2018-10-31 15:35:27.712881 10.100.9.107 → 173.171.132.82 HTTP 340 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/83/ HTTP/1.1
4644 2018-10-31 15:35:45.125617 10.100.9.107 → 34.233.102.38 HTTP 251 GET / HTTP/1.1
5165 2018-10-31 15:36:11.105720 10.100.9.107 → 173.171.132.82 HTTP 280 POST /sat91/HEADLESS-PC_W617601.88AD32764B61024C64A0DFEC972C64A8/90 HTTP/1.1
6109 2018-10-31 15:45:45.982930 10.100.9.107 → 192.35.177.64 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 46.173.214.185.

curl https://urlhaus.abuse.ch/downloads/csv/ > 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 46.173.214.185 blacklist.csv

"72453","2018-10-30 17:23:02","http://46.173.214.185/startr.ack","offline","malware_download","Trickbot","https://urlhaus.abuse.ch/url/72453/"

Answering questions #1 and #6
Great! This proves 46.173.214.185 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 hash.cymru.com 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 10.100.9.107 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: victor@yourserver.tech.

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==10.100.9.107 and kerberos' -V | grep CNameString

CNameString: headless-pc$
CNameString: headless-pc$
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 10.100.9.107 → 10.100.9.4   KRB5 291 AS-REQ
508 2018-10-31 15:33:27.137685 10.100.9.107 → 10.100.9.4   KRB5 371 AS-REQ
510 2018-10-31 15:33:27.138631   10.100.9.4 → 10.100.9.107 KRB5 224 AS-REP
522 2018-10-31 15:33:27.142123   10.100.9.4 → 10.100.9.107 KRB5 132 TGS-REP
536 2018-10-31 15:33:27.189280   10.100.9.4 → 10.100.9.107 KRB5 262 TGS-REP
567 2018-10-31 15:33:27.725585   10.100.9.4 → 10.100.9.107 KRB5 246 TGS-REP
603 2018-10-31 15:33:27.763775   10.100.9.4 → 10.100.9.107 KRB5 246 TGS-REP
615 2018-10-31 15:33:27.765637   10.100.9.4 → 10.100.9.107 KRB5 110 TGS-REP

Review

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?
   ichabod.crane
3. What is the host name of the infected Windows computer?
   Headless-PC
4. What is the MAC address of the infected Windows computer?
   00:50:8b:2a:96:0a
5. What are the SHA256 file hashes for any malware from the pcap?
   396223eeec49493a52dd9d8ba5348a332bf064483a358db79d8bb8d22e6eb62c
6. What type of infection this is?
   Trickbot malware

References

• 2018-10-31 - TRAFFIC ANALYSIS EXERCISE - HAPPY HALLOWEEN!
• 2018-10-31 - TRAFFIC ANALYSIS EXERCISE - ANSWERS
• HackerTarget: tshark
• LinuxMagazine: tshark
• Linux Simba: Tshark Command Examples
• Wireshark: UTC time with -T fields
• Wireshark: Determining unique MAC and IP addresses in a PCAP
• Wireshark: How do I design a filter based on packet number?
• Medium: Kerberos Wireshark Captures
• RFC 4120: The Kerberos Network Authentication Service (V5)
• MIT: What is a Kerberos Principal?
• MSDN: DNS Records that are required for proper functionality of Active Directory
• Zulhardy Rahim: www.msftncsi.com