Inferno: From HTTP Basic Auth to Root via an Abandoned Web IDE

This write-up documents my approach to solving the Inferno room on TryHackMe, a medium difficulty challenge built around Dante's Inferno. Behind that literary, sparse-looking homepage lies a practical attack chain: brute-forcing an HTTP Basic Auth wall, reusing the recovered credentials to slip into an abandoned web IDE, weaponizing its known remote code execution bug, decoding a hidden SSH password out of a passage from the book itself, and escalating to root through an unrestricted sudo rule on tee.

The homepage doesn't hide what it's about either. The first thing you see is a few lines of Dante addressing Virgil, sitting over an old illustration of the nine circles of hell. It's a fitting preview: you know exactly what's waiting for you, and you have to go down through it anyway.

What made it genuinely harder than that description sounds is a detail the walkthrough doesn't advertise: something on the box logs every session out roughly a minute after it starts. I never found where it lived, but I felt it constantly. Reconnecting, re-running the same exploit, racing to grab what I needed before the connection dropped again.

Phase 1: Enumeration

Started with a full port sweep instead of a default scan, since a lot of these rooms hide the real service somewhere non-obvious.

nmap -p- -sV -sC <TARGET_IP>

Two ports came back: 22, running OpenSSH, and 80, running Apache. Loading the site in a browser didn't add much. A black page with a short passage from Dante's Inferno layered over an old woodcut-style map of hell. No links, no visible source worth reading. Moody, but empty.

Phase 2: Finding the Door

A directory brute-force against the site root mostly returned a wall of 403s for old backup and htaccess filenames the usual noise, no real leads.

Switching to gobuster with a larger wordlist finally turned up something:

One hit: /inferno , returning a 401. Not a web login form this time. An actual browser-native HTTP Basic Auth prompt, the kind with its own little "this site is asking you to sign in" dialog.

Phase 3: Cracking the Basic Auth Wall

Nothing on the site hinted at a valid username, so I went with the obvious guess (admin) and let hydra work through the rest against the Basic Auth endpoint directly:

It didn't take long. One valid pair came back: admin / dante1.

Security Issue #1: No Throttling on HTTP Basic Auth. Every request against /inferno got checked against the same static credential store, with nothing watching for repeated failures. A default username guess and a common wordlist were enough on their own; a lockout policy or rate limit would have turned this into a much longer afternoon.

Phase 4: Same Key, Second Door

Getting past Basic Auth didn't drop me onto a dashboard. It revealed a second, completely separate login page belonging to whatever application actually lived at /inferno.

I tried the same admin / dante1 pair out of habit more than expectation. It worked immediately, dropping me into a file browser for a project named, fittingly, inferno.

Security Issue #2: One Password, Two Independent Doors. The Basic Auth layer and the application's own login are separate authentication systems protecting the same path, and they turned out to share a password. Getting past the outer wall was effectively the same as getting past the inner one too.

Phase 5: Fingerprinting Codiad

The interface gave it away fast: this was Codiad, an open-source, browser-based IDE.

A quick look at its GitHub told the rest of the story, no real commits in years. Nobody's patching this thing. Searching for a public exploit turned up a ready-made Python tool built around CVE-2018- 14009, one of a small cluster of Codiad RCEs disclosed in 2017 and 2018, affecting every release up to and including 2.8.4. Since the project never shipped a 2.8.5, that CVE covers every Codiad install still standing.

Security Issue #3: Internet-Facing Software With No One Maintaining It. Codiad's known remote code execution bugs are documented, public, and exploitable off the shelf. Software with no active maintainer is a standing liability the moment it's reachable from outside the network.

Phase 6: From Exploit to a Very Temporary Shell

The exploit needs two listeners running to work: one to catch its own handshake and hand back a second-stage command, and a second to catch the actual interactive shell. After setting up listeners, i execute the scripts.

in listener:

A shell landed as www-data , sitting in /var/www/html/inferno/components/filemanager. It lasted less than a minute before the connection just closed on its own, the first sign of that timer I mentioned earlier. Every session on this box gets killed on a schedule. Treat each shell as a short, disposable window, not somewhere to sit and explore.

Phase 7: A Line for Virgil, With a Password Attached

/home/dante/Downloads was readable from the www-data shell, and mostly full of decoration. A set of files literally named after the Cantos of Dante's Inferno. One file didn't fit the pattern: a hidden .download.dat . Catting it produced a wall of raw hex.

Decoding it turned that wall into a few lines of Italian, a passage from Dante's own Inferno, the moment Dante recognizes Virgil and asks for his guidance:

Right after the last line, with no separator, sat a plaintext credential. SSH access for the user dante, tucked in behind a few stanzas of poetry.

Security Issue #4: A Credential Hidden by Encoding, Not Protected by It. Hex isn't encryption; reversing it took one command. The real problem sits underneath the disguise: a live credential stored in plaintext, in a file any local user could read, made to look like flavor text instead of a secret.

Phase 8: SSH and the First Flag

SSH with the recovered credentials worked right away. The same timer problem followed me in. .bash_history was symlinked straight to /dev/null, and the session itself had just as short a fuse as the reverse shell did.

Flag 1

I moved straight to /home/dante and grabbed local.txt before getting logged out again. First flag down.

Phase 9: Privilege Escalation via GTFOBins

A quick check of sudo permissions showed exactly one usable entry:

Dante could run /usr/bin/tee as root, no password required. GTFOBins has a standing entry for exactly this: any binary that can write or append to an arbitrary file as root, with no restriction on which file, doubles as a way to grant yourself anything you want.

That one line appended a full-privilege, passwordless sudo rule for dante directly into /etc/sudoers. From there:

Security Issue #5: Unrestricted, Passwordless Sudo on a Write Primitive. tee doesn't care which file it writes to, and the sudo rule didn't restrict it either. A NOPASSWD entry on any filewriting binary, with no argument restrictions, is root access wearing a disguise.

Flag 2

Second flag located in root directory, i just immediately grab it.

Blue Team Perspective

Working back through the chain, here's where I think a defensive team would have had a real chance to catch this, and what I'd fix.

1. No Throttling on Basic Auth

A burst of repeated 401 responses from a single source is one of the oldest brute-force signatures there is. Fix: rate-limit or lock out after a handful of failed attempts, and don't allow default or wordlist-common passwords on any account guarding an entry point.

2. Credential Reuse Across Trust Boundaries

One password guarded two authentication layers that were supposed to be independent. Fix: treat every boundary as its own system, and flag identical credentials showing up across separate login layers during a security review.

3. Sudoers Hygiene

A NOPASSWD rule on a generic file-writing utility is root access with extra steps. Fix: check any new sudo rule against GTFOBins before it ships, and scope permissions to specific files and arguments instead of granting a binary free rein.

This write-up is part of my ongoing series documenting CTF challenges as I build my portfolio in cybersecurity. I approach each challenge from both offensive and defensive perspectives, because understanding both sides is what makes a well-rounded security professional.

If you're also on the journey toward a SOC or Security Engineering role, feel free to connect — I'm always happy to discuss techniques and share resources.