By investigating and answering the questions below, we can create a timeline of events to lead the incident response activity. This will also allow us to present concise and confident findings that answer questions such as:
What vulnerabilities did the attacker exploit on the web server?
What user accounts were compromised?
What data was exfiltrated from the server?
After Everything is booted up, Navigate to http://target IP
Enter Elastic Credentials :
Username : elastic
Password : raCK0W**BLlW66oNlKAk
After logging in to elastic with the given credentials. Head to Discover. Set the date to July 26, 2023 as it was when the suspicious activity started (Mentioned in the task) and add below mentioned Fields.
response.status
http.url
request.headers.User-Agent
transactions.remote_address
Answer the questions below
What was the attacker's IP?
10.0.2.15
When we click on transaction.remote_address, we can see a very high amount of traffic from a certain IP. This is very unusual
We can add it to the filter.
We can see this is an unusually high traffic from one IP in a single day as shown in the 2nd picture.
What was the first scanner that the attacker ran against the web server?
Nmap Scripting Engine
To find the first scanner used, we can sort by old-new after clicking on the timestamp. We can find the answer as shown in the images.
What was the User Agent of the directory enumeration tool that the attacker used on the web server?
Mozilla/5.0 (Gobuster)
As its a directory enumeration, there will be a lot of 404 codes in the responses.
We can filter this out.
(Hover over any 404 response and click + to add to filters.)
Now if we look at the request headers and http.url we can find dir enum requests and can confirm that is dir enumeration.
In total, how many requested resources on the web server did the attacker fail to find?
1867
Number of failed to find requests equals number of 404 responses.
We already filtered 404 previously so we can see number of requests in the same page itself.
What is the flag under the interesting directory the attacker found?
a76637b62ea99acda12f5859313f539a
A flag is present in one of the directories founded by the attacker.
Since the directory is found, the response status should be 200.
Edit the response.status filter from 404 to 200
Add Mozilla/5.0 (Gobuster) to filter by clicking the + sign we get when hovering above it.
Now we can find the flag in the http.url field along with the interesting directory.
What login page did the attacker discover using the directory enumeration tool?
/admin-login.php
The login page was discovered using dir enum tool, hence we don’t have to change User-Agent filter.
However we have not found any login page while filtering using 200, We can include its exception. And similarly the 404.
After adding these to the filters we can find the login page in the http.url field.
What was the user agent of the brute-force tool that the attacker used on the admin panel?
Mozilla/4.0 (Hydra)
We can clear the User-Agent and Resp.status filters.
Since it is a brute-force login, there will be a lot of 401(Unauthorized) Response code.
We can add it to the filter.
We can find the tool used in the User-Agent field.
What username:password combination did the attacker use to gain access to the admin page?
admin:thx1138
We know the User-Agent of brute-force tool used, we can add it to the filters.
Since the attacker gained access, we know the response won’t be 401,
So add that to the filters as well.
We got one hit with 200 status code. We can expand that for more details.
We got YWRtaW46dGh4MTEzOA==
Which is Base64 encoded. We can decode it for the answer.
What flag was included in the file that the attacker uploaded from the admin directory?
THM{ecb012e53a58818cbd17a924769ec447}
The attacker uploaded a file from the admin directory. We can first check the admin directory.
We can go to search bar to filter then type http.url : /admin/*
Which means http.url is equal to /admin/* and because of our wildcard(*) it will consider what comes after /admin as well.
We find upload.php and action from admin directory, We can expand it for more details.
By expanding the request body, we’ll get the flag.
What was the first command the attacker ran on the web shell?
whoami
While doing last question we noticed the name of uploaded file.
ie easy-simple-php-webshell.php
Now we can use that filename in search bar within single quotes( ‘ ) to filter all requests with that keyword.
We also add 200 status code to filters.
We need the first command, so we will sort the timestamp from Old to New.
We can find the answer in the http.url field.
What file location on the web server did the attacker extract database credentials from using Local File Inclusion?
/etc/phpmyadmin/config-db.php
While we filtered /admin/* , we noticed some path traversal requests.
We can add that filter again and we get some repeating file path in http.url and since the attacker extracted database credentials, we can confirm that this is the file.
What directory did the attacker use to access the database manager?
phpmyadmin
This can easily be found during the previous question.
What was the name of the database that the attacker exported?
customer_credit_cards
Since we know attacker used phpmyadmin directory access database, we can add that to filter with a wildcard(*).
There was a lot of requests.
But few of them can get more attention.
[export.php , import.php , tbl_replace.php]
Since the attacker exported the database, let’s check export.php.
What flag does the attacker insert into the database?
c6aa3215a7d519eeb40a660f3b76e64c
We can check the previously found import.php then tbl_replace.php
By expanding message in import.php, we can see some sql queries, success messages.
It is URL encoded, we can decode it easily.
From this we can understand the attacker added a credit card credentials.
But we can see only carldholder_name field has value and it’s just a random alphanumeric word. It is most likely our flag.
