What We Know So Far about CyberHaven and Other Chrome Extension Attacks

Overview of the Attack and Tactics Used:

Consent phishing – Consent phishing is an attack technique where instead of trying to steal credentials directly, attackers trick users into granting permissions to a malicious application through legitimate OAuth authorization flows.

In this instance, the attacker created an application with an innocuous name (i.e. “Privacy Policy Extension”). Employees were targeted with well researched phishing emails, mimicking legitimate emails in look and feel to obtain the required OAuth permissions for this application.This personalization increased the likelihood of users trusting and interacting with malicious links or applications. Victims unknowingly granted these permissions, allowing the attacker to publish their malicious version of the Cyberhaven plugin seemingly designed to collect Facebook-specific information, such as:

• Facebook access tokens
• User account identifiers
• Business account information
• Advertising account details
• Browser cookies and user agent data

The attack methodology demonstrates a sophisticated understanding of Facebook’s API infrastructure and advertising ecosystem. By targeting advertising accounts specifically, the attackers showed clear intent to gather information about Facebook’s advertising users and their associated business accounts.

Security Extensions Compromised but Not the Target

As at date of publishing, researchers like John Tuckner have identified:

• 36 different browser extensions compromised through consent phishing
• Up to 2.6 million users potentially affected
• Multiple high-profile security and AI tool browser extensions were impacted

Given the host of security vendors (Beyondtrust, Okta etc) being targeted recently in other incidents, the immediate thought is that Cyberhaven was targeted due to their privileged access and trusted position within customer environments. However the evidence suggests the attackers’ primary goal wasn’t to exploit Cyberhaven’s DLP capabilities. Instead, the malicious code appeared to focus on harvesting Facebook advertising account credentials, and enabling attackers to enroll their own MFA devices by:

• Collecting authentication tokens and cookies,
• Capturing QR codes specifically for MFA bypass,

This targeting suggests a financially motivated campaign focused on advertising account access through a compromised browser. However, the attack still demonstrates how security vendors can become unwitting vectors for credential theft, data exfiltration and MFA bypass. 

Early Warning Signs Missed

While the Cyberhaven incident brought widespread attention to this attack methodology, similar attacks had been observed in the wild as early as December 2024. Security researcher Denis Podgurskii had identified and documented suspicious OAuth-based extension compromises on LinkedIn by December 5th, and the removal of the Moonsift plugin from the Google Play Store on December 10th showed similar patterns. Additionally, SquareX CEO Vivek Ramachandran had published details of a nearly identical attack on December 21. However, this threat intelligence remained largely siloed within specific security communities and wasn’t effectively disseminated across the broader technology ecosystem.

 The lack of coordinated sharing and action on these early warnings meant that many organizations remained vulnerable to an attack pattern that had already been identified as malicious. This highlights an ongoing challenge in the cybersecurity community: the gap between initial threat detection and widespread defensive action.

Authentication Doesn’t Predicate Authorization

A critical nuance to this “Consent Phishing” attack is unlike traditional phishing attacks which attempt to compromise the account itself – this phishing attack was focused on getting authorization for their account to publish to the Chrome Web Store. It highlights a fundamental security principle: authentication does not equate to authorization.

While the Cyberhaven employee’s Google account remained secure with MFA enabled, the attacker didn’t need to break this authentication – they simply needed the user to authorize their malicious application. This authorization granted the attacker legitimate publishing rights to the Chrome Web Store, bypassing all authentication controls. Most security programs are still focused on the “proving who you are” (authentication) aspect of zero trustZero Trust is a security concept that businesses deploy to s... and have yet to really tackle in a meaningful way the “what you’re allowed to do” (authorization) or least privilege blind spot they have ignored for years.

Separating Accounts into Privileged Admin and Other Tasks is STILL Hard

The Cyberhaven incident highlights another persistent challenge. For decades, best practices have recommended separating admin accounts from regular user accounts to avoid exposing privileged accounts to the risk of day to day activities like email and internet browsing. Unfortunately 

In this instance, it was clear that the support email Browser Profile Mixing

• Admin accessing Chrome Web Store publishing with same profile used for email/browsing
• Development credentials accessible in primary browsing context
• Security tool administration mixed with general web access

Despite these challenges, the increasing sophistication of consent phishing and social engineering attacks makes this separation crucial. Had Cyberhaven’s browser extension developers used a dedicated admin profile without email access, this attack path would have been blocked.

What We Don’t Know

There are always unknowns at this stage of an incident investigation, as the forensic investigation unfolds and law enforcement works to identify the full impact and the true identity and motivation of the attack group. Some notable questions are currently front of mind, namely:

How the Compromise was detected

Cyberhaven’s disclosure doesn’t describe how they initially detected the compromise. As a Data Loss Prevention (DLP) vendor whose core business is identifying suspicious data flows, one might expect their own product to have detected anomalous data movements from the compromised extension or at the various least, the malicious network flows from the compromised endpoint to the newly registered domain. However, Cyberhaven has remained silent on this point, although some indicators of compromise point to network traffic from the endpoint as a mechanism for ongoing detection.

Also of interest is whether any other impacted organizations (both end user customers and vendor extensions) detected anything anomalous from the impacted plugins, besides CyberHaven. 

The Impact on any End User Customers

The full scope of impact on end users remains a critical area of concern. Since the compromised extensions (not only Cyberhaven) had the ability to collect user information for any targeted website, the finding to date that only “facebook” had been targeted is comforting, but should not be relied upon as fact.

The fact is that any end user that updated to a compromised extension may have experienced unauthorized data access or exfiltration. Organizations using the affected extension should conduct their own forensic analysis of impacted endpoints during the period of compromise.

Lessons Learnt From Cyberhaven

As with any incident, while the focus is on immediate response, conducting a blame free post mortem also provides an opportunity to learn, as well as the impetus to make long overdue changes to existing security controls in the wake of the incident. 

Immediate Response

The immediate incident response should of course be to identify, contain, eradicate and recover from the ongoing threat. Organizations should first take steps to identify if they have been exposed in this incidents.  To this end, Cyberhaven has published their preliminary analysis of the incident: which contains a useful list of indicators of compromise.

The team at SecureAnnex and John Tuckner has also published an incredibly detailed review of the incident including IOC’s and a current list of other compromised extensions

The Browser Security wakeup call

It is obvious that Browser security demands immediate attention, especially in light of these  recent extension-based attacks. Organizations need to implement strict controls while maintaining business functionality through a well-defined extension management program – This may be achieved by using an Enterprise browser such as Island, Palo Alto (formerly Talon) or a Browser Detection and Response (BDR) solution such as SquareX. These solutions can help organizations 

Extension Control Framework:

• Deploy allowlist-based extension policies
• Establish formal approval workflows for new extensions
• Implement automated detection of unauthorized extensions
• Monitor extension behavior and data access patterns of all extensions installed and used by employees across the organization
• Blocking OAuth interactions to unauthorized websites to prevent employees from accidentally giving attackers unauthorized access to your Chrome Store account
• Blocking and/or flagging any suspicious extension updates containing new, risky permissions

The Broader Implication 

This incident highlights a troubling paradox. Organizations rely on security vendors to safeguard their environments, yet these same vendors, when compromised, become highly effective vectors for attack. The privileged access and trust placed in security tools, which are often integral to daily operations, make them an attractive target for threat actors. This is of course not limited to Security tools and vendors but across the supply chain. Similarly in today’s interconnected digital landscape, supply chain complexity is both a strength and a vulnerability. Tools that require deep integrations and extensive permissions introduce potential weaknesses, as their compromise can have cascading effects across multiple systems and organizations. 

The attack also underscores a glaring gap in many organizations’ defenses. While much effort is spent on preventing initial compromises, less attention is given to monitoring what authorization is provided to new identities and the data flows that follow. Tools that are trusted to operate within an organization’s environment are often given a free pass, even when their behavior begins to deviate from the norm.

Organizations must prioritize a swift and comprehensive review of their security posture in relation to security vendors. In our opinion, this begins with an extensive audit of permissions and access controls to your most important asset, data. Organizations should:

• Conduct thorough audit of third party permissions and access patterns to your sensitive data
• Identify and revoke unnecessary or excessive access rights
• Continuously monitor access by third parties.

The Final Takeaway

The Chrome extension supply chain attacks serve as a crucial reminder that while initial access vectors may vary, the ultimate goal of attackers remains consistent: establishing malicious data flows to extract valuable information. The compromise of security vendors like Cyberhaven highlights how even security tools themselves can become conduits for data theft.

Organizations must shift their focus from solely preventing compromise to also detecting anomalous data flows, regardless of their source. In an era where security tools require extensive access and trust, the ability to spot when these tools begin behaving abnormally becomes critical to defending against supply chain attacks.