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:
- 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.
- 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
- 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:
- Color picker tool – geco (2025)
- Cyberhaven security extension V3 (2024)
- QuickLens – Search Screen with Google Lens (2026)
- PaperPanda — Get millions of research papers (2025)
- Trust Wallet (2025)
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:
- Behaviour shorteners found
- Base64Decoding
- Base64 Strings
- CookieHarvesting
- EncodeURI
- EvalUsage
- Long One-Liner
- ParseIntUsage
- PrepareNetworkRequest
- NetworkRequest
- SplitReverseJoin
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.
| Detection focus | Rule name | Percentage | Examples |
| Detect extensions that have an updated service worker and a content script has been updated or added, which may indicate significant changes in extension functionality and potential introduction of malicious behavior | UPDATED-BACKGROUND-SCRIPT-AND- UPDATED-OR-ADDED-CONTENT-SCRIPT | ~40% | Cyberhaven security extension V3 QuickLens – Search Screen with Google Lens PaperPanda — Get millions of research papers Trust Wallet |
| Detect extensions that reference new domains and have a new or updated service worker, which may indicate the introduction of a C2 domain and a potential persistence mechanism | NEW-DOMAIN-NEW-OR- UPDATED-BACKGROUND-SCRIPT | ~35% | Color picker tool – geco Cyberhaven security extension V3 QuickLens – Search Screen with Google Lens PaperPanda — Get millions of research papers Trust Wallet |
| Detect extensions that reference new domains, have an updated service worker, and a content script has been updated or added, which may indicate significant changes in extension functionality and potential introduction of malicious behavior | NEW-DOMAIN-UPDATED-BACKGROUND-SCRIPT -AND-UPDATED-OR-ADDED-CONTENT-SCRIPT | ~24% | Cyberhaven security extension V3 QuickLens – Search Screen with Google Lens PaperPanda — Get millions of research papers Trust Wallet |
| Detect extensions with script updates showing anomalous characteristics, which may signal significant changes in functionality or code style, and could indicate takeover by a malicious actor using z-score and entropy anomalous characteristics | SCRIPT-UPDATES-WITH- ANOMALOUS-CHARACTERISTICS | ~11% | Cyberhaven security extension V3 |
| Detect extensions that reference new domains, have new assembly line service detections, have an updated service worker, and a content script has been updated or added, which may indicate significant changes in extension functionality and potential introduction of malicious behavior | NEW-DOMAIN-NEW-ASSEMBLY-LINE- SERVICE-DETECTIONS-UPDATED- BACKGROUND-SCRIPT-AND-UPDATED -OR-ADDED-CONTENT-SCRIPT | ~9% | Cyberhaven security extension V3 QuickLens – Search Screen with Google Lens PaperPanda — Get millions of research papers Trust Wallet |
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.
import os
https://cybercentrecanada.github.io/assemblyline4_docs/integration/python/
from assemblyline_client import get_client # pip install assemblyline_client
Set up the Assemblyline client.
al_client = get_client(
f"https://{os.getenv('ASSEMBLYLINE_HOST')}"
apikey=(os.getenv("ASSEMBLYLINE_USERNAME"), os.getenv("ASSEMBLYLINE_API_KEY")),
verify=False,
)
files = [
"pajkjnmeojmbapicmbpliphjmcekeaac_24.10.2.zip",
"pajkjnmeojmbapicmbpliphjmcekeaac_24.10.4.zip",
]
Submit files to Assemblyline. Store the submission information by file name in a dictionary.
submissions: dict[str, dict] = {
file: al_client.submit(
params={
"description": os.path.basename(file),
"services": {
"selected": [
"Extract",
"Characterize",
"DeobfuScripter",
"FrankenStrings",
"JsJaws",
"Pixaxe",
"URLCreator",
],
},
},
path=file,
)
for file in files
}
Assemblyline’s reports won’t always definitively classify a submitted file as malicious. Therefore, additional interpretation is necessary. To detect potentially malicious changes in an updated extension, we employed a multi-layered comparative analysis focusing on key indicators and report differences.
Signature and domain comparison
After submitting both the old and new extension versions to Assemblyline for analysis we then compared the resulting reports, specifically focusing on extracted domains and detection signatures. This comparison makes it simple to spot any newly added or modified service signatures or domains, which is a strong initial sign of potential suspicious resource access or activity.
Identifying script modifications
When a background or content script is added to an extension, the manifest.json is updated. For example, adding the content.js
script in version 24.10.4 is easily identified by taking a diff of the manifest files. However, when an existing script is updated, the manifest doesn’t change. In this scenario, we relied on the file’s hash to assess any modification. Fortunately, Assemblyline’s extract service calculates and provides the hash of each file in the file_tree
key of the returned report. This feature allowed us to easily see that a preexisting service worker, like worker.js
, was updated.
Statistical anomaly detection
Merely flagging the presence of a new or modified script generates excessive noise. To cut through this, we integrated a statistical anomaly analysis to determine if a change is a significant deviation from the established norm. Consider the new content.js
script introduced in version 24.10.4. By analyzing the legitimate previous version (24.10.2), we established a normal entropy range for content scripts (3.82–4.84, with a mean/median around 4.79/4.82). The new content.js
, however, exhibited an entropy of 4.98 and, more damningly, a modified z-score of 75.4. This extreme statistical outlier strongly indicates a radical deviation in coding style, suggesting authorship by an outside or unfamiliar entity.
Furthermore, an update to a preexisting script, such as the service worker, can also be detected: its updated entropy (5.2) showed a significant 12.7 percent increase over the previous version’s (4.6) in 24.10.2—a clear sign of deviation from the normal writing style. Assemblyline’s characterize service automatically calculates the entropy for every submitted file, which can be retrieved directly via the file API endpoint.
The final assessment/alert below is the result of comparing the two versions. It is specifically designed to take a seemingly harmless event—a browser extension update—and provide critical insights into what changed. This alert can be read as such:
The update to the “Cyberhaven security extension V3” (extension_id:
pajkjnmeojmbapicmbpliphjmcekeaac
), from version 24.10.2 to 24.10.4, triggered significant security alerts due to highly suspicious changes. The new version introduced a content script,js/content.js
, exhibiting an extremely high entropy z-score (75.38), strongly suggesting obfuscation or high compression. Additionally, the service worker’s (js/worker.js
) entropy increased anomalously by 12.27 percent. The update further raises red flags by adding a reference to a new domain,cyberhavenext[.]pro
, and containing two new suspicious signatures:Base64Decoding
andCookieHarvesting
(JSJAWS.3
). These combined indicators point toward a potential risk of data exfiltration.
{
"extension_id": "pajkjnmeojmbapicmbpliphjmcekeaac",
"version": "24.10.4",
"old_version": "24.10.2",
"extension_name": "Cyberhaven security extension V3",
"matched_rules": [
"NEW-DOMAIN-UPDATED-BACKGROUND-SCRIPT-AND-UPDATED-OR-ADDED-CONTENT-SCRIPT",
"NEW-DOMAIN-NEW-ASSEMBLY-LINE-SERVICE-DETECTIONS-UPDATED-BACKGROUND-SCRIPT-AND-UPDATED-OR-ADDED-CONTENT-SCRIPT",
"UPDATED-BACKGROUND-SCRIPT-AND-UPDATED-OR-ADDED-CONTENT-SCRIPT",
"SCRIPT-UPDATES-WITH-ANOMALOUS-CHARACTERISTICS",
"NEW-DOMAIN-NEW-OR-UPDATED-BACKGROUND-SCRIPT"
],
"new_content_script_anomalous_characteristics": true,
"new_content_scripts": [
"js/content.js"
],
"new_domains": [
"cyberhavenext[.]pro"
],
"new_script_anomalous_characteristics": false,
"new_service_worker_anomalous_characteristics": false,
"new_signatures": {
"JSJAWS.3": [
"Signature: Base64Decoding",
"Signature: CookieHarvesting"
]
},
"notes": [
"New content script added: js/content.js. Entropy: 4.98 (Medium). The z-score for the new content script's entropy is 75.38, which indicates a significant deviation from previous content scripts.",
"Service worker (js/worker.js) updated. Entropy: 5.17 (Medium). This is 12.27% higher than the previous version of the service worker: 4.60 (Medium).",
"1 new domain(s) referenced",
"2 new signature(s) detected."
],
"updated_service_worker": "js/worker.js",
"updated_service_worker_anomalous_characteristics": true
}
Closing thoughts
The key takeaway is this: High-fidelity detection of potentially malicious browser extension updates is a practical reality. Security teams can build a robust, automated assessment workflow to aid in early detection of risky or malicious version updates before public reporting. This is achieved by combining continuous monitoring with a powerful static analysis sandbox. While this can serve as a complementary detection layer for more advanced programs or those with access to extensive telemetry, it is useful for all organizations regardless of maturity level. This is especially vital for those concerned about supply chain attacks who have not yet implemented version pinning, established an extension review process of their own, or offloaded that work to an external team.
References
- Assemblyline as a Malware Analysis Sandbox | SANS ISC
- Assemblyline 4: File triage and malware analysis | GitHub
- Google and Microsoft Trusted Them. 2.3 Million Users Installed Them. They Were Malware. | Koi
- Cyberhaven Supply Chain Attack: Exploiting Browser Extensions | Darktrace
- Pixel Perfect: Sold Extension Injects Code Through Pixel | Annex Blog
- PandaPaper turns malicious | SiloCityLabs
- Trust Wallet Browser Extension v2.68 Incident: An Update to Our Community | Trust Wallet
- Modified Z-Score | Oracle
- LibGuides@Southampton: Skewness and Kurtosis: Maths and Stats| University of Southampton
- Z-score introduction | Modeling data distributions | AP Statistics | Khan Academy
Facts Only
Cyberhaven was the target of a supply chain attack on its browser extension.
The attack injected code through pixels, allowing malware to be installed on 2.3 million users.
The attack was discovered by Darktrace.
The attack highlights the vulnerability of browser extensions to supply chain attacks.
Security teams can build a robust, automated assessment workflow to aid in early detection of risky or malicious version updates.
The workflow uses a powerful static analysis sandbox.
The workflow is particularly useful for organizations concerned about supply chain attacks.
The workflow can serve as a complementary detection layer for more advanced programs or those with access to extensive telemetry.
The workflow is useful for all organizations, regardless of maturity level.
The workflow is especially vital for those who have not implemented version pinning, established an extension review process, or offloaded that work to an external team.
Executive Summary
The article discusses the importance of high-fidelity detection of potentially malicious browser extension updates. The article presents a case study of a supply chain attack on Cyberhaven, a browser extension, and demonstrates how security teams can build a robust, automated assessment workflow using a powerful static analysis sandbox. This workflow can aid in early detection of risky or malicious version updates before public reporting, and is particularly useful for organizations concerned about supply chain attacks.
The article also provides references to various sources, including SANS ISC, GitHub, Koi, Darktrace, Annex Blog, SiloCityLabs, Trust Wallet, Oracle, University of Southampton, and Khan Academy.
Full Take
The article highlights the importance of high-fidelity detection of potentially malicious browser extension updates, particularly in the context of supply chain attacks. The case study of Cyberhaven demonstrates the vulnerability of browser extensions to such attacks and the need for robust, automated assessment workflows to aid in early detection. The article emphasizes the usefulness of such workflows for all organizations, regardless of maturity level, and is a reminder of the need for continued vigilance in cybersecurity.
Patterns detected: ARC-0043 Motte-and-Bailey (the article presents a strong case study but does not address potential counterarguments or alternative perspectives).
Root cause: The root cause is the increasing complexity and interconnectedness of modern software systems, which make them vulnerable to supply chain attacks.
Implications: The implications are that organizations must take proactive measures to protect themselves against supply chain attacks, particularly with regard to browser extensions. This includes implementing version pinning, establishing an extension review process, and using robust, automated assessment workflows.
Bridge questions: What other measures can organizations take to protect themselves against supply chain attacks? How can users protect themselves when using browser extensions? What are the ethical implications of browser extension companies collecting user data?
Counterstrike scan: The article does not present any evidence of a coordinated influence campaign. However, the topic of browser extension security is likely to be of interest to a variety of malicious actors, and organizations must remain vigilant against potential attacks.
Sentinel — Human
The article shows strong signs of human authorship, with technical depth, idiosyncratic emphasis, and specific tool-based workflows that are unlikely to be AI-generated.