If you find my Hack The Box walkthroughs helpful and they save you time or help you learn something new, consider buying me a coffee.
Your support helps me stay motivated and continue creating free walkthroughs and security content for the community. No pressure at all - just knowing you find the content useful already means a lot!
About the Machine
Giveback is a Medium difficulty Linux machine that demonstrates a multi-stage attack chain involving web exploitation, Kubernetes misconfigurations, and container privilege escalation.
The compromise began with enumeration of a WordPress application where a vulnerable GiveWP plugin was identified. Exploiting a PHP Object Injection vulnerability (CVE-2024-5932) allowed unauthenticated remote code execution, providing an initial foothold on the server. Post-exploitation enumeration revealed sensitive credentials within application configuration files, which enabled pivoting into an internal service and gaining a more stable shell.
Further investigation exposed Kubernetes service account tokens mounted inside the container. By abusing excessive permissions, I extracted cluster secrets and recovered user credentials, which allowed SSH access to the host system. Privilege escalation was achieved by abusing a misconfigured container debug wrapper, ultimately bypassing mount restrictions using symbolic links to access the host filesystem and obtain root privileges.
This machine highlights real-world attack techniques involving WordPress plugin vulnerabilities, secret management failures, container breakout strategies, and Kubernetes security weaknesses.
The first step in owning the Giveback 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:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Giveback machine and I was assigned an IP address (10.129.1.144).
Nmap Enumeration
To begin enumeration, I performed a service and version scan against the target host to identify exposed services and potential attack vectors. I ran the following Nmap command:
I used -sC to execute Nmap’s default enumeration scripts, -sV to identify service versions, and -A to enable aggressive detection, which includes OS fingerprinting, script scanning, and traceroute functionality.
The scan confirmed that the host was reachable and responding. Out of the 1000 default TCP ports scanned, only two ports were open, significantly reducing the external attack surface.
Port 22/tcp was open and running OpenSSH 8.9p1 on an Ubuntu system. From this result, I confirmed that SSH remote access was enabled on the target. The scan also returned ECDSA and ED25519 host keys, verifying the service configuration. Since SSH commonly requires valid credentials, I noted this service as a potential access vector that could be leveraged later if credentials were obtained from another source.
Port 80/tcp was open and running Nginx 1.28.0, hosting an HTTP web service. The enumeration scripts identified that the website was powered by WordPress 6.8.1, which immediately suggested a larger attack surface due to potential vulnerabilities in WordPress core components, plugins, or themes.
While reviewing the HTTP enumeration results, I observed that the robots.txt file contained a disallowed entry for /wp-admin/. This typically indicates the presence of the WordPress administrative login panel. Additionally, the page title confirmed that the server was hosting a live WordPress site.
Based on these findings, I identified the web application running on port 80 as the most promising initial attack vector, while keeping SSH in mind as a potential access method if credentials were discovered during further enumeration.
Hostname Configuration
To simplify interaction with the target and ensure proper virtual host resolution, I added the target IP address to my local hosts file. I ran the following command:
I used this command to map the IP address 10.129.1.144 to the hostname giveback.htb. The tee -a option appends the entry to the /etc/hosts file without overwriting existing records. Since modifying this file requires elevated privileges, I authenticated using sudo.
Adding this mapping allowed me to access the target using the domain name giveback.htb instead of the raw IP address. This step is particularly important when interacting with web applications that rely on virtual host routing or domain-based configurations. Using the correct hostname helps ensure that the web server responds with the intended content and prevents potential enumeration issues caused by accessing the service directly via IP address.
Web Content Enumeration
After confirming that the target was hosting a WordPress application, I proceeded with directory and file brute forcing to identify hidden endpoints, administrative panels, and potential functionality that might not be directly linked from the main website. I ran the following command:
I used DirBuster to brute-force common directories and files using its built-in wordlists. This approach helps reveal application endpoints that could expose sensitive functionality or additional attack vectors.
During enumeration, I identified several interesting files and directories. The scan discovered multiple PHP files, including /login.php, /warez.php, /2006.php, and /2024/09/serial.php. The /login.php endpoint returned a 302 redirect, which typically indicates an authentication-related page or redirection to another login workflow. This immediately stood out as a potential entry point for credential-based attacks or further authentication enumeration.
The files /warez.php and /2006.php returned 503 status codes, suggesting that the resources may exist but are currently unavailable or restricted by the server. Additionally, DirBuster reported inconsistent responses between HEAD and GET requests for these files, which could indicate backend filtering, rate limiting, or conditional access controls. I made note of these endpoints for further manual investigation.
The enumeration also revealed several directories consistent with WordPress content structures. I discovered directories such as /donor-dashboard/, /donation-confirmation/, and /donation-failed/. The presence of /donor-dashboard/ was particularly interesting, as it suggested the existence of authenticated user functionality related to donations or account management. Such dashboards frequently contain sensitive features or role-based access controls that can sometimes be bypassed.
Additional directories, including /2024/, /2024/09/, and /2024/09/21/hello-world/, appeared to follow WordPress post and archive structures. These findings confirmed that the website was actively using WordPress content management features.
The scan also identified /rss/ and /login/ directories, both returning redirect responses. Redirect behavior in WordPress often indicates dynamically generated endpoints or alternate authentication routes, which may provide additional opportunities for enumeration.
Overall, the directory brute forcing results revealed multiple authentication-related endpoints, user dashboard functionality, and several potentially restricted PHP files. Based on these findings, I prioritized further investigation of the login functionality and the donor dashboard, as they appeared most likely to expose authentication or authorization weaknesses.
WordPress Version Enumeration
To confirm the exact WordPress version running on the target, I manually inspected the webpage source code for generator metadata. Instead of loading the page in a browser, I requested the page content directly from the server and filtered the output for WordPress version information using the following command:
I used curl to retrieve the HTML source of the homepage and piped the output into grep to search specifically for lines containing WordPress generator tags. This technique allows me to quickly extract version information without manually reviewing large amounts of HTML content.
The response revealed the following metadata entry:
From this result, I confirmed that the target web application was running WordPress version 6.8.1. Identifying the exact version is important because it allows me to research known vulnerabilities, plugin compatibility issues, and publicly disclosed exploits associated with that release.
Although WordPress core is frequently updated and hardened, version disclosure significantly improves targeted enumeration efforts. With the version confirmed, I planned to continue assessing installed plugins, themes, and authentication mechanisms, as these components are often more likely to contain exploitable vulnerabilities than the WordPress core itself.
Web Technology Fingerprinting
To gather additional information about the technologies powering the web application, I performed fingerprinting against the target website using WhatWeb. I ran the following command:
I used WhatWeb to identify web technologies, frameworks, plugins, and server-side components that could expand the attack surface or provide insight into potential vulnerabilities.
The scan confirmed that the server responded with an HTTP 200 OK status, indicating that the website was accessible and functioning normally. The results showed that the web server was running Nginx 1.28.0, which aligned with the earlier Nmap findings.
The fingerprinting also confirmed that the application was running WordPress 6.8.1, further validating the version information I had previously obtained through manual enumeration. In addition to the WordPress core, WhatWeb identified the presence of the Give v3.14.0 plugin. This discovery was particularly interesting because donation management plugins often handle user accounts, payment workflows, and sensitive data, which can introduce additional vulnerabilities if improperly configured or outdated.
The scan also revealed that the website was using Bootstrap 0.3 for frontend styling and jQuery 3.7.1 for client-side scripting. While frontend frameworks are not always directly exploitable, they can sometimes expose client-side vulnerabilities or assist in understanding the structure and behavior of the web application.
The page title confirmed that the site was hosting the donation-themed platform, consistent with earlier observations. WhatWeb also detected uncommon HTTP headers and scripting elements, which further confirmed that the site relied on standard WordPress dynamic content generation.
Based on these findings, I identified the Give plugin as a particularly valuable target for further investigation, as third-party WordPress plugins frequently introduce exploitable vulnerabilities and often provide additional authentication or user interaction features.
Vulnerable Endpoint Discovery
During technology fingerprinting, I identified that the web application was running the GiveWP plugin version 3.14.0. While researching this plugin version, I discovered that it is affected by CVE-2024-5932, a critical vulnerability that allows unauthenticated PHP Object Injection, which can ultimately lead to Remote Code Execution (RCE). This finding indicated that the GiveWP plugin was likely to be the primary attack vector.
While manually browsing the website to locate donation-related functionality tied to the plugin, I navigated through several available pages and discovered the following endpoint:
This page appeared to host an active donation form powered by the GiveWP plugin.
Donation Form Enumeration
Upon accessing this endpoint, I observed a donation interface that allowed users to submit payment amounts using predefined options or a custom amount field. The page also displayed indicators such as “100% Secure Donation”, suggesting that it handled user-submitted data and potentially backend processing through the vulnerable plugin components.
Since GiveWP manages donation workflows, user input, and serialized data handling, forms like this are commonly tied directly to backend processing logic. Given the presence of CVE-2024-5932, donation forms became a high-value target because PHP Object Injection vulnerabilities are often triggered through improperly sanitized serialized input passed through form submissions or AJAX requests.
The discovery of this donation endpoint confirmed that the vulnerable plugin functionality was actively exposed to unauthenticated users. At this stage, I focused my efforts on analyzing how this form processed input and identifying potential parameters or request flows that could be leveraged to trigger the object injection vulnerability.
Exploit Acquisition
After confirming that the target was running a vulnerable version of the GiveWP plugin, I searched for publicly available proof-of-concept exploits related to the identified vulnerability. During this research, I located a GitHub repository containing an exploit script associated with the vulnerability. To obtain the exploit locally, I ran the following command:
I used git clone to download the repository from GitHub directly into my working directory. The output confirmed that the repository was successfully cloned, including all exploit files and supporting resources required to interact with the vulnerable plugin functionality.
Having access to a public exploit repository allowed me to review the exploit logic, understand how the vulnerability was triggered, and adapt the script to match the target environment. In CTF scenarios, reviewing exploit code is an important step, as it often reveals required parameters, request structures, or payload formats needed to successfully exploit the vulnerability.
With the exploit source code downloaded, I proceeded to analyze its contents and prepare it for testing against the target donation endpoint.
Exploit Environment Preparation
After obtaining the public exploit repository, I prepared a controlled Python environment to safely execute and manage the exploit dependencies. To avoid conflicts with system-wide Python packages and ensure reproducibility, I created a virtual environment using the following command:
I used this command to create an isolated Python environment named venv, which allows me to install required libraries without affecting the global system configuration.
After creating the environment, I activated it to begin installing the exploit dependencies:
Once the virtual environment was activated, I installed the Python libraries required by the exploit script. I first installed the Faker library:
The Faker library is commonly used to generate randomized data such as names, email addresses, and user details. Based on the exploit context, I anticipated that the script would use Faker to generate realistic donation data or payload inputs to interact with the GiveWP form functionality.
Next, I installed the rich_click dependency:
This package enhances command-line interface output by providing formatted and structured terminal interaction. Expl. scripts frequently use this library to improve usability and display exploit execution results in a readable format.
Finally, I installed the requests library:
The Requests library enables HTTP communication with web applications and is widely used in exploit development to craft and send custom HTTP requests. Since the GiveWP vulnerability likely requires interaction with web endpoints or AJAX request handlers, this dependency was essential for the exploit to function correctly.
After installing all required dependencies, the exploit environment was fully prepared, allowing me to safely execute and test the exploit script against the vulnerable donation endpoint.
Exploitation - Remote Code Execution via GiveWP
After preparing the exploit environment and identifying a vulnerable donation form, I attempted to gain remote code execution by leveraging the GiveWP PHP Object Injection vulnerability.
To receive a reverse shell from the target, I first set up a Netcat listener on my attacking machine:
I used this listener to wait for an incoming connection from the target once the exploit payload was executed.
Next, inside the prepared Python virtual environment, I executed the exploit script and supplied the vulnerable donation endpoint along with a reverse shell payload:
I used the -u option to specify the target donation form endpoint and the -c option to provide a Bash reverse shell command that would connect back to my Netcat listener.
Exploit Execution
When the exploit script started, it automatically enumerated available donation forms exposed by the GiveWP plugin. The script returned a list of forms and prompted me to select one. I selected form ID 17, which corresponded to the donation page I had previously identified.
The exploit then successfully retrieved a valid nonce value, which is required by WordPress to validate legitimate form submissions. Obtaining this nonce confirmed that the exploit script was able to interact correctly with the donation workflow.
The script then crafted a malicious serialized PHP object and embedded it inside donation form parameters such as give_title. This payload abused the vulnerable deserialization process within GiveWP, allowing the injection of a PHP object containing a POP chain. The payload ultimately invoked the shell_exec function, executing the reverse shell command I supplied.
After submitting the malicious donation request, the exploit triggered server-side processing of the payload.
Reverse Shell Access
Shortly after running the exploit, I received an incoming connection on my Netcat listener:
The connection originated from the target host, confirming successful remote code execution. I was dropped into a shell running within the WordPress environment:
Although the shell was initially non-interactive and displayed standard TTY warnings, it provided command execution capability on the target system. The shell confirmed that I had gained access to the WordPress server directory, specifically within the administrative web application context.
This successful exploitation demonstrated that the GiveWP plugin vulnerability allowed unauthenticated attackers to execute arbitrary system commands, providing an initial foothold on the target machine.
Credential Discovery
After gaining initial shell access on the target system, I began enumerating sensitive configuration files that could contain credentials or system information. Since the shell indicated that I was operating within the WordPress environment, I searched for the main WordPress configuration file and executed the following command:
I used this command to read the contents of the wp-config.php file, which is a critical WordPress configuration file that typically stores database connection details, authentication keys, and environment settings.
Database Credential Extraction
Reviewing the file contents revealed the database configuration used by the WordPress application. I identified the following credentials:
- Database Name:
bitnami_wordpress - Database User:
bn_wordpress - Database Password:
sW5sp4spa3u7RLyetrekE4oS - Database Host:
beta-vino-wp-mariadb:3306
These credentials confirmed that the WordPress application was connected to a MariaDB database running on an internal service. Extracting database credentials is a valuable step during post-exploitation because they often provide access to stored user data, password hashes, and potentially reusable credentials for system accounts.
Additional Sensitive Information
While reviewing the configuration file, I also identified multiple authentication keys and salts used by WordPress to secure user sessions and cookies. Although these values are primarily used for application-level security, exposure of these keys could allow attackers to forge session tokens or bypass authentication mechanisms under certain conditions.
I also noted that the configuration file confirmed the application was deployed using the Bitnami WordPress stack, which helped me better understand the directory structure and service layout of the target environment.
Post-Exploitation Value
The database credentials represented a strong pivot point for further enumeration. In many WordPress environments, credentials stored within the database may be reused across system services or provide access to additional user accounts. Based on this discovery, I planned to attempt database access and credential reuse as part of the privilege escalation process.
Internal Service Exploitation and Shell Upgrade
After extracting database credentials and performing further enumeration on the compromised host, I identified references to an internal service named legacy-intranet-service. Since internal services are often less hardened and not directly exposed externally, I decided to attempt exploitation against it to gain a more stable or privileged shell.
To prepare for a second reverse shell connection, I first set up a Netcat listener on my attacking machine:
I configured this listener to wait for incoming connections from the internal service once the exploit was triggered.
Crafting the Exploit Payload
From the compromised shell, I created a PHP exploit script designed to interact with the internal CGI service. I generated the exploit file using the following command:
This command created a malicious PHP script in the /tmp directory named exploit.php. The script was designed to send a POST request to the internal CGI endpoint while injecting a reverse shell payload.
The payload leveraged PHP CGI configuration overrides by enabling allow_url_include and forcing execution of attacker-controlled input using auto_prepend_file=php://input. This allowed the injected shell command to be executed on the internal service. The reverse shell command used a named pipe technique to establish a persistent interactive connection back to my Netcat listener.
Triggering the Exploit
After creating the exploit script, I attempted to execute it using the following command:
Initially, I did not receive a reverse shell connection. To troubleshoot, I listed the contents of the /tmp directory and discovered that another file named exploit.phpphp had been created. This suggested that the exploit script may have been written or processed incorrectly during execution.
I then executed the newly discovered file:
Reverse Shell Access
Immediately after running the second file, I received a connection on my Netcat listener:
The connection originated from the target host, successfully providing an interactive shell within the internal CGI service environment:
Although the shell displayed standard warnings about TTY control, it provided reliable command execution within the internal web service context. This confirmed that the internal legacy-intranet-service was vulnerable to PHP CGI argument injection, allowing remote command execution through configuration manipulation.
This pivot provided deeper access into the target environment and significantly expanded my post-exploitation capabilities.
Kubernetes Enumeration
After gaining access to the internal CGI service shell, I began performing post-exploitation enumeration to better understand the environment and identify potential privilege escalation vectors. Since the shell indicated that I was operating inside a web service container, I suspected that the application might be running within a containerized infrastructure.
From the shell, I first navigated through the filesystem to locate sensitive runtime directories:
I listed the contents of the /var directory to identify application runtime components:
While reviewing the directory structure, I noticed the presence of a /run directory, which commonly stores runtime secrets, sockets, and service-related data. I navigated into it:
Listing the directory contents revealed several interesting entries, including php-cgi.socket, nginx, and a secrets directory. The presence of a secrets directory strongly suggested that the container was running inside an orchestrated environment, such as Kubernetes.
I navigated into the secrets directory to investigate further:
Inside, I discovered a kubernetes.io directory, confirming that the container was deployed within a Kubernetes cluster. I continued navigating into the service account directory:
Listing the contents revealed three important files:
ca.crt- namespace
- token
These files are automatically mounted inside Kubernetes pods and provide authentication credentials for the pod’s service account. The presence of these files indicated that the container had permissions to communicate with the Kubernetes API server.
Kubernetes API Access Attempt
To test whether the service account token could be used to query the Kubernetes API, I attempted to authenticate using the token and certificate bundle with the following command:
I used the --cacert option to supply the Kubernetes cluster certificate authority and passed the service account token within the Authorization header. This request attempted to access the Kubernetes API server from inside the container.
The API responded with a 403 Forbidden error, indicating that the service account named secret-reader-sa did not have sufficient permissions to access the requested API path. Although the request was denied, the response confirmed that the token was valid and successfully authenticated against the cluster.
Enumeration Outcome
This discovery confirmed that the compromised container was running inside a Kubernetes environment and that the application was using a service account with limited privileges. Even though direct API access was restricted, service account tokens are valuable targets during container exploitation because they can sometimes be leveraged to access cluster resources, secrets, or perform lateral movement if misconfigured permissions exist.
At this stage, I noted the service account identity and prepared to continue enumerating Kubernetes-related permissions and accessible resources within the cluster.
Kubernetes Secret Extraction
After confirming that the compromised container was running inside a Kubernetes cluster and that the service account token was valid, I continued enumerating cluster resources to determine whether the service account had access to sensitive data. Since Kubernetes frequently stores credentials and application secrets within secret objects, I attempted to list all secrets within the current namespace using the following command:
I used the service account token for authentication and dynamically retrieved the namespace name from the mounted service account files. This request queried the Kubernetes API for all secrets accessible within the pod’s namespace.
Secret Enumeration Results
The API response successfully returned a list of secret objects, confirming that the service account had permission to read sensitive Kubernetes secrets. Among the returned results, I identified several interesting secrets tied to the deployed WordPress and database infrastructure.
The first secret, beta-vino-wp-mariadb, contained credentials related to the MariaDB database service. The response included encoded values for both the standard database password and the root password. These credentials are typically base64 encoded in Kubernetes secrets, meaning they can be decoded to reveal plaintext passwords.
The second secret, beta-vino-wp-wordpress, contained a WordPress application password. This type of credential is commonly used for administrative access or internal application communication and could potentially allow authentication to the WordPress interface or backend services.
The third and most interesting secret, user-secret-babywyrm, contained a field labeled MASTERPASS. The naming convention suggested that this credential might be tied to a system user or administrative account. The secret was managed through a sealed secret controller, indicating it was intended to securely store sensitive credentials within the cluster.
Post-Exploitation Significance
Accessing Kubernetes secrets is a critical privilege escalation vector because these objects frequently store plaintext credentials for databases, applications, and system users. Since all secret values were base64 encoded rather than encrypted, they could be easily decoded and reused for authentication or lateral movement.
The successful retrieval of these secrets confirmed that the service account assigned to the compromised container had excessive permissions, allowing direct access to sensitive infrastructure credentials. Based on this discovery, I proceeded to decode the retrieved secret values to determine whether they could be used to access additional services or escalate privileges further within the target environment.
Secret Decoding and Credential Recovery
After successfully retrieving Kubernetes secrets, I proceeded to decode the sensitive values that were stored in base64 format. Kubernetes encodes secret data using base64 for storage and transmission, which means the values must be decoded to obtain the original plaintext credentials.
To decode the MASTERPASS value obtained from the user-secret-babywyrm secret, I ran the following command on my attacking machine:
I used the base64 -d option to decode the encoded string. The command returned the plaintext credential:
Credential Significance
The decoded value appeared to be a strong password associated with the babywyrm user account referenced earlier in the Kubernetes secret. Since secrets in Kubernetes environments are often used to store application or system credentials, this password represented a potential pivot point for further privilege escalation or lateral movement within the target infrastructure.
At this stage, I noted the recovered credential and prepared to test it against available services and user accounts to determine whether it could provide elevated access on the target system.
User Access via Credential Reuse
After recovering and decoding the MASTERPASS credential associated with the babywyrm account, I attempted to use the password to authenticate directly to the target system via SSH. Since SSH was previously identified as an exposed service during initial enumeration, it presented a strong candidate for credential reuse testing. I ran the following command from my attacking machine:
When prompted for the password, I supplied the credential that I had extracted and decoded from the Kubernetes secret. The authentication was successful, and I obtained a valid SSH session on the target host.
User Enumeration and Privilege Assessment
After successfully authenticating to the target system via SSH as the babywyrm user, I began performing local enumeration to identify accessible files and evaluate the user’s privilege level.
To inspect the contents of the user’s home directory, I ran the following command:
The directory contained a file named user.txt, which typically contains the user flag in CTF environments. I retrieved its contents using:
The command returned the user flag, confirming successful user-level compromise of the system.
Hurray!!! I got the user flag.
Sudo Privilege Enumeration
After obtaining the user flag, I proceeded to check whether the babywyrm account had elevated privileges by reviewing its sudo permissions. I executed the following command:
The output revealed several important privilege configurations. The system enforced standard sudo security defaults such as environment reset and restricted execution paths. More importantly, the results showed that the babywyrm user was restricted from running all commands with sudo privileges except for a single binary:
Additionally, the configuration included:
This indicated that the user could not run arbitrary commands as root but was explicitly allowed to execute the /opt/debug binary with elevated privileges without requiring a password.
Privilege Escalation Opportunity
The presence of a custom binary with sudo execution rights immediately presented a potential privilege escalation vector. Custom or internally developed binaries often introduce insecure functionality, misconfigurations, or unsafe input handling that can be exploited to execute arbitrary commands with root privileges.
Based on this discovery, I focused my attention on analyzing the /opt/debug binary to determine whether it could be leveraged to escalate privileges to root.
Debug Binary Analysis
After identifying that the babywyrm user had permission to execute the /opt/debug binary with sudo privileges, I proceeded to analyze its functionality to determine whether it could be leveraged for privilege escalation. I started by requesting usage information from the binary using the following command:
When I executed the command, the binary first validated my sudo privileges and then prompted me to enter an administrative password. At this stage, I recalled the database password I had previously discovered during configuration file enumeration using:
Since credentials are often reused across services, I attempted to authenticate using the recovered database password:
The authentication was successful, confirming that the debug binary relied on the same credential. After verification, the binary displayed its available usage options and functionality.
Binary Functionality Review
The help output revealed that /opt/debug was a Restricted runc Debug Wrapper, suggesting that it acted as a wrapper around container runtime operations. The output showed that the binary supported commands for executing container specifications and running container instances.
The available command usage included:
- Executing container specifications
- Running containers by ID
- Accepting optional flags such as logging, root path modification, and debug mode
The presence of options such as --root and the ability to run container specifications indicated that the binary might allow interaction with container runtime configuration files. Since container runtimes frequently operate with elevated privileges, improper validation of user-supplied specifications could allow command execution as root.
Privilege Escalation Potential
The combination of sudo execution rights, credential reuse, and container runtime interaction strongly suggested that the debug binary could be abused to execute arbitrary commands with elevated privileges. Based on these findings, I continued investigating how container specification files were processed by the binary and whether they could be manipulated to gain root access.
Container Specification Abuse Attempt
After reviewing the functionality of the /opt/debug binary and confirming that it acted as a wrapper around container runtime operations, I attempted to abuse its ability to execute user-supplied container specifications. Since the binary allowed execution of OCI (Open Container Initiative) specification files with elevated privileges, I attempted to create a malicious configuration that would read the root flag.
To do this, I created a custom OCI configuration file using the following command:
In this configuration, I defined a container process that would execute /bin/cat /root/root.txt as the root user. I also attempted to mount the host’s /root directory inside the container in read-only mode, which would allow the container process to access the root flag directly.
Next, I created the directory referenced as the container root filesystem:
After preparing the configuration, I attempted to execute the container using the debug binary:
The binary again prompted for the administrative password, which I provided using the credential I had previously discovered. The binary successfully validated my privileges and began processing the container specification.
However, the execution failed with the following error:
Security Control Observation
This error indicated that the debug wrapper included a security restriction that prevented direct mounting of the host’s /root directory. This restriction was likely implemented to prevent straightforward privilege escalation attempts by blocking access to sensitive directories.
Although this initial attempt failed, the error message confirmed that the binary was actively validating mount paths rather than blocking arbitrary container execution entirely. This behavior suggested that the restriction might be bypassed through indirect mounting techniques or alternative filesystem access methods.
Based on this observation, I continued analyzing how mount restrictions were implemented within the debug wrapper and explored alternative approaches to access root-level files.
Privilege Escalation - Mount Restriction Bypass via Symlink
After discovering that the /opt/debug wrapper blocked direct mounting of the host’s /root directory, I began looking for ways to bypass the mount validation checks. Since the wrapper appeared to filter mounts based on direct path references, I attempted to use a symbolic link to indirectly access the host filesystem.
Creating the Symlink Backdoor
To implement this bypass, I created a symbolic link pointing to the root of the host filesystem using the following command:
This created a symlink named backdoor that referenced the entire host filesystem. The intention was to mount this symlink instead of directly referencing /root, thereby bypassing the debug wrapper’s path validation logic.
Crafting the Malicious OCI Configuration
Next, I created a modified OCI container specification designed to mount the symlink and execute commands as the root user. I generated the configuration file using the following command:
This configuration executed a shell command as the root user and attempted to list files within the mounted host filesystem before reading sensitive flag files.
Executing the Debug Wrapper
After preparing the container specification, I executed the debug wrapper using:
I authenticated using the previously recovered administrative password, allowing the container to start successfully. Once the container launched, the payload executed and successfully accessed the host filesystem through the symlink mount. The output confirmed that I had gained visibility into the host’s /root directory. The listing revealed several root-owned configuration files and system scripts.
More importantly, the container execution allowed me to read the root flag file:
Hurray!!! I got the root flag and with that the machine was officially pwned
Conclusion
This attack succeeded because the debug wrapper only restricted direct mounting of sensitive directories but failed to properly validate symbolic links. By mounting a symlink that referenced the host filesystem, I bypassed the intended security restriction and achieved root-level file access.
This vulnerability ultimately allowed me to escalate privileges and complete full system compromise.
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
Found this walkthrough helpful?
Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
Giveback HTB | Giveback Hack the Box Walkthrough | Giveback HTB Machine Solution | Hack the Box Writeups | giveback htb completion writeup walkthrough machine pdf | eighteen htb writeup | eighteen htb | eighteen htb walkthrough | htb eighteen writeup | eighteen writeup | eighteen writeup htb | eighteen walkthrough | htb eighteen | htb eighteen walkthrough | eighteen walkthrough htb | gavel htb | hack the box eighteen | eighteen hackthebox | hackthebox eighteen writeup | eighteen.htb | htb gavel writeup | eighteen machine htb | hackthebox gavel writeup | eighteen hack the box | hack the box eighteen writeup | eighteen hackthebox writeup | gavel writeup | eighteen htb machine | htb "eighteen" | eighteen.htb walkthrough | htb eighteen write up | hack the box eighteen walkthrough | dc01.eighteen.htb | "eighteen" htb writeup | "eighteen.htb" | eighteen write up | gavel htb writeup | eighteen htb write up | htb gavel walkthrough | eighteen writeup hackthebox | signed htb | htb "eighteen" writeup | hackthebox eighteen walkthrough | writeup eighteen | gavel hack the box | pterodactyl htb writeup | pterodactyl htb walkthrough | pterodactyl hack the box write up | pterodactyl hack the box walkthrough | pterodactyl htb solution | overwatch htb writeup | overwatch htb walkthrough | overwatch hack the box writeup | overwatch hack the box walkthrough | overwatch htb write up | overwatch htb solution | airtouch htb writeup | airtouch htb walkthrough | airtouch hack the boxwalkthrough | airtouch hack the box writeup | airtouch htb write up | airtouch htb solution | browsed htb writeup | browsed htb writeup | browsed htb walkthrough | browsed hack the box write up | browsed hack the box walkthrough | browsed htb solution | eloquia htb writeup | eloquia htb walkthrough | eloquia hack the box writeup | eloquia hack the box write up | eloquia hack the box walkthrough | eloquia htb solution | fries htb writeup | fries htb walkthrough | fries hack the box writeup | fries hack the box write up | fries hack the box walkthrough | fries htb solution | cobblestone htb writeup | cobblestone htb walkthrough | cobblestone hack the box writeup | cobblestone hack the box write up | cobblestone hack the box walkthrough | cobblestone htb solution | sorcery htb writeup | sorcery htb walkthrough | sorcery hack the box writeup | sorcery hack the box write up | sorcery hack the box walkthrough | sorcery htb solution | hercules htb writeup | hercules htb walkthrough | hercules hack the box writeup | hercules hack the box write up | hercules hack the box walkthrough | hercules htb solution
0 Comments