T1219.001: IDE Tunneling
Adversaries may abuse Integrated Development Environment (IDE) software with remote development features to establish an interactive command and control channel on target systems within a network. IDE tunneling combines SSH, port forwarding, file sharing, and debugging into a single secure connection, letting developers work on remote systems as if they were local. Unlike SSH and port forwarding, IDE tunneling encapsulates an entire session and may use proprietary tunneling protocols alongside SSH, allowing adversaries to blend in with legitimate development workflows. Some IDEs, like Visual Studio Code, also provide CLI tools (e.g., `code tunnel`) that adversaries may use to programmatically establish tunnels and generate web-accessible URLs for remote access. These tunnels can be authenticated through accounts such as GitHub, enabling the adversary to control the compromised system via a legitimate developer portal.[1][2][3]
Additionally, adversaries may use IDE tunneling for persistence. Some IDEs, such as Visual Studio Code and JetBrains, support automatic reconnection. Adversaries may configure the IDE to auto-launch at startup, re-establishing the tunnel upon execution. Compromised developer machines may also be exploited as jump hosts to move further into the network.
IDE tunneling tools may be built-in or installed as IDE Extensions.
Analyst context for executives and security teams
IDE Tunneling matters because a normal developer tool can become a full interactive remote-access channel. For leaders, the risk is not simply “an IDE was installed”; it is that legitimate remote development features can combine tunneling, file access, debugging, and authenticated web access in ways that may look like approved engineering activity while supporting command-and-control.
Executive priority
Prioritize this where developer workstations, build systems, IT service provider access, or sensitive engineering environments are material to business continuity. Ask whether the organization knows which IDE remote-development features are approved, whether unauthorized IDE command-line tools or extensions can execute, and whether SOC/IR teams can distinguish legitimate developer tunnels from unexpected persistence or jump-host behavior. The ATT&CK relationships to reported campaigns make this a behavior worth validating, but local exposure depends on actual IDE usage, account governance, and telemetry coverage.
Technical view
This is a command-and-control sub-technique of Remote Access Tools affecting Linux, macOS, and Windows. Defenders should validate coverage for IDE and IDE CLI execution, especially remote tunnel features such as Visual Studio Code tunnel usage, proprietary IDE tunneling protocols, SSH/port-forwarding-like behavior, IDE extension installation, auto-reconnect behavior, and startup auto-launch configuration. Because official ATT&CK detection text is not provided, use the related DET0133 strategy direction—process, file, and network behaviors—as the primary validation frame rather than relying on any single indicator.
Likely telemetry
- Endpoint process creation for IDE applications and IDE command-line tools, including parent/child process context
- File and configuration changes for IDE extensions, tunnel settings, auto-reconnect, and startup persistence
- Network connection metadata from developer endpoints to remote IDE, tunnel, SSH, or web-accessible relay services
- Authentication and account activity for developer portals used to authorize remote IDE access, where available
- Asset and software inventory showing approved IDEs, extensions, and remote development features across Linux, macOS, and Windows
Detection direction
- Baseline legitimate remote development workflows before alerting on all IDE tunneling activity; false positives are likely in engineering environments.
- Hunt for IDE tunnel execution from non-developer systems, unusual service accounts, unexpected parent processes, or systems that should not initiate remote development sessions.
- Correlate process execution with new tunnel configuration files, IDE extension changes, startup entries, and outbound network sessions.
- Treat auto-launch plus auto-reconnect behavior as higher priority because the ATT&CK description notes persistence potential.
- Use relationship context from DET0133 to validate process, file, and network visibility; do not assume coverage if only one telemetry class is collected.
Mitigation priorities
- Apply execution prevention to block unauthorized IDE binaries, IDE command-line tools, scripts, and extensions from running on systems where they are not approved.
- Maintain an approved-use model for IDE remote development features, especially on developer machines, build infrastructure, and IT administration systems.
- Restrict persistence opportunities by controlling startup execution paths and unauthorized auto-launch configuration for IDE tooling.
- Review IDE extension governance because the ATT&CK object notes IDE tunneling tools may be built in or installed as IDE Extensions.
- Ensure incident response playbooks include triage of legitimate remote access tools, not only malware-specific tooling.
Analyst notes and limits
This object is newly defined in ATT&CK v19.1 as T1219.001 and is explicitly tied to command-and-control. Relationship context includes detection strategy DET0133, mitigation M1038 Execution Prevention, parent technique T1219 Remote Access Tools, and reported use relationships for Operation AkaiRyū, Operation Digital Eye, and Mustang Panda. Those relationships support prioritizing validation, but they do not prove current activity in any specific environment.
Official ATT&CK detection text is not provided for this technique. The take therefore relies on the official description, external references, and relationship names/descriptions only. Local IDE inventory, developer workflow documentation, network logs, endpoint telemetry, and account-authentication records are required to determine actual risk and detection quality.
IDE Tunneling
Adversaries may abuse Integrated Development Environment (IDE) software with remote development features to establish an interactive command and control channel on target systems within a network. IDE tunneling combines SSH, port forwarding, file sharing, and debugging into a single secure connection, letting developers work on remote systems as if they were local. Unlike SSH and port forwarding, IDE tunneling encapsulates an entire session and may use proprietary tunneling protocols alongside SSH, allowing adversaries to blend in with legitimate development workflows. Some IDEs, like Visual Studio Code, also provide CLI tools (e.g., `code tunnel`) that adversaries may use to programmatically establish tunnels and generate web-accessible URLs for remote access. These tunnels can be authenticated through accounts such as GitHub, enabling the adversary to control the compromised system via a legitimate developer portal.[1][2][3]
Additionally, adversaries may use IDE tunneling for persistence. Some IDEs, such as Visual Studio Code and JetBrains, support automatic reconnection. Adversaries may configure the IDE to auto-launch at startup, re-establishing the tunnel upon execution. Compromised developer machines may also be exploited as jump hosts to move further into the network.
IDE tunneling tools may be built-in or installed as IDE Extensions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1219 | Remote Access Tools | This object subtechnique of Remote Access Tools. |
Groups, software, and campaigns
G0129: Mustang Panda
Mustang Panda is a China-based cyber espionage threat actor that has been conducting operations since at least 2012. Mustang Panda has been known to use tailored phishing lures and decoy documents to deliver malicious payloads. Mustang Panda has targeted government, diplomatic, and non-governmental organizations, including think tanks, religious institutions, and research entities, across the United States, Europe, and Asia, with notable activity in Russia, Mongolia, Myanmar, Pakistan, and Vietnam. [1][2][3][4][5][6][7][8][9][10][11][12][13]
C0060: Operation AkaiRyū
Operation AkaiRyū (Japanese for RedDragon) was a cyberespionage spearphishing campaign conducted by MirrorFace between June and September 2024 against entities in Japan and Central Europe. Operation AkaiRyū notably included the first reported targeting of a European entity by MirrorFace, as well as their use of UPPERCUT, which was thought to be exclusive to menuPass.[1][2]
C0061: Operation Digital Eye
Operation Digital Eye was conducted in June and July of 2024 by suspected People's Republic of China (PRC)-nexus threat actors targeting business-to-business IT service providers in Southern Europe. Operation Digital Eye activity included the use of Visual Studio Code tunnels for command and control (C2) and custom lateral movement capabilities. Overlaps in tooling between Digital Eye and previous China-nexus campaigns, Operation Soft Cell and Operation Tainted Love, indicate the potential use of shared vendors or digital quartermasters.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | d69c6fdbe6f8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
sentinelone operationDigitalEye Dec 2024
Aleksandar Milenkoski, Luigi Martire. (2024, December 10). Operation Digital Eye | Chinese APT Compromises Critical Digital Infrastructure via Visual Studio Code Tunnels. Retrieved February 27, 2025.
Open source URL -
[2]
Unit42 Chinese VSCode 06 September 2024
Tom Fakterman. (2024, September 6). Chinese APT Abuses VSCode to Target Government in Asia. Retrieved March 24, 2025.
Open source URL -
[3]
Thornton tutorial VSCode shell September 2023
Truvis Thornton. (2023, September 25). Visual Studio Code: embedded reverse shell and how to block, create Sentinel Detection, and add Environment Prevention. Retrieved March 24, 2025.
Open source URL -
[4]
mitre-attack T1219.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.