DEV Community: Badathala Jaisurya

Hack The Box : Layover writeup

Badathala Jaisurya — Tue, 29 Sep 2026 20:00:30 +0000

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:

ssh aporter@10.13.37.10

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

What I Learned From Completing Fortinet NSE 1 as a Cybersecurity Specialist

Badathala Jaisurya — Mon, 28 Sep 2026 09:05:26 +0000

I recently completed NSE 1 – Fortinet Certified Fundamentals in Cybersecurity.

It’s an entry-level certification, so I wasn’t expecting it to suddenly turn me into a cybersecurity expert. What I wanted was something more useful: a stronger understanding of the fundamentals before going deeper into security.

And that’s exactly how I approached it.

Why I Started With the Fundamentals

Cybersecurity is a huge field.

You can go into penetration testing, SOC operations, cloud security, application security, digital forensics, DevSecOps, threat intelligence, AI security, and many other areas.

When you're starting out, it’s easy to get overwhelmed by tools and technologies.

Kali Linux, Burp Suite, Wireshark, SIEM platforms, cloud security tools, vulnerability scanners — there is always something new to learn.

But tools make much more sense when you understand what you're actually looking at.

That’s why I wanted to strengthen my foundation first.

What NSE 1 Covers

During the certification, I worked through fundamental cybersecurity concepts including:

Common cybersecurity threats
Basic security concepts
Network security fundamentals
Different types of attacks
Security terminology
The importance of protecting digital systems and information

Nothing here is extremely advanced, and that’s actually the point.

The fundamentals are supposed to be understandable before you start dealing with more complex security problems.

One Thing I Took Away

One thing I’ve started to realise while learning cybersecurity is that knowing a tool isn't the same as understanding security.

You can learn how to run a vulnerability scanner.

But understanding why a vulnerability matters, what could happen if it is exploited, how to validate the finding, and how to mitigate it is a different skill.

The same applies to almost every area of security.

The tools change.

The fundamentals remain.

Where I'm Going Next

My interests are currently spread across a few areas:

Cybersecurity
Cloud Security
DevSecOps
AI Security

I’m especially interested in AI security because modern AI systems introduce a different set of security problems.

Prompt injection, insecure tool use, data leakage, RAG security, agent security and model-related risks are areas I want to explore more deeply.

But before going too far into those topics, I want to make sure the underlying security concepts are solid.

Certifications vs Practical Skills

I don't want to collect certifications just to make a longer list on my resume.

For me, the useful part of a certification is what happens after it.

Can I apply the concepts?

Can I build something?

Can I investigate a problem?

Can I explain what I found?

Can I break something and understand why it broke?

Those are the skills I want to keep developing.

NSE 1 is only a small step, but it's a useful one.

Now the interesting part begins: taking the fundamentals and putting them into practice.

What I'm Learning Next

I’ll be spending more time on practical cybersecurity projects, cloud security, DevSecOps and AI security.

I also plan to document some of the things I build, the problems I run into, and the lessons I learn along the way.

If you're also learning cybersecurity, I'd genuinely like to know:

What was the first security concept, tool, or project that really helped things start making sense for you?

You can find some of my work here:

GitHub: https://github.com/jaisurya93945

LinkedIn: https://www.linkedin.com/in/badathala-jaisurya/

Thanks for reading.

cybersecurity #infosec #devsecops #cloudsecurity #aisecurity