ANALYSING A WIRESHARK CAPTURE FOR ATTACKS

(University Coursework from 2019)

Introduction

The aim of this report is to analyse a Wireshark output file, evidencing conclusions regarding network boundaries, normal traffic and suspicious traffic. Malicious attacks will be discussed.

Method

The capture is recorded in Wireshark which is a widely-used network protocol analyser (Wireshark.org, n.d.). The process followed is summarised in fig.1.

FIG. 1 — Process for analysing the Wireshark capture.

Endpoints to find all IP addresses of hosts within this capture.

IO Graph to visualise network traffic flow within this capture.

Protocol Hierarchy to summarise the protocols used within this capture.

Conversations to summarise which hosts communicate the most, and with which others.

Filtering by Protocol in the main display window, allowing each protocol to be viewed separately, to check for protocol-specific attacks, based on prior research.

Follow TCP Stream for packets of interest. This allowed content of HTTP and TCP requests to be viewed to identify certain attack vectors. It also filtered the main window to the entire sequence of events irrespective of protocols.

Review and revisit traffic with a focus on the suspicious IP address. This involved further research of traffic which looked unusual, but for which the author could not initially identify a specific attack vector.

Network Boundaries

An internal IP address always falls within the following ranges 10.0.0.1–10.255.255.254, 172.16.1.1–172.31.255.254, 192.168.0.1–192.168.255.254, as these are reserved for hosts which are not directly connected to the internet (Lowe, 2016). All other IP addresses will be external, so the internal IP addresses relate to those devices which are on the network captured.

FIG. 2 — List of both internal and external IP addresses found within this capture.

Fig.2 lists all hosts’ IP addresses found within this packet capture file, along with the type.

FIG. 3 — Graph of inbound packets.

Fig.3 shows the inbound packets directed to all five internal IP addresses from external IP addresses only. Although Wireshark can produce a PDF of the graph, this was found to exclude the colour key.

FIG. 4 — Graph of outbound packets.

Fig.4 shows the outbound packets directed from all five internal IP addresses, to external IP addresses.

FIG. 5 — Zoomed in graph of outbound traffic.

Fig.5 is a zoomed in version of fig,4 showing outward traffic sent by all five internal IP addresses. It is now possible to see internal IP addresses which have sent fewer packets. IP address 192.168.1.200 has sent and received the most traffic crossing the network boundary during this capture period.

Normal Traffic

Fig.6 shows the protocol hierarchy, in terms of usage, in descending order. The protocols used in this capture are ARP, Browser, DHCP, DNS, HTTP, ICMPv6, LLC, NBNS, SSH, SSHv2, TCP, UDP, VNC.

FIG. 6 — Protocol Hierarchy.

Fig.7 shows all the network traffic collectively throughout this capture period. It peaks significantly between 4000 and 5000 seconds.

FIG. 7 — Graph of network traffic.

Malicious Activities

Of the packets utilising TCP protocol, external IP address 146.90.197.173 sends many packets to internal IP address 192.168.1.200, from various ports, to various ports in quick succession (fig.8). This is a TCP-based port scan which also closes the connection once it is achieved. This is to avoid a denial of service situation (Santos et al, 2017).

FIG. 8 — Port Scan.

In Fig.9, an external IP address is making requests to the server IP address, to view websites. Line 1035 and 1037 show the server respond successfully to the requests with ‘HTTP/1.1 200 OK’. Line 1039 and every two lines after that show the server returning an error 404 message because the website has not been found.

FIG. 9 — Slow loris attack.

Fig,10 shows the TCP stream for line 1038. The red text shows the packets sent by the client. It contains a command ‘keep-Alive’, which will keep the connection going, causing the server to wait for a further request. If there are multiple packets sent in quick succession, using this command, eventually all sockets of the server will be occupied, rendering it unavailable for requests from legitimate users. This is a ‘slow loris’ attack and is a way of causing a denial of service (Computerphile, 2016).

FIG. 10 — TCP stream for a Slow loris attack.

Fig,11 shows a HTTP GET request including the string ‘/piranha/secure/passwd.php3’. Redhat Piranha is a GUI tool for administering Linux Virtual Servers. Version 0.4.12 has a vulnerability allowing remote access of a pre-configured administration account (SecuriTeam, 2000).

FIG. 11 — attempt to search for and access Redhat Piranha.

Fig.12 and Fig.13 show an X-HTTP-Method-Override request and the response from the server. Specific HTTP headers containing override commands, can be used to overcome server protections against dangerous HTTP verbs. Ordinarily these override functions are used where certain verbs are requested but the API or proxy still needs to use them, however they can be exploited by hackers (Vulncat Fortify, n.d.).

FIG. 12 — X-HTTP-Method-Override request.

FIG. 13 — X-HTTP-Method-Override request rejection.

Fig.13 shows an error 405 message, saying that this method is not allowed. Within the communication from the server, we see the commands that would be allowed. The command ‘GET’ appears to be permissible, but this is in capitals, unlike the request from the client. Supposing override functions are configured for use, the GET request verb must be capitalised (W3.org, n.d).

Fig.14 shows a key exchange successfully taking place between the host and the suspicious IP address 146.90.197.173 between lines 710 and 725. Whilst this behaviour may seem expected, it is of concern here because we have already established this external IP address to be sending malicious traffic.

FIG. 14 — Key exchange and encrypted communication.

In the lines further down the image, encrypted communication takes place between both IP addresses. The type of key exchange used in the image above is the Diffie-Hellman method (Computerphile, 2017). The SSHv2 protocol is commonly used for securely remotely accessing and administrating a network but can be used by an attacker to send data from a breached network back to an external SSH server (Santos, 2017).

Conclusion

This report has discussed network traffic which crosses network boundaries and provided an overview of network traffic to identify a spike. Specific attacks have been identified and these have originated from IP address 146.90.197.173, now regarded as suspicious.

References

AT & T. (1999) Virtual Network Computing. [Online] available from: https://www.hep.phy.cam.ac.uk/vnc_docs/howitworks.html [Accessed: 1st December 2019].

Computerphile. (2016) Slow Loris Attack. YouTube. [Online] available from: https://youtu.be/XiFkyR35v2Y [Accessed: 16th November 2019].

Computerphile. (2017) Secret Key Exchange. YouTube. (Diffie-Hellman) — Computerphile. [Online] available from: https://www.youtube.com/watch?v=NmM9HA2MQGI [Accessed 1st December 2019].

Kurose, J.F, & Ross, K.W. (2017) Computer networking: a top-down approach, 7th Ed. Boston, Pearson Education Limited.

Lowe, D. (2016) Networking All-in-One for Dummies, 6th Ed. New Jersey, John Wiley and Sons Inc.

Petters, J. (n.d.) 5 Basic Port Scanning Techniques. [Online] available from: https://www.varonis.com/blog/port-scanning-techniques/ [Accessed: 24th November 2019].

Red Button DDoS Experts. (n.d.) DDoS Glossary: Ack Flood. [Online] available from: https://www.red-button.net/ddos-glossary/ack-flood/ [Accessed: 23th November 2019].

Rizwan, B. (2018) WordPress xmlrpc.php -common vulnerabilities & how to exploit them. Medium.com. [Online] available from: https://medium.com/@the.bilal.rizwan/wordpress-xmlrpc-php-common-vulnerabilites-how-to-exploit-them-d8d3c8600b32 [Accessed: 1st December 2019].

Santos, O. et al. (2017) CCNA Cyber Ops SECOPS 210–255 official cert guide, Indianapolis, IN: Cisco Press.

SecuriTeam. (2000) Piranha default password exploit code. [Online] https://securiteam.com/exploits/5eq0h000je/ [Accessed: 1st December 2019].

Severance, C. R. et al, (2015) Introduction to Networking: How the Internet Works, USA, CreateSpace Independent Publishing Platform.

Vulncat Fortify. (n.d.) Fortify Taxonomy Software Security Errors, Often Misused: HTTP Method Override. [Online] available from: https://vulncat.fortify.com/en/detail?id=desc.dynamic.xtended_preview.often_misused_http_method_override [Accessed: 1st December 2019].

W3.org. (n.d.) Part of Hypertext Transfer Protocol — HTTP/1.1, RFC 2616 Fielding, et al. [Online] available from: https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html [Accessed: 1st December 2019].

Wiresharg.org. (n.d.) About Wireshark. [Online] available from: https://www.wireshark.org/ [Accessed: 23rd November 2019].

APPENDICES

APPENDIX A

The image below shows multiple RST packets sent in quick succession from 192.168.1.200 to 146.90.197.173. These are sent from various ports, to various ports, based on whichever one sent the initiating packet. RST packets are sent to refuse a connection because the port is closed. As such, they are replies to port scans (Petters, n.d.).

APPENDIX B

In the images below, Line 476 shows the IP address 192.168.1.200 send an ACK packet to 146.90.197.173. From this point on, ACK packets are exchanged in quick succession between the two IP addresses.

After line 593 in the middle image, we see that 192.168.1.200 stops returning the ACK packets, although it continues to receive them from 146.90.197.173. This is an ACK packet flood and is a malicious way of causing a denial of service. These packets are not linked to any active connection, so extra resources will be used to process them and will become depleted (Red button DDoS Experts, n.d.). ACK packets are part of the TCP handshake and are used to acknowledge receipt of a packet (Santos et al 2017). After line 593, it appears that 192.168.1.200 is unable to send packets back.

APPENDIX C

In the two images below, we can see that at line 5163, the client sends an application/xml POST to the server.

In the second image above, line 5222 shows that the application/XML POST request causes the server to return an error 404, with the comment that ‘xmlrpc.php’ was not found on the server. The xmlrpc.php file is an API for use with WordPress and is vulnerable to brute force attacks (Rizwan, 2018).

APPENDIX D

The image below shows six lines of communication over the VNC protocol. The server is sending packets to the suspect IP address. VNC is a protocol used to allow remote access to graphical user interfaces (AT & T, 1999). Therefore, this is of concern.