Shadow IT Battlefield: The CyberHaven Breach and Browser Extension Security

Shadow IT Battlefield: The CyberHaven Breach and Browser Extension Security

Speakers: Rohit Bansal, Zach Pritchard

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: https://www.youtube.com/watch?v=Yg4kT79xBy8

Reading time: ~7 minutes

TL;DR

The December 2024 CyberHaven breach — in which attackers phished a developer's Google credentials, abused OAuth to upload a malicious Chrome extension, and compromised a data-loss prevention tool used by enterprise customers — was not an isolated incident. It was part of a campaign that hit more than 30 extensions. Rohit Bansal and Zach Pritchard from Grammarly describe how their own team was targeted, how existing preventive controls stopped the attack before it landed, and what it took to build a mature browser extension and OAuth governance program from scratch.

Introduction

On December 26, 2024, CyberHaven — a company whose core product is an enterprise data loss prevention agent running in browsers — discovered that attackers had published a malicious version of its Chrome extension to the Chrome Web Store. The attack chain began with a phishing email. A CyberHaven employee clicked a link, entered Google credentials on a fake page, and inadvertently granted an OAuth access token with the ability to make API calls to the Chrome Web Store — including publishing extension updates. Because the malicious code changes were minimal, the extension likely received only lightweight review before Google approved the update and distributed it to CyberHaven's enterprise customers.

Research by SecureNX later revealed that CyberHaven was one of approximately 30 browser extensions compromised through the same phishing-to-OAuth attack pattern. For Grammarly — whose browser extension is used by 40 million people daily — this campaign was an immediate concern. As Rohit Bansal described: "We being Grammarly, Grammarly's bread and butter is a Chrome extension. Were we also targeted?" The answer was yes. But unlike CyberHaven, Grammarly did not get breached.

How Grammarly Was Targeted — and How the Attack Stopped

▶ Watch: Phishing attack chain and CyberHaven breach mechanism (04:01)

The phishing email targeting Grammarly was blocked by Grammarly's spam and phishing protection system before it reached an employee's inbox. But the talk goes beyond crediting that single control — Bansal was explicit that phishing filters alone are insufficient, and that defense in depth is the only reliable posture.

Two additional preventive controls, implemented in the six months preceding the attack, would independently have blocked the threat even if the phishing email had been delivered:

1. Google OAuth app allowlist. Grammarly had implemented an allowlist for Google OAuth applications, requiring any third-party app requesting Google Workspace data access to pass through a formal review. Even if the employee had clicked the phishing link and reached the OAuth consent screen, the authorization would have been blocked before the attacker received an access token.

1. Browser extension allowlist. Grammarly had operationalized a Chrome extension allowlist, ensuring that extensions not on the approved list cannot be installed in managed browser profiles. Of the roughly 30 extensions compromised in this campaign, none were in Grammarly's allowed set, providing the company with a documented assurance that none of those compromised extensions were running in its environment.

Bansal described this as the first time in his career that he had personally witnessed preventive controls stop an active, real-world campaign. The validation was significant — and the program's origins preceded the CyberHaven incident by months, driven by a risk-based discovery exercise rather than a reactive response.

Building the Program: Discovery, Communication, and Implementation

▶ Watch: Discovery, alignment, and the four-pillar framework (08:03)

Bansal organized the talk around a four-pillar framework for running shadow IT risk reduction programs, derived from Grammarly's own process.

Pillar 1: Discovery and Alignment. Before any technical controls can be justified, a team needs to understand the actual scope of the problem. Grammarly discovered — after enabling telemetry — that its 1,200-person workforce had installed approximately 1,000 unique browser extensions and had 400 distinct Google OAuth client applications accessing Google Workspace data. That number made the risk case for leadership. A product requirements document (PRD) served as a shared, commentable space to align stakeholders across security, engineering, and the business before any enforcement began.

Pillar 2: Communication. Bansal called this "the most important and often weakest pillar." The team communicated project goals with both the engineering team (explaining the "what and why") and the broader workforce (explaining the changes they would experience, such as a policy requiring all Google Sign-In to occur through a company-managed Chrome profile). Transparency about the review process for extension and OAuth app requests was built into the program from the start — employees filing new requests receive context, not just a verdict.

Pillar 3: Implementation.

▶ Watch: Implementation details and technical trade-offs (12:06)

For browser extension governance, Grammarly made three key implementation decisions: set machine-level (cloud) policy as the highest-precedence override so that a blocked extension is blocked on every Chrome profile on the device; pre-approve all extensions already in active use to avoid productivity disruption at launch; and enable Chrome Web Store's built-in extension request mechanism, which allows employees to submit a justification when attempting to install a blocked extension. That submission automatically creates a Jira ticket for security team review.

For OAuth governance, internal clients were trusted by default (preserving developer velocity), pure sign-in flows that don't request Google Workspace data access were exempted, and external apps that do request data access must pass through review. Since Google provides no native request mechanism for OAuth app access, the team added a custom error message — limited to 400 characters — directing employees to a Jira queue.

The extension review workflow uses an enterprise GPT instance to generate an initial assessment of each requested extension across six dimensions: permissions, popularity, publisher reputation, privacy practices, data security practices, and potential business use case for Grammarly. A team member reviews the GPT output and makes a final allow/defer decision. Importantly, extensions are "deferred" rather than outright blocked, preserving the ability to revisit decisions as business needs evolve.

Pillar 4: Maturity. Programs require ongoing refinement. As a follow-up project, Grammarly pruned its original 1,000-extension allowlist down to approximately 400 by October–December 2024 — a 50% reduction — by eliminating extensions with no clear business use or negligible adoption.

The Unsolved Problem: Detecting Rogue Approved Extensions

▶ Watch: Chrome Watch project and taint-flow analysis (20:09)

Allowlists solve the problem of preventing unauthorized extensions from entering the environment. They don't solve the problem that the CyberHaven breach actually demonstrated: an already-approved, trusted extension can turn malicious through a supply chain compromise.

This is the challenge Zach Pritchard addressed in the second half of the talk. Grammarly is developing an internal project (tentatively named "Chrome Watch") that monitors every extension update across managed browser devices and performs static analysis to detect malicious data flows in JavaScript code.

The system works by pulling a list of all installed Chrome extensions via Google Workspace APIs, detecting each version update, retrieving the new extension payload from the Chrome Web Store, and using the Tree-Sitter library to parse the JavaScript AST. The analysis identifies when sensitive sources — such as browser cookies, browsing history, or open tabs — flow into suspicious sinks such as calls to fetch, XMLHttpRequest, or WebSocket connections. This is essentially taint-flow analysis applied to extension JavaScript.

Pritchard was careful to contextualize what permissions-based checks cannot do. A legitimate extension may need the chrome.tabs permission for valid functionality. Similarly, an extension may appear to log keystrokes for a hotkey registration feature rather than for data exfiltration. Permission signals are valuable inputs, not conclusive verdicts — which is precisely why behavioral code analysis matters.

Early results have been encouraging: Chrome Watch has not identified malicious extensions in Grammarly's fleet (a good outcome), but has identified and reported multiple extensions in the Chrome Web Store attempting to steal cookies or browsing history. Pritchard's advice for finding test cases: search the Chrome Web Store for "ChatGPT" and scroll until you find one with official-looking branding and very few reviews.

Limitations acknowledged: heavily obfuscated JavaScript can evade static analysis, and validating obfuscated code is genuinely difficult. The team is exploring whether diffing old and new versions and piping the diff to an LLM could augment detection — with the caveat that LLMs themselves can be manipulated by adversarial content embedded in the extension code being reviewed.

Notable Quotes

"In my career, it was the first validation of preventive controls saving us from an active campaign. I've never seen an active threat mitigated by preventive controls before."

— Rohit Bansal ▶ 06:03

"We want to reduce the time it takes to identify malicious extensions from 'a vendor has told us they're compromised' to 'we're telling the vendor they're compromised.'"

— Zach Pritchard ▶ 20:09

"Communication needs to be the strongest pillar in your strategy — and it's often the weakest. We don't do enough."

— Rohit Bansal ▶ 10:03

Key Takeaways

• The CyberHaven attack chain is reproducible at scale. Thirty-plus extensions were compromised through the same phishing-to-OAuth pathway. Any organization whose employees have granted OAuth access to third-party apps with Google Workspace permissions faces the same exposure surface.
• Allowlists are a necessary but incomplete defense. Extension and OAuth allowlists prevent unauthorized tools from entering the environment — but they don't protect against already-approved extensions that later turn malicious. Supply chain monitoring is a distinct, additional requirement.
• Discovery before enforcement. Starting with telemetry to map the actual extension and OAuth footprint across the organization produces the business case for restrictive controls and prevents productivity surprises at rollout.
• Communication is the highest-leverage, most-neglected part of the program. Over-communicating the "what and why" of governance changes to engineering and the broader workforce directly determines adoption quality and reduces adversarial workarounds like personal device use.
• Static taint-flow analysis of JavaScript is a viable detection approach. Tree-Sitter-based AST parsing to identify source-to-sink data flows in extension code is an accessible technique — though obfuscation remains a meaningful evasion path that will likely require LLM augmentation or dynamic analysis to close fully.