Exploitation Walkthrough#

Port Scan Results#

The target system exposes the following open ports and services:
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Artificial - AI Solutions
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Initial Recon#
Result from browser

→ Add the following entry to your hosts file 10.10.11.74 artificial.htb
After reviewing artificial.htb, I found several interactive features available:
- Account registration and login
 - Uploading and executing machine learning models
 - A downloadable template.py for building models in .h5 (Keras) format
 


Upload model

Run model

The most significant risk lies in the server’s ability to execute user-uploaded machine learning models. It’s unclear whether any validation or filtering is performed before these models are run. This behavior presents a promising attack surface and is worth investigating for potential vulnerabilities.
Exploiting Model Execution#
Research#
After a bit of Googling, I found several resources suggesting that this functionality could be exploitable.

- On Malicious Models
 - Potential Remote Code Execution (RCE) Vulnerability in Custom Layers Handling (#82214)
 
Prepare payload#
I created two payloads: one to test command injection by triggering a sleep delay, and another to establish a reverse shell.
Reverse shell established successfully.

User Account Owned#
After gaining a shell as the app user, I accessed the server-side code to analyze it further and identify the underlying vulnerability.
Using server_upload.py to receive data app.tar.gz .


- Spotted user.db — looks like it holds the keys to user accounts on the site.
 

1|gael|gael@artificial.htb|c99175974b6e192936d97224638a34f8
2|mark|mark@artificial.htb|0f3d8c76530022670f1c6029eed09ccb
3|robert|robert@artificial.htb|b606c5f5136170f15444251665638b36
4|royer|royer@artificial.htb|bc25b1f80f544c0ab451c02a3dca9fc6
5|mary|mary@artificial.htb|bf041041e57f1aff3be7ea1abd6129d0
These are the first five accounts in the user table, all using the @artificial.htb domain. This suggests they belong to staff members or users associated with the organization or internal system.
Smashing the Hash#

→ The gael account stands out as noteworthy.

They’re using MD5 for password hashing — perfect target for John the Ripper .

gael@artificial.htb: mattp005numbertwo
royer@artificial.htb: marwinnarak043414036
Cracked and logged in — both gael and royer accounts are now accessible.


Escalating Account Compromise#
Is there a way to escalate further and gain access to other users?
In app.py, I discovered the secret_key, which allows me to forge valid session cookies. Using hijacking_session.py , I can hijack sessions and log in as other users.

mark@artificial.htb

…or hijack sessions of other players active on the box.
MeowMeow@artificial.htb

Mission Complete: Flag Acquired#
At first, I tried switching to the gael user using the cracked password, but it failed. This left me confused, and I spent a significant amount of time exploring alternative exploitation paths — but nothing seemed to work…

Wasted half a day chasing dead ends… then I tried SSH — and boom, I was in.

Flag: 72c6100ad4e95442bfd90e3d0f66b706
System Pwned#
Knowing the system runs Linux, I used linpeas.sh from PEASS-ng to enumerate potential privilege escalation vectors.
Fired up a server on my end and fetched linpeas.sh to the target — time to hunt for root.
python -m http.server 8000

After running it, the linpeas.sh output
revealed several noteworthy findings worth investigating.



Service Discovery#
The backrest.log file also revealed that a web server is running locally on 127.0.0.1:9898

Setting up an SSH local port forwarding tunnel to view this service.
ssh gael@10.10.11.74 -L 9898:127.0.0.1:9898

Service Breach#

This is a base64-encoded bcrypt password. I’m also using John the Ripper to attempt to crack it.

backrest_root: !@#$%^
Escalate Privileges to Root#
Backrest && Restic#

First, I explored some of the available actions, such as creating a repository and testing the “run command” feature. I attempted command injection, but it didn’t work.


So, I needed to understand what Backrest actually does in order to find a way to leverage it for exploitation.


Backrest: a cross platform backup orchestrator and WebUI for restic
Imagine setting up a repo that points to /root and exfiltrates the data straight to my Restic server — now that’s leverage.
Weaponized Restic Server#
First, create a rest-server.

Init repo to my server.

Backup /root directory to my repo

Access to /root from server.


SSH access using the .ssh/id_rsa

Flag: 99b888214ef2cd3206a36fee7cba0918