LetsDefend Challenge: Malicious Web Traffic Analysis
Scenario: 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.
Q1. What is the IP address of the web server?
For this we will first filter the wireshark packet capture as “http” this will only show us the packets that used HTTP protocol
Using this we can clearly see source and destination IP, since we are dealing with the Web Server (public server), it will have a public IP in our case 10.1.0.4
Q2. What is the IP address of the attacker?
Now, in the pcap provided there are two private IP addresses interacting with the webserver, but if we notice something in the screenshot above, the web-server IP addresses is using GET and PUT request to another IP, which means this is not the attacker IP we are looking for, it might be an internal server with which the IP is making a contact.
If we scroll down a bit, we will see another IP address which is requesting web pages from the server, since theses are the only 2 IPs contacting our webserver, this is the attacker IP.
NOTE: In real world we will be having tonnes of IP addresses from which we would have to identify the attacker IP address, using behaviour based techniques we can filter out the malicious ones
Q3. 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?
Since the question says “attacker first tried to sign up on the website” we will look for any signup page requested by the attacker.
As we can see we have the register.php page requested, if we check the hex dump/follow HTTP stream (which ever is convenient) we can see the email section contains form data as &xxe.
XML external entity injection (XXE) is a security vulnerability that allows a threat actor to inject unsafe XML entities into a web application that processes XML data. Threat actors that successfully exploit XXE vulnerabilities can interact with systems the application can access, view files on the server, and in some cases, perform remote code execution (RCE).
Reference: https://www.imperva.com/learn/application-security/xxe-xml-external-entity/
Q4. There was a note in the source code, what is it?
The attacker when submitted this request, he received an entire source code as the response, we can view this by viewing the packet HTTP stream
The response received is in base64 we can convert this using any tool of choice like CLI or CyberChef
Q5. After exploiting the previous vulnerability, the attacker got a hint about a possible username. What is the username that the attacker found?
If we drill down we can see attacker used a very common yet powerful username in security world “admin” which are defaults as well in some industries
The attacker tried to brute-force the password of the possible username that he found. What is the password of that user?
This might be challenging to find sometimes since brute force itself is a kind of attack where it attempts every possible password from the word list, hence these many number of logs. But a way to find the answer to this question is by looking at the abnormality in the packets generated after attempting each combination i.e. the response packets
for this I used a filter: HTTP && ip.addr==197.32.212.121 && http.response
this gave me only HTTP response packets for attacker IP
Now, if we check the pattern, we could see for each response the length factor remains same, we just need to find that one abnormal value different from common length observed as 681. In this case I found as 295 which had drastic difference. This is our successful login attempt.
Now, we just have to find the request packet just before this response, and check the hex dump for password used.
Q6. 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?
If we scroll the logs further down, we will see a weird-looking request for dashboard.php something like ../../../ and so on, this is basically a directory traversal vulnerability, where the attacker goes right to the root and hunt for a password file from the Linux systems.
Q7. The attacker was able to view all the users on the server. What is the last user that was created on the server?
The response to this request will be the passed file, if we check the last user of the passed file, that will be the most recent created user
Q8. The attacker also found an open redirect vulnerability. What is the URL the attacker tested the exploit with?
An open redirection vulnerability occurs when a web application allows a user’s input to control the destination of a redirect, which can lead to attackers redirecting users to malicious websites
To find these we need to check any instance of “url” or “http” keywords after the web-page, this is because attacker uses a URL key word and the value of the URL in one of the user input, hence we might see something like this:
Challenge Link:
https://app.letsdefend.io/challenge/malicious-web-traffic-analysis
