Port 2179 – VMConnect (Hyper-V Virtual Machine Connection)

Port 2179 is the default port for Hyper-V VMConnect — the Virtual Machine Connection channel a Hyper-V host uses to hand a guest VM’s console to a remote client. When you open a VM from Hyper-V Manager, System Center VMM, or Windows Admin Center, the enhanced-session desktop of that guest streams back to you over TCP 2179. IANA registers the port as vmrdp, “Microsoft RDP for virtual machines,” and that name is the important distinction: 2179 carries an RDP-style console feed through the hypervisor, not to a guest’s own network stack the way RDP on port 3389 does. An open 2179 therefore doesn’t mark just another Windows box — it marks a Hyper-V host, and a host owns every VM running on it.

Why It’s Open

Port 2179 is open because the machine is a Hyper-V host and something needs console access to its guests. VMConnect — bundled with Hyper-V Manager, VMM, and Windows Admin Center — connects to it to give operators a keyboard/video/mouse view of a VM even when that VM has no network, is mid-boot, or sits behind a broken firewall. It’s the virtualization equivalent of a physical KVM or an out-of-band console. The host listens on 2179 by default, and the port must be reachable from any workstation that manages VMs, so it commonly shows up on the management NIC of Hyper-V servers, failover-cluster nodes, and VDI hosts.

Because console access is a host-level function, 2179 usually sits alongside the rest of the Windows management plane — WinRM (5985/5986), RPC (135), SMB (445), and RDP (3389) — on the same host.

Common Risks

• Crown-jewel exposure. 2179 identifies a hypervisor, and a hypervisor outranks any single VM as a target: compromise the host and you inherit every guest — its disks, its memory, its running sessions.
• Management plane on the wrong network. If 2179 is reachable from a user VLAN or the internet, the virtualization fabric’s control surface is exposed to systems that should never be able to touch it.
• Console access is data access. A successful VMConnect session is a live console to the guest — a logged-in desktop, a recovery console, or a boot screen — reached without the guest’s own network credentials. Access is gated by Hyper-V Administrators rights on the host, so the real question is who can reach and authenticate to the host in the first place.
• The broader Hyper-V attack surface. An exposed, unpatched host is also exposed to the platform’s guest-to-host escape bugs in the virtual switch, RemoteFX vGPU, and VMBus. Those are not “port 2179 bugs,” but they are the class of flaw that makes a reachable Hyper-V host dangerous.
• Enhanced Session Mode redirection. VMConnect’s enhanced session can redirect the clipboard, drives, and devices between client and guest — convenient, and one more data path to account for when the host is exposed.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

For a defender or auditor, the goal on 2179 is not to “log in” — it’s to identify that a box is a Hyper-V host so it gets treated as the high-value asset it is.

Fingerprint the service

nmap -sV -p 2179 <target>

A service/version scan is the quickest way to flag the port. An open 2179 is a reliable fingerprint that the box is a Hyper-V hypervisor rather than an ordinary Windows server.

Map the management plane around it

nmap -sV -p 135,445,2179,3389,5985 <target>

2179 open next to 135, 445, 3389, and 5985 confirms a Windows virtualization host and tells you the whole management surface is reachable from wherever you’re scanning.

Note that 2179 does not answer a plain RDP client. VMConnect negotiates a console session for a specific VM through the host’s VMBus, so mstsc or rdesktop pointed at 2179 won’t connect the way they do against 3389. For a defender that’s the point: seeing 2179 is about identifying the host role, not authenticating to it.

Record every Hyper-V host you fingerprint this way so it lands in the pentest report with the rest of the management-plane findings instead of a scratch file.

What to Look For

Known CVEs and Exploits

None of the CVEs below is a remote bug you fire at TCP 2179. They live in the Hyper-V platform — the virtual switch, the RemoteFX vGPU, the emulation layer — and are typically reached from an authenticated guest VM (a guest-to-host escape) or from the host itself. They matter here because an open 2179 marks exactly the kind of asset these flaws compromise: a Hyper-V host. Keeping the host patched is what closes them.

• CVE-2021-28476 — Hyper-V vmswitch remote code execution, CVSS 9.9. The host’s virtual switch driver (vmswitch.sys) mishandles input from a guest, letting an authenticated guest VM execute code on the host or take the whole hypervisor down. About as close to a worst case as Hyper-V gets.
• CVE-2019-0721 — Hyper-V Network Switch remote code execution, CVSS 9.1. The host fails to validate input from an authenticated user on a guest OS — another guest-to-host code-execution path.
• CVE-2020-1043 — Hyper-V RemoteFX vGPU remote code execution, CVSS 9.0. Improper input validation in the RemoteFX vGPU component lets an authenticated guest run code on the host. One of the batch that led Microsoft to deprecate and remove RemoteFX vGPU entirely.
• CVE-2018-0959 — Hyper-V remote code execution, CVSS 7.6. The host’s instruction emulation fails to validate guest input, allowing a guest-to-host escape.

Mitigation

• Never expose the management plane. Keep 2179 — along with WinRM, RDP, and WMI/RPC — off untrusted networks entirely. It should be reachable only from the admin workstations that actually manage VMs.
• Isolate the virtualization fabric. Put Hyper-V host management interfaces on a dedicated management VLAN, separate from guest/production networks and the internet. A compromised guest should have no route to the host’s console port.
• Restrict Hyper-V Administrators. VMConnect access is gated by membership in Hyper-V Administrators (or local admin) on the host — keep that group tight and audited.
• Patch the host. Host cumulative updates are what close the guest-to-host escape CVEs above; patching the guests does not help. Prioritize Hyper-V hosts in the patch cycle.
• Remove RemoteFX vGPU. It’s deprecated and was disabled and removed by Microsoft (KB4570006) after repeated host-RCE bugs — don’t re-enable it.
• Use guarded fabric / shielded VMs where the workload warrants it, and firewall 2179 down to the specific management hosts even inside the admin VLAN.

Real-World Example

In mid-2020 Microsoft shipped a run of critical Hyper-V RemoteFX vGPU remote code execution vulnerabilities — CVE-2020-1043 among them — each allowing an authenticated guest VM to execute code on the host. Rather than keep patching the feature, Microsoft disabled RemoteFX vGPU by default and then removed it outright (KB4570006). It’s a clean illustration of the real risk model behind port 2179: the danger isn’t the console port answering on the network, it’s that the port marks a hypervisor whose guest-facing components — vGPU, virtual switch, VMBus — are the actual attack surface, and a single guest-to-host bug hands over every VM on the box.

FAQ

What is port 2179 used for?

TCP 2179 is Hyper-V VMConnect — the “Virtual Machine Connection” channel. A Hyper-V host listens on it so that Hyper-V Manager, System Center VMM, or Windows Admin Center can open a console session (the enhanced-session desktop) of a guest VM over the network. IANA registers it as vmrdp, “Microsoft RDP for virtual machines.”

Is port 2179 the same as RDP on port 3389?

No. Port 3389 connects to the guest operating system’s own Remote Desktop service. Port 2179 connects to the VM’s console through the Hyper-V host itself, using the vmrdp variant of RDP — so it works even when the guest has no network or isn’t fully booted. 3389 talks to the guest; 2179 talks to the hypervisor.

Is it dangerous to expose port 2179?

The port itself is authenticated — a VMConnect session needs Hyper-V Administrators rights on the host — so it isn’t an open door. The danger is what it reveals and where it sits: an open 2179 marks a Hyper-V host, and if that host’s management plane is reachable from untrusted networks, you’ve exposed the crown-jewel asset that owns every VM. Keep it on an isolated management network.

How do I secure or close port 2179?

Don’t expose the host’s management plane: isolate 2179 (and WinRM, RDP, WMI/RPC) on a dedicated management VLAN, restrict Hyper-V Administrators, firewall the port down to known admin hosts, keep the host patched to close the guest-to-host escape CVEs, and remove the deprecated RemoteFX vGPU component.

TL;DR

• Service: Hyper-V VMConnect (vmrdp) — the VM console channel on a Hyper-V host
• Default port: 2179/TCP
• What it signals: a Hyper-V host (crown-jewel — it owns all of its guests)
• Biggest risk: management-plane exposure, plus the platform’s guest-to-host escape CVEs (vmswitch / RemoteFX vGPU)
• Mitigation: isolate on a management VLAN, restrict Hyper-V Administrators, patch the host, remove RemoteFX vGPU