Detecting and Mitigating IDE Tunneling Abuse (T1219.001)

Developers use remote development tools every day, and those tools are designed to open a secure link to another machine. MITRE ATT&CK tracks the abuse of that feature as T1219.001, IDE Tunneling, a Remote Access Tools sub-technique in the Command and Control tactic. It applies to Linux, macOS and Windows.

How attackers use it

IDE tunneling combines SSH, port forwarding, file sharing and debugging into one secure connection, so a developer can work on a remote system as if it were local. MITRE notes that unlike plain SSH and port forwarding, IDE tunneling wraps a whole session and may use proprietary tunneling protocols alongside SSH. That lets adversaries blend in with real development workflows.

Some IDEs, such as Visual Studio Code, have command line tools, for example code tunnel, that adversaries can use to set up tunnels programmatically and get web accessible URLs for remote access. The tunnels can be authenticated through accounts such as GitHub, which lets the adversary control the compromised system through a legitimate developer portal.

Persistence is part of the picture too. Some IDEs, such as Visual Studio Code and JetBrains, support automatic reconnection. An adversary may configure the IDE to launch at startup and bring the tunnel back up each time. Compromised developer machines may also be used as jump hosts to move further into the network. IDE tunneling tools may be built in or installed as IDE extensions.

Why developer machines are a special case

Developer laptops often have broader access than other endpoints: source repositories, build systems, cloud consoles and internal networks. Developers also run unusual software and open outbound connections to many services. A new tunnel to a developer portal does not look strange on that machine, which is exactly why it is attractive.

How to detect it

The MITRE strategy has three analytics that describe the same story from different angles:

• Creation of VS Code or JetBrains CLI tunneling profiles, followed by persistent remote access through IDE integrated tunnels, possibly authenticated through GitHub or JetBrains accounts.
• Creation of a VS Code tunnel configuration file combined with an interactive remote session through the code command line or SSH with the JetBrains gateway.
• JetBrains or VS Code tunnel profile creation followed by unusual persistent SSH or IDE based tunnel communication to the dev tunnels APIs.

In practice, collect:

1. Process creation with command lines, so the use of the tunnel subcommand of the IDE command line shows up.
2. File creation events for tunnel profile and configuration files.
3. Network and DNS logs for connections to the tunnel service endpoints, and long lived connections from developer tools.
4. Startup items and scheduled tasks that launch an IDE at login.

Tuning

Many organizations sanction remote development. If yours does, decide where it is allowed and by whom. Then alert on tunnels created on machines outside that group, on servers, and on any account that is not a corporate identity.

How to reduce the risk

MITRE lists execution prevention as the key mitigation. It describes using Group Policy to require user authentication by disabling anonymous tunnel access, which prevents unauthenticated tunnel creation or use. It also describes disabling the Visual Studio Dev Tunnels feature to block tunnel related commands, allowing only minimal exceptions for utility functions, and restricting tunnel access to approved Microsoft Entra tenant IDs by naming the allowed tenants.

In plain steps:

1. Decide whether you allow IDE tunnels at all. If not, disable the feature.
2. If you do, require authentication and limit tunnels to your own tenant.
3. Block or monitor tunnel service endpoints at the proxy for everyone who should not use them.
4. Control which IDE extensions can be installed.

Know what is installed on developer machines

You cannot restrict what you cannot see. An inventory of the tools and extensions on developer machines is the first step, and asset discovery helps close the gap for hosts nobody registered.

Try it yourself

Click through it at your own pace, or open it full screen.

Check your own environment

• Is remote development approved for your company, and for whom?
• Can your proxy or DNS logs show connections to tunnel services from devices outside that group?
• Do you know which IDEs and extensions run on production adjacent machines?
• Are developer machines treated as high value targets in your monitoring?

This read-only command lists processes whose name contains code on Linux or macOS, which helps you see whether a VS Code server or CLI is running where it should not:

ps aux | grep -i "[c]ode"

What good looks like

A good outcome is a clear policy and a few precise alerts. Remote development is either off, or allowed for named people on named machines with corporate authentication only. Tunnel service endpoints are monitored. Tunnel profile and configuration files trigger an alert when they appear on machines outside the approved group. And developer machines are covered by the same logging as servers.

Quick check

Sources

• MITRE ATT&CK, T1219.001: https://attack.mitre.org/techniques/T1219/001