Browser Credential Stealing Detection
5 July 2022
Last updated
5 July 2022
Last updated
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.
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:
Right click the target file/folder and select "Properties"
Select "Security" tab and click "Advanced"
Select "Auditing" tab and click "Continue"
Click "Add" to insert a new auditing entry
Click "Select a principal" and insert "Everyone"
Click "Clear all" in the permissions and click "Show advanced permissions"
Tick "List folder / read data" and save all the changes
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
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.
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.
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.
Once the SACL is configured, we will execute well-known offensive security tools (e.g., , ) that perform browser credential stealing attack and validate corresponding file read activities in the Windows event log.
