If you’re a CISO or a threat analyst, you already know the browser is the corporate workspace. What’s easy to forget is that every browser extension is effectively a third-party app runtime living inside that workspace often with broad permissions, frequent auto-updates, and a trust model that’s weaker than most endpoint software controls.

Extensions are attractive to attackers for four structural reasons:

1) Permissions are “high leverage.”
A single extension can read and modify web pages you visit, observe browsing behavior, inject scripts, access cookies/session context (depending on permissions and browser controls), and interact with SaaS workflows. That’s more than enough to support credential theft, session hijacking, data collection, or covert exfiltration.

2) The supply chain is built-in.
Extensions update silently. Even if an add-on is clean on day one, a later update – malicious, compromised, or “monetized” – can flip it into surveillance overnight. This is why “it was fine when we approved it” is not a defense.

3) The web store trust signal is imperfect.
Recent reporting continues to show malicious or privacy-invasive extensions reaching large install bases before removal, including “AI helper” extensions designed to siphon chat content and browsing telemetry.

4) GenAI made prompts a new data class.
A prompt is often a pastebin of the organization: snippets of source code, incident notes, customer context, internal URLs, strategy drafts, or troubleshooting output. When an extension can see the DOM of an AI chat page, it can “prompt-poach” at scale – harvesting what users type and what the model returns. That turns the browser into a DLP blind spot unless you explicitly manage it.

Case Study: “ChatGPTStealer” via an “AI Sidebar” Extension

Microsoft Defender for Endpoint detected “ChatGPTStealer” on an endpoint and initiated containment actions (block + scan + isolation). The suspicious artifacts mapped to a Chromium extension path under the user profile:

…\Microsoft\Edge\User Data\Default\Extensions\inhcgfpbfdjbjogdfjbclgolkmhnooop\…

The stolen data set isn’t just “chat text.” It often includes:

• proprietary code pasted into prompts,
• internal project names, incident context, and architecture clues,
• customer or partner data (PII/PCI exposure risk),
• internal URLs that map your SaaS stack and admin surfaces,
• sensitive query strings or parameters that can include identifiers or session context.

What to Do Operationally (CISO + SOC View)

Immediate response priorities (first hours)

1. Contain the endpoint (MDE isolation is appropriate when active exfil is plausible).
2. Preserve evidence: export relevant MDE alert details, and copy the extension folder for offline analysis.
3. Eradicate: remove the extension, and consider nuking/rebuilding the browser profile if you suspect persistence.
4. Assume prompt leakage for the user: review what the user likely interacted with (AI tools, internal portals, admin consoles).
5. Reset access: revoke sessions and rotate credentials for the impacted identity (especially if the user accessed privileged tools).
6. Scope across the fleet: hunt the extension ID/name and any related artifacts on other devices.

Medium-term controls (days/weeks)

• Move from “user-choice extensions” to enterprise-managed allowlists.
• Add “prompts” to your data classification guidance.
• Treat “AI browser helper” tools like any other third-party SaaS integration: vendor review, least privilege, monitoring, lifecycle.

Advanced Hunting: Practical KQL for Microsoft Defender (MDE / Defender XDR)

Below are KQL queries you can paste into Advanced Hunting to (a) find the extension at scale, (b) detect new suspicious installs, and (c) correlate with network activity.

1) Find installs using the browser extension inventory (best starting point)

Microsoft Defender Vulnerability Management can surface extension inventory via DeviceTvmBrowserExtensions (Preview), including ExtensionId, ExtensionName, InstallationTime, IsActivated, and an ExtensionRisk derived from requested permissions.

DeviceTvmBrowserExtensions
| where ExtensionId == "inhcgfpbfdjbjogdfjbclgolkmhnooop"
| project Timestamp, DeviceName, BrowserName, ExtensionId, ExtensionName, ExtensionVersion,
          ExtensionRisk, IsActivated, InstallationTime, ExtensionVendor
| order by InstallationTime desc

2) File-level scoping: locate the extension folder and associated files

DeviceFileEvents records file activity like creation/modification, which is useful for proving presence even if inventory is incomplete.

let extId = "inhcgfpbfdjbjogdfjbclgolkmhnooop";
DeviceFileEvents
| where FolderPath has "\\User Data\\Default\\Extensions\\" and FolderPath has extId
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA1, InitiatingProcessFileName,
          InitiatingProcessAccountName
| order by Timestamp desc

If your environment uses multiple profiles, broaden it:

let extId = "inhcgfpbfdjbjogdfjbclgolkmhnooop";
DeviceFileEvents
| where FolderPath has "\\User Data\\" and FolderPath has "\\Extensions\\" and FolderPath has extId
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Files=dcount(FileName) by DeviceName
| order by LastSeen desc

3) Detect new Chromium extension installations (generic hunting pattern)

This pattern flags new extension materialization by watching for manifest.json or typical extension scaffolding created under the Extensions directory.

let lookback = 14d;
DeviceFileEvents
| where Timestamp > ago(lookback)
| where ActionType in ("FileCreated","FileModified")
| where FolderPath has "\\User Data\\" and FolderPath has "\\Extensions\\"
| where FileName in ("manifest.json","background.js","service_worker.js")
| extend ExtensionId = extract(@"\\Extensions\\([^\\]+)\\", 1, FolderPath)
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), ExamplePath=any(FolderPath)
          by DeviceName, ExtensionId, InitiatingProcessFileName, InitiatingProcessAccountName
| order by FirstSeen desc

Analyst tip: feed ExtensionId results into an allowlist comparison, or pivot into DeviceTvmBrowserExtensions to pull names, vendors, and risk scoring

Prevention: What Actually Reduces Risk (Not Just “User Awareness”)

1) Enforce extension governance (allowlist-first)

On Edge, Microsoft explicitly supports allow/block controls (e.g., ExtensionInstallAllowlist, ExtensionInstallBlocklist, and the more granular ExtensionSettings).
For Chrome, Google provides enterprise controls via extension policies (commonly using ExtensionSettings to allow/block/force-install).

Practical policy stance that works:

• Block all by default (or severely restrict),
• Allowlist business-required extensions,
• Force-install vetted extensions where needed,
• Disable/limit user installs outside managed channels.

2) Treat “AI helper” extensions as high risk by default

The current wave of malicious and data-harvesting AI-related add-ons is explicitly exploiting trust and novelty, “sidebar assistants,” “multi-model chat,” “productivity boosters.” Recent coverage labels this pattern “prompt poaching” and shows it reaching massive scale before takedown.
Make it policy: No AI extensions unless vendor-reviewed and technically constrained.

3) Add prompt hygiene to your data security program

Your acceptable-use training should explicitly ban pasting:

• credentials, tokens, private keys,
• customer data or regulated identifiers,
• sensitive incident details,
• proprietary code (unless you have an approved internal AI environment).

This isn’t about shaming users: it’s about acknowledging that the browser now hosts untrusted “apps” by design.

4) Monitor extensions like software assets

Use DeviceTvmBrowserExtensions for inventory + risk, and alert on:

• newly installed extensions,
• “High risk” permissions,
• unusual vendor patterns,
• extension IDs seen across multiple endpoints rapidly.

Executive takeaway

Extensions are not cosmetic add-ons; they’re code execution and data access inside your most business-critical application. The “ChatGPTStealer” incident shows why the emerging frontier isn’t just credential theft: it’s knowledge theft: prompts, internal context, and browsing intelligence. Tighten extension governance, hunt for new installs, and treat GenAI prompts as sensitive data: because attackers already do.