Bedside Machine Summary
Bedside is a medium-difficulty Linux machine on Hack The Box that focuses on modern web application security, containerized environments, internal network pivoting, development server misconfigurations, arbitrary file read vulnerabilities, and insecure machine learning model deserialization. The machine demonstrates how a seemingly isolated container compromise can be chained with exposed development services, weak filesystem permissions, and an unsafe PyTorch checkpoint loading mechanism to achieve full system compromise.
The attack began with Nmap enumeration, which identified SSH and an Apache web server hosting bedside.htb. After host configuration, web enumeration, and web technology enumeration, I confirmed the application stack before performing virtual host enumeration, which revealed research.bedside.htb. Following another host configuration, I continued with research portal enumeration, where I identified a file upload feature. Through file upload testing and upload request analysis, I discovered that uploaded files were processed by pdfminer.six, eventually leading to an insecure deserialization vulnerability that provided the initial foothold inside a Docker container. After obtaining code execution, I performed shell stabilization, upgraded the session to a fully interactive TTY, applied terminal configuration, and carried out extensive environment enumeration and system enumeration. I confirmed I was operating inside a Docker container with host-mounted directories and then transferred CDK by first preparing the enumeration tool. Using CDK for container assessment, I identified shared namespaces, host networking, and bind-mounted host filesystems. During mounted disk enumeration, I confirmed that although the container was not privileged, the mounted datastore exposed valuable attack surfaces for further investigation.
With host networking available, I performed internal port enumeration, discovering an internal service listening on localhost:3000. I prepared for pivot enumeration by deploying Ligolo-ng, completing the tunnel setup, tunnel establishment, tunnel configuration, and tunnel verification to transparently access internal services from my attacking machine. This allowed me to perform internal web enumeration, revealing a React-based medical image viewer that was inaccessible from outside the container. While reviewing the application, client-side source code analysis exposed Vite's Hot Module Replacement endpoint, indicating that the application was running in development mode. Guided by this discovery, I performed path traversal testing, successfully exploiting an arbitrary file read vulnerability. Through arbitrary file read, I extracted sensitive files from the filesystem, including the developer user's private SSH key. After SSH key preparation, I authenticated directly to the host via SSH authentication, escaping the container entirely and gaining an interactive shell on the underlying Linux system.
Once on the host, I carried out host enumeration, followed by sudo privilege enumeration, revealing that the developer account could execute a privileged Python training script without a password. After retrieving the user flag, I performed sudo script analysis, identifying that the application automatically loaded PyTorch checkpoints using MONAI's CheckpointLoader. Initial permission enumeration showed that the checkpoint directory was inaccessible, while dependency enumeration confirmed the installed PyTorch version and its checkpoint loading behavior. Returning to the compromised container, I exploited weak filesystem permissions through datastore permission manipulation, making the checkpoint directory writable. I then created a malicious PyTorch checkpoint during checkpoint preparation and verified it through checkpoint verification. Finally, I triggered the vulnerable training application with sudo, causing the crafted checkpoint to be deserialized as root, which resulted in successful privilege escalation. After confirming root access, I retrieved the root flag, completing the compromise of the Bedside machine.
Protected Page
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Bedside machine and I was assigned an IP address (10.129.52.2).
Nmap Enumeration
I began the assessment by performing a comprehensive Nmap scan against the target to identify exposed services, detect software versions, and gather as much information as possible about the underlying operating system. I used the -sCV option to combine default NSE scripts with version detection, while the -A flag enabled aggressive enumeration, including OS detection, traceroute, and additional service fingerprinting.
The scan revealed only two accessible TCP services: SSH on port 22 and an Apache HTTP server on port 80, while port 3000 appeared filtered, indicating that a firewall or packet filtering mechanism was preventing direct access. The SSH service was running OpenSSH 10.0p2 on Debian, suggesting that remote administration was available but would require valid credentials. More importantly, the web server was identified as Apache 2.4.68, making the HTTP service the primary attack surface for initial enumeration.
Host Configuration
Since the Nmap scan showed that the web server redirected all HTTP requests to http://bedside.htb, I needed to configure my local system to resolve that hostname to the target's IP address. Because bedside.htb is an internal hostname and does not exist in public DNS, my machine would otherwise be unable to reach the application correctly. To accomplish this, I added a static entry to the /etc/hosts file, mapping the target IP address to the virtual host discovered during enumeration.
This command appends the line
10.129.52.2 bedside.htb to the system's hosts file while preserving the required root privileges through sudo. As a result, any requests made to bedside.htb were resolved locally to the target machine instead of being sent to an external DNS server. With hostname resolution configured, I could now access the intended web application by browsing to http://bedside.htb, ensuring that the correct Host header was included in every request. This was an essential prerequisite for the subsequent web application enumeration, as many applications using name-based virtual hosting serve different content depending on the requested hostname.Web Enumeration
After configuring the virtual host, I visited http://bedside.htb in my browser to begin enumerating the web application. The site loaded successfully and presented itself as Bedside Clinic, a healthcare website showcasing AI-powered cardiovascular treatments, personalized rehabilitation, and contact information.
At first glance, the application appeared to be a simple static website with no obvious functionality such as authentication, forms, or user interaction, suggesting that additional enumeration would be required to uncover hidden content or attack surfaces.
Since the homepage exposed only informational content, I proceeded with further web enumeration to identify hidden directories, virtual hosts, and other functionality that was not immediately visible through the browser.
Web Technology Enumeration
To identify the technologies powering the website, I ran WhatWeb against the target. This helped me fingerprint the web server, identify potential technologies in use, and collect any additional information that could guide the next stage of enumeration.
The results confirmed that the application was hosted on a Debian server running Apache 2.4.68 and also revealed the contact email address
contact@bedside.htb, although no additional frameworks or CMS signatures were detected. With no obvious technologies or vulnerable applications exposed, I continued the assessment by enumerating hidden directories and virtual hosts in search of functionality that was not visible from the homepage.Virtual Host Enumeration
Since the homepage did not expose much functionality, I enumerated for additional virtual hosts using FFUF by fuzzing the Host header. This technique helps identify hidden subdomains that may host separate applications or administrative interfaces not linked from the main website.
The scan returned several common subdomains such as
www, mail, admin, vpn, and docs; however, every result responded with the same 301 redirect and identical response size, indicating they were default wildcard responses rather than valid virtual hosts. Since no unique subdomains were discovered, I shifted my focus to directory and content enumeration on the main web application.Directory Enumeration
After the virtual host enumeration yielded no interesting results, I enumerated the web server for hidden directories and files using Feroxbuster. I included several common file extensions to search for backup files, archives, and source code that might expose additional functionality.
The scan discovered only a few accessible resources, including
index.php and the /javascript/ directory containing a jQuery library. No administrative panels, backup files, or sensitive directories were exposed, indicating that the application's attack surface was likely hidden elsewhere. I therefore continued with more in-depth web enumeration to uncover additional functionality.Virtual Host Enumeration
Since the initial virtual host scan produced only wildcard responses, I performed a more targeted scan using a larger wordlist while filtering out the default response size. This approach eliminates false positives and highlights only virtual hosts that return unique content.
This time, the scan identified a valid virtual host named
research.bedside.htb, which returned a unique HTTP 200 response with a different page size. This indicated the presence of a separate web application, making research.bedside.htb the next target for further enumeration.Host Configuration
After discovering the research.bedside.htb virtual host, I updated my local hosts file so that my system could resolve the hostname to the target IP address. Without this mapping, requests to the new virtual host would not reach the intended application.
With the hostname configured, I was able to browse directly to
http://research.bedside.htb and begin enumerating the newly discovered application, which represented a much more promising attack surface than the main website.Research Portal Enumeration
After resolving the new virtual host, I visited http://research.bedside.htb to enumerate the application. Unlike the main website, this portal exposed a file upload feature intended for staff to submit medical images and research documents for AI model training, making it a much more interesting target for further assessment.
The page accepted several image and document formats and also noted that collections can be uploaded as archives, suggesting that server-side file processing was taking place. Since file upload functionality is a common attack vector in CTFs, I focused my attention on testing the upload mechanism for potential vulnerabilities.
File Upload Testing
I began testing the upload functionality by attempting to upload a standard PHP reverse shell while starting a Netcat listener on my attacking machine to catch an incoming connection. This is a common technique for determining whether uploaded files are stored and executed by the web server.
The upload was immediately rejected with the message "Invalid file type. Allowed: jpeg, jpg, png, bmp, tiff, dcm, pdf, gz, zip", and my Netcat listener never received a callback. This confirmed that the application enforced server-side file type validation, so I shifted my focus to identifying a method of bypassing the upload restrictions rather than attempting direct PHP file execution.
Upload Request Analysis
To better understand how the upload functionality worked, I intercepted the requests with Burp Suite and inspected both the request and response headers. During this analysis, I noticed the response included the header X-Powered-By: pdfminer.six, revealing that the server was processing uploaded documents with the Python pdfminer.six library.
The disclosure of
pdfminer.six was a valuable clue because it identified the backend technology responsible for handling uploaded files. Knowing the application relied on this library, I shifted my focus to researching publicly disclosed vulnerabilities affecting pdfminer.six to determine whether the upload mechanism could be abused for code execution or another attack vector.Initial Foothold
While analyzing the backend technology, I discovered that the application relied on pdfminer.six, which was vulnerable to insecure deserialization. I developed a proof-of-concept exploit that generated a malicious compressed pickle payload and a crafted PDF designed to trigger deserialization during document processing.
Before launching the exploit, I started a Netcat listener to receive the incoming reverse shell.
Then I ran the exploit with Python:
A few seconds after the exploit uploaded both files, my Netcat listener received a connection from the target, confirming that the deserialization vulnerability had been successfully triggered.
This provided an initial shell on the target as the
datawrangler user inside the data-wrangler environment, giving me my first foothold on the machine.Shell Stabilization
After obtaining the initial foothold, I enumerated the environment to identify the current user, group memberships, hostname, working directory, and the availability of Python. Since Python 3 was installed, I used it to upgrade the basic reverse shell into a fully interactive TTY and configured the terminal for a better command-line experience.
The enumeration confirmed that I had access as the
datawrangler user, a member of the dataops group, inside the data-wrangler host with the current working directory set to /app. With a stabilized interactive shell, I was ready to begin post-exploitation enumeration and search for privilege escalation opportunities.Fully Interactive TTY
Although the shell was already usable, I performed the standard TTY upgrade to obtain a fully interactive terminal with proper job control, command history, and terminal editing. I temporarily backgrounded the Netcat session, determined my local terminal dimensions, restored the shell in raw mode, and reset the terminal.
After completing these steps, the reverse shell behaved like a normal interactive Bash session, making subsequent enumeration and privilege escalation significantly more convenient.
Terminal Configuration
To complete the shell stabilization process, I configured the terminal environment by setting the TERM variable and matching the shell dimensions to my local terminal. This ensures that full-screen applications, text editors, and command-line utilities display correctly without formatting issues.
With the terminal fully configured, I had a stable and properly sized interactive shell, allowing me to continue post-exploitation enumeration without display or input problems.
Environment Enumeration
With a stable shell, I began enumerating the filesystem to better understand the execution environment. I listed the contents of the root directory and checked for the presence of the .dockerenv file, which is commonly used to identify Docker containers.
The enumeration confirmed that I was operating inside a Docker container, as indicated by the presence of
/.dockerenv. I also identified a writable /datastore directory owned by the datawrangler:dataops user, suggesting it was likely used for application data processing and would be an important location to investigate during post-exploitation.System Enumeration
To gain a better understanding of the environment, I enumerated the operating system, hostname, and mounted filesystems. This helped me determine whether I was operating on the host or inside a container and identify any host directories exposed to the current environment.
The output confirmed that the target was running Debian 13 (Trixie) inside a Docker container named
data-wrangler using an overlay filesystem. More importantly, the host's /dev/sda4 partition was mounted into the container, exposing directories such as /datastore and /var/www/research.bedside.htb/uploads, indicating that the container had direct access to persistent data on the underlying host and making these locations prime targets for further enumeration.Environment Enumeration
I continued enumerating the environment by reviewing the available environment variables and checking the mounted filesystems for useful paths or configuration details. This helped me identify the runtime environment and any locations shared with the underlying host.
The output confirmed that the container was running Python 3.12.12 with the application located in
/app, while the mounted filesystems showed that /datastore was backed by the host's /dev/sda4 partition rather than ephemeral container storage. This reinforced that any files written to /datastore would persist outside the container, making it a high-value location for further enumeration and potential privilege escalation.Container Enumeration
Since I had confirmed that my foothold was inside a Docker container, I transferred CDK (Container Diagnostic Kit) to the target to automate container enumeration and identify potential container escape or privilege escalation opportunities. I hosted the binary on my attacking machine, downloaded it inside the container, and made it executable.
On my Kali Linux machine, I ran:
On the target machine, I ran:
With the CDK binary successfully transferred to the container, I was ready to execute it and perform a comprehensive assessment of the container environment in search of misconfigurations, exposed host resources, and potential escape vectors.
Preparing the Enumeration Tool
After transferring the CDK binary to the target, I made it executable and verified that the file had been downloaded successfully. Confirming the file permissions and size ensured that the binary was intact and ready to be executed inside the container.
The output showed that the binary was executable and approximately 6.3 MB in size, confirming a successful transfer. With the tool ready, I proceeded to run CDK to enumerate the container for potential escape vectors and privilege escalation opportunities.
Container Assessment
To identify potential escape vectors and container misconfigurations, I executed CDK in evaluation mode. This automated the enumeration of the container environment, including namespaces, capabilities, mounted filesystems, running services, and other security-related settings.
The assessment confirmed that I was running inside a Docker container with shared host namespaces, including the network, mount, PID, IPC, and UTS namespaces. It also revealed that the container was running with host networking (
--net=host) and had direct access to host-mounted directories such as /datastore and /var/www/research.bedside.htb/uploads. These findings indicated a weakly isolated container, making the exposed host resources and running services the next focus for privilege escalation.Mounted Disk Enumeration
Based on the previous CDK findings, I attempted to use the mount-disk module to determine whether the host's filesystem could be mounted from within the container. This would have provided direct access to the underlying host if the container had been started with sufficient privileges.
The module confirmed that the host's
/dev/sda4 partition was already bind-mounted into locations such as /datastore and /var/www/research.bedside.htb/uploads. However, the attempt to mount the disk failed because the container was not running in privileged mode, preventing a straightforward container escape. Since the host-mounted directories were already accessible, I shifted my focus to thoroughly enumerating those locations for sensitive files and privilege escalation opportunities.Internal Port Enumeration
Since the container was sharing the host's network namespace, I enumerated common localhost ports to identify services that were not exposed externally. This is a useful post-exploitation technique for discovering internal applications that may only be accessible from within the compromised environment.
The scan revealed that ports 80 and 3000 were listening on the local interface. While port 80 corresponded to the web application I had already identified, the previously filtered port 3000 was now accessible from inside the container, making it a high-priority target for further enumeration.
Pivot Preparation
Since an internal service was listening on localhost:3000, I prepared a tunneling solution to access it from my attacking machine. I downloaded the Ligolo-ng agent, extracted it, made it executable, and transferred it to the compromised container using my temporary HTTP server.
On my Kali Linux terminal, I ran:
On the target machine, I ran:
With the Ligolo-ng agent successfully transferred to the target, I was ready to establish a tunnel into the container and enumerate the previously inaccessible service running on 127.0.0.1:3000.
Tunnel Setup
To access the internal service running on localhost:3000, I prepared the Ligolo-ng proxy on my attacking machine. I downloaded the proxy binary from the official release, extracted the archive, and verified that the executable was available before establishing the tunnel.
The extraction produced the
proxy executable, confirming that the Ligolo-ng proxy was ready to accept connections from the compromised container. With both the proxy and agent prepared, I proceeded to establish the tunnel and enumerate the internal service listening on 127.0.0.1:3000.Tunnel Establishment
To access the internal services from my attacking machine, I started the Ligolo-ng proxy and configured it to listen for incoming agent connections. I then launched the Ligolo-ng agent on the compromised container, allowing it to establish a reverse tunnel back to my system.
On my attacker machine (Kali Linux), I ran:
On the target machine, I ran:
Once the agent connected successfully, the proxy reported that the
datawrangler@data-wrangler session had joined.
This confirmed that the tunnel was active, enabling me to securely reach internal services such as 127.0.0.1:3000 directly from my attacking machine.
Tunnel Configuration
After the agent connected successfully, I selected the active Ligolo-ng session and configured a TUN interface on my attacking machine. I then added a route for the internal target before starting the tunnel, allowing my system to communicate with services inside the compromised environment as if they were locally reachable.
With the tunnel running, I gained transparent network access to the container through the
ligolo interface. This allowed me to interact directly with internal services, including those bound exclusively to localhost, without relying on traditional port forwarding.Tunnel Verification
Before accessing the internal service, I verified that the Ligolo-ng tunnel had been configured correctly on my attacking machine. I checked that the virtual ligolo interface was active and confirmed that the route to the internal target had been added successfully.
The output confirmed that the
ligolo interface was up and that traffic destined for 240.0.0.1 would be routed through the tunnel. With the tunnel fully operational, I could now access internal services on the compromised host directly from my attacking machine.Internal Web Enumeration
After establishing the Ligolo-ng tunnel, I visited the internal application running on port 3000 through the routed address. This allowed me to access a service that was previously reachable only from within the compromised container.
The page loaded successfully and presented a React-based single-page application named "Bedside Clinic - Image Viewer." At first glance, the application exposed a minimal interface with no obvious functionality, so I shifted my focus to inspecting the client-side source code and associated API requests to identify hidden features and potential attack vectors.
Client-Side Source Code Analysis
While inspecting the application's source code, I discovered the /@hmr endpoint and visited it directly. The response contained the Hot Module Replacement (HMR) client used by Vite, confirming that the application was running in development mode rather than as a production build.
After identifying the exposed Vite HMR client, I researched known issues affecting development servers and found that certain configurations have been vulnerable to path traversal attacks. Based on this observation, I proceeded to test multiple path traversal payloads against the application to determine whether arbitrary files could be accessed from the underlying filesystem.
Path Traversal Testing
Based on the exposed Vite development server, I tested whether the application was vulnerable to path traversal by requesting a sensitive system file. I used curl with the --path-as-is option to prevent path normalization and send the traversal sequence exactly as intended.
The server returned the contents of
/etc/passwd, confirming that the application was vulnerable to arbitrary file read via path traversal. The output also revealed local user accounts, including developer and datawrangler, demonstrating that files outside the web root could be accessed and providing a powerful primitive for further enumeration and credential hunting.Arbitrary File Read
After confirming the path traversal vulnerability, I expanded my enumeration by targeting sensitive files outside the web root. I attempted to read the SSH private key belonging to the developer user, as SSH credentials could provide a more stable foothold than the container shell.
The request successfully returned the contents of
/home/developer/.ssh/id_rsa, confirming that the path traversal vulnerability allowed arbitrary file reads across the filesystem, including highly sensitive user data. Recovering the developer's private SSH key provided a potential authentication method to access the host directly, making it the next step in the attack chain.SSH Key Preparation
After retrieving the developer's private SSH key through the path traversal vulnerability, I saved it to a local file on my attacking machine. I then updated its permissions to ensure it complied with SSH's strict security requirements before attempting authentication.
With the key stored locally and its permissions restricted to
600, it was ready for use with the SSH client. I then attempted to authenticate to the target as the developer user using the recovered private key.SSH Authentication
With the recovered private key prepared, I attempted to authenticate to the target over SSH as the developer user. After verifying and accepting the server's host key fingerprint, the connection was successfully established using key-based authentication.
The login completed successfully, granting me an interactive shell as
developer on the underlying Debian host. This confirmed that the SSH private key obtained through the path traversal vulnerability was valid and allowed me to pivot from the restricted container environment to direct access on the host system.Host Enumeration
After authenticating as developer, I verified my access by checking the current user, privileges, hostname, working directory, and listening services. This provided a baseline understanding of the host environment before continuing with post-exploitation enumeration.
The output confirmed that I had an interactive shell as the
developer user on the bedside host. It also revealed that an esm.sh process was listening on port 3000, confirming that the internal React development service originated from the host rather than the container and highlighting it as an important component for further investigation.Sudo Privilege Enumeration
After confirming my access to the host, I enumerated the user's sudo privileges to identify commands that could be executed with elevated permissions. This is a standard post-exploitation step that often reveals misconfigured administrative scripts or binaries.
The output showed that the
developer user could execute /usr/bin/python3 /opt/trainer/bedside_trainer.py as root without providing a password. This immediately became the primary privilege escalation target, so I proceeded to analyze the Python script for insecure functionality that could be abused to obtain root access.User Flag
After obtaining a shell as the developer user, I enumerated the contents of the home directory to locate any interesting files. As expected on a Hack The Box machine, the user flag was present and ready to be retrieved.
The home directory contained the
user.txt file, which I read to obtain the user flag, confirming successful compromise of the developer account before proceeding with privilege escalation to root.Sudo Script Analysis
After identifying the custom Python script as my primary privilege escalation target, I reviewed its source code to understand its functionality and look for insecure behavior. Since the script would execute as root, any unsafe handling of user-controlled input could potentially lead to full system compromise.
The script processes files from the
/datastore directories, automatically promotes files from staging to processed, and resumes training by loading the latest PyTorch checkpoint from /datastore/checkpoints using MONAI's CheckpointLoader. Because loading PyTorch checkpoints involves deserializing trusted objects, I focused my attention on the checkpoint-loading functionality as the most promising avenue for privilege escalation.Permission Enumeration
Since the training script relied on the /datastore/checkpoints directory, I verified whether I could access or modify its contents as the developer user. If write access were available, I could potentially place a malicious checkpoint for the root-owned training script to load.
All three operations returned
Permission denied, confirming that the developer account could neither view nor write to the checkpoint directory. This ruled out a direct checkpoint injection attack, so I continued searching for another writable location or alternative way to influence the training process.Dependency Enumeration
Since the training script relied heavily on PyTorch for loading model checkpoints, I verified the installed version of the library. Identifying the exact version would help determine whether any known deserialization behavior or security issues could be leveraged during the checkpoint loading process.
The output confirmed that the system was running PyTorch 2.5.0+cpu, with MONAI installed as a dependent package. Knowing the exact PyTorch version allowed me to research its checkpoint deserialization behavior and assess whether the training script's use of
torch.load() could be abused for privilege escalation.Datastore Permission Manipulation
After discovering that the developer account could not access the checkpoint directory, I returned to the datawrangler shell inside the container to inspect the datastore permissions. I created a small dummy image to satisfy the training script's data requirements, then modified the permissions on the datastore and checkpoint directory to determine whether they could be made writable.
The permissions were successfully updated, leaving
/datastore/checkpoints world-writable (777). Since the root-owned training script automatically loads the latest checkpoint from this directory, this configuration opened the door to placing a crafted checkpoint that would later be deserialized with root privileges.Checkpoint Preparation
After modifying the datastore permissions from the container, I returned to the developer account to verify that the checkpoint directory had become writable. Once I confirmed I could create and remove files inside the directory, I prepared a custom PyTorch checkpoint that would be consumed by the root-owned training script during its checkpoint loading routine.
The successful creation of the checkpoint confirmed that I could place arbitrary checkpoint files in
/datastore/checkpoints. Because the privileged training script automatically loads the latest checkpoint when executed with sudo, this became the key primitive for the final privilege escalation step.Checkpoint Verification
Before executing the privileged training script, I verified that the newly created checkpoint had been written successfully to the checkpoint directory. I also updated its modification timestamp to ensure it would be recognized as the most recent checkpoint during the script's startup routine.
The output confirmed that the checkpoint file existed and was owned by the
developer user. Refreshing its timestamp ensured it would be selected as the latest checkpoint, making it the file processed when the root-owned training script resumed from its saved state.Privilege Escalation
With the checkpoint in place, I started a Netcat listener on my attacking machine and executed the privileged training script using the developer account. As the script initialized, it detected the latest checkpoint and attempted to resume training by loading it with MONAI's CheckpointLoader.
On the attacker machine (Kali Linux), I set up a netcat listener at port 5555:
On the target machine, I ran:
As soon as the checkpoint was loaded, the deserialization process executed with root privileges, and a reverse shell connected back to my listener.
This successfully elevated my access from the
developer account to a root shell, completing the privilege escalation chain.Root Flag
After receiving the reverse shell, I verified that the privilege escalation had succeeded by checking my user ID. I then navigated to the root user's home directory to enumerate its contents and retrieve the final flag.
The output confirmed that I was running as
root (uid=0), giving me unrestricted access to the system. I successfully read root.txt, obtaining the root flag and completing the compromise of the target machine.
Keywords:
bedside.htb
BedSide - HackTheBox
I just solved BedSide from Hack the Box
BedSide Hack the Box Writeup
Bedside Hack the Box Walkthrough
bedside htb write up
bedside htb walkthrough
HackTheBox - BedSide htb Season 11 machine complete walkthrough
bedside htb machine user flag
bedside hack the box machine root flag
Bedside - HTB Writeup
research.bedside.htb
Bedside - HTB Walkthrough
DanglingTree - HackTheBox
danglingtree htb walkthrough
danglingtree htb writeup
I just solved DanglingTree from HackTheBox
DanglingTree - HTB Writeup
HackTheBox - DanglingTree Season 11 Complete Walkthrough
Checkpoint - HTB Walkthrough
HackTheBox - Checkpoint Writeup
I just solved Checkpoint from Hack the Box
Owned Checkpoint from Hack The Box!
Checkpoint - HackTheBox Writeup
Solved Checkpoint on HackTheBox!
Mastering Checkpoint: Beginner's Guide from Hack The Box
HTB Checkpoint Owned: Windows AD Box Challenge
Checkpoint HTB Writeup Premium
Checkpoint Writeup - HackTheBox
HackTheBox Checkpoint walkthrough
I just solved Checkpoint on @hackthebox_eu!
Owned Checkpoint on Hack The Box - Season 11. OS: Windows | Difficulty: Medium
HTB: Checkpoint Writeup
[HackTheBox] "Checkpoint"
HTB Checkpoint Walkthrough
Owned Checkpoint from Hack The Box!
0 Comments