Detecting new- or updated chromium-based extensions

Modern browsers are becoming more and more like operating systems in terms of complexity. They have full control over and insight into end users’ online activity. With browser extensions functionality can be added to the browser, making it easier to use.

However, these browser extensions can be malicious as well. Malicious extensions can be installed (for example) through a malicious app store, masquerading as a legitimate version. Adversaries might exploit these extensions to gain access to credentials, to establish persistent access to systems, or to serve as C2 infrastructure. Once installed, extensions remain fairly undetected. Therefore it is crucial to be able to identify extension activity deviating from normal, expected or benign activity.

This query is aimed at detecting new or updated browser extensions, specifically for Chromium builds.

As mentioned earlier, you want to identify newly installed extensions rapidly to make sure seemingly benign extensions do not create gaping security holes in your environment.

You can find the query here on GitHub, we tagged it as T1176-WIN-001.md.

A few considerations:

• To properly compare activity, start with building a list of trusted sources. In the query, we structured our list based on ‘standard in the browser’, ‘deprecated yet still trusted’ and ‘commonly observed’. You can tweak this to your organization.
• We only query new installations or updates of Chromium extensions post installation of the browser. We do this because we want to identify abnormalities from extension installations.
• You want to filter unknown extensions as fast as possible. We added a sort based on empty ExtensionName field, usually being interesting enough to followup upon.
• Attackers could potentially side-load extensions thus spoofing the ExtensionId of trusted sources. For this to work however, the browser needs to run in developer mode. Secondly, attackers could modify extensions to evade detection; you want to investigate InitiatingProcessFileName to identify this activity.

Example diving into one of our findings

• Running the query results in the following list, please note this is just an example list.

• Validating extensionId’s in CRXcavator can help you identify what you are looking at. For example, you could encounter a VPN & proxy service extension which might not be something you’d want in your organization.

 

 

• Diving deeper into the plugin, you can start exploring many aspects focussing on ‘why’ questions. One thing you also want to be checking is plugin vulnerability, providing additional reasons for prevent the use of it.

 

 

Usage in production

One of the recommendations when implementing a rule like this into production is to keep track of all used Extensions in your organization and periodically look at the risk rating of all Extensions. An attacker might be able to alter a popular Extension with a large install base with additional features that change the risk rating dramatically. Being aware of these changes allows you to quickly take action

Detecting binaries connecting to the internet with an unsigned or untrusted code signing certificate

In order to evade detection, attackers may use binaries to mimic a trusted certificate or modified signed binaries to make outbound network connections. This increases the chance of deceiving users, analysts, or tools and allowing them to execute their use-case. Adversaries for example could copy metadata and signature information from a signed program, then use this as a template for an unsigned program.

This query is aimed at detecting network connections towards non-RFC-1918 IP addresses.

The binary can also be completely unsigned which stands out even more. By combining the network connection events towards non-private IP addresses with the certificate validation information of the binaries in question we can have a fairly trustworthy means of detection.

You can find the query here on GitHub, we tagged it as T1036.001-WIN-001.md.

Considerations

• This search is resource intensive. For example on larger data volumes Defender ATP might complain, restricting the scope.
• Not all unsigned binaries are bad. You probably want to be aware of what binaries exist in your environment and investigate.
• Untrusted binaries are most-likely bad. Revoked certificate are instant red flags.

Usage in production

There are legitimate binaries that are unsigned, even Microsoft supplied ones like powershell.exe. Taking into account the description of this rule it might be called a false positive, however you might want to be interested in connections towards the internet from those as well.