Bitlab — HTB Machine

Rishabh Rai
7 min readJan 14, 2024

Hello everyone, I am present here with a new machine of medium level difficulty. Let’s dive right in this machine…..

Okay so let’s get started wtih the nmap scans on the IP now in order to automate this process as i talked in my last blog. I wrote a small script to help me with this.

automate scan script Nmap

This script helps in scanning by firing up two small scans in two different windows and in the background also starts a bigger scan and one more added benefit to it is that. This will run a dirsearch scan if any open port is found. Which is really helpful sometimes.

Will rectify it more in coming time and then might also write a blog about the whole process….. But let’s leave this story for other time..

I moved my script to /usr/bin in order to access it from anywhere, you can also add the location of the file to PATH env and then run it from anywhere.

Anyways, I fired up my script by doing:

which is

hackscanner <IP> output_file name

This stores the nmap scan in the same folder it is triggered from and also saves the output of dirsearch scan in a specified folder.

After the scan is complete i found this output from the nmap file

In the output we can see that there is one ssh port open and one http service on port 80 even though it seems closed. I added the IP to the /etc/hosts and the script also ran a disearch scan on the port and IP.

And the stored output was this:

Gitlab Login page

Since the output was a little clustered i thought of removing some of the status and extension which were causing a lot of false positives.

Anyhow upon taking a closer look i visited the first page which was robots.txt

dirsearch -u “http://bitlab.htb:80" -e * -f -r “(?i)200|30[1–8]|50[0–9]” — exclude-status “401,404,400” — exclude-ext zip -o

After sometime i went to the help page and there I found a link to the Gitlab_Login but when i clicked the link it was not working so i went to check it from the page source and i found out this:

seems like a javascript funciton….. let’s give it a closer look by copying and analysing.

since it was under the name of gitlab login, I pasted it on the login page and then automatically it wrote the credentials for me and seems like we are in the account.

we are the administrator and we have two personal projects…. lets have a look at both of them…

Looking at this code it is checking if the repo is Profile and branch is master and the event is for merge request and the status is merged then

shell_exec runs git pull …… on the server so let us write something in the profile repo and let is git pull on the server…

So upon comitting and merging a branch from master branch we can see that it sticks there only and git pull must be taken by the code it self so.. all I have to do now is to put a reverse shell file and then commit and merge it to be able to exist on the server and making it easy for me to load the file and get a reverse shell foot hold on the machine.

afte merging and waiting for some time

we have got the initial foothold on the machine

but upon getting the shell we couldn’t directly get the user shell

we have a todo and creds to postgresql which we stumbled upon while the initial exploration of the gitlab account..

upon lookign at the netstat output we can see some of my http instances connected and one is my curent shell session. Other than that we have 5432 and 3000 port in which 5432 is interesting as it directs us towards postgresql.

Since i already ahd the snippet i just googled and completed it to be able to run and print me the data that i rquire

$db_connection = pg_connect(“host=localhost dbname=profiles user=profiles password=profiles”);
$result = pg_query($db_connection, “SELECT * FROM profiles”);

while ($row = pg_fetch_assoc($result)) {
// Process each row of data, e.g., print it


let’s gooooooooo
we have the password…….

I was trying ssh-ss….. for a long time and then I tried the code directly and to my surprise it worked …


Let’s go for the root flag

We already know about the Remote connection.exe in the clave directory… Let transfer it to our PC and have a look at it……

Since this is not working lets try scp as ssh is enable on the box so it should not be a problem.

ok so after scp jut open ghidra and import the exe file …… and let it analyse it and if not

Go to analyse and hit auto analyse or you can hit A as well it might work the same way……

after analysis is complete.. go to window and select defined strings…

While going through all that i saw GET USERNAME but there we no reference to it so,….. we move to something more interersting which is clave…. afte going to rreference and opening decompile we see

In order to find the value of the passsowrd we have to use the debugger this took a lot of time to find a good GUI debugger in LINUX

but in the end i had to look for a windows option as it was becoming tough to debug through linux and then i downloaded x32dbg.

First i navigated to the string references through this …

And then I put a breakpoint at the shell execute to check what is happening at that place… and also I change the JNE of clave to JE to make it jump with coming ZF value…

And just like that we have the root flag popping up in the stack, we can directly use this in ssh login and then fetch the root.txt.


Finally it is DONE and Conquered !!!!

My review:

the foothold of this room was fairly easy but to get the root flag i had to break a sweat as reverse engineering is fairly new for me but GHIDRA and debugger clutched the scenario… Great learning experience I had while solving this machine..

Looking forward to more Reverse Engineering Machines ….. in future

Join me on various platforms to discuss Cybersecurity and Cloud-related topics. From security best practices to cloud infrastructure, let’s exchange ideas and insights and stay ahead of the curve..




Rishabh Rai

4th year student exploring the world of cyber security with a knack for writing and always learning.