VS Code dev tunnels expose C2-like remote execution paths

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SpecterOps's blog post: VS Code Dev Tunnels combine REST discovery, a WebSocket relay, SSH and MsgPack RPC into a layered remote access path that supports command execution and file operations.

Why it matters: This matters because remote access mechanisms that look like convenience features can also create durable operator-controlled pathways that defenders need to inventory, authenticate and monitor like privileged access surfaces.

Context

Dev tunnels are not just a forwarding trick. They are a multi-layer remote access mechanism that moves from tunnel discovery to authenticated relay setup and then into shell-like operations over an application protocol.

That matters for identity and access governance because the access path depends on tokens, session binding and hidden control channels rather than a single obvious login. Treating it as ordinary developer plumbing misses the governance gap between convenience access and monitored remote administration.

SpecterOps's example is a red-team use case, which is typical of how such tooling gets explored before defenders have fully modelled the access and detection implications.

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. Put them behind strong authentication, session approval, audit logging, and time bound access, then restrict who can create, open, and forward ports. The tunnel owner, target system, and commands run through it should all be attributed and revocable.

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. A user may start a browser session, a tunnel, and then a shell or port forward, but the whole session chain must still be authorised and logged. If any layer allows arbitrary command relay, the stack becomes a covert execution channel.

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. The WebSocket establishes the transport, then SSH negotiates keys, authentication, and channels within it. Security teams should treat the WebSocket endpoint and the SSH endpoint as one access path for policy and logging.

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.

Technical breakdown

Tunnel discovery through REST management

The first layer is standard HTTP-based tunnel enumeration. The client queries a management API to discover available tunnels, labels, ports and relay metadata, then uses that metadata to request a scoped access token for a selected tunnel. This is not the actual transport path yet. It is the control plane that decides which tunnel can be reached and what identity context is required to proceed. Because the discovery step exposes tunnel state and endpoint metadata before any interactive connection begins, it becomes a governance boundary in its own right.

Practical implication: Inventory and restrict tunnel discovery endpoints as control-plane assets, not just as convenience APIs.

WebSocket relay and SSH over the tunnel

After token issuance, the client upgrades to a WebSocket session against a relay endpoint and then carries SSH inside that tunnel. The relay abstracts away direct host reachability, which is why the connection can survive firewall constraints and network address translation. The SSH layer is not a conventional remote login in the usual sense. It relies on the already-authenticated outer session and on protocol choices that standard client libraries do not always support. That layering makes inspection harder unless defenders understand both the relay and the inner session semantics.

Practical implication: Monitor the relay layer separately from SSH and treat authenticated tunnel upgrades as privileged remote access events.

MsgPack RPC turns the session into remote administration

Once SSH is established, the tunnel speaks MsgPack-encoded RPC methods that go well beyond file transfer. The available methods include command execution, file reads and writes, directory operations, process control and socket tunnelling. That means the tunnel is not just a pipe for editor traffic. It becomes an administrative interface with enough capability to behave like a remote management framework. The security implication is that the effective attack surface is defined by the RPC method set, the authorization context behind it and the trust granted to the tunnel session. See the RMM Tool Security Guide.

Practical implication: Classify each exposed RPC method as an administrative capability and restrict it with explicit policy and logging.

Threat narrative

Attacker objective: The objective is durable remote command execution and host control through a tunnel that blends into legitimate development access.

1. Entry begins with authenticated tunnel discovery and token acquisition from the remote management plane.
2. Escalation occurs when the attacker upgrades into the relay and establishes SSH over the authenticated WebSocket session.
3. Impact follows when MsgPack RPC methods are used to execute commands, inspect files and manipulate processes on the remote host.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The named concept here is the C2-shaped developer tunnel: a collaboration feature whose layered control plane, relay and RPC stack can be repurposed into an operator-controlled remote execution path. That matters because the security boundary shifts from network reachability to method-level authority. If defenders only monitor ports and not protocol behaviour, they miss the real control surface. The practitioner conclusion is to detect and govern the method set, not just the endpoint.

Authentication siloing does not eliminate tunnel abuse if the session itself is over-permissioned. The article shows separate identity containers for GitHub and Entra ID, but the issue is that the authenticated tunnel can still become a powerful remote control channel once established. That is an identity governance problem as much as a transport problem, because the access token is only the beginning of the trust chain. The practitioner conclusion is to review tunnel identity binding, not just login strength.

Remote command features hidden inside developer tooling deserve the same scrutiny as any other administrative substrate. Command execution, file operations and process control are privileged capabilities even when they arrive through familiar developer workflows. That means NHI-style thinking applies to tunnel-bound tokens and session credentials: inventory, scope, expiry and offboarding matter. The practitioner conclusion is to govern these flows as managed remote access, not as incidental product behaviour.

Tooling that normalises remote execution can outpace defenders' mental models faster than it changes the network. The practical risk is not novelty for its own sake but the lag between feature rollout and control design. Security teams need to decide where to record session provenance, how to alert on unusual RPC usage and which identities may create or reuse tunnels. The practitioner conclusion is to close the governance gap before the feature becomes routine.

What this signals

C2-shaped developer tunnels are becoming a governance problem, not just a red-team curiosity. Once a developer feature can enumerate sessions, relay traffic and expose command methods, the question becomes which identities may create, use and inspect those tunnels. Security teams should assume that any tooling offering interactive remote control will be examined for abuse paths, and policy should define that boundary before attackers do.

Session-level oversight will matter more than network perimeter logic. The practical control point is no longer the reachable port but the authenticated tunnel session and the methods it exposes. Teams that already manage privileged remote access, third-party support channels and administrative bastions can reuse those patterns here. The difference is that developer workflows may normalise behaviour that would look suspicious in any other remote administration system.

Remote access telemetry needs method awareness. A tunnel that can spawn processes, edit files and connect sockets produces a different risk profile from one that only forwards a single port. Defender workflows should therefore separate ordinary transport events from administrative RPC events and alert on the latter as potential operator activity, abuse or lateral movement.

For practitioners

• 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.
• Review identity binding across tunnel sessions Verify which identity provider, token type and account class can reach each tunnel so that one authentication path cannot silently inherit another team's access.
• Document tunnel response procedures for red-team and abuse cases Predefine how to suspend a tunnel, revoke its token and preserve relay logs when the session is used in ways that resemble operator activity.

Key takeaways

• Dev tunnels can combine discovery, relay and execution layers into a remote administration path that is much broader than simple port forwarding.
• The security concern is not the transport alone but the control plane, token scope and RPC methods available once a session is established.
• Practitioners should govern tunnel creation and use as privileged remote access, with strong logging, revocation and method-level restrictions.

Related NHI Mgmt Group resources: Remote Access Identity Guide · Command and Control (C2) Guide · RMM Tool Security Guide · Secure Remote Access Beyond VPN Guide

Key terms

• Dev Tunnel: A dev tunnel is a temporary network path from a local development machine or tool to a remote service, usually to expose ports, reach internal resources, or proxy traffic. Practitioners use it for remote debugging and testing, but it can also bypass normal network boundaries if it allows access to shells, APIs, or internal systems.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
• WebSockets: WebSockets are a persistent communication channel that supports real-time, two-way data exchange between a client and a server. They are commonly used when systems need immediate update delivery instead of periodic checking. That makes them useful for synchronization scenarios where freshness matters.
• SSH: SSH, or Secure Shell, is the encrypted protocol commonly used for remote command-line administration of Linux systems. In bastion architectures, SSH is usually the access method being controlled, narrowed to trusted source addresses, and routed through a hardened entry host rather than exposed broadly.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners turn identity governance into operational controls across access, privilege and lifecycle management.