Posted on: July 2, 2025 | Reading time: 8 minutes | Word count: 1646 words | Author: Dang Duong Minh Nhat
Hello everyone, it’s been a while since I last wrote a blog on cybersecurity — especially in the field of red teaming. Today, we’ll explore how to extract a cookies database from one machine and transfer it to another. This technique serves as a foundation for bypassing two-factor authentication (2FA).
Let’s dive into how this process works in the blog below.
Table of Contents
Website Cookies
Website cookies are small blocks of data, typically stored in a database, that websites transfer to your computer or mobile device to store information about you. They allow websites to identify users and remember useful details in order to enhance user experience.
To better understand this, imagine adding items to an online shopping cart — even if you leave the website, those items are still in the cart when you return. That’s thanks to cookies. Other daily conveniences made possible by cookies include staying logged into websites and preserving customized settings.
Cookies can also be used to store information about the websites you’ve visited, thereby providing advertisers with more data to deliver products and services tailored to your lifestyle. Another common implementation of cookies is session storage. A typical example is the “Remember me” checkbox. When you check this box, the website knows how to store a cookie on your device that helps identify you, allowing you to browse without having to log into your account again—unless the cookie expires.
Virtually every modern website uses cookies. According to W3Techs, as of June 24, 2024, 41.3% of all websites use cookies, with major providers such as Google, Facebook, Microsoft, and Apple among them.
Cookies are often used to store sensitive information about users, and some are specifically used to retain user identities through session storage, eliminating the need to re-authenticate each time. However, alongside these benefits, cookies also pose several risks. One of the most notable threats is the potential for user data to be stolen. With access to such sensitive data, malicious actors (i.e., hackers) can do much more than just access your account. We will explore these risks further in this blog.
WEB Browse DATA
On Windows operating systems, the Google Chrome web browser stores Browse cookies in the file C:/Users/%USERNAME%/AppData/Local/Google/Chrome/User Data/Default/Network/Cookies. To insert this database into Google Chrome on another machine, we first need to understand that they are SQLite databases. Therefore, we use an application such as SQLiteStudio to inspect the data contained in these databases.
For the Cookies database, we observe that it consists of two tables: meta and cookies. Notably, the cookies table contains a column named encrypted_value, which is encrypted to provide some protection against cookie theft. On Windows, this value is encrypted using AES-256-GCM. Fortunately, the encryption key is stored by Chrome in a file named Local State, located at C:/Users/%USERNAME%/AppData/Local/Google/Chrome/User Data/Local State.
Figure 1: The Cookies Database.
The encryption of cookies in this manner makes it practically impossible to read the encrypted_value across two different machines. Therefore, our goal is to find a way to enable machine B to read these cookie values. To achieve this, I devised a highly reasonable approach: first, decrypt the cookies on machine A using the encryption key from machine A; then, transfer the decrypted cookies to machine B and re-encrypt them using the encryption key from machine B. In this way, machine B will be able to read the cookie data properly. At this point, we encounter another issue: the encryption key mentioned earlier is stored in the JSON file Local State under the name encrypted_key, which is itself encrypted using DPAPI in Chrome versions prior to version 127.
DPAPI (Data Protection Application Programming Interface) is a simple encryption API integrated into Windows operating systems starting from Windows 2000. It is considered the standard way to store encrypted data on disk for applications running on Windows. DPAPI provides a straightforward set of APIs to encrypt and decrypt opaque data “blobs”: CryptProtectData() is used for encryption, and CryptUnprotectData() is used for decryption. It works by using a secret encryption key that is implicitly tied to a specific user or to the system. This allows applications to securely protect user data without dealing with key management. DPAPI is widely used by popular applications such as Internet Explorer, Google Chrome, and Skype to encrypt their stored passwords. Windows itself also uses DPAPI to store sensitive information such as EFS certificates and WiFi keys (WEP and WPA).
DPAPI encryption is based on the user’s password; therefore, data encrypted under one user account cannot be decrypted by another account. DPAPI also allows restricting access to the data even within the same account by specifying an additional secret, known as entropy. As a result, unless the additional entropy is known, an application cannot access data protected by another application.
However, while DPAPI can protect data at rest from cold boot attacks or from other users on the Windows system, it does not protect against malicious tools or scripts that are designed to execute code as the logged-in user — which is precisely the vector exploited by information-stealing malware.
Therefore, starting from version 127, Chrome introduced a new protection mechanism on Windows to enhance DPAPI by implementing Application-Bound (App-Bound) Encryption. Chrome’s App-Bound Encryption feature uses a new Windows service running under the SYSTEM account to verify the identity of the application requesting encryption. This service binds the application’s identity to the encrypted data, ensuring that only the intended application can decrypt it, and preventing other applications from accessing the data.
Because this service operates with system-level privileges, an attacker would need to gain SYSTEM access or inject code into the protected application (such as Chrome) in order to decrypt the data — a behavior that is neither typical nor legitimate, and thus easier for antivirus software to detect when malware attempts to steal sensitive data. The differences between the two Chrome versions result in some slight changes in the encrypted_value field of the cookies table. To distinguish between them, Chrome adds a three-character prefix to the beginning of each encrypted_value. In the older version, this prefix is v10, while in the newer version it is v20 (as seen in Figure 1, where the encrypted values follow the v20 format).
The key difference in decrypting v20 cookies compared to v10 lies in how the AES key is retrieved. For v10 cookies, the encrypted key (referred to as encrypted_key in the Local State JSON file) only needs to be decrypted using DPAPI. However, for v20, the decryption process involves three stages to retrieve the encryption key (named app_bound_encrypted_key in the Local State file): first, a DPAPI decryption using the SYSTEM account; second, a DPAPI decryption using the user account; and finally, AES-GCM or ChaCha20-Poly1305 decryption of the cookie value.
Due to the distinction between DPAPI decryption under the SYSTEM account (which can be understood as running with administrative privileges and not tied to any specific user) and the user account (which refers to the currently active user), the decryption process for the cookies table on machine A is divided into two steps. First, a partial decryption of the key is performed using the SYSTEM account via DPAPI. Second, a further DPAPI decryption is conducted under the user account. This is then followed by a final decryption using either AES-GCM or ChaCha20-Poly1305 to obtain the actual key and successfully decrypt the encrypted_value entries in the cookies table. The same two-step key decryption process must also be followed when encrypting the encrypted_value entries for the cookies table on machine B.
We begin the exploitation process. First, to execute the code in Step 1 with SYSTEM-level privileges, we use PsTools, which allows us to run a file with administrative rights. Using this, we perform the first-stage DPAPI decryption of the encryption key and save the result to a binary file named intermediate_key.bin (the result is shown in the figure below).
Figure 2: Result of first DPAPI decryption saved to intermediate_key.bin.
Next, we simply perform the remaining decryption steps to recover the final key, and then use it to decrypt the encrypted_value entries in the cookies table. As shown in the figure below, several cookie values are now visible in the database, confirming that the encrypted_value fields were successfully decrypted. For machine B, we perform the same key decryption process to obtain the appropriate encryption key. This key is then used to re-encrypt the encrypted_value entries that were previously decrypted on machine A. Both the encryption and decryption of the encrypted_value field in the cookies table on both machines use the AES-256-GCM algorithm.
Figure 3: Successfully decrypted encrypted_value entries in the database.
Finally, we directly save the re-encrypted database into the existing Cookies database on machine B. Note that it is necessary to terminate any running Chrome processes using the appropriate command before writing to the Cookies database, as it is locked while Chrome is running.
The figure below illustrates the result before and after inserting the record into the database. Initially, the Facebook website had not been logged into; however, after the insertion, it is possible to bypass even two-factor authentication and gain direct access to the Facebook account originally logged in on machine A.
Figure 4: Facebook login status before and after inserting the decrypted cookie record.
All of the source code used in this blog post is available at the following link: https://github.com/dangduongminhnhat/Transferring-Chrome-Cookies
References
- Haboob Team. Abusing Windows Data Protection API. Retrieved from https://www.exploit-db.com/docs/48589
- Alon Zahavi. (2024, August 07). The Current State of Browser Cookies. Retrieved from https://www.cyberark.com/resources/threat-research-blog/the-current-state-of-browser-cookies
- Sergiu Gatlan. (2024, July 30). Google Chrome adds app-bound encryption to block infostealer malware. Retrieved from https://www.bleepingcomputer.com/news/security/google-chrome-adds-app-bound-encryption-to-block-infostealer-malware/
- Stack Overflow. Cookies: Couldn’t able to extract chrome / edge v20 cookies using AES Decryption in python. Retrieved from https://stackoverflow.com/questions/79213980/cookies-couldnt-able-to-extract-chrome-edge-v20-cookies-using-aes-decryption
Connect with Me
Connect with me on Facebook, LinkedIn, via email at dangduongminhnhat2003@gmail.com, GitHub, or by phone at +84829258815.