(Writeup) LetsDefend Challenge - Investigate Web Attack

Welcome

#

• LetsDefend is a Blue Team Training platform.
• This writeup documents an Easy-level challenge focused on analyzing Apache logs using bash tools such as awk, grep, sort, and uniq.

Challenge Overview

#

Role Targeted: Security_Analyst
Skill Level: Easy

Scenario

#

We detected some web attacks and need to do deep investigation.

Challenge File: /root/Desktop/ChallengeFile/access.log

Initial Thoughts

#

“The file is access.log, which makes me think of Apache. If we’re going through Apache logs, it’ll take some bash-fu."
“Ah, the size of the file is only 2MB, which is much smaller than expected; but still bigger than what would be easy to analyze in Notepad.”

Questions

#

1. Which automated scan tool did attacker use for web reconnaissance?
   • If they used a tool, the implication is that it’s probably in the user-agent. Let’s figure out which column we need to grab for that. After cding to the directory we run head access.log to get a sample from the top of the file.
   • We can see from the output that if we’re looking for the user-agent then " would be a good delimiter. After a little with the output of the head command we get the following command to get all the unique user-agents from the log: awk -F\" '{print $6}' access.log | sort | uniq -c
   • Woah, while we got the answer of Nikto… That’s a lot of output, because it puts the test in the user agent. We can pipe the output into another awk to filter it down for easier viewing: awk -F\" '{print $6}' access.log | awk '{print $1 $2}' | sort | uniq -c
2. After web reconnaissance activity, which technique did attacker use for directory listing discovery?
   • Directory listing… Sounds like Forced Browsing… unless the Apache server has directory indexing enabled. (Mentioning forced browsing, I quite like feroxbuster myself.) But we need to look at he path in the logs: awk -F\" '{print $2}' access.log | sort | uniq -c
   • Yep, so many attempted files and directories that it can’t even fit in the terminal history. That’s definitely forced browsing… But that isn’t the answer? It looks like they are using slightly different terminology: directory brute force
3. What is the third attack type after directory listing discovery?
   • If we list the paths without sorting, we can get an idea of where the forced browsing ends (we’ll still use uniq -c to minimize repeats at least): awk -F\" '{print $2}' access.log | uniq -c
   • We can see 134 POST requests in a row at /bWAPP/login.php, indicating they were brute-forcing the login page.
4. Is the third attack successful?
   • Knowing the path and method they are using, we can grep to grab those logs: grep 'POST /bWAPP/login.php HTTP/1.1' access.log and we can instantly see that many of the requests were responding with HTTP code 200, with a size of 4086 every time. Until the end, when the server responds with an HTTP 302 code indicating a redirect. That usually happens on a successful login. So, yes.
5. What is the name of fourth attack?
   • We saw something earlier at the bottom of the log when we used the command: awk -F\" '{print $2}' access.log | uniq -c
   • We notice at the very bottom: GET /bWAPP/phpi.php?message=%22%22;%20system(%27whoami%27) HTTP/1.1 so we know that code injection is the answer. (Personally, I’d go by OWASP and call it “Command Injection” but that isn’t what the answer is looking for.)
6. What is the first payload for 4th attack?
   • Seeing as the attack was at the very bottom, we can check if we can see them with tail and we can indeed: tail access.log
   • We can see after sending a test, they send: GET /bWAPP/phpi.php?message=%22%22;%20system(%27whoami%27) HTTP/1.1 which is php code injected to run the shell command: whoami
7. Is there any persistency clue for the victim machine in the log file ? If yes, what is the related payload?
   • In the very last log we see: GET /bWAPP/phpi.php?message=%22%22;%20system(%27net%20user%20hacker%20Asd123!!%20/add%27) HTTP/1.1 which has php code to run the shell command: net user hacker Asd123!! /add: the attacker added a user to the machine.

Summary

#

Key Takeaways

#

“It’s not always possible to handle elegant logs ingested and enriched by a SIEM. Sometimes we need to dig into the logs from the endpoint straight. It’s good to practice those skills. Bash-fu is useful.”