MITRE ATT&CK Technique T1503: Credentials from Web Browsers

The October 2019 ATT&CK release from MITRE includes updates to techniques, Groups, and Software for both Enterprise and Mobile. The biggest change is the addition of cloud-focused techniques which include 36 new and updated techniques covering adversary behavior against cloud-based platforms. We are pleased to announce that T1503: Credentials from Web Browsers contributed by the Exabeam team has been added to the ATT&CK knowledge base.

Introduction

Many popular Internet browsers provide users the ability to save login credentials, such as a username and password. Saving your login information can simplify the login process for frequently visited websites. Yet, an adversary can place a backdoor and get access to a compromised computer to dump all the encrypted data stored in the web browser. What’s worse? Usually people have the same password across multiple platforms, and adversaries can retrieve the credentials from the collected web browser data and attempt brute force attacks for different accounts.

In the past, few malware have boasted the capability to steal browser-stored credentials. One of them is trickbot, which was updated last year and included a pwgrab32 (password grabber) module which checks for credentials, cookies, autofills from popular web browsers like Chrome, Firefox, Edge and Internet Explorer. Similarly, Vega Stealer which is written in .NET steals browser stored credentials and financial information and checks for key3.db” “key4.db”, “logins.json”, and “cookies.sqlite in the Firefox user profile. As can be seen from past attacks, adversaries are more curious now about browser data as it provides a wealth of information.

If we take an example of the most popular browser, Google Chrome, encrypted passwords are stored in the sqlite database file in “%APPDATA%\..\Local\Google\Chrome\User Data\Default\Login Data”. Below are the steps Chrome performs while storing the password (code snippets from chromium GitHub).

1. When you fill the login form, Chrome checks for a successful login. If it is a successful login and you used a new credential, it will ask if you want to save your password.

Figure 1: After a successful login Chrome will ask if you want to save your password.

2. If you clicked yes, it will call the “Save” function of Chrome’s password manager. Then it calls the add login function to add the credentials.

Figure 2: If you choose to save your password, to add the credentials Chrome will first call the “Save” function of the password manager and then the add login function.

3. An SQL query is performed to store the encrypted data in the login data file.

Figure 3: Showing the SQL query performed to store the encrypted data in the login data file.

4. The password provided is then encrypted using CryptProtectData, a windows API function. The password can be decrypted by the same user with the same logon credentials that were used to encrypt the data.

Figure 4: CryptProtectData, a windows API function, encrypts the password.

Decryption

There are several scripts written in PowerShell/Python on GitHub to decrypt the password or you can pass the decrypted file to the Windows API function CryptUnprotectData. The only caveat is it has to be used on the same machine. Alternatively, you can use Metasploit module enum_chrome to collect user data from Chrome.

Detection

The following steps describe how to detect the techniques in T1503. 

1. Enable auditing for PowerShell Logs (800/4103) as these can be incredibly helpful when trying to piece together malicious PowerShell activity and capture module, script block and transcription block for any abnormal argument or script. As you can see in the screenshot, a script Get-ChromePassword.ps1 was run with the argument as “C:\Users\Admin\AppData\Local\Google\Chrome\User Data\Default\Login Data” to extract the password.

Figure 5: A script Get-ChromePassword.ps1 is run to extract the password.

2. Enable auditing (Event ID – 4663) for the login data file to track any abnormal file accesses. Note these events can be pretty noisy, so only enable auditing for important files or folders. Any file read event (cmd.exe accessing login data file or running any decrypter on the same file) which is not associated with the web browser itself could potentially be malicious and analysts should perform further investigations. In Firefox, you can enable auditing for the logins.json and key4.db file in AppData\Roaming\Mozilla\Firefox\Profiles\<Profile Name>.

How to keep your passwords safe

Use password managers like LastPass and 1Password to store your passwords. These apps provide regular updates and make sure your password is secure and encrypted. However, we have seen some keyloggers in the past which can track your master passwords for these managers. In order to overcome this, consider implementing two-factor authentication for better protection. Additionally, as a browser hygiene uninstall unwanted browser extensions as a number of extensions are found to steal a user’s personal information via browser data. 

Conclusion

While it may sound convenient and useful, storing passwords in web browsers can do more harm than good. Although, most web browsers have raised their security protections, some risks remain, especially if your computer password is breached. With Exabeam Smart Timelines, it is possible to use behavior-based detection to effectively monitor file-read events for password login files and audit for PowerShell-based attacks.