New details on commercial spyware vendor Variston

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:

/?=

The 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.

Source