Layover HTB Writeup

I just solved Layover machine from Hack the Box!

Layover Machine Summary

Layover is a medium-difficulty Linux machine on Hack The Box that focuses on network enumeration, wireless traffic analysis, credential extraction, web application exploitation, lateral movement, and Linux privilege escalation.

I began by performing Nmap enumeration to identify exposed services, followed by configuring the target hostname in my local /etc/hosts file. Using the provided contractor credentials, I authenticated through RDP and obtained an initial shell on the airside-ws01 workstation. During local enumeration, I discovered unrestricted sudo permissions, allowing me to escalate privileges to root.

With elevated access, I enumerated nearby wireless networks and connected to the internal HTB International WiFi network. I then configured a wireless interface in monitor mode and captured network traffic using tcpdump and TShark. By analyzing HTTP POST requests, I extracted plaintext credentials belonging to jenny, which provided authenticated access to the airport's Craft CMS administrative dashboard.

Further enumeration of the Craft CMS system report revealed version 5.9.8, along with information about the underlying application stack. I also discovered the database backup functionality, which allowed me to download and analyze an SQL backup containing sensitive mail relay configuration data.

During vulnerability research, I identified CVE-2026-28695 and prepared a Python proof of concept targeting the Craft CMS application. By authenticating with Jenny's credentials and executing the exploit, I established a reverse shell on the internal web server as www-data.

I then enumerated the web server and discovered the application's .env configuration file, which exposed the Craft security key and MySQL database credentials. Using these credentials, I queried the htbairways_settings table and recovered an encrypted mail relay password. I subsequently used Yii's decryptByKey() function with the recovered security key to decrypt the password successfully.

The decrypted credentials allowed me to authenticate over SSH as aporter, providing a user-level shell on the portal server and access to the user flag.

For the final privilege escalation, I enumerated internal listening services and identified CUPS running on port 631. Version enumeration confirmed CUPS 2.4.16, leading me to investigate CVE-2026-34990. Using a public Python proof of concept, I exploited the CUPS service to capture a local authentication token and write a malicious sudoers configuration, granting aporter passwordless sudo privileges.

Finally, I executed sudo -i to obtain a root shell, retrieved the root flag, and successfully completed the machine.

Overall, Layover demonstrates how wireless credential exposure, insecure access to application backups, compromised cryptographic secrets, credential reuse, authenticated remote code execution, and vulnerable local services can be chained together to achieve full system compromise.

Protected Page

asdf

d

e

Nmap Enumeration

I started by running an Nmap scan against the target to identify any open ports, services, and available version information.

The scan revealed that SSH on port 22 was the only exposed TCP service, running OpenSSH 9.6p1 on Ubuntu.

Since no web services or additional ports were available, SSH became the primary entry point for further enumeration.

With the contractor credentials provided at the start of the machine, my next step was to authenticate to the target over SSH.

Hosts File Configuration

I added the target IP address to my local /etc/hosts file and mapped it to the hostname layover.htb.

This allowed me to reference the target using layover.htb instead of repeatedly entering its IP address.
The entry also ensures that any services relying on hostname resolution correctly resolve the domain to the HTB target. With the hostname configured, I could continue my enumeration using layover.htb.

RDP Authentication

I used the provided contractor credentials to authenticate to the target through RDP with FreeRDP.

The warnings simply indicated that supplying the password directly on the command line can expose it through the process list. The authentication succeeded and landed me in the Contractor graphical desktop session. From there, I launched the terminal from the desktop panel to begin enumerating the system from inside the target.

Initial Shell Enumeration

After connecting through RDP, I launched a terminal and obtained a shell as contractor on the airside-ws01 workstation. I ran id to confirm my current user and group memberships.

The output confirmed that I was running as uid=1001(contractor) with several additional group memberships.

Most notably, the account belonged to the sudo and wireshark groups, which immediately stood out as potential privilege-escalation paths. With the initial foothold confirmed, I continued enumerating the permissions available to the contractor account.

Sudo Privilege Enumeration

I ran sudo -l to enumerate which commands the contractor account was permitted to execute with elevated privileges.

After authenticating with the contractor password, the output showed (ALL : ALL) ALL.

This means contractor can execute any command as any user, including root, through sudo. This effectively provides a direct privilege-escalation path, so my next step was to use the sudo access to obtain a root shell.

Root Privilege Escalation

Since sudo -l confirmed unrestricted sudo permissions, I used sudo su - to switch directly to the root account.

The command succeeded and changed my shell from contractor@airside-ws01 to root@airside-ws01.

The - option started a login shell, loading root’s environment and home directory. At this point, I had obtained full root privileges on the workstation and could continue enumerating it without permission restrictions.

Wireless Network Enumeration

After escalating privileges, I ran id to verify that my shell was operating as root, then enumerated nearby wireless networks using the wlan2 interface.

The id output confirmed uid=0(root), verifying successful privilege escalation. The wireless scan revealed an SSID named HTB International WiFi, indicating another network accessible from the compromised workstation. 

This provided a new avenue to investigate for potentially reaching additional systems or network segments.

Connecting to the Internal WiFi

I used nmcli to connect the compromised workstation’s wlan2 interface to the previously discovered HTB International WiFi network.

The connection succeeded, confirming that wlan2 was now associated with the passenger wireless network.

Immediately afterward, the browser launched automatically and redirected me to http://wifi.international.htb/.

This appeared to be a captive portal confirming that I had connected to the airport’s WiFi network.

I clicked Accept & continue to airport portal to proceed through the captive portal.

The browser then redirected me to http://portal.international.htb/, exposing the main HTB International Airport website.

The portal contained flight information, terminal resources, and an HTB Airways Miles section.

I also noticed a Sign in to Miles option, indicating that authenticated functionality was available from this network.

This confirmed that connecting to the wireless network had exposed additional internal web resources that were not previously reachable.

From here, I continued enumerating the portal and its authentication functionality for another potential foothold.

Wireless Packet Capture

I prepared the wlan3 interface for passive wireless monitoring so I could capture traffic from the nearby WiFi network on channel 6.

I first stopped NetworkManager from managing wlan3, then brought the interface down so I could switch it into monitor mode.

I brought the interface back up and explicitly tuned it to channel 6 to capture the relevant 802.11 traffic.

I then ran tcpdump for 180 seconds and saved the complete packet capture to channel6.pcap.

The capture completed with 2,411 packets captured and no packets dropped by the kernel.

This gave me a PCAP containing raw wireless frames that I could inspect offline for useful network activity.

My next step was to analyze channel6.pcap for authentication exchanges, client activity, and other potentially useful information.

Wireless Traffic Capture

I ran tshark on the wlan3 monitor-mode interface to capture wireless traffic directly from channel 6.

The -i wlan3 option selected the wireless interface, while -w saved the captured packets to channel6.pcap.

TShark began capturing live 802.11 traffic and displayed an increasing packet count as frames were collected.

This PCAP could then be analyzed offline to identify interesting wireless clients, protocols, or authentication traffic.

HTTP Credential Extraction

I analyzed the captured traffic with tshark, filtering specifically for HTTP POST requests and extracting submitted form fields.

The capture exposed a login request to portal.international.htb/miles/login.php originating from 10.13.37.132.

Because the credentials were transmitted through unencrypted HTTP, the submitted username and password were visible directly in the packet capture.

I recovered the credentials jenny:Fl1ghtDeck2026!, which I could now test against the HTB Airways Miles portal.

Craft CMS Authentication

I navigated to the administrative login page at http://portal.international.htb/admin/login and tested the credentials recovered from the wireless packet capture.

I authenticated successfully as jenny, confirming that the captured credentials were valid for the administrative interface.

After signing in, the application redirected me to http://portal.international.htb/admin/dashboard.

This provided authenticated access to the backend management panel of the airport portal.

While reviewing the dashboard, I identified the application as Craft CMS.

The version displayed at the bottom of the dashboard was Craft CMS Solo 5.9.8.

Identifying the exact CMS and version was important because it gave me a specific technology stack to investigate further.

I could now focus my enumeration on the functionality available to Jenny’s account and any security issues affecting this Craft CMS release.

System Report Enumeration

After authenticating to Craft CMS, I opened the hamburger menu, navigated to Utilities, and selected System Report to enumerate the application stack.

The report exposed exact versions for the CMS, operating system, database, PHP runtime, and several underlying libraries.

I also confirmed that no Craft CMS plugins were enabled, reducing the likelihood of a plugin-specific attack path.

With these version details identified, I could focus my research on known vulnerabilities affecting the installed Craft CMS and its dependencies.

Database Backup Enumeration

While enumerating the available Craft CMS utilities, I opened Database Backup and found that Jenny’s account had permission to generate and download database backups.

I selected Download backup and generated a new backup directly through the administrative interface.

Craft CMS successfully created a compressed SQL dump and initiated the download through the browser.

Since database backups often contain user records, password hashes, configuration data, and other sensitive information, this file was a valuable target for further analysis.

Database Backup Analysis

I copied the downloaded Craft CMS database backup from airside-ws01 to my local Linux machine using the RDP clipboard, then extracted the archive and began reviewing the SQL dump.

I searched through the database for configuration entries, credentials, secrets, and other sensitive values that could provide another attack path.

While reviewing the dump, I found the htbairways_settings table containing several mail relay configuration values.

The table exposed mailRelayHost as mail.htbairways.htb and mailRelayPort as 587.

I also identified the configured mailRelayUser as aporter.

More importantly, the same table contained a mailRelayPassword entry.

Unlike a normal plaintext password, however, the stored value appeared to be an encoded or encrypted string.

This meant I could not immediately use the value as a credential without determining how the application protected it.

The presence of a dedicated mail relay account was still significant because it revealed another internal service and username.

At this stage, I had the mail server hostname, SMTP submission port, username, and protected password value.

My next objective was to determine how Craft CMS or the application encrypted this setting and whether I could recover the original mail relay password.

Craft CMS Vulnerability Research – CVE-2026-28695

After identifying Craft CMS Solo 5.9.8 during my enumeration, I started researching publicly disclosed vulnerabilities affecting this version.

My research led me to CVE-2026-28695, which appeared to be relevant to the installed Craft CMS release. I then searched GitHub for publicly available exploits and discovered a proof-of-concept repository published by predyy.

I reviewed the repository as a potential exploitation path against the authenticated Craft CMS instance.

Since I already had access to the administrative dashboard using Jenny's credentials, I wanted to determine whether the PoC could be used within my existing session. This was particularly interesting because I had previously recovered a protected mailRelayPassword value from the database backup.

I also wanted to establish whether the vulnerability could provide additional access to the underlying application or server. At this stage, I had identified a promising public exploit, but I still needed to validate its prerequisites and behavior against the target.

My next step was to examine the PoC and determine how it could be applied to the HTB International Airport environment.

Craft CMS RCE Exploit Preparation

I created a Python exploit script named exp.py on the airside-ws01 workstation using nano, based on the public PoC for CVE-2026-28695.

I pasted the Python script into the file, which was designed to exploit a potential authenticated blind Remote Code Execution (RCE) vulnerability in Craft CMS 5.9.8. The script uses requests to authenticate with valid credentials, retrieve CSRF tokens, and maintain an authenticated session. It then constructs a malicious JSON payload targeting the /element-search/search endpoint, using Yii's AttributeTypecastBehavior and ConsoleProcessus::execute gadget chain. Since the exploit is blind, successful command execution would not directly return command output, requiring separate verification. With the script saved, I was ready to test the vulnerability against the authenticated Craft CMS instance.

Craft CMS RCE Exploitation – Reverse Shell

After preparing the Python exploit, I started a Netcat listener on port 4444 from the airside-ws01 workstation to catch the incoming reverse shell.

With the listener running, I executed exp.py using Jenny's credentials and supplied a BusyBox Netcat reverse shell as the command payload.

The exploit successfully authenticated as jenny and submitted the malicious payload to the Craft CMS application. Although the script returned a timeout, this was expected because the reverse shell command maintained an active connection. When I checked my Netcat listener, I noticed an incoming connection from 10.13.37.10 on source port 51224. This confirmed that the target had established a connection back to my workstation on port 4444. The listener provided a shell session, demonstrating successful Remote Code Execution (RCE) through the vulnerable Craft CMS instance. With this foothold established, my next step was to identify the execution context and enumerate the underlying server for further access.

Reverse Shell Verification

After receiving the reverse shell connection from 10.13.37.10, I ran ls to enumerate the contents of the current working directory.

The output revealed several web application files and directories, including index.php, assets, cpresources, and miles. These files suggested that my reverse shell had landed inside the HTB International Airport web application's directory. The presence of index.php and miles also matched the web application I had previously enumerated. With command execution confirmed, I continued investigating the server to identify my current privileges and locate sensitive application files.

Web Server Enumeration

After obtaining the reverse shell, I ran several commands to identify my current user, working directory, and available files on the compromised server.

The output confirmed that I was operating as www-data (UID 33) inside /var/www/portal/web, the web root of the airport portal. I also confirmed that the shell belonged to the web server's service account rather than a privileged system user. The directory listing revealed application files such as index.php, .htaccess, assets, cpresources, and miles. With the web server foothold confirmed, I continued enumerating the application directories for sensitive configuration files, credentials, and potential privilege-escalation opportunities.

Craft CMS Configuration Enumeration

I navigated to the main Craft CMS application directory at /var/www/portal to investigate files outside the publicly accessible web root.

The directory listing revealed several important application files, including .env, composer.json, config, storage, and vendor. The .env file immediately caught my attention because it was readable by www-data and could contain sensitive application credentials. I also identified the config directory, which could provide additional information about the application's database connections and security settings. With access to the application's root directory, my next step was to inspect the .env file for secrets that could help me progress further.

Craft CMS Environment File Enumeration

I inspected the .env file in the Craft CMS application directory to identify sensitive configuration settings and potentially reusable credentials.

The file exposed the CRAFT_SECURITY_KEY, which is used by Craft CMS for security-related cryptographic operations. I also recovered the MySQL database credentials: craftuser:CraftDB_pw_2026, connecting to the local craft database on port 3306. Additionally, I confirmed that the application was running in production mode with debugging disabled and the Twig sandbox enabled. The exposed security key was particularly interesting because it could potentially help decrypt the protected mailRelayPassword value I had previously discovered in the database backup.

MySQL Database Enumeration

Using the database credentials recovered from the .env file, I authenticated to the local MySQL database as craftuser and queried the htbairways_settings table.

The query revealed the mail relay configuration, including mail.htbairways.htb on port 587 and the username aporter. I also recovered the same encrypted mailRelayPassword value previously identified in the Craft CMS database backup. With the CRAFT_SECURITY_KEY now available from the .env file, I had a potential way to decrypt the stored password. My next step was to investigate Craft CMS encryption and attempt to recover the plaintext mail relay credentials.

Craft CMS Mail Relay Password Decryption

After recovering the CRAFT_SECURITY_KEY from the .env file, I used PHP and Yii's built-in security class to decrypt the mailRelayPassword stored in the database.

I loaded the application's Composer dependencies and used decryptByKey() to decrypt the Base64-decoded value with the recovered security key. The decryption succeeded and revealed the plaintext password Skyp0rt_Relay!26. Combining this with my earlier database findings, I now had the credentials aporter:Skyp0rt_Relay!26 for the mail relay service at mail.htbairways.htb:587. With the mail relay password recovered, I could investigate whether these credentials provided access to additional internal services.

SSH Authentication with Recovered Credentials

After decrypting the mail relay password, I attempted to reuse the recovered credentials to authenticate as aporter over SSH on the internal server 10.13.37.10.

I used sshpass to supply the recovered password automatically, while StrictHostKeyChecking=no disabled the initial SSH host key confirmation prompt. The SSH client connected to the server and added its ED25519 host key to my local known_hosts file. This confirmed that the SSH service was reachable, although the displayed output did not yet confirm successful authentication. My next step was to verify whether the credentials granted an interactive shell as aporter, potentially providing access beyond the existing www-data foothold.

User Flag Retrieval

After successfully authenticating over SSH as aporter, I obtained an interactive shell on the portal server and enumerated the user's home directory.

The directory contained a user.txt file, which I opened to retrieve the user flag. The command returned 34ffc9cb0e6f189f582e37ed3a126299, confirming that I had successfully obtained the user flag. With user-level access established as aporter, I could now focus on enumerating the server for potential privilege-escalation paths to root.

Internal Network Service Enumeration

After obtaining the user flag, I ran ss to enumerate listening TCP services on the portal server and identify potential privilege-escalation opportunities.

The output revealed that SSH (22) and HTTP (80) were listening on all network interfaces, making them accessible remotely. I also identified MySQL (3306), CUPS (631), and DNS services on port 53, all bound to localhost addresses. The locally bound services caught my attention because they were not directly exposed to other machines on the network. With these services identified, I continued investigating the internal environment for misconfigurations or potential privilege-escalation paths.

CUPS Service Enumeration

After identifying port 631 during my internal service enumeration, I researched its purpose to understand whether it could provide another privilege-escalation path.

I discovered that port 631 is commonly used by CUPS, which manages printers, print jobs, and printing queues on Linux systems. CUPS also provides a web-based management interface, typically accessible through http://localhost:631. Since the service was listening on 127.0.0.1, it was only accessible locally on the compromised server. This caught my attention, so I decided to investigate the CUPS installation and its configuration for potential privilege-escalation opportunities.

CUPS Version Enumeration

After identifying the CUPS service on port 631, I checked its installed version to determine whether it might be affected by any known vulnerabilities.

The command returned CUPS version 2.4.16, confirming the version installed on the portal server. I used 2>/dev/null to suppress any error messages and keep the output clean. With the version identified, I could now research publicly disclosed vulnerabilities and determine whether this CUPS release offered a potential privilege-escalation path.

CUPS Privilege Escalation – CVE-2026-34990

After confirming that the target was running CUPS 2.4.16, I researched publicly disclosed vulnerabilities affecting this version.

I discovered a GitHub proof of concept for CVE-2026-34990, which claimed to exploit CUPS versions up to 2.4.16.

According to the repository, the vulnerability could allow local privilege escalation to root when CUPS runs with elevated privileges. The PoC described a technique involving the disclosure of CUPS authentication tokens and abuse of a file:// print queue to write a sudoers configuration fragment.

This caught my attention because I already had SSH access as aporter, giving me the local foothold needed to investigate the exploit. My next step was to review the PoC and test whether the target's CUPS configuration was vulnerable.

CUPS Privilege Escalation – CVE-2026-34990

I created a Python script named poc.py on the portal server and pasted the public PoC targeting CUPS 2.4.16.

Then I ran the script by running:

I executed the exploit as aporter, targeting the locally running CUPS service on 127.0.0.1:631. The script launched a rogue IPP server and successfully captured a CUPS Local authentication token. Using the captured token, the exploit abused a file:// printer destination to write a malicious sudoers configuration to /etc/sudoers.d/aporter-pwn.

This granted aporter unrestricted passwordless sudo privileges, effectively escalating my access to root. The exploit confirmed successful privilege escalation by returning uid=0(root) gid=0(root) groups=0(root), allowing me to proceed with obtaining a root shell.

Root Shell Access

After successfully exploiting CVE-2026-34990 and obtaining passwordless sudo privileges, I ran sudo -i to elevate my session to root.

The command executed successfully, changing my shell prompt from aporter@portal:~$ to root@portal:~#. This confirmed that I had obtained an interactive root shell on the portal server. With full administrative privileges established, I could now access restricted system files and directories. My next step was to navigate to the root directory and retrieve the final flag to complete the machine.

Root Flag Retrieval

After obtaining an interactive root shell on the portal server, I listed the contents of the root user's home directory to locate the final flag.

The directory contained root.txt, which I opened using cat to retrieve the root flag. The command returned xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, confirming successful access to the final flag. With both the user and root flags obtained, I had successfully completed the Hack The Box Layover machine.

Keywords:

Layover - HTB Writeup

HTB Layover Writeup - Hack The Box Season 12

Layover---HTB

Layover HTB Walkthrough

I just solved Layover from Hack the Box

Layover HTB Season 12 Machine CTF Solution

HTB Layover - Writeup

Layover HTB Writeup

Hack The Box : Layover writeup

HackTheBox - Layover

Beginner's Guide to Conquering Layover on Hack the Box

Conquer Layover on Hack The Box

Layover HTB Walkthrough Season 12 Aero Writeup

Rooted Layover on Hack The Box

Layover - HTB Walkthrough

Layover Writeup - HackTheBox

layover.htb

Layover HTB Writeup & Walkthrough

I just solved Layover from Hack the Box

layover htb writups

Layover HTB - Complete Writeup Key

Layover WriteUp - HackTheBox

HTB-Layover WriteUp Reconnaissance

HTB-Layover WriteUp

HTB Layover Walkthrough: Craft CMS & CUPS to Root

Full walkthrough of Hack The Box Layover ,RDP jumpbox, WiFi sniffing, Craft CMS 5.9.8 RCE, and CUPS CVE privilege escalation to root

Layover - HTB Writeup exploit & vulnerabilities

Owned Layover on Hack The Box - Season 12. OS: Linux | Difficulty: Medium