Browser Credentials

Extracting Credentials from the Browser's Credential Store

Web browsers have evolved into essential tools for accessing various online services, often storing user credentials to facilitate swift logins. These credentials, typically saved in encrypted databases, are enticing targets for attackers. The process of extracting credentials from a browser's credential store or database involves several steps, requiring specific methods and tools.

The initial step involves identifying the storage location of the credentials. Different browsers use various formats and locations for storing this data. For example, Google Chrome stores credentials in a SQLite database named Login Data, located in the user's AppData directory on a Windows system. Firefox, in contrast, stores credentials in JSON files like logins.json and, in older versions, uses files such as key3.db and signons.sqlite. These storage locations and formats are critical for attackers to understand to effectively extract credentials.

Once the storage location is identified, attackers need to gain access to the database file. This access can be achieved through several methods. If the attacker has physical access to the device, they can directly access these files. However, more commonly, attackers gain remote access through malware. This malware is often deployed using social engineering tactics, such as phishing emails, or by exploiting software vulnerabilities. The malware is designed to run with elevated privileges, allowing it to access files that would otherwise be protected. By gaining such access, the attacker positions themselves to manipulate the system's stored data.

After securing access to the database file, the next step is to extract the data contained within. This extraction process involves running SQL queries to retrieve the encrypted credentials. For instance, in Google Chrome, attackers can query the logins table within the Login Data SQLite database to pull out the encrypted usernames and passwords. These queries are typically automated using scripts or specialized tools designed for this purpose, which streamline the process and reduce the likelihood of detection.

The extracted credentials are encrypted, so the attackers must decrypt the credentials to use the information. The decryption process is often tied to the user’s operating system profile. On a Windows system, for example, Google Chrome uses the Data Protection API (DPAPI) to encrypt and decrypt stored credentials. Attackers can leverage functions such as CryptUnprotectData to decrypt the credentials if they have access to the user's logon session or can mimic the user environment through the malware. This decryption process involves extracting the encryption keys, which are stored within the operating system’s secure storage.

Once the credentials are decrypted, attackers now have access to plaintext usernames and passwords. These credentials can then be used to log in to the victim’s accounts, leading to further exploitation. If users have reused passwords across multiple sites or services, the impact can be extensive, giving attackers access to a wide range of services and potentially sensitive information. This scenario underscores the importance of unique, strong passwords for different services to mitigate the risks associated with credential reuse.

Acquiring Credentials by Searching Web Browser Process Memory

Another method attackers use to acquire credentials involves searching the web browser's process memory for patterns that match credential formats. This technique exploits the fact that during normal operation, web browsers often handle credentials in plaintext within their process memory, even if they store them in encrypted form on disk. The process of acquiring credentials through memory searching involves several critical steps and techniques.

Initially, attackers must gain access to the browser’s process memory. This access is typically achieved through malware that runs with elevated privileges on the user’s system. Techniques such as process injection, rootkits, or direct memory access (DMA) attacks are commonly used to facilitate this access. Malware can be deployed through various vectors, including phishing attacks, malicious downloads, or exploiting known vulnerabilities in the operating system or other installed software.

Once the malware has access to the browser's process memory, it begins scanning for patterns that correspond to credential data. These patterns include common strings like “username” and “password” or regular expressions that match email addresses and typical password structures. The scanning process involves analyzing the memory contents in real-time, as users enter their credentials into login forms or as the browser handles stored credentials during user sessions. This real-time analysis allows the malware to capture credentials immediately as they are processed by the browser.

The malware extracts any data matching these patterns and stores the relevant information, which can include usernames, passwords, session tokens, and other sensitive data. This extracted data is then either stored locally or transmitted back to the attacker’s command and control (C2) server in real-time. The transmission of this data can be performed stealthily to avoid detection by security software. By transmitting the data in small, inconspicuous packets, the malware minimizes the risk of detection and maximizes the likelihood of a successful breach.

Detection Strategies

Monitoring Access to Browser Profile Directories

First, focus on identifying processes attempting to access credential files in browser profile directories. These directories store essential user data, such as cookies, browsing history, and login credentials. Processes that attempt to access these directories but are not legitimate browser processes (e.g., chrome.exe, firefox.exe, and msedge.exe) should be flagged. This strategy targets non-legitimate processes trying to access browser directories that contain credentials.

GrantedAccess Values and Memory Manipulation

Second, focus on processes with suspicious GrantedAccess values interacting with chrome.exe, firefox.exe, and msedge.exe. The specified access rights can allow a process to read from or write to another process's memory. Such access is often sought by malware attempting to extract credentials from a running browser. By monitoring these specific access rights, you can detect attempts to manipulate the memory space of browser processes.

Memory Protection Changes via System Calls

Using the CallTrace field in Sysmon EventID 10 to monitor for NtProtectVirtualMemory calls is also essential. This system call is often used by attackers to change the memory protection of browser processes, allowing them to read or execute code. By focusing on specific browser processes (chrome.exe, firefox.exe, msedge.exe), you can detect attempts to manipulate the memory of these applications.

Suspicious Access to Credential Storage Files

Monitor processes with suspicious granted access permissions for access attempts to credential storage files. These access masks include PROCESS_VM_READ, which allow a process to read another process’s memory or files. Make sure to exclude common browser processes from this monitoring to reduce false positives.

Unsigned Modules in Browser Processes

Lastly, modules like freebl3.dll, sqlite3.dll, mozglue.dll, nss3.dll, and softokn3.dll are associated with browser functionalities, including security and data storage. It is important to monitor for processes that are not signed and that load these specific modules into memory, as these could indicate malicious activity.