This tabletop walks a team through a compromised force-installed browser extension in about 45 minutes. It tests whether you can find where the extension runs, block it, remove it, and decide what to rotate, using the browser policy behavior your team should already know.
Set up the exercise
Participants: security, IT or endpoint management, the extension owner, a help desk lead and a communications contact.
Scenario (fictional): A vendor extension, force-installed for all staff, ships an update. A researcher posts that the new version sends page data to an unfamiliar domain. Your help desk begins to receive calls.
Ground rules: Use your real policy repository and console during the exercise, but change nothing. Note every gap in a shared list.
Facts the team should confirm in advance
These come from vendor documentation and are worth checking on your own versions:
- A Chrome force-installed extension cannot be removed or disabled by the user through the browser, and the force setting supersedes the blocklist.
- A blocked extension that is already installed is disabled, not uninstalled, in Chrome and Edge.
- A force-installed extension is uninstalled automatically in Chrome when removed from the force list.
- Chrome checks for extension updates every few hours.
The injects
| Minute | Inject | Questions |
|---|---|---|
| 0 | Researcher post and first help desk call | Who decides this is an incident? Who is the incident lead? |
| 10 | You confirm the extension is force-installed to all staff | Which groups, how many devices, which version is live? |
| 15 | Executive asks if customer data is exposed | What permissions did the extension hold? What could it read? |
| 20 | You try to block it | Which policy file changes? Who approves? Does the force entry need to go first? |
| 30 | Some devices still show it | What does disabled versus removed mean here? How do you verify? |
| 40 | Vendor says a fix is coming | What is the criteria to allow it again, and who signs off? |
Discussion prompts
- How fast could you list every device with the extension installed?
- Do you know which sites staff used in the exposure window?
- Which credentials or sessions need rotation, and who does it?
- How do you tell staff what happened, in plain language, without speculating?
- Where is the extension owner recorded, and did that record work?
Scoring the exercise
Give one point for each of these you could do in under an hour with existing tools: identify scope, block, remove, confirm removal on a sample machine, notify staff, and record a timeline. Anything under four points becomes an action item with an owner and a date.
After the exercise
- Fix gaps in the owner register.
- Make sure the response steps match what you actually did.
- Add a rule that no extension update is trusted forever: re-review on publisher or permission change.
- Schedule the next run within a year.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how a later change raises an alert even when the first scan was clean. That is the gap this exercise probes.
Quick check
Who should run the exercise?
A facilitator who does not own the extension, so they can ask uncomfortable questions.
Do we need a real incident to learn from this?
No. A fictional scenario against real tools and records exposes most gaps.
Sources
- Chromium policy definition: ExtensionInstallForcelist
- Chromium policy definition: ExtensionInstallBlocklist
- Microsoft Learn: Manage Microsoft Edge extensions with policies
- Chrome for Developers: Self-host for Linux
Last reviewed: 19 October 2026.
