Vidar Malware Successfully Evades Google Chrome’s Application-Bound Encryption
In a significant development in the world of cybersecurity, operators of the Vidar infostealer malware have successfully devised a sophisticated evasion technique that bypasses Google Chrome’s Application-Bound Encryption (ABE). Introduced in 2024, ABE was specifically designed to enhance the security of browser-stored cookies and sensitive credentials, ensuring that personal information remained protected from unauthorized access.
Recent research conducted by Gen Threat Labs reveals that the latest versions of Vidar are now being updated weekly, incorporating intricate methodologies including a chain of process forking, memory pattern scanning, and Asynchronous Procedure Call (APC) injection. These advancements enable attackers to directly extract the browser’s master decryption key from live memory, thereby circumventing the protections that ABE was meant to enforce.
At the core of Chrome’s ABE mechanism is the connection of sensitive data encryption to the specific application that created it. For modern infostealers like Vidar, the ultimate objective is to acquire the browser’s v20_master_key, a vital asset that allows for the decryption of ABE-protected data such as cookies and credentials. This master key is stored on disk, secured behind two layers of CryptProtectData.
In memory, the Chrome browser adds another layer of protection using CryptProtectMemory alongside the CRYPTPROTECTMEMORY_SAME_PROCESS flag. Because of this specific memory protection, attackers face challenges in extracting the encrypted key and decrypting it offline. The decryption of the key can only be performed by invoking the complementary CryptUnprotectMemory function from within the active browser process, creating substantial barriers for infostealers.
Traditionally, attackers struggled to extract key material outside of the browser’s process context, as the security measures in place halved their options. Instead of relying on disk-based extraction, Vidar cleverly targets the browser’s live memory. When Chrome is operational, the malware opens a handle to the browser process that has specific read permissions and invokes NtCreateProcessEx with a null section handle. This process creates a silent, threadless fork of the browser, yielding a memory snapshot that avoids triggering security alerts from endpoint protection tools.
In cases where no instance of Chrome is active, Vidar executes a hidden version of the browser using a command designated as CreateDesktopA. This instance is uniquely named in the format v20_%d, and is run with parameters that disable primary functions like GPU acceleration, effectively creating a low-profile execution without drawing attention.
Once this process is established, Vidar embarks on a meticulous search of the virtual memory via NtQueryVirtualMemory. Utilizing up to 64 parallel worker threads, the malware scans through committed and readable memory regions, hunting for a targeted 32-byte pattern. This pattern maps to the sequence decoding as the ASCII string v20\x00, which correlates to a specific node within Chromium’s internal Encryptor::KeyRing.
The KeyRing structure is critical as it stores the keys used for ABE encryption, and identifying this pointer leads directly to the encrypted master key. Vidar uses a majority-voting approach to accurately validate potential candidates from the memory, effectively filtering out incorrect, zero-filled entries.
Upon locating a probable candidate address, Vidar must execute CryptUnprotectMemory from within the live browser process. This step involves APC injection, and the malware adopts one of two methodologies, contingent upon the operational security environment:
-
Classic Method: Engaged when security products like ESET or Bitdefender are detected. This approach creates a suspended remote thread to queue an APC and resumes the thread to execute the necessary functions.
- Special Method: This default strategy locates an existing browser thread and queues a specific user APC that executes immediately, circumventing the need for an alertable wait state.
According to Gendigital, the APC function decrypts data in place, leaving no forensic traces. Vidar proceeds to create a second fork of the process to safely read the decrypted key using NtReadVirtualMemory. The validity of the extracted key is verified through an AES-256-GCM decryption attempt of the ABE-protected data using BCryptDecrypt.
To mitigate any risk of detection, the malware swiftly injects a subsequent APC to re-encrypt the key in memory, thereby returning the browser to its prior state. If all attempts at decryption fail across the candidates, Vidar escalates by terminating all browser instances and relaunching them to initiate the extraction process from scratch.
This methodology adeptly avoids traditional code injection techniques by leveraging legitimate Windows APC functionalities, aspects that many endpoint detection systems tend to overlook. As a result, security teams are urged to refine their detection strategies to tackle this evolving threat landscape.
Threat hunters are specifically encouraged to scrutinize endpoint detection rules for suspicious NtCreateProcessEx calls featuring null section handles, as well as unexpected APC queuing directed into active browser threads. A primary Indicator of Compromise (IoC) that organizations should monitor for is the Vidar 2.1 SHA-256 hash: 459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a.
With the landscape of cyber threats continually evolving, staying ahead of sophisticated techniques like those employed by the Vidar malware is essential for maintaining cybersecurity integrity.