Network Forensics Analysis of DNS Traffic and Security Implications

The assignment focuses on analyzing a captured traffic file (.pcap) for DNS-related anomalies and suspicious activities. Utilizing Wireshark, the analysis begins by filtering DNS responses to identify any errors in the capture. No DNS errors were found with a response code of zero indicating normal ...Read More

Running Head: NETWORK FORENSICS 1
NETWORK FORENSICS
Name:
Professor:
Course:
Date:

NETWORK FORENSICS 2
Contents
Introduction...................................................................................................................................2
DNS Errors....................................................................................................................................3
Analysis by packettotal.com..........................................................................................................4
Analyzing the DNS Query Traffic on Wireshark..........................................................................6
Outcome from the Wireshark evaluation...................................................................................9
Analysis by Networktotal.com....................................................................................................10
References...................................................................................................................................11

NETWORK FORENSICS 3
Introduction
To begin the analysis of the DNS traffic in the given captured traffic file, we need to
fire up Wireshark and then examine the .pcap file. We then go ahead to observe the capture
through the Wireshark packet list pane. The traffic on the pane contains different protocols that
were captured at different times. For reasons of determining if there was a suspicious activity,
we will not have to take much time checking on every capture one by one (Chapell, 2013). We
shall utilize the filter to find for any DNS Errors in the captured packets.
DNS Errors
On selecting a response packet in Wireshark, for this instance, the second packet is a
response. To check for errors, we look into the Domain Name System in the packet details
pane. The response code exists inside the flags section in the DNS response. The reply code
field inside the flags section is set to zero (0). This means that there is no error in the response
packet. Anything other than a zero then it’s a problem. Now to check on all the packets to find
for DNS errors, on the filter, we type in “dns.flags.rcode !=0” on applying this, we find that this
trace file has no DNS errors.

NETWORK FORENSICS 4
No error in DNS response

NETWORK FORENSICS 5
No DNS Errors found
Analysis by packettotal.com
Observing the DNS trail of the pcap file in Packettotal.com, the device did not at any
instance utilize the Tunneled Transport Layer Security (TTLS) protocol. This protocol provides
for privacy and data integrity between two communicating devices. There was no connection
security between the 192.168.1.30 and 10.1.1.20. Deep analysis done by Packettotal.com also
indicate that there is a single strange network activity from a sender IP of 192.168.1.30
(Messier, 2017). The name of the strange activity is given as “DNS_RR_unknown_type”.

NETWORK FORENSICS 6
Strange Network Activity
Looking into the sender port this IP used, the port is 33777 which is not a usual port that
personal computers send requests on a network. It is also clear from packet total that the sender
is trying to access data from the network without using any secure protocol. At the transport
layer of the OSI model, traffic on a network needs to be encrypted using the TLS protocol.
From the screenshot shown below, Packettotal.com has found that at no time was the TLS
protocol used. This is a major security flaw that the device has utilized to do malicious
operations in the network.

NETWORK FORENSICS 7
TLS protocol never used
Unknown sender ports used by 192.168.1.30

NETWORK FORENSICS 8
Analyzing the DNS Query Traffic on Wireshark
On IPv4 (Internet Protocol version 4) protocol details. Here we see that the source
address is the IP of 192.168.1.30. It is clear here that the GEO IP of the Source is Unknown.
This is enough reason for us to suspect this source IP is not at any good. A perfect reason for
this is because any time a malicious person or a black hat who has the means to penetrate into a
network, the first thing they do is conceal their location. They always do this to reduce the risks
of them being arrested by the law enforcers. Nearly every other state/country now implements
different cyber-crime acts that aim at safeguarding the integrity of personal and organizational
data. The Destination address is 10.1.1.20 which is the IP address of the DNS server.
Expanding the User Datagram Protocol (UDP) details, the source port is 33777 a dynamic port
that is selected just for this DNS query. The destination port is 53 (Known to be the DNS server
port). Moving on, to observe the Domain Name System (DNS) (query) details, we expand on it.
We will then have to expand on the flags to observe their details. Doing that, we note that a
Recursive query is requested, any non-authenticated data is unacceptable, the message is not
truncated, and the response message is in form of a query. Finally, expanding on the queries,
we find the query for Name: Paaiaq5x.tnl.slick.evl. The additional records at the far bottom
show the UDP payload size to be 4096.

NETWORK FORENSICS 9
DNS query traffic.

NETWORK FORENSICS 10
DNS response traffic.
Fig. 1.1
Outcome from the Wireshark evaluation
From the analysis of the DNS traffic by Wireshark, many appropriate protocols have
been seen to be applied correctly so there is a low suspicion level from this analysis
(Bachupally, 2016). Contrary to this, there is a high level of suspicion after an analysis is done
using www.networktotal.com. The correct internal network pool we are given is
192.168.1.0/24. Therefore, traffic from the IP of 192.168.1.0.30 is from an external source.
This IP, however, can be said to be an incorrect IP that might have been a result of DNS cache

NETWORK FORENSICS 11
spoofing; mostly known as cache poisoning. This is where an internet server domain name
system is corrupted and correct IP addresses are replaced with rogue IP addresses. The DNS
resolver’s cache will then return incorrect IP addresses.
Analysis by Networktotal.com
An analysis of the provided .pcap file by using a web service on www.networktotal.com
shows that on Sunday, 28 Nov 2010 at 07:40:01 hours, excessive DNS Responses with 1 or
more RR's (100+ in 10 seconds) occurred. This is a clear recipe for possible Cache Poisoning
Attempt. The figure below shows a screenshot of the analysis results by Networktotal.com.
Fig.1.2
In conclusion, the host claiming the IP of 192.168.1.30 has been found to be the
executer of DNS spoofing and It’s MAC address is 00:0c:29:38:63:95. This host has further
rent requests to the destination of 10.1.1.20 without using the TTLS protocol to ensure the
integrity of the critical infrastructure’s data.
Every IP address on this critical infrastructure facility can be an entry point for
cybercriminals. In order to distinguish between good and bad traffic despite all the
vulnerabilities that might be available on the network, new digital solutions must be

NETWORK FORENSICS 12
implemented by the critical infrastructure facility. These solutions include: Maintaining a
strong firewall, conducting regular scans on the network, segmenting the network and limiting
remote access.
References
Bachupally, Y. R., Yuan, X., & Roy, K. (2016, March). Network security analysis using
Big Data technology. In SoutheastCon, 2016 (pp. 1-4). IEEE.
Chappell, L., & Combs, G. (2013). Wireshark (R) 101: Essential Skills for Network
Analysis. PODBOOKS. COM, LLC.
Messier, R. (2017). Network Forensics. John Wiley & Sons.