browserforensics
← Back to all articles

Detect malicious browser extensions

2026-06-21 · 4 min

A rogue extension is one of the quietest footholds an attacker can keep: it reads every page, rides profile sync across machines, and survives a reboot without a single dropped binary. The good news is that the metadata you need to triage one — what it can do, where it came from, and when it landed — sits in plain JSON inside the profile. This is a field-ready workflow for hunting the risky entry among the benign ones.

What a malicious extension looks like on disk

You are not scoring code or running AV — you are triaging metadata. Three signals do most of the work: capability (permissions), provenance (install source), and timing (install time). Any one of them can put an extension on your shortlist; together they make the case.

Red flags to triage

  • Broad or abusable permissions. <all_urls> is the headline, but pair it mentally with the capability it unlocks: webRequest / webRequestBlocking (intercept and rewrite traffic), cookies (read session tokens), tabs and scripting (read and inject into pages), debugger (drive the page via DevTools protocol), and nativeMessaging (talk to a local helper binary). An extension holding <all_urls> plus cookies or webRequest can read and exfiltrate anything the browser sees.
  • Not installed from the store. In Chrome/Edge, from_webstore: false means sideloaded or dev-loaded. In Firefox, a sourceURI that does not point at addons.mozilla.org — a file:// path or an arbitrary HTTPS host — means the same thing. Store review was bypassed.
  • Recent or off-hours install time. An extension that appeared minutes after a phishing click, or at 3 a.m. when the user was asleep, is a lead on its own.
  • Unknown extension id. A 32-character Chrome id or a UUID/email-style Firefox id you do not recognise — and cannot find in the store — is worth a second look.
  • Externally added or force-installed. Entries marked as externally added, or pushed via enterprise policy, deserve confirmation that the policy is real and not attacker-planted persistence.

Where to look

Chrome / Edge

Each extension lives under the extensions.settings object inside the profile's Preferences and Secure Preferences files. Keyed by id, every entry carries the manifest name and version, the granted permissions, the install_time, and the from_webstore flag. The extension's actual code sits separately on disk:

…\<profile>\Extensions\<id>\<version>\

Pull the manifest.json and the background/content scripts from there when you need to read what the extension does, not just what it declared.

Firefox

Firefox keeps its inventory in extensions.json at the profile root. The high-value fields are active (enabled or not), sourceURI (where it was installed from), installDate, and type (extension, theme, dictionary, …). sourceURI is your provenance check; a disabled add-on still counts as evidence that someone installed it deliberately.

The hunting workflow

  1. Parse the extensions from Preferences / Secure Preferences and extensions.json into one sortable view.
  2. Sort by install time. The most recent installs are the cheapest to clear or escalate first.
  3. Scan permissions. Triage by capability, not by name — find the entries holding <all_urls>, cookies, webRequest, debugger, or nativeMessaging.
  4. Flag non-store sources. Filter for from_webstore: false (Chrome) and non-AMO sourceURI values (Firefox).
  5. Correlate against the incident timeline. Line each install_time / installDate up against the known events of the case — a logon, a phishing click, a fresh download. An extension that appears in that window is a strong lead.
  6. Cross-reference unfamiliar ids with the public store to confirm the name, publisher, and current permission set match what is on disk.

In the tool

BrowserForensics parses Chrome Preferences / Secure Preferences and Firefox extensions.json into sortable tables — id, name, version, permissions, source, install time, and state — entirely in your browser, with nothing uploaded. That makes it quick to surface the one entry with <all_urls> and a file:// source among twenty benign theme add-ons. The tool exposes this metadata so you can triage and correlate it; it does not score or AV-scan the extension code itself.

Further reading