Dev.to Security 🔐 Cybersecurity 👁 0 📖 5 min read

Hack The Box : Layover writeup

Author: Badathala Jaisurya I recently rooted Layover on Hack The Box. This machine had a really interesting attack chain because every stage depended on information discovered during the previous stage. The overall pat

Hack The Box : Layover writeup

Author: Badathala Jaisurya

I recently rooted Layover on Hack The Box. This machine had a really interesting attack chain because every stage depended on information discovered during the previous stage.

The overall path was:


RDP → Wi-Fi Traffic Analysis → Credential Discovery → Internal Portal → Craft CMS → RCE → SSH → CUPS LPE → Root

This write-up documents the path I followed, from the initial enumeration all the way to root.

HTB Achievement:
https://labs.hackthebox.com/achievement/machine/1830127/984

Initial Enumeration

I started with a basic Nmap scan against the target.

nmap -sC -sV -p- <TARGET_IP>

The important services exposed were:

22/tcp    SSH
3389/tcp  RDP

The SSH service was running OpenSSH, while port 3389 exposed Remote Desktop.

Since RDP was available and I had valid credentials, I used it as the initial entry point.

RDP Access

I connected to the machine using the available RDP credentials:

Username: contractor
Password: Contractor2026!

After logging in, I was on the Windows jump host.

The hostname was:

airside-ws01

At this point, the interesting part was that the system had access to an internal wireless network that wasn't directly reachable from my attacking machine.

Internal Network & Wi-Fi

I checked the available network interfaces.

One of the wireless interfaces was connected to:

HTB International WiFi

The interface had an internal address:

10.13.37.182/24

This opened up another possible attack path.

Instead of immediately trying to exploit services, I started looking at the wireless traffic available from the compromised environment.

Wi-Fi Traffic Analysis

By analysing the wireless traffic, I was able to recover another set of credentials.

The credentials were:

Username: jenny
Password: Fl1ghtDeck2026!

These credentials turned out to be useful for an internal web application.

This was a good example of why traffic analysis can be valuable after gaining access to an intermediate system. The initial RDP access wasn't the final objective — it provided a position from which I could discover the internal environment.

Internal Portal

I discovered an internal portal at:

http://portal.international.htb/miles/login.php

I logged in using the recovered Jenny credentials.

The dashboard showed information belonging to Jenny Crawford, including:

Member ID: HA-4471880
Membership: Gold Member
Miles: 48,250
Upcoming Booking: KS7X2M

While enumerating the application, I discovered another interesting endpoint:

/admin

This redirected to:

/admin/login

The application was running Craft CMS.

Craft CMS Enumeration

The CMS identified itself as:

Craft CMS

The version was:

5.9.8

At this point, I researched the version and its attack surface.

The important part was that I already had authenticated access to the CMS, which made authenticated vulnerabilities particularly relevant.

After working through the applicable Craft CMS attack path, I was able to achieve remote code execution.

Craft CMS RCE

The successful exploitation gave me command execution on the underlying server.

The resulting shell was running as:

www-data

I now had code execution on the Linux server.

From here, the attack shifted from web application exploitation to local enumeration and credential discovery.

SSH Access

While enumerating the compromised system and its files, I recovered credentials that allowed me to access the internal server over SSH.

The internal server was:

10.13.37.10

I connected using:

This gave me a proper SSH session as the aporter user.

The user flag was then obtained from the user's home directory.

Local Enumeration

With SSH access established, I started enumerating the system for possible privilege-escalation paths.

One of the interesting services running locally was CUPS.

I checked the service:

systemctl status cups

The service was running with:

/usr/sbin/cupsd -f

There was also a custom systemd service configuration:

/etc/systemd/system/cups.service

The service contained:

Environment=LD_LIBRARY_PATH=/usr/lib64

CUPS was also listening locally on:

127.0.0.1:631

Identifying the CUPS Version

I checked the installed CUPS version:

cups-config --version

The result was:

2.4.16

The installed version was vulnerable to a local privilege-escalation vulnerability.

The relevant vulnerability was:

CVE-2026-34990

This gave me a clear privilege-escalation path to investigate.

CUPS Privilege Escalation

I prepared the applicable proof-of-concept and transferred it to the target.

The exploit initially returned an error because the Python script was missing an import:

NameError: name 'os' is not defined

I fixed the script by adding the required import:

sed -i '2i import os' /tmp/exploit.py

I then executed it:

python3 /tmp/exploit.py

The exploit successfully elevated my privileges.

I obtained a root shell.

Root

At this point, the machine was fully compromised.

The final privilege-escalation path was:

aporter
   ↓
CUPS 2.4.16
   ↓
CVE-2026-34990
   ↓
root

Complete Attack Chain

The complete path I followed through Layover was:

Internet
   │
   ▼
RDP
   │
   ▼
Windows Jump Host
   │
   ▼
Wi-Fi Traffic Analysis
   │
   ▼
Jenny Credentials
   │
   ▼
Internal Portal
   │
   ▼
Craft CMS 5.9.8
   │
   ▼
Authenticated RCE
   │
   ▼
www-data
   │
   ▼
SSH
   │
   ▼
aporter
   │
   ▼
CUPS 2.4.16
   │
   ▼
CVE-2026-34990
   │
   ▼
ROOT

Credentials Discovered

During the machine, I encountered the following credentials:

Username Password Purpose
contractor Contractor2026! RDP access
jenny Fl1ghtDeck2026! Internal portal
aporter Recovered during enumeration SSH access

Key Takeaways

The biggest takeaway from Layover was that the machine rewarded proper enumeration and understanding of the environment.

The initial RDP access wasn't enough by itself. It provided access to a system that could see an internal network.

The Wi-Fi traffic analysis then exposed credentials, which opened the internal portal.

The portal led to Craft CMS, which provided the route to RCE.

Finally, after obtaining SSH access, local enumeration revealed the vulnerable CUPS installation that provided the path to root.

The machine was essentially a chain of smaller discoveries rather than one single obvious vulnerability.

Final Result

Machine: Layover
Platform: Hack The Box
Difficulty: [Add HTB difficulty here]
Status: Rooted

HTB Achievement:

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

GitHub:

https://github.com/jaisurya93945

Author:

Badathala Jaisurya

Closing

Another machine rooted, another attack chain understood.

Layover was a good hands-on exercise across network enumeration, wireless traffic analysis, web application security, authenticated RCE, Linux enumeration, and privilege escalation.

I'm continuing to spend more time on hands-on cybersecurity, penetration testing, offensive security, and AI security while building projects and improving my practical skills.

If you're working through HTB or CTFs as well, feel free to share what you're currently working on.

Cybersecurity #HackTheBox #PenetrationTesting #EthicalHacking #OffensiveSecurity #Linux #InfoSec #CTF

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.