I am pleased to introduce the first module for my latest project, BrowserGather. BrowserGather is an entirely fileless web browser information gathering tool for red teamers, written in PowerShell to compliment tools such as Empire and PowerSploit. The Get-ChromeCreds module allows for the extraction of Chrome credentials without the need to write to disk, making it much stealthier than previous techniques.
As you may already know, the Chrome browser provides the option of storing passwords locally on a user’s device. On Windows, these passwords are stored in the user’s directory as a SQLite database file. The passwords are encrypted at rest via the Windows Data Protection API. This encryption is fairly trivial to decrypt, so the main challenge is to extract the information from the SQLite database without writing to disk. As we will soon find out, this is much harder than one might assume!
After learning about the existence of the SQLite database, the first step was to find a way to interact with it via PowerShell. Luckily, a .NET assembly exists that allows for PowerShell to do exactly that. The next step was to figure out a way to load this assembly into PowerShell without writing to disk. Although there is a method that exists for in-memory loading of DLLs via PowerShell, described by mattifestation here, I quickly found out that it was not applicable in this situation. For whatever reason, Microsoft has decided that mixed-mode assemblies (assemblies that include both native code and managed code) cannot be loaded into PowerShell via memory, and must be loaded from a file. This is why previous methods for Chrome credential extraction, such as the one provided by Empire, first write the SQLite assembly DLL to disk before loading.
Undeterred, I first attempted to convert the SQLite assembly from mixed-mode to pure managed code. I won’t go into detail here, but attempts to compile the code with the /clr:pure flag were an abject failure. My next thought was to try and open the database with a hex editor and see if there may be some way to extract the data, without needing to utilize the SQLite assembly. I found that there were certain patterns in the raw hex that I could use to create regex patterns and extract the data. Using mattifestation’s technique for performing regular expression extractions on binary data, I was finally able to build a working PowerShell module. You can find the code on my Github.
Please note that from a purely functional standpoint, this method is less effective than using the SQLite assembly. There is a very high probability that any changes Google or the SQLite developers make to the database will break the technique, and require changes to be made. This method is intended for red teamers who need to minimize the footprint they leave on victim’s machine as much as possible during an engagement.
That being said, I did notice an interesting quirk when I used the technique on my primary machine. More passwords appeared using this technique than even Chrome reported! Evidence of this is shown in the following image, where output from this technique is compared against Nirsoft ChromePass:
I tried to replicate the issue on a VM, but was unable to do so. It appears that at some point during development, Chrome did not sync saved passwords between different machines; this is no longer the case, possibly due to the introduction of Google Smart Lock. Therefore, if you have been using Chrome for a while, you might have old passwords on your system and not even realize it!
Update: I have released the second part of the BrowserGather project, for fileless Chrome credential extraction. Check it out!
- wald0, tifkin_, and harmj0y for requesting this project.
- mattifestation for the many reasons listed above.
- et0x for his existing work on PowerShell-based Chrome credential extraction, located here.
- xorrior for his previous work on Empire and providing guidance.
- Coalfire/Veris Group, for allowing me to develop this project.