GreenOptic: 1 || VulnHub Walkthrough

Hello, everyone! Welcome back to our VulnHub Walkthrough series.

In today’s video, we’ll be exploring another challenging machine from the VulnHub collection: GreenOptic:1.

This machine is rated Very Hard, so we can expect multiple stages of enumeration, exploitation, and privilege escalation.

According to the machine description:

“British Internet Service Provider GreenOptic has been subject to a large-scale cyber attack. Over 5 million of their customer records have been stolen, along with credit card information and bank details.

GreenOptic has created an incident response team to analyse the attack and close any security holes. Can you break into their server before they fix their security holes?”

So, in this walkthrough, we’ll investigate the machine from the beginning, identify the available attack surface, discover the vulnerabilities, and work our way toward gaining full access. Before we begin the actual exploitation, let’s first set up the vulnerable machine in our virtual environment.

Let’s get started!

Settings Up

Downloading the Machine

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

If you're new to VulnHub, I recommend checking out our previous videos in this playlist, where we cover how to work with vulnerable machines.

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

Importing the OVA file into VirtualBox

For this walkthrough, we have already downloaded the machine as an OVA file.

An OVA (Open Virtual Appliance) file is a packaged virtual machine that can be imported directly into virtualization software such as VirtualBox.

Now let's launch VirtualBox. Once VirtualBox is open, go to the Home screen.

• From the navigation menu, click: Import

This will open the Import Virtual Appliance window, and Here, you need to configure the source of the virtual appliance.

• Since we have already downloaded the OVA file and saved it locally on our computer, the Source should be set to: Local File
• Click the file-selection button and navigate to the location where you downloaded the GreenOptic OVA file and select the GreenOptic OVA file.

VirtualBox will now read the appliance configuration and display the available virtual machine settings. We can review these settings and modify them if necessary, such as the allocated memory, CPU, storage, and other hardware configuration.

• For now, we can leave the default settings unless we have a specific reason to change them.
• Once everything looks good, click Finish

On clicking Finish, VirtualBox will begin importing the appliance. Depending on your computer's storage speed and the size of the OVA file, this process may take some time. Once the import is complete, you'll see a new virtual machine in VirtualBox named:

GreenOptic

For better organization, I like to keep my vulnerable machines together. So, move the GreenOptic virtual machine into my VulnHub group. This isn't required for the machine to work, but it makes it easier to manage multiple vulnerable machines in VirtualBox.

Now, we need to configure the network. 

Configure the Network

This is an important step because our attacking machine, Kali Linux, and the vulnerable GreenOptic machine need to be able to communicate with each other.

For this lab, we'll use a Host-Only Adapter.

A host-only network allows the virtual machines to communicate with each other through a private virtual network without exposing the vulnerable machine directly to the external network.

So, select the GreenOptic virtual machine and open Settings. Then go to: Network. Here, we need to configure the network adapter. 

• Enable the network adapter and change the attached network type to: Host-Only Adapter

Make sure that the Kali Linux machine we'll be using for testing is connected to the same Host-Only network. This gives us an isolated environment where Kali can communicate with GreenOptic during the security assessment.

Now that the virtual machine has been imported and the network has been configured, everything should be ready. 

Starting the GreenOptic Machine

Let's start the GreenOptic VM.

• Click: Start

VirtualBox will boot the machine. After the boot process completes, you should eventually see a login prompt.

At this point, don't worry if you don't know the username or password. Remember, this is a vulnerable machine designed for penetration-testing practice. Our objective is not to log in directly through the console.

Instead, we'll investigate the machine from our Kali Linux system and determine how we can gain access. And there we have it. Our GreenOptic:1 vulnerable machine is now running and waiting at the login prompt. Our basic lab environment is ready:

From here, we'll begin with the most important phase of any penetration test.

Enumeration

The first step in our attack is enumeration. Before attempting to exploit anything, we need to gather information about the target machine, starting with its IP address and then identifying the services it exposes.

Identifying The Target

To discover the Target IP Address, We'll use Netdiscover to identify active devices on our Host-Only network. Open a terminal in Kali Linux and run:

Where, 

•  -i,  is used to specify the network interface.

If you're not sure which interface to use, run ifconfig. This will display the available network interfaces and their IP addresses. Here, in my case, it is eth1.

The command output displays a list of devices detected on the network, showing their IP and MAC addresses, as well as the associated vendor. 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.56.104”.

We'll use this IP address for the remainder of our initial enumeration.

Port and Service Enumeration

Now that we know the target's IP address, next, we'll perform a network scan to identify open ports on the target, which is a critical part of the enumeration process. Identifying open ports provides insights into the network’s attack surface, helping us pinpoint services that may be vulnerable to exploitation. For this task, we’ll use the popular network scanning tool, Nmap.

In this command, 

• -A option enables Nmap's aggressive scan functionality. It combines several enumeration techniques, including OS detection (attempts to identify the target's operating system), Version detection (attempts to identify the versions of running services), Default NSE scripts (runs Nmap Scripting Engine scripts for additional information), Traceroute (attempts to determine the network path to the target).

Here, the scan is completed, and the results reveal 5 open ports with their respective services:

• Port 21 (TCP): FTP, or File Transfer Protocol, is used to transfer files between a client and a server. The GreenOptic server is running vsftpd 3.0.2. vsftpd means Very Secure FTP Daemon, a commonly used Linux FTP server. During enumeration, we can investigate whether anonymous access is enabled, whether valid credentials can be used, and what files or directories are accessible.
• Port 22 (TCP): Running SSH (Secure Shell), which provides encrypted remote access to the system. SSH normally requires valid credentials, such as a username and password or an SSH key. Although SSH is designed to provide secure remote access, weak or compromised credentials can still allow unauthorized access.
• Port 53 (TCP): running DNS (Domain Name System), which is used to resolve domain names and hostnames to IP addresses. The GreenOptic machine is running ISC BIND 9.11.4-P2 on a CentOS/RHEL 7 environment. DNS is interesting during enumeration because it may reveal additional hostnames, subdomains, or other information about the target's network configuration.
• Port 80 (TCP): running HTTP (Hypertext Transfer Protocol), which is used for communication between web browsers and web servers. The scan identifies a website titled: GreenOptic running on Apache server version 2.4.6 with PHP version 5.4.16.
• Port 1000 (TCP): Running an HTTP service associated with Webmin. This is different from the normal web application running on port 80. Webmin is a web-based administration interface commonly used to manage Linux/Unix systems. Our scan identifies MiniServ 1.953 on this port. We'll investigate this service further during the enumeration phase to determine whether it provides any useful information or potential attack vectors.

At this point, we have identified several services that could potentially provide an entry point into the target system. 

The next step is to perform deeper enumeration of each service. 

Web Application Enumeration

Our objective is to identify vulnerabilities, misconfigurations, exposed information, or valid credentials that could help us obtain an initial foothold on the target.

For this machine, we'll begin with the HTTP web server on Port 80.

Web applications are often valuable sources of information because they can expose additional directories, files, parameters, and functionality that aren't visible from the initial Nmap scan.

So, let's start by accessing the web service. Open a web browser. Enter the target's IP address:

The page loads successfully, and we can see that this is the GreenOptic Broadband website. 

Initial Website Observations

At first glance, we can identify several useful pieces of information.

The website is clearly branded: GreenOptic Broadband

It appears to be the website of a broadband Internet service provider, offering fibre broadband services. At the top of the page, we can see three main navigation options:

• BROADBAND
• ACCOUNT
• GET HELP

The ACCOUNT section immediately catches our attention because it suggests that the website may contain customer-account functionality, such as a login page or other authenticated features. We can also see a telephone number. There is also a CHECK FOR COVERAGE button on the main page.

At this stage, however, we should not assume that any of these elements represent vulnerabilities. They are simply clues that may help us understand the application and determine where further enumeration should be focused.

The next step is to look beyond what is visible on the homepage. Web applications often contain directories and files that aren't linked from the main page. These may include Login pages, Administrative interfaces, Configuration files, Application directories, Backup files, APIs, and other functionality.

Directory Enumeration with Gobuster

To discover these resources, we'll perform directory and file enumeration using Gobuster.

Gobuster systematically requests common directory and filename paths and analyzes the HTTP responses. This can reveal resources that aren't immediately visible through the website's navigation.

Execute the appropriate commands in the terminal to initiate the enumeration process.

The results of directory enumeration typically highlight potentially sensitive or hidden files and directories on the web server. Each file or directory's HTTP response code and status provide critical insights into access restrictions and potential security risks.

Reviewing the Gobuster Results

Once the scan completes, we'll examine the discovered paths and their HTTP status codes. 

• Among the results, we find several common static-resource directories css, js, img.

These directories are useful for understanding the structure of the website, but they aren't immediately our highest-priority targets.

• More interestingly, Gobuster discovers /account/  (Status: 301).

This is particularly interesting because /account/ suggests that the website has a dedicated account-related section.

Investigating /account/

Let's open the discovered directory:

Here, we find an account login page. I initially tried some random usernames and passwords, but none of them allowed me to log in. Instead of continuing to guess credentials, let's examine the application more closely.

While inspecting the page, we notice an interesting parameter in the URL: “include=cookiewarning”.

Enumerating LFI(Local File Inclusion)

The presence of a parameter named include immediately deserves further investigation. Parameters that control which file or resource an application loads can sometimes be associated with file inclusion vulnerabilities.

At this point, however, we don't yet know whether the parameter is actually vulnerable. An interesting parameter is only a clue; it is not proof of a vulnerability.

So instead of continuing to guess usernames and passwords, let's investigate how the include parameter behaves.

Testing for Local File Inclusion

A common first test for a suspected LFI is to determine whether the application can access a known local file.

One useful file on Linux systems is /etc/passwd.

Let's try supplying it through the include parameter. If the application successfully processes the file, the response should contain information from /etc/passwd, and in our case, it does. After scrolling through the response, we can see the contents of the file.

The /etc/passwd file is a standard Linux system file containing information about local user accounts, including usernames, user IDs, group IDs, home directories, and login shells.

This gives us considerably more information about the target. We can now identify users and determine which accounts have interactive shells such as /bin/bash

This is an important information-gathering step because these users may potentially be valid accounts for other services such as SSH or FTP.

Although /etc/passwd gives us useful information, we still do not have valid credentials to get login access. I was stuck here for a while, so to get to know what to do next, I decided to investigate further and look for a clue.

Looking for More Information

In searching for a clue, I found something interesting. 

Running gobuster using a big wordlist reveals two particularly interesting files.

• .htaccess: The .htaccess file is commonly used by Apache to configure directory-level web-server behavior, such as access control and URL-related configuration.
• .htpasswd: The .htpasswd file is particularly interesting because it is commonly associated with Apache HTTP authentication and can contain usernames together with password hashes.

So now we have another hypothesis:

If .htpasswd exists somewhere under the web server's directory structure, it may contain credentials or password hashes that could be useful elsewhere on the machine. 

So our next step is to find and understand where the file path of .htpasswd is.

Enumerating .htpasswd

Based on the web-server configuration and the information, usually .htpasswd is located within /var/www/, that is the web directory on a Linux platform.

We then use the LFI to attempt to read:

/var/www/.htpasswd

This time, we get something very interesting.

At the bottom of the response, we find a password hash associated with the user, staff. We now have a credential hash that we can attempt to recover.

The value appears to be a password hash rather than plaintext. Since this is a controlled VulnHub environment, we can attempt to recover the original password using a password-cracking tool.

Cracking the Password Hash

For this purpose, we'll use John the Ripper.

First, we have to save this to a file. Open a text editor such as Mousepad and paste the recovered hash.

Now, save the file as: user.hash

In the terminal, before we run the john command, let me extract rockyou.txt.gz, as I recently installed Kali Linux on my virtual box. Run with sudo.

Now, the wordlist is ready. In the terminal, run:

John identifies the hash as md5crypt and begins testing passwords from the wordlist. After a short time, the result is successfully cracked. John has successfully recovered the password. We can therefore record the credentials as:

• Username: staff
• Password: wheeler

Now, let’s use this username and password in the account login page. Upon trying to log in, it shows

“This website is using cookies. By continuing to use this service, you consent to cookies being stored.”

Now, we do not know what to do next or where the credentials can be used.

From Nmap, we already know that the FTP service is working on the target server. But it failed to get a successful authentication. So this is not a username and password to use for login via SSH or FTP. There may be some other way to use it.

Enumerating Port 10000/TCP Webmin

Previously, we discovered from nmap that there is Port 10000/tcp is open, running an HTTP service, the MiniServ 1.953 (Webmin httpd).

This tells us that Webmin is running on the target.

What Is Webmin?

Webmin is a web-based administration interface for Unix and Linux systems. 

Instead of performing all server administration through a command-line terminal, administrators can use Webmin through a web interface.

Depending on the account's privileges, Webmin can provide functionality for managing:

• Users
• Services
• Networking
• System configuration
• Packages
• Files
• Server administration

Because Webmin is an administrative interface, valid administrative credentials could potentially provide considerably more access than credentials for an ordinary web application.

Therefore, it is worth checking whether the credentials we recovered can be used to authenticate to Webmin.

Let's first try accessing the service by adding the port:

Instead of displaying the Webmin login page, the server returns an error message:

This web server is running in SSL mode. Try the URL https://websrv01.greenoptic.vm:10000/ instead.

This gives us another useful piece of information. The Webmin service is configured to use SSL/HTTPS, rather than plain HTTP. The server is also telling us the hostname that should be used:

So, instead of using HTTP, let's access Webmin through HTTPS:

When we open the HTTPS URL, the browser displays a certificate/security warning. This is expected in a lab environment because the Webmin server is using a certificate that our browser does not trust.

• We can select: Advanced...

and then choose:

• Accept the Risk and Continue

After accepting the certificate warning, we reach the Webmin login page.

Now we have another potential place to test the credentials we recovered earlier. Let's try:

• Username: staff
• Password: wheeler

However, Webmin rejects the credentials and displays:

Warning: Login Failed: Try again

So, the credentials we recovered from .htpasswd are not providing Webmin access either.

At this point, rather than continuing to guess where the credentials might work, we need to return to our earlier enumeration and look for additional information about the target. We tested these credentials against the services we had already identified, including FTP and Webmin, but they were rejected.

This means we should not immediately assume that the password is useless. There are several possibilities:

• The credentials may belong to a different service.
• The username may be associated with another application.
• There may be another host or virtual host on the same server.
• The credentials may be intended for a service that we haven't discovered yet.

So instead of continuing to blindly try the same username and password everywhere, let's return to our original enumeration results and ask:

Is there anything in the Nmap scan that could reveal another system, application, or hostname?

And this brings us to DNS on Port 53.

Enumerating Port 53/TCP

From Nmap:

At first, DNS might seem unrelated to our current problem. But remember what DNS does. DNS is responsible for translating Domain names into network addresses.

It has to be remembered that we cannot use the dig command utility tool to reveal all domains. Here is what will happen. But we must have a clue about the domain.

But before, let me have to check if there is any domain name revealed previously. If we remember correctly, you may have noticed that when we visit webmin on port 10000, it revealed

https://websrv01.greenoptic.vm:10000/

This urls.

Upon clicking it redirected to desire page. Unfortunately, here it displays an error.

“Hmm, We’re having trouble finding that site…”

It usually means the browser fails to reach the destination web server. Common causes include local internet service drops, incorrect device date settings, DNS server failures, strict firewall blocks, or the target website being completely offline.

Configuring Kali to Use the Target's DNS Server

To fix it, we have to add the domain name to the hosts file. To do this, in the terminal, run:

Here, we have to add our IP and Domain name.

Once done, save it using CTRL + X and then type y.  Now, as you see, it displays the Webmin login page. 

This is not main point, our work is to Next is, we will use dig command line utility.

Enumerate the DNS with dig (Domain Information Groper)

The dig (Domain Information Groper) command is a command-line tool used to query Domain Name System (DNS) servers. It is the industry standard for troubleshooting network issues and verifying DNS records because it provides detailed, structured output directly from the source.

Dig is used for troubleshooting network outages, Verifying Domain Ownership & Email Setup, and checking DNS Propagation.

From Nmap: 

This tells us that the target is running BIND, a commonly used DNS server.

DNS doesn't only translate domain names into IP addresses. A DNS server can also contain information about other hosts and services within a domain.

Since the target is using:

greenoptic.vm

there may be additional hostnames or subdomains associated with this domain. One useful enumeration technique in a controlled lab is to check whether the DNS server allows a zone transfer.

Attempting a DNS Zone Transfer

A successful zone transfer could reveal DNS records that aren't immediately visible from the website.

But before we run Configuring Kali to Use the Target's DNS Server, if we run the dig command, it doesn't understand how to fetch data.

First, we can configure Kali to use the GreenOptic machine as its DNS server. Open the resolver configuration using the following command:

Add the target's IP address as the nameserver. 

We can then verify the configuration by using the cat command:

Now Kali will use the GreenOptic DNS server when resolving names. 

Next, let's attempt to retrieve the DNS zone for: greenoptic.vm

We can use the dig command:

Where:

• AXFR is the DNS record type used for a full zone transfer.

The result is very interesting. This confirms that the DNS server is allowing us to retrieve the zone. More importantly, we've discovered additional hostnames. The most interesting discovery is:

We did not see this hostname on the main GreenOptic website. This is exactly why DNS enumeration was worth performing.

Why recoveryplan.greenoptic.vm Matters?

Think back to our problem. We currently have:

staff : wheeler

But we don't know where those credentials belong. At the same time, we've discovered another hostname. This gives us a new hypothesis:

Perhaps the credentials we recovered are associated with another application hosted on this hostname.

The hostname itself is also suggestive. A name such as recoveryplan could potentially indicate an internal application, recovery portal, administrative function, or some other service related to the incident described by the CTF.

We shouldn't assume that yet, but it gives us a very good reason to investigate it. Because the zone records resolve to 127.0.0.1 in the DNS response, we'll map the discovered hostnames to the actual target IP from Kali.

Making the New Hostname Reachable

Edit /etc/hosts and add greenoptic.vm recoveryplan.greenoptic.vm websrv01.greenoptic.vm hosts and verify using the cat command-line utility.

Now our Kali system can resolve

• greenoptic.vm
• recoveryplan.greenoptic.vm
• websrv01.greenoptic.vm
• ns1.greenoptic.vm

to:

• 192.168.56.104

Investigating the Newly Discovered Host

Now comes the important part. Open:

The browser responds differently from the main GreenOptic website. It prompts for a username and password.

If we cancel the authentication prompt, the application responds with an unauthorized-access message. This is significant because we have now discovered a separate application protected by authentication.

And remember what we already have:

So, this is exactly the type of situation where we should test the credentials we've already recovered rather than immediately starting another credential attack.

Enter:

• Username: staff
• Password: wheeler

This time, the credentials are accepted, and we gain access to the application, and this leads us to another important discovery:

• The application running there is phpBB.

Exploring the Recovery Plan Forum

What Is phpBB?

phpBB is an open-source bulletin-board or forum application written in PHP.

The name comes from PHP Bulletin Board. It is designed to provide web-based discussion forums where users can:

• Create and view forum topics, post messages
• Reply to discussions
• Exchange information
• Manage user accounts
• Participate in private or restricted discussions

For this CTF, however, the important point is not simply that we have discovered a forum. The important question is:

What information has the incident-response team left inside this application?

Since we now have authenticated access, the next phase is to enumerate the forum and examine the available discussions.

Investigating the Recovery Plan Forum

The phpBB installation is titled:

Recovery Plan

From the main forum page, we can see two major sections.

1. Information

Under this section, there is a forum called:

Key Information

Its description says:

“Key Information about the breach and our recovery efforts”

The forum contains one topic:

Team Message

2. Incident Response

There is also a Tasks, forum containing three topics. The most recent task shown on the page was posted by Terry.

• This is already interesting because we previously discovered Webmin running on Port 10000. The fact that this forum contains incident-response and operational information means that it may contain references to the same services and systems we have already discovered during enumeration.

So, rather than treating the forum as just another website, we should read it as a potential source of internal information about the target infrastructure.

Examining the Key Information Forum

Now, let’s examine the Key Information Forum.

Let's start with:

Key Information → Team Message

The topic was posted by:

Terry 

Opening the topic reveals a message beginning with:

Team,

Terry explains that the incident-response team needs to be especially careful while investigating the attack.

The most important section says:

“As discussed in our team meeting, we do not know how the attackers got in currently, but as the account portal is the most dynamic bit of software we are running on our website, we believe the vulnerabilities to exist there, hence taking it offline until we can investigate further.”

This is a very useful confirmation.

Earlier, we discovered that the main GreenOptic website contained an account portal and that the include parameter in that application was vulnerable to Local File Inclusion.

Now the forum message tells us that the company's own incident-response team also considers the account portal to be the most likely location of the vulnerability.

So we have independent confirmation from the application's own internal documentation.

The next part of Terry's message is even more important.

Terry says:

“Sam - thanks for volunteering to help earlier. The network monitoring I told you about is located here: dpi.zip.”

There is a clickable link:

dpi.zip

This immediately catches our attention because Terry explicitly describes it as:

Network monitoring

That strongly suggests that the archive contains information related to captured network traffic.

Inspecting the ZIP File

Let's download the file and inspect it. 

After downloading dpi.zip, we attempt to extract it. However, the archive asks us for a password. This is another important clue. We now know that dpi.zip is password-protected.

Instead of trying to crack the ZIP immediately, let's go back and read Terry's message carefully. There is another sentence that may explain where the password comes from.

Terry explicitly says:

“I have e-mailed you the password.”

This raises an obvious question:

Who is the email intended for?

The message is addressed to:

Sam

So, we now have:

Recipient: Sam

File: dpi.zip

Password: sent by email

The next question becomes:

Can we access Sam's email on the target system?

And this is where the LFI vulnerability becomes useful again.

Using LFI to Read Local Mail

But where are emails typically stored on a Linux file system, you may ask?

On Linux systems, locally delivered mail can be stored in standard locations such as:

/var/mail/

or:

/var/spool/mail/

depending on the system configuration.

Since we already know that the target has a user named sam,  we can investigate the corresponding mail file. A typical location is:

/var/mail/sam

We can therefore use the LFI vulnerability to request:

The application returns the contents of Sam's mailbox.

And inside the email, we find:

“Hi Sam, per the team message, the password is HelloSunshine123.”

This is the missing piece. Now that we have the password, we can return to the downloaded archive and extract it.

The archive successfully opens, and inside we find a PCAP file.

Inspect PCAP

A PCAP (Packet Capture) file contains captured network traffic.

In other words, it can contain information about communications that occurred on the network while the capture was running.

Depending on the traffic captured, a PCAP can reveal things such as:

• Source and destination IP addresses
• Protocols
• Ports
• DNS queries
• HTTP requests
• FTP traffic
• Authentication exchanges
• Other network metadata

For this reason, packet captures can be extremely valuable during incident-response investigations—and, in a deliberately vulnerable CTF, they can also contain clues that lead us to the next stage.

We can examine the packet capture using a packet-analysis tool. Here, I will use A-Packets (apackets.com).

The A-Packets Data Overview shows several categories extracted from the packet capture:

• Credentials: 2
• DNS Queries: 2
• HTTP Communication: 20
• Connections: 10
• Open Ports: 3
• FTP: 1
• Servers: 1

The most interesting item for us is Credentials: 2. That means the packet capture contains at least two authentication exchanges that A-Packets was able to recognize.

Let’s take a look at the credentials. Here, it reveals FTP and HTTP passwords.

This credential was captured as readable plain text. This is significant because FTP authentication is normally transmitted without encryption, so packet captures can expose the username and password when the session is captured.

The logical next step is to test the captured FTP credential against the FTP service we already identified.

Foothold

Earlier in the enumeration step, we captured FTP login credentials. 

Enumerating the FTP Directory

Let’s use them to get to know if gain access and get to know if Captured the Flag or anything.

On the terminal, run the following command:

It asks for username and password; just input it.

And the login was successful. Now let's list files and directories to know what to do next. Use the dir command. 

Here it displays the “user.txt” file. Let’s run the get command to download the file.

Now, let’s take a look at what is inside. Here it shows:

“Well done. Now to try and get root access.

Think outside of the box!”

To think outside of the box, instead of ftp can we use SSH to gain access? 

From FTP to SSH

Let’s run:

Here it is. You successfully got access with SSH. Let's now escalate the privilege.

Privilege Escalation (Credential Disclosure)

In the privilege escalation process, the primary goal is to enumerate the system further, identifying potential misconfigurations, exploitable vulnerabilities, or overlooked permissions. Our focus is to search for files or processes that may allow us to escalate to root or another privileged user, and also we will investigate permissions, SUID files, running services, and scheduled tasks for exploitation opportunities.

However, as we currently operate with limited user privileges through the reverse shell, we face restrictions on accessing certain files or commands for a comprehensive assessment.

To gather details, we run the id command, which will provide the user's UID, GID, and group memberships.

Here the,

• uid=1002(alex): User ID. The system identifies the user "alex" internally by the unique number 1002.
• gid=1002(alex): Primary Group ID. The user's primary group is also named "alex" with the ID 1002. It is standard practice in most Linux distributions to automatically create a primary group with the exact same name as the user when an account is made.
• groups=1002(alex),994(wireshark): Supplementary Groups. This lists every group the user belongs to.

The most notable detail here is 994(wireshark). Because "alex" has been added to the wireshark group, this user has been granted special permissions to capture and analyze network traffic without needing full root (administrator) access.

So, it means we have to run Wireshark to inspect network activity that is occurring on the machine.

That could potentially reveal useful information such as:

• Source and destination hosts
• Services being accessed
• DNS queries
• HTTP requests
• Authentication traffic
• Other unencrypted application data

This doesn't immediately mean that membership in the Wireshark group gives us root access. Instead, it gives us a new capability to investigate.

Now, let me show a problem that will occur next. 

In the terminal, if we run Wireshark, it will display a Gtk-WARNING **: cannot open display warning. 

This happens because Wireshark's graphical interface requires access to an X display, while a normal SSH connection does not automatically provide one.

To run a graphical application through SSH, we can use X11 forwarding.

In a new terminal, run the following command.

The -X option requests X11 forwarding, allowing graphical applications launched on the remote machine to display through the local X server.

On successful connection is established, now run Wireshark.

As a result, you will see it display the classic Wireshark graphical interface. 

On the Wireshark interface, choose any to give an instruction to capture traffic from all available interfaces. Now click on Start to capture; it will take time. 

Now click on Stop Capture to stop. Here, we can now understand if any important clues are listed in it.

Also, if you want then you can also use tshark, a command-line tool. You just have to run the following:

The -i option specifies the interface from which TShark should capture traffic, and any tells it to capture traffic from all available interfaces.

The output begins with:

Capturing on 'any'

This confirms that packet capture has started successfully. 

Now, let’s understand the captured data.

This is already an important finding: Alex's current privileges are sufficient to capture network traffic.

TShark now starts displaying packets as they are captured. The first few packets are local traffic, DNS queries, the SMTP server responds, and many more.

Here, we discovered an interesting part: Auth Plain Login; it is telling the client that it accepts basic username and password authentication. The client chooses to use the PLAIN method and sends the AUTH PLAIN command along with the login credentials to begin the process.

Those credentials look like a random jumble of letters and numbers, but they are actually just encoded in Base64. Since Base64 is used as the username and password, there may be a trace of the username and password when we decode to plain text.

Now, let’s decode the captured value. Now, run:

Here, it displayed plain text. The decoded value starts with root, which strongly suggests that the authentication attempt involved the root account. However, decoding the string alone is not enough to prove that the entire decoded value is the authentication username and password.

Here, run the following command:

The authentication succeeds, and we receive the root shell. This indicates that we have successfully escalated from the unprivileged alex username account to root.

Whenever we obtain a privileged shell, we should verify the privilege level rather than relying solely on the prompt. Now, run the following command.

It displayed root. Which means we now have root access. This confirms that we have full administrative access to the system.

Now that we have root access, we can inspect the root user's home directory.

The machine contains:

• anaconda-ks.cfg
• root.txt

The final flag can then be displayed with:

The machine responds:

Congratulations on getting root!

This confirms that we have completed the GreenOptic privilege-escalation path.