Topic starter
06/11/2026 6:36 pm
TL;DR: VS Code Dev Tunnels are layered beyond simple port forwarding, combining REST discovery, a WebSocket relay, SSH and MsgPack RPC into a remote access path that can run commands, move files and manage processes, according to SpecterOps research. The architecture matters because it behaves like a C2 channel with stronger assumptions about trusted tunnel access and token handling.
Editorial analysis by NHI Mgmt Group, based on content published by SpecterOps: “The Accidental C2: Exploring Dev Tunnels for Remote Access”.
Key questions
Q: How do teams govern dev tunnels as privileged remote access?
A: Teams should govern dev tunnels as privileged remote access by treating them as a controlled path to internal hosts, shells, and services.
Q: Why do layered tunnel protocols create remote execution risk?
A: Layered tunnel protocols create remote execution risk because each wrapper can hide the real origin, destination, and command path.
Q: How does SSH over WebSocket tunnelling work?
A: SSH over WebSocket tunnelling carries an SSH session inside a WebSocket connection so SSH traffic can pass through web infrastructure.
Practitioner guidance
- Map dev tunnels to privileged remote access controls Classify tunnel creation, relay upgrades and RPC-backed command execution as privileged access events in your control catalog and logging design.
- Restrict tunnel discovery and token issuance Limit who can enumerate active tunnels and obtain connect-scoped tokens, and record every issuance for later review.
- Log and alert on RPC methods with execution power Treat spawn, file write, process kill and socket tunnelling methods as high-risk actions and alert when they are invoked outside approved workflows.
Bottom line: Dev tunnels can combine discovery, relay and execution layers into a remote administration path that is much broader than simple port forwarding.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Dev tunnels collapse the distance between remote access and administrative control. Once discovery, authentication and execution sit in one chained flow, the security question is no longer whether a tunnel exists. It is whether the organisation has treated that tunnel as an elevated access plane with governance, logging and revocation discipline. The practitioner takeaway is to classify dev tunnels alongside other privileged remote access channels, not developer convenience.
A question worth separating out:
Q: What should teams do first when remote command methods appear in developer tooling?
A: The first step is to identify where the command method is exposed, who can invoke it, and whether it allows interactive shell or arbitrary execution. Then remove default access, require strong authentication and explicit authorisation, and log every command with the accountable user or service account. Remote command features should never be left enabled for broad developer use without controls.
👉 Read our full editorial: VS Code dev tunnels expose C2-like remote execution paths