Hidden VNC (hVNC): detecting, investigating and responding to hidden desktop access

Hidden VNC (hVNC) lets malware operators control an infected Windows machine on a second, invisible desktop, so they act as the real user, from the user's own device and sessions, while the user sees nothing. It is a feature of banking trojans and remote access trojans rather than a tool in its own right, and it defeats controls that trust the device: device fingerprinting, conditional access and session binding all see a legitimate machine. This guide is for SOC analysts, detection engineers, incident responders and fraud teams. It explains what defenders can observe, which log sources and ATT&CK v20 techniques apply, detection logic, and how to respond. It does not describe how to build or operate hVNC.

Key takeaways

• It is a hidden window technique. ATT&CK v20 places hVNC under T1564.003 Hidden Window (Stealth tactic): Windows can create additional desktops with their own explorer.exe, and applications on them are invisible to the user's desktop.
• The device is genuine, so the session looks genuine. Banks adopted device fingerprinting; hVNC answers it by committing fraud from the victim's own machine. Identity and fraud controls that stop at "known device" will pass it.
• Endpoint telemetry is the best detection point. A second explorer.exe or browser not started by the user's shell, code injection into explorer.exe, and a long-lived outbound session from that process tree are the core signals.
• Prevention is about the initial infection and remote access policy. Block the loaders (phishing attachments, malicious extensions), restrict software that can create hidden desktops (M1033) and control which remote access tools may run.
• Respond as a full compromise of the user. Isolate the host, then revoke every session and credential the user had open, including tokens for developer and SaaS tools.

How hVNC looks from the defender's side

Microsoft documents that the interactive window station has several desktops (Default, ScreenSaver and Winlogon by default) and that only one, the input desktop, is visible and receives user input at a time. Window messages pass only between processes on the same desktop. The ATT&CK Hidden Window technique notes that the Windows CreateDesktop() API can create a hidden desktop with its own explorer.exe, and anything running there, such as an hVNC session, is invisible to other desktops.

IBM's analysis of hVNC in banking trojans describes why operators use it: transactions from a known, trusted device are more likely to pass bank checks, and conventional remote control would show the victim a moving cursor. The operator streams the hidden desktop out, usually over an encrypted outbound channel, and browses as the user, inheriting logged-in browser sessions and saved credentials.

Where it appears

ATT&CK v20 records hVNC use by TrickBot (S0266), which used a hidden VNC window to monitor victims and collect information, WarzoneRAT (S0670), which offers remote desktop access via an hVNC window, and GlassWorm (S9010). Dridex (S0384) carried a VNC module. IBM names Dridex, Neverquest and Gozi among banking trojans with hVNC. The GlassWorm campaign deployed hidden VNC remote access on developer machines alongside theft of npm, GitHub and Open VSX tokens, which shows that hVNC is not only a banking problem: a hidden operator on a developer workstation can use every session and token that developer has. Commodity loaders and malware-as-a-service families also advertise it; see the DarkGate Malware Guide.

ATT&CK v20 mapping

All IDs verified against the ATT&CK v20 dataset. Mitigations: M1033 Limit Software Installation (ATT&CK explicitly cites restricting software that can create hidden desktops such as hVNC) and M1038 Execution Prevention. D3FEND countermeasures: D3-PSA Process Spawn Analysis, D3-PLA Process Lineage Analysis, D3-NTA Network Traffic Analysis and D3-EAL Executable Allowlisting.

Log sources

Detection logic

MITRE's detection strategy for Hidden Windows (DET0128) includes a Windows analytic (AN0360) that correlates hidden execution with anomalous process lineage or hVNC-like CreateDesktop calls, using Sysmon process creation and registry events, and advises restricting it to processes where hidden execution is unexpected and correlating with suspicious parents. Practical rules built on that:

• Second shell: an explorer.exe started by anything other than the logon process chain (userinit) while the user's normal explorer.exe is already running. Expect some false positives from software that restarts the shell; baseline first.
• Browser from an odd parent: a browser launched by explorer.exe that was itself started by an unusual process, or a browser started with a copied or non-default profile directory, shortly after a suspicious process appeared.
• Injection into explorer.exe or browsers: remote thread creation (Sysmon 8) or high-access process handles (Sysmon 10) into explorer.exe from unsigned or user-writable-path binaries.
• Hidden desktop API use: where EDR exposes API telemetry, desktop creation or switching by processes that are not known remote support, kiosk or security tools.
• Long outbound session from the injected tree: a continuous TLS session lasting tens of minutes from explorer.exe or a child process to a destination with no reputation, or regular beacons followed by a burst of traffic.
• Identity correlation: high-risk actions (payee changes, token creation, repository settings, mass downloads) from a user whose endpoint has an open alert, even though device and IP look normal.

Test detections in an isolated lab with benign multi-desktop utilities to confirm that the telemetry fires, then run rules in monitoring mode for two to four weeks, tuning for legitimate virtual desktop and remote support tools. Hunt queries can be written in KQL or SPL; see the KQL for Threat Hunting Guide.

Where identity fits

hVNC turns a compromised endpoint into a compromised identity without stealing a single password. The operator inherits signed-in browser sessions, SSO cookies, password manager unlocks, and on developer machines, the CLI tokens, SSH agents and package registry tokens available to the user. Phishing-resistant MFA does not help once the session is live, because the attacker never authenticates. Three identity controls limit the damage:

• Step-up for sensitive actions: require fresh user verification (a FIDO2 touch, a transaction signing step on a separate device) for payments, token creation and admin changes, so a remote operator cannot complete them silently.
• Short-lived tokens and scoped credentials: developer and automation tokens with short lifetimes and narrow scopes limit what an operator can take. See the Infostealer Logs and Session Token Abuse Guide.
• Endpoint risk in access decisions: feed EDR risk into conditional access so a host with an active alert loses access to sensitive applications.

Response steps

1. Isolate the host through EDR network containment. Do not log the user off first; keep the process tree for memory capture.
2. Capture evidence: memory image, process list with lineage, network connections and the EDR timeline. See the Memory Forensics Guide.
3. Scope the identity: list every application the user was signed in to, every token on the host, and actions taken in the user's name during the infection window (sign-in logs, SaaS audit logs, transaction logs).
4. Revoke and rotate: revoke sessions and refresh tokens at the identity provider, rotate passwords stored in browsers, and revoke developer, cloud and registry tokens from the host.
5. Find the loader: identify the initial infection (attachment, extension, download) and search the estate for the same indicators.
6. Rebuild the endpoint from a known-good image rather than cleaning it.
7. Notify fraud, finance or the bank if transactions may have been made, and review payee and payment changes during the window.

Prevention and hardening

• Application control: allow-list execution (WDAC or AppLocker) so loaders in user-writable paths cannot run (M1038, D3-EAL).
• Remote access policy: approve a small set of remote support tools, block others, and alert on new ones. CISA's countermeasure CM0020 covers disabling unneeded VNC services, blocking default VNC ports and preventing VNC executables from running. See the RMM Tool Security Guide.
• Extension and add-in control: restrict browser and IDE extensions to approved lists, since GlassWorm arrived through editor extensions.
• Email and download controls: attachment sandboxing and blocking of risky file types reduce loader delivery.
• Egress control: force traffic through a proxy that blocks uncategorised and newly registered domains for non-browser processes.

Detection and measurement

• Telemetry coverage: percentage of Windows endpoints with EDR and process lineage reaching the SIEM.
• Rule validation: date each hidden-window rule last fired in a controlled test.
• Containment time: median minutes from alert to host isolation.
• Revocation completeness: percentage of incidents where all sessions and tokens for the user were revoked within four hours.
• Unapproved remote access: number of hosts running remote access software outside the approved list, trending to zero.

Common failure patterns

• Trusting the device: fraud or conditional access rules treat a known device and IP as proof of the user.
• Remediating the password only: the user's password is reset but browser sessions, refresh tokens and developer tokens stay valid.
• Looking for VNC ports: hunting only for TCP 5900 misses hVNC traffic carried over 443 to operator infrastructure.
• Reimaging before capture: the host is wiped before memory and lineage are collected, so the operator's actions cannot be scoped.
• Ignoring developer machines: hVNC on a developer workstation is treated as a desktop issue while the operator uses repository and registry tokens, as GlassWorm showed.

Practitioner checklist

• Confirm EDR and Sysmon (with Event ID 3 enabled where needed) cover all Windows endpoints and feed the SIEM.
• Deploy and tune rules for second explorer.exe instances, odd browser parents and injection into explorer.exe.
• Correlate endpoint alerts with identity provider and SaaS high-risk actions for the same user.
• Maintain an approved remote access tool list and block the rest.
• Enforce application control and extension allow lists on high-risk users and developer machines.
• Require step-up verification for payments, token creation and admin changes.
• Write an hVNC response runbook that isolates first, captures memory, then revokes every session and token.
• Validate the detections in a lab at least twice a year.

Standards and references

• MITRE ATT&CK: Hide Artifacts: Hidden Window
• MITRE ATT&CK: Remote Access Tools
• MITRE ATT&CK: Browser Session Hijacking
• CISA: Eviction Strategies Tool, CM0020 Disable VNC Desktop-sharing System
• Microsoft Learn: Desktops
• Microsoft Learn: Sysmon
• MITRE D3FEND: Process Lineage Analysis
• IBM Security Intelligence: Anatomy of an hVNC Attack

Related NHI Mgmt Group resources: GlassWorm VS Code Extension Worm Guide · T1055 Process Injection Defensive Guide · Unauthorised Remote Monitoring and Management Tool Playbook · Session Hijacking and Cookie Theft Guide · EDR Guide