Edgecution: an extension escaped the browser sandbox — how to check what yours can reach

Every time I write about a malicious extension, someone in the replies says a version of the same thing: it's just a browser extension, how bad can it be? The honest answer used to be "bad, but contained" — stolen cookies, hijacked search, injected ads, all of it stuck inside the browser.

Edgecution is the one I point at now. According to BleepingComputer's June report on Zscaler ThreatLabz's analysis, a malicious Microsoft Edge extension served as the front half of a ransomware crew's foothold — and the back half was a Python backdoor running on the host, outside the browser entirely. No browser bug, no zero-day. The bridge it crossed — native messaging — is a documented platform feature that works exactly as designed.

It also never appeared in anybody's extensions list. Edgecution isn't installed in the sense you're picturing: a scheduled task launches a second, headless copy of Edge against a throwaway profile and sideloads the extension into that. The victim's actual browser looks untouched, because it is.

What Zscaler found

Zscaler's researchers describe Edgecution as two pieces that only make sense together. The first is an Edge extension that beacons out to a command-and-control server and relays whatever it's told to do. The second is a Python-based backdoor sitting on the machine, which is where the actual damage happens: collecting system information, writing files to arbitrary paths, listing running processes, running shell commands and PowerShell, and executing arbitrary Python.

The extension by itself can't do any of that. It's the messenger. Zscaler attributes the tooling to an initial access broker connected to the Payouts King ransomware operation — meaning the goal isn't the browser at all. The browser is how the crew gets in the door and hands the keys to someone else.

The way in is depressingly low-tech. Zscaler traces it to a Microsoft Teams message impersonating the company's own IT staff, telling the employee their spam filter needs updating. The link lands on a fake Microsoft page dressed up as an "Outlook Updates Management Console" — not a Web Store listing, a page the attacker controls.

Its buttons hand over an AutoHotKey script, a Windows batch script, or a PowerShell one-liner copied to the clipboard, any of which sets the malware up; one button simply asks for the victim's password outright. If you've followed the ClickFix-style fake-fix lures I wrote about earlier, it's the same social engineering with a corporate costume on. The victim isn't being careless. They're being helpful to a person they think works down the hall.

Zscaler also notes both components carry commands that aren't wired up to anything — BleepingComputer reads them as capabilities that could be switched on in a future version — and published indicators of compromise, C2 servers and file hashes, for defenders to hunt with.

Native messaging is the bridge, and it isn't broken

Here's the part worth understanding, because it will show up again in campaigns that have nothing to do with Payouts King.

Browser extensions are sandboxed. They can't spawn processes, can't read arbitrary files, can't touch your OS. Native messaging is the officially supported escape hatch from that rule, and it exists for good reasons — it's how a password manager extension talks to its desktop app, how a hardware token gets to the browser, how enterprise agents integrate. Chrome documents it, Edge implements the same protocol, and Firefox has its own version.

The mechanics are simple enough to hold in your head. A JSON file called a native messaging host manifest gets registered on the machine. It names the host, points at an executable with path, sets type to stdio, and lists which extension IDs may connect in allowed_origins. The extension declares the nativeMessaging permission. When it calls out, the browser launches that executable as a separate process and pipes JSON between them over stdin and stdout.

Read that list again and notice what's missing: there is no consent step. No prompt, no dialog, no "this extension wants to run a program on your computer." The allowed_origins field is the entire access-control model, and whoever can write that manifest onto the machine decides what it says.

The direction of trust got reversed

Normally the flow goes: you install a desktop app you chose, the app registers its own host manifest, and later an extension connects to it. The app came first, and you agreed to it.

Edgecution runs that backwards. The malware brings both halves — it drops the payload and creates the host manifest that tells the browser how to reach it, with the malicious extension's own ID in allowed_origins. Nothing on the machine had to be vulnerable. The attacker just filled in a form the platform was already reading.

That's why "it's only an extension" stops being a containment argument. The relevant question isn't what the extension can do — it's whether anything on this machine is allowed to register a native messaging host at all. That's a machine-level policy question, and most people, including most IT teams, have never looked at it. I broke down the permission side of this in more depth in my piece on the nativeMessaging permission; Edgecution is what it looks like when someone builds a campaign on top of it.

For scale: when I mapped declared permissions across 308,210 live listings, only 3,515 of them — 1.1% — asked for nativeMessaging at all. That rarity is the good news. On a normal machine the list of legitimate native hosts is short enough to read end to end.

There's a second trap buried in here, and it's the one I'd most like people to take away. Removing the extension does not remove the backdoor. The host manifest and the payload it points at live outside the browser profile. Uninstall the extension, and the Python process, its files, and its registration are all still sitting there — plus a manifest that will happily accept a connection from whatever extension ID it lists, including one the operator installs later. Extension cleanup that stops at edge://extensions is half a cleanup — and against Edgecution it is no cleanup at all, because the extension was never listed there in the first place.

How to check your own machine

None of this requires special tooling. It requires knowing where to look.

1. See which extensions declare nativeMessaging. Open edge://extensions (or chrome://extensions), turn on Developer mode, and click Details on each one. The permission is listed explicitly when it's declared. On a personal machine you should be able to name the desktop app behind every extension that has it. If you can't, that's the one to dig into.

Say the quiet part out loud, though: this step would not have caught Edgecution. The scheduled task starts a second Edge against a separate User Data\Recovery profile with --load-extension and --headless=new, so nothing ever shows up in the list you're reading. Step 1 is baseline hygiene for the extensions you did install. Step 2 is the one that catches this campaign.

2. Inventory the host manifests themselves. This is the step almost nobody does, and it's the step that catches Edgecution-shaped problems. Each registered host is a JSON file or registry entry you can read:

• Windows (Edge): HKEY_CURRENT_USER\Software\Microsoft\Edge\NativeMessagingHosts\ and the HKEY_LOCAL_MACHINE equivalent
• Windows (Chrome): the same paths under Software\Google\Chrome\NativeMessagingHosts\
• macOS: ~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/ (and the Google/Chrome equivalent), plus the system-wide copies under /Library/
• Linux: ~/.config/microsoft-edge/NativeMessagingHosts/ and /etc/opt/edge/native-messaging-hosts/ (Chrome: ~/.config/google-chrome/NativeMessagingHosts/ and /etc/opt/chrome/native-messaging-hosts/)

Open each entry. path tells you which binary the browser will launch; allowed_origins tells you which extension IDs may launch it. A host pointing at a Python interpreter, a script in a temp directory, or anything in a user-writable folder you don't recognize deserves an explanation before it deserves the benefit of the doubt.

3. Treat a suspicious extension as a host-level incident, not a browser one. If you find something you didn't install, don't just remove it and move on. Check for a matching host manifest, check what its path points at, and get the machine looked at properly. Zscaler published IoCs for exactly this reason.

4. Learn the pretext, because it's the reusable part. Real IT departments do not DM you on Teams and walk you through installing a browser add-on from a link. Neither do they need you to paste a command to "fix" anything. The malware in this campaign will be rewritten; the fake-helpdesk script will not, because it keeps working. It's the same delivery pattern behind sideloaded enterprise extension attacks like SNOWBELT.

5. If you run a fleet, close the door with policy. Extension allowlisting is the obvious control, but native messaging has its own. Chrome and Edge support a native messaging blocklist and allowlist, and NativeMessagingUserLevelHosts determines whether user-level hosts — the kind malware can register without admin rights — may be used at all. Turning that off, and allowlisting the handful of hosts you actually need, removes the bridge Edgecution walked across.

Two detections are worth writing down while you're in there. The browser spawning an interpreter is the obvious one — but allow a hop, because Edgecution's manifest points at a .bat file that launches Python, so the rule has to survive msedge.exe → cmd.exe → python.exe rather than matching a direct parent only. The sharper signal is the launch itself: a scheduled task starting msedge.exe with --load-extension and --headless=new is not something a legitimate deployment does. That's the same command-line shape as the SNOWBELT sideloading I've written about before.

If you'd rather start from what's already installed than from a registry key, npx @extenshi/guard scan reads the extensions in your local browsers and flags the risky ones — no account needed for the scan, and you can disable or remove things from the results with an undo. Details are in the guard docs.

Why this one matters more than the install count

Most extension-malware stories lead with reach: 840,000 installs, 4.3 million users, 37 million downloads. Edgecution isn't that story. It's targeted, it's manual, and the interesting number isn't how many people got it — it's how little the attacker needed.

No browser vulnerability. No store review to defeat. No exotic persistence. One convincing Teams message, one file the platform was already configured to read, and a browser add-on turns into shell access for a ransomware affiliate.

Every organization that treats "browser extensions" and "endpoint software" as two separate inventories with two separate owners has a seam right where this attack lands.

That seam is the actual finding. Extensions stopped being a browser-scoped risk a while ago, and the tooling most teams use hasn't caught up.

How Extenshi helps

You can't manually track what a native host binary does once it's running — that's an EDR problem. What you can do is stop accumulating extensions you've never examined, which is where nearly every one of these incidents starts.

Extenshi scans the extensions you have installed across Chrome, Firefox, and Edge against store metadata and security signals, so you can see which ones ask for host-reaching permissions like nativeMessaging, which have thin or recently changed publishers, and which look nothing like what their listing promises. An inventory you actually understand is the cheapest control in this entire article.

Check your extensions → Scan your browser extensions with Extenshi, or browse the catalog to see how the ones you already run score before the next fake helpdesk message arrives.

Sources

• Malicious Edge extension abuses Native Messaging as bridge to malware — BleepingComputer
• Payouts King ransomware initial access broker deploys new Edgecution malware — Zscaler ThreatLabz
• Native messaging — Chrome for Developers
• Native messaging — Microsoft Edge developer documentation
• Native messaging — MDN Web Docs
• NativeMessagingUserLevelHosts policy — Chrome Enterprise

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].