Malicious Browser Extension Incident Playbook

A browser extension that turns malicious through a hijacked update runs inside every signed-in session on every device that has it, and can steal the cookies that make MFA irrelevant. On 24 December 2024 a phished developer at Cyberhaven gave an attacker a publishing-capable OAuth token, and a malicious version 24.10.4 of its Chrome extension was live for roughly 30 hours before detection, targeting cookies, session data and Facebook business account tokens; the same technique hit dozens of other extensions in a wider campaign. Because extensions update silently, the first sign is usually a vendor notice or threat report, not an alert. This template is for SOC, endpoint and identity teams responding to a malicious, compromised or hijacked extension in Chrome, Edge or other managed browsers. Preventive controls are covered in the Browser Extension Security Guide; this page is the response.

How to use this template

Replace placeholders: [Organisation], [browser management console], [MDM], [IdP], [EDR] and bracketed thresholds with your own values.
Two jobs, run together: remove the extension everywhere, and invalidate everything it could have stolen. Removing it alone leaves stolen sessions working.
Know your extension inventory: this playbook assumes you can list installed extensions by ID and version across managed browsers. If you cannot, building that is the first item in the implementation guidance.
Related playbooks: if stolen tokens were used against SaaS, also run the OAuth Token Theft Incident Playbook; for broader endpoint risk see the Top 10 Endpoint Security Risks.

1. Scope and triggers

This playbook covers browser extensions and add-ons on all [Organisation] managed and bring-your-own devices that access corporate services. Invoke it on any of the following:

Vendor or researcher notice: an extension publisher, browser vendor or threat report states that an extension version is malicious or compromised.
Store removal: an extension installed in your estate is removed from the Chrome Web Store, Edge Add-ons or another store as malware.
Suspicious behaviour: [EDR] or proxy logs show browser processes contacting newly registered or unknown domains after an extension update, or data uploads from the browser to unexpected destinations.
Session anomalies: several users show session reuse from new IP addresses or devices without a fresh sign-in (ATT&CK T1550.004 Web Session Cookie), and they share an extension.
Ownership change: a widely installed extension changes publisher or requests new permissions in an update.

2. Roles and contacts

Role	Responsibilities	Named lead / deputy
Incident commander	Severity, scope, decision to block, executive updates	[Name] / [Name]
Browser and endpoint engineering	Extension inventory, blocklist policy, removal, verification	[Name]
Identity team	Session and refresh token revocation, password resets, conditional access	[Name]
SaaS owners	Revoke sessions and tokens in SaaS platforms the extension could reach	[Per application owner list]
SOC	Log hunt for exfiltration domains, session abuse and follow-on activity	[Name]
Service desk	User communication, handling broken workflows when the extension is removed	[Name]
Extension vendor contact	Version details, indicators, clean version	[Contact route]

3. Detection and triage

Identify the extension precisely: extension ID (the 32-character identifier, not the display name, which attackers copy), affected versions, publish and removal times, and indicators such as exfiltration domains.
Find every install: query [browser management console] and [EDR] for the extension ID and version across all profiles. On disk, Chromium browsers store extensions under the profile's Extensions folder by ID and version.
Establish the exposure window: for each device, when the malicious version was installed and when it was removed or updated. In the Cyberhaven case the malicious version was published about 17:24 UTC on 24 December and its exfiltration domain operated from 01:32 UTC on 25 December to 02:50 UTC on 26 December.
Read the permissions: what sites and data the extension could access (all sites, cookies, tabs, web requests). Broad host permissions mean every session in the browser is in scope.
List affected users and their high-value sessions: identity provider, mail, admin consoles, cloud consoles, code hosts, finance and advertising platforms.

Situation	Severity	Response
Malicious version confirmed, installed on any device, broad host permissions	High	Block and revoke sessions for all affected users
Affected users include administrators or privileged roles	Critical	Major incident, privileged session revocation first
Evidence of session reuse or data access by the attacker	Critical	Major incident, SaaS investigation
Extension removed from store, no malicious version confirmed	Medium	Block as a precaution, investigate

4. Containment

Block by ID across browsers: add the extension ID to ExtensionInstallBlocklist, or set its installation_mode to blocked in ExtensionSettings. Chrome and Edge documentation both state that already installed blocklisted extensions are disabled and users cannot re-enable them, and that removing the ID from the blocklist re-enables them automatically. In Edge on Windows the policy sits under SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallBlocklist with one REG_SZ value per ID.
Verify the policy landed: on sample devices open chrome://policy (or edge://policy), reload policies and confirm the status is OK.
Cover unmanaged browsers: devices or profiles outside management (personal profiles, other browsers) need conditional access controls that block or limit access to corporate services until the user confirms removal.
Revoke sessions for affected users: stolen cookies survive extension removal (T1539 Steal Web Session Cookie). Revoke identity provider sessions and refresh tokens; Microsoft notes that existing access tokens can stay valid for up to an hour unless the app supports Continuous Access Evaluation, and that application-issued session cookies must be revoked in each application.
Revoke in SaaS platforms directly for high-value applications that keep their own sessions, starting with admin consoles and the platforms the extension targeted.
Block indicators: add exfiltration domains to proxy, DNS and firewall blocks.

Decision: blocking a widely used extension breaks workflows. If the extension is business critical and the vendor has published a clean version, the incident commander can allow the clean version by pinning it (force install from a verified version) rather than leaving it blocked, but only after sessions have been revoked and the vendor's fix is confirmed. Smaller organisations without central browser management should use [MDM] scripts or the identity provider's device compliance checks to get the same result, and accept a slower removal.

5. Eradication

Remove, not just disable: after blocking, remove the extension files from affected profiles through [MDM] or [EDR], and clear any local data it stored.
Hunt for follow-on activity: check affected devices for additional payloads, new extensions installed around the same time, or browser settings changed (search provider, proxy).
Rotate exposed secrets: if the extension could read pages where users view API keys or tokens (cloud consoles, developer portals, AI service dashboards), rotate those keys. Researchers reported AI service API keys among the data targeted in some variants of the 2024 campaign.
Close the publishing path if you publish extensions yourself: the Cyberhaven attacker obtained publishing rights through a malicious OAuth app consent that produced no MFA prompt. Restrict third-party OAuth apps for developer accounts; in Google Workspace, admins can set unconfigured apps to "Block all third-party apps" and mark only reviewed apps as trusted.

6. Recovery

Restore approved extensions through the allowlist or a pinned clean version once the vendor fix is verified.
Confirm clean state on each affected device: extension removed or at a clean version, policy applied, no new unknown extensions.
Restore user access: users sign in again with phishing-resistant MFA; consider requiring re-registration of MFA for privileged users if session abuse was seen.
Watch for reuse of stolen sessions for [30] days: sign-ins from new devices or locations for affected users, and token use from unfamiliar IP addresses.

Where identity fits

The damage from a malicious extension is identity damage: session cookies, access tokens and the API keys users look at in the browser. Treat every affected user's sessions as stolen, and treat the extension's publishing account as a privileged non-human identity if your organisation ships extensions. See the Session Hijacking and Cookie Theft Guide and the Browser Storage Security Guide.

7. Communication and notification

Users: which extension was removed and why, why they must sign in again, and not to reinstall it from the store or a personal profile.
Executives: number of affected users, privileged users among them, evidence of data access, and status of session revocation.
Customers and partners: needed if their data was reachable through affected sessions or if your published extension was the compromised one.
Regulators: legal assesses whether stolen sessions led to personal data access that is reportable under [GDPR Article 33 / other regimes].
Browser store: report malicious extensions through the store's abuse process if not already removed.

8. Post-incident review

Timeline: malicious version published, first install in your estate, notice received, block applied, sessions revoked, last device cleaned.
Inventory quality: how long it took to list every install by ID and version.
Policy gaps: was the extension on an allowlist, and were permission-based restrictions in place?
Permission creep: list every allowed extension that can read all sites or cookies, confirm each still has a business owner and a clear need, and move the rest to narrower alternatives or remove them.
Revocation reach: which SaaS platforms kept sessions alive after identity provider revocation, and how long it took each owner to revoke them directly.
Detection: did any control see the exfiltration traffic or session reuse before the notice arrived? Lessons for the next case are in the Cyberhaven Chrome Extension Breach 2024.

Implementation guidance

Build the inventory: collect installed extension ID, version, permissions and profile from every managed browser into [browser management console] or the SIEM.
Move to an allowlist: set the blocklist to * and allow reviewed extensions by ID; both Chrome and Edge document that * blocks all extensions by default with allowlisted, signed extensions still permitted.
Pre-stage the block: keep a tested change that adds an ID to the blocklist across all browser management channels within [1] hour.
Script session revocation for a list of users across the identity provider and top SaaS platforms.
Exercise: run a tabletop where a popular productivity extension is reported malicious on a public holiday.

Metric	Target example
Managed browsers reporting extension inventory	Above [98] percent
Time from notice to blocklist applied fleet-wide	Under [2] hours
Time from notice to sessions revoked for affected users	Under [4] hours
Extensions installed that are not on the allowlist	Zero on managed devices
Affected devices confirmed clean	100 percent within [48] hours

Framework mapping

Framework	Reference
NIST CSF 2.0	PR.PS-02, DE.CM-09, RS.MA-02, RS.MI-01, RS.MI-02, RC.RP-01
NIST SP 800-53 Rev. 5	CM-7, CM-8, CM-11, SI-4, AC-12, SR-11, IR-4
MITRE ATT&CK v20	T1176.001 Browser Extensions; T1195.002 Compromise Software Supply Chain; T1539 Steal Web Session Cookie; T1550.004 Web Session Cookie; T1528 Steal Application Access Token

Malicious Browser Extension Incident Playbook: Remove it fleet-wide and kill stolen sessions