Browser extensions can become long-lived identity footholds

At a glance

What this is: This is an analysis of a browser-extension campaign that used legitimate-looking TikTok downloaders as a long-lived foothold for tracking, fingerprinting, and post-install behaviour changes.

Why it matters: It matters because identity and access teams increasingly have to govern browser-installed software that sits inside authenticated sessions, not just accounts and devices.

By the numbers:

• Extensions typically operated legitimately for 6 to 12 months before introducing malicious features.
• 12 interrelated browser extensions were identified across the, cross the Chrome and Microsoft Edge marketplaces.

👉 Read LayerX Security's analysis of the TikTok downloader extension campaign

Context

Browser extensions are often treated as convenience software, but in practice they can sit inside authenticated user sessions and observe activity, collect data, and change behaviour after installation. This campaign shows why install-time approval is not the same as runtime trust, especially when the extension can fetch remote configuration and alter its function later.

For IAM and NHI practitioners, the useful question is not whether a browser add-on is labelled legitimate at the point of install. The question is whether it can behave like a controlled identity-adjacent foothold after trust has already been granted, which is exactly where current marketplace review models struggle.

Key questions

Q: How should security teams govern browser extensions that run inside authenticated sessions?

A: Security teams should govern browser extensions as runtime software assets that can observe and affect authenticated sessions. That means inventorying them, limiting installation to approved sources, monitoring network destinations and DOM activity, and revoking extensions that fetch remote configuration or change behaviour after install. Marketplace approval alone is not enough to establish trust.

Q: Why do browser extensions create identity and access risk beyond normal endpoint software?

A: Browser extensions sit inside the user’s active session, so they can see behaviour, collect telemetry, and influence requests in a context that already has trust. That makes them identity-adjacent footholds rather than simple utilities. The risk grows when extensions can update themselves or fetch remote instructions after installation.

Q: What breaks when browser extension reviews only check install-time permissions?

A: Install-time reviews fail when the extension can change behaviour later through remote configuration or cloned replacement listings. The review covers a static artifact, but the user experiences a mutable one. That gap allows legitimate-looking extensions to become tracking or data-collection tools after they have already passed marketplace scrutiny.

Q: What should organisations do when a browser extension appears legitimate but behaves differently over time?

A: They should remove the assumption that store metadata is proof of safety and treat the extension as a monitored, revocable component. Investigate whether it contacts unknown domains, alters functionality after installation, or shares a code family with other suspicious listings. If those signals exist, containment should happen before the extension keeps operating in managed browsers.

Technical breakdown

Manifest v3 browser extensions and shared codebase reuse

The samples use a consistent Manifest V3 architecture with nearly identical permissions, host permissions, and code structure. That matters because the campaign does not depend on one uniquely malicious binary. It depends on cloned or lightly modified extensions that preserve functionality long enough to earn trust, then redeploy under new names when removed. The shared codebase also makes it easier to maintain infrastructure and update behaviour across many listings. In practical terms, the apparent diversity of products masks one coordinated operational model.

Practical implication: treat repeated code and permission patterns across extensions as a control signal for review, not as separate low-risk products.

Remote configuration and post-install behaviour change

Remote configuration turns the extension into a moving target. Instead of hardcoded behaviour, the extension fetches instructions from attacker-controlled infrastructure and can change what it does after installation, including network activity, data collection, or feature activation. This defeats the assumption that review at publication time captures the full risk. In other words, the reviewed artifact is not the same artifact the user runs a month later. Behavioural drift becomes part of the design, not an anomaly.

Practical implication: inspect post-install network destinations and configuration fetches, not just manifest permissions and store metadata.

User fingerprinting inside authenticated browser context

The extensions collect telemetry such as language, timezone, user agent, content interaction, and even battery status. That combination is useful because it creates a high-entropy device fingerprint and helps tie sessions together across visits. When an extension runs inside a logged-in browser, it can observe more than a website can usually see on its own, including patterns that support tracking and later abuse. The result is not only privacy loss but a durable identity signal that can be repurposed for broader exploitation.

Practical implication: monitor extensions as session observers and data collectors, not just as convenience plugins.

Threat narrative

Attacker objective: The objective is durable browser-side access that can track users, collect high-value telemetry, and preserve a reusable foothold inside authenticated sessions.

1. Entry occurs when users install a seemingly benign TikTok downloader from a trusted browser marketplace, sometimes after seeing a Featured badge that reduces suspicion.
2. Credential access is indirect but powerful because the extension gains access to authenticated browser context, user activity, and device signals that can support session abuse and tracking.
3. Impact comes from persistent surveillance, post-install functionality changes, and the ability to spin up new clones after removals, preserving access and reach across marketplaces.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 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 are part of the identity attack surface, not just the endpoint stack. When an extension runs inside a signed-in browser, it can observe session context, collect behavioural signals, and influence requests after trust has already been granted. That means identity teams cannot treat browser-installed software as outside governance simply because it is not a user account or a service account. The practical conclusion is that browser runtime behaviour now belongs in identity-adjacent risk management.

Runtime trust is the named concept this campaign exposes. The marketplace validated the extension at install time, but the real control gap appeared after installation when remote configuration changed behaviour. That is a governance failure mode, not merely a malware trick, because the review model assumed the code user accepted was the code that would keep running. Practitioners should recognise that post-install mutability breaks the assumption that trust can be granted once and held constant.

Featured badges can become misplaced trust signals when behaviour is remotely controlled. The campaign shows how surface-level store indicators can amplify adoption even when the underlying code family is shared and the later behaviour is unknown. This does not mean the badge itself is the problem. It means security teams need to separate marketplace reputation from runtime assurance. The practitioner implication is to treat trust indicators as input, not evidence of safety.

Cloned extension ecosystems create a persistence model that resembles identity sprawl. When one listing is removed, another clone can appear with the same code family, similar screenshots, and updated infrastructure. That is operational resilience for the attacker and governance fatigue for defenders. The field should stop thinking only in terms of malicious apps and start thinking in terms of rotating distribution identities for the same underlying capability.

Browser-side telemetry can become a de facto identity layer for tracking. Language, timezone, user agent, content behaviour, and battery status are not random data points. Together they form a profile that can be reused to follow a user across sessions and potentially across services. The practitioner takeaway is that telemetry collection inside the browser deserves the same scrutiny as any other high-risk non-human identity signal.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A further 47% of organisations report only partial visibility into those third-party OAuth connections, which leaves hidden trust paths in place.
• For a broader control lens, read Top 10 NHI Issues for the governance gaps that show up when identity sprawl outpaces monitoring.

What this signals

Runtime trust is becoming the real control boundary. Security programmes that still equate trust with install-time approval will miss the point of browser-based footholds, because behaviour can change long after review. The practical shift is toward continuous observation of extension activity, especially where authenticated sessions and remote configuration intersect.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the next governance frontier is not only service accounts and tokens. Browser extensions that operate inside user sessions behave like adjacent non-human identities and need similar lifecycle and monitoring discipline.

Identity blast radius: browser extensions can expand the effective blast radius of a compromised session by observing behaviour, collecting telemetry, and reconfiguring themselves after installation. Teams should assume that any extension with remote control channels can become a moving part of the identity surface, not a fixed utility.

For practitioners

• Inventory extensions as governed software assets Map all browser extensions in managed environments, including those installed outside policy. Record publisher, permissions, update channel, remote endpoints, and whether the extension can fetch configuration after install.
• Block remote configuration paths for unapproved add-ons Flag extensions that retrieve JSON, script, or control data from external domains. Any post-install configuration fetch should trigger review because it can change behaviour without user awareness.
• Monitor extension behaviour after installation Track network destinations, DOM interaction, and permission drift over time rather than relying on marketplace validation alone. Focus on changes that appear after a reputation-building period.
• Separate marketplace trust from runtime assurance Treat Featured status, screenshots, and store ratings as weak signals. Require behavioural evidence from the extension’s live activity before allowing access in managed browsers.

Key takeaways

• Browser extensions can become long-lived, identity-adjacent footholds when runtime behaviour is controlled remotely after installation.
• The campaign’s scale, with more than 130,000 users affected, shows that store trust signals do not substitute for behavioural assurance.
• The control that matters most here is continuous runtime monitoring of extension behaviour, not reliance on marketplace review alone.

Key terms

• Browser Extension Runtime Trust: The level of confidence an organisation places in a browser extension after it has been installed and is operating inside a user session. For security teams, this trust must be based on observed behaviour over time, not just marketplace approval or permissions at the point of install.
• Remote Configuration: A control channel that lets software change its behaviour by pulling instructions from an external server after deployment. In browser extensions, this creates post-install mutability, which means the reviewed code and the running code can diverge without user awareness.
• Identity-adjacent Foothold: Software that is not itself an account or credential but operates close enough to the user session to observe, influence, or exploit trusted activity. Browser extensions can become identity-adjacent footholds when they collect telemetry or alter requests inside authenticated contexts.
• High-entropy Fingerprinting: The practice of combining multiple device and behavioural signals to create a distinctive profile for tracking a user across sessions. In this campaign, fields like language, timezone, user agent, and battery status increase the likelihood that a user can be recognised later.

Deepen your knowledge

Browser extension runtime governance is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with browser-based trust gaps or session-adjacent tooling, it is worth exploring.

This post draws on content published by LayerX Security: LLMjacking-style browser extension campaign analysis involving TikTok downloader clones. Read the original.