If I were to ask if you could trust a script from Google that is loading on your website, the majority of users would say “yes” or even “absolutely”. But when malicious behavior ensues, everything should be double-checked and suspected, even assets that come from “trusted sources” like Google, Facebook, and Youtube.
In the past, we saw how adsense was abused with a malvertising campaign. Even more recently, we saw how attackers injected malware that called Google AdSense ads to generate revenue for the attackers, however, there’s an even more troublesome part of the toolkit that Google offers to webmasters – Google Tag Manager.
How GTM Works
With so many measurement tools out there, marketers need flexibility — whether that’s changing tags on the fly or having the ability to easily add tags from other sources.
In Google Tag Manager, marketers can add or change their own tags as needed. Tag Manager supports all tags and has easy-to-use turnkey templates for a wide range of Google and third-party tags — for web and mobile apps. Don’t see a tag listed? You can add it immediately as a custom tag. With so much flexibility, your campaign can be underway with just a few clicks.
How is Google Tag Manager Implemented?
The Google Tag Manager script is easily called on a website like this:
Where the ID of the script is, defines what content to bring. This makes it easy for an attacker to just change the ID to one that they control, making it hard for the webmaster to know if a compromise on their website has taken place unless he constantly keeps an eye on every change that happens and/or knows the GTM ID by heart.
Google Tag Manager Used to Load Malvertising
Now, let’s dig into it with a practical real-life occurrence that we came across recently.
This is a block of code we found on a Google Tag Manager script being used on a website:
That code makes the website load the following scripts:
They seem pretty normal, right? Two of them (Facebook) are seen quite often and act normally, but the one from adform[.]net is a different story. The name itself reveals that it loads ads, and since most ad networks have very lenient ad filters, this becomes a prime suspect for malicious behavior on the website. We’ll need to investigate it further.
Pop-ups and Redirects
The issues reported were pop-ups and redirects. Just a quick look at how the adform script was behaving gave the indication that something was off.
The script from adform[.]net was requesting a script from action.dstillery[.]com, which then redirected the request to the following URL:
This behavior is common with ads, but when investigating the media6degrees.com request, the data returned was:
It loads ads from other networks. This is a normal strategy for some advertisers, but the problem is that there are networks with known ineffective advertising policies which make it possible for ads with malicious intentions to pass their filters. As a consequence, this allows the ads to be delivered to your website and infect your visitors with several kinds of malware.
We then have the after effect that each of those networks can load other networks and several more scripts. Before we notice it, we have dozens of unknown scripts loading on the website and with each one of them, the potential risk for the visitors multiplies exponentially.
Some of those networks were causing the redirects and pop-ups, so going straight to the removal of the GTM script from the website fixes the problem immediately.
On a separate case which also faced pop-ups and redirects, nothing strange appeared to be loading on the website directly at first glance. As soon as we went to check the scripts which were being executed, we found this on the Google Tag Manager script:
In this case, the code would make the site load scripts from various usual domains, however, it also included hxxps://s.adroll[.]com, which takes us back to the suspicion of malvertising that can come with ad networks.
Upon further investigation, we could see that that adroll.com script was loading scripts from several other websites such as:
Several of these items are ad networks and are often chosen by attackers to display ads on your website to generate some revenue for them. Each of those could load dozens of other scripts.
Again, in this case, some of those networks were directly or indirectly responsible for the malicious behavior, so immediate removal of the GTM script fixed the issue.
In these two examples, it is still unclear if the client’s Google Tag Manager account was compromised and then the ads code added, if the client added the code himself to have ads showing up on his website, or if the attacker just changed the ID call on the script to make it load a version fully controlled by him.
Google Adword’s algorithms are blocking campaigns due to malicious ads such as these, which load from within the GTM script. This makes it imperative to keep in mind every bit of code that is being called from it.
In another example that we came across, the attackers simply replaced the ID of the Google Tag Manager to make it load the one that they wanted. Inside that Google Tag Manager script was a simple redirect that would take the visitor to another website, achieved with the following:
window.location.href = “http://www.yourdomain.com/somepage.html”;
Why Target Google Tag Manager?
One can see why Google Tag Manager’s script can be a potential source for hiding malicious activity. An attacker can just copy all the contents of your legitimate version and put it in their modified version while adding the malicious content. After that, it’s just a matter of changing the ID that your website is calling.
Since the script will come with Google’s name already, many webmasters most likely ignore it, which makes it perfect for the attackers to hide their code in.
It’s important to understand that a compromise of your website or of your Google Tag Manager account has to take place to allow the attacker to either replace the code or the ID called on the script for the script to be used for bad intentions.
There’s also the possibility that the webmaster himself added the code that then led to malicious activity, but this is something that the webmaster needs to be wary of at all times.
Moral of the Story
The point to be taken here is that seemingly trustworthy scripts can never be trusted when strange behaviors start happening on your website. The most innocent of scripts, even ones such as StatCounter, can wreak havoc on your website and reputation.
Any external assets which load on your website should be kept to a minimum so that you can maintain the most control over everything. Any accounts which are directly connected should be kept secure with strong and unique passwords.
If you believe your website has been compromised or is serving malicious content, we can help.