Purchased Chrome extensions became remote content-injection tools

At a glance

What this is: This investigation shows how seemingly benign Chrome extensions were repurposed into remotely controlled content-injection tools that can rewrite webpages and persistently manipulate what users see.

Why it matters: It matters because browser extensions sit inside enterprise trust boundaries, so IAM, NHI, and security teams need to treat delegated software as governed access, not harmless productivity tooling.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read LayerX Security's analysis of remotely controlled Chrome extension abuse

Context

Browser extensions are not just add-ons. They are delegated code that runs inside a user’s trusted browsing session, often with broad visibility into pages, forms, and content. In this case, the governance gap is not classic authentication failure but post-acquisition trust drift, where ownership changes and remote update channels turn a benign extension into a content manipulation layer.

That matters for NHI governance because the extension behaves like a non-human actor with ongoing delegated access, even if it is not a service account or token. Once the code can pull remote instructions and rewrite the DOM, the security question shifts from installation approval to lifecycle control, behavioural monitoring, and offboarding discipline.

Key questions

Q: What breaks when browser extensions can fetch remote configuration and rewrite webpages?

A: The trust model breaks. A browser extension that can pull attacker-controlled instructions and modify page content is no longer a static utility, it is a runtime control plane inside the user session. That means store review, install approval, and signature checks do not fully describe the risk, because effective behaviour can change after deployment.

Q: Why do browser extension ownership transfers increase security risk?

A: Ownership transfers can separate the original benign purpose from the person now controlling updates and remote behaviour. If the new operator adds configuration fetching, DOM rewriting, or persistence logic, the extension can become malicious without a fresh store listing. Security teams should treat ownership change as a trust reset, not an administrative detail.

Q: How can security teams detect malicious browser extensions in practice?

A: Look for recurring outbound requests to configuration domains, mutation-based page rewriting, and injected HTML or form changes that do not match the extension’s advertised function. Behavioural sandboxing is more reliable than name-based allowlists, because abused extensions often keep the same branding while their runtime logic changes after acquisition.

Q: Who is accountable when a browser extension is repurposed for content injection?

A: Accountability sits with the organisation that approved the extension, the team that maintains the extension allowlist, and the owner who controls updates after a transfer. Governance should require periodic revalidation of delegated software, because runtime abuse can occur long after initial installation and well before users notice visible tampering.

Technical breakdown

Remote configuration turns a browser extension into a live control plane

The core mechanism is periodic retrieval of attacker-hosted configuration, typically every five minutes in the cases described. That configuration defines target patterns, DOM selectors, and remote payload locations, which lets the extension change behaviour without a new store update. In practice, this is command-and-control embedded inside the browser, because the extension can be redirected at runtime to new sites and new actions. The risk is not just malicious code, but mutable code paths that allow the operator to rewrite what the extension does after publication.

Practical implication: monitor for extensions that fetch remote configuration files and treat that behaviour as a control-plane signal, not a harmless update pattern.

DOM injection makes webpage manipulation persistent and user-visible only by effect

Dynamic DOM injection lets the extension overwrite page elements, replace links, insert HTML, or change displayed content using rules from the remote configuration. The article also describes MutationObservers, which reapply changes whenever the page updates, making the manipulation resilient against normal page refresh behaviour. This creates a durable in-session tampering model rather than a one-time script injection. For practitioners, the architectural issue is that the extension becomes an active intermediary between the user and the site, capable of altering trust cues, forms, and transactional content on demand.

Practical implication: inspect extensions for DOM rewriting logic and persistent mutation monitoring, because those are strong indicators of content tampering capability.

Ownership transfer is the governance breakpoint in extension abuse

The campaign pattern described in the article is consistent: benign behaviour before ownership change, followed by remote injection logic after acquisition. That sequence matters because store review tends to focus on the published package, not the lifecycle event that changes who controls it. A browser extension can remain installed, trusted, and auto-updated while its operational intent flips. This is a lifecycle failure, not a packaging failure. Once ownership changes, the extension’s trust chain should be re-evaluated as if access had been delegated to a new operator with broader runtime authority.

Practical implication: tie extension trust decisions to ownership changes and not just install-time review, because post-acquisition modification is the abuse window.

Threat narrative

Attacker objective: The attacker aimed to convert trusted browser extensions into remotely controllable webpage manipulation tools that could alter what users saw and interacted with in real time.

1. Entry began when a previously benign Chrome extension changed ownership and later pulled remote configuration from attacker-controlled infrastructure.
2. Escalation occurred when the extension used those instructions to inject HTML, overwrite DOM elements, and persistently alter page content without requiring a store update.
3. Impact was webpage manipulation at scale, including deceptive overlays, altered forms, and content tampering that could support phishing or fraud.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser extensions have crossed from convenience tooling into governed access assets. Once an extension can fetch remote instructions, rewrite DOM content, and persist changes across page updates, it is no longer a passive add-on. That behaviour belongs in access governance, not only endpoint hygiene, because the extension is acting inside the trusted user session. Practitioners should treat extension runtime behaviour as part of the identity attack surface.

Post-acquisition trust drift is the failure mode this campaign exposes. The extension was designed for a benign owner and a stable operating model. That assumption fails when ownership changes and the new operator can insert remote configuration logic after publication. The implication is that store approval alone is not a durable control model for delegated software.

Remote configuration fetching is a named control gap, not a feature request. The article shows that periodic config retrieval created an off-store control path that allowed the extension to change target sites and payloads instantly. That pattern collapses review assumptions built around static code and predictable updates. The practitioner takeaway is to classify remote-config behaviour as an abuse indicator, not an implementation detail.

Identity governance must extend to software that impersonates user intent inside the browser. These extensions operated as non-human actors with delegated authority to modify what users perceived and clicked. That makes them relevant to NHI governance because the risk is not just code execution, but delegated runtime power with no human approval gate once installed. Security teams should model extensions as managed identities with revocation and monitoring requirements.

Remote-config content injection: This is the specific failure mode the campaign illustrates. The extension retained trusted installation status while its effective behaviour was redirected by attacker-owned configuration, which means the real control boundary was never the store listing. Practitioners need to rethink whether signed distribution alone is sufficient when runtime authority can be rewritten after ownership transfer.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For the broader lifecycle view, see Ultimate Guide to NHIs , Standards for the control families that map delegated software to identity governance.

What this signals

Remote-config extensions are a governance problem, not just a browser problem. Once software can rewrite the user’s view of a trusted site, it behaves like a delegated identity that must be monitored, reviewed, and revoked when the trust chain changes. The practical signal for security teams is to expand software inventory and access review processes beyond server-side NHIs to include browser-delivered control surfaces and delegated client code.

LayerX Security’s findings suggest a market-wide pattern: attackers increasingly exploit the gap between initial approval and later behavioural change. That is the same lifecycle problem seen in other delegated access models, where the install decision is durable but the runtime authority is not. Teams that already govern NHI control families should apply the same thinking to browser extensions that can observe, modify, and persist inside authenticated sessions.

As browser workloads become richer, extension governance will need more than allowlists and store reputation. The stronger model is behavioural attestation, with alerts for remote configuration pulls, DOM tampering, and ownership changes that alter the operating context. That is where identity governance starts to converge with endpoint control and browser security.

For practitioners

• Audit for remote-configuration behaviour Inventory browser extensions that periodically contact external domains for config.php, theme.php, or similar instruction files, then flag any package that can alter behaviour outside the store update cycle.
• Treat ownership changes as trust resets Re-review extensions after developer or owner changes, because post-acquisition code insertion can convert a benign package into a runtime manipulation tool without changing its listing metadata.
• Block DOM-rewriting extensions by policy Disallow extensions that use selectors, regex targeting, MutationObservers, or injected HTML unless there is a clearly approved business case and compensating monitoring.
• Monitor browser network behaviour centrally Collect extension-level network telemetry where possible and look for cache-bypassing fetches, recurring polling, and requests to newly registered infrastructure that aligns with extension update timing.
• Align extension governance with NHI lifecycle controls Apply install, review, offboarding, and revocation logic to browser extensions as delegated software identities, especially where they can observe forms, content, or authenticated sessions.

Key takeaways

• Browser extensions that fetch remote instructions can become live content-manipulation tools even when they appear benign at install time.
• The campaign shows that ownership transfer and runtime configuration are the key trust breaks, not just the original store listing or package name.
• Teams should govern browser extensions as delegated software identities, with lifecycle review, behavioural monitoring, and revocation paths when trust changes.

Key terms

• Remote Configuration Fetching: Remote configuration fetching is when software regularly downloads instructions or rules from an external server after it has been installed. In identity terms, it creates a runtime control path that can change behaviour without a fresh approval step, making the software’s effective authority larger than its original review.
• DOM Injection: DOM injection is the alteration of a webpage’s document structure by inserting, replacing, or rewriting elements in the browser. It matters for identity security because it can change what users see, click, or submit inside a trusted session, turning client-side code into a manipulation layer.
• Trust Drift: Trust drift is the gap between the conditions under which software was approved and the conditions under which it later operates. In delegated access environments, it often appears after ownership changes, feature creep, or runtime configuration changes that invalidate the original trust decision.
• Delegated Software Identity: A delegated software identity is a non-human actor that operates with permissions or influence granted through installation, configuration, or ownership rather than a traditional login. For browser extensions, the important issue is not only whether the code is signed, but whether its runtime authority can be changed after approval.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by LayerX Security: Silent Takeover: How Purchased Chrome Extensions Became Remote-Controlled Webpage Manipulation Tools. Read the original.