August 7, 2024
In this challenge, we’ll be analyzing a pcap to identify various attacks against a webserver.
During a cybersecurity investigation, analysts have noticed unusual traffic patterns that may indicate a problem. We need your help finding out what’s happening, so give us all the details.
What is the IP address of the web server?
We’ll start by filtering for packets with a destination port of 80 or 443.
As we can see, 10.1.0.4 is calling out to 168.63.129.16 repeatedly with GET requests to /machine?comp=goalstate.
Checking the HTTP fields of these calls shows the user-agent is WALinuxAgent/2.9.1.1
Researching the user-agent and the endpoint targeted by the GET request, this appears to be common behavior of an Azure VM.
We’ll filter out requests from 10.1.0.4 to see what the remaining packets tell us.
In the results, we see login requests from 197.32.212.121 to 10.1.0.4.
Examining these requests we see the login page was targeted by a brute force attack against the admin user.
POST requests targeting the login pageAnswer 10.1.0.4
What is the IP address of the attacker?
We discovered the source of a brute force attack against the web server in the previous question.
The attacker first tried to sign up on the website, however, he found a vulnerability that he could read the source code with. What is the name of the vulnerability?
Among the POST requests targeting the login page, we also noticed a few POST requests to the register page.
Analyzing the HTTP stream of these requests reveals an XXE attack targeting the endpoint.
We can also see the server’s response is Sorry, [base64 encoded content] is already registered!
Note: you can read more about xxe attacks here - https://portswigger.net/web-security/xxe
There was a note in the source code, what is it?
We can analyze the base64 encoded response in CyberChef.
decoded response from register.phpIn the source code, we find a comment that explains that the Admin password has been strengthened.
We also see a note telling us the flag. Answer yougotme
After exploiting the previous vulnerability, the attacker got a hint about a possible username. What is the username that the attacker found?
We already discovered the targeted username in Q1 and confirmed this by decoding the content in the previous question.
The attacker tried to brute-force the password of the possible username that he found. What is the password of that user?
We could try to check the last POST request and see if that was the successful one or we could filter response code 302 which represents a redirect. Redirects are common upon successful logins.
We see there were only 4 redirects. To make things easier we can add a column for the Request URI.
Note: you can add the column by right-clicking it in the packet details and applying it as a new column. It is the final field of the HTTP header.
We can see that there were 2 redirects from the login page and another redirect to a URL. We should take note of this for further investigation later.
If we follow the http stream of either login redirects we can see the admin password. Not so secure after all.
Note: you should remove the Request URI column after this question by right-clicking the column and selecting Remove this column.
Once the attacker gained admin access, they exploited another vulnerability that led the attacker to read internal files that were located on the server. What payload did the attacker use?
We’ll adjust our filter to see HTTP requests from the attacker. After the POST requests, we see a GET request that is attempting to exploit directory traversal.
The answer request is URL encoded so we’ll need to decode it with something like CyberChef before we submit it.
The attacker was able to view all the users on the server. What is the last user that was created on the server?
In the previous, question we discovered that the attacker accessed the /etc/passwd file. This file contains user information on Linux machines.
We can follow the HTTP stream of this GET request to view the server response, which will contain the contents of the file.
Based on the User ID numbers we can see the highest User ID is 1001, which would be the last created user.
The attacker also found an open redirect vulnerability. What is the URL the attacker tested the exploit with?
We discovered this redirect attack when we filtered for redirect codes earlier in Q6.
Refang the URL for submission.
hxxps[://]evil[.]com/
Previous post
Next post