HTB [Easy Lab] - Cohort

I conducted an Nmap scan against the target and discovered three open ports: SSH, HTTP, and HTTPS. When browsing the website, I encountered a redirect error pointing to a domain named cohort.htb.

I then mapped this domain to the hosts file on the attack machine and accessed the website again. I proceeded to browse through the website to understand its structure and available functionalities. After exploring the site, I discovered an endpoint that provides a data feed functionality.

I used Burp Suite to intercept the request and provided test inputs, which allowed me to obtain the request body structure as shown in the image.

I proceeded to test command injection payloads; however, it seems that the application is not vulnerable to command injection. After that, I moved on to checking whether the application was vulnerable to SSRF. The application also states that loopback and internal addresses are not allowed, so using values such as localhost or other internal addresses resulted in an error indicating that they are not permitted.

I moved on to checking whether the application was vulnerable to SSRF. The application also states that loopback and internal addresses are not allowed, so using values such as localhost or other internal addresses resulted in an error indicating that they are not permitted.

I tried another bypass value, which was 0.0.0.0, and the result was successful. The application returned the page source of the website. This proves that the endpoint is vulnerable to SSRF. Although the application restricts internal and loopback addresses, it fails to properly validate and block the 0.0.0.0 value, allowing it to be used as a bypass

Therefore, I will focus on exploiting the SSRF vulnerability in this endpoint. When encountering an SSRF vulnerability, I usually try to fuzz for internal endpoints that may be exploitable, or identify whether there are any internal services running on unknown ports within the server.

As the first step, I will use ffuf to discover whether there are any additional endpoints that could reveal valuable information. After that, I will perform further enumeration of local ports to identify any services running on the server. After using a wordlist and running the scan, I discovered several accessible endpoints.

I used Burp Suite to query these endpoints, and while browsing the /status endpoint, I obtained additional valuable information. I discovered another site named notebooks running under the domain nb-1be3782a8afd3ad5.cohort.htb. I was also able to obtain its local ports.

I mapped this domain to the hosts file and attempted to access it. At this point, I was redirected to a new site called Marimo login. However, it did not reveal much additional information that I could use for further enumeration, such as the application version or other useful details.

I tried using Burp Suite to connect to port 8888, but I did not find any useful information other than the fact that an access token is required to gain access.

I was quite stuck at this point, but I decided to check whether there were any public CVEs or exploit PoCs available for Marimo. Trying available PoC payloads seemed more productive than just staring at the Marimo authentication page.

After searching, I discovered a CVE related to Marimo that could lead to Pre-Authentication RCE, which is CVE-2026-39987. The affected versions are those before 0.23.0. However, since I do not yet know the exact Marimo version running on the target machine, I will not jump to the conclusion that the target is vulnerable to this CVE.

I proceeded to review the available exploit PoCs. According to the description, Marimo versions <= 0.23.0 are affected because the WebSocket endpoint /terminal/ws lacks authentication validation, allowing an unauthenticated attacker to obtain a full PTY shell and execute arbitrary system commands. The /terminal/ws WebSocket endpoint is used to connect to the terminal on the server. Therefore, if there is no authentication mechanism in place, we can execute commands freely with the privileges of the user account running the Marimo service.

Okay, I will test whether this target Marimo instance is affected by this CVE. I will use wscat to connect to the WebSocket endpoint and use the -x parameter to send a command through the WebSocket, as described in the PoC. When using ws://, it returned a 301 error. This could indicate that the endpoint has been moved to another domain or that it requires a secure WebSocket connection (wss://).

I switched the connection to the secure WebSocket (wss://). At this point, I could see the terminal user appearing, but it did not return any output. I then realized that because it uses a PTY (Pseudo Terminal), it expects an Enter key input before executing commands. I adjusted the command after the -x parameter in wscat, and it worked successfully. Therefore, I can conclude that the target Marimo instance is affected by this CVE and allows RCE.

Now, the only remaining step is to retrieve the user flag from the home directory.

The next task is to escalate privileges to root. I tried using various reverse shell techniques, but most of them were unable to maintain a stable connection, possibly due to the PTY environment.

I will use a Python script that allows interactive terminal usage with a background thread for receiving output. You can find the script here.

I proceeded with enumeration to find a way to escalate privileges to a root shell. After checking for SUID binaries, processes running as root, cron jobs, and sudo -l, I did not find any useful information that could help me escalate privileges. I then moved on to checking the installed packages on the system to see if any outdated packages with known vulnerabilities could be exploited for privilege escalation. After a long period of filtering and investigation, I discovered that the installed PackageKit version was associated with a CVE: CVE-2026-41651 (Pack2TheRoot).

PackageKit is a package management framework on Linux. Its purpose is to provide a common communication layer between applications and different package managers. PackageKit like an “intermediate API” that allows Linux applications to install, update, and remove software without needing to know whether the system uses apt, dnf, pacman, or another package manager.

For example, on ubuntu, you’ll use apt isntall .... and on fedora dnf install....These two systems use different package managers. PackageKit provides a common abstraction layer, applications only need to call PackageKit and PackageKit then translates the request into the appropriate command for the system.

The vulnerability is a time-of-check-time-of-use (TOCTOU) race condition in PackageKit’s D-Bus transaction handling.  The vulnerable program checks a state, permission, object, or parameter at one moment, then uses something later after the relevant state has changed. The check may have been correct when it happened. The use may be unsafe because the world is no longer the same.

You can read more about the CVE through the provided link [1] [2], and I also found a GitHub repository containing a proof-of-concept (PoC) exploit. I will proceed to download this PoC onto the target machine and execute it.

And boom, I obtained a root shell.

My assessment of the privilege escalation process on this machine is that the challenging part is identifying which packages on the target system are outdated or affected by security vulnerabilities that have not been patched yet.

As for the exploitation phase, luckily there was an available PoC payload. However, I would still recommend reading and understanding the CVE details before using the exploit.