Turning a Cloud Serial Console into a SOCKS5 Proxy

Many cloud providers, including AWS and GCP, have some form of console access to the virtual private servers hosted on their infrastructure. This is so users can access them even if their network interfaces are down and is commonly referred to as out-of-band management. Generally speaking, it's only meant to provide an interface to run setup or recovery commands on the remote host. Sending network traffic over this channel is usually not supported.

Linode's implementation is called the Linode Console (aka Linode Shell, aka LISH, aka Lish... jury is still out on that one). There is a web-based weblish, a graphical Glish, and unfortunately a soon-to-be deprecated LISH via SSH (LISH via SSH is still working as of early November 2026, and there have been no updates from Akamai on the matter). The latter is what we're going to focus on for this experiment.

I've talked about this idea with friends before, but originally it seemed like a decent amount of work, and I didn't have any real use cases. But nowadays code is cheap, so I revisited the idea to see if I could build a small proof of concept.

I started with a Nanode 1GB instance ($5/month) running Debian 13.

With some initial notes of how LISH via SSH worked as well as the official documentation, I had Codex get to work on writing a client and server which used a text-based protocol over /dev/ttyS0, the serial console. The "client" would serve a SOCKS5 proxy on localhost, forwarding traffic over SSH to the Linode as text, which would then be processed by the "server" and finally forwarded out the public interface. The server would be installed over LISH as a systemd service and attached to the console interface so you could still log into the server via Glish. This means the tool never interacts with the public interface of the VPS.

In a few hours, I had a working proof of concept. Codex (gpt-6.1-sol-xhigh with medium reasoning subagents for coding tasks) landed on a base64 encoded JSON implementation for the text-based protocol. This is not very efficient and likely hurts the bandwidth a little bit, but works for a proof of concept (and regardless, it's not like the bandwidth is going to be outstanding anyways). Check out my Github repo for source and more details.

First we connect with a LISH SSH Gateway, in this case I'm using lish-eu-central.linode.com. One neat thing is that the Linode is actually in a Virginia datacenter, but we can enter Linode's infrastructure from their datacenter in Frankfurt, Germany.

PYTHONPATH=src python3 -m client ~/.ssh/lish 'ropbear@lish-eu-central.linode.com proxy-test'

2026-11-04 22:08:31.593 INFO client.main: Starting client mode=serial 2026-11-04 22:08:31.594 INFO client.main: Subprocess started pid=2571100 2026-11-04 22:08:31.594 INFO client.transport: Waiting for the serial console before sending the handshake 2026-11-04 22:08:48.681 INFO client.transport: Serial console attached; starting a fresh handshake 2026-11-04 22:08:48.682 INFO client.main: Waiting for session handshake timeout=30s 2026-11-04 22:08:49.079 INFO client.main: Received server ready protocol_version=1 2026-11-04 22:08:49.079 INFO client.main: Session handshake confirmed; starting SOCKS listener 2026-11-04 22:08:49.080 INFO client.main: SOCKS5 TCP proxy ready on 127.0.0.1:9050. Press Ctrl+C to stop.

I then tested the connection with a 100MB download. Without the proxy, the file that downloaded at about 80 Mib/s. For proxy tests, I limited the connection duration to 30 seconds to avoid waiting over an hour for the download to complete.

curl --proxy socks5h://127.0.0.1:9050 --noproxy ''
--location --fail --silent --show-error
--connect-timeout 15 --max-time 30
--output /dev/null
--write-out 'HTTP: %{http_code}\nReceived: %{size_download} bytes\nDownload: %{speed_download} bytes/s\n'
'https://lil1-rbx.speedtest.network.ovh.net/files/100Mb.dat'

Entering through Frankfurt, the download speed was 149 Kib/s.

curl: (28) Operation timed out after 30000 milliseconds with 557020 out of 104857600 bytes received HTTP: 200 Received: 557020 bytes Download: 18567 bytes/s

Using same datacenter as the Linode was hosted in, the download speed was still 149 Kib/s. Almost like there's a bottleneck somewhere...

curl: (28) Operation timed out after 30000 milliseconds with 573386 out of 104857600 bytes received HTTP: 200 Received: 573386 bytes Download: 19112 bytes/s

Again, this isn't limited to Linode, they're simply my preferred provider. So in the end we have a SOCKS5 proxy riding an encrypted SSH connection to a trusted domain, tunneling traffic through /dev/ttyS0 on the VPS and egressing from its public interface. This combination has some interesting privacy and security implications.

From a privacy perspective, this is a neat little way to disrupt traffic analysis large ISPs might use for advertising or surveillance purposes. On top of that, you never have to open ports on the cloud or VPS firewalls. This allows you to have a cheap, privacy friendly SOCKS proxy that looks innocuous to your ISP. It's by no means a privacy guarantee, but it makes netflow analysis a little more difficult.

It's important to note that the proof of concept code uses an unencrypted protocol, so anyone with access to the screen session (Linode in this case) would be able to read the traffic as it is sent on the wire. However, the same console is trusted with the plaintext VPS root password when you log in, so there are hopefully significant security controls already in place.

From an offensive security perspective, the out-of-band nature of this channel becomes a little more interesting. There are three use cases off the top of my head.

First, for high-profile red team engagements, the netflow analysis disruption would make it challenging for blue teams to correlate the traffic streams and identify the originating operational infrastructure. The ease of deployment and low cost makes this a prime candidate for ephemeral redirectors, making it a challenging game of cat and mouse for the blue team to block IP addresses they see traffic originating from.

Second, in the opposite direction, this could potentially be a C2 channel for malware. However, I think this is less likely since the chosen cloud provider would need to have granular RBAC which allows a least-privilege SSH credential to be hard coded into the malware, potentially giving forensic investigators root access to the proxy VPS. Outgoing SSH connections are also likely to be blocked in most red team engagements, but there is also web-based console access (weblish on Linode) which uses HTTPS and/or WSS for console IO over 443/TCP.

Finally, if a organization's serial console access is compromised, this is a covert out-of-band exfiltration channel. Serial consoles in particular seem to be a monitoring blind spot which I believe is commonly overlooked by security operations. It's easy to assume that if a host was compromised via an exposed serial console access, the attacker would need to use the host's network interface to establish a C2 connection. This might lead a network security engineer to believe it would be blocked by a firewall or caught by IDS or IPS. However, this project proves that, although it's a slow connection, an attacker could establish C2, move laterally, and exfiltrate limited amounts of data using only the connection to the serial console, never establishing an outbound connection from the cloud host.

On top of this, cloud providers are unlikely to protect their clients from this attack vector aside from enforcing MFA. Automatically monitoring this channel for the customer would imply monitoring the most sensitive administrative control channel for a VPS, which would be a significant privacy and security violation if not explicitly requested by the customer. And since customers are unlikely to monitor this channel themselves, I think this makes for a large blind spot for monitoring.

So if you're a network security engineer, I would recommend triple checking that your serial console access is gated behind MFA, ideally backed by hardware. As for monitoring, I think that would look something like monitoring the serial console output for anomalous activity, but again, I'm not sure many (if any) built-in solutions exist for this.