Introduction
Many cloud providers, including AWS and GCP, have some form of serial console access to the virtual private servers hosted on their infrastructure so users can access them even if their network interfaces are down. This is commonly referred to as out-of-band management and is generally only meant to provide an interface to run setup or recovery commands on the remote host. Generally speaking, sending network traffic over this channel is not supported.
But it's still nothing more than a channel that transmits bidirectional data, right?
Linode's implementation is called the Linode Console or Linode Shell (LISH or Lish, jury is still out on that one). Effectively, it's a terminal-like way to manage your Linodes. There is a web-based weblish, a graphical Glish, and a possibly 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.
Building the Proxy
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 in a regional datacenter. 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 the 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 (/dev/ttyS0) so you could still log into the server via Glish. This means you would never need to interact 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 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).
You can see the end result here.
Testing the connection with a 100MB download, a file that downloaded at 86.8 Mib/s without the proxy downloaded at 177 Kib/s over the proxy. A significant 99.8% decrease in speed, but the connection was stable.
The end result is a SOCKS5 proxy riding an encrypted SSH connection to a trusted domain, tunneling traffic through the VPS to egress from its public IPv4 address. To someone conducting netflow analysis, the primary correlations would be the timing and volume of the incoming and outgoing traffic to the cloud provider. However, since the incoming and outgoing protocols are likely to differ, and since it's possible to use a LISH SSH Gateway that is not in the same datacenter as the Linode, correlation via timing could be tricky.
Again, this isn't limited to Linode, they're simply my preferred provider.
Privacy Implications
From a privacy perspective, this is a convenient way to disrupt traffic analysis large ISPs might use for advertising or legal 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 fairly normal to your ISP.
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.
Security Implications
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.
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, this is a monitoring blind spot which I believe is commonly overlooked by security operations. The general assumption is if a host was compromised via exposed serial console access, the attacker would need to use the host's network interface to establish a C2 connection and therefore be blocked by a firewall or caught by IDS or IPS. However, this proof of concept proves that, although it's a slow connection, an attacker could establish C2, move laterally, and exfiltrate 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. Monitoring this channel for the client 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 clients are unlikely to monitor this channel themselves, 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.