Moving up the Assemblyline: Exposing malicious code in browser extensions

Browser extensions are ubiquitous, offering users enhanced functionality and customization. However, they also represent a significant, often overlooked, attack surface. The very nature of extensions—small code bundles with broad permissions and automatic updates—makes them an ideal vector for supply chain attacks. This risk is compounded by the sheer volume of extensions found in enterprise environments: while the median number of unique extensions installed across our customer base is 30, we’ve observed upwards of 3,000 in some environments.

High-profile browser extension compromises, such as the Trust Wallet and Cyberhaven incidents, underscore the urgent need for mitigation against browser extension supply chain attacks. However, mitigation can fail or might not be implemented organization-wide (e.g., if you leverage version pinning). Therefore, a robust strategy for assessing and detecting potentially risky or malicious extension updates within organizations is crucial.

While in-browser telemetry is the gold standard for deep runtime monitoring, this single data source can only detect malicious code after execution and not all security teams have access to it. Furthermore, solely relying on public reporting about malicious extension updates significantly increases dwell time in environments.

This blog details how to leverage Assemblyline, an open-source malware analysis framework, to proactively assess and detect potentially malicious extension updates in your environment. This isn’t just theoretical. Using a simple yet effective workflow, we’ve confirmed that this process would have successfully detected each of the five publicly reported malicious extension updates that we used for our assessment, validating its real-world effectiveness.

The workflow

Since this blog post focuses on assessing extension updates, the core workflow is as follows:

1. Detection and submission: When a new version of an extension is detected in your environment, submit both the old and new extension packages to Assemblyline for static analysis.
2. Analysis and comparison: Once the Assemblyline reports are generated, compare the significant differences between the two versions. This comparison is critical for identifying suspicious changes, such as:
   • New or updated service workers or scripts
   • Statistical deviations from the norm (e.g., increased script entropy)
   • Newly requested permissions
   • New network domains (extracted by Assemblyline)
   • New Assemblyline service detections/signatures present in the new version but absent in the old
3. Alerting: Alerts are raised when predefined detection criteria are met. The next section details a few of the rules we created and their associated “noise” levels.

The results

Over a set of 2,850 total extension version comparisons, we used the above workflow and created five rules to generate alerts. These alerts showed a high concentration of signals tied to suspicious behavior. To validate the efficacy of these detection rules, we backtested them against known real-world compromises, specifically those involving the following extensions:

Crucially, the most effective and lowest-noise detection rule—which looked for new domains being referenced in the extension, new Assemblyline signatures, an updated service worker, and an added or updated content script—successfully identified four of the five real-world compromises (NEW-DOMAIN-NEW-ASSEMBLY-LINE-SERVICE-DETECTIONS-UPDATED-BACKGROUND-SCRIPT-AND-UPDATED-OR-ADDED-CONTENT-SCRIPT).

Specifically, the difference between the previously non-malicious and the newly malicious versions was strongly indicated by three Assemblyline default services: the JsJaws service, the URLCreator service, and the FrankenStrings service. The signatures raised included:

However, the malicious update for the “Color picker tool – geco” was only caught by a broader, less specific detection rule that looks for a new domain being referenced in the extension and a new or updated service worker (NEW-DOMAIN-NEW-OR-UPDATED-BACKGROUND-SCRIPT). Importantly, this rule did raise on all five backtested real-world compromises. Therefore, depending on your organization’s tolerance for detection volume, you might choose to implement rules that are either more or less “noisy.” That said, we tested this across multiple customer environments and found the volume to be consistently low; therefore, for most organizations, the level of “noise” should remain low.

Cyberhaven case study

Using the Cyberhaven incident as an example—which triggered all five of our custom detectors noted in the above section—we will now walk through the workflow. We submitted both the maliciously updated version (24.10.4) and the prior legitimate version (24.10.2) of the Cyberhaven extension from the late 2024 supply chain attack to Assemblyline.

For transparency, and to simulate a pre-disclosure analysis, we intentionally disabled Assemblyline services that incorporate threat intelligence feeds. This is because these services would now flag the malicious 24.10.4 version based on the known malicious C2 domain (cyberhavenext[.]pro). Our objective, however, is to assess extension updates for potentially malicious additions before they are publicly known to be malicious.

Therefore, we created a custom submission profile. This profile included the following services, with all others disabled except for the necessary Extract service:

Note: The Extract service is crucial, as it ensures the extension archive is unpacked and its embedded files are then subjected to the static analysis services listed above. This approach saves time by allowing us to submit the extension once rather than submitting each file individually.