Touch is a beginner-friendly Windows box on Hack The Box that’s less about brute-forcing your way in and more about paying attention. The lesson at its core: web applications leak more than they realize, and that leakage is often the real vulnerability — not some flashy exploit.
Initial Recon
A standard nmap -sC -sV sweep turns up a handful of familiar Windows services — RPC, RDP, WinRM — plus something more interesting: an HTTP service on port 8443 identifying itself as a Nexion DeviceHub management portal.
It’s tempting to jump straight at RDP or WinRM since they’re the obvious “get a shell” targets. Resist that urge. Without credentials, neither gets you anywhere — and this box hands you credentials through the web app first. Port 8443 is where the real work starts.
Finding the Leak
Basic web enumeration against the portal — directory brute-forcing, checking for exposed API routes — turns up an endpoint that doesn’t require authentication at all. On paper, it’s just a device-status check: is the hardware online, what firmware is it running. In practice, it returns far more than that.
This is the core lesson of the box: read API responses carefully, even the boring ones. A “status” endpoint that includes a serial number, hostname, or firmware version might be handing you exactly what you need, just not labeled as a vulnerability.
In this case, that serial number turns out to double as the login password for the management portal itself — a classic case of using a device identifier as a secret. Anyone who can reach the unauthenticated endpoint can walk away with the credential needed to log in.
Into the Dashboard — and a Second Mistake
With the serial number in hand, authentication against the portal succeeds, opening up the full DeviceHub dashboard — scanner and printer status, device cards, and so on.
The dashboard isn’t the end goal, though. It’s worth slowing down here and actually inspecting the page rather than clicking through it. Each device card shows a masked credential field with a “show” toggle next to it.
It’s easy to assume clicking “show” triggers some authenticated backend call to fetch the real password. In a well-built app, it would. Here, it doesn’t have to — because the password was already sent to the browser in full, just hidden behind CSS or a JavaScript toggle function. A quick look at the page source (or the onclick handler driving that button) reveals the plaintext credential sitting right there in the HTML.
This is a good habit to build generally: when a password is “hidden” rather than genuinely protected, check whether it’s actually been withheld from the client, or just visually obscured.
From Application Creds to Windows Creds
The credentials revealed this way aren’t just for the device panel — they belong to an actual local Windows account. That distinction matters a lot: with RDP (3389) and WinRM (5985) both open, it’s worth testing the new credentials against both.
In this case, the intended path is RDP. The account authenticates there and drops you into an interactive session — but not a normal desktop. Instead, you land inside a fullscreen airport self-service kiosk application, with the usual Windows UI deliberately hidden from view.
That’s where the foothold stage ends, and kiosk-breakout territory begins.
The Chain, Summarized
Port 8443 (Nexion DeviceHub)
→ Unauthenticated API enumeration
→ Device info disclosure (serial number)
→ Serial number doubles as portal password
→ Dashboard access
→ Client-side JS/HTML leaks real device credentials
→ Credentials belong to a Windows account
→ RDP login
→ Kiosk-mode footholdTakeaway: nothing here required a CVE or a complex exploit chain. Every step was a design flaw — an endpoint that shouldn’t be public, a secret reused as a password, and a credential “hidden” only from the eye, not the browser. Half the battle on boxes like this is simply reading what’s already in front of you.