Hacking the BillyBoss Practice Machine

Our target for this exercise will be OffSec’s BillyBoss Practice Machine. OffSec offers a subscription-based service that allows users to practice hacking skills on various virtual machines via a VPN. Many aspiring hackers begin their learning experiences with platforms like this.

The goal of this exercise is to achieve Remote Code Execution (RCE) on the machine, which essentially means executing arbitrary code. Typically, this involves establishing a stable remote shell, often referred to as a reverse shell. Following that, our aim is to elevate our privileges to Administrative rights, ultimately allowing us to retrieve the flag located at C:/Users/Administrator/Desktop/proof.txt. Let's get started.

Remote Code Execution

Before exploiting the machine, we must conduct enumeration to determine its configuration. In a real-world scenario, we may have little to no information about the machine beforehand. Thus, we need to answer key questions such as: "What operating system is it running?", "What services are available?" (like HTTP, FTP, SSH, SMB, etc.), and "What users are linked to the system?" Understanding these factors guides our attack strategy.

To kick off the enumeration process, we commonly use Nmap, a tool that helps identify active services and sometimes even the operating system. Below are the results from our Nmap scan conducted from our Kali Linux machine:

As we methodically analyze the available services, the HTTP server on port 8081 stands out. Port 8080 is commonly used for HTTP traffic, suggesting that the machine's setup might be attempting to obscure its HTTP service. This exemplifies how "security through obscurity" can be ineffective, as Nmap easily detected the web server.

Upon accessing the web server through a browser, we encounter the Sonatype Nexus Repository Manager:

While authentication is required for the web application, it's often beneficial to test common credentials such as user:user or admin:admin. Occasionally, default credentials are also worth trying. In this case, we successfully log in with nexus:nexus. The control panel indicates that we are running version 3.21.0, which could be significant for our next steps.

Once we identify a web application with valid credentials, we typically leverage it to gain access to the system. Some services allow us to execute scripts directly, while others may require us to discover publicly available exploits. To find such exploits, we utilize exploit-db.com, an online database cataloging vulnerabilities in software. When searching for "Sonatype Nexus," we find a relevant exploit:

Reviewing the exploit's comments reveals that Nexus Repository Manager versions below 3.21.1 are susceptible to this exploit. Since our instance runs version 3.21.0, it is indeed vulnerable. Notably, the exploit requires authentication, which is not an issue for us given that we have the nexus:nexus credentials.

Next, we download the exploit's Python script and open it in our code editor. Typically, we need to modify exploits to tailor them for our specific needs. For instance, we must set the target machine's IP and port, and we might need to install dependencies for the script. Thus, executing the exploit isn't as simple as downloading and running it. Below are the adjustments made to the script:

In particular, we've configured the URL to point to the Nexus application, specified the username and password, and set the CMD to execute on the target machine. This command retrieves shell.exe from our Kali machine and saves it on the target. The command used to generate shell.exe with the Metasploit framework is as follows:

When we execute shell.exe, the target machine will initiate a connection back to our Kali machine on port 443, establishing a reverse shell. To capture this connection, we need to set up a netcat listener. Once the listener is ready, we can trigger the exploit script and observe the connection:

We also need to make shell.exe accessible to the target machine by running our own HTTP server on port 80. This enables the target to download the file from our server:

Now, we are ready to execute the exploit:

The script logs the command execution, indicating that the process is proceeding as expected. Let's check our HTTP server to verify that the target machine successfully retrieved shell.exe:

Indeed, the target successfully called our HTTP server. Next, we check the netcat listener for the reverse shell:

The output confirms a connection from the target machine's IP to our Kali's IP. To ensure functionality, we run a whoami command and receive confirmation that we are executing commands on the target as the user Nathan. Thus, we have achieved Remote Code Execution on BillyBoss. Our next objective is privilege escalation.

Privilege Escalation

Currently, we cannot access the files in C:/Users/Administrator/Desktop because we lack Administrative privileges. Our next steps involve internal enumeration of the machine. We may find a service running with Admin rights that we can exploit, or perhaps discover Admin credentials in a PowerShell history file. The methods for privilege escalation are numerous, and there's no single approach. I have compiled a few strategies in a runbook, which you can explore for further insights.

For this phase, I generally combine manual enumeration techniques with automated tools. One notable tool is WinPEAS, which performs a series of tests on the Windows machine to identify potential privilege escalation vectors.

In this instance, we don’t need to run WinPEAS. Following the runbook, one of the first tasks is to determine the privileges associated with our current Windows user through the command whoami /priv:

A key privilege to note is SeImpersonatePrivilege, which allows the user to impersonate administrators. This potentially enables the execution of commands with Administrative rights. For more in-depth information, refer to this resource. Various tools are available to exploit this privilege, and we will use JuicyPotatoNG.

Our ultimate aim is to spawn a new remote shell with Administrative rights, which can also connect back to our netcat listener, similar to our earlier process. We already have shell.exe on the target, but we'll need to transfer JuicyPotatoNG.exe to the system. As noted previously, this can be accomplished by hosting it on our HTTP server and retrieving it using PowerShell as we did with the Python exploit. After transferring the file, we start a netcat listener on our Kali machine:

Now, we execute JuicyPotatoNG.exe with a command to run shell.exe:

The output suggests success. Checking our netcat listener reveals:

At this point, it’s understandable if some readers wonder about the difference between the reverse shell obtained through this method and the one acquired earlier. The key distinction lies in the privileges of the shells. The first shell was executed under the user Nathan. Attempting to access the proof file from the Nathan shell yields:

Nathan lacks the necessary permissions to access files in C:/Users/Administrator. Conversely, if we attempt to retrieve the file from the shell running with SYSTEM privileges, we can access it:

(Note that I've redacted the contents of the file to avoid spoiling the machine.)

In a real-world scenario, a hacker would typically seek to secure their access by installing a backdoor, allowing for future entry into the system. This might also involve creating additional Admin accounts for later use.