Multiple threat actors including ransomware operators and initial access brokers have started to abuse GoogleAds in a new way and it is really hard to spot how they do it.
Whats the problem?
When you search for something via Google search, the top couple of links are typically adverts, or sponsored links. In many cases the first advert you get is a monetised link to the place you actually want to go to, a little way down the page, the same link appears, but isn’t the monetised link.
Google know that most people don’t bother to scroll down the results, and click the 1st link that they feel will be the one to take them to the site they want.
When you examine Google’s Policy for creating sponsored / monetised ads, it states that the URL you see must take the user to the actual URL landing page – it cannot be a “mask” for a different URL.
This part of the policy is an attempt to instill a level of trust with advertisers and consumers, and give an assurance that people aren’t going to be tricked into visiting a fake site.
Well, in principle, this works (mostly) – Google’s AI actively scans adverts to check that the URL being shown matches the URL being clicked, and malicious adverts get taken offline fairly quickly.
However, criminals being criminals, have found a loop-hole. Researchers at Malwarebytes recently found such exploitation being used to deploy malicious copies of webex – the popular meeting application from Cisco.
The URL shown says it will direct the user to webex.com, but there are some nefarious deeds happening behind the scenes here.
The following image is a view of the underlying code for the above advert, which shows that the URL the user will click goes to webex.com. (Display URL). It also shows the Final URL which goes via Google adservices (for the monetisation) and eventually re-directs to webex.com/inclusive-colaboration.html
So where’s the problem?
The problem lies in the Tracking template URL.
The tracking template is the part of the sponsored advert that allows the owner of the advert to gain metrics from their user clicks – how many people saw the link, how many clicked it, where they are from, what did they type for this advert to be displayed, etc. All part of Search Engine Optimisation (SEO), and totally normal in this context.
However, tracking templates can be abused to hold URL re-direction links that can ultimately cause the user to visit fake sites, and be the victim of drive-by downloads.
In the example shown, the threat actors have created a Tracking template which goes to trixwe.page.link.
Code on this site checks to see if the visiting application is a real browser, or a sandbox system. If the site detects a sandbox, it redirects the visitor to the real webex website – this is done to ensure security analysts don’t spot the attack, and as such allows the malicious campain to remain online for longer.
If however, a real browser is used to click the link, a different set of actions occurs…
If the link is contacted via a real browser (as shown below), it performs a redirect to a site called monoo3at.com.
In this case the monoo3at website redirects the user to a site called webexadvertisingoffer.com which is 100% fake and NOT associated with Cisco.
If the user downloads this application, they will install a trojan file dropper which deploys malware.
The fake app runs a number of scripts, one of which calls out to a C2 server to download the actual malware payload.
In this instance, the malware downloaded is a copy of the DanaBot malware which is a favoured malware of a number of ransomware gangs, including the recently disrupted Qakbot gang, who seem to have resurfaced with new C2 infrastructure after the FBI took down their previous setup back in August.
As can be seen, it is really difficult for any user to spot a good, sponsored link, from a bad sponsored link.
Bring out the pi-hole!
It’s exactly situations like this that I use a pi-hole to ensure sponsored links (good or bad) can never be accessed by devices in my network.
When anyone in my network clicks a sponsored link, my pi-hole intercepts the DNS request, checks to see if the URL is on tha allow, or deny lists and if denied – responds with an empty IP address (0.0.0.0) which makes the browser report back that the site cannot be reached – if the site cannot be reached, no redirects can happen, and no malware can be downloaded.
I wrote extensively at the beginning of the year about the benefits of running a pi-hole, and how to set-up and configure on in your own network. As this year starts to draw to an end, my 365 days of blogs challenge do so as well, so it seems quite poignant that my 1st few posts, and one of my final posts for the year concerns the same subject.
- (04-01-23) Blog 4 – Blocking ads and more with a Pi-hole
- (05-01-23) Blog 5 – Pi-hole, post install activities
- (06-01-23) Blog 6 – Blocking those pesky ads
- (07-01-23) Blog 7 – customising your pi-hole
- (08-01-23) Blog 8 – analysing your data
- (09-01-23) Blog 9 – Changing your view
- (10-01-23) Blog 10 – Enhancing the Pi-hole
- (11-01-23) Blog 11 – installing a VPN
I cannot stress enough how important it is to be on your guard when surfing the web – running a pi-hole really does take much of the stress of modern-day browsing away.
