Day 3:  Log Analysis

Day 3: Log Analysis

Introduction

Day 3 focused on investigating attacks, using tools like ELK, Kibana, and understanding vulnerabilities like Remote Code Execution (RCE).

I’m learning a lot every day, and I can’t wait to share my progress with you all. Let’s dive in!

The Blue Team Investigation - Operation Blue

Today’s task took me through the world of log analysis, a crucial skill for anyone working in cybersecurity, especially for blue teamers. The goal was to investigate an attack using logs from a web application, WareVille Rails, which had been targeted by attackers trying to upload a malicious web shell.

Log Analysis with ELK

ELK (Elasticsearch, Logstash, and Kibana) is a powerful set of tools that makes it easier to manage, search, and analyze logs. This stack is essential for investigating security incidents, especially when dealing with large volumes of log data from different sources.

Here’s what I learned today:

  1. Kibana: Kibana provides a user-friendly interface for searching and visualizing logs. It allows you to filter out unnecessary data and zero in on what’s important.

  2. KQL (Kibana Query Language): This is the query language used in Kibana. It allows you to search through logs efficiently. I learned how to search for specific values, such as IP addresses or file names like shell.php, and filter logs accordingly.

  3. Time Filters: Kibana allows you to filter logs by specific time ranges, which is crucial for narrowing down attacks. In today’s scenario, we were analyzing logs from October 1, 2024, when the attack took place.

Investigating the Attack

The SOC team had alerted us to a suspicious activity involving a web shell upload to the system. Using Kibana, I tracked down the logs from the specified date and identified several entries related to shell.php. This was a key clue, as it indicated that a web shell had been uploaded.

The attacker’s activity was logged, and by using KQL, I was able to narrow down the logs further to focus on the IP address involved in the attack. I then saw multiple logs that indicated a malicious file upload was happening around the same time.

Kibana Query for Logs

Answering the Questions

As part of the task, I was also required to answer a few questions to confirm my understanding and ensure I had correctly investigated the logs. Here’s how I approached them:

What file was uploaded to the server?

By searching through the logs and filtering by file name, I identified that the file uploaded was named shell.php. This was a key indicator that the attacker had successfully uploaded a web shell.

Answer:

The uploaded file was shell.php.

What IP address was responsible for the attack?

After identifying the shell.php file, I used Kibana’s search functionality to trace back to the IP address from which the file was uploaded. The attacker’s IP address was logged multiple times throughout the session, allowing me to confirm the source of the attack.

Answer:

The IP address responsible for the attack was 192.168.1.105.

What vulnerability did the attacker exploit to upload the shell?

The attacker exploited a file upload vulnerability in the web application. The system did not properly validate or restrict the types of files that could be uploaded, allowing the attacker to upload a PHP file disguised as an image.

Red Team Operation - Performing Remote Code Execution (RCE)

After completing the investigation of the attack as a blue team member, I switched to the red team perspective. The objective was to exploit the system and gain unauthorized access.

In this scenario, I was able to perform Remote Code Execution (RCE) by navigating to the admin panel, which was accessible without proper authentication or restriction. Once inside the admin panel, I discovered that the application allowed users to upload files, including images. I was able to upload a backdoor PHP file, named shell.php, to the hotel booking page, which was used for adding rooms.

Steps Taken to Exploit the Vulnerability:

  1. Accessing the Admin Panel: First, I navigated to the admin panel, which was exposed without authentication. This allowed me to access the functionality to upload files.

  2. Uploading the Web Shell: I uploaded the shell.php file to the hotel booking page. The application failed to properly filter or validate the file type, allowing me to upload a PHP shell disguised as an image.

  3. Executing Commands: Once the backdoor was uploaded, I accessed the shell and was able to execute commands on the server. This gave me complete control over the system, allowing me to run arbitrary code and potentially escalate privileges.

Uploading the Backdoor (shell.php)

Executing Commands on the Server via Shell

Key Takeaways from the Red Team Operation:

  1. Unrestricted File Uploads: A key vulnerability in this case was the lack of proper file upload validation. By uploading a PHP shell file, I was able to gain control over the server.

  2. Admin Panel Exposure: The admin panel should have been protected with authentication to prevent unauthorized access. Exposing sensitive parts of the web application can lead to easy exploitation.

  3. RCE Exploitation: Remote Code Execution vulnerabilities can have devastating consequences. Once an attacker gains control of the server, they can run commands at will and further exploit the system.


Thanks for reading!
If you’re also learning cybersecurity, feel free to leave a comment or connect with me on Hashnode. Let’s learn and grow together!