Clearfake

There are several malicious fake updates campaigns being run across thousands of compromised websites. Here I will walk through one with a pattern that doesn’t match with others I’ve been tracking. This campaign appears to have started around July 19th, 2023. Based on a on PublicWWW of the injection base64 there are at least 434 infected sites.

I’m calling this one ClearFake until I see a previously used name for it. The name is a reference to the majority of the Javascript being used without obfuscation. I say majority because base64 is used three times. That’s it. All the variable names are in the clear, no obfuscation on them.

One noticeable difference from SocGholish is that there appears to be no tracking of visits by IP or cookies. As an analyst you can you go back to the compromised site over and over coming from the same IP and not clearing your browser cache. This also means the site owner is more likely to see the infection as well.

When a user visits a compromised website with ClearFake, the page initially loads as normal before the whole page is taken over by a call to action to update Chrome. Here’s what it looks like along with Fiddler showing some of the malicious web calls in yellow.

On the index page of the compromised site there is a Javascript injection. The Javascript is base64 encoded. Presumably this is a dynamic injection and will change over time to reflect the new host for the initial payload.

For EKFiddle users you might consider adding a CustomRegex to watch for these injections.

I like to use CyberChef to decode such things. Here’s the injection decoded and tidied up a bit.

This is a straightforward initial call for the first payload which is hosted on Cloudflare Workers. The Cloudflare domain being used is a wildcard. I’ve seen two variations of the first portion of the FQDN.

A urlscan for the base domain shows how long it has been in use and some of the variations of the first part of the name.

The Cloudflare worker returns a very similar Javascript that simply makes another call to a Keitaro host, but not to a Keitaro endpoint.

The second web call returns a Javascript that creates an iframe to house the fake update UI. The iframe src is set to a Keitaro endpoint.

Payload three - Keitaro

The response from the Keitaro endpoint is the foundation for the HTML to be rendered within the iframe.

The blank var base64 decoded is _index.php . Since the base href is set, when fetch() is called the path to be used will be /lander/chrome/_index.php .

_index.php finally contains all the HTML/CSS to build the fake update webpage.

It also contains two malicious components.

FingerprintJS is included within _index.php. to the bottom it is used to fingerprint the browser and send the results to the threat actor at stats-best.site . This will happen as the page renders.

The last malicious chunk of Javascript within _index.php is used to make the Update Chrome button clickable.

Upon clicking the button, the URL is built with various parameters. Again there is a touch of base64 for the path. Here it is P19scD0x which decodes to ?_lp=1 .

An example fully built URL would look like this.

Of note is the FPID parameter. It is the FingerprintJS visitorId which was sent earlier to stats-best.site . This appears to be a unique identifier that presumably should make it difficult for analysts to arbitrarily replay or poke at the final endpoint.

This download endpoint will be a 302 redirect to where the malicious executable is that the user will see downloaded.

When this campaign was first observed yesterday the redirect was to login.live.com and required a login to Outlook. Sadly the payload was not there. Today it is for a OneDrive file with a URL that looked like this.

Of note here is the obscured filename which url encoded is this.

Chr%D0%BEm%D0%B5S%D0%B5tu%D1%80.exe

Visually the end user will see ChrоmеSеtuр.exe but technically the characters are non-standard and hamper detections based simply on the string ChromeSetup.exe .

Once downloaded if the user runs the EXE they’ll become infected with Amadey as this report shows.

I like to use SSL certs as one method to determine when malicious domains come online. With the domains I’ve seen so far, the earliest date is July 19th.