September 03, 2024

When on Workstation, Do as the Local Browsers Do!

Written by Megan Nilsen

Purple Team Adversarial Detection & Countermeasures

Table of contents

1 Introduction
2 Browser Extensions
3 Sensitive Data Extraction
4 Examining (Other) Potential Log Sources
5 Conclusion
6 References

1 Introduction

Web browsers are common targets for many different APTs. Tools like Redline Malware or penetration testing tools such as SharpChrome or SharpChromium steal sensitive data like cookies and saved login data, and many others target the installation of browser extensions that can allow for exfiltration of data or other browser-related exploits.

To boot, building detections on browser abuse can be challenging and riddled with false positives due to the sheer volume of data that can waste analyst time and prevent timely identification of key IOCs that may stop more widespread compromise.

This post will seek to provide organizations with high-fidelity template detections based on classic Splunk SPL queries to assist with detecting this activity. It should be noted that this post is not a comprehensive study on all telemetry available to identify these attacks; rather, we will focus on the most accessible means of detection.

It should also be noted that TrustedSec also has community detections that provide some alternate detection opportunities as well as SIGMA detections written by Leo Bastidas @cyberGoatPysOps. While the detections we will build within this blog post are different, they can be used in addition to the original work done by TrustedSec and Leo.

2 Browser Extensions

2.1 Configuring Auditing and SACLS—Browser Extension Installation

Before we can execute attacks, we need to ensure our lab is configured with the proper auditing and SACLs to build the detections within Splunk.

To start, you will need to enable Windows Event ID 4657 in order to detect modifications to the Registry. Ensure you have Registry modification auditing enabled within GPO at the following location:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access

In addition, navigate to Global Object Access Auditing and also enable and configure the SACL.

Figure 2 - Enabling Registry Auditing via GPO

2.2 Installing Extensions (Attack Simulation and Detection)

To simulate an attacker installing a potentially malicious extension, we are also going to install an extension into multiple browsers—in this case, Chrome, Edge, Firefox, and Brave.

For the sake of this use case, we will install the LastPass browser extension. This is obviously not a malicious extension but will work for the purpose of our experimentation.

Figure 4 - Installing LastPass in Chrome

In order to confirm that we can see the installation of the extension in the browser, we will use the string for the LastPass extension, which is hdokiejnpimakedhajhdlcegeplioahd, to ensure the data is ingested into Splunk.

index=main EventCode= 4657 Operation_Type="New registry value created" hdokiejnpimakedhajhdlcegeplioahd 
| table _time, EventCode, host, Account_Name, Process_Name, Object_Name, Object_Value_Name, Old_Value, Old_Value_Type, New_Value, New_Value_Type, Logon_ID

Figure 5 - Identification of Extension in Logs

Now, we can build a baseline detection to see installations of extensions within multiple browsers.

index=main EventCode=4657 Operation_Type="New registry value created" Account_Name!="*$*" Object_Value_Name!="@*" Object_Value_Name!="*_*" Object_Value_Name!="*|*" Process_Name IN ("*chrome*", "*firefox*", "*msedge*", “*brave*”) AND NOT (Object_Value_Name IN ("mhjfbmdgcfjbbpaeojofohoefgiehjai" ```ChromePDFViewer```, "nkeimhogjdpnpccoofpliimaahmaaome" ```Hangouts```))
| table  _time, EventCode, host, Account_Name, Process_Name, Object_Name, Object_Value_Name, New_Value, New_Value_Type, Logon_ID
| stats count by Object_Value_Name, host, Account_Name, Process_Name
| where  len(Object_Value_Name)>14
| sort – count

Figure 6 - Baseline Browser Extension Installation Detection

The obvious issue is that the logs themselves contain the string identifier of the browser extension installed and not the normalized name of the extension. To make things even more fun, the same extension has a different string identifier across browsers, as shown by the extensions boxed in red in the above screenshot.

As far as I’m aware, there is not an easy way to circumvent this—at least not entirely. However, as introduced to me by Mike Spitzer, Splunk tags can be created that allow you to filter by more easily recognizable names.

2.2.1 A Basic Application of Using Splunk Tags

To create a tag, you will first need the parsed field and the value of the extension. In this case, my parsed field is Object_Value_Name, and the string of the LastPass extension is hdokiejnpimakedhajhdlcegeplioahd.

The tag name then becomes the searchable value that allows you to filter data; in this case, I simply named it Chrome_LastPass.

Then the created tag can be used to quickly filter data that matches the key-pair provided by the tag.

tag=Chrome_LastPass
| table  _time, EventCode, host, Account_Name, Process_Name, Object_Name, Object_Value_Name, New_Value, New_Value_Type, Logon_ID

Figure 8 - Basic Detection with Splunk Tag

In addition, you can create multiple tags with the same name but different values. Below, you can see that I have created two (2) new tags named LastPass_Extension; however, the field value pair is different on both tags.

This allows us to query “all” LastPass extensions across multiple browsers without needing to input each value in the search. This provides great value and a potential use case for detecting specific extensions being installed within an organization.

tag=LastPass_Extension
| table  _time, EventCode, host, Account_Name, Process_Name, Object_Name, Object_Value_Name, New_Value, New_Value_Type, Logon_ID
| stats count by Object_Value_Name, Account_Name, host

Figure 10 - Relational LastPass Extension Installation Query With Tags

This video and this reference article here provide great guides to understanding and working with Splunk Tags.

However, the best way to limit the amount of tuning needed to make this detection functional is to limit the approved browsers used within the organization with application controls, and then disallow users to install extensions in the browser via organizational controls in order to ensure only approved extensions can be used.

3 Sensitive Data Extraction

3.1 Configuring Auditing and SACLS—Extracting Sensitive Data From Browsers

Once again, we need to start by ensuring we have auditing enabled for the events we will need to review in the SIEM. In this case, we need Event ID 4663, which can be enabled by:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access > Audit File System

In addition to enabling Event ID 4663 via GPO, you must also specify the folders on the hosts you are looking to audit on, and a SACL must be set in order to ensure auditing coverage is provided.

For the sake of this blog post, I enabled it on the root folder for the browser. However, you can enable finer-grained auditing that would help to reduce the amount of false positives in the logs.

For example, as mentioned in this post, the following specific folders contain the data that is accessed for credential extraction:

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

3.2 Sensitive Information Theft (Attack Simulation and Detection)

To start, I added some fake passwords and saved them into Chrome.

Figure 14 - Saving Credentials in Browser

Next, I used the tool SharpChrome to execute a theft of login data from Chrome. It should be noted that this specific tool only targets Chrome.

Note: This tool was run using elevated privileges.

Figure 15 - Scraping Logins From Browser

We can quickly identify the logs within the system and identify the key values needed to build a high-fidelity detection.

EventCode=4663 Object_Name IN ("*login*", "*Local State", "*cookies*") Object_Type!="Key"
| table _time, Account_Name, Logon_ID, Object_Type, Object_Name, Process_Name, Process_ID
| stats values by Account_Name, Object_Name

In order to expand our existing query, we can also tie in data using Event ID 4688 in order to get more information about the processes involved with the “attack.” It should also be noted that both the detection written previously and the subsequent detection will also catch manual attempts to read the targeted files.

(EventCode=4663 Object_Name IN ("*login*", "*Local State", "*cookies*") Object_Type!="Key" ) OR (EventCode=4688 AND Process_Command_Line!="*splunk*" )
| eval Process = coalesce(Process_ID, New_Process_ID)    
| table  _time, Account_Name, Logon_ID, Object_Type, Object_Name, Process_Name, Process, Process_Command_Line, Creator_Process_Name   
| stats values(*) as * by Process , Account_Name, Logon_ID
| fillnull
| search  Object_Name!=0

Figure 17 - Complex Browser Credential Theft Detections

There are also toolsets that will attempt sensitive information extraction from all identified browsers, such as SharpChromium.

This gets caught by our existing detection with no additional modifications.

4 Examining (Other) Potential Log Sources

DPAPI events can also be generated by attempting to extract sensitive data from browsers. For this activity, we enabled Audit DPAPI Activity within GPO and on the local host.

In many cases, there is mention that Event ID 4693 on the local host will be generated during these attacks. However, in no case during testing was an Event ID 4693 generated, although Event ID 4695 was generated.

While Event ID 4695 provided information about the browsers involved, it contained no information about the accessing processes. Event ID 4695 can be combined with Event ID 4688 to provide all relevant data within one (1) view.

index=main (EventCode=4695 OR EventCode=4688) 
| stats values(*) as * by Account_Name, Logon_ID
| fillnull
| search  Data_Description!=0 
| table  _time, Account_Name, Logon_ID, Process_Name, Process_Command_Line, Creator_Process_Name, Data_Description, Key_Identifier 
| stats  values(*) as * by Logon_ID

Figure 22 - Detection With Event ID 4695 and 4688

5 Conclusion

Browsers can be a high-value target for stored credentials, cookies, or access tokens that may allow attackers to escalate their privileges, move laterally on the network, or gain access to other applications.

Ensuring that access controls are in place to prevent this exposure is a critical piece of defense. However, effort should be undertaken to build detections to supplement this effort and provide valuable baselining that will help analysts recognize abnormal activity in their environment.

I also want to thank several people, they were all a huge help in researching and putting together this post.

Ryan Leese

Andrew Schwartz

Leo Bastidas

Mike Spitzer