Paperwork HTB Writeup Premium

I just solved Paperwork from Hack the Box!

Paperwork Machine Summary

Paperwork is an easy-difficulty Linux machine on Hack The Box that focuses on source code review, command injection, post-exploitation enumeration, Printer Job Language (PJL) abuse, arbitrary file read/write vulnerabilities, SSH key injection, UNIX socket communication, file descriptor leakage, and privilege escalation through insecure daemon design. The machine demonstrates how seemingly isolated vulnerabilities can be chained together to achieve complete system compromise.

The attack begins with Nmap enumeration, which identifies SSH and an Nginx web server, followed by host configuration to resolve the paperwork.htb virtual host. During web enumeration, an exposed application archive is discovered and downloaded for offline analysis. After archive extraction, reviewing the application's source code reveals an unsafe use of subprocess.Popen() with shell=True, leading to source code analysis that identifies a command injection vulnerability. By exploiting the LPD service, a crafted print job triggers remote code execution and provides an initial shell on the target.

Following initial access, the shell is upgraded through shell stabilization, after which initial user enumeration is performed to identify accessible users and directories. The session is temporarily suspended through shell backgrounding before being restored with a fully interactive terminal using a second shell stabilization step. Internal service enumeration uncovers services bound to the loopback interface, while internal port verification confirms that an internal printer service is reachable on port 9100.

Further investigation through PJL service enumeration reveals that the printer service exposes a virtual filesystem. To automate interaction with the service, a custom utility is developed during developing a PJL file read script, which exploits directory traversal to achieve arbitrary file read via PJL. Sensitive files such as /etc/passwd are retrieved to enumerate local users. Anticipating SSH access, SSH key generation is performed on the attacker's machine, followed by transferring the SSH public key to the compromised host and verifying the transferred SSH key.

A second custom utility is created during developing a PJL file write script, allowing arbitrary file uploads through the vulnerable PJL service. By writing the SSH public key into the target user's authorized_keys file, SSH authentication is established, enabling SSH authentication as archivist without requiring a password. After gaining stable access, user enumeration confirms successful compromise of the user account and retrieval of the user flag.

The privilege escalation phase begins with process enumeration, which identifies a root-owned Python daemon. Subsequent UNIX socket enumeration reveals a management socket accessible by the compromised user. Analysis of the daemon's source code leads to developing the file descriptor leak exploit, which is then prepared during preparing the file descriptor leak exploit. By exploiting the file descriptor leak, privileged file descriptors are recovered through SCM_RIGHTS, exposing sensitive configuration files and revealing the administrator password. Finally, after triggering the daemon to activate its forensic response, the recovered credentials are used for privilege escalation, resulting in full root access and successful retrieval of the root flag.

Protected Page

The first step in owning the Paperwork 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 Paperwork machine and I was assigned an IP address (10.129.36.72).

Nmap Enumeration

I began by running an Nmap scan to identify the exposed services, operating system, and software versions on the target. This gave me an initial understanding of the attack surface and helped me determine which services were worth investigating further.

The scan revealed two open ports: SSH (22) running OpenSSH 10.0p2 on Ubuntu and HTTP (80) served by Nginx 1.28.0. I also noticed that the web server automatically redirected requests to paperwork.htb, indicating that a virtual host was in use. Based on this, I planned to add the hostname to my local hosts file before continuing with web enumeration.

Host Configuration

After discovering that the web server redirected requests to paperwork.htb, I configured my local machine to resolve the hostname correctly. This ensured that all requests were sent using the expected virtual host, allowing me to interact with the web application as intended.

With the hostname mapped to the target IP address, I authenticated future HTTP requests against the correct virtual host and prepared the environment for further web enumeration and application testing.

Web Enumeration

After configuring the virtual host, I opened my browser and navigated to http://paperwork.htb to begin enumerating the web application. The landing page exposed an internal document intake portal and referenced an archive named paperwork-archive-v1.02, which appeared to be available for download.

The archive looked like a potential source of sensitive information, so I downloaded paperwork-archive-v1.02.zip for offline analysis. I planned to inspect its contents for source code, configuration files, credentials, or other artifacts that could help advance the attack.

Archive Extraction

After downloading the archive, I moved it to my working directory to keep all files for the machine organized in one location. I then extracted the archive to inspect its contents and identify any files that could reveal application logic or potential vulnerabilities.

The extraction produced a single file named server.py, indicating that the archive contained the application's server-side source code. Since source code often exposes hidden functionality, hardcoded credentials, or insecure implementations, I proceeded to analyze server.py in detail.

Source Code Analysis

I inspected the extracted server.py file to understand how the archive service processed print jobs and to identify any insecure functionality. During the review, I noticed that the application extracted the job name from user-supplied input before passing it to a shell command.

The use of subprocess.Popen() with shell=True immediately caught my attention because it executes commands through the system shell. Since job_name originated from client-controlled data and was inserted directly into the command without sanitization, I suspected that it could be abused for OS command injection, making this functionality a likely entry point for remote code execution.

Exploiting the LPD Service

Based on the insecure use of subprocess.Popen() with shell=True, I created a Python exploit to inject a malicious job name into the LPD service. The exploit submitted a crafted print job that executed my payload and connected back to my attacking machine.

Before executing the exploit, I started a Netcat listener to wait for the incoming reverse shell connection.

Finally, I executed the exploit, and within a few seconds the target connected back to my listener. This confirmed that the command injection was successful, giving me an interactive shell on the target as the lp user.

Output:

Shell Stabilization

After obtaining the initial reverse shell, I stabilized it to make command execution more reliable. Upgrading the shell to a fully interactive Bash session allowed me to use terminal features more comfortably during post-exploitation.

Once the shell was stabilized, I enumerated the current working directory to understand the application layout. The directory contained the previously analyzed server.py file, confirming that I had gained access to the LPD server's installation directory.

Initial User Enumeration

After gaining a stable shell, I began enumerating the system to identify accessible user accounts and locate potential targets for privilege escalation. I navigated to the /home directory to inspect the available user home directories.

The enumeration revealed a single user named archivist, but my current lp account did not have permission to access the user's home directory. This indicated that I would need to identify another path for lateral movement or privilege escalation before I could access the user's files.

Shell Backgrounding

After completing my initial enumeration, I temporarily suspended the reverse shell to return to my local terminal. This allowed me to perform additional actions on my attacking machine, such as configuring the terminal, transferring files, or preparing the next stage of the attack, without terminating the existing shell session.

The Netcat process was suspended rather than closed, preserving the active connection to the target. I could later resume the session from my local terminal and continue interacting with the compromised host.

Shell Stabilization

To fully stabilize the reverse shell, I resumed the suspended Netcat session after configuring my local terminal to operate in raw mode. This restored interactive terminal functionality, allowing me to use features such as command history, tab completion, and keyboard shortcuts.

Once the session was restored, I set the TERM environment variable to xterm so terminal-based applications would render correctly and behave as expected during further enumeration.

Internal Service Enumeration

After stabilizing my shell, I enumerated the listening network services to identify internal applications that were not exposed during the initial Nmap scan. This is a useful post-exploitation step because locally bound services often provide additional attack vectors.

The output confirmed that the vulnerable LPD service was running on port 1515 under a python3 process. More importantly, I identified two services listening only on localhost - 127.0.0.1:1337 and 127.0.0.1:9100 - which were inaccessible externally and became my next targets for further enumeration and potential privilege escalation.

Internal Port Verification

I attempted to interact with the internal service listening on 127.0.0.1:9100 using Netcat, but the utility was not installed on the target. To work around this limitation, I used a short Python script to create a TCP connection to the service instead.

The successful connection confirmed that the service on port 9100 was active and accepting local connections. Since it was bound only to the loopback interface, I decided to investigate it further as a potential avenue for lateral movement or privilege escalation.

PJL Service Enumeration

After confirming that the service on 127.0.0.1:9100 was reachable, I interacted with it by sending a Printer Job Language (PJL) command using a short Python script. My goal was to enumerate the contents exposed by the printer service and determine whether it leaked any useful files.

The response revealed a directory listing containing a logs directory and a file named jetdirect.py. This confirmed that the PJL service exposed a virtual filesystem, making it a promising target for further enumeration and possible extraction of sensitive files.

Developing a PJL File Read Script

To investigate the PJL service further, I created a custom Python script that automated file retrieval using the @PJL FSUPLOAD command. The script accepted a file path as input, established a connection to the local printer service, and requested the contents of the specified file.

The script also constructed a directory traversal path to reach files outside the printer's virtual filesystem and parsed the server's response to determine the file size before downloading its contents. With this utility in place, I was ready to read arbitrary files exposed through the vulnerable PJL service.

Arbitrary File Read via PJL

With the PJL file-read script ready, I began enumerating sensitive files on the system to verify the impact of the vulnerability. I first retrieved /etc/passwd to enumerate local user accounts before focusing on the archivist user discovered earlier.

The file read succeeded, confirming that the PJL service allowed arbitrary file access through directory traversal. The output identified archivist as a valid local user, while the empty authorized_keys file indicated that no SSH public keys had been configured, prompting me to continue searching for other sensitive files that could lead to user access.

SSH Key Generation

Since I anticipated gaining SSH access to the archivist account, I generated a new Ed25519 SSH key pair on my attacking machine. This provided a public key that I could later place on the target if I found a way to write to the user's authorized_keys file.

The command created both a private key (archivist_key) and its corresponding public key (archivist_key.pub) without a passphrase. I kept these files ready for use in the next stage of the attack, where I planned to establish persistent SSH access.

Transferring the SSH Public Key

To make my SSH public key available to the target, I started a temporary HTTP server on my attacking machine. I then downloaded the public key onto the compromised host using wget, providing a simple way to transfer files without requiring additional tools.

On the attacker machine, I ran:

On the target machine, I ran:

The download completed successfully, and the HTTP server logs confirmed that the target retrieved the file from my machine. With the public key now stored in /tmp, I was ready to use it in the next stage to obtain SSH access as the archivist user.

Verifying the Transferred SSH Key

After transferring the public key to the target, I verified its contents to ensure that it had been downloaded correctly and was not corrupted during the transfer. Confirming the key before using it helped avoid authentication issues later in the attack.

The output displayed my Ed25519 public key exactly as expected, confirming that the transfer was successful. With the key verified, I proceeded to use it in the next stage to establish SSH access as the archivist user.

Developing a PJL File Write Script

After confirming that the PJL service allowed arbitrary file reads, I tested whether it also supported writing files to the underlying filesystem. To do this, I created a second Python utility that used the @PJL FSDOWNLOAD command to upload a local file to an arbitrary path on the target.

The script accepted a target path and a local file, established a connection to the PJL service on 127.0.0.1:9100, and uploaded the file using a directory traversal path. With both arbitrary file read and file write capabilities available, I was ready to leverage the vulnerability to gain SSH access as the archivist user.

Writing the SSH Public Key

With the file-write utility in place, I made it executable and used it to upload my public key into /home/archivist/.ssh/authorized_keys. This allowed me to leverage the PJL file-write vulnerability to authorize my own SSH key for the archivist account.

The script returned OK, indicating that the write operation completed successfully. I verified the result by reading the authorized_keys file and confirmed that my public key had been written correctly, allowing me to authenticate to the target as archivist using my corresponding private key.

SSH Access as archivist

After adding my public key to the authorized_keys file, I authenticated to the target over SSH using the corresponding private key. This provided a stable and fully interactive shell, eliminating the limitations of the initial reverse shell.

On the first connection, I accepted the server's host key and successfully logged in as the archivist user. With direct SSH access established, I now had a reliable foothold on the system and could continue privilege escalation from the user's account.

User Enumeration

After successfully authenticating as archivist, I verified my access level and gathered basic information about the compromised account. I also enumerated the user's home directory to identify any interesting files before attempting privilege escalation.

The output confirmed that I had obtained an interactive shell as the archivist user on the paperwork host. The home directory contained the user.txt flag, which I successfully retrieved before continuing with the enumeration for a path to root.

Process Enumeration

After obtaining access as archivist, I began enumerating running processes to identify privileged services that could be abused for privilege escalation. A Python process named paperwork-daemon running as root immediately stood out, so I inspected the script to understand its functionality.

The source code revealed that the daemon opened /etc/paperwork/admin_pins.conf as root and monitored commands.log for PJL-related activity such as FSQUERY, FSUPLOAD, and FSDOWNLOAD. More importantly, I noticed that when malicious activity was detected, the daemon called sendmsg() with SCM_RIGHTS to transfer open file descriptors, including one for the privileged admin_pins.conf file, suggesting a potential path to privilege escalation.

UNIX Socket Enumeration

After identifying the root-owned paperwork-daemon, I continued enumerating its supporting files to understand how it communicated with other components. I discovered a directory under /run/paperwork containing a UNIX domain socket named mgmt.sock.

The socket was owned by root but belonged to the archivist group, and its permissions (srw-rw----) allowed members of that group to communicate with it. Since I was running as archivist, I could access the management socket, making it a promising target for interacting with the privileged daemon and potentially triggering the file descriptor leak I had identified earlier.

Developing the File Descriptor Leak Exploit

After discovering that I could access the daemon's management socket, I created a Python exploit to communicate with it and inspect any resources it exposed. The script connected to the UNIX socket and listened for file descriptors passed through SCM_RIGHTS, which I had previously identified in the daemon's source code.

The exploit collected any received file descriptors and attempted to read their contents directly. If successful, this would allow me to access files that had been opened by the root-owned daemon, including the privileged /etc/paperwork/admin_pins.conf file, without requiring direct filesystem permissions.

Preparing the File Descriptor Leak Exploit

To test the management socket, I switched to the /tmp directory and recreated my Python exploit there. The script connected to the daemon's UNIX socket, received any file descriptors transferred through SCM_RIGHTS, and attempted to read the contents of the associated files.

By reading the contents of the leaked file descriptors instead of accessing the files directly, I aimed to bypass normal filesystem permissions. If the daemon transferred the descriptor for /etc/paperwork/admin_pins.conf, I would be able to recover its contents despite the file being readable only by root.

Exploiting the File Descriptor Leak

After preparing the exploit, I made it executable and connected to the daemon's management socket to trigger the file descriptor leak. The daemon responded with a forensic alert and transferred the open file descriptors that I had previously identified in the source code.

The first descriptor contained the printer command log, while the second exposed the contents of /etc/paperwork/admin_pins.conf. From this leaked file, I recovered the administrator password ApparelMortuaryCedar22, giving me a valuable credential that I could leverage during the final privilege escalation stage.

Triggering the Daemon

After recovering the administrator password, I reconnected to the target over SSH and prepared to interact with the privileged paperwork-daemon. From reviewing its source code, I knew the daemon monitored the printer log for specific PJL commands, so I manually inserted one of the monitored keywords to trigger its security routine.

By appending FSUPLOAD to commands.log, I deliberately simulated malicious printer activity. This caused the daemon to detect a security violation and execute its forensic response logic, which I leveraged in the next step to continue the privilege escalation process.

Privilege Escalation

After recovering the administrator password from the leaked file descriptor, I authenticated as root using su. The password was accepted immediately, confirming that the credential obtained from admin_pins.conf was valid and granted full administrative access to the system.

The output confirmed that I was now running with UID 0 as the root user. With full privileges obtained, I successfully retrieved the root.txt flag, completing the machine.

Keywords:

paperwork htb walkthrough

paperwork htb writeup

paperwork.htb

HackTheBox - Paperwork Season 11 htb machine complete walkthrough solution

Paperwork Hack the Box Write Up

PaperWork Hack the Box Walkthrough

paperwork-archive-v1.02.zip

Paperwork OS command injection

Paperwork HackTheBox user flag

Paperwork htb root flag season 11 machine writeup

Rooted Paperwork - HackTheBox Season 11 Machine Walkthroughs

Owned Paperwork from HTB

Hack The Box - HTB Paperwork Writeup - Easy - Weekly - July 11th, 2026

checkpoint.htb

Checkpoint HTB Writeup

Checkpoint - HTB Walkthrough

Checkpoint Hack the Box Write Up

Checkpoint Hack the Box Walkthrough

HackTheBox - Checkpoint HTB Season 11 Machine

I just solved Checkpoint from Hack the Box

Rooted Checkpoint from Hack the Box

Pwned Checkpoint - HackTheBox Season 11 HTB Machine

Checkpoint HTB Machine User Flag

Checkpoint - HackTheBox Root Flag Season 11 HTB Machine

enigma htb walkthrough

enigma htb writeup

enigma hack the box walkthrough season 11 htb machine

enigma hack the box writeup

HackTheBox - Enigma Htb Season 11 Complete Walkthrough

enigma htb user flag

HTB Enigma root flag captured

enigma.htb

pingpong.htb

pingpong HackTheBox Season 10 htb complete walkthrough

Season 11 HTB Machine Paperwork - HackTheBox Complete Walkthrough Solution

HTB-Paperwork

enigma-htb

Enigma writeup season 11 HTB

HTB Enigma - Writeup

/mnt/enigma

nfs enigma.htb

Enigma Corp

mail001.enigma.htb

support_001.enigma.htb

Enigma Hack the Box OpenSTAManager Vulnerability

htb-writeup paperwork

http://paperwork.htb

paperwork-archive-v1.02

paperwork-htb season 11 machine hackthebox

archivist (PJL Path Traversal)

archivist - root (SCM_RIGHTS File Descriptor Leak)