MedusaHVNC Hijacks Your Bank From a Hidden Windows Desktop You Never See

An attacker can open your bank in your own browser, on a second desktop you will never see, and move money while your screen shows nothing wrong. It is called MedusaHVNC, and it is not something a lone hacker built for one victim. It is sold as a product, with a website, a Telegram channel, and a panel where a buyer picks a target and starts a session. 🧐

Researchers at BlackFog pulled a sample apart and mapped the chain from the first click to the final payload. Who builds and sells it is not known. It moves through a website and a Telegram channel, and no researcher has put a name to the person behind it.

A normal account takeover trips alarms. This one does not, and the reason is the machine it runs on. The browser loads your profile, your session cookies, and your saved passwords. To your bank, the login comes from your usual computer, your usual city, your usual browser fingerprint. The checks that stop a login from a new phone or a strange country see nothing off, because nothing changed. The theft happens from inside your own trusted session, and that is exactly what the buyer is paying for.

The technique itself is old. It is called hidden VNC, or HVNC, and banking-fraud crews have used it for years. Windows can run a second desktop that the person at the screen never sees, a feature meant for software that needs its own workspace. MedusaHVNC spins up a full desktop of its own, with its own explorer.exe, and runs a full browser session on it while your visible screen carries on as normal.

The sales page brags about the rest. One feature runs the attacker’s code straight in memory, so nothing is ever written to disk for a scanner to find. It also switches off the two things Windows leans on to catch this: the part that lets antivirus check code before it runs, called AMSI, and the part that keeps a log of what happened, called ETW. Both off, and the code runs while Windows keeps no trace. The seller calls it Mem Exec.

A second feature, Browser Recovery, digs your saved passwords, cookies, and history out of Chrome, Edge, Brave, Firefox, and Telegram. That last one matters, a stolen Telegram session hands the attacker the messenger account itself, on top of the browser logins. The live hidden session is more limited, and lets the operator drive Chrome, Edge, or Firefox on the second desktop. In a video BlackFog obtained, a Chrome window sits open and already signed in, with sliders for frame rate and image quality. Taking over an account turns into a few clicks.

There are several separate threats called Medusa, and they have nothing to do with each other. The FBI investigated the Medusa ransomware and stated it is unrelated to a second family called MedusaLocker and to a Medusa banking trojan on Android. On top of those there is an old Medusa botnet, and now this, MedusaHVNC. Same word, different crews, different code, different goals. So if you have read about Medusa locking hospitals out of their files, that is the ransomware. This one does not encrypt anything. It sits quietly and uses your own logged-in sessions.

The hidden desktop trick has a long line behind it. It showed up early in Zeus, the banking trojan whose source code leaked in 2011, which is how the technique spread into other malware. It turned up over the years in banking trojans like Gozi, Dridex, TrickBot, and IcedID, and today it ships as a ready-made feature in off-the-shelf remote access tools like XWorm and Xeno RAT.

In 2017 the author of a trojan called TinyNuke published his own hidden VNC source code in public, and that code became the base for much of the hidden VNC sold today. That same year two IBM researchers showed exactly how the trick handles Chrome. It copies your whole Chrome profile to a second spot on the disk and starts the browser from that copy, so the hidden browser opens with your cookies and your logins already in place. That is the same move MedusaHVNC makes now. The idea is nine years old in the open, and older than that in the wild. What changed is that it now comes with a control panel and a monthly price.

The infection runs in five stages, each one built to slip past whatever is watching:

• → Windows Script Host runs a scrambled JScript launcher that waits just over 7.5 seconds, long enough to outlast sandboxes that only watch a file for a few seconds
• → It rebuilds its files in a temp folder and drops a batch script in the Startup folder, so it survives a reboot
• → A legitimate Windows tool called AutoIt decrypts the dropped payload with a one-byte XOR key, the value 0xAE, and produces the first 64-bit executable
• → That executable starts C:\Windows\System32\charmap.exe, the built-in Character Map, and injects the loader into it, so the malware lives inside a trusted Windows process
• → Inside charmap the loader carries two more encryption layers before the final payload appears

Those last two layers show how much work went into hiding one file. The payload itself is wrapped in two more locks. The first is a plain 16-byte key XORed over and over across 1,009,152 bytes of data. The second is ChaCha20, a modern cipher, decrypting 998,912 bytes with a 32-byte key, a 12-byte nonce, and a counter starting at 1. Researchers peeled both off and rebuilt the payload byte for byte. What comes out is an unsigned 64-bit console program with a section named .pay and the family name MedusaHVNC sitting inside it.

That payload talks to its operator over a custom TCP protocol built on the standard Windows network calls. The server address is hard-coded into the binary: 51.89.204.28 on port 4444.

Hiding the loader inside charmap.exe is not a one-off idea either. A few weeks earlier, Fortinet documented a separate campaign, with no proven link to this one, that hides its loader inside colorcpl.exe, the Windows Color Management tool, starting it frozen, dropping the payload in, then letting it run. Other campaigns this year leaned on MSBuild, a Microsoft build tool that ships with Windows. Character Map, Color Management, a build tool, small trusted programs that barely get watched. Picking one of them to hide in has become a pattern across 2026, not a single incident. Two of them, colorcpl and MSBuild, already sit on the public LOLBAS list of Windows tools known to be abused, the ones defenders watch. Charmap does not, which may be the point. MedusaHVNC picked a trusted program that was not on the list.

The rest is done with ordinary Windows functions, and that is why hunting for “malicious behavior” comes up empty. It captures the screen with BitBlt, EnumWindows, and PrintWindow. It types and clicks with SendInput and SetWindowsHookExW. It reads and writes the clipboard with OpenClipboard, GetClipboardData, and SetClipboardData. The same calls a support technician’s remote tool makes.

Whatever happens on that invisible desktop still has to leave the machine to reach the operator. The desktop is silent on your screen, but the network is not. An unapproved connection to an attacker’s server looks the same whether a browser or a native client opens it, and that is where you catch it.

The malware also leaves a mark on the machine itself. To give the operator a working hidden desktop, it starts a second explorer.exe, one you see on your screen and one you do not. Researchers at Cybereason showed this in their own lab runs, and IBM listed the same thing back in 2017. They saw an extra explorer.exe holding a handle to a desktop that is not the normal one, with browser and shell processes hanging off it that never draw a window you can find.

Spotting it on a suspect machine. Character Map should never spawn child processes, so list them first:

1

Get-CimInstance Win32_Process -Filter "Name='charmap.exe'" | Select-Object ProcessId, ParentProcessId, CommandLine

Then check whether anything is talking to the hard-coded server:

1

netstat -ano | findstr "51.89.204.28"

And tie that connection back to the process behind it:

1

Get-NetTCPConnection -RemoteAddress 51.89.204.28 | Select-Object OwningProcess, RemoteAddress, RemotePort, State

That server address is a single hard-coded IP, 51.89.204.28, sitting on a rented OVH range, with no backup and no domain to fall back on. Right now the address has a clean abuse record, which is how it stays quiet. One address, no fallback, means one firewall rule takes it offline the moment you know it.

What to do:

• → Block traffic to 51.89.204.28 on port 4444, and the file hashes in the IOC table
• → Alert on charmap.exe spawning any child process, which it has no reason to do
• → Watch for a second explorer.exe tied to a non-standard desktop
• → Watch for a browser started with odd flags, Firefox with -no-remote-profile or Chrome with --disable-gpu, a habit of hidden VNC tools
• → Watch for unexpected AutoIt activity and new entries in the Startup folder
• → Flag outbound connections to odd high ports
• → It still has to reach the machine first, through phishing or a fake installer, so do not run files you did not ask for

MedusaHVNC is Windows only. The hidden desktop, the charmap injection, the AutoIt stage, the AMSI and ETW tricks, all of it is Windows. Linux and macOS are not affected.

I cover penetration testing, privilege escalation, persistence, and living off the land step by step in my ethical hacking course. → Check out my complete ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

BlackFog | CISA | IBM DeepSec 2017