ATTACKERS ARE HIDING INSIDE VIRTUAL MACHINES NOW — AND YOUR ANTIVIRUS CAN'T SEE THEM

The QEMU Backdoor: When Your Virtualization Tool Becomes the Intrusion

Here's a scenario that should keep every security team up at night: an attacker gains access to your network, then instead of deploying traditional malware that your endpoint detection tools might catch, they simply boot up a fully functional virtual machine inside your infrastructure. A machine that your security tools literally cannot see into.

That's not a thought experiment. It's happening right now.

Sophos researchers have published detailed findings on two distinct attack campaigns — tracked as STAC4713 and STAC3725 — both weaponizing QEMU, the legitimate open-source machine emulator and virtualizer, as a covert backdoor for credential theft and ransomware delivery.

How It Works: The Invisible Attack

The elegance (from the attacker's perspective) is brutal. QEMU is a trusted, widely-used, digitally-signed piece of software. It's not flagged as malicious because it isn't malicious. It's a tool — a hammer that the attacker is using to break into your house, but it's a hammer you might legitimately own.

Here's the attack chain in the STAC4713 campaign, linked to the PayoutsKing ransomware operation:

1. A scheduled task named TPMProfiler runs qemu-system-x86_64.exe under the SYSTEM account — because nothing says trustworthy like a TPM profiler, right?
2. The task boots a virtual hard disk image disguised as bisrv.dll (previously vault.db) — file extensions chosen specifically to blend into legitimate Windows system files.
3. The VM sets up port forwarding from custom ports (32567, 22022) to port 22 for SSH access.
4. On boot, the image establishes a reverse SSH tunnel via AdaptixC2 or OpenSSH to a remote IP — a hidden remote access channel that completely bypasses endpoint detection.
5. Inside the VM: an Alpine Linux image preloaded with an attacker's toolkit — Linker2, AdaptixC2, a custom WireGuard traffic obfuscator, BusyBox, Chisel, and Rclone.

The second campaign, STAC3725, is even more aggressive. It enters through the CitrixBleed2 vulnerability (CVE-2025-5777), installs a malicious ScreenConnect client for persistence, then deploys a QEMU VM to harvest Active Directory credentials. But instead of a pre-built toolkit, attackers manually compile their full attack suite inside the VM — Impacket, KrbRelayX, Coercer, BloodHound.py, NetExec, Kerbrute, and Metasploit, with supporting libraries for Python, Rust, Ruby, and C.

Why This Is Different

This isn't your standard malware attack. The key distinction: the malicious activity happens inside a virtual machine. Security controls on the host system cannot see what happens inside a hidden VM. Traditional endpoint detection and response (EDR) solutions monitor processes, file system changes, and network traffic on the host — but a QEMU VM creates an entirely separate execution environment.

It's like having a room inside your house that your security cameras can't see into. The cameras still work. The doors are still locked. But someone is living in that hidden room, and they have access to everything.

The forensic evidence left behind is minimal, too. When the VM shuts down, most of the artifacts vanish with it. No persistent malware on the host. No suspicious processes. No unusual file modifications. Just a few configuration changes and a scheduled task that looks like it belongs there.

Two Attackers, One Playbook

What makes these campaigns particularly interesting is how different they are in execution but identical in concept:

The Bigger Trend: Living Off the Land, But Virtualized

QEMU abuse is part of a broader shift in attacker methodology. We've seen "living off the land" techniques for years — attackers using legitimate tools like PowerShell, WMI, or certutil instead of dropping custom malware. QEMU abuse takes this concept to its logical extreme: why just use legitimate tools when you can boot an entirely legitimate operating system that your target's security infrastructure is blind to?

The technique isn't brand new — researchers have documented VM-based evasion since at least 2017 — but the increasing sophistication and frequency of QEMU-based attacks in 2025-2026 signals a worrying trend. As EDR solutions get better at detecting traditional malware, attackers are moving to environments that those solutions simply can't monitor.

What You Can Do About It

Defending against virtualization-based attacks requires a different mindset:

• Monitor for QEMU processes on systems where virtualization isn't expected. If qemu-system-x86_64.exe appears on a workstation or domain controller, that's a red flag the size of a barn.
• Audit scheduled tasks rigorously. An attacker-created task named TPMProfiler running as SYSTEM should immediately trigger investigation.
• Restrict virtualization software deployment. Use application whitelisting to control which systems can run QEMU, VirtualBox, or other virtualization tools.
• Network segmentation matters more than ever. Unusual outbound SSH connections from QEMU processes should be blocked at the network level.
• Monitor for unusual disk images with suspicious extensions (.dll files that are actually virtual disks, for instance).
• Patch CitrixBleed2 and similar edge vulnerabilities — STAC3725 gained initial access through a known vulnerability in Citrix NetScaler.

The Arms Race Continues

The QEMU backdoor campaigns illustrate a fundamental truth about cybersecurity: defenders build walls, attackers find doors. Or in this case, they build entire hidden rooms inside your walls.

As endpoint detection gets more sophisticated, attackers will continue to seek environments that are invisible to those detection systems. Virtual machines are just the latest evolution of a cat-and-mouse game that shows no signs of slowing down.

The question isn't whether your EDR can catch malware on your host OS. The question is: can it detect an entire operating system running inside your operating system? For most organizations today, the answer is no.