GhostPoster campaign shows browser extensions can hide malware

At a glance

What this is: GhostPoster is a browser-extension malware campaign that used steganography, delayed execution, and multi-store persistence to evade review and stay active.

Why it matters: It matters because managed browsers are part of the identity surface, and extension abuse can undermine human access, session security, and downstream NHI controls through stolen or manipulated browser state.

By the numbers:

• The campaign spans 17 confirmed malicious Firefox extensions, with infrastructure overlap across Chrome and Edge.
• 3, ne variant alone accounted for 3,822 installs.

👉 Read LayerX Security's analysis of the GhostPoster browser extension campaign

Context

Browser extensions are a high-trust layer inside the human identity stack because they operate inside the user session, can observe page content, and can alter what the user sees or submits. GhostPoster shows how that trust can be abused when malicious code is hidden in places static review does not expect, including image files bundled with the extension.

For IAM teams, the deeper issue is not just malware on the endpoint. It is that browser extensions can intercept authentication flows, manipulate content in the session, and create a blind spot between policy on paper and actual user behaviour in the browser. That makes extension governance part of identity security, not a separate niche control domain.

The pattern is now familiar: store presence is not the same as trust, and install counts do not equal safety. The article’s starting point is typical for modern browser-threat research, but the operational lesson is broader because the extension channel sits directly in front of SSO, MFA, and web app access paths.

Key questions

Q: What breaks when malicious browser extensions are allowed in managed environments?

A: Malicious extensions can observe sessions, alter web content, inject code, and weaken browser-enforced security controls without needing a classic endpoint exploit. That breaks the assumption that the authenticated browser session is trustworthy once login has succeeded. It also creates a path for credential theft, traffic manipulation, and downstream identity abuse inside the user’s normal workflow.

Q: Why do browser extensions complicate identity and access management?

A: Browser extensions sit inside the human access path, so they can influence what users see, submit, and trust after authentication. That makes them relevant to SSO, MFA, session assurance, and data exfiltration risk. IAM teams need to treat extensions as part of the access surface, not just as software add-ons managed by IT.

Q: How do security teams know if browser extension controls are actually working?

A: They should be able to answer three questions: which extensions are installed, which ones are allowed, and which ones show suspicious runtime behaviour. If the inventory is incomplete or extensions can act without detection after install, the control is not working. Continuous monitoring matters because store takedown does not remove already installed code.

Q: Who is accountable when a malicious extension persists after store removal?

A: Accountability sits with the organisation that permits the extension in the managed browser environment and with the control owners responsible for policy enforcement. A store takedown is not containment if installed copies remain active on endpoints. That is why enterprise browser governance, endpoint control, and IAM oversight need shared ownership.

Technical breakdown

How steganographic payload delivery works in browser extensions

GhostPoster hides initial loader code inside the binary data of a PNG icon file. During runtime, the extension reads the image, extracts bytes that are not visually meaningful, and decodes them into executable content. This defeats security reviews that look for obvious script logic or malicious network calls in the extension bundle. The technique is effective because extension stores and static scanners often treat image assets as inert files, not executable containers. Once the payload is decoded, the extension can move into later-stage retrieval and execution without revealing the original loader structure.

Practical implication: treat bundled media files as potential code carriers and include unpacking checks in extension review.

Why delayed execution and staged retrieval weaken detection

The campaign uses long sleep periods, including 48 hours or more and in one variant roughly five days, before making network requests. That delay breaks simple behavioural detection because the extension looks quiet during installation and early inspection. After dormancy, the malware contacts a remote command-and-control server, retrieves additional JavaScript, and executes it dynamically. This staged model also allows the operator to update payloads after approval and to change behaviour without republishing the extension, which makes store-based review a weak containment point on its own.

Practical implication: monitor extension behaviour over time, not just at install, and flag delayed first-contact patterns.

Browser extension persistence and policy bypass in managed environments

Once installed, malicious extensions remain active until removed, even if the store later takes them down. That persistence matters because browser extensions can modify HTTP headers, inject scripts, and alter page behaviour inside the user session. In managed environments, the real risk is policy bypass through trusted browser state, not only code execution on the host. When an extension can manipulate DOM content or traffic patterns, it can erode the protections IAM teams assume are present at the session boundary, including the integrity of authentication and transaction flows.

Practical implication: pair allowlisting with continuous runtime monitoring for header tampering, DOM injection, and suspicious outbound requests.

Threat narrative

Attacker objective: The attacker objective is to keep a stealthy browser foothold that can monetize user sessions, manipulate web traffic, and persist across multiple browser ecosystems.

1. Entry occurs through a malicious browser extension distributed through extension stores and installed by users in normal browsing workflows.
2. Credential and session abuse follows when the extension operates inside trusted browser context and can manipulate web traffic, headers, and page content.
3. Impact emerges through long-lived persistence, monetisation traffic hijacking, click fraud, tracking, and extended control that survives store takedown until manual removal.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 now belong in the identity security perimeter: GhostPoster shows that a browser add-on can sit directly in the human session, observe content, and alter the user’s interaction path without needing traditional endpoint compromise. That makes browser governance a control plane issue for IAM and security architecture, not a niche desktop-management concern. Practitioners should treat extension policy as part of identity enforcement, not merely software inventory.

Extension review fails when security assumes visible code is the only code: The campaign used steganography inside a PNG icon and delayed activation to bypass static inspection and store review. That is a control gap in the review model itself, not just a missed detection signature. The practical conclusion is that extension vetting must account for non-obvious payload containers and long-dormancy behaviour.

Session tampering is the real identity impact, not just malware presence: Once active, the extension can inject iframes, strip headers, and reshape browser traffic in ways that weaken web security policy enforcement. In identity terms, this can undermine the integrity of authenticated sessions and the trust decisions made by downstream applications. Teams should view browser-side manipulation as a session assurance problem that crosses human IAM and web access governance.

Store removal is not containment when installed extensions persist: The article notes that removed extensions remain active on endpoints until users remove them. That means the operational blast radius outlives the vendor takedown, which is why browser governance needs enforcement inside the enterprise, not just at the store boundary. The practitioner implication is simple: if the endpoint keeps the extension, the risk keeps running.

Identity blast radius in the browser is a useful named concept here: The browser is where authentication, content rendering, and user action converge, so a malicious extension can amplify a small foothold into broad session influence. That concept helps teams think beyond malware detection and toward where the trust boundary actually collapses. Practitioners should map which browser extensions can reach the most sensitive identity flows.

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.
• 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.
• That confidence gap makes browser-side governance harder to ignore, and the broader NHI context is captured in Ultimate Guide to NHIs , Key Research and Survey Results.

What this signals

Browser extension governance is becoming part of identity operations. When extensions can sit inside authenticated sessions, manipulate page content, and persist after store takedown, the control problem moves from endpoint malware to access assurance. Teams should expect browser policy, session monitoring, and identity governance to converge more tightly over the next planning cycle.

Extension allowlisting is no longer enough without runtime telemetry. GhostPoster’s delayed activation and staged payload delivery show why install-time review misses the operational risk. The practical change for programmes is to measure post-install behaviour, not just package provenance, and to tie browser control ownership to IAM and endpoint teams together.

Policy-bound browser state is the new trust boundary. If a malicious extension can alter headers or inject scripts, then the browser becomes a place where identity and data control can fail silently. That is why the identity programme should treat browser extensions as an active part of session risk, not as a separate hygiene task.

For practitioners

• Inventory every browser extension in managed environments Build a live inventory of installed extensions across Chrome, Firefox, and Edge, including those installed outside policy controls. Compare the inventory to approved business use and remove anything that lacks a documented purpose.
• Inspect extension assets for hidden payload containers Review packaged images, scripts, and background assets for steganography, obfuscation, and unexpected byte patterns. Static code review is not enough when the payload can be embedded in a PNG or extracted at runtime.
• Monitor browser behaviour after installation Use behaviour-based controls that watch for delayed first network contact, DOM manipulation, header tampering, and unexpected remote script retrieval. Establish alerts for extensions that stay silent at install and activate later.
• Restrict extension install paths and enforce policy controls Block consumer store installs where possible, allow only pre-approved extensions, and require revalidation when an extension changes permissions or update behaviour. Treat browser policy as part of identity access enforcement.

Key takeaways

• GhostPoster demonstrates that malicious browser extensions can hide executable payloads in non-obvious assets and evade traditional review.
• The campaign’s scale reached 17 extensions and more than 840,000 downloads, showing that store presence does not equal trust.
• Behaviour-based browser monitoring, strict allowlisting, and continuous extension inventory are the controls most likely to reduce this risk.

Key terms

• Browser Extension Governance: Browser extension governance is the practice of controlling which add-ons can run in managed browsers, what permissions they hold, and how they are monitored after installation. In identity programmes, it extends access control into the session layer where authentication, content rendering, and user action intersect.
• Steganographic Payload Delivery: Steganographic payload delivery hides executable data inside apparently harmless files such as images or icons. Security tooling may miss the threat because the malicious content is not obvious until the file is parsed at runtime and decoded into code.
• Session Assurance: Session assurance is the confidence that an authenticated browser session still reflects approved, untampered user activity. It depends on controls that detect manipulation of headers, scripts, page content, and browser state after login, not just on initial authentication success.
• Identity Blast Radius: Identity blast radius is the amount of access, influence, and downstream trust impact a compromised identity can create. In the browser context, a small extension foothold can affect multiple applications, authentication flows, and web security controls from a single session boundary.

Deepen your knowledge

Browser extension governance and session trust are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment relies on managed browsers for authentication and access, the course gives you a structured starting point.

This post draws on content published by LayerX Security: Browser Extensions Gone Rogue, the Full Scope of the GhostPoster Campaign. Read the original.