Researching the Chrome Extension Compromise Activity using Synapse
by savage | 2025-02-28
In late December 2024, multiple sources reported on the compromise of various Chrome extensions. At The Vertex Project, we used this reporting as a starting point for our own research into the compromise activity. While some of our findings align with those that other organizations and researchers have publicly reported, others did not. In some cases, the difference in findings were likely the result of varying visibility into the activity, while others were more likely due to differences in methodology. In this piece, we’ll go over our findings that diverged from public reporting, and discuss the methodology and analytic choices behind them.
What Chrome Extension Compromise?
On December 27th, 2024, Cyberhaven reported identifying and removing a malicious Cyberhaven Chrome extension from the Chrome Web Store. The company’s subsequent investigation found that unidentified threat actors had targeted a Cyberhaven developer with a phishing email and stole their Chrome Web Store credentials. The threat actors then compromised the Cyberhaven extension and uploaded a trojanized version to the Chrome Web Store. Additional public reporting in the following days corroborated Cyberhaven’s findings and uncovered additional compromised extensions, pointing to a more widespread operation than what Cyberhaven had initially reported.
What Assessments Did We Agree With?
When it comes to the broad outlines of the activity, our findings were consistent with those of Cyberhaven, BleepingComputer, and others. We found that in late December 2024, an unidentified threat actor uploaded compromised Chrome extensions to the Chrome Web Store, where unsuspecting users could download them. The threat actor had trojanized the Chrome extensions with malicious code. We assessed that this activity was cohesive and the work of the same actor, which we tracked as the Greyshark threat cluster, rather than a confluence of individuals with their own tactics and motives.
We believe the threat actors behind this activity used the developers’ compromised credentials to obtain copies of the legitimate Chrome extensions and upload trojanized versions to the Chrome Web Store. Although we did not have direct visibility into this part of the activity, several sources stated that the actors had targeted Chrome extension developers with phishing emails and compromised those developer’s Chrome Web Store credentials. We track the code implanted into the Chrome extensions as Aquavulture. Although Google removed many of the trojanized extensions shortly after Cyberhaven’s disclosure, we were able to use Chrome-Stats to download historical samples and find when the trojanized samples were originally published to the Chrome Web Store.
Where Did Our Findings Differ? Why the Difference?
Some of the assessments we’ve made regarding this activity vary from those of other organizations. While varying levels of visibility into the activity unavoidably comes into play, we can also track these divergent assessments back to our methodology and some of the analytic choices we’ve made. These differing findings and the reasons behind them include:
The Activity Start Date
The Vertex Project currently dates the beginning of the Chrome compromise activity to at least July 2024, whereas other organizations have reported start dates as early as February 2024. This difference in our start date assessments are due to a combination of visibility and methodology.
We began our research by working to verify and build out Cyberhaven’s reporting on the compromise of its Chrome extension in late December 2024. This involved identifying the implant used to trojanize the extensions and ingesting data from Chrome-Stats, such as samples of uploaded files, versioning information, and upload dates. We could then run those file samples against a YARA rule written to detect the implanted code that we track as Aquavulture, and verify whether or not the sample was one of the trojanized Chrome extensions.
We took timing into account when building out our cluster of Chrome extension compromise activity. Timeboxing plays a critical role in our clustering methodology - when we pivot on related resources to build out activity, we want to make sure there is also an overlap in timing. In short - the use of those overlapping resources must take place within the same timeframe for us to consider it part of the same cluster of activity.
Our research found that the threat actors published a trojanized Chrome extension to the Chrome Web Store on September 5th, 2024:
The threat actors had compromised an extension called Bard AI Chat, and had it communicate with bardaiforchrome.live for command and control (C2). The threat actors had registered this domain on July 29th, 2024, and almost certainly designed it to masquerade as actual Bard AI Chat infrastructure to escape scrutiny.
We assess with high confidence that the Chrome compromise activity began by at least July 29th, 2024, which is when the threat actors registered bardaiforchrome.live. There is the possibility that the activity began as early as March 9th, 2024, which is when the threat actors registered other, related infrastructure. However, we have less confidence in this earlier start date as while we did find evidence to attribute that infrastructure to the Greyshark cluster, we did not identify evidence specifically linking the FQDNs to the Chrome extension compromise activity. There is a small chance that Greyshark registered the FQDNs for use in other operations.
In contrast, Hunt.io assessed that the Chrome extension compromise activity began as early as February 9th, 2024, based on the discovery of TLS certificates associated with related infrastructure. Hunt.io noted that a certificate associated with the FQDN admin.tkv2.pro had validity dates ranging from February 9th through 14th 2024. While we identified infrastructure overlap between that FQDN and other Greyshark infrastructure, we did not find any evidence that this FQDN was used in association with any of the compromised Chrome extensions.
Similarly, DomainTools cited February 2024 as the likely start date based on webpages used for credential phishing, while BleepingComputer noted March 2024, based on WhoIs registration dates for the FQDN goodenhancerblocker.site, which overlaps with other infrastructure related to what we track as the Greyshark cluster.
We found the same overlaps during our investigation and attributed the indicators to the Greyshark threat cluster. However, we have yet to identify evidence specifically connecting those resources to the compromise of Chrome extensions, as opposed to other Greyshark activities. Based on research into their infrastructure, we believe that Greyshark has been active since November 2021, during which time the cluster has most likely engaged in other operations besides the Chrome extension compromises.
The Number of Compromised Chrome Extensions
ExtensionTotal reported identifying at least 36 compromised Chrome extensions related to the Cyberhaven-reported activity, compared to the 16 compromised extensions that we were able to confirm:
Our process for confirming a compromised Chrome extension and attributing it to both the Greyshark cluster and Greyshark's Chrome extension campaign involved a combination of file, infrastructure, and historical web data analysis. We only considered a compromised Chrome extension to be a confirmed part of the activity if we were able to verify the following:
The Chrome extension file was trojanized with Aquavulture; and
The trojanized extension communicated with infrastructure we attributed to the Greyshark threat cluster;
The trojanized Chrome extensions communicated with FQDNs that the threat actors most likely designed to resemble the legitimate extensions. Pivoting on this infrastructure led us to other FQDNs serving as C2 infrastructure for additional compromised Chrome extensions. We used Chrome-Stats to obtain samples of these additional extensions, and ran them against a YARA rule written to detect Aquavulture code.
Some of our infrastructure pivots led us to FQDNs that we suspect were used as C2 infrastructure for this activity, although we were unable to confirm this. For example, the threat actors appeared to have designed some FQDNs to masquerade as Chrome extension names, however, we were unable to identify the extensions and obtain samples for analysis. Several of these FQDNs are shown below:
Reported Indicators Attributed to the Activity
A key part of our research involved attempting to validate publicly reported indicators so that we could effectively detect, track, and build out related activity. Attempting to validate these indicators, rather than automatically including them in our Greyshark threat cluster, helps to ensure that our activity cluster is high fidelity and to avoid potential false positives. We identified several FQDNs that we were unable to link to the Chrome extension compromise activity or to other malicious activity.
While one of the FQDNs, remiwantnun.com, overlapped with other infrastructure we attributed to Greyshark, we did not find evidence of malicious use. Similarly, we were unable to identify any ties between artseasy.com and kra18.com and the Greyshark threat cluster (or other malicious activity) despite ExtensionTotal reporting the FQDNs as part of the Chrome extension compromises.
Capturing Third Party Reporting vs Our Own Assessments
Throughout our investigation, we were careful to differentiate between our own assessments and those of others so that we could definitively represent where our findings overlap, as well as where they differ. In Synapse, we capture third party assessments by applying a #rep tag to the relevant node. The #rep.cyberhaven.mal tag, for example, means that Cyberhaven has reported the indicator as malicious. We use a separate tag tree to capture our internal assessments, such as tagging an inet:fqdn with #cno.threat.greyshark.own to note we’ve determined that indicator to be controlled by or unique to the GreyShark threat cluster.
Another reason why we distinguish between internal and third party assessments is because Vertex’s methodology mandates that we “show our work.” Our assessments and supporting evidence must be documented within Synapse, so that an analyst looking at a node tagged #cno.threat.greyshark.own can navigate the graph and identify why that node was included in the Greyshark threat cluster. In contrast, third party assessments are "informational". While we care what other organizations report, we do not have access to their supporting data and therefore cannot verify their assessments.
Through comparing our assessments with those of others, we can gradually develop a sense of which reporting organizations most likely have a similar visibility and methodology, and whose findings we consider more reliable. While this is not a substitute for performing our own analysis and verifying their assessments, having a sense of which organizations’ findings tend to overlap closely with our own can help provide context and inform our research.
Capturing Findings and Supporting Evidence in Synapse
Using Synapse to research the Chrome extension compromise activity allowed us to verify and build out reported activity, note our own assessments as well as those of third parties, and capture supporting evidence. As we noted previously, several of our assessments differed from those publicly reported by others, such as the timeframe that we assigned to the Chrome extension compromise activity. Reflecting the reasoning behind these assessments (as well as others we made) is key, not only for understanding why we made the call we did, but also so that we can reassess as we encounter new data.
Note
Our research thus far is available in the Vertex Intel-Sharing cortex for review and further collaboration. If you do not yet have access to the Intel-Sharing cortex, you may request access here.
