Securityaffairs

MedusaHVNC Trojan Creates Hidden Desktops to Hijack Browsers and Steal Data


MedusaHVNC Trojan Creates Hidden Desktops to Hijack Browsers and Steal Data

Pierluigi Paganini
July 27, 2026

MedusaHVNC RAT uses hidden Windows desktops to remotely control browsers, steal data, and evade detection through legitimate system features.

Windows has always supported hidden desktops as a legitimate feature, useful for specialized software that needs a workspace the user never touches. It’s a niche capability most people never think about, buried deep in how the operating system manages sessions. Unfortunately, malware authors noticed that too, and BlackFog’s research team just dissected a new remote access trojan called MedusaHVNC that maliciously uses this feature.

“We recently came across a sample of MedusaHVNC, a new remote access trojan (RAT) being sold as malware-as-a-service (MaaS). When we took it apart, we found a hidden virtual network computing (HVNC) module that opens a browser on a separate Windows desktop, out of sight of the victim.” reads the report published by Blackfog. “The browser still runs on the victim’s device, so it can load an existing profile, including cookies and session state. This gives the operator access to live, logged-in sessions while the activity continues to come from the victim’s usual machine.”

MedusaHVNC is marketed through its own website and Telegram channel as a malware-as-a-service platform. It includes in-memory execution of .NET and native payloads with AMSI and ETW bypasses, plus browser recovery features to steal passwords, cookies, and browsing history. It supports Chrome, Edge, Brave, Firefox, and Telegram, making credential and session theft easier.

The core feature is a hidden virtual network computing module that spins up a real browser on a separate desktop the victim never sees. BlackFog obtained a video showing an operator’s console with Google Chrome open on Google’s homepage, already signed into an account, alongside controls for adjusting frame rate and image quality like it’s a video call.

That level of polish tells you this wasn’t thrown together over a weekend. The client panel lets an operator pick which browser to run, Chrome, Edge, or Firefox, and configure the session before it even launches, turning account takeover into something closer to a point-and-click chore.

Getting there takes five stages, starting from something almost embarrassingly mundane. The chain kicks off when Windows Script Host runs an obfuscated JScript launcher, which pauses for exactly 7,584 milliseconds before rebuilding its files under a folder called Nx2981Okkr2 inside the Temp directory. That pause isn’t an accident; it’s the kind of small delay malware authors add to slip past sandboxes that only watch a sample for a few seconds. From there it drops an AutoIt interpreter, a config file, an encrypted payload with no file extension, and a batch script tucked into the Startup folder so the infection survives a reboot.

AutoIt, a completely legitimate Windows automation tool, then decrypts that payload using a single-byte XOR key, the value 0xAE, producing the first native 64-bit executable in the chain. That executable launches straight into charmap.exe, yes, the built-in Windows Character Map utility that ships on every machine. Sandbox data BlackFog reviewed shows charmap.exe spawning as a child of the AutoIt process, with the malicious loader injected directly into it, turning a completely trusted system binary into the payload’s hiding spot. Anyone scanning a process list for something suspicious would glance right past it, because nothing looks more boring than the character map tool.

Inside charmap.exe, the loader still isn’t done unwrapping itself. It runs a 16-byte repeating XOR pass across just over a million bytes of data, then a ChaCha20 decryption step using a 32-byte key and a 12-byte nonce, before the actual malware finally emerges. That’s three separate layers of obfuscation stacked on top of each other, each one designed to slow down anyone trying to reverse-engineer the sample by hand. BlackFog says it rebuilt that entire unpacking process offline and recovered the final payload byte for byte, which is about as thorough as forensic verification gets.

What comes out the other side is an unsigned 64-bit executable carrying the internal string MedusaHVNC. It talks to its operator over a custom protocol built on Windows’ native networking functions, and the command server address, 51.89.204.28 on port 4444, is baked directly into the binary rather than resolved dynamically. Fixed infrastructure like that is a tradeoff: simple for the attacker to run, but also a stable target defenders can block outright the moment they know to look for it.

Once the hidden session is live, the malware leans entirely on legitimate Windows capabilities to do its work. Screen and window capture ride on built-in functions like BitBlt, EnumWindows, and PrintWindow, while synthetic mouse clicks and keystrokes come through SendInput and SetWindowsHookExW. Clipboard functions round out the toolkit, giving the operator a simple way to move text and files into or out of the hidden session without ever touching a file transfer tool that might get flagged.

“Clipboard functions, including OpenClipboard, GetClipboardData, and SetClipboardData, provide another way to move information into or out of the session.” continues the report. “Taken together, these findings are consistent with the core HVNC workflow. The browser references identify the applications involved, and the capture, input, window-management, and clipboard functions provide the mechanisms needed to observe and control activity inside the hidden desktop.”

None of these are exotic hacking tools. They’re the same APIs legitimate remote-support software uses every day, which is exactly why watching process behavior alone won’t catch this. A security tool looking for “malicious” function calls will come up empty, because every single function involved has a completely ordinary, everyday use.

BlackFog’s own conclusion lands on the one place this scheme can’t hide: the network. Whatever happens inside that invisible browser, moving money, logging into accounts, copying data, still has to leave the machine to reach the operator, and that outbound connection looks the same whether it came from a hidden desktop or a plain remote-access tool. Blocking the known command server and the associated file hashes is a reasonable starting point for any team that wants to act today rather than wait for a signature update. It’s also exactly the layer BlackFog built its own anti-data-exfiltration product to watch, catching the connection in real time regardless of which process tries to make it, browser or otherwise.

Funny thing about building an invisible desktop: it’s only invisible until the data tries to leave the building, and buildings tend to have exits everyone’s watching.

“An unapproved connection to an attacker’s server is the same event whether it comes from a browser or a native client. Blocking traffic to known C2 infrastructure and alerting on unexpected outbound connections works regardless of how the session was hidden. Blocking the C2 address and the hashes in the IOC table is a concrete starting point.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, MedusaHVNC )







Source link