Threat Research Center Threat Research Malware Malware Operation FlutterBridge: macOS Malvertising Campaign Spreads New FlutterShell Backdoor 17 min read Related Products Advanced WildFire Cloud-Delivered Security Services Cortex Cortex XDR Cortex XSIAM Unit 42 Incident Response By: Ido Asher Noa Dekel Tom Fakterman Published: June 2, 2026 Categories: Malware Threat Research Tags: CL-CRI-1089 MacOS Malvertising Share Executive Summary We are tracking an increasingly widespread malvertising campaign targeting macOS. This campaign appears to be the next stage of a previous campaign known as JSCoreRunner, which was first identified in August 2025. In recent months, the financially-motivated attackers behind these campaigns transitioned from delivering standard adware, to delivering adware with full backdoor capabilities. We designate this campaign Operation FlutterBridge, and we call the payload that it delivers FlutterShell. Built using the Flutter framework, FlutterShell infects targets with adware via malicious desktop applications. In addition to its adware functionality, the payload possesses backdoor capabilities, including shell command execution and file system manipulation. Some variants weaponize artificial intelligence (AI) summarization features for data exfiltration by routing documents through an attacker-controlled server before processing them. The FlutterShell malware strain appears to be under active development, with new improvements being rapidly integrated into the code. Operation FlutterBridge targets a global audience through an extensive Google Ads campaign, with an emphasis on Anglophone and Western European markets, distributed via hundreds of Google-verified advertisements. Our research indicates that the attackers behind this cluster distributed the ads using a series of shell companies, to bypass ad-network vetting and orchestrate these attacks at scale. We reported these advertisers to Google, which provided the following statement: Malware has no place on our platforms, and we’ve suspended these advertiser accounts for violating our policies. We track Operation FlutterBridge and the JSCoreRunner campaign under a cluster of activity that we refer to as CL-CRI-1089 . This article provides a technical overview of the FlutterShell macOS malware and the delivery network behind the malvertising campaigns. Palo Alto Networks customers are better protected from the threats described in this article through the following products and services: Advanced WildFire Advanced URL Filtering and Advanced DNS Security Cortex Agentix Threat Intel Agent Cortex XDR and XSIAM If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team . Related Unit 42 Topics macOS , Malvertising Campaign Background CL-CRI-1089 is a cybercrime cluster of activity that has been operational since at least 2023. The attackers behind this cluster are responsible for spreading malicious payloads via malvertising campaigns, targeting both Windows and macOS users through separate, ongoing operations. The attackers’ modus operandi is consistent across these operations: They distributed malicious advertisements using a network of Google-verified shell companies. These ads were designed to trick targets into deploying malware that masquerades as legitimate desktop applications. While in-the-wild observations suggest the malware functions primarily as adware, it possesses capabilities for far more dangerous behavior, effectively functioning as a backdoor. Operations attributed to this cluster include the RecipeLister and Calendaromatic Windows campaigns, as well as the JSCoreRunner macOS campaign. The Windows activity was previously tracked by other vendors under the broader “TamperedChef” designation, before Unit 42 researchers deconstructed the activity into distinct clusters. In late 2025, the attackers expanded their operations with Operation FlutterBridge, deploying a new macOS backdoor identified as FlutterShell. Overview of the FlutterShell Malware FlutterShell is a macOS backdoor developed using the Flutter framework and designed to masquerade as legitimate software. FlutterShell’s authors implemented a WebView-based architecture that utilizes a JavaScript-to-native bridge. This design allows the attackers to host malicious logic on an external website, rather than hardcoding it into the binary. This enables the attackers to dynamically alter FlutterShell's behavior in real time, without needing to recompile or redistribute the application. FlutterShell has a set of built-in commands that provide attackers with the following capabilities: Arbitrary command execution File system interaction Environment variables exfiltration During our investigation, we observed FlutterShell being used as adware. Upon execution, the malware modifies Google Chrome configuration files to hijack the browser, forcing all traffic through an attacker-controlled, ad-filled intermediary site. We identified several versions of FlutterShell that did not yet contain malicious code. Additionally, an examination of the JavaScript logic hosted on the attackers’ infrastructure revealed multiple unfinished functions. These findings, combined with the frequent appearance of new variants, indicate that the malware is likely under active development. The use of the Flutter framework presents specific analytical hurdles. The Flutter engine compiles Dart code into a dynamic library and uses an Object Pool to store data. This separates the code from the strings and variables it uses, making it difficult for security analysts to see how the malware actually functions. This feature also makes tracing the execution flow of a Flutter application via static analysis particularly challenging. To overcome these challenges, we used a custom version of Worawit Wangwarunyoo's blutter tool to disassemble the Dart binary and reconstruct the application logic. FlutterShell Deployment and Masquerading We encountered three versions of FlutterShell in which the malware posed as a podcast player and two different PDF viewers. These desktop applications were fully functional, effectively concealing the malicious logic executing in the background. Figure 1 shows two of the applications on macOS hosts. Figure 1. FlutterShell masquerading as a legitimate podcast player and PDF viewer application. All observed samples were signed with valid Apple Developer IDs and successfully passed notarization, meaning Apple's automated security checks did not flag them as malicious at the time of submission. Figure 2 shows the legitimate signature of FlutterShell’s binaries and its successful notarization by Apple. Figure 2. FlutterShell is signed with valid Apple Developer IDs and successfully passed notarization. At the time of analysis, all three applications containing FlutterShell had zero detections on VirusTotal, as shown in Figure 3 for the PodcastsLounge application. Figure 3. Malware analysis conducted on VirusTotal. FlutterShell Technical Analysis FlutterShell’s Malicious WebView Architecture The FlutterShell backdoor logic is not hardcoded into the binary. Instead, FlutterShell employs a WebView-based architecture utilizing a JavaScript-to-native bridge. In WebView-based architecture, a native application uses an embedded web browser component to display content. The JavaScript-to-native bridge acts as a communication channel between this web content and the host native application, allowing them to exchange data and cross-invoke functionality. Consequently, the malicious logic of FlutterShell is stored on the attackers’ website and is only triggered when the application loads the specific web content. Figure 4 demonstrates how the application converts web content to native commands. Figure 4. WebView architecture to native OS code execution graph. Upon initial execution, FlutterShell waits for a specific duration received dynamically from the command and control (C2) server before contacting the attackers’ website — which contains the malicious JavaScript code — to avoid analysis and build user trust. More details about the backdoor’s delay routine are provided in Appendix A . JavaScript Bridge Injection Technique The primary payload of FlutterShell is embedded within the main webpage and a /update-thanks.html subdirectory of the attacker-controlled site. Figure 5 shows the website's landing page. Figure 5. “Thank You for Updating!” landing page that hides the malicious logic of FlutterShell. To facilitate communication between the remote attacker-controlled webpage and the infected local system, the malware injects a JavaScript bridge. This bridge uses a message channel named flutterInvoke to pass JSON-formatted commands from the WebView context into the native Dart environment. The remote webpage acts as the execution environment for the JavaScript-to-native bridge. By loading the external content, the attackers can send JSON-formatted commands to the application, which are then translated into native system calls and operations on the infected machine. The main webpage and the /update-thanks.html subdirectory retrieve the core malicious logic from external endpoints: /getConfig and /getUpdateThanksConfig , respectively. These scripts contain the JavaScript code that defines which commands should be executed and configures the supported functionality. This architecture allows the attackers to modify the code in /getConfig and /getUpdateThanksConfig at any moment, dynamically altering FlutterShell's behavior without requiring a software update. Figure 6 shows the HTML page presented to the targeted end-user, followed by the subsequent JavaScript code executed by the payload. Figure 6. JavaScript code in /update-thanks.html responsible for retrieving the malicious logic. At the time of investigation, the call to /getConfig was either commented out on the main page or the endpoint was unreachable. We also noticed that /getUpdateTha