A sophisticated new technique employed by the Vidar infostealer to bypass Google Chrome’s Application-Bound Encryption (ABE), a security mechanism introduced in 2024 to protect cookies and credentials stored by the browser.
Documented by Gen Threat Labs, the latest Vidar versions now drop weekly updates, using a combination of process forking, memory pattern scanning, and APC injection to extract the browser’s master decryption key directly from live memory.
Chrome’s ABE ties sensitive data encryption to the specific application that created it, binding the v20_master_key to the browser process via CryptProtectMemory with the CRYPTPROTECTMEMORY_SAME_PROCESS flag.
This means any attacker reading encrypted key material from memory cannot simply decrypt it outside the browser’s process context a significant barrier for infostealers. Rather than attempting disk-based extraction, Vidar targets the browser’s live memory.
Vidar Malware Bypasses Chrome Encryption
When a Chrome process is running, Vidar opens a handle to it using OpenProcess with PROCESS_CREATE_PROCESS | PROCESS_VM_READ permissions, then calls NtCreateProcessEx with SectionHandle set to NULL.
This creates a silent, threadless fork of the browser, a frozen copy-on-write memory snapshot that does not trigger active execution or alert security tools.

If no browser is running, Vidar launches one on a hidden desktop created via CreateDesktopA, naming it in the format v20_%d, using the command line --no-first-run --disable-gpu about:blank.
Vidar then enumerates the forked process’s virtual memory using NtQueryVirtualMemory, collecting up to 4,096 committed, private, and readable/read-write memory regions. Up to 64 parallel worker threads scan these regions via NtReadVirtualMemory, searching for a specific 32-byte pattern:
76 32 30 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? 03 00 00 00 00 01 ?? ?? ??
The first four bytes decode to the ASCII string v20\x00 matching a node within Chromium’s internal Encryptor::KeyRing, a std::map structure that stores ABE keys.
The pointer at offset +32 from the match points directly to the encrypted v20_master_key stored inside a std::vector<uint8_t>. Candidates are validated through a majority-voting scheme to filter out zero-filled false positives.
Once a candidate’s address is identified, Vidar must invoke CryptUnprotectMemory from within the live browser process itself. It does this through Asynchronous Procedure Call (APC) injection, selecting one of two methods based on the security software detected on the system.
- “Classic” method (used when ESET or Bitdefender is present): Creates a suspended remote thread in the browser via
CreateRemoteThread, queues an APC usingNtQueueApcThread, then resumes the thread to flush and execute the routine. - “Special” method (default): Locates an existing browser thread via
CreateToolhelp32Snapshot, opens it withNtOpenThread, and queues a special user APC usingNtQueueApcThreadEx2withQUEUE_USER_APC_FLAGS_SPECIAL_USER_APC— which executes immediately without requiring an alertable wait state.
In both cases, the APC payload is CryptUnprotectMemory called with the candidate address, 32-byte size, and CRYPTPROTECTMEMORY_SAME_PROCESS.

Since the function decrypts data in place, Vidar creates a second process fork and reads the now-decrypted key via NtReadVirtualMemory. It validates the key by attempting AES-256-GCM decryption of ABE-protected browser data using BCryptDecrypt.
To avoid leaving forensic traces, Vidar re-encrypts the key in the browser’s memory by injecting a follow-up APC calling CryptProtectMemory, restoring the browser’s original state.
Gendigital stated that if decryption fails across all candidates, Vidar escalates, terminating all browser instances, relaunching them, and repeating the full cycle.
This technique is notable for avoiding NtWriteVirtualMemory-based code injection, instead abusing legitimate Windows APC mechanisms that some endpoint detection systems may not monitor as closely.
Combined with recent updates to Vidar’s string obfuscation and configuration protection, this evolution signals that infostealer developers are investing heavily in research on ABE bypass.
Security teams should review EDR rules for suspicious NtCreateProcessEx calls with null section handles and APC queuing into browser threads as key detection opportunities.
Indicator of Compromise (IoC)
459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a (Vidar 2.1)
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.