Devvortex is an easy Linux machine from Hack The Box that provides a solid opportunity to practice a full attack chain, from web enumeration and CMS fingerprinting to initial access, credential recovery, and privilege escalation.

This post is adapted from notes I originally wrote about two years ago. Instead of preserving it as a raw step-by-step lab dump, I have cleaned it up into a more readable walkthrough that keeps the technical flow while avoiding unnecessary sensitive details.

Introduction

Devvortex starts with a web-facing attack surface and gradually expands into a realistic chain involving virtual host discovery, Joomla enumeration, exploitation, post-exploitation, and local privilege escalation.

Although it is rated easy, I found it useful for reinforcing a repeatable methodology: enumerate carefully, validate assumptions, chain findings into access, and then move methodically toward privilege escalation.

Enumeration

I started with a standard Nmap scan to identify the exposed services on the target.

nmap -A -Pn 10.10.11.242

Once the reachable web service was identified, I mapped the target domain locally so the site could be accessed properly during testing.

echo "10.10.11.242 devvortex.htb" | sudo tee -a /etc/hosts

At that point, I moved into virtual host enumeration to look for additional content and web attack surface that might not be visible on the main host.

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ -u http://FUZZ.devvortex.htb/ -fw 5080

This revealed an additional virtual host, which I also mapped locally.

echo "10.10.11.242 dev.devvortex.htb" | sudo tee -a /etc/hosts

With the new host identified, I continued with directory enumeration to look for administrative paths and interesting endpoints.

dirsearch -u https://dev.devvortex.htb

This led to an administrative interface, which suggested that the application might be CMS-backed. From there, the next logical step was to fingerprint the underlying platform.

Exploitation

To confirm the CMS in use and identify the version, I ran Joomla-focused enumeration.

joomscan -u http://dev.devvortex.htb/

This revealed that the target was running Joomla 4.2.6. Once the version was identified, I then reviewed the known public attack surface associated with that release and validated a public exploitation path that exposed useful application-level access.

At this point, the machine shifted from reconnaissance into practical exploitation. Rather than stopping at version identification, the next goal was to turn that information into a usable foothold on the target.

Initial Access

After gaining access through the web application, I used the administrative functionality to work toward code execution and establish an interactive shell on the system.

Once the shell was obtained, I stabilized it to improve local interaction.

python3 -c 'import pty; pty.spawn("/bin/sh")'

That small step made local enumeration much cleaner and more reliable. It is a minor detail in many labs, but it usually pays off quickly once post-exploitation begins.

Post-Exploitation and Credential Access

With a shell available, I began reviewing the local environment for configuration details, stored credentials, and application data that could help transition from a temporary foothold into stable user access.

The local application database became an important source of information during this phase. After identifying credential material of interest, I prepared it for offline password recovery.

hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt

This part of the box highlighted a useful lesson: web access is often only the entry point. The more valuable objective is converting that foothold into a durable user session that supports the rest of the attack chain.

Privilege Escalation

Once I had user-level access, I moved into standard local privilege escalation checks.

sudo -l

From there, I reviewed the available privilege boundaries and validated the escalation path to full compromise. Although I had noted some inconsistency in the lab behavior at the time, the machine still provided a useful end-to-end workflow from enumeration to root.

Key Takeaways

1. Enumeration drives the result

The most important progress in this machine came from careful discovery. Virtual host enumeration and directory discovery were what opened the path forward.

2. CMS fingerprinting is high-value work

Identifying the Joomla version made exploitation much more targeted. Correct technology identification often narrows the path faster than trial-and-error testing.

3. Post-exploitation matters as much as exploitation

Getting a shell is not the end goal. The more useful transition is turning that foothold into stable user access and then into privilege escalation.

4. Easy labs still reinforce strong habits

Even on an easy machine, the lab was useful for reinforcing good workflow discipline across the entire chain: recon, fingerprinting, access, credential handling, and escalation.

Final Thoughts

Devvortex is a compact but valuable machine for practicing a complete offensive workflow on a Linux target.

For me, the biggest takeaway from this lab was not the exploit itself, but the reminder that good fundamentals consistently win: enumerate carefully, identify technology accurately, validate the right path, and move step by step toward full compromise.

If you are also revisiting retired labs, I think they are worth documenting, not only as technical walkthroughs, but also as a way to capture methodology and lessons learned over time.

Connect With Me

LinkedIn: https://www.linkedin.com/in/waris-damkham/ Website: https://waris-damkham.netlify.app/