Scenario
Khalid has just logged onto a host that he and his team use as a testing host for many different purposes, it’s off their corporate network but has access to lots of resources in network. The host is used as a dumping ground for a lot of people at the company but it’s very useful, so no one has raised any issues. Little does Khalid know; the machine has been compromised and company information that should not have been on there has now been stolen – it’s up to you to figure out what has happened and what data has been taken.
Artefact
litter.zip (suspicious_traffic.pcap)
Tasks
First things first, I unzipped litter.zip and opened suspicious_traffic.pcap using wireshark.
Task 1: At a glance, what protocol seemed to be suspicious in this attack?
Upon looking at the first few entries in the pcap file it seemed like DNS protocol surfaced numerous times. To confirm, I opened wireshark's Protocol Hierarchy and sort by the number of packets in descending order.
True enough, apart from QUIC or TCP, the number of entries for DNS is a little suspicious as of now.
Answer: DNS
Task 2: There seems to be alot of traffic between our host and another, what is the IP address of the suspicious host?
Knowing that DNS is what I should focus on, I opened wireshark's Conversations to find out which IP address had the most activity in port 53 (DNS).
In the image above, it is clear that the suspicious IP address belongs to 192.168.157.145.
Answer: 192.168.157.145
Task 3: What is the first command the attacker sends the client?
From here on out, I assumed that I would be looking into the content of the conversations. I did the following:
- Narrowed down the pcap results using the following filter:
dns && ip.addr == 192.168.157.145. - Selected the entry with the highest length, and followed the UDP stream.
- Copied the whole body of text in the UDP Stream window and pasted it into
CyberChefto decodeFrom Hex.
The results shown in the image are command outputs from the victim host to the attacker.
Answer: whoami
Task 4 What is the version of the DNS tunneling tool the attacker is using?
Now that I have the conversation decoded, I followed the text to find the answer. In addition, I looked up the internet on popular DNS tunneling tools and hope I discover it in the malicious traffic. And after looking through, a familiar name and its version surfaced.
dnscat2 is a popular dns tunneling tool and the version found in the traffic is 0.07.
Answer: 0.07
Task 5: The attackers renamed the tool, what was the new name?
I am looking for a command that renames, and voila. There were a few attempts to rename but the rename failed, only one succeeded.
ren is short for Rename, and is a command-line tool to rename files or directories.
Answer: win_installer.exe
Task 6: The attackers enumerated the cloud storage, how many files were in the cloud?
One cloud storage location I saw was OneDrive, and there were no files in it.
Answer: 0
Task 7: What is the full location of the Personal Identifiable Information (PII) file that was stolen?
Following the traffic, there were entries of PIIs and before the first entry, the full directory path could be found.
type is a command-line utility in Windows to read contents, similar to cat in Linux.
Answer: C:\users\test\documents\client data optimisation\user details.csv
Task 8: How many customer PII records were stolen?
The headers of the csv file indicated that the first column of each entry is a serial number. The first entry started with 0 and the last entry was 720, that makes 721 records in total.
Answer: 721
Pretty interesting pcap file to allow me to learn more about DNS Tunneling. It is my first time looking at how DNS tunneling looks like over the traffic. The pre-requisites to make DNS tunneling is difficult and because each packet is limited by 253 bytes, there will be alot more packets and thus causing an abnormal spike in DNS traffic. However, an attacker could use this as a form of persistence to stay or get back into the system.
Some recommended ways to detect and prevent DNS tunneling are to apply a Zero Trust Network Access policy to make all connected devices constantly authenticate themselves, and implement network detection solutions to detect anomalies in DNS (e.g. spike in DNS traffic, domain lifetime, etc)
