ShadyPanda shows unmanaged browser extensions as NHI risk

At a glance

What this is: Astrix Security’s article explains how the ShadyPanda browser-extension campaign turned unmanaged extensions into long-lived NHI-style access paths with spying, persistence, and remote execution capabilities.

Why it matters: It matters because IAM, NHI, and IAM-adjacent governance programmes often miss browser extensions even though they can carry broad permissions, long-lived persistence, and direct access to corporate data.

By the numbers:

• 17 minutes and as quickly as 9 minutes

👉 Read Astrix Security's analysis of the ShadyPanda browser-extension campaign

Context

Browser extensions are not just user add-ons. In enterprise environments they can behave like privileged integrations that read browsing activity, reach into SaaS workflows, and persist across sessions, which turns unmanaged extensions into an identity governance problem rather than a simple endpoint hygiene issue.

ShadyPanda shows the consequence of treating extension access as benign. Once a malicious extension is installed, the actor can combine visibility, persistence, and command execution in ways that bypass ordinary human-user controls. That is why extension governance belongs alongside NHI oversight, not outside it.

Key questions

Q: What breaks when browser extensions are treated as low-risk add-ons?

A: Security teams lose visibility into a delegated access layer that can read browsing activity, intercept requests, and persist across sessions. That turns a simple install decision into an identity governance problem. Extensions need ownership, permission review, and lifecycle control because they can behave like durable non-human integrations rather than temporary tools.

Q: Why do browser extensions increase enterprise data exposure risk?

A: They often sit between the user and the browser, which gives them access to URLs, referrers, form data, and workflow context. If a malicious extension is installed, that access can be used for spying or remote action without a traditional malware footprint. The risk rises when permissions exceed the declared business purpose.

Q: How can security teams tell whether an extension is over-privileged?

A: Compare the extension’s declared function with the permissions it requests and the data paths it can observe. If a utility tool asks for broad browsing visibility, request interception, or sync access, the access is likely out of scope. A clean approval model requires clear purpose, least privilege, and documented business justification.

Q: How should organisations respond when a suspicious extension is discovered?

A: Remove the extension, reset any synced browser state, and review whether the same identifier or configuration persists across other endpoints. Then assess which data the extension could already see and whether browser activity logs, SaaS sessions, or credentials need follow-up review. Containment must include the identity surface, not just the endpoint.

Technical breakdown

How malicious extensions become persistent access paths

Browser extensions run with declared permissions that can include page access, web requests, downloads, and storage. When those permissions are abused, the extension becomes a delegated access path rather than a simple utility. In this case, the malicious code used disguises such as cleaners and converters to earn installation, then maintained a long-lived foothold through browser storage and cross-device synchronisation. The technical problem is not just installation. It is that the extension inherits trust from the browser and can quietly extend that trust into enterprise data flows.

Practical implication: inventory browser extensions as governed integrations and remove any extension that requests access beyond a clear business justification.

Remote code execution and spyware inside extension permissions

Malicious extensions can do more than observe. With access to browser APIs and network paths, they can exfiltrate URLs, referrers, and fingerprinting data, while also using command-and-control infrastructure to trigger remote actions. That creates a dual-use pattern: data theft plus operational control. The important architectural point is that browser permission models often assume benign developer intent. Once that assumption fails, the extension is no longer a productivity tool but an embedded control plane for surveillance and command execution.

Practical implication: block high-sensitivity permission sets such as browsing-data and request interception unless a formal review proves they are required.

Cross-device persistence through browser sync and stored identifiers

The most dangerous part of the campaign is persistence that survives normal user behaviour. By storing a UUID and syncing it through browser mechanisms, the operator can keep a stable identifier across devices and sessions, which makes revocation harder and tracking more durable. That is a governance problem because the identity is no longer tied to a single machine or one login session. The extension effectively becomes a durable non-human actor with its own continuity of state.

Practical implication: treat synced browser state as part of the identity surface and monitor for persistent identifiers that outlive user sessions.

Threat narrative

Attacker objective: The attacker aims to maintain durable visibility into user activity, preserve persistence across devices, and use browser access as a covert channel for spying and remote control.

1. Entry occurred when users installed malicious Chrome and Edge extensions disguised as routine utilities such as cleaners and PDF tools. Credential access and data harvesting followed through browser permissions that exposed URLs, history, referrers, and fingerprinting data. Escalation came from remote code execution backdoors and command-and-control infrastructure that allowed the actor to extend control beyond passive spying. Impact included long-term tracking, cross-device persistence, and exposure of sensitive corporate browsing activity and workflows.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 now an identity governance problem, not just an endpoint risk. ShadyPanda shows that extension permissions can create durable access paths into SaaS use, browsing data, and organisational workflows. Once an extension inherits trust from the browser, its access profile needs to be governed like any other delegated identity. Practitioners should stop treating extensions as peripheral software and start treating them as part of the access estate.

Persistent browser state creates a hidden non-human identity surface. The UUID stored in browser sync means the extension can retain continuity across devices and sessions, which breaks the assumption that browser-based access is ephemeral and easy to reset. That is a governance gap in lifecycle thinking, because the identity persists even when the user believes the session has ended. The practical conclusion is that browser state needs to be in scope for NHI visibility and offboarding.

High-sensitivity permission requests are the named concept here: browser privilege drift. The campaign used utility branding to request access with no legitimate business justification, then converted that permission into broad observation and control. Browser privilege drift is what happens when the permission granted at install time expands into a wider operational capability than the original use case implied. Practitioners should regard this as a control boundary failure, not a one-off malicious app.

Policy enforcement is only useful when origin, permission, and business purpose are evaluated together. Blocking extensions from untrusted origins is not enough if over-privileged requests still pass review. Likewise, permission prompts alone do not expose whether the extension is meant to observe browsing activity or manipulate it. The governing question is whether the requested access can be justified for the declared function. Practitioners should build review logic around that three-part test.

Cross-device persistence makes revocation a lifecycle issue, not a simple uninstall task. Once an extension can survive through sync and stored identifiers, removal from one endpoint does not equal offboarding from the identity surface. That changes the governance model for browser-integrated NHIs because the asset is no longer tied to one machine or one user profile. Practitioners should build lifecycle controls for extensions the way they already would for other persistent non-human credentials.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader breach pattern view, read 52 NHI Breaches Analysis to see how hidden access paths become durable incident drivers.

What this signals

Browser privilege drift: the real issue is not whether a browser extension is malicious at install time, but whether its permissions and sync state create a durable access path that outlives user intent. Once that happens, browser governance needs to sit beside NHI lifecycle controls, because offboarding a user profile is not the same as offboarding an embedded integration.

A practical response is to fold extension review into the same governance motions used for other non-human access. That means inventory, ownership, expiry, and revocation logic, plus external reference points such as the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0. The programme lesson is simple: if a browser add-on can see enterprise data, it belongs in the identity perimeter.

The next control step is to connect browser state to lifecycle management so revocation is not a single endpoint event. Teams that already struggle with secret sprawl should treat this as the same structural problem in a different wrapper, and use the NHI Lifecycle Management Guide to anchor offboarding and review practice.

For practitioners

• Inventory browser extensions as governed identities Classify extensions that can access browsing data, network requests, or browser storage as non-human integrations. Require owners, use cases, and expiry rules for anything deployed on corporate endpoints.
• Block high-risk permission combinations by policy Reject extensions that request browsingData, webRequest, or similar high-sensitivity permissions unless the business need is documented and approved through a security review.
• Add extension provenance checks to app approval workflows Review publisher origin, signing history, and installation path before allowing enterprise use. Treat unknown or high-risk origins as a separate control decision, not just a procurement concern.
• Include browser sync state in offboarding and incident response When a suspicious extension is removed, also reset synced browser state, remove persistent identifiers, and verify that the same extension is not reintroduced through another profile.

Key takeaways

• ShadyPanda shows that malicious browser extensions can operate as persistent non-human access paths, not just risky user add-ons.
• The campaign’s scale, with more than 4.3 million users affected, shows why browser extension governance belongs inside identity and access programmes.
• The control that matters most is not detection after install, but permission review, provenance checks, and lifecycle offboarding for extension state.

Key terms

• Browser Privilege Drift: Browser privilege drift is the gap between what an extension says it does and what its permissions allow it to do. In practice, a simple utility can evolve into a broad access layer for browsing data, requests, and stored state, which makes governance and offboarding essential.
• Persistent Browser State: Persistent browser state is information stored by the browser that survives a single session, such as sync data, identifiers, and configuration. For identity governance, it matters because persistence can outlive the user’s intent and keep an extension or integration effectively active across devices.
• Delegated Access Path: A delegated access path is a non-human component that inherits trust from another system and can act on its behalf within declared permissions. Browser extensions are a common example because they operate inside the browser context and can observe or modify data flows without being the primary user.

What's in the full article

Astrix Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The permission-by-permission breakdown of the malicious extension family, including how each access scope enabled spying or persistence.
• The context used to decide when supplier origin and high-sensitivity permissions should trigger immediate removal.
• The detection and policy logic behind proactive blocking of untrusted extensions before enterprise rollout.
• The specific extension names and behavioural indicators that security teams can use during internal review.

👉 Astrix Security's full post covers extension behaviour, risk context, and policy enforcement details.

Deepen your knowledge

Browser extension governance and lifecycle control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats extensions as peripheral software, it is time to close that gap.