WOOF locker: Unmasking the browser locker behind a stealthy tech support scam operation

In the early days, practically all tech support scammers would get their own leads by doing some amateur SEO poisoning and keyword stuffing on YouTube and other social media sites. They’d then leverage their boiler room to answer incoming calls from victims.

Today, these practices continue, but we are seeing more advanced operations with a clear separation between lead generation and actual call fulfillment. Malvertising campaigns and redirections from compromised sites to browser locker pages are owned and operated by experienced purveyors of web traffic.

There is one particular browser locker (browlock) campaign that had been eluding us for some time. It stands apart from the others, striking repeatedly on high-profile sites, such as the Microsoft Edge Start page, and yet, eluding capture. In addition, and a first to our knowledge, the browser locker pages were built to be ephemeral with unique, time-sensitive session tokens.

In November 2019, we started dedicating more time to investigating this campaign, but it wasn’t until December that we were finally able to understand its propagation mechanism. In this blog, we share our findings by documenting how threat actors used targeted traffic-filtering coupled with steganography to create the most elaborate browser locker traffic scheme to date.

A well-documented history

There are many public reports about this tech support scam affecting users with the same red screen template. Contrary to what some people have posted online, this is not malware, and computers aren’t infected. It is simply what we call a browser locker, or browlock for short, a social engineering technique that gives the illusion of a computer virus and scares people into calling a toll-free number for assistance. Here are some examples:

• When Searching Ebay only I get Google Chrome Critical Error (eBay forums)
• Microsoft Edge Critical Process Died Stop Code – Red Screen (Microsoft forums)
• First full day using new Surface and get this “critical process died error report”. Why? (Reddit)
• Google Chrome Critical Error after update (Malwarebytes forums)

One lengthy and epic forum thread on Microsoft’s forums describes how this browlock campaign has been afflicting the Microsoft Edge start page and even left Microsoft engineers puzzled as to where, exactly, it came from:

We do quite a bit of work to scan the ads we get from our exchanges, but some behave differently for certain users than they do when we do our scanning. In the future, please continue to submit feedback so we can narrow the scans on our end and potentially reproduce and remove this once and for all.

This is noteworthy for a couple of reasons: First, it is quite daring to push your browlock right on Microsoft’s own start page. Second, a large part of the targeted audience for tech support scams are going to be people that use Windows’ default browser and start page. To this day, this campaign is still active on the MSN portal.

This browlock was also found on many other large sites, including several online newspaper portals. For a campaign to run with such a wide distribution and for this length of time is unheard of, at least when it comes to browser lockers.

Cat-and-mouse game

Each victim report we received was more or less the same. A user would open up the MSN homepage or perhaps be browsing a popular tech portal, when all of the sudden their screen would turn red and display a warning message similar to the one shown below:

As we’d go to manually check the page, we would be greeted with a “404 Not Found” error message, as if it were gone. For this reason, we began calling this campaign the “404Browlock.” Attempts to replay the browser locker redirection by visiting the same portals as the victims were also unsuccessful.

Most, if not all, browlock URLs can be revisited without any special user-agent or geo-location tricks. In fact, browlocks themselves aren’t typically sophisticated; their only advantage is they can iterate through hundreds or thousands of different domain names more rapidly than one can blacklist them.

Mapping the browser locker campaign infrastructure

Despite coming up empty each time, we started to build a list of indicators of compromise (IOCs) and did some retro hunting to get a better idea of the scale of this campaign.

Most domain names are registered on the .XYZ TLD (although several other TLDs have and continue to be used) and named using dictionary words grabbed somewhat alphabetically.

2019-12-06,transfiltration[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,transmutational[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,tricotyledonous[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,triethanolamine[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,trigonometrical[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,trithiocarbonic[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)

The threat actor hosts, on average, six domains on each VPS server, and then rotates to new ones when they are burned. After retro hunting back to June 2019, we collected over 400 unique IP addresses.

Looking at additional data sources, we can see that this browser locker campaign started at least in December 2017. At the time, the infrastructure was located on a different hosting provider and domains used the .WIN TLD.

Even back then, visiting the browlock URL directly (without proper redirection) would also result in a 404 page.

One lone artifact, an audio file (help.mp3), was indexed by VirusTotal and can be played below:

Again based on open source data, we created a rough timeline of the infrastructure the threat actors abused—from where they were first spotted on Petersburg Internet to moving briefly to DigitalOcean before settling on OVH from January 30, 2019 onward.

Steganography to hide redirection mechanism

Given that we couldn’t identify how this browlock was propagating, we figured it must be using an unconventional trick.

Many of the sites that victims reported being on when the browlock happened contained videos, so we thought one likely vector could be video ads. This form of malvertising is more advanced than traditional malicious banners because it enables the crooks to hide their payload within media content.

Once again, we spent a fair amount of time looking at video ads but still couldn’t identify the entry point. We switched our search to another type of medium but evidence was shared with us later on confirming the video ad infection vector.

Coincidentally, we had just been studying some interesting new developments with online credit card skimmers where malicious code was embedded into image files. This technique, known as steganography, is a clever way to hide artifacts from humans and scanners.

While developing tools to identify such rogue images, we came across what we thought might be the smoking gun. We discovered a PNG file that contained obfuscated data.

This time though, if the fraudsters were indeed using steganography, they certainly weren’t making it obvious. We identified a malformed PNG file that contained extra data after its end of file marker and looked suspicious.

Unlike the aforementioned credit card skimmer, which was clearly visible and recognizable with obvious character strings, this one looked like it was encoded. And clearly, the image on its own could not be weaponized without additional code to load with the per-victim unique key to decrypt it.

Anti-bot and traffic filtering

The JavaScript code that interacted with the PNG image used some light hex obfuscation and random variable naming to hide its intentions.

The hex string x57x45x42x47x4c decodes to WEBGL, and by decoding the rest of the obfuscated variable, we can see that this script is using the WEBGL_debug_renderer_info API to gather the victim’s video card properties. This allows the threat actors to sort real browsers (therefore real people) from crawlers or even virtual machines, which would not show the expected hardware information. The Zirconium group’s vast malvertising operation, disclosed in January 2018 by Jerome Dangu over at Confiant, also used that same API to filter traffic.

But perhaps the most interesting function within this JavaScript snippet is the one that processes the actual PNG image behind the steganography. The _Nux function parses the image data by using the @#@ delimeter (as seen in Figure 8 above) and stores it within the _OIEq variable.

If the user is detected as a bot or not interesting traffic, the PNG does not contain the extra data after the IEND end of file marker, and therefore the _OIEq variable will be empty.

The function still attempts to parse the PNG, but it will fail on the eval, and will not generate the browlock URL. The user, not being considered a proper candidate, will not be redirected and won’t even be aware of the fingerprinting that just happened.

This kind of filtering is not usually seen (except for advanced malvertising operations), which is one of the reasons why so many victims have experienced this browlock, yet little is known about it.

Anti-replay mechanism

The next evasion technique is intended for security folks, and those trying to troubleshoot these malicious redirections. A network traffic capture (SAZ, HAR) must include the malicious JavaScript, as well as the steganographic PNG and the browlock itself.

Similar to a technique we’ve previously only observed with exploit kits, the threat actor is using one-time tokens to prevent “artificial” replays of the redirection mechanism. If the proper session key is not provided, the decryption of the PNG data will fail to produce the browlock URL.

Once again, we must pause for a moment and note that this kind of complexity is unheard of for something like a browser locker. While cloaking techniques are common, this is by far the most covert way we’ve seen to redirect to any browlock.

Other traffic chains

After we had discovered the PNG redirection mechanism, we shared our findings with security firm Confiant. They were aware of the domain api.imagecloudsedo[.]com but had seen it in a different campaign. Confiant nicknamed it WOOF due to a string of the same name found in the code.

Additionally, Google, via Confiant’s intermediary, shared yet another instance that explains the number of redirections from newspaper sites we had been seeing. This second instance of the WOOf script was loaded via video widgets.

Digital Media Communications, a company that specializes in ads converted into widgets for the web, was apparently compromised several months ago. According to data collected by the Internet Archive, one of their scripts hosted at widgets.digitalmediacommunications[.]com/chosen/chosen.jquery.min.js was injected on August 13, 2019.

A number of websites, many of them news portals, load this widget and are therefore unwittingly exposing their visitors, as the compromised library subsequently retrieves the malicious PNG from api.imagecloudsedo[.]com before redirecting to the browlock page.

It’s highly likely that there are other compromises of third parties that haven’t been found yet, although we suspect that the methods used would be similar to the ones we know about.

Examining the browser locker page

The following diagram depicts what needs to take place in order for victims to get redirected to the browser locker page after several layers of validation.

Ultimately, the previously analyzed function will arrive at the eval part of the code and return code to launch the browlock.

top.location = '[browlock URL]';

This little bit of code redirects the current browser page to the new URL. It is, in fact, one of the most common techniques for malicious ads to redirect users to scam pages. We believe the threat actor is likely using the same trick for its other malvertising campaigns.

This browser locker is clean and contained as it obfuscates its source code and has few external dependencies, such as libraries. We can see that it uses the evil cursor, which is a flaw that allows criminals to create a fake cursor that tricks users into clicking on the wrong area when they are trying to close a browlock.

While Chrome and Edge users can somewhat get rid of the offending page, on Firefox, this is a true browlock, causing the browser to eventually crash.

The code used to freeze the browser has been duplicated enough times to render the browser useless. In the image below, we see the same function with slightly different parameters.

If we deobfuscate any of the functions, we recognize the history.pushState() method, which we reported back in 2016, and which is still not handled well by most browsers. This bug actually came to Mozilla’s attention three years ago, and more recently when someone reported the same 404Browlock:

Browser lockers can be difficult to fix because they often use code that is otherwise perfectly legitimate. Browser vendors often have to juggle with performance and compatibility issues at the same time.

Handing victims over to tech support scammers

The ultimate goal for browser lockers is to get people to call for assistance to resolve (non-existent) computer problems. This is handled by third parties via fraudulent call centers. The threat actor behind the traffic redirection and browlock will get paid for each successful lead.

To confuse victims, the fake Microsoft agent will tell you to run some commands simply intended to open up a browser window.

From there, they will ask you to download and run a remote assistance program that will enable them to take control of your computer. A few minutes later, they will use their favorite tool, notepad, to start drafting an invoice:

While the machine is still supposedly infected, they will simply browse to a site to take the payment for 1 year, 3 year, or 5 year plans costing $195, $245, and $345, respectively.

Where do we go from here?

Given the level of sophistication involved in this campaign, we can expect that the threat actor has diversified their traffic to have some kind of redundancy.

We hope that our efforts to expose this scheme will help others to identify the browlock redirections within their networks. Despite our repeated attempts to report these abuses, they have not been fixed. We remain available to OVH for closer collaboration to shut down this campaign.

For best protection against this and other browlocks, we recommend using our free browser extension, Browser Guard. Not only does it benefit from our domain and IP blacklist, but it can also detect and block browlocks and other tech support scams via signatureless techniques.

Acknowledgements

We would like to thank Confiant for sharing additional data regarding the other cases of the malicious script (_WOOf variant).

Thanks to @prsecurity_ for pointing out a quicker way to retrieve the browlock URL by RC4 decrypting the PNG data using the unique key found within the script.

Indicators of Compromise (IOCs)

There are simply too many IOCs to put here, so we’ve uploaded the browlock domains and IP addresses as a STIX2 file onto our GitHub page. It includes data going back to June 2019 based on indicators we collected by conducting retro hunting. Please note that this is only a partial account of this campaign based on the data we could collect.

Compromised library

widgets.digitalmediacommunications[.]com/chosen/chosen.jquery.min.js

Steganographic redirector

api.imagecloudsedo[.]com
141.98.81[.]198

Regex to identify the browlock URLs

/en/?search=w?(%[w_-~.]{1,4}){10,20}&list=([0-9]00000|null)$

The post WOOF locker: Unmasking the browser locker behind a stealthy tech support scam operation appeared first on Malwarebytes Labs.