Credential Access - Detecting Browser's secrets stealing

Browser's saved credentials (passwords & permanent cookies) are a juicy target for any attacker for the following reasons:

• elevated privileges are not required
• we all tend to reuse passwords and if not we rely a lot on auto-saving them in the browser
• EDR and AV solutions are quite ineffective at detecting them based solely on their behavior (file read access is a legit action as long as the source process is not a known bad binary)
• Stolen credential allow to log to some web application (business data)

In this short post we will explain you one way to detect rogue processes accessing specific browser's files used to obtain clear text saved passwords, this test is limited to the following browsers, but you can replicate the same logic for other browsers:

• Google Chrome & Opera (both based on chromium browser)
• Mozzila Firefox

Browser's creds dumpers (not in-memory) need to access the following files (mapped per browser):

Windows provide the ability to audit access to chosen folders or files based on the desired audit settings (principal or account, type of access modify, fullcontrol etc. and success of failure attempts):

1st, you will need to edit your GPO advanced audit policy settings to include Object Access > File System:

at this point nothing is logged yet, now we need to deploy a simple PowerShell script (must be run with high privileges) to edit the desired files and folders's audit access control list:

N.B: to reduce generated 4663 events, you can be more specific and change the paths array to point to specific files instead of all the folder and sub-folders & also to set $InheritType to "None" (used to specify that audit settings will be inherited by child objects).

Now let's run the malicious program and check our Security Events:

As can be seen above, you will need to collect 4663 events or use local scheduled task that notifies you based on an events XML filter that exclude legit combination of Process Name and Accesses (usually you will see browser processes, explorer.exe if accessed via GUI, dllhost.exe and eventually backup and restoring related processes). 

From an offensive perspective, it's good to execute your browsers dumping routine from one of those trusted processes (i.e. dllhost.exe or explorer.exe hollowing).

Remember that the same concept can be applied to other sensitive files, below an example of rogue access via renamed rar.exe with an attempt to compress & ex-filtration victim's offline global address book:

Below resulting log:

That's all & remember that key-loggers and browser's creds dumpers are still challenging to detect, test your EDR and AV solution before others do it.