EvilCUPS HTB
EvilCUPS HTB Target Overview EvilCUPS is a retired Linux machine from Hack The Box that focuses on exploiting an exposed CUPS (Common UNIX Printing System) service to gain an initial foothold. The attack begins with network enumeration, which reveals a CUPS web interface running on port 631. By abusing the exposed printing service, I was able to register a rogue printer and trigger command execution when a test page was printed. This provided a shell as the low-privileged lp user. During privilege escalation, I discovered that the lp user had traversal permissions over the CUPS spool directory. Although directory listing was restricted, the predictable naming convention used for cached print jobs allowed me to access a previously completed print job directly. The cached document contained what appeared to be a plaintext password. Testing this credential against the root account over SSH was successful, resulting in full root access to the machine. --- Enumeration Nmap Scanning I started the assessment by performing an aggressive Nmap scan against the target to identify exposed ports, services, and available version information. The scan revealed only two exposed TCP ports: | Port | Service | Version | |---|---|---| | 22 | SSH | OpenSSH 9.2p1 | | 631 | IPP / CUPS | CUPS 2.4.2 | SSH did not immediately provide an attack path because I did not yet have credentials. Port 631, however, exposed a CUPS web interface and therefore became the main focus of enumeration. --- Enumerating CUPS on Port 631 Browsing to port 631 revealed the CUPS web interface running version 2.4.2. CUPS, or the Common UNIX Printing System, is commonly used on Linux and Unix-like systems to manage printers and print jobs. From the web interface, I selected the Administration option. This redirected me to the /admin endpoint, but access to the administrative interface was forbidden from my current location. Since the administrative page was restricted, I moved to the Printers section to inspect the printers already configured on the server. A printer named Canon_MB2300_series was present, and its status was shown as idle. I selected the printer by clicking its queue name. The printer information showed that a previous print job had already completed and that the username associated with the job was displayed as Withheld. This confirmed that the CUPS server was actively managing printer queues and had previously processed print jobs. --- Researching the CUPS Service With CUPS 2.4.2 exposed, I researched known vulnerabilities affecting CUPS and its related components. One useful reference covering the attack chain can be found here: Oligo Security - CUPS Vulnerabilities For exploitation, I used the evilcups.py proof-of-concept provided by IppSec: IppSec EvilCUPS GitHub The script is used to create a rogue printer controlled by the attacker and make it available to the target CUPS environment. Its basic usage is: The important arguments are: — My attacker/VPN IP address. — The IP address of the EvilCUPS machine. — The command I want executed when the malicious printer configuration is triggered. For this attack, I supplied a Bash reverse shell as the command. --- Preparing the Reverse Shell Before launching the exploit, I opened another terminal and started a Netcat listener on port 443. The listener would wait for the target machine to connect back if command execution was successfully triggered. --- Creating the Rogue Printer I then executed evilcups.py, supplying my VPN IP address, the target IP address, and the Bash reverse-shell command. The script started an IPP server on my machine and then sent the required packet toward the target CUPS service. After waiting for the script to complete, I returned to the CUPS web interface and opened the Printers section again. This time, two printers were visible. The original Canon_MB2300_series printer was still present, but a new rogue printer had also appeared. The appearance of the second printer confirmed that the malicious printer had successfully been registered with the target. --- Triggering the Malicious Print Job I opened the newly added HACKED... printer. From the available printer actions, I selected: Triggering the print operation caused the malicious printer configuration to be processed. I immediately checked the Netcat listener. The target successfully connected back to my listener. The shell prompt showed: This confirmed that I had achieved remote command execution and obtained an initial shell as the lp user. The messages: were expected because the reverse shell was not attached to a fully interactive terminal. --- User Flag From the lp shell, I was able to access the htb user's home directory. I navigated to /home/htb and read the user flag. With the user flag captured, the next objective was to identify a path to root privileges. --- Privilege Escalation Enumeration I started by examining the environment associated with the lp account. Interestingly, the lp user's current directory was: The only visible file was: Since this location belonged to the CUPS spool hierarchy, I began inspecting the surrounding directories. --- Investigating the CUPS Spool Directory Moving one directory back placed me inside: However, attempting to list its contents failed. This initially appeared to prevent further enumeration. To understand the permissions more clearly, I inspected the CUPS directory from /var/spool. The permissions were: and the ownership was: This was important. The lp group had the execute permission on the directory but did not have read permission. For directories: Read (r) allows listing filenames. Execute (x) allows traversing the directory and accessing an object when its exact filename is already known. Therefore, even though I could not run ls successfully, I could potentially access files directly if I could predict their names. --- Understanding CUPS Cached Print Jobs CUPS stores cached print-job data inside /var/spool/cups. The naming structure for completed print-job data generally follows a predictable pattern such as: For example: Where: d identifies the file as print-job data. 00001 represents the print-job ID. 001 represents the page number. Earlier, the CUPS interface showed only one completed print job associated with the configured Canon_MB2300_series printer. Based on that information, I inferred that the cached print-job file could be: Even though directory listing was blocked, the execute permission on /var/spool/cups allowed me to attempt to access that exact filename directly. --- Reading the Cached Print Job I attempted to read the predicted file: The file existed and was readable. Most of the file contained PostScript data describing the previously printed document. However, one line immediately stood out: strongly resembled a password. Because SSH was exposed on port 22, I decided to test whether this credential belonged to a local account. The string itself also contained the word root, so I tested it against the root user. --- Root Access Through SSH I attempted to authenticate directly as root over SSH. The authentication succeeded. The prompt: confirmed that the credential recovered from the cached print job was the password for the root account. At this point, I had obtained full root-level access to the machine. --- Root Flag Finally, I read the root flag. This completed the machine. --- Attack Path Summary The complete attack path for EvilCUPS was: --- Remediation Guidance Several weaknesses contributed to the successful compromise of the machine. Restrict CUPS Exposure The CUPS service should not be unnecessarily exposed to untrusted networks. Access to port 631 should be restricted using firewall rules so that only authorised management systems and trusted printer networks can communicate with the service. Where remote administration is not required, CUPS should listen only on trusted interfaces or localhost. Patch CUPS Components The CUPS installation and all related printing components should be updated to vendor-supported versions containing the relevant security fixes. Systems should be regularly reviewed for security updates affecting: CUPS cups-browsed IPP-related components Printer drivers and filters Unused printing services should be disabled or completely removed from servers that do not require printing functionality. Restrict Automatic Printer Discovery Automatic discovery and registration of network printers should be disabled unless it is operationally required. Only trusted printing infrastructure should be permitted to advertise printers to the system. Network-level filtering should also prevent untrusted hosts from communicating with printer-discovery services. Protect CUPS Spool Data Cached print jobs may contain highly sensitive information such as: Credentials Internal documents Personal information Confidential business data Permissions on /var/spool/cups and its contents should ensure that low-privileged service accounts cannot access completed print-job data unnecessarily. Print-job retention should also be minimised, and sensitive spool files should be securely deleted after processing when operational requirements allow. Never Print or Store Plaintext Credentials Passwords should never be included in documents sent through shared printing infrastructure. The root password recovered in this attack existed directly inside a cached print job, allowing a low-privileged account to recover it. Administrative credentials should instead be stored using an approved password-management solution. Restrict Root SSH Authentication Direct SSH authentication as root should be disabled. For example, SSH configuration should use: Administrators should authenticate using individual accounts and elevate privileges through controlled mechanisms such as sudo. Password-based SSH authentication should also be disabled where practical in favour of properly managed SSH keys. --- Final Thoughts EvilCUPS demonstrated how a service that may initially appear to be a simple printing interface can become the starting point for complete system compromise. The initial foothold relied on abusing the exposed CUPS environment to register a rogue printer and trigger command execution. This provided access as the low-privileged lp service account. The privilege-escalation stage was particularly interesting because the CUPS spool directory could not be listed directly. However, the lp group still had directory traversal permissions. By understanding the predictable naming convention used for cached CUPS print jobs, I was able to access the previous job directly. That print job contained a plaintext credential, which was ultimately valid for the root account over SSH. The machine reinforced several important lessons: Exposed infrastructure services should always be treated as potential attack surfaces. Printer services can process attacker-controlled data and should be isolated appropriately. Directory permissions must be evaluated beyond simply checking whether ls succeeds. Predictable filenames can allow access even when directory listing is restricted. Print spool data can contain highly sensitive information. Administrative passwords should never appear in printed documents. Direct root authentication should be restricted. See you in the next writeup. Until then, keep enumerating and stay curious. By Madhav