If your enterprise browser is compromised: containment, credential rotation and rebuild playbook

An enterprise browser is where your users sign in to everything, so an attacker who controls its management tenant, its update channel or its extension distribution can reach every session, password and document that passes through it. The managed browser has become a control plane: one console pushes policy, extensions and data rules to every device, and the browser holds session cookies, saved credentials and sometimes injected secrets for privileged web applications. This playbook is for incident responders, endpoint and identity engineers and browser platform owners. It covers how a platform compromise shows up, triage, containment in priority order, the session and credential rotation that must follow, rebuilding trust in the fleet, and evidence. It is vendor-neutral; confirm setting names with your vendor. A single malicious extension is handled in the Malicious Browser Extension Incident Playbook, and hardening before an incident in Securing the enterprise browser itself.

Key takeaways

• Treat the management console as tier 0. Whoever controls it can push an extension, open a data rule or disable a protection on every managed device at once.
• Every session in the browser is suspect. Revoke sessions at the identity provider and at each high-value application; clearing the browser alone leaves stolen cookies working elsewhere.
• Revoking an enrolment token does not unenrol devices. In common designs it only stops new enrolments, so device tokens and existing enrolments need their own action.
• Do not stop updates as a reflex. Pausing or pinning the update channel is a short, documented measure while you verify a build, not a fix.
• Restore policy from a trusted export. Compare live browser policy with the last approved baseline; attacker changes are both evidence and the first thing to revert.

What an attacker gains, by component

For the options and baseline policies that sit behind this table, see the Enterprise Browser and Browser Security Guide.

How the compromise shows up

• Console audit events: a new administrator or API key, a force-installed extension nobody requested, a data control rule disabled, or a change to the update or version policy outside change control.
• Fleet anomalies: many browsers receiving the same new extension or policy within minutes, or browsers reporting an unexpected version.
• Identity provider signals: session reuse from new devices or locations shortly after users signed in through the managed browser, which points to stolen cookies (T1539).
• Vendor notice: a security advisory, a compromised build or a compromised extension publisher. Browser extensions update silently, so the Cyberhaven extension breach of 2024 reached customers through the vendor's notice rather than their own alerts.
• Endpoint detections: browser processes spawning unusual child processes, or tools reading browser credential stores (T1555.003).

Triage: the first hour

1. Locate the entry point: console administrator, admin API key, enrolment token, extension publisher, browser build, or a single endpoint. Only the first five are a platform compromise; a single endpoint follows your endpoint isolation process.
2. Export and hash evidence: console audit log, current policy set for every organisational unit or group, extension force-install list with versions and IDs, and the enrolled browser inventory.
3. Diff against baseline: compare live policy with the last approved export in version control and list every change since.
4. Size the exposure: which user groups received the change, from what time, and which applications those users signed in to during the window. Pull sign-in logs from the identity provider for that population.
5. Decide the containment level: console-only (attacker changes reverted, sessions rotated) or fleet-wide (extension, build or update channel tampered). The second needs device-level action and wider session revocation.

Containment by priority

1. Lock the console: revoke all admin sessions, disable unknown administrators, delete unknown API keys and reduce administration to named responders with phishing-resistant MFA. Use the break-glass account if the identity provider is also in scope. See the Break-Glass Account Guide.
2. Remove the payload from the fleet: block the malicious extension ID by policy rather than only removing it from the force-install list, so it uninstalls and cannot be reinstalled. Revert relaxed data controls and restore disabled protections.
3. Stop new trust: revoke and regenerate enrolment tokens. In common designs, browsers already enrolled with a revoked token stay enrolled, so also delete rogue or unknown enrolled browsers in the console, which invalidates their device tokens.
4. Hold the update channel if the build is suspect: pin to a known-good version or pause updates only for the time needed to verify the vendor's build, with a written end date. Vendors warn that pinning and disabling updates leave devices exposed to known vulnerabilities, and rollback is usually limited to recent major versions.
5. Fail closed on unmanaged starts: where the browser supports mandatory enrolment, set it so a browser that cannot reach the tenant does not start unmanaged during the incident, and confirm access to sensitive applications requires a managed browser.
6. Protect the logs: make sure console audit logs and data control events stream to a store browser administrators cannot change.

Session and credential rotation

A compromised browser platform turns every session it held into a possible replay token. Rotation has to happen where the session is accepted, not only where it was stored.

• Token revocation limits: RFC 7009 notes that self-contained access tokens cannot be revoked immediately without backend interaction, which is why short lifetimes and monitoring after revocation matter.
• Device-bound sessions: where sites use device-bound session credentials, a cookie stolen from the browser is much harder to replay from another machine, because refreshing it needs proof of a key held in the device's secure hardware. The design note is clear that malware present when the session was registered could still extract the key, so do not skip rotation.
• Further reading: see the Session Hijacking and Cookie Theft Guide and the Leaked Credential Response Playbook.

Eradication and rebuild

1. Rebuild policy from baseline: restore the last approved export, then re-apply legitimate later changes one at a time with approval.
2. Verify the build: confirm with the vendor which versions are trusted, check signatures on installers you distribute, and move the fleet to a clean version as soon as it is confirmed.
3. Re-enrol where trust is lost: for devices that ran a tampered build or extension, remove the browser profile and device token, reinstall from a verified package and re-enrol with a new token. Where an extension executed code outside the browser sandbox or endpoint detections fired, rebuild the device.
4. Remove attacker artefacts: administrators, API keys, organisational units, policies, extension entries, data rule exceptions and log destinations created during the incident.
5. Hunt downstream: review the applications users reached during the window for actions taken with their sessions: mailbox rules, new OAuth grants, repository tokens and admin changes.

Recovery, testing and rollback

• Pilot ring first: restore normal policy and update cadence to the security team and a pilot group, confirm protections and data controls behave as approved, then widen in rings.
• Lift temporary measures on a date: unpin versions and resume updates as soon as the clean build is confirmed; record when.
• Test detections: push a harmless test extension and a test policy change through change control and confirm both raise alerts.
• Rollback: keep the pre-incident and rebuilt baselines in version control so a recovery change can be reverted without reintroducing attacker settings.

Choosing the scale of response

Evidence and notification

• Preserve: console audit log exports, policy exports before and after, the extension package and version, installer hashes, identity provider sign-in logs, and a sample of affected browser profiles for analysis. See the Browser Forensics Guide.
• Data control logs are evidence and exposure: if they captured personal data and the attacker reached them, include them in the breach assessment.
• Notify: GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals. Other duties vary by sector and country; see the Cyber Incident Reporting Requirements Map.

Detection and measurement

1. Time from an unapproved console change to alert, measured in exercises.
2. Share of managed browsers enrolled with mandatory enrolment and on a supported version.
3. Number of force-installed extensions without an owner or review date (target zero).
4. Time to revoke sessions for a defined user population at the identity provider and top applications.
5. Age of the last approved policy export.
6. Use of revoked sessions or passwords seen after rotation (target zero after the residual window).

Framework mapping

CIS Controls v8.1 Control 9 covers supported browsers and restricting extensions; see the CIS Control 9 Email and Web Browser Protections Guide.

Common failure patterns

• Removing the extension from the install list only: it stays installed or can be reinstalled; block its ID explicitly.
• Clearing browser data instead of revoking sessions: stolen cookies keep working on the attacker's machine.
• Assuming token revocation unenrols devices: rogue enrolments created during the incident remain under management and receive policy.
• Disabling updates indefinitely: the fleet falls behind on security fixes long after the suspect build is cleared.
• Forgetting injected credentials: passwords the browser filled from a vault are rotated last or never.
• Browser start without management: a browser that cannot reach the tenant runs unmanaged and sidesteps the restored policy.

Practitioner checklist

• Export and hash console audit logs, policy sets, extension lists and enrolled browser inventory before changing anything.
• Lock console administration, remove unknown admins and API keys.
• Block malicious extension IDs and revert relaxed data controls fleet-wide.
• Regenerate enrolment tokens and delete rogue enrolled browsers.
• Pin or pause updates only with a written end date while a build is verified.
• Revoke identity provider and application sessions, and rotate saved, synced and injected credentials for affected users.
• Reinstall and re-enrol browsers that ran tampered code; rebuild devices with endpoint detections.
• Restore policy from the approved baseline and close with a post-incident review.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• Google: Enroll cloud-managed browsers (enrolment and device tokens)
• Google: Manage browser updates on Windows
• Chrome for Developers: Device Bound Session Credentials
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• MITRE ATT&CK: T1176.001 Browser Extensions
• MITRE ATT&CK: T1539 Steal Web Session Cookie

Related NHI Mgmt Group resources: Enterprise Browser and Browser Security Guide · Malicious Browser Extension Incident Playbook · Browser Extension Security Guide · Token and Session Security Guide · If your CASB and SSE platform is compromised