New details on commercial spyware vendor Variston

Threat Analysis Group (TAG) has been tracking the activities of commercial spyware vendors for years, using our research to improve the safety and security of Google’s products and share intelligence with our industry peers. TAG’s research underscores that the commercial surveillance industry is thriving and has expanded significantly in recent years, creating risk for Internet users around the globe. Commercial spyware puts advanced surveillance capabilities in the hands of governments who use them to spy on journalists, human rights activists, political opposition and dissidents. Google and TAG are committed to disrupting these threats, protecting users, and raising awareness of the risks posed by the growing commercial spyware industry.

Continuing this work, today, we’re sharing findings on an exploitation framework with likely ties to Variston IT, a company in Barcelona, Spain that claims to be a provider of custom security solutions. Their Heliconia framework exploits n-day vulnerabilities in Chrome, Firefox and Microsoft Defender and provides all the tools necessary to deploy a payload to a target device. Google, Microsoft and Mozilla fixed the affected vulnerabilities in 2021 and early 2022. While we have not detected active exploitation, based on the research below, it appears likely these were utilized as zero-days in the wild. TAG has created detections in Safe Browsing to warn users when they attempt to navigate to dangerous sites or download dangerous files. To ensure full protection against Heliconia and other exploits, it’s essential to keep Chrome and other software fully up-to-date.

TAG became aware of the Heliconia framework when Google received an anonymous submission to the Chrome bug reporting program. The submitter filed three bugs, each with instructions and an archive that contained source code. They used unique names in the bug reports including, “Heliconia Noise,” “Heliconia Soft” and “Files.” TAG analyzed the submissions and found they contained frameworks for deploying exploits in the wild and a script in the source code included clues pointing to the possible developer of the exploitation frameworks, Variston IT.

The exploitation frameworks, listed below, included mature source code capable of deploying exploits for Chrome, Windows Defender and Firefox. Although the vulnerabilities are now patched, we assess it is likely the exploits were used as 0-days before they were fixed.

• Heliconia Noise: a web framework for deploying an exploit for a Chrome renderer bug followed by a sandbox escape
• Heliconia Soft: a web framework that deploys a PDF containing a Windows Defender exploit
• Files: a set of Firefox exploits for Linux and Windows.

Below, we share our findings on the exploitation frameworks and how they work. This analysis was done in collaboration with our colleagues, Ivan Fratric and Maddie Stone from Project Zero, and Stephen Röttger from the V8 Security Team.

Heliconia Noise

Heliconia Noise is a web framework for deploying a Chrome renderer exploit, followed by a Chrome sandbox escape and agent installation. A manifest file in the source code provides a product description:

The Chrome renderer exploit supports Chrome versions 90.0.4430.72 (April 2021) to 91.0.4472.106 (June 2021). It takes advantage of a V8 deoptimizer bug fixed in August 2021. As is currently normal for internally found Chrome bugs, no CVE was assigned.

The source code contains references to a sandbox escape called chrome-sbx-gen. This component was maintained in a separate Git submodule, and was not present in the obtained source code.

To obfuscate the JavaScript code, the framework uses minobf, likely a custom tool that was also not included in the source code.

Heliconia Noise includes a pre-commit cleaning script that leaks the name of the company that likely develops this project, Variston IT. The script, shown below, checks that binaries produced by the framework do not contain sensitive strings such as “Variston,” developer aliases or server names. Variston Information Technology is a small company based in Barcelona that describes itself as offering “tailor made Information Security Solutions.”

Heliconia Noise is configurable using a JSON file that enables customers to set various parameters, including:

• attackExecution: maximum number of times to serve the exploit
• expiration: server does not work after this date
• redirectUrl: redirect URL in case of a failed exploit or disallowed visitor
• targetValidator: custom rules specifying when visitors are considered valid targets
• dnsMirrors: mirrors where the iframe is fetched from

The framework runs a Flask web server to host the exploit chain. A full infection performs requests to six different web endpoints during the different stages of the exploit chain:

Stage 1: Remote code execution (RCE)

• index.py: the landing page
• iframe.py: the iframe that runs the RCE exploit
• wasm.py: a dummy WebAssembly (Wasm) module

Stage 2: Sandbox escape

• sbx.py: the sandbox escape shellcode

Stage 3: Post-exploitation

• launcher.py: the agent launcher
• agent.py: the agent

The file names for each endpoint are randomized during server deployment, except for the first endpoint, which is served by a URL specified in the configuration file.

The framework allows setting parameters to validate visitors of the web server. Customers can configure target validations based on user agent, client country, client IP, and a client identifier used to track individual visitors. If any of the validation checks fail, the user is redirected to the preconfigured redirect URL.

Heliconia Noise Infection Chain

Stage 1: Remote code execution

The infection chain starts with a client visiting the landing page URL defined in the configuration file. If the validation checks succeed, the landing page is served and 2 cookies are set:

• A cookie with name wp_blog and value 1 to detect and redirect recurring visitors.
• A “client identifier” cookie with:
  • A name that is randomly generated during server deployment and is constant for the entire deployment (referred to as cookie_client_identifier and formatted [A-Za-z]{16})
  • A value that is uniquely generated per visitor (referred to as cid and in UUID format).

The JavaScript in the landing page then creates an iframe for every mirror configured in the configuration file. The iframe URLs have the following format:

<url>/<iframe_url>?<cookie_client_identifier>=<cid>

The <iframe_url> string is a random path formatted [a-f0-9]{16}.

The main script communicates with the iframes through messages using the postMessage method.

The iframes in their turn launch web workers that run exploit code. Communication with the workers happens again through messages.

Once the exploit obtains an arbitrary read and write primitive, a dummy Wasm module is fetched as a method for creating a memory area with read-write-execute permissions. The URL format is similar to the iframe URL above.

The Wasm area is then overwritten with the stage 1 shellcode. This shellcode is executed via a call from JavaScript to the exported Wasm function hello().

The first time the stage 1 shellcode is called it resolves the address of chrome.dll, VirtualAlloc, NdrServerCall2 and the ntdll timestamp. It also allocates memory for the upcoming sandbox escape shellcode. The resulting information is returned to the JavaScript.

Stage 2: Sandbox escape

The JavaScript then fetches the sandbox escape shellcode from a URL with a format similar to the iframe and Wasm URL, but with 5 extra GET parameters which are used by the server to prepare the sandbox escape shellcode:

• address of VirtualAlloc function
• address of NdrServerCall2 function
• address of chrome.dll
• address of the allocated memory for the sandbox escape
• timestamp of ntdll

The fetched sandbox escape is written to the previously allocated memory. It is executed via a second call to the stage 1 shellcode, which now calls into the sandbox escape shellcode.

Since TAG did not have access to the chrome-sbx-gen module, we do not have specific details on how the sandbox escape works.

Stage 3: Post-exploitation

After a successful sandbox escape, the launcher is executed. The goal of the launcher is to launch the (final) agent. The launcher is served as a DLL that is prepended with a PE loader shellcode.

The launcher has its own configuration, which contains following fields of interest:

• URL to retrieve the agent
• Path on the system to store data
• If the agent should be dropped to disk
• Filename of the agent on disk

The configuration is stored as an RC4 encrypted tar archive in the binary. The launcher fetches and runs the agent, and based on the exit code of the agent, it can uninstall the agent, upgrade it, run it again or exit.

The agent_simple provided in this archive is a dummy agent and it randomly selects the exit code. In a real deployment, we believe the customer using the framework may provide their own agent, or the agent may be part of a different project.

Heliconia Soft

Heliconia Soft is a web framework that deploys a PDF containing a Windows Defender exploit. It exploits CVE-2021-42298, a bug in the JavaScript engine of Microsoft Defender Malware Protection that was fixed in November 2021. The manifest in the source code describes Heliconia Soft as:

The exploit achieves SYSTEM privileges with a single vulnerability and the only action required by the user is to download a PDF, which triggers a scan by Windows Defender.

The Heliconia Soft framework sets up an infection chain with two endpoints on the web server:

• index.py: the weaponized PDF file
• agent.py: the agent

In the first stage, a PDF is served when a user visits the attack URL. The PDF contains some decoy content, plus JavaScript that contains the exploit. Like Heliconia Noise, it uses the custom JavaScript obfuscator minobf. The framework code performs checks to confirm that common exploit strings (“spray”, “leak”, “addr”, etc.) are not present in the obfuscated JavaScript. The framework inserts the PE loader shellcode and the launcher DLL as strings in the exploit JavaScript.

The PE loader is similar to the one described above for Heliconia Noise. The launcher also has the same functionality, with a few notable differences. The launcher tries to “defuse” the exploit PDF by replacing the JavaScript in the PDF with spaces, likely to protect the exploit code from forensics. Similar to Heliconia Noise, the launcher retrieves the agent from a configured URL, runs it and acts based on its exit code.

A dummy agent agent_simple is provided in the archive. As with Heliconia Noise, we believe the framework is likely designed for the customer to replace the dummy agent with their own agent.

Heliconia Files

The “Files” package contained a fully documented Firefox exploit chain for Windows and Linux. For remote code execution it exploits CVE-2022-26485, a use after free vulnerability in the XSLT processor that was reported in March 2022 as being exploited in the wild. TAG assesses that the Heliconia Files package likely exploited this RCE vulnerability since at least 2019, well before the bug was publicly known and patched. The Heliconia exploit is effective against Firefox versions 64 to 68, suggesting it may have been in use as early as December 2018 when version 64 was first released. Additionally, when Mozilla patched the vulnerability, the exploit code in their bug report shared striking similarities with the Heliconia exploit, including the same variable names and markers. These overlaps suggest the exploit author is the same for both the Heliconia exploit and the sample exploit code Mozilla shared when they patched the bug.

The sandbox escape is specific to the Windows version of Firefox and was fixed without a CVE in September 2019. The vulnerability abused the fact that user-controlled CSS values can be rendered inside the privileged content process using the Forms:ShowDropDown IPC. Code execution is achieved by injecting XBL bindings to resolve Windows APIs and call WinExec. The exploit code spawns a new calculator, and unlike the other Heliconia frameworks, does not include a launcher capability or dummy agent.

Conclusion

TAG's research has shown the proliferation of commercial surveillance and the extent to which commercial spyware vendors have developed capabilities that were previously only available to governments with deep pockets and technical expertise. The growth of the spyware industry puts users at risk and makes the Internet less safe, and while surveillance technology may be legal under national or international laws, they are often used in harmful ways to conduct digital espionage against a range of groups. These abuses represent a serious risk to online safety which is why Google and TAG will continue to take action against, and publish research about, the commercial spyware industry.