Tech support browser lockers continue to be one of the most common web threats. Not only are they a problem for end users who might end up on the phone with scammers defrauding them of hundreds of dollars, they’ve also caused quite the headache for browser vendors to fix.
Browser lockers are only one element of a bigger plan to redirect traffic from certain sites, typically via malvertising chains from adult portals or sites that offer pirated content.
There’s a slightly different campaign that we’ve been tracking for several weeks due to its high volume. Threat actors are relying on Facebook to distribute malicious links that ultimately redirect to a browser locker page. Their approach is interesting because it involves a few layers of deception including abusing a cross-site scripting vulnerability (XSS) on a popular website.
Malicious links shared via Facebook
Links posted onto social media platforms should always be scrutinized as they are a commonly abused way for scammers and malware authors to redirect users onto undesirable content. For this reason, you might see a disclaimer when you click on a link, warning you that it could be spam or dangerous.
The campaign we looked at appears to exclusively use links posted on Facebook, which is fairly unusual considering that traditionally tech support scams are spread via malvertising. Facebook displays a warning for the user to confirm that they want to follow the link. In this case, the destination is further obscured by the fact that the link is a bit.ly shortened URL.
The threat actor is using the bit.ly URL shortener to craft the first stage of redirection. In total, we catalogued 50 different bit.ly links (see IOCs) over a 3 month period, suggesting that there is regular rotation to avoid blacklisting.
Although we do not know exactly how these links are being shared with Facebook users, we have some indication that certain games (i.e. apps on the Facebook site) may help to spread them. Because this is out of our reach, we have alerted Facebook in case it is able to identify the exact source.
Abuse of cross-site scripting vulnerability
The bit.ly URL triggers the second stage redirection that involves a Peruvian website (rpp[.]pe) which contains a cross-site scripting vulnerability (XSS) that allows for an open redirect. Threat actors love to abuse open redirects as it gives some legitimacy to the URL they send victims. In this instance, the news site is perfectly legitimate and draws over 23 million visits a month.
Besides redirecting users to other sites, an attacker could exploit the XSS to rewrite the current page into anything they like.
We reported this issue to Grupo RPP but have not heard back at the time of publication.
The open redirect trick is something that was added later on in the campaign. Originally the threat actors were directly loading decoy cloaking domains. Their purpose is to check incoming traffic and only serve the malicious content to legitimate victims. This is a very common practice and we’ve seen this before, for example with fake recipe sites.
We documented 6 domains involved in this third stage of the redirection process:
The code (shared above) loads the browser locker landing page to one of the disposable and randomly-named domains using one of the newer TLDs:
We collected close to 500 such domains (see IOCs) during a period of a few months, but there are likely many more.
Browser locker at the end of the chain
The browser locker fingerprints the user to display the appropriate version for their browser. It shows an animation mimicking a scan of current system files and threatens to delete the hard drive after five minutes.
Of course this is all fake, but it’s convincing enough that some people will call the toll-free number for assistance. In all, we collected almost 40 different phone numbers (see IOCs) but this is not an exhaustive list.
This is where it ends for the traffic scheme, but where it truly begins for the tech support scam. We did not make contact with the call centre, but we know very well how this next part plays out.
Malwarebytes users were already protected against this browser locker, thanks to our Browser Guard web protection. We will continue to track and report this campaign.
Thanks to Marcelo Rivero for helping with the replay and Manuel Caballero for his insights on the XSS.
Indicators of Compromise