A sophisticated evasion technique developed by Vidar infostealer operators successfully bypasses Google Chrome’s Application-Bound Encryption (ABE). Introduced in 2024, ABE was designed to protect browser-stored cookies and sensitive credentials.
According to recent findings by Gen Threat Labs, the latest iterations of Vidar are now dropping weekly updates that utilize a complex chain of process forking, memory pattern scanning, and Asynchronous Procedure Call (APC) injection to extract the browser’s master decryption key directly from live memory.
Chrome’s ABE mechanism ties sensitive data encryption to the specific application that created it. The primary objective for any modern infostealer is obtaining the browser’s v20_master_key, which allows attackers to decrypt ABE-protected data such as cookies and credentials. On disk, this key sits behind two layers of CryptProtectData.
In memory, Chrome secures it using CryptProtectMemory coupled with the CRYPTPROTECTMEMORY_SAME_PROCESS flag. Because of this specific memory-protection flag, attackers cannot simply extract the encrypted key and decrypt it offline.
Vidar Bypasses Chrome’s ABE Encryption
The key can only be decrypted by invoking the complementary CryptUnprotectMemory function directly from within the active browser process, forcing threat actors to execute code within that specific context
This creates a significant barrier for infostealers, as attackers cannot simply decrypt key material outside the browser’s process context. Rather than attempting disk-based extraction, Vidar circumvents this by targeting the browser’s live memory.
When Chrome is running, the malware opens a handle to the process with specific read permissions and calls NtCreateProcessEx with a null section handle.
This creates a silent, threadless fork of the browser, forming a frozen copy-on-write memory snapshot that does not trigger active execution or alert endpoint security tools.
If no Chrome instance is running, Vidar launches a hidden instance using a CreateDesktopA command. It names the hidden desktop in the format v20_%d and executes it using the command line --no-first-run --disable-gpu about:blank.
Once the process is forked, Vidar enumerates the virtual memory using NtQueryVirtualMemory. It deploys up to 64 parallel worker threads to scan committed and readable memory regions for a specific 32-byte pattern.
The malware specifically hunts for a sequence decoding to the ASCII string v20x00, which correlates to a node within Chromium’s internal Encryptor::KeyRing.
This map structure stores ABE keys, and the identified pointer leads directly to the encrypted master key. Vidar validates candidates using a majority-voting scheme to successfully filter out zero-filled false positives.
After identifying the candidate address, Vidar must execute CryptUnprotectMemory from within the live browser process. It achieves this through APC injection, utilizing one of two distinct methods based on the host’s security environment:
- Classic Method: Deployed when security solutions like ESET or Bitdefender are detected, creating a suspended remote thread to queue an APC and resuming the thread to execute the routine.
- Special Method: The default approach locates an existing browser thread and queues a special user APC that executes immediately without requiring an alertable wait state.
Gendigital revealed that the APC function decrypts data in place, and Vidar creates a second process fork to safely read the decrypted key via NtReadVirtualMemory. It validates the extracted key by attempting an AES-256-GCM decryption of the ABE-protected browser data using BCryptDecrypt.
To avoid leaving forensic traces, the malware immediately injects a follow-up APC to re-encrypt the key in memory, restoring the browser’s original state. If decryption fails across all candidates, Vidar escalates by terminating all browser instances and relaunching them to repeat the full extraction cycle.
This methodology notably avoids traditional code injection by instead exploiting legitimate Windows APC mechanisms that many endpoint detection systems fail to monitor closely. Security teams must adapt their detection strategies to identify this evolving threat.
Threat hunters should specifically review endpoint detection rules for suspicious NtCreateProcessEx calls featuring null section handles, as well as unexpected APC queuing directed into active browser threads.
As a primary Indicator of Compromise (IoC), organizations should monitor their environments for the Vidar 2.1 SHA-256 hash 459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
