
24.07.2026 browser-forensicsbrowser-extensionssession-hijackingsupply-chain
Anyone who still thinks browser extensions are a niche concern for privacy nerds missed a busy few weeks in mid-2026. Within days of each other, three campaigns surfaced that show just how professional this space has become: a fake Perplexity extension, a crypto-clipper campaign dubbed “Silent Swap,” and – as the headline case – Microsoft’s takedown of 119 malicious Edge extensions. Three browser extension campaigns disclosed in late June 2026 confirm that extensions are now a mature, scalable attack surface reaching enterprise environments.
Microsoft’s disclosure of the “StegoAd” campaign deserves particular attention because it illustrates how far the tradecraft has evolved. The operation ran for roughly five years across more than a hundred extensions, hiding code inside image and font files and layering in delayed execution, analyst-detection checks, and decoy server responses to survive both store review and researcher scrutiny. Concretely, this involved hiding executable payloads inside PNG, WebP, and WOFF2 files, allowing malicious logic to appear as ordinary extension assets. The technique itself evolved over time: early versions appended malicious data after the end marker of PNG image files, letting the image render normally while carrying extra, unscanned content.
The scale is remarkable: combined, the 119 extensions had an install base of up to 2.6 million users, while a multi-day delay, server-side validation, and a 10% execution gate on some variants meant the payload never fired for many installs. That restraint is precisely what makes forensic reconstruction so difficult: an incident response team examining an extension at time X may find nothing at all – the logic bomb simply hasn’t detonated yet.
A parallel campaign illustrates the other side of the coin: targeted attacks on enterprise software. In early 2026, security researchers uncovered a coordinated campaign targeting enterprise HR and ERP platforms, in which five Chrome extensions, installed more than 2,300 times, masqueraded as productivity tools for Workday, NetSuite, and SuccessFactors. The consequences were severe: once installed, they exfiltrated session tokens, enabled direct account takeover, and prevented IT teams from accessing security controls to respond.
Investigating these campaigns requires more than checking store ratings. Two artifacts in every extension folder are central: manifest.json, which defines the extension’s permissions, scope, and where it is allowed to run, and the content script (commonly content.js), which executes within web pages and interacts directly with page content – together these provide essential context for identifying extensions with excessive access or malicious intent. Crucially, manifest.json and content.js must be reviewed together; neither is meaningful in isolation.
A second focus area is Native Messaging – the bridge between an extension and a local process that lets attackers escape the browser sandbox. A recently documented Italian campaign shows the pattern: a malicious Chrome extension used Native Messaging to escape the browser sandbox, steal session data and execute remote PowerShell commands on Windows. For investigators this translates into concrete steps: Native Messaging registrations under HKCU should be compared with an approved software inventory, the allowed_origins field in each host manifest reveals which extension can start the host, and an unknown extension ID paired with an executable in a user-writable directory is a strong warning signal.
Making matters worse, Manifest V3 has reduced but not eliminated the attack surface. Recent research found that after adapting to the new framework, 290 of 517 examined malicious extensions (56%) retained their capability to conduct harmful activities within the V3 framework. And even after an official store cleanup, the case isn’t closed: removed store listings do not automatically solve every installed-client scenario, every synced profile, every sideloaded package, or every cross-browser installation. For DFIR teams, the takeaway is clear: extension hunting belongs in every endpoint triage checklist – not as an optional extra, but as standard procedure.
← Back to overview