BlueMoon Exploit Kit Breaks Out of Chrome to Deploy Espionage Malware
Four espionage groups used a shared Chrome-to-Windows exploit chain. Build checks show current exposure; campaign artifacts support a separate compromise hunt.
Four espionage-motivated groups used BlueMoon, a shared exploit kit that chained two Chrome flaws to a Windows kernel vulnerability, to escape the browser and deliver different payloads. Proofpoint first observed the China-aligned TA412 using the kit on August 28. Other clusters adopted it within days.
Volexity detected the same byte-for-byte shellcode on September 1 in campaigns by UTA0560 and JungleBamboo. One campaign targeted multiple nongovernmental organizations with financial lures; the other delivered a credential-stealing Chrome extension. Neither research team published a complete victim count, and the observed Windows build gate narrowed the systems on which the full chain could succeed.
Three flaws cross two sandboxes
BlueMoon starts with CVE-2026-85046, a type-confusion flaw that gives the exploit arbitrary read and write access inside V8. It then uses the WebAssembly defect tracked as CVE-2026-87491 to escape V8’s sandbox. The browser is still running its renderer in Chrome’s operating-system sandbox at that point.
A reflectively loaded DLL profiles the Windows host, including its OS build, token privileges, integrity level, AppContainer state, CPU features and hypervisor. JavaScript reads only three fields from that larger profile to decide whether to continue. Debugger and sandbox findings are reported but do not automatically stop execution.
The next DLL exploits CVE-2026-85880 in the Windows kernel function RtlpCreateServerAcl. That local privilege-escalation stage lifts the renderer out of Chrome’s process sandbox. A final shellcode component injects a CreateProcess stub into the parent Chrome broker process, where the operator’s command runs outside the renderer.
Long description
The linear chain begins with a malicious page exploiting CVE-2026-85046 for arbitrary read and write access inside V8. CVE-2026-87491 then escapes the V8 sandbox. A fingerprinting DLL checks the Windows build and process token. On a supported target, CVE-2026-85880 raises the renderer’s privileges and crosses the Chrome process sandbox. Injector shellcode reaches the parent Chrome broker, which executes an operator-selected payload. A side note marks the Windows build gate: Windows 10 1809 through 22H2, Windows Server 2022 and Windows 11 21H2 were accepted by the observed kit, while builds above 22000 were rejected.
Proofpoint found a blunt default command: BlueMoon launches curl to download an actor-supplied executable, writes it to disk and executes it. That sequence creates useful process and network telemetry. Actors also changed the final injector to deliver their own loaders, so the default command is a recognition opportunity rather than a universal signature.
Patch gaps narrowed the target
The two Chromium flaws were patch-gap zero-days during the campaigns. Fixes were visible in the public Chromium source tree before downstream stable Chrome releases carried them. Proofpoint assesses that the kit developer probably weaponized those public changes. Volexity reaches a similar assessment with medium confidence.
The evidence does not establish who developed BlueMoon or how several groups obtained it. Proofpoint writes that “BlueMoon may not be exclusive to China-aligned actors.” The company also found comments, diagnostic logging and a referenced handover document that were consistent with AI-assisted development, while stating that no single artifact proved AI involvement.
BlueMoon’s Windows gate limited its reach. Volexity found that the kernel stage accepted Windows 10 1809 through 22H2, Windows Server 2022 and Windows 11 21H2, and rejected builds above 22000. Pairing browser flaws present in current releases with a kernel flaw limited to older Windows builds reduced the chain’s success rate.
The current exposure test covers the whole chain. Chrome must include the fixes for both V8 flaws: 153.0.8010.36 or later on Linux, and 153.0.8010.36, 153.0.8010.37 or later on Windows and macOS. The Windows hosts seen in the kernel stage also need the September fixed floor for their release: 10.0.17763.9245 for Windows 10 1809 and Windows Server 2019, 10.0.19044.7725 for Windows 10 21H2, 10.0.19045.7725 for Windows 10 22H2 and 10.0.20348.5622 for Windows Server 2022. Windows 11 21H2 is outside ordinary support and should move to a supported release.
Those version results describe whether the published chain can run now. They cannot determine whether an older browser and OS combination already launched a payload.
Two payloads reveal actor goals
UTA0560 sent financial-themed spear-phishing messages to NGOs. Links first reached a legitimate US university website with a reflected cross-site scripting flaw, then redirected the browser to attacker-controlled BlueMoon infrastructure. The visible page showed a donation-form image tailored to the targeted organization while exploitation and malware delivery ran behind it.
The final payload was GRIMWEDGE, a JScript backdoor with host reconnaissance, file and process management, command execution and additional payload-delivery functions. Volexity tied the delivery domain and server to infrastructure used in unsuccessful UTA0560 phishing during March 2026.
JungleBamboo used identical exploit components on separate infrastructure but installed SUPERSTOMP and the LONGTALE Chrome extension. LONGTALE targets credentials associated with Google Gemini rather than providing general command execution. The shared exploitation chain and divergent payloads support reuse by distinct operators, not one uniform campaign.
Proofpoint observed four espionage-motivated clusters in total and cautioned that additional users may exist. The infrastructure for the observed deliveries was generally created on the campaign day or only days earlier. Rapid setup, broad diagnostic logging and the obvious curl process chain suggest speed mattered more than mature operational security.
Indicators connect delivery and payloads
Start with the infrastructure Volexity associated with the two observed clusters. Search DNS, proxy, browser and endpoint records for cloud[.]shinewrist[.]net, ocr[.]opusaccel[.]top, msbenefit[.]com, gitprogram[.]com and 206[.]166[.]251[.]164. The first two values belong to UTA0560 delivery and GRIMWEDGE command activity. The latter domains belong to JungleBamboo phishing, exploit hosting and payload delivery.
The published file evidence provides a second layer:
| Artifact | SHA-256 |
|---|---|
Files1.html landing page | d17053557bb90298f7b115432b4820a248fdbe678bca31721529b1f51a82343b |
react.min.js loader | 337b48c1cd6dd6e7b8073327082a60e149517fa084ba17b180e041fffa3b130d |
shared p1 data | cd0c21f9b32b7feeda1787fccab622dec60ecdf84c0538c08bde3946856b0fa0 |
shared p1 DLL | b7b0cd6539464ab39c6526e499f86d611faa21c5af945535ebaf187cec543af1 |
shared p2 data | 5995f42a828606705a7339d58a665c229936e81c4e539cdfa115eb46a2eb53d6 |
shared p2 DLL | 51462a23ac25e1bd0e49b7cae7f3a71f8d2201e22d45175b587e4740b49863cc |
| GRIMWEDGE JScript | 59dc108e22cb856c228bbf8a1ab955fb66f0844a07fe10fa0d9fc3823d2cbbcb |
| LONGTALE extension | 5eb5645511b00e4f4d73125654eeb3a3930fcf09c65685dc7f03f725331492e3 |
Correlate those values with a browser process, the landing-page sequence, reflective DLL loading, a Windows build accepted by the kernel stage and an unexpected Chrome broker child process. A domain or hash match deserves investigation, but one isolated value cannot establish that the complete chain ran. The reports describe evolving infrastructure and multiple actor-specific payloads.
Verify code and host evidence
Collect the running Chrome and Windows build from each managed workstation. Require Chrome to meet the version floor that includes both V8 fixes, and compare the OS with its supported September update floor. Relaunch the browser before collecting its version so a staged package does not masquerade as active protection.
For systems that were previously below either floor, retain DNS, proxy, process, file and extension telemetry across the vulnerable window. Search for the defanged infrastructure and hashes above, plus curl launched through an unexpected Chrome broker lineage. Scope any match with the user, lure, browser history, process tree and payload behavior before assigning it to BlueMoon.
The expected current-state result is a fixed running browser on a supported, patched Windows release. The expected incident result is either no correlated BlueMoon evidence in the retained window or a contained host with the delivered payload and credentials fully scoped.
A clean version inventory answers whether the published chain can run now. Only retained endpoint and network evidence can answer whether it ran before the patches. Treat those as two separate conclusions, because combining them lets a successful rollout erase the incident question.