Edgecution: Malicious Edge Extension Escapes the Sandbox

A fake IT support call on Microsoft Teams. A convincing Microsoft branded page titled 'Outlook Updates Management Console'. A button helpfully labelled as a spam filter update. That is the entire front door to Edgecution, a malicious Microsoft Edge extension that researchers at Zscaler have tied to an initial access broker working with the Payouts Kings ransomware group.

The engineering behind it is genuinely clever. The social engineering in front of it is depressingly simple.

Talking its way out of the sandbox

Browser extensions are meant to live inside the browser, contained by the sandbox so they cannot poke at the rest of the machine. Edgecution gets around that by abusing Chrome's Native Messaging protocol, the same plumbing a legitimate password manager uses to talk to its desktop companion app. The extension runs inside a headless Edge process the user never sees, and uses native messaging to hand instructions to a Python backdoor sitting on the host. That backdoor takes its orders from the attacker's command server.

It is not a new exploit. It is an entirely supported feature, used the way it was designed to work, by someone who should not have been allowed to install the extension in the first place.

A delivery chain that hides in plain sight

The dropper is just as careful. The payload arrives as a ZIP archive with deliberately mangled headers, so security tools scanning the file do not recognise it as a valid archive and skip past it. Once on disk, an AutoHotKey, batch, or PowerShell script does the cleanup, repairing the headers and unpacking the contents.

What comes out is a self-contained kit:

• An embedded Python 3.13.3 runtime, so the attacker does not have to rely on whatever is or is not installed locally.
• The malicious Edge extension itself.
• The native messaging host that bridges the two.
• A scheduled task to launch Edge headless on a regular cadence.

By the time anything is running, the attacker has a persistent foothold, a working command channel, and a process tree that looks like a user quietly opening their browser.

The part that actually decides the outcome

For all the engineering, every component downstream of the Teams message is wasted effort if the employee on the other end of the call hangs up, or pauses, or thinks to check with the real IT team. The sandbox escape only matters because someone followed a link from a stranger claiming to be internal support and clicked the button they were told to click.

That is the pattern worth sitting with. Initial access brokers are not breaking in through some unpatched exotic vulnerability. They are getting invited in over Teams, on a call that looks like the sort of mildly annoying request people deal with every week.

What's worth doing this week

Zscaler's writeup includes indicators of compromise and is well worth pulling into your detection stack. Two practical things to check while you are there:

• Extension install policy. Do you actually restrict which extensions users can add to Edge and Chrome, or is it whatever they fancy?
• Native messaging host configurations. These are registered on the endpoint and rarely audited. A rogue entry there is a quiet way for a browser extension to reach into the rest of the machine.

And, less technically, whether anyone on the service desk would feel comfortable telling a confident-sounding caller on Teams to slow down and verify who they are. That conversation is the one that decides whether any of the rest of this matters.