VoidStealer: The Sleeper Malware Hijacking Chrome, Edge, and Copilot

5 min. read

Let’s talk about the latest garbage fire brewing on the MSP and sysadmin subreddits. If you have been watching your EDR telemetry lately, you might have noticed some incredibly weird behavior originating from browsers. We are tracking a new, highly evasive infostealer currently dubbed "VoidStealer" (often flagged generically as Win.Trojan.VoidStealer.lyca or Win.Trojan.Stealergen), and it is an absolute nightmare to hunt.

Right now, the major security vendors are doing what they always do when a new zero-day behaviour drops: shrugging their shoulders and waiting for someone else to publish the Indicators of Compromise (IoCs). There is practically zero solid documentation on prevention methods out there. So, we have to tear this apart ourselves.

Here is what we know about the attack chain. It almost always starts with a legitimate, highly trusted process like chrome.exe, msedge.exe, or ironically, Microsoft’s shiny new mscopilot.exe. A user clicks a bad link, gets hit by a weaponised ad network, or installs a sketchy extension. But instead of detonating immediately and triggering your EDR alerts, the malicious payload goes to sleep inside the browser process.

This is a calculated sandbox evasion tactic. Most automated EDR sandboxes will detonate a suspicious file, watch it for five to fifteen minutes, and if nothing blows up, they stamp it as "benign" to save compute cycles. VoidStealer knows this. It hooks into the browser thread and waits... sometimes for hours, sometimes for days. Once the sandbox times out and the EDR stops looking closely, it wakes up.

When the timer pops, you suddenly see the browser process start writing randomly named executables (like radB3F1.exe) directly into %USERPROFILE%\AppData\Local\Temp.

From a technical standpoint, this is a masterclass in abusing trusted execution paths. The malware likely uses Process Hollowing or DLL Side-Loading to hide its malicious thread inside the browser. Because the thread is running under the PID of Chrome or Edge, any command-and-control (C2) network traffic it generates just looks like standard HTTPS web browsing.

Worse, it executes from the Temp folder. Malware authors love the user Temp directory because it is universally writable, and EDRs traditionally treat it with kid gloves. Legitimate software installers, from Zoom to Adobe, dump executable junk into the Temp folder all day long. If your EDR blocked every .exe running from Temp, your helpdesk would be paralyzed by false positives. VoidStealer exploits this exact operational blindspot.

Once that random executable runs, the real damage happens. It immediately goes after the SQLite databases where Chromium-based browsers store session cookies and passwords (\User Data\Default\Login Data and \Network\Cookies). By piggybacking off the browser process, the malware bypasses the file-lock restrictions that usually protect those databases while the browser is open. It packages your clients' session tokens, saved passwords, and crypto wallets, and ships them out the back door.

The inclusion of mscopilot.exe as a host process is the most infuriating part of this. Because Microsoft integrates Copilot deeply into Windows 11 and updates it constantly, a lot of legacy AVs and lazy MSPs have slapped broad exclusions on Copilot binaries to stop CPU spikes. If you blindly whitelisted Copilot, you just gave this infostealer a VIP pass to bypass your stack entirely.

Since the vendors are dragging their feet on static hashes, you need to rely on behavioral hunting. Don't wait for an update... Get into your RMM or EDR platform and start looking for the anomalies. If you are running Sysmon, you need to be querying for Event ID 8 (CreateRemoteThread) or Event ID 10 (ProcessAccess) where the source is a browser executable.

If you use Defender for Endpoint, run this KQL query in Advanced Hunting immediately to see if you have sleeping agents in your tenants:

Code snippet

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "mscopilot.exe")
| where FileName endswith ".exe"
| where FolderPath has @"\AppData\Local\Temp\"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath, ProcessCommandLine

If you catch this behavior, assume the host is compromised. Do not just kill the Temp executable. Isolate the machine from the network, wipe the Temp directories, kill the parent browser process tree, and immediately go into Entra ID to revoke MFA sessions for that user. Until the vendors catch up, we are on our own. Write your custom rules, audit your blindspots, and stop trusting the browser.