Browser Credential Stealing Detection
Credential dumping is a common technique used by adversaries to compromise credentials from a system. Particularly, extracting password or hash from LSASS process is the best known method. EDR and antivirus vendors paid a lot of effort on detecting LSASS dump related attacks. However, browser credential stealing attacks such as obtaining stored credential and cookies from browser are often forgotten and not detected.
Therefore, I am writing this blog to walkthrough a way that could be used to detect a potential browser credential stealing attack.
Since browser credential stealing attack will involve object access activities to some specific files (e.g., Cookies, Login Data), we will first enable the "Audit File System" via group policy.
"Computer Configuration" -> "Policies" -> "Windows Settings" -> "Security Settings" -> "Advanced Audit Policy Configuration" -> "Audit Policies" -> "Object Access" -> "Audit File System"
Then we can force a group policy update on the testing workstation using "gpupdate.exe".
Next we will identify which files will be accessed during the execution of browser credential stealing attack and particularly audit all file read activities under the "C:\Users\<username>\AppData\Local\Google\Chrome\User Data" application data directory.
To do so, you are required to configure the System Access Control List (SACL) for that particular file/folder object using the following steps:
- 1.Right click the target file/folder and select "Properties"
- 2.Select "Security" tab and click "Advanced"
- 3.Select "Auditing" tab and click "Continue"
- 4.Click "Add" to insert a new auditing entry
- 5.Click "Select a principal" and insert "Everyone"
- 6.Click "Clear all" in the permissions and click "Show advanced permissions"
- 7.Tick "List folder / read data" and save all the changes
Access Control Entry (ACE) in a SACL will be used to determine what types of access is logged in the event log.
Once the SACL is configured, we will execute well-known offensive security tools (e.g., SharpChrome, Mimikatz) that perform browser credential stealing attack and validate corresponding file read activities in the Windows event log.
SharpChrome.exe cookies
SharpChrome.exe logins
mimikatz dpapi:chrome
"execute-assembly" and "chromedump" command in Cobalt Strike adopted "fork and run" approach so new process will be spawned for each execution. The process to spawn could be customized in the Cobalt Strike malleable profile or "spawnas" command. In this demonstration, "C:\Windows\System32\werfault.exe" was used for "fork and run". Therefore, the 4663 Windows event log will show "werfault.exe" in the "Process Name" field.
By checking the Windows 4663 events (An attempt was made to access an object) in the Event Viewer, we will be able to identify the following files were accessed during the execution:
- C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Local State
- C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies
- C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies-journal
- C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Login Data
- C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Login Data-journal
Similar to Google Chrome, credential dumping against Microsoft Edge will generate file access events in the following file paths:
- C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Local State
- C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies
- C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies-journal
- C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\Login Data
- C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\Login Data-journal
So now you have all the file objects you need for monitoring. Similar to the above, you could tailor the SACL to monitor all "List folder / read data" events on these specific files.
Monitor all file events on the entire "C:\Users\<username>\AppData\Local\Google\Chrome" folder is also a reliable way. However, this SACL configuration will generate a lot of unnecessary file events. Therefore, I would suggest to narrow down the SACL auditing scope to file based monitoring.
Once the SACLs are configured, the workstation will only generate 4663 event log when "Login Data", "Cookies", and "Local State" are accessed.
To identify a potential browser credential stealing attack among these 4663 event logs, the key indicator will be the "Process Name" field in the Windows 4663 event. Generally, only browser related process (i.e., chrome.exe) will access browser application files. If you identified non-browser process (e.g., werfault.exe) accessing these files, it is possible an indicator of a browser credential stealing attack.
There could be some other enterprise products that will access browser application files legitimately. Therefore, It is always recommended to audit and baseline processes that will access these files in your environment to minimize false positive.
It is also worth to note that file copy to other directory will also trigger ReadData Windows 4663 event.
One detection blind spot for this detection technique will be the attacker could spawn browser process (e.g., chrome.exe) to perform the browser credential stealing attack using "spawnto" and "execute-assembly" in Cobalt Strike. The malicious activity will then be executed using a legitimate browser process that could blend in normal file access event and bypass the abnormal process detection.
I often use browser credential stealing attack in my red team engagement to obtain web credentials and cookies to access critical web based applications and bypass MFA without touching the LSASS. I found this attack is often forgotten when it comes to detection. Therefore, I hope this blog could provide some ideas on how to detect this type of attack using Windows event log 4663.
Last modified 8mo ago