How do you detect Visual Studio Code tunnels abused for remote access on Windows?

What makes VS Code tunnels visible in Windows telemetry?

Focus on the tunnel lifecycle, not just the process name. VS Code tunnelling is usually detectable through a new remote-access capability appearing where none is expected, followed by repeated outbound connectivity from developer tooling, often with a stable destination and persistent session behaviour. On Windows, that means correlating process creation, command line, network telemetry, and user context rather than relying on a single indicator.

Microsoft’s NIST SP 800-207 Zero Trust Architecture is useful here because the core problem is unauthorised access through a trusted client path, so the practical question is whether the connection is expected, constrained, and attributable. Command and Control (C2) Guide is also relevant because tunnel abuse often looks like ordinary egress until you examine beacon-like persistence, unusual destinations, and protocol hiding.

For Windows detections, that usually means watching for VS Code or related helper processes spawning a tunnel, a browser, or child processes that create long-lived network sessions. Pay attention to non-interactive hosts such as servers and jump boxes, because the same behaviour on a developer laptop may be normal while on infrastructure systems it is a stronger sign of remote-access abuse.

Which behaviours should trigger suspicion?

Suspicion increases when tunnelling appears without a clear operational need, especially if the account is not a developer, the host is not a workstation, or the session begins outside normal support hours. Also watch for tunnel use that bypasses established remote-access paths, because that often means the user is trying to avoid VPN, RDP gateway, or PAM visibility.

Two patterns matter most: first, the tunnel is started from a user context that does not normally administer the machine; second, the network pattern shows a durable outbound relationship rather than a short troubleshooting session. RMM Tool Security Guide is a useful comparison point because remote-access abuse through legitimate tooling often relies on the same detection problem, which is distinguishing sanctioned administration from hidden remote control. Remote Access Identity Guide reinforces the operational baseline: if the environment has no approved need for tunnelling, the tunnel itself becomes the anomaly.

Another useful signal is mismatch between the parent process and the role of the endpoint. For example, tunnel creation on a server by a non-admin account, or by a process lineage that does not fit approved developer workflows, deserves immediate review. If you also see unusual DNS, egress to consumer infrastructure, or repeated reconnects after logoff, treat it as possible unauthorised remote access rather than a benign developer test.

How should you investigate and contain it?

Start with the account, the endpoint role, and the destination. Confirm whether the tunnel was authorised, whether the destination was expected, and whether the process tree matches approved usage. Then determine whether the tunnel was used for interactive access, file transfer, command execution, or lateral movement, because that changes both containment scope and evidence collection.

Privileged Session Management Guide matters when the tunnel is acting as an alternate admin path, because session visibility and recording become the difference between a noisy alert and a defensible investigation. If the same host also exposes RDP or other remote access, compare those channels and determine whether the tunnel was used to evade monitored entry points. Remote Desktop (RDP) Security Guide helps here because tunnel abuse and exposed remote desktop are often alternative paths to the same outcome.

Containment should be targeted. Kill the tunnel process, revoke the account if abuse is plausible, and check for follow-on persistence such as scheduled tasks, startup items, remote administration tools, or new credentials on the host. If the tunnel was on a privileged or shared account, assume the remote path may have exposed broader access than the tunnel itself suggests.

Risk and Threat Considerations

VS Code tunnels are risky because they can turn a legitimate developer workflow into an unmonitored remote-access channel. The main exposure is not the tool itself, but the trust placed in a process that can quietly create a private path into a Windows host, especially where developers, contractors, or support staff have more reach than the endpoint owner expects.

Failure mechanism: An attacker or unauthorised user abuses a VS Code tunnel to establish interactive access that blends into normal outbound traffic, then uses that access to inspect, modify, or persist on the system while avoiding standard remote-access controls.

Impact: The result can be stealthy administrative access, reduced logging fidelity, lateral movement from a trusted host, and delayed detection because the session may look like routine developer activity rather than remote intrusion.

Practitioner Guidance

What to verify: Confirm that tunnelling is approved for the host class, user role, and operating window before treating it as benign. If the host is a server, jump box, or endpoint with no development purpose, require a stronger justification than “the user needed access.”

What to measure: Track how often tunnel creation occurs outside approved developer systems, and how often those events involve privileged users, long-lived sessions, or unusual parent processes. A small number of repeat offenders usually indicates a policy gap, not just noisy telemetry.

Common mistake: Treating the VS Code binary as inherently suspicious and stopping there. The real judgement is whether the tunnel is expected, attributable, and constrained, because the same technique may be legitimate on one asset and high risk on another.

Practitioner takeaway: The best detections correlate process lineage, host role, and outbound session behaviour, because unauthorised tunnel abuse is easiest to miss when each signal is viewed in isolation.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2020-1147 (Microsoft .NET Framework, SharePoint, and Visual Studio Remote Code Execution)?
• How do you detect unauthorised remote access software such as UltraVNC on Windows?
• How do you detect unauthorised remote access tools like AnyDesk on Windows endpoints?
• How do security teams detect when AD password changes and remote access controls are being abused?