SURIQ
An extension store review is a single photograph of a moving target. Microsoft's takedown of the campaign it calls StegoAd shows exactly how little that photograph is worth. The 119 Edge extensions it pulled shipped clean, passed review, sat quiet for days, then pulled their real payload out of an ordinary-looking image or font file and went to work. By the time the code that stole your Google password existed on the machine, the review that approved the extension was weeks in the past and had inspected none of it.
This is the part defenders should sit with. The thing that got vetted and the thing that attacked your users were never the same software. That gap is the whole campaign, and it is why a one-time gate at publish does almost nothing against this class of threat.
Microsoft's Edge security team disclosed the takedown on June 29, 2026, and independent reporting from The Hacker News and Security Affairs filled in the campaign's evolution. The name is a contraction of steganography and adware, and both halves matter.
How code hides inside a picture
Steganography means hiding data inside an innocent-looking file. StegoAd's operators were good at it, and they kept moving as detection caught up. Early extensions tucked JavaScript after the IEND marker that signals the end of a PNG image, so the picture still rendered normally while the extension peeled the extra bytes off the end and ran them. When scanners learned that trick, the actor switched to WebP images, then to WOFF2 web fonts, where payload bytes lived as high Unicode codepoints tucked into glyph tables, passing for foreign script or routine typeface internals. By March 2026 the operators were renaming a PNG to setting.conf and pulling Base64 out from between slash delimiters.
| Carrier file | Where the code hid | What it slipped past |
|---|---|---|
| PNG image | JavaScript appended after the IEND end-of-image marker | Static scanners that stop reading at the image boundary |
| WebP image | Same trailing-data trick in a newer container | Tools that had learned to flag tampered PNGs |
| WOFF2 font | Payload bytes stored as high Unicode codepoints in glyph ranges | Pattern matching that never inspects font glyph tables |
| setting.conf | A PNG renamed to a config file with Base64 between slash delimiters | File-type heuristics keyed on extension |
None of these formats is exotic. Every browser loads images and fonts constantly, and almost no security tool treats a font file as executable input. That is the point. The actor was not breaking encryption or finding a zero-day. They were storing instructions in the one place defenders had decided was safe to ignore.
Why "it worked fine for a week" was the trap
StegoAd did not run the moment you installed it. Extensions stayed dormant for roughly three to five and a half days after install, and some only activated in about one session in ten. They also watched for trouble: a flag the operators called dipFlgDev checked whether developer tools were open, and if an analyst was poking at the extension, it extended its sleep indefinitely and served decoy content. The command server added its own gate, checking each caller's extension identifier and browser fingerprint before it would release anything live, so a researcher pulling the file got a harmless dummy.
Invert your intuition here. For sleeper malware, a quiet first week is not evidence the extension is clean. It is the expected behavior. The campaign was built specifically to make "I have been using it for a while and nothing happened" the wrong conclusion. We have seen the same shape in a package that cleared inspection and turned hostile a day later: the artifact that gets checked and the artifact that attacks are not the same one. Any model of trust that depends on a user noticing something go wrong has already lost to a design like this.
The second factor it stole as you typed it
Once awake, the extensions had full reach into the browser session. Microsoft recovered a backdoor that executed arbitrary JavaScript pushed from a server, credential theft aimed at Google sign-in pages that captured passwords and second-factor codes, WordPress administrator login harvesting, and bulk cookie theft for session hijacking. Stolen data left through a domain named mitarchive.info. Layered on top was the ad-fraud business: injected ads, swapped AdSense and Amazon slots capped at six per page to stay quiet, and hijacked affiliate commissions across Amazon, eBay, AliExpress, and other stores.
The credential theft carries the lesson worth keeping. When the adversary is running inside the browser tab, it reads your one-time code at the moment you type it into the real login form. A time-based code from an authenticator app and an SMS code are both just short-lived secrets that pass through the page, so an in-session attacker forwards them in real time. Phishing-resistant keys behave differently. A passkey or hardware security key signs a challenge bound to the site's origin, and the signing secret never enters the page, so there is nothing for an in-browser thief to copy and replay. This campaign is a clean argument for moving the accounts that matter off SMS and authenticator codes and onto WebAuthn keys.
Manifest V3 did not change the outcome
Browser vendors sold Manifest V3, the current extension platform, partly as a security improvement, because it removes the old ability to intercept and rewrite network responses live. StegoAd adapted in weeks. Where the older Manifest V2 builds rewrote HTTP responses directly, the V3 builds fetched declarativeNetRequest rules from the command server roughly every 15 days to keep stripping security headers through the new, sanctioned mechanism. The platform change raised the actor's cost a little and changed none of the results. That is a useful calibration: tightening the extension API narrows specific techniques, but a funded operator treats it as an engineering ticket, not a wall.
The same adaptability shows in attribution. Koi Security tied the exfiltration domain and the icon-hiding method to DarkSpectre, a China-nexus operation previously linked to campaigns tracked as ShadyPanda and GhostPoster, and StegoAd reused extension names and steganographic tradecraft from those. Microsoft did not publicly name the actor. Across roughly eight removal waves from early 2024 to April 2026, every takedown was answered within weeks by fresh domains, new encryption, and a new carrier format.
Make extension installs a policy decision, not a user choice
Cleaning up after StegoAd starts with the obvious and ends with the structural. Check edge://extensions against the full list of 119 IDs in Microsoft's report, and treat any browser that ran one as compromised: rotate Google, WordPress, and any financial passwords reached from it, and review recent sign-in activity. Microsoft published the indicators in a form usable across Chromium browsers, so the same checks apply to Chrome estates.
The durable fix is to stop leaving extension installation to individual judgment, the same gap that lets marketplace plugins built to steal developer credentials reach the people who trust the store. Both Edge and Chrome support an enterprise allowlist through group policy, where ExtensionInstallAllowlist permits only vetted IDs and ExtensionInstallBlocklist set to a wildcard blocks everything else. Most organizations never turn this on, which is how a credential stealer reaches 2.6 million browsers. Pair the allowlist with detection on the behavior the store cannot see: an extension reaching out to an unfamiliar domain, decoding font or image assets into executable strings, or rewriting request headers. Those runtime signals are where this campaign was always visible, even while the store said it was fine.