Get Installed Browser Extensions

What the browser extension inventory Worklet does

This Automox Worklet™ enumerates every browser profile under every local user account on a Windows endpoint and reports the full set of installed extensions. The Worklet covers the four Chromium and Gecko browsers that account for nearly all Windows fleet exposure: Microsoft Edge, Google Chrome, Brave, and Mozilla Firefox. It runs from the Automox agent context, so no interactive login is required and no end user is prompted.

For each Chromium browser, the script reads manifest.json from every subfolder of the user's Extensions directory and extracts the name and version fields. When an extension uses Chrome's internationalization scheme and lists its name as a __MSG_<id>__ token, the Worklet follows the pointer into _locales\en\messages.json and resolves the token to the human-readable string. Without that resolution step, an audit would surface dozens of __MSG_extName__ rows that no analyst can act on.

For Firefox, the Worklet parses extensions.json from each profile directory, filters the addons array for entries where hidden is false and type is extension, then emits the defaultLocale.name and version. The final output is grouped by user, then browser, then profile, then extension. The hierarchy is the same one a SOC analyst already uses when correlating a malicious add-on advisory to a specific workstation, so the Activity Log entry maps directly onto an incident response timeline.

Why audit browser extensions across the fleet

Browser extensions are a frequently overlooked risk on hardened Windows endpoints. A signed, reviewed extension can be sold to a new owner, repackaged with credential-stealing code, and pushed through the official update channel without any prompt to the end user. The 2023 Cyberhaven incident and the recurring waves of malicious Chrome Web Store removals show that a clean inventory yesterday is no guarantee today. The CIS Microsoft Windows benchmarks for Edge and Chrome and the CIS Mozilla Firefox benchmark all include controls for extension allowlisting and inventory (specific section numbers vary by benchmark version), and the inventory itself supports the installed-software evidence called for in SOC 2 CC6.1 and PCI-DSS 2.2.

Blocking extensions through ExtensionInstallBlocklist via Group Policy is fast; reading the actual extension state already installed under every user profile across managed endpoints is the harder operational step. Targeting this Worklet from the Worklet Catalog or running it via FixNow against your Windows workstation group reads the Chrome, Edge, Brave, and Firefox extension state under each profile on every targeted endpoint, then reports the results into the Activity Log. A known-bad extension ID becomes a concrete list of endpoints to act on, not a population-wide guess.

How the browser extension scan works

1. Evaluation phase: The evaluation script is intentionally a no-op that exits 0, so every targeted endpoint advances to the remediation phase. This Worklet is built as a Catalog or FixNow inventory tool, not a compliance gate, so there is no extension state to compare before reading the data.

2. Remediation phase: The remediation script queries Win32_UserProfile via Get-CimInstance, filters to interactive user SIDs that match S-1-5-21, and walks each profile path. For each user it probes the three Chromium data roots under %LOCALAPPDATA% (Microsoft\Edge\User Data, Google\Chrome\User Data, BraveSoftware\Brave-Browser\User Data) and the Firefox root under %APPDATA%\Mozilla\Firefox\Profiles. Chromium evaluation iterates the Default profile plus Profile 1 through Profile 50, opens each extension ID folder under Extensions\, picks the first version subfolder it finds, and parses manifest.json. If the manifest name uses the __MSG_<id>__ internationalization token, the script reads _locales\en\messages.json and resolves the token to the human-readable string. Firefox parses extensions.json and filters addons where hidden is false and type is extension, then emits defaultLocale.name and version. Results are written to the Activity Log as a nested tree of user, browser, profile, and extension name and version pairs between BEGIN OUTPUT and END OUTPUT banner lines.

Browser extension audit requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, or 2022 endpoint with the Automox agent installed

• At least one of Microsoft Edge (Chromium), Google Chrome, Brave Browser, or Mozilla Firefox installed on the endpoint; absent browsers are skipped silently

• PowerShell 5.0 or later (5.1 ships with Windows 10 and later) so Get-CimInstance and ConvertFrom-Json are available without modules

• Automox agent running as SYSTEM, which it does by default, to read every user profile directory without per-user credentials

• Run via FixNow or from the Worklet Catalog, a Device page, or a Policy page for on-demand audits; the script header explicitly recommends against scheduled-policy use

• No outbound network access required – every read is local to the endpoint file system

Expected browser extension report

After the Worklet runs, the Automox Activity Log for each endpoint contains a hierarchical extension report. The top-level node is the local user profile name, followed by each browser detected, each profile inside that browser, and each extension as a name and version pair. An endpoint with two Windows users, both running Edge and Chrome, will produce four browser blocks and a flat list of extensions under each. Profiles with no installed extensions are omitted, so the report stays compact even on shared workstations.

Use the report as the input to three follow-up workflows. First, diff this run against the previous run to surface newly installed or silently updated extensions – the version field is the signal for an update. Second, grep the Activity Log for known-bad extension IDs from a vendor advisory or a Chrome Web Store removal post to scope the blast radius across the fleet. Third, export the run output and attach it to the audit evidence package for CIS Benchmark, SOC 2 CC6.1, or PCI-DSS 2.2 reviews. The Worklet does not set a failure exit code on per-profile parse errors, so review the Activity Log directly for any user or browser block that is missing from the tree.