Volexity Volcano Recovers Browser Exploit Traces After Cleanup
A replayed Chrome-to-Windows intrusion left encoded script in free memory. Capture RAM early, then use host artifacts to guide wider collection.
After an attacker tried to erase traces from a Windows virtual machine, encoded malware script still surfaced in free memory. In an October 16 demonstration, Volexity recovered that trace with Volcano. For teams investigating a suspected browser intrusion, the useful window is before a restart or further cleanup removes volatile evidence.
The chain came from Volexity’s September investigation of phishing against non-governmental organizations. UTA0560 led people through a university site’s reflected cross-site scripting flaw to a Chrome exploit and a Windows kernel exploit, then deployed the GRIMWEDGE backdoor. JungleBamboo used the same exploit chain with a different final payload. Earlier Nulltap coverage addresses the browser and OS update question; this new demonstration addresses what an investigator can recover from a machine after the attack.
A replay after attacker cleanup
Volexity compromised a VM with the same chain and payloads it attributed to UTA0560. The attackers noticed monitoring and tried to cover their tracks. Volexity then acquired RAM, system and user registry hives, event logs, the USN journal ($UsnJournal), and the master file table ($MFT) with Surge Collect Pro and analyzed the collection in Volcano.
An intact disk image captures files and metadata; the RAM capture can retain the payload and pages freed after execution. Volexity says its built-in indicators flagged reflectively loaded DLLs and position-independent shellcode in chrome.exe, as well as persistence and unusual process relationships. Its subscription threat-intelligence feed matched the attacker-controlled hostname cloud.shinewrist[.]net in event logs and in command lines for shells and curl processes. The feed is an additional source of indicators; Volcano’s built-in checks produced the memory-only hits in this demonstration.
Free memory holds the script
Volexity extended its indicator set and scanned the acquired evidence again. This time it recovered GRIMWEDGE-encoded JavaScript from free, deallocated memory. The report calls it “highly volatile proof” and says conventional endpoint detection and antivirus tools cannot ordinarily read that slack space. A reboot or delayed capture may cost an investigator this particular lead even when file and event-log evidence survives.
The original campaign report describes the route into the host: the V8 type confusion CVE-2026-85046, the WebAssembly sandbox escape CVE-2026-87491, and the Windows kernel flaw CVE-2026-85880 moved execution out of the browser renderer. UTA0560’s GRIMWEDGE ran JScript in memory in msiexec.exe; JungleBamboo instead installed the LONGTALE credential-stealing Chrome extension. Those distinct payloads call for different follow-up checks even though the groups shared exploit components. Volexity previously found a donation-form decoy on the browser page while the exploit ran out of sight.
The September report gives a second host-side clue for UTA0560 specifically. Its sideloaded wsc.dll dropper created a task named Windows Scheduled System that re-ran the chain every five minutes. GRIMWEDGE then executed as JScript in msiexec.exe memory. Check the task action and process lineage alongside the captured RAM: a file search alone misses the later script even if it finds a loader on disk.
Seeded history triggers collection
Volexity also demonstrated a narrower way to choose which endpoint merits RAM collection. Its team placed a URL under cloud.shinewrist[.]net in Microsoft Edge history on one Windows Server in a Volcano Endpoint group. Through Volcano’s MCP server, an analyst used an AI client to schedule a small registry-and-browser-history collection; an indicator hit then triggered a second collection with browser files, other forensic files, and memory. Volcano’s interface showed both scheduled collections. The URL was deliberately seeded, so this example measures collection orchestration rather than a second live intrusion.
Other MCP examples triaged hits, labeled representative artifacts, and created more indicators from the first sample. Volexity is evaluating its own Volcano product here, and it thanks OpenAI for a partnership through the Trusted Access for Cyber program. Treat the AI-assisted output as investigative leads to inspect in the underlying artifacts, particularly before automating a wider collection or attaching a label that others will trust.
Capture RAM before restarting hosts
For a Windows endpoint tied to this chain, preserve volatile memory and the browser, registry, event-log, $UsnJournal, and $MFT artifacts while the machine is available. Search available history and logs for cloud.shinewrist[.]net, and correlate a hit with shell or curl command lines, chrome.exe memory findings, and persistence evidence. Keep that hostname defanged in case notes and rule documentation. The original report’s campaign indicators and earlier build-check coverage can guide the separate patch and compromise investigation. For UTA0560 signs, inspect the Windows Scheduled System task and its action; preserve the underlying evidence before changing the host. Scope accounts and browser credentials where JungleBamboo’s LONGTALE extension appears, rather than assuming a GRIMWEDGE-only hunt covers both groups.
If your collection system supports staged acquisition, start with the smaller browser-and-registry sample and have an indicator hit schedule a deeper file-and-memory capture. Verify the handoff by checking that the first collection produced the expected browser or registry evidence, the indicator fired on the expected host, and the second collection contains RAM and the requested files. A quiet disk scan cannot replace that memory examination: Volexity found the encoded script in pages the running system had already freed.