Lab Exp 1 To 3
Lab Exp 1 To 3
AIM: Basic Packet Inspection: Capture network traffic using Wire shark and analyze basic
protocols like HTTP, DNS, and SMTP to understand how data is transmitted and received.
Introduction
The first part of the lab introduces packet sniffer, Wireshark. Wireshark is a free open- source
network protocol analyzer. It is used for network troubleshooting and communication protocol
analysis. Wireshark captures network packets in real time and display them in human-readable
format. It provides many advanced features including live capture and offline analysis, three-pane
packet browser, coloring rules for analysis. This document uses Wireshark for the experiments, and it
covers Wireshark installation, packet capturing, and protocol analysis.
1. Application Layer: The application layer includes the protocols used by most applications
for providing user services. Examples of application layer protocols are Hypertext
Transfer Protocol (HTTP), Secure Shell (SSH), File Transfer Protocol (FTP), and Simple
Mail Transfer Protocol (SMTP).
2. Transport Layer: The transport layer establishes process-to-process connectivity, and it
provides end-to-end services that are independent of underlying user data. To implement
the process-to-process communication, the protocol introduces a concept of port. The
examples of transport layer protocols are Transport Control Protocol (TCP) and User
Datagram Protocol (UDP). The TCP provides flow- control, connection establishment,
and reliable transmission of data, while the UDPis a connectionless transmission model.
3. Internet Layer: The Internet layer is responsible for sending packets to across networks. It
has two functions: 1) Host identification by using IP addressing system(IPv4 and IPv6);
and 2) Packets routing from source to destination. The examples of Internet layer
protocols are Internet Protocol (IP), Internet Control Message Protocol (ICMP), and
Address Resolution Protocol (ARP).
4. Link Layer: The link layer defines the networking methods within the scope of the local
network link. It is used to move the packets between two hosts on the same link. An
common example of link layer protocols is Ethernet.
Getting Wireshark
The Kai Linux has Wireshark installed. You can just launch the Kali Linux VM and open Wireshark
there. Wireshark can also be downloaded from here: https://www.wireshark.org/download.html
Figure 3: Download Page of Wireshark
Starting Wireshark
When you run the Wireshark program, the Wireshark graphic user interface will be shown as
Figure below. Currently, the program is not capturing the packets.
Then, an interface should be chosen. If you are running the Wireshark on your laptop,you need to select
WiFi interface. If you are at a desktop, you need to select the Ethernet interface being used. Note that
there could be multiple interfaces. In general, you can select any interface but that does not mean that
traffic will flow through that interface. The
network interfaces (i.e., the physical connections) that your computer has to the networkare shown. After
you select the interface, you can click start to capture the packets as shown in Figure
Figure 5: Capture Interfaces in Wireshark
Capturing Packets
After downloading and installing Wireshark, you can launch it and click the name of an interface
under Interface List to start capturing packets on that interface. For example, if you want to capture
traffic on the wireless network, click your wireless interface.
Test Run
Do the following steps:
1) Start up the Wireshark program (select an interface and press start to capture packets).
4) After your browser has displayed the http://www.wayne.edu page, stop Wireshark packet
capture by selecting stop in the Wireshark capture window. This will cause the Wireshark
capture window to disappear and the main Wireshark window to display all packets
captured since you began packet capture see image below:
5) Color Coding: You’ll probably see packets highlighted in green, blue, and black.
Wireshark uses colors to help you identify the types of traffic at a glance. By default,
green is TCP traffic, dark blue is DNS traffic, light blue is UDP traffic, and black
identifies TCP packets with problems — for example, they could have been delivered
out-of-order.
6) You now have live packet data that contains all protocol messages exchanged between
your computer and other network entities! However, as you will notice the HTTP
messages are not clearly shown because there are many other packets included in the
packet capture. Even though the only action you took was to open your browser, there are
many other programs in your computer that communicate via the network in the
background. To filter the connections to the ones we want to focus on, we have to use the
filtering functionality of Wireshark by typing “http” in the filtering field as shown below:
7) Now, we can try another protocol. Let’s use Domain Name System (DNS) protocol as an
example here.
8) Let’s try now to find out what are those packets contain by following one of the
conversations (also called network flows), select one of the packets and press the right
mouse button (if you are on a Mac use the command button and click), you should see
something similar to the screen below:
Experiment-2
AIM: Detecting Suspicious Activity: Analyze network traffic to identify suspicious patterns, such
as repeated connection attempts or unusual communication between hosts.
Task 1 Introduction-
Note: A VM is attached to this room. You don’t need SSH or RDP; the room provides a “Split View” feature.
DO NOT directly interact with any domains and IP addresses in this room. The domains and IP addresses are
included only for reference reasons.
The images below show the three-way handshake process of the open and close TCP ports. Images and pcap samples
are split to make the investigation easier and understand each case’s details.Open TCP port (Connect):
The above images provide the patterns in isolated traffic. However, it is not always easy to spot the given patterns in
big capture files. Therefore analysts need to use a generic filter to view the initial anomaly patterns, and then it will
be easier to focus on a specific traffic point. The given filter shows the TCP Connect scan patterns in a capture file.
SYN Scans
TCP SYN Scan in a nutshell:
5. Doesn’t rely on the three-way handshake (no need to finish the handshake process).
6. Usually conducted with nmap -sS command.
7. Used by privileged users.
8. Usually have a size less than or equal to 1024 bytes as the request is not finished and it doesn’t expect to
receive data.
The given filter shows the TCP SYN scan patterns in a capture file.
UDP Scans
UDP Scan in a nutshell:
9. Doesn’t require a handshake process
10. No prompt for open ports
11. ICMP error message for close ports
12. Usually conducted with nmap -sU command.
The above image shows that the closed port returns an ICMP error packet. No further information is provided about
the error at first glance, so how can an analyst decide where this error message belongs? The ICMP error message
uses the original request as encapsulated data to show the source/reason of the packet. Once you expand the ICMP
section in the packet details pane, you will see the encapsulated data and the original request, as shown in the below
image.
The given filter shows the UDP scan patterns in a capture file.
Task 3 Identifying Hosts: DHCP, NetBIOS and
Kerberos – Identifying Hosts
When investigating a compromise or malware infection activity, a security analyst should know how to identify
the hosts on the network apart from IP to MAC address match. One of the best methods is identifying the hosts
and users on the network to decide the investigation’s starting point and list the hosts and users associated with the
malicious traffic/activity.
Usually, enterprise networks use a predefined pattern to name users and hosts. While this makes knowing and
following the inventory easier, it has good and bad sides. The good side is that it will be easy to identify a user or
host by looking at the name. The bad side is that it will be easy to clone that pattern and live in the enterprise
network for adversaries. There are multiple solutions to avoid these kinds of activities, but for a security analyst, it
is still essential to have host and user identification skills.
Protocols that can be used in Host and User identification:
13. Dynamic Host Configuration Protocol (DHCP) traffic
14. NetBIOS (NBNS) traffic
15. Kerberos traffic
DHCP Analysis
DHCP protocol, or Dynamic Host Configuration Protocol (DHCP), is the technology responsible for managing
automatic IP address and required communication parameters assignment. DHCP investigation in a nutshell:
NetBIOS (NBNS) Analysis
NetBIOS or Network Basic Input/output System is the technology responsible for allowing applications on different
hosts to communicate with each other.
NBNS investigation in a nutshell:
Kerberos Analysis
Kerberos is the default authentication service for Microsoft Windows domains. It is responsible for authenticating
service requests between two or more computers over the untrusted network. The ultimate aim is to prove identity
securely.
Kerberos investigation in a nutshell:
Tunnelling Traffic: ICMP and DNS Traffic tunnelling is (also known as “port forwarding”) transferring the
data/resources in a secure method to network segments and zones. It can be used for “internet to private networks”
and “private networks to internet” flow/direction. There is an encapsulation process to hide the data, so the
transferred data appear natural for the case, but it contains private data packets and transfers them to the final
destination securely.
Tunnelling provides anonymity and traffic security. Therefore it is highly used by enterprise networks. However, as
it gives a significant level of data encryption, attackers use tunnelling to bypass security perimeters using the
standard and trusted protocols used in everyday traffic like ICMP and DNS. Therefore, for a security analyst, it is
crucial to have the ability to spot ICMP and DNS anomalies.
ICMP Analysis
Internet Control Message Protocol (ICMP) is designed for diagnosing and reporting network communication
issues. It is highly used in error reporting and testing. As it is a trusted network layer protocol, sometimes it is
used for denial of service (DoS) attacks; also, adversaries use it in data exfiltration and C2 tunnelling activities.
ICMP analysis in a nutshell:
Usually, ICMP tunnelling attacks are anomalies appearing/starting after a malware execution or vulnerability
exploitation. As the ICMP packets can transfer an additional data payload, adversaries use this section to exfiltrate
data and establish a C2 connection. It could be a TCP, HTTP or SSH data. As the ICMP protocols provide a great
opportunity to carry extra data, it also has disadvantages. Most enterprise networks block custom packets or require
administrator privileges to create custom ICMP packets.
A large volume of ICMP traffic or anomalous packet sizes are indicators of ICMP tunnelling. Still, the
adversaries could create custom packets that match the regular ICMP packet size (64 bytes), so it is still
cumbersome to detect these tunnelling activities. However, a security analyst should know the normal and the
abnormal to spot the possible anomaly and escalate it for further analysis.
DNS Analysis
Domain Name System (DNS) is designed to translate/convert IP domain addresses to IP addresses. It is also known
as a phonebook of the internet. As it is the essential part of web services, it is commonly used and trusted, and
therefore often ignored. Due to that, adversaries use it in data exfiltration and C2 activities.
DNS analysis in a nutshell:
Similar to ICMP tunnels, DNS attacks are anomalies appearing/starting after a malware execution or vulnerability
exploitation. Adversary creates (or already has) a domain address and configures it as a C2 channel. The malware or
the commands executed after exploitation sends DNS queries to the C2 server. However, these queries are longer
than default DNS queries and crafted for subdomain addresses. Unfortunately, these subdomain addresses are not
actual addresses; they are encoded commands as shown below:
“Encoded-commands.maliciousdomain.com”
When this query is routed to the C2 server, the server sends the actual malicious commands to the host. As the DNS
queries are a natural part of the networking activity, these packets have the chance of not being detected by network
perimeters. A security analyst should know how to investigate the DNS packet lengths and target addresses to spot
these anomalies.
EXPERIMENT- 3
AIM: Malware Traffic Analysis: Analyze captured traffic to identify signs of malware communication, such as
command-and-control traffic or data infiltration.
One of the most effective tools for malware infection has been the Emotet malware; A malware that can itself collect
and transmit data about the systems it infects while actively introducing other malware, such as ransomware, onto the
system. The Emotet malware has been traditionally difficult to detect in systems and in its current form has been
made available to malicious actors as a “Malware-as-a-Service” that can be customized with various malicious
payloads.
Wireshark has two levels of filters: one that is applied at the initial ‘capture’ level, so that only the broader types of
traffic that you are interested in are syphoned from all of the network traffic, and the other that is applied at the
‘display’ level to help isolate data of interest (Porup, 2018). One additional feature of Wireshark is that it also allows
users to configure special ‘coloring rules’ that can highlight captured packets that contain specific signatures of
possible malware that makes it easy to quickly identify potential threats.
Once traffic has been captured and, if necessary, effectively filtered, it can be exported and saved in a .pcap file
that can be stored and analyzed at a later time. Especially useful in this project was Wireshark’s ability to export
the captured data from an infected system as a TCP dump to the .pcap file, which we were then able to acquire and
analyze, without risk of infecting our own systems for the sake of investigation (Duncan, 2021).
As a contraction of the words “malicious” and “software”, the word malware is an umbrella term that covers a vast
number of unique variations. One of those variations is ransomware, a type of malware that is characterized by its
holding the victim’s data for ransom. In many instances, after infection, the malware will encrypt the victim’s files
and then demand a ransom payment in exchange for restoring access to the data (Fruhlinger, 2020).
In terms of attack vectors, ransomware can infect a system in a number of different ways, common among them is
phishing spam and, according to Kaspersky, this is the most frequent way that Emotet infects computer systems.
Emotet is often spread through spam emails that contain either a malicious URL or an infected document and after
the victim either downloads the infected file or accesses the URL, more malware is then downloaded onto the
system (Kaspersky, n.d.).
Emotet then gathered the infected system’s data (such as host name, all running processes and more) and compressed
it using the Deflate algorithm. The malware then “encrypts the compressed data … with a session key, and packs the
session key (AES), that is encrypted using an RSA public key, along with a hash value and the encrypted data” (Lu,
2019). This encrypted data makes up the HTTP body data of POST requests sent to the C2 servers.
Example of Emotet-Encrypted Data Source: A Deep Dive into the Emotet Malware (Lu,
2019)
Emotet infections have remained especially challenging to detect and prevent in their earliest stages.
Because Emotet spreads and further infects over HTTP, we can analyze the data sent over a network to identify and
track the behavior of the Emotet virus. We managed to obtain a series of .pcap files that contain the network packet
data of a system that has been infected by the Emotet virus, and will be analyzing it using Wireshark to further
understand its behavior (Duncan, 2021). Keep in mind that these network activities contain Windows- based
malware, and you should be incredibly careful if following along on a Windows system.
Through Wireshark we have a very detailed history of network activity involving this infected system, but a good
deal of it is not very valuable to us. What we need to do now is filter out all the activity that we do not need so that
we can find and isolate the data we are interested in more easily. A significant amount of data can be found in each of
these pcap files, and each one only holds a few minutes of traffic on systems that were mostly stationary. Suspicious
traffic can be easily camouflaged amongst regular traffic, so it is important that we can search for and identify
unwanted or dangerous behavior.
Since we know Emotet maneuvers through the web, we can apply a filter that will give us HTTP requests and TLS
handshakes only. From there we may be able to determine where the infection might have come from.
Wireshark Filtering Captured Traffic to Display Only HTTP or TLS Handshake Packets
Now we can see a few web requests have been made that may have been used to retrieve the ransomware (although
one of the URLs redirected to a suspended page) that still leaves 3–4 possible sources. We can edit the previously
used filter to view the responses of these requests.
Wireshark Filtering to Display Only Responses to the Above Requests
Now we can see the responses that the infected system received from the web requests. The one that should stand
out is the last request, seo.udaipurkart.com, as there is no response. We can use Wireshark to follow the TCP stream
in order to discover more about it. By right-clicking the request and clicking follow TCP Stream, or by pressing
Ctrl+Alt+Shift+T we can see the full exchange. Extracting the DLL
Now that we know where the malware came from, we should further determine what it is doing. Since this
version of Emotet uses HTTP POST requests to command and control the system, we can filter traffic with
the following filter to show us all these requests.
Alternatively, you can use the following command to view the post requests coming from the non URL encoded
transfers.
Failed connection requests may also show in the .pcap file. In some cases, an infected host may try to connect
with a server that has been taken off-line or is refusing a TCP connection. If that is the case, you can still
analyze the requests being made to discover the destination. We used the following filter to find failed
connection attempts.
As Emotet also works as a spambot, we can take a look at the system’s mailing traffic to learn even more. Use this filter
to get a look at traffic using simple mail transfer protocol.
Filtering Wireshark Capture to Examine SMTP Traffic
Most (if not all) of the data will be encrypted. If you are lucky enough, you might be able to find some unencrypted
data. The following filter will give you results of unencrypted SMTP transfers that you can analyze.
Other filters can be used to analyze traffic that is commonly used by Emotet infections. For example, variations of
Emotet that use Trickbot can be identified by searching traffic over Trickbots commonly used ports: 447 and
449. Additionally, Trickbot is also known to take binaries through .png image files. Either of these filters will be
able to identify Trickbot behaviour in an Emotet infected system.
Examining the Initial HTTP GET Request for the Emotet DLL
The IP of the web server hosting the DLL is 103.92.235.25 which resolves to server27.hostingraja.org, an
Indian hosting service. The hostname of the site that the DLL is served on is seo.udaipurkart.com which looks
like a compromised online shopping platform.
The machine which receives the DLL and becomes infected with Emotet has the IP 10.1.6.206 and it communicates
with two C2 servers. One of the C2 servers is 5.2.136.90 and the other is 167.71.4.0. The infected machine
communicates with the C2 servers through POST requests with the commands sent through encrypted files.
Wireshark-Captured HTTP POST Communications with the
C2 Server
We saw how after the initial execution of the Emotet binary, HTTP GET and POST requests are
made to and from a remote C2 server that contain both critical data about the infected host
machine as well as various malicious payloads to further infect it. Using the example of infection
above, we saw that some methods of detection could easily flag an Emotet infection but would
also likely trigger false-positive Emotet identifications by legitimate HTTP traffic as well. To
avoid this, the most promising method of early prevention of the Emotet infection in the first
place, would be to block unsigned DLLs from being downloaded or run.