In the 3rd and final installment of our blog series, we attempt to complete a Capture The Flag (CTF) challenge posted by The Honeynet Project using Gigasheet. While the challenge is quite dated (2015), the analysis techniques we showcase in the series are still relevant today.
The challenge is called "Weird Python" and is available for public download via The Honeynet Project's website. It presents a series of twelve questions one must answer by analyzing a packet capture file.
Part 1 of this blog provides the analysis methodology to find the answers to the following questions (questions 1 and 2 of the challenge):
In Part 2 of the blog series, we continue analyzing the same data set but focus on answering the following questions (questions 3 and 4 of the challenge):
In this final blog, we will attempt to answer questions 5 of the challenge:
Below is the challenge excerpt, copied from honeynet.org.
"Your Boss John went to a BYOD conference lately. Yeah, he's that kind of security guy… After some mumble about targeted attacks happening during the event, your team finally got their hands on a PCAP with his traffic. Your colleague Pete Galloway investigated the incident. Yesterday, he casually mentioned that he found some weird Python bytecode, but couldn't make much sense out of "random" payloads yet. Today, Pete didn't come to work. Five minutes ago, he sent a company-wide mail with a total of four words: "F*** you, I quit. ". What has happened!?"
Upload the PCAP file name "conference.pcap" downloaded from the Honeynet Project's website to Gigasheet, and let's get started.
Question 5: Do you think this is a targeted or an automated attack? Why?
We will work under the assumption of a targeted attack to answer this question, mainly because the Boss' computer became infected at a BYOD conference. If this were a targeted attack, the most likely scenario would be for the attacker to deploy a rogue wireless access point at the conference venue, advertising a wireless network with a name that matches or resembles a legitimate one. Another possible attack scenario could be that the attacker and the Boss connected to the same wireless network, and the attacker was able to carry out an ARP poisoning attack against the Boss' computer to route his traffic through the attacker's system.
Unfortunately, the PCAP file does not have enough data to help us validate and confirm the first attack scenario, so we will assume that the attacker carried out an ARP poisoning attack and verify it by analyzing the PCAP file in Gigasheet.
ARP or Address Resolution Protocol is a network protocol that maps IP addresses to MAC addresses and is used when devices want to communicate with other devices on the same local network. When device A wants to communicate with device B, device A sends an ARP request to its broadcast address to ask for the MAC address of device B. The ARP request will include the IP address of device B. All devices on the same local network will receive the ARP request, but only device B will reply to it with its MAC address.
The format of an ARP request is as follows:
"Who has <REQUESTED_IP_ADDRESS>? Tell <REQUESTING_IP_ADDRESS>"
REQUESTING_IP_ADDRESS is the IP address of the computer sending the ARP request, and REQUESTED_IP_ADDRESS is the IP address of the computer answering the ARP request.
The format of an ARP reply is as follows:
"<REQUESTED_IP_ADDRESS> is at <REQUESTED_MAC_ADDRESS>"
REQUESTED_IP_ADDRESS and REQUESTED_MAC_ADDRESS are the IP and MAC addresses of the computer answering the ARP request, respectively.
Let's find ARP requests and replies in Gigasheet by filtering the INFO column using Regex Match for the following values:
- Who has \w+.\w+.\w+.\w+?
- is at \w+:\w+:\w+:\w+:\w+:\w+
The first filter will find ARP requests, and the second one ARP replies.
On line #1275, we observe an ARP request from 172.16.254.128, the IP address assigned to the Boss' computer, for 172.16.254.2, presumably the Boss' computer's default gateway. On line #1276, we see the ARP reply for 172.16.254.2 with a MAC address of 00:50:56:f3:f2:f6.
We can perform an Organizational Unique Identifier (OUI) lookup to identify the manufacturer of 00:50:56:f3:f2:f6, and help determine if the device replying to the ARP request is an actual wireless router or network device. Spoofing MAC addresses is trivial, so this method may not be the most accurate. Unfortunately, we do not have any other information to verify the authenticity and legitimacy of the ARP reply.
Querying the MAC address in Wireshark's OUI lookup tool reveals that the manufacturer is VMWare, indicating that the responding device may be a virtual machine.
We can reset the filters and continue tracing the PCAP starting on line #1276 to analyze the Boss' computer's actions following the ARP reply. If our assumption is correct, the attacker's machine now acts as a man-in-the-middle, looking at and manipulating the boss' computer's traffic.
We can see on the screenshot above that the malware was downloaded on line #5675 following the suspected ARP poisoning attack on line #1276. However, we cannot tell from the analysis whether the attacker influenced the infection or tricked the Boss into downloading the malware on his computer.