Malware News Zscaler ThreatLabz has discovered a new malware family that they named Edgecution, which is linked to Payouts King ransomware attacks.

Khushal

Level 16
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
750
4,691
1,469
Zscaler ThreatLabz has been monitoring ransomware operations that align with tactics previously employed by an initial access broker affiliated with Payouts King ransomware. In recent attacks, the threat actor leverages social engineering tactics paired with an innovative malware delivery mechanism. The technique utilizes a malicious Microsoft Edge browser extension that exploits the Chrome native messaging protocol to interact with host-native applications beyond the confines of the browser sandbox. By abusing this interface, the attackers gain direct host access, enabling them to manipulate the local filesystem, launch processes, and execute arbitrary code on the compromised host. We have dubbed this web browser-based malware Edgecution.
This blog provides an in-depth technical analysis of this attack campaign, including the techniques used to deploy and evade detection by malware sandboxes, network signatures, antivirus, and endpoint detection and response (EDR) software.
 
This write-up is a good reminder that “browser-based” doesn’t always mean “sandboxed.” If an attacker can get a malicious Edge/Chrome extension installed and then abuse Chrome/Edge Native Messaging, they can bridge from the browser into a native process on the host and effectively operate like regular malware.

What’s important about this technique (Native Messaging abuse)

Native Messaging is a legitimate feature intended to let an extension talk to a locally installed “native host” application.

At a high level, it works like this:
  • An extension requests a connection to a named native host.
  • The browser looks up that native host registration on the system (Windows registry / manifest file).
  • If allowed, the browser launches the native host executable and passes JSON messages over stdin/stdout.
  • Whatever the native host can do (read/write files, spawn processes, run commands) becomes reachable through the extension’s logic.

So the key risk is not the browser exploit itself, but that a malicious extension + an associated native host (or a hijacked/abused native host registration) can give an attacker direct code execution capability on the endpoint.

Why this is operationally dangerous
  • It can blend in with normal “extension” activity, especially in environments where extensions are widely allowed.
  • If the attacker gets persistence via extension policies or user profile sync, reinfection/persistence can be easier than traditional droppers.
  • Native Messaging bypasses the “browser sandbox” boundary by design, because it’s explicitly a browser-to-OS bridge.

Practical mitigations (home users)
  • Remove any extensions you don’t absolutely need, and prefer official store installs only.
  • Review extension permissions; be cautious with extensions requesting broad access (e.g., “Read and change all your data on all websites”).
  • If your browser is “managed by your organization” and you don’t expect that, treat it as a red flag and investigate immediately.
  • Run reputable on-demand scans (and consider a second-opinion scanner) if you suspect unauthorized extensions or policy enforcement.

Practical mitigations (organizations/admins)
  • Use Extension Allowlisting (block all by default; allow only approved extension IDs).
  • Block “developer mode” extension loading and block installs from outside the official store where possible.
  • Monitor for unexpected extension force-installs via policy and for unusual changes to browser policy keys.
  • Hunt for abnormal Native Messaging host registrations and unexpected native host executables on disk (new/unsigned binaries in user-writable paths are especially suspicious).
  • Add detections for browser spawning unusual child processes and for native hosts launched by msedge.exe/chrome.exe with suspicious command lines or from strange locations.

Next step for anyone investigating

If you suspect this kind of activity, focus on:
  • Browser extension inventory (installed + force-installed by policy) and recent changes
  • Native Messaging host registrations and the referenced executable paths
  • Process tree telemetry (msedge.exe/chrome.exe -> native host -> cmd/powershell/rundll32/etc.)
  • Persistence via browser policies and scheduled tasks/services created shortly after extension installation

Sources